retransmissions.  Note that the client sends an empty ACK message because it can only acknowledge Record 1 sent by the server once it has processed messages in Record 0 needed to establish epoch 2 keys, <del> which are needed to encrypt to decrypt messages found in Record 1. </del> <ins> which are needed to encrypt or decrypt messages found in Record 1. </ins> ack-msg provides the necessary background details for this interaction.


peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight retransmission in previous versions of DTLS.  For instance in the <del> flow shown in Figure 11 if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </del> <ins> flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is recommended. </ins> The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 13, acknowledges receipt and processing of record 4 (containing the NewSessionTicket message) and if it is not sent the server will continue retransmission of the NewSessionTicket <del> indefinitely until its transmission cap is reached. </del> <ins> indefinitely until its maximum retransmission timemout value is reached. </ins> 8.


sequence number fields in the DTLSCiphertext structure have been reduced from those in previous versions. <ins> The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility with DTLS 1.2.  However, this value is set as the least significant 2 octets of the connection epoch, which is an 8 octet counter incremented on every KeyUpdate.  See seq-and-epoch for details.  The sequence number is set to be the low order 48 bits of the 64 bit sequence number.  Plaintext records MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the upper 16 bits will always be 0. </ins> The DTLSCiphertext structure has a variable length header. DTLSPlaintext records are used to send unprotected records and


compatibility purposes.  It MUST be ignored for all purposes.  See TLS13; Appendix D.1 for the rationale for this. <ins> The least significant 2 bytes of the connection epoch value. </ins> The unified header (unified_hdr) is a structure of variable length, as shown in cid_hdr.


When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below: <del> This 64-bit value is used in the ACK message as well as in the "record_sequence_number" input to the AEAD function. </del> <ins> This 128-bit value is used in the ACK message. </ins> The entire header value shown in hdr_examples (but prior to record number encryption, see rne) is used as as the additional data value for the AEAD function.  For instance, if the minimal variant is used, the AAD is 2 octets long.  Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with <del> Connection ID. </del> <ins> Connection ID.  In DTLS 1.3 the 64-bit sequence_number is used as the sequence number for the AEAD computation; unlike DTLS 1.2, the epoch is not included. </ins> 4.1.


Implementations MUST either abandon an association or re-key prior to allowing the sequence number to wrap. <del> Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. </del> 4.2.2. When receiving protected DTLS records, the recipient does not have a full epoch or sequence number value in the record and so there is <del> some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </del> <ins> some opportunity for ambiguity.  Because the full sequence number is used to compute the per-record nonce and the epoch determines the keys, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. </ins> If the epoch bits match those of the current epoch, then implementations SHOULD reconstruct the sequence number by computing


include handshake messages, such as post-handshake messages (e.g., a NewSessionTicket message). <del> epoch value (4 to 2^16-1) is used for payloads protected using </del> <ins> epoch value (4 to 2^64-1) is used for payloads protected using </ins> keys from the [sender]_application_traffic_secret_N (N>0). Using these reserved epoch values a receiver knows what cipher state


successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"


the "TLS Alerts" registry with value 52. IANA is requested to allocate two values in the "TLS Handshake Type" <del> registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for </del> <ins> registry, defined in TLS13, for request_connection_id (TBD), and new_connection_id (TBD), as defined in this document.  The value for </ins> the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher


the connection establishment. With these exceptions, the DTLS message formats, flows, and logic are <del> the same as those of TLS 1.3. </del> <ins> the same as those of TLS 1.3.  DTLS implementations SHOULD not use the TLS 1.3 "compatibility mode" described in I-D.ietf-tls-tls13, Section D.4 and DTLS servers SHOULD ignore the "session_id" value generated by the client rather than sending ChangeCipherSpec messages.  Implementations MUST still ignore ChangeCipherSpec messages received during the handshake and at all other times SHOULD treat them as if they had failed to deprotect. </ins> 5.1.


Same as for TLS 1.3. A DTLS 1.3-only client MUST set the legacy_cookie field to zero <del> length. </del> <ins> length.  If a DTLS 1.3 ClientHello is received with any other value in this field, the server MUST abort the handshake with an "illegal_parameter" alert. </ins> Same as for TLS 1.3.


4.1.3. <del> When the Push method is assigned to a binding, the source endpoint sends PUT requests to the destination resource when the Conditional Notification Attributes are satisfied for the source resource.  The source endpoint SHOULD only send a notification request if any included Conditional Notification Attributes are met.  The binding entry for this method MUST be stored on the source endpoint. </del> <ins> The Push method can be used to allow a source endpoint to replace an outdated resource state at the destination with a newer representation.  When the Push method is assigned to a binding, the source endpoint sends PUT requests to the destination resource when the Conditional Notification Attributes are satisfied for the source resource.  The source endpoint SHOULD only send a notification request if any included Conditional Notification Attributes are met. The binding entry for this method MUST be stored on the source endpoint. 4.1.4. An alternative means for a source endpoint to deliver change-of-state notifications to a destination resource is to use the Execute Method. While the Push method simply updates the state of the destination resource with the representation of the source resource, Execute can be used when the destination endpoint wishes to receive all state changes from a source.  This allows, for example, the existence of a resource collection consisting of all the state changes at the destination endpoint.  When the Execute method is assigned to a binding, the source endpoint sends POST requests to the destination resource when the Conditional Notification Attributes are satisfied for the source resource.  The source endpoint SHOULD only send a notification request if any included Conditional Notification Attributes are met.  The binding entry for this method MUST be stored on the source endpoint. Note: Both the Push and the Execute methods are examples of Server Push mechanisms that are being researched in the Thing-to-Thing Research Group (T2TRG) I-D.irtf-t2trg-rest-iot. </ins> 4.2.


9. <ins> draft-ietf-core-dynlink-10 Binding methods now support both POST and PUT operations for server push. </ins> draft-ietf-core-dynlink-09 Corrections in Table 1, Table 2, Figure 2.


seconds, between two consecutive notifications (whether or not the resource value has changed).  In the absence of this parameter, the maximum period is up to the server.  The maximum period MUST be <del> greater than zero and MUST be greater than the minimum period parameter (if present) otherwise the receiver MUST return a CoAP error code 4.00 "Bad Request" (or equivalent). </del> <ins> greater than zero and MUST be greater than, or equal to, the minimum period parameter (if present) otherwise the receiver MUST return a CoAP error code 4.00 "Bad Request" (or equivalent). </ins> 3.1.3.


the request does not contain a fresh Echo option value, and the server cannot verify the freshness of the request in some other way, the server MUST NOT process the request further and SHOULD send a <del> 4.01 Unauthorized response with an Echo option. </del> <ins> 4.01 Unauthorized response with an Echo option.  The server MAY include the same Echo option value in several different responses and to different clients. </ins> The application decides under what conditions a CoAP request to a resource is required to be fresh.  These conditions can for example


Cryptographically, EDHOC does not put requirements on the lower layers.  EDHOC is not bound to a particular transport layer, and can <del> be used in environments without IP.  The transport is responsible to handle message loss, reordering, message duplication, fragmentation, and denial of service protection, where necessary. </del> <ins> be used in environments without IP.  The application using EDHOC is responsible to handle message loss, reordering, message duplication, fragmentation, demultiplex EDHOC messages from other types of messages, and denial of service protection, where necessary. </ins> The Initiator and the Responder need to have agreed on a transport to be used for EDHOC, see applicability.  It is recommended to transport


