Change:
In this diagram, the protocol between Attester and a Relying Party can be any new or existing protocol (e.g., HTTP(S), COAP(S), ROLIE <del> RFC8322, 802.1x, OPC UA, etc.), depending on the use case.  Such protocols typically already have mechanisms for passing security </del> <ins> RFC8322, 802.1x, OPC UA OPCUA, etc.), depending on the use case. Such protocols typically already have mechanisms for passing security </ins> information for purposes of authentication and authorization.  Common formats include JWTs RFC7519, CWTs RFC8392, and X.509 certificates. <del> To enable remote attestation to be added to existing protocols, enabling a higher level of assurance against malware for example, it is important that information needed for appraising the Attester be usable with existing protocols that have constraints around what formats they can transport.  For example, OPC UA OPCUA (probably the most common protocol in industrial IoT environments) is defined to carry X.509 certificates and so security information must be embedded into an X.509 certificate to be passed in the protocol.  Thus, remote attestation related information could be natively encoded in X.509 certificate extensions, or could be natively encoded in some other format (e.g., a CWT) which in turn is then encoded in an X.509 certificate extension. Especially for constrained nodes, however, there is a desire to minimize the amount of parsing code needed in a Relying Party, in order to both minimize footprint and to minimize the attack surface area.  So while it would be possible to embed a CWT inside a JWT, or a JWT inside an X.509 extension, etc., there is a desire to encode the information natively in the format that is natural for the Relying Party. </del> <ins> Retrofitting already deployed protocols with remote attestation requires adding RATS conceptual messages to the existing data flows. This must be done in a way that doesn't degrade the security properties of the system and should use the native extension mechanisms provided by the underlying protocol.  For example, if the TLS handshake is to be extended with remote attestation capabilities, attestation Evidence may be embedded in an ad hoc X.509 certificate extension (e.g., TCG-DICE), or into a new TLS Certificate Type (e.g., I-D.tschofenig-tls-cwt). Especially for constrained nodes there is a desire to minimize the amount of parsing code needed in a Relying Party, in order to both minimize footprint and to minimize the attack surface area.  So while it would be possible to embed a CWT inside a JWT, or a JWT inside an X.509 extension, etc., there is a desire to encode the information natively in the format that is natural for the Relying Party. </ins> This motivates having a common "information model" that describes the set of remote attestation related information in an encoding-agnostic

Discussion:
This sentence: it's quite hard to digest. But more generally, the motivating use case (OPC UA) is slightly convoluted, and I'm wondering whether it is really needed? But assuming it were, the exposition needs to be improved to present a clear and compelling case.
I cannot speak for the applicability of OPC UA here. It seems to be an item in an already long list. I actually wonder more why EAP is not in there to add some diversity. Having said that, how about:
Looks much better, thanks! Elaborating a bit further: "Retrofitting already deployed protocols with remote attestation requires adding RATS conceptual messages to the existing data flows. This must be done in a way that doesn't degrade the security properties of the protocol and should use the native extension mechanisms (if available). For example, if an authentication protocol (e.g., the TLS handshake) has to be extended with remote attestation capabilities, attestation Evidence may be embedded in an ad-hoc X.509 certificate extension, or into a new TLS Certificate Type."
You had me at "retro". In my kickstarting proposal, I barged on with "DER", which is now gone but now there are TLS and Certificate Type for elaboration. None, one, or all? I don't want to overload that paragraph with arbitrary examples. Unfortunately, now these start to seem arbitrary to me. What is the reasoning for choosing examples here, actually?
These are both existing mechanisms: the first (new cert extension) is , the second (new TLS cert type) is . I dropped DER as it's a necessity when using x.509 certs, and looked redundant.
That actually helped me a lot! Maybe we should pull these reference in? I am aware that it is sometimes better to shy away from specifica, but in this case I think it would help the reader to be more specific. Thoughts?
Doing a background check on OP CUA, I've found that the is not open, and that there are only two research papers that talk about adding attestation to the existing model: (2020) and (2017). This paucity of related content makes its presence as a "demo" use case a bit brittle. I suggest we remove it. DICE and TLS-CWT should be enough.