Pass AD_1 to the security application. <del> If any verification step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the protocol MUST be discontinued. </del> <ins> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error, and the session MUST be discontinued.  Sending error messages is essential for debugging but MAY e.g. be skipped due to denial of service reasons, see security. </ins> 5.4.


Pass AD_2 to the security application. <del> If any verification step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in error, and the protocol MUST be discontinued. </del> <ins> If any processing step fails, the Initiator SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY e.g.be skipped if a session cannot be found or due to denial of service reasons, see security.  If an error message is sent, the session MUST be discontinued. </ins> 5.5.


security application.  The application can now derive application keys using the EDHOC-Exporter interface. <del> If any verification step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the protocol MUST be discontinued. </del> <ins> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY e.g.be skipped if a session cannot be found or due to denial of service reasons, see security.  If an error message is sent, the session MUST be discontinued. </ins> After verifying message_3, the Responder is assured that the Initiator has calculated the key PRK_4x3m (explicit key confirmation)


transported depends on lower layers, which need to enable error messages to be sent and processed as intended. <del> All error messages in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error messages might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </del> <ins> Errors in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error message might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </ins> error SHALL be a CBOR Sequence (see CBOR) as defined below


cipher suite, and the parameters defined in asym-msg4-proc. If any verification step fails the Initiator MUST send an EDHOC error <del> message back, formatted as defined in error, and the protocol MUST be </del> <ins> message back, formatted as defined in error, and the session MUST be </ins> discontinued. 7.2.


the initiator to demonstrate reachability at its apparent network address. <ins> An attacker can also send faked message_2, message_3, message_4, or error in an attempt to trick the receiving party to send an error message and discontinue the session.  EDHOC implementations MAY evaluate if a received message is likely to have be forged by and attacker and ignore it without sending an error message or discontinuing the session. </ins> 8.6. The availability of a secure random number generator is essential for


Application keys and other application specific data can be derived using the EDHOC-Exporter interface defined as: <del> where label is a tstr defined by the application and length is a uint defined by the application.  The label SHALL be different for each different exporter value.  The transcript hash TH_4 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del> <ins> label_context is a CBOR sequence: </ins> <del> where H() is the hash function in the selected cipher suite.  Example use of the EDHOC-Exporter is given in I-D.ietf-core-oscore-edhoc. </del> <ins> where label is a registered tstr from the EDHOC Exporter Label registry (exporter-label), context is a bstr defined by the application, and length is a uint defined by the application.  The (label, context) pair must be unique, i.e. a (label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same key several times as long as it is done in a secure way.  For example, in most encryption algorithms the same (key, nonce) pair must not be reused. The transcript hash TH_4 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. where H() is the hash function in the selected cipher suite. Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and I-D.ietf-core-oscore-edhoc. </ins> To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the function EDHOC-KeyUpdate.  When EDHOC-KeyUpdate is called the old PRK_4x3m is deleted and the new <del> PRk_4x3m is calculated as a "hash" of the old key using the Extract </del> <ins> PRK_4x3m is calculated as a "hash" of the old key using the Extract </ins> function as illustrated by the following pseudocode: 5.


9.1. <ins> IANA has created a new registry titled "EDHOC Exporter Label" under the new heading "EDHOC".  The registration procedure is "Expert Review".  The columns of the registry are Label, Description, and Reference.  All columns are text strings.  The initial contents of the registry are: 9.2. </ins> IANA has created a new registry titled "EDHOC Cipher Suites" under the new heading "EDHOC".  The registration procedure is "Expert Review".  The columns of the registry are Value, Array, Description, and Reference, where Value is an integer and the other columns are text strings.  The initial contents of the registry are: <del> 9.2. </del> <ins> 9.3. </ins> IANA has created a new registry entitled "EDHOC Method Type" under the new heading "EDHOC".  The registration procedure is "Expert


strings.  The initial contents of the registry is shown in fig- method-types. <del> 9.3. </del> <ins> 9.4. </ins> IANA has created a new registry entitled "EDHOC Error Codes" under the new heading "EDHOC".  The registration procedure is


is a CDDL defined type, and Description is a text string.  The initial contents of the registry is shown in fig-error-codes. <del> 9.4. </del> <ins> 9.5. </ins> IANA has added the well-known URI 'edhoc' to the Well-Known URIs registry.


Related information: None <del> 9.5. </del> <ins> 9.6. </ins> IANA has added the media type 'application/edhoc' to the Media Types registry.


Change Controller: IESG <del> 9.6. </del> <ins> 9.7. </ins> IANA has added the media type 'application/edhoc' to the CoAP Content-Formats registry.


Reference: [[this document]] <del> 9.7. </del> <ins> 9.8. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what


Responder, respectively, see m3 and m2. When the credential is a certificate, CRED_x is an end-entity <del> certificate (i.e., not the certificate chain), encoded as a CBOR bstr.  In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement". </del> <ins> certificate (i.e., not the certificate chain).  In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement". </ins> To prevent misbinding attacks in systems where an attacker can register public keys without proving knowledge of the private key,


external_aad = << TH_2, CRED_R, ? EAD_2 >> <del> CRED_R - bstr containing the credential of the Responder, see </del> <ins> CRED_R - CBOR item containing the credential of the Responder, see </ins> EAD_2 = unprotected external authorization data, see


external_aad = << TH_3, CRED_I, ? EAD_3 >> <del> CRED_I - bstr containing the credential of the Initiator, see id_cred. </del> <ins> CRED_I - CBOR item containing the credential of the Initiator, see id_cred. </ins> EAD_3 = protected external authorization data, see


algorithms (AEAD, hash) in the selected cipher suite (see cs) and the application can make use of the established connection identifiers C_I and C_R (see ci).  EDHOC may be used with the media type <del> application/edhoc defined in media-type. </del> <ins> application/edhoc+cbor-seq defined in media-type. </ins> The Initiator can derive symmetric application keys after creating EDHOC message_3, see exporter.  Protected application data can


9.8. <del> IANA has added the media type "application/edhoc" to the "Media Types" registry. </del> <ins> IANA has added the media types "application/edhoc+cbor-seq" and "application/cid-edhoc+cbor-seq" to the "Media Types" registry. 9.8.1. </ins> Type name: application <del> Subtype name: edhoc </del> <ins> Subtype name: edhoc+cbor-seq </ins> Required parameters: N/A


Change Controller: IESG <del> 9.9. </del> <ins> 9.8.2. Type name: application Subtype name: cid-edhoc+cbor-seq </ins> <del> IANA has added the media type "application/edhoc" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </del> <ins> Required parameters: N/A </ins> <del> Media Type: application/edhoc </del> <ins> Optional parameters: N/A </ins> <del> Encoding: </del> <ins> Encoding considerations: binary </ins> <del> ID: TBD42 </del> <ins> Security considerations: See Section 7 of this document. </ins> <del> Reference: [[this document]] </del> <ins> Interoperability considerations: N/A Published specification: [[this document]] (this document) Applications that use this media type: To be identified Fragment identifier considerations: N/A Additional information: Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: See "Authors' Addresses" section. Intended usage: COMMON Restrictions on usage: N/A Author: See "Authors' Addresses" section. Change Controller: IESG 9.9. IANA has added the media types "application/edhoc+cbor-seq" and "application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </ins> 9.10.


of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. <ins> A static Diffie-Hellman key for authentication in method 1, 2 or 3 MUST NOT not be used as a digital signature key for authentication in method 0, unless proven secure by a dedicated cryptographic analysis. A preliminary conjecture is that a minor change to EDHOC may be sufficient to fit the analysis of secure shared signature and ECDH key usage in [Degabriele2011] and [[Thormarker2021]]. </ins> So-called selfie attacks are mitigated as long as the Initiator does not have its own identity in the set of Responder identities it is allowed to communicate with.  In trust on first use (TOFU) use cases


protect against passive attacker as active attackers can always get the Responder's identity by sending their own message_1.  EDHOC uses the Expand function (typically HKDF-Expand) as a binary additive <del> stream cipher.  HKDF-Expand is not often used as it is slow on long messages, and most applications require both IND-CCA confidentiality as well as integrity protection.  For the encryption of message_2, any speed difference is negligible, IND-CCA does not increase security, and integrity is provided by the inner MAC (and signature depending on method). </del> <ins> stream cipher which is proven secure as long as the expand function is a PRF.  HKDF-Expand is not often used as a stream cipher as it is slow on long messages, and most applications require both IND-CCA confidentiality as well as integrity protection.  For the encryption of message_2, any speed difference is negligible, IND-CCA does not increase security, and integrity is provided by the inner MAC (and signature depending on method). </ins> Requirements for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve.  For X25519 and


of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. <del> A static Diffie-Hellman key for authentication in method 1, 2 or 3 MUST NOT not be used as a digital signature key for authentication in method 0, unless proven secure by a dedicated cryptographic analysis. </del> <ins> As noted in Section 12 of I-D.ietf-cose-rfc8152bis-struct the use of a single key for multiple algorithms is strongly disencouraged unless proven secure by a dedicated cryptographic analysis.  In particular this recommendation applies to using the same private key for static Diffie-Hellman authentication and digital signature authentication. </ins> A preliminary conjecture is that a minor change to EDHOC may be sufficient to fit the analysis of secure shared signature and ECDH key usage in Degabriele11 and Thormarker21.


such code to be read or tampered with by code outside that environment. <ins> Note that HKDF-Expand has a relativly small maximum output length of 255 * hash_length.  This means that when when SHA-256 is used as hash algorithm, message_2 cannot be longer than 8160 bytes. </ins> The sequence of transcript hashes in EHDOC (TH_2, TH_3, TH_4) do not make use of a so called running hash, this is a design choice as running hashes are often not supported on constrained platforms.


much previous information as possible.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, <del> COSE, and CoAP libraries. </del> <ins> COSE, and CoAP libraries.  Like (D)TLS, authentication is the responsibility of the application, EDHOC identifies (and optionally transports) authentication credentials, and provides proof-of- possession of the private authentication key. </ins> To simplify for implementors, the use of CBOR and COSE in EDHOC is summarized in CBORandCOSE.  Test vectors including CBOR diagnostic


So-called selfie attacks are mitigated as long as the Initiator does not have its own identity in the set of Responder identities it is <del> allowed to communicate with.  In trust on first use (TOFU) use cases the Initiator should verify that the Responder's identity is not equal to its own.  Any future EHDOC methods using e.g., pre-shared keys might need to mitigate this in other ways. </del> <ins> allowed to communicate with.  In Trust on first use (TOFU) use cases, see tofu, the Initiator should verify that the Responder's identity is not equal to its own.  Any future EHDOC methods using e.g., pre- shared keys might need to mitigate this in other ways. </ins> 8.3.


3.8. <del> In order to reduce round trips and the number of messages or to </del> <ins> In order to reduce round trips and the number of messages, or to </ins> simplify processing, external security applications may be integrated into EDHOC by transporting authorization related data in the messages. <del> EDHOC allows opaque external authorization data (EAD) to be sent in each of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4). </del> <ins> EDHOC allows processing of external authorization data (EAD) to be defined in a separate specification, and sent in dedicated fields of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4).  EAD is opaque data to EDHOC. </ins> <del> External authorization data is a CBOR sequence (see CBOR) consisting of one or more (ead_label, ead_value) pairs as defined below: </del> <ins> Each EAD field is a CBOR sequence (see CBOR) consisting of one or more EAD items (ead_label, ead_value) as defined below: </ins> A security application using external authorization data need to <del> register an ead_label, specify the ead_value format for each message (see iana-ead), and describe processing and security considerations. </del> <ins> register a positive ead_label and the associated ead_value format for each EAD item it uses (see iana-ead), and describe processing and security considerations.  Each application registers their own EAD items and defines associated operations.  The application may define multiple uses of certain EAD items, e.g., the same EAD item may be used in different EDHOC messages with the same application. An EAD item can be either critical or non-critical, determined by the sign of the ead_label in the transported EAD item included in the EDHOC message.  Using the registered positive value indicates that the EAD item is non-critical.  The corresponding negative value indicates that the EAD item is critical. ead_label = 0 MUST NOT be used. If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, the EDHOC protocol MUST be discontinued.  A non-critical EAD item can be ignored. The specification registring a new EAD label needs to describe under what conditions the EAD item is critical or non-critical. </ins> The EAD fields of EDHOC must not be used for generic application <del> data.  Examples of the use of EAD is provided in ead-appendix. </del> <ins> data.  Examples of the use of EAD are provided in ead-appendix. </ins> 3.9.


Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.


3.1. The EDHOC protocol consists of three mandatory messages (message_1, <del> message_2, message_3) between Initiator and Responder, an optional fourth message (message_4), and an error message.  All EDHOC messages are CBOR Sequences RFC8742, and are deterministically encoded. fig- flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol </del> <ins> message_2, message_3) between an Initiator and a Responder, an optional fourth message (message_4), and an error message.  The roles have slightly different security properties which should be considered when the roles are assigned, see sec-prop.  All EDHOC messages are CBOR Sequences RFC8742, and are deterministically encoded. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol </ins> elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error.


respectively, and the public authentication keys are denoted G_I and G_R, respectively. <del> For X.509 certificates the authentication key is represented with a </del> <ins> For X.509 certificates the authentication key is represented by a </ins> SubjectPublicKeyInfo field.  For CWT and CCS (see auth-cred)) the <del> authentication key is represented with a 'cnf' claim RFC8747 containing a COSE_Key RFC9052. </del> <ins> authentication key is represented by a 'cnf' claim RFC8747 containing a COSE_Key RFC9052.  In EDHOC, a raw public key (RPK) is an authentication key encoded as a COSE_Key wrapped in a CCS. </ins> 3.5.2. The authentication credentials, CRED_I and CRED_R, contain the public authentication key of the Initiator and the Responder, respectively. <ins> The authentication credential typically also contains other parameters that needs to be verified by the application, see auth- validation, and in particular information about the identity ("subject") of the endpoint to prevent misbinding attacks, see identities. </ins> EDHOC relies on COSE for identification of credentials (see id_cred), for example X.509 certificates RFC5280, C509 certificates I-D.ietf- cose-cbor-encoded-cert, CWTs RFC8392 and CWT Claims Sets (CCS) RFC8392.  When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 <del> certificate / CWT. </del> <ins> certificate / CWT.  The Initiator and the Responder MAY use different types of authentication credentials, e.g., one uses an RPK and the other uses a public key certificate. </ins> Since CRED_R is used in the integrity verification, see asym- msg2-proc, it needs to be specified such that it is identical when


SHALL be the C509Certificate I-D.ietf-cose-cbor-encoded-cert. When the authentication credential is a CWT including a COSE_Key, <del> then CRED_x SHALL be the untagged CWT. </del> <ins> CRED_x SHALL be the untagged CWT. </ins> When the authentication credential includes a COSE_Key but is not <del> in a CWT, CRED_x SHALL be an untagged CCS. </del> <ins> in a CWT, CRED_x SHALL be an untagged CCS.  This is how RPKs are encoded, see fig-ccs for an example. </ins> <del> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, which is done by prefixing the COSE_Key with 0xA108A101. </del> <ins> Naked COSE_Keys are thus dressed as CCS when used in EDHOC, in its simplest form by prefixing the COSE_Key with 0xA108A101 (a map with a 'cnf' claim).  In that case the resulting authentication credential contains no other identity than the public key itself, see identities. </ins> An example of a CRED_x is shown below:


protocol execution (specifically, cipher suite, see cs) but other parameters are only communicated and may not be negotiated (e.g., which authentication method is used, see method).  Yet other <del> parameters need to be known out-of-band. </del> <ins> parameters need to be known out-of-band.  The application decides which endpoint is Initiator and which is Responder. </ins> The purpose of an application profile is to describe the intended use of EDHOC to allow for the relevant processing and verifications to be


Transport of external authorization data. EDHOC is designed to encrypt and integrity protect as much <del> information as possible.  Symmetric keys and random material derived using EDHOC_KDF are derived with as much previous information as possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, </del> <ins> information as possible.  Symmetric keys and random material used in EDHOC are derived using EDHOC_KDF with as much previous information as possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, </ins> processing, and the ability to reuse already existing CBOR, COSE, and CoAP libraries.  Like in (D)TLS, authentication is the responsibility of the application.  EDHOC identifies (and optionally transports)


length, the output length in bits. <del> fig-edhoc-kdf lists derivations made with EDHOC_KDF during message processing, where </del> <ins> fig-edhoc-kdf lists derivations made with EDHOC_KDF, where </ins> hash_length - length of output size of the EDHOC hash algorithm of the selected cipher suite


4.1.3. <del> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is </del> <ins> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf, is </ins> the output session key of a successful EDHOC exchange. <del> Keys for applications are derived using EDHOC_Exporter from PRK_exporter (see exporter) which in turn is derived from PRK_out. For the purpose of generating application keys, it is sufficient to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a Trusted Execution Environment, see impl-cons). </del> <ins> Keys for applications are derived using EDHOC_Exporter (see exporter) from PRK_exporter, which in turn is derived from PRK_out as shown in fig-edhoc-kdf.  For the purpose of generating application keys, it is sufficient to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a Trusted Execution Environment, see impl-cons). </ins> 4.2. This section defines EDHOC_Exporter in terms of EDHOC_KDF and <del> PRK_out.  A key update function is defined in keyupdate. </del> <ins> PRK_exporter.  A key update function is defined in keyupdate. </ins> 4.2.1.


length is a uint defined by the application <del> PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. </del> The (exporter_label, context) pair used in EDHOC_Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same


(method equals 1 or 3), then mac_length_2 is the EDHOC MAC length of the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then <del> mac_length_2 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del> <ins> mac_length_2 is equal to hash_length. </ins> ID_CRED_R - identifier to facilitate the retrieval of CRED_R, see


(method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then <del> mac_length_3 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del> <ins> mac_length_3 is equal to hash_length. </ins> ID_CRED_I - identifier to facilitate the retrieval of CRED_I, see


4. <del> Applications MUST use external PSKs that adhere to the following requirements: Each PSK MUST be derived from at least 128 of entropy and MUST be at least 128-bits long unless the TLS handshake is being used with a separate key establishment mechanism such as a Diffie-Hellman exchange.  This recommendation protects against passive attacks using exhaustive search of the PSK. </del> <ins> Applications MUST adhere to the following requirements for external PSKs: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a


violated, then the security properties of TLS are severely weakened. As discussed in use-cases, there are use cases where it is desirable <del> for multiple clients or multiple servers share a PSK.  If this is </del> <ins> for multiple clients or multiple servers to share a PSK.  If this is </ins> done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious


appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when <del> using external PSKs if these risks. </del> <ins> using external PSKs to mitigate these risks. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can


constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. <del> Some devices are provisioned PSKs via an out-of-band, cloud-based </del> <ins> Some devices provision PSKs via an out-of-band, cloud-based </ins> syncing protocol. Some secrets may be baked into or hardware or software device


Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH <del> exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </del> <ins> exchange for forward secrecy.  As discussed in sec-properties, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided.  Low entropy keys are only secure against active attack if a Password Authenticated Key Exchange (PAKE) is used with TLS. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a


6.1. <del> Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </del> <ins> Most major TLS implementations support external PSKs.  Stacks supporting external PSKs provide interfaces that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </ins> OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake. <del> These callbacks must provide a PSK identity (as a character string) and key (as a byte string).  (If no identity is provided, a default one is assumed.)  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </del> <ins> These callbacks must provide a PSK identity and key.  The exact format of the callback depends on the negotiated TLS protocol version with new callback functions added specifically to OpenSSL for TLS 1.3 RFC8446 PSK support.  The PSK length is validated to be between [1, 256] bytes.  The PSK identity may be up to 128 bytes long. </ins> mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. <del> Servers must implement callbacks similar to that of OpenSSL.  PSK lengths are validate to be between [1, 16] bytes. </del> <ins> Servers must implement callbacks similar to that of OpenSSL.  Both PSK identity and key lengths may be between [1, 16] bytes long. </ins> gnuTLS: Applications configure PSK values, either as raw byte <del> strings or hexadecimal strings.  The PSK size is not validated. </del> <ins> strings or hexadecimal strings.  The PSK identity and key size are not validated. </ins> wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.


Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. <del> [[OPEN ISSUE: discuss implication of collisions between external and resumption PSKs.]] </del> <ins> 6.1.2. It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK. </ins> 7.


indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used.  This is in contrast to methods <del> like RTX RFC4588 or flexfec I-D.ietf-payload-flexible-fec-scheme retransmissions, which only transmit redundant data when necessary, at the cost of an extra roundtrip. </del> <ins> like RTX RFC4588 or flexfec's retransmission mode ( I-D.ietf-payload- flexible-fec-scheme, Section 1.1.7), which only transmit redundant data when necessary, at the cost of an extra roundtrip. </ins> Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low, and SHOULD


This approach, as described in RFC2198, allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous <del> packet, or for codecs that support variable-bitrate encodings, </del> <ins> payload, or for codecs that support variable-bitrate encodings, </ins> possibly a smaller, lower-quality representation.  In certain cases, <del> the redundant data could include multiple prior packets. </del> <ins> the redundant data could include encodings of multiple prior audio frames. </ins> Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant


Some audio codecs, notably Opus RFC6716 and AMR RFC4867, support their own in-band FEC mechanism, where redundant data is included in <del> the codec payload. </del> <ins> the codec payload.  This is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient. </ins> <del> For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery </del> <ins> For Opus, audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery </ins> of a lost packet.  This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed <del> is about 20-30%, depending on the amount of protection needed.  Note that this mechanism can only carry redundancy information for the immediately preceding packet; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </del> <ins> is only about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </ins> For AMR/AMR-WB, packets can contain copies or lower-quality encodings <del> of multiple prior audio frames.  This mechanism is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, Section 3.7.1 for details on this mechanism. </del> <ins> of multiple prior audio frames.  See RFC4867, Section 3.7.1 for details on this mechanism. </ins> In-band FEC mechanisms cannot recover any of the RTP header.


Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described <del> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1, as an </del> <ins> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1.2, as an </ins> additional supported media type for the associated m= section in the SDP offer RFC3264.  As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group,


result MAY be used by the client instance in the request- capabilities of the request. <del> OPTIONAL.  A list of the AS's interaction methods.  The values of this list correspond to the possible fields in the request- interact of the request. </del> <ins> OPTIONAL.  A list of the AS's interaction start methods.  The values of this list correspond to the possible values for the request-interact-start of the request. OPTIONAL.  A list of the AS's interaction finish methods.  The values of this list correspond to the possible values for the method element of the request-interact-finish of the request. </ins> OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the


Mutual TLS certificate verification <del> OAuth Demonstration of Proof-of-Possession key proof header </del> HTTP Signing signature header OAuth PoP key proof authentication header


7.3.4. <del> This method is indicated by "dpop" in the "proof" field.  The signer creates a Demonstration of Proof-of-Possession signature header as described in I-D.ietf-oauth-dpop section 2.  In addition, this specification defines the following fields to be added to the DPoP payload: Digest of the request body as the value of the Digest header defined in RFC3230.  When a request contains a message body, such as a POST or PUT request, this field is REQUIRED. In this example, the request body is the following JSON object: ~~~ { "access_token": { "access": [ "dolphin-metadata" ] }, "interact": { "start": ["redirect"], "finish": { "method": "redirect", "uri": "https://client.foo/callback", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }, "client": { "proof": "dpop", "key": { "jwk": { "kid": "gnap-rsa", "kty": "RSA", "e": "AQAB", "alg": "RS256", "n": "hYOJ- XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_ 3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ" } } "display": { "name": "My Client Display Name", "uri": "https://client.foo/" }, } } ~~~ The JOSE header contains the following parameters, including the public key: The JWS Payload contains the following JWT claims, including a hash of the body: This results in the following full HTTP message request: The verifier MUST parse and validate the DPoP proof header as defined in I-D.ietf-oauth-dpop.  If the HTTP message request includes a message body, the verifier MUST calculate the digest of the body and compare it to the "htd" value.  The verifier MUST ensure the key presented in the DPoP proof header is the same as the expected key of the signer. 7.3.5. </del> This method is indicated by "httpsig" in the "proof" field.  The sender creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures.


The verifier MUST validate the signature against the expected key of the signer. <del> 7.3.6. </del> <ins> 7.3.5. </ins> This method is indicated by "oauthpop" in the "proof" field.  The signer creates an HTTP Authorization PoP header as described in I-


If the client instance is capable of directing the end-user to a URL defined by the AS at runtime, the client instance indicates this by <del> sending the "redirect" field with the boolean value "true".  The means by which the client instance will activate this URL is out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end-user's device, providing a scannable image encoding, and printing out a URL to an interactive console.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the AS grant URL. </del> <ins> including "redirect" in the array under the "start" key.  The means by which the client instance will activate this URL is out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end-user's device, providing a scannable image encoding, and printing out a URL to an interactive console. While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the AS grant URL. </ins> If this interaction mode is supported for this client instance and request, the AS returns a redirect interaction response response-


If the client instance can open a URL associated with an application on the end-user's device, the client instance indicates this by <del> sending the "app" field with boolean value "true".  The means by </del> <ins> including "app" in the array under the "start" key.  The means by </ins> which the client instance determines the application to open with this URL are out of scope of this specification.


If the client instance is capable of displaying or otherwise communicating a short, human-entered code to the RO, the client <del> instance indicates this by sending the "user_code" field with the boolean value "true".  This code is to be entered at a static URL that does not change at runtime.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its </del> <ins> instance indicates this by including "user_code" in the array under the "start" key.  This code is to be entered at a static URL that does not change at runtime.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its </ins> contents, composition, or relationship to the AS grant URL. If this interaction mode is supported for this client instance and


ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.


as far as the overall protocol is concerned. A single role need not be deployed as a monolithic service.  For <del> example, A client instance could have components that are installed </del> <ins> example, a client instance could have components that are installed </ins> on the end user's device as well as a back-end system that it communicates with.  If both of these components participate in the delegation protocol, they are both considered part of the client


In some circumstances, the information needed at a given stage is communicated out of band or is preconfigured between the components <del> or entities performing the roles.  For example, one entity can fulfil multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </del> <ins> or entities performing the roles.  For example, one entity can fulfill multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </ins> 1.5.1.


The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction- <del> redirect given by the AS in (2). </del> <ins> usercode given by the AS in (2). </ins> <del> The user's directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </del> <ins> The users directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </ins> documentation, the AS documentation, or the client software itself.  Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a


The client instance request.  The client instance does not send any interaction modes to the server. <del> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to the client instance.  Note that response-subject is not generally </del> <ins> The AS determines that the request has been authorized, the AS grants access to the resource in the form of response-token to the client instance.  Note that response-subject is not generally </ins> applicable in this use case, as there is no user involved. The client instance use-access-token to call the RS.


the RS again. The RS validates the access token and determines that the access <del> token is expired The RS responds to the client instance with an </del> <ins> token is expired.  The RS responds to the client instance with an </ins> error. The client instance calls the token management URI returned in (2)


2. <del> To start a request, the client instance sends RFC8259 document with </del> <ins> To start a request, the client instance sends a RFC8259 document with </ins> an object as its root.  Each member of the request object represents a different aspect of the client instance's request.  Each field is described in detail in a section below. Additional members of this request object can be defined by <del> extensions to this protocol as described in </del> <ins> extensions to this protocol as described in request-extending. </ins> A non-normative example of a grant request is below:


to determine appropriate key information, the client instance can send this instance identifier as a direct reference value in lieu of the "client" object.  The instance identifier MAY be assigned to a <del> client instance at runtime through the response-dynamic-handles or MAY be obtained in another fashion, such as a static registration process at the AS. </del> <ins> client instance at runtime through a grant response (response- dynamic-handles) or MAY be obtained in another fashion, such as a static registration process at the AS. </ins> When the AS receives a request with an instance identifier, the AS MUST ensure that the key used to binding-keys is associated with the


In response to a client instance's request, the AS responds with a JSON object as the HTTP entity body.  Each possible field is detailed <del> in the sections below </del> <ins> in the sections below. </ins> In this example, the AS is returning an response-interact-redirect, a response-interact-finish, and a response-continue.


it can request-interact-usercode. The AS determines that interaction is needed and response with a <del> response-interact-usercode.  This could optionally include a URI to direct the user to, but this URI should be static and so could be configured in the client instance's documentation.  The AS also includes information the client instance will need to response- continue in (8) and (10).  The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </del> <ins> response-interact-usercode.  The AS also includes information the client instance will need to response-continue in (8) and (10). The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </ins> The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-


any interaction modes to the server, indicating that it does not expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using <del> the request-user. </del> <ins> the request-user.  It's also possible for the AS to determine which RO needs to be contacted by the nature of what access is being requested. </ins> The AS determines that interaction is needed, but the client instance cannot interact with the RO.  The AS response with the


response-token-single, the proof of that key MUST be used when presenting the access token. <del> A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of public keys in security-symmetric. A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key. </del> <ins> A key presented by value MUST be a public key and MUST be presented in one and only one supported format, as discussed in security- multiple-key-formats.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of the presentation of public keys in security-symmetric. </ins> Additional key formats are defined in the IANA-key-formats. <del> This non-normative example shows a single key presented in multiple formats.  This example key is intended to be used with the httpsig- binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. </del> <ins> This non-normative example shows a single key presented in two different formats.  This example key is intended to be used with the httpsig-binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. As a JSON Web Key: As a certificate in PEM format: </ins> 7.1.1.


SSRF is somewhat more difficult to manage at runtime, and systems should generally refuse to fetch a URI if unsure. <ins> 12.33. Keys presented by value are allowed to be in only a single format, as discussed in key-format.  Presenting the same key in multiple formats is not allowed and is considered an error in the request.  If multiple keys formats were allowed, receivers of these key definitions need to be able to make sure that it's the same key represented in each field and not simply use one of the key formats without checking for equivalence.  If equivalence were not carefully checked, it is possible for an attacker to insert their own key into one of the formats without needing to have control over the other formats.  This could potentially lead to a situation where one key is used by part of the system (such as identifying the client instance) and a different key in a different format in the same message is used for other things, like calculating signature validity. To combat this, all keys presented by value have to be in exactly one supported format known by the receiver.  Normally, a client instance is going to be configured with its keys in a single format, and it will simply present that format as-is to the AS in its request.  A client instance capable of multiple formats can use discovery to determine which formats are supported, if desired.  An AS should be generous in supporting many different key formats to allow different types of client software and client instance deployments. </ins> 13. The privacy considerations in this section are modeled after the list


An example set of protocol messages for this method can be found in example-async. <ins> Additional considerations for asynchronous interactions like this are discussed in security-async. </ins> 1.6.5. In this example flow, the AS policy allows the client instance to


returned and it might not match what the client instance requested, see the section on subject information for details. <ins> 1.6.8. In this scenario, the end user and resource owner are two different people.  In this scenario, the client instance already knows who the end user is, likely through a separate authentication process.  The end user, operating the client instance, needs to get subject information about another person in the system, the RO.  The RO is given an opportunity to release this information using an asynchronous interaction method with the AS.  This scenario would apply, for instance, when the end user is an agent in a call-center and the resource owner is a customer authorizing the call center agent to access their account on their behalf. Precondition: The end user is authenticated to the client instance, and the client instance has an identifier representing the end user that it can present to the AS.  This identifier should be unique to the particular session with the client instance and the AS. The RO communicates a human-readable identifier to the end user, such as an email address or account number.  This communication happens out of band from the protocol, such as over the phone between parties.  Note that the RO is not interacting with the client instance. The end user communicates the identifier to the client instance. The means by which the identifier is communicated to the client instance is out of scope for this specification. The client instance request.  The request includes the RO's identifier in the request-subject "sub_ids" field, and the end user's identifier in the request-user of the request.  The request includes no interaction start methods, since the end user is not expected to be the one interacting with the AS.  The request does include the request-interact-callback-push to allow the AS to signal to the client instance when the interaction with the RO has concluded. The AS sees that the identifier for the end user and subject being requested are different.  The AS determines that it can reach out to the RO asynchronously for approval.  While it is doing so, the AS returns a response-continue with a "finish" nonce to allow the client instance to keep polling after interaction with the RO has concluded. The AS contacts the RO and has them authenticate to the system. The means for doing this are outside the scope of this specification, but the identity of the RO is known from the subject identifier sent in (3). The RO is prompted to authorize the end user's request via the client instance.  Since the end user was identified in (3) via the user field, the AS can show this information to the RO during the authorization request. The RO completes the authorization with the AS.  The AS marks the request as . The RO pushes the interaction-pushback to the client instance. Note that in the case the RO cannot be reached or the RO denies the request, the AS still sends the interaction finish message to the client instance, after which the client instance can negotiate next steps if possible. The client instance validates the interaction finish message and continue-after-interaction. The AS returns the RO's response-subject to the client instance. The client instance can display or otherwise utilize the RO's user information in its session with the end user.  Note that since the client instance requested different sets of user information in (3), the client instance does not conflate the end user with the RO. Additional considerations for asynchronous interactions like this are discussed in security-async. </ins> 2. To start a request, the client instance sends a RFC8259 document with


12.34. <ins> GNAP allows the RO to be contacted by the AS asynchronously, outside the regular flow of the protocol.  This allows for some advanced use cases, such as cross-user authentication or information release, but such advanced use cases have some distinct issues that implementors need to be fully aware of before using these features. First, in many applications, the return of a subject information to the client instance could indicate to the client instance that the end-user is the party represented by that information, functionally allowing the end-user to authenticate to the client application. While the details of a fully functional authentication protocol are outside the scope of GNAP, it is a common exercise for a client instance to be requesting information about the end user.  This is facilitated by the several interaction-start defined in GNAP that allow the end user to begin interaction directly with the AS. However, when the subject of the information is intentionally not the end-user, the client application will need some way to differentiate between requests for authentication of the end user and requests for information about a different user.  Confusing these states could lead to an attacker having their account associated with a privileged user.  Client instances can mitigate this by having distinct code paths for primary end user authentication and requesting subject information about secondary users, such as in a call center.  In such use cases, the client software used by the resource owner (the caller) and the end-user (the agent) are generally distinct, allowing the AS to differentiate between the agent's corporate device making the request and the caller's personal device approving the request. Second, RO's interacting asynchronously do not usually have the same context as an end user in an application attempting to perform the task needing authorization.  As such, the asynchronous requests for authorization coming to the RO from the AS might have very little to do with what the RO is doing at the time.  This situation can consequently lead to authorization fatigue on the part of the RO, where any incoming authorization request is quickly approved and dispatched without the RO making a proper verification of the request.  An attacker can exploit this fatigue and get the RO to authorize the attacker's system for access.  To mitigate this, AS systems deploying asynchronous authorization should only prompt the RO when the RO is expecting such a request, and significant user experience engineering efforts need to be employed to ensure the RO can clearly make the appropriate security decision.  Furthermore, audit capability, and the ability to undo access decisions that may be ongoing, is particularly important in the asynchronous case. </ins> An attacker may aim to gain access to confidential or sensitive resources.  The measures for hardening and monitoring resource server systems (beyond protection with access tokens) is out of the scope of


4.2. If an interaction response-interact-finish method is associated with <del> the current request, the AS MUST follow the appropriate method at upon completion of interaction in order to signal the client instance to continue, except for some limited error cases discussed below.  If a finish method is not available, the AS SHOULD instruct the RO to </del> <ins> the current request, the AS MUST follow the appropriate method upon completion of interaction in order to signal the client instance to continue, except for some limited error cases discussed below.  If a finish method is not available, the AS SHOULD instruct the RO to </ins> return to the client instance upon completion. The AS MUST create an interaction reference and associate that


appropriate cryptographic processes to ensure the integrity of the assertion. <del> For example, when SAML 2 assertions are used, the receiver hast to </del> <ins> For example, when SAML 2 assertions are used, the receiver has to </ins> parse an XML document.  There are many well-known security vulnerabilities in XML parsers, and the XML standard itself can be attacked through the use of processing instructions and entity


usercode and the AS supports this mode for the client instance's request, the AS responds with a "user_code" field.  This field is string containing a unique short code that the user can type into a <del> web page.  This string MUST be case-insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The time in which this code will be accepted SHOULD be short lived, such as several minutes.  It is RECOMMENDED that this code be no more than </del> <ins> web page.  To facilitate usability, this string MUST be case- insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The string MUST be randomly generated so as to be unguessable by an attacker within the time it is accepted.  The time in which this code will be accepted SHOULD be short lived, such as several minutes.  It is RECOMMENDED that this code be no more than </ins> eight characters in length. The client instance MUST communicate the "user_code" value to the end


When the end user is directed to enter a short code through the response-interact-usercode mode, the client instance communicates the user code to the end user and directs the end user to enter that code <del> at an associated URI.  This mode is designed to be used when the client instance is not able to communicate or facilitate launching an arbitrary URI.  The associated URI could be statically configured with the client instance or in the client software's documentation. As a consequence, these URIs SHOULD be short.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </del> <ins> at an associated URI.  The client instance MAY format the user code in such a way as to facilitate memorability and transfer of the code, so long as this formatting does not alter the value as accepted at the user code URI.  For example, a client instance receiving the user code "A1BC3DFF" could choose to display this to the user as "A1BC 3DFF", breaking up the long string into two shorter strings.  In this example, the space in between the two parts would be removed upon its entry into the user code URI. This mode is designed to be used when the client instance is not able to communicate or facilitate launching an arbitrary URI.  The associated URI could be statically configured with the client instance or in the client software's documentation.  As a consequence, these URIs SHOULD be short.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </ins> In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and


When the end user is directed to enter a short code through the response-interact-usercodeuri mode, the client instance communicates the user code and associated URI to the end user and directs the end <del> user to enter that code at the URI.  This mode is used when the client instance is not able to facilitate launching a complex arbitrary URI but can communicate arbitrary values like URIs.  As a consequence, these URIs SHOULD be short to allow the URI to be typed by the end user.  The client instance MUST NOT modify the URI when communicating it to the end user; in particular the client instance MUST NOT add any parameters to the URI.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </del> <ins> user to enter that code at the URI.  The client instance MAY format the user code in such a way as to facilitate memorability and transfer of the code, so long as this formatting does not alter the value as accepted at the user code URI.  For example, a client instance receiving the user code "A1BC3DFF" could choose to display this to the user as "A1BC 3DFF", breaking up the long string into two shorter strings.  In this example, the space in between the two parts would be removed upon its entry into the user code URI. This mode is used when the client instance is not able to facilitate launching a complex arbitrary URI but can communicate arbitrary values like URIs.  As a consequence, these URIs SHOULD be short to allow the URI to be typed by the end user.  The client instance MUST NOT modify the URI when communicating it to the end user; in particular the client instance MUST NOT add any parameters to the URI.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </ins> In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and


13.27. Several parts of the GNAP process make use of unguessable randomized <del> values, such as nonces, tokens, and randomized URIs.  Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number </del> <ins> values, such as nonces, tokens, user codes, and randomized URIs. Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number </ins> generation space.  While this attack is particularly applicable to the AS, client software could likewise be targeted by an attacker triggering new grant requests against an AS.


This specification defines the following interaction start modes: <ins> All interaction start method definitions MUST provide enough information to uniquely identify the grant request during the interaction.  In the "redirect" and "app" modes, this is done using a unique URI (including its parameters).  In the "user_code" and "user_code_uri" mode, this is done using the value of the user code. </ins> Additional start modes are defined in the IANA-interaction-start- modes.


methods: If interaction finishing is supported for this client instance and <del> request, the AS response-interact-finish used by the client instance to validate the callback.  Requests to the callback URI MUST be processed as described in interaction-finish, and the AS MUST require presentation of an interaction callback reference as described in continue-after-interaction. </del> <ins> request, the AS will response-interact-finish used by the client instance to validate the callback.  All interaction finish methods MUST use this nonce to allow the client to verify the connection between the pending interaction request and the callback.  GNAP does this through the use of the interaction hash, defined in interaction- hash.  All requests to the callback URI MUST be processed as described in interaction-finish. All interaction finish methods MUST require presentation of an interaction reference for continuing this grant request.  This means that the the interaction reference MUST be returned by the AS and MUST be presented by the client as described in continue-after- interaction.  The means by which the interaction reference is returned to the client instance is specific to the interaction finish method. </ins> 2.5.2.1.


hash.  The client instance will use this value to validate the "finish" call. <del> The AS MUST send the hash and interaction reference based on the interaction finish mode as described in the following sections. </del> <ins> All interaction finish methods MUST define a way to convey the hash and interaction reference back to the client instance.  When an interaction finish method is used, the client instance MUST present the interaction reference back to the AS as part of its continue- after-interaction. </ins> Note that in many error cases, such as when the RO has denied access, the "finish" method is still enacted by the AS.  This pattern allows


3.1. A GNAP AS offering RS-facing services can publish its features on a <del> well-known discovery document using the URL ".well-known/gnap-as-rs". </del> <ins> well-known discovery document using the URL ".well-known/gnap-as-rs" appended to the grant request endpoint URL. </ins> <del> This endpoint contains a JSON document RFC8259 consisting of a single JSON object with any combination of the following optional fields: </del> <ins> The discovery response is a JSON document RFC8259 consisting of a single JSON object with the following fields: </ins> <del> The URL of the endpoint offering introspection. </del> <ins> OPTIONAL.  The URL of the endpoint offering introspection.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. </ins> A list of token formats supported by this AS. <del> The URL of the endpoint offering resource registration. The grant endpoint of the GNAP AS. </del> <ins> The URL of the endpoint offering resource registration.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. REQUIRED.  The location of the AS's grant request endpoint, used by the RS to derive downstream access tokens.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components.  This URL MUST be the same URL used by client instances in support of GNAP requests. OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the "proof" field of the key section of the request. </ins> 3.2.


If the RS needs to, it can post a set of resources as described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol to <del> the AS's resource registration endpoint. </del> <ins> the AS's resource registration endpoint along with information about what the RS will need to validate the request. REQUIRED.  The list of access rights associated with the request in the format described in the "Resource Access Rights" section of I-D.ietf-gnap-core-protocol. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The token format required to access the identified resource.  If the field is omitted, the token format is at the discretion of the AS.  If the AS does not support the requested token format, the AS MUST return an error to the RS. OPTIONAL.  If present and set to "true", the RS expects to make a token introspection request as described in introspection.  If absent or set to "false", the RS does not anticipate needing to make an introspection request for tokens relating to this resource set. </ins> The RS MUST identify itself with its own key and sign the request. <del> The AS responds with a handle appropriate to represent the resources list that the RS presented. </del> <ins> The AS responds with a reference appropriate to represent the resources list that the RS presented in its request as well as any additional information the RS might need in future requests. REQUIRED.  A single string representing the list of resources registered in the request.  The RS MAY make this handle available to a client instance as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to client software developers. </ins> <del> The RS MAY make this handle available as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to developers. </del> <ins> OPTIONAL.  An instance identifier that the RS can use to refer to itself in future calls to the AS, in lieu of sending its key by value. </ins> <del> [[ See issue #117 [2] ]] </del> <ins> OPTIONAL.  The introspection endpoint of this AS, used to allow the RS to perform token introspection. </ins> 4.


itself with its own key in the "client" field and sign the request just as any client instance would. <del> [[ See issue #116 [3] ]] </del> <ins> [[ See issue #116 [2] ]] </ins> The AS responds with a token for the downstream RS2 as described in I-D.ietf-gnap-core-protocol.  The downstream RS2 could repeat this


[1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 <del> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/117 [3] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </del> <ins> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </ins>


The RS signs the request with its own key and sends the access token as the body of the request. <ins> REQUIRED.  The access token value presented to the RS by the client instance. RECOMMENDED.  The proofing method used by the client instance to bind the token to the RS request. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The minimum access rights required to fulfill the request.  This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol. The AS MUST validate the access token value and determine if the token is active.  An active access token is defined as a token that was issued by the processing AS, has not been revoked, has not expired, and is appropriate for presentation at the identified RS. </ins> The AS responds with a data structure describing the token's current state and any information the RS would need to validate the token's presentation, such as its intended proofing mechanism and key <del> material.  The response MAY include any fields defined in an access token response. </del> <ins> material. REQUIRED.  If "true", the access token presented is active, as defined above.  If any of the criteria for an active token are not true, or if the AS is unable to make a determination (such as the token is not found), the value is set to "false" and other fields are omitted. If the access token is active, additional fields from the single access token response structure defined in I-D.ietf-gnap-core- protocol are included.  In particular, these include the following: REQUIRED.  The access rights associated with this access token. This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol.  This array MAY be filtered or otherwise limited for consumption by the identified RS, including being an empty array. REQUIRED if the token is bound.  The key bound to the access token, to allow the RS to validate the signature of the request from the client instance.  If the access token is a bearer token, this MUST NOT be included. OPTIONAL.  The set of flags associated with the access token. The response MAY include any additional fields defined in an access token response and MUST NOT include the access token "value" itself. </ins> 3.4.


control application were shown in Section 2.2 of RFC7390. An application group can be named in many ways through different <del> types of identifiers, such as numbers, URIs or other strings.  An application group name or identifier, if explicitly encoded in a CoAP request, is typically included in the path component or in the query component of a Group URI.  It may also be encoded using the Uri-Host Option RFC7252 in case application group members implement a virtual CoAP server specific to that application group.  The application group can then be identified by the value of the Uri-Host Option and each virtual server serves one specific application group.  However, encoding the application group in the Uri-Host Option is not the preferred method because in this case the application group cannot be encoded in a Group URI, and also the Uri-Host Option is being used for another purpose than encoding the host part of a URI as intended by RFC7252 - which is potentially confusing.  Appendix A of I-D.ietf- core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group. In this example an application group identifier is not explicitly encoded in the RD nor in CoAP requests made to the group, but it implicitly follows from the CoAP group used for the request.  So there is a one-to-one binding between the CoAP group and the application group.  The "NoSec" security group is used. A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group identifier (like <groupname>) should be as short as possible when used in constrained networks. </del> <ins> types of identifiers, such as name string, number, URI or other type of string.  An application group name may be explicitly encoded in a CoAP Group URI, or it may be not included in the Group URI.  This is an implementation-specific decision.  If the application group name is explicitly encoded in a CoAP Group URI, it can be encoded within one of the URI path component: this is the most common and RECOMMENDED method to encode the application group name.  A best practice for encoding application group into a Group URI is to use one URI path component to identify the application group and use the following URI paths component(s) to identify the resource within this application group.  For example, /<groupname>/res1 or /base/<groupname>/res1/res2 conform to this practice.  An application group name (like <groupname>) should be as short as possible when used in constrained networks. URI query component: using this method, the query may consist of the group name (?<groupname>) or it may be one parameter of the query (?g=<groupname> or ?param1=value1&gn=<groupname>). URI host subcomponent: using this method, the application group becomes equal to the CoAP group.  This can only be used if there is a one-to-one mapping between CoAP groups and application groups. URI port subcomponent: using this method, the application group is identified by a number that is encoded in some way in the destination port. There are also methods to encode the application group name within the CoAP request even though it is not encoded within the Group URI. Examples of such methods are: encode in a Uri-Host Option RFC7252 which is added to the CoAP request by the client before sending it out.  Each CoAP server that is part of the CoAP group, receiving this request, decodes the Uri-Host Option and treats it as an application group name. (It can also treat the application group name in this Option as a "virtual CoAP server" specific to that application group, exactly in the same way that the Uri-Host Option was intended to allow support for multiple virtual servers hosted on the same port.  The net effect of both treatments is the same.) encode in a new (custom/application-specific) CoAP Option which is added to the CoAP request by the client before sending it out. Each CoAP server that is part of the CoAP group, receiving this request, would by design understand this Option, would decode it, and treat it as an application group name. Finally, it is possible to not encode the application group name at all within the CoAP request.  This yields the most compact representation on the wire.  In this case, each CoAP server needs to determine the application group based on contextual information, such as client identity and/or target resource.  For example, each application group on a server could have a unique set of resources that does not overlap with any resources of other application groups. Appendix A of I-D.ietf-core-resource-directory shows an example registration of an application group into a Resource Directory (RD), along with the CoAP group it uses and the resources supported by the application group.  In this example an application group name "lights" is encoded in the "ep" (endpoint) attribute of the RD registration entry.  The CoAP group is ff35:30:2001:db8:f1::8000:1 and the "NoSec" security group is used. </ins> A security group is identified by a stable and invariant string used as group name, which is generally not related with other kinds of


6. <del> Encoding notifications for the HTTPS notifications is the same as the encoding notifications as defined in RFC8040 Section 6.4, with the following changes.  Instead of saying that for JSON-encoding purposes, the module name for "notification" element will be "ietf- restconf, it will say that for JSON-encoding purposes, the module name for "notification" element will be "ietf-https-notif". With those changes, the SSE event notification encoded JSON example that would be sent over the HTTPS notif transport would appear as follows: </del> <ins> Notifications are encoded as defined in RFC8040 Section 6.4.  The examples in that section apply for sending notifications over the "https-notif" based transport. An example of YANG-Push in JSON would look something like this: An example of YANG-Push in XML would look something like this: </ins> 7.


If the "Idempotency-Key" request header is missing for a documented idempotent operation requiring this header, the resource server SHOULD reply with an HTTP "400" status code with body containing a <del> link pointing to relevant documentation.  Alternately, using the HTTP header "Link", the client can be informed about the error as shown below. </del> <ins> link pointing to relevant documentation.  Following examples shows an error response describing the problem using RFC7807. Alternately, using the HTTP header "Link", the client can be informed about the error as shown below. </ins> If there is an attempt to reuse an idempotency key with a different request payload, the resource server SHOULD reply with a HTTP "422" status code with body containing a link pointing to relevant documentation.  The status code "422" is defined in Section 11.2 of <del> RFC4918.  The server can also inform the client by using the HTTP header "Link" as shown below. </del> <ins> RFC4918. The server can also inform the client by using the HTTP header "Link" as shown below. </ins> If the request is retried, while the original request is still being processed, the resource server SHOULD reply with an HTTP "409" status <del> code with body containing a link or the HTTP header "Link" pointing to the relevant documentation. </del> <ins> code with body containing problem description. Or, alternately using the HTTP header "Link" pointing to the relevant documentation </ins> Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST


6. An entity in the RATS architecture includes at least one of the roles <del> defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </del> <ins> defined in this document.  An entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles. In these cases, interaction between these roles do not necessarily use the Internet Protocol.  They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </ins> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.


role.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. <del> In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this </del> <ins> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this </ins> document. 7.