Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "Message Authentication Code (MAC)", "Hash-based Message Authentication Code (HMAC)", and "verify" are taken from [RFC4949].¶

RESTful terminology follows HTTP [RFC9110].¶

Readers are expected to be familiar with the terms and concepts defined in CoAP [RFC7252], OSCORE [RFC8613], and EDHOC [RFC9528].¶

Readers are also expected to be familiar with the terms and concepts of the ACE framework described in [RFC9200] and in [RFC9201].¶

Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749], such as the client (C), the resource server (RS), and the authorization server (AS). It is assumed in this document that a given resource on a specific RS is associated with a unique AS.¶

Note that the term "endpoint" is used here, as in [RFC9200], following its OAuth definition, which is to denote resources such as /token and /introspect at AS, and /authz-info at RS. The CoAP [RFC7252] definition, which is "An entity participating in the CoAP protocol", is not used in this document.¶

The authorization information (authz-info) resource refers to the authorization information endpoint as specified in [RFC9200]. The term "claim" is used in this document with the same semantics as in [RFC9200], i.e., it denotes information carried in the access token or returned from introspection.¶

Concise Binary Object Representation (CBOR) [RFC8949][RFC8742] and Concise Data Definition Language (CDDL) [RFC8610] are used in this document. CDDL predefined type names, especially bstr for CBOR byte strings and tstr for CBOR text strings, are used extensively in this document.¶

Examples throughout this document are expressed in CBOR diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610]. Diagnostic notation comments are often used to provide a textual representation of the numeric parameter names and values.¶

In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in Figure 9 of Appendix C. For example, {e'session_id' : h'01', e'cipher_suites': 3} stands for {0 : h'01', 2 : 3}.¶

Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in Figure 9 of Appendix C. Finally, please delete this note.¶

3.1. C-to-AS: POST to /token endpoint

The client-to-AS request is specified in Section 5.8.1 of [RFC9200].¶

The client MUST send this POST request to the /token endpoint over a secure channel that guarantees authentication, message integrity, and confidentiality (see Section 5).¶

When using this profile, the payload of the POST request MUST be encoded in CBOR [RFC8949], i.e., the request has media-type "application/ace+cbor". In order to reduce the number of libraries that C has to support, it is RECOMMENDED that C and AS use CoAP as message transfer protocol, OSCORE as security protocol, and EDHOC to establish an OSCORE Security Context.¶

AUTH_CRED_C is specified in the "req_cnf" parameter [RFC9201] of the POST request, either transported by value or uniquely referred to.¶

For AUTH_CRED_C, its authentication credential type MUST be one of those supported by EDHOC, e.g., CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. Consequently, the "req_cnf" parameter MUST specify a confirmation method suitable for the type of AUTH_CRED_C, e.g., "x5chain" or "x5t" when AUTH_CRED_C is an X.509 certificate transported by value or referred to, respectively.¶

Note that EDHOC does not admit the use of naked COSE_Keys as authentication credentials. The closest admitted authentication credential type is a CCS containing a COSE_Key in a "cnf" claim and possibly other claims, which can be transported by value using the confirmation method "kccs". Therefore, the "req_cnf" parameter MUST NOT specify the confirmation method "COSE_Key" (CBOR abbreviation: 1).¶

When receiving an Access Token request including the "req_cnf" parameter, AS checks whether it is already storing the authentication credential of C, namely AUTH_CRED_C, specified in "req_cnf" by value or reference.¶

If this is not the case, AS retrieves AUTH_CRED_C, either using the "req_cnf" parameter or some other trusted source. After that, AS validates the actual AUTH_CRED_C. In case of successful validation, AS stores AUTH_CRED_C as a valid authentication credential. Otherwise, the Client-to-AS request MUST be declined with the error code "unsupported_pop_key" as defined in Section 5.8.3 of [RFC9200].¶

An example of client-to-AS request is shown in Figure 3. In this example, C specifies its own authentication credential by reference, as the hash of an X.509 certificate carried in the "x5t" field of the "req_cnf" parameter.¶

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: application/ace+cbor
   Payload:
   {
     / audience / 5 : "tempSensor4711",
     / scope /    9 : "read",
     / req_cnf /  4 : {
       e'x5t' : [-15, h'79F2A41B510C1F9B']
     }
   }

If C wants to update its access rights without changing an existing OSCORE Security Context, it MUST specify an EDHOC_Information object in the "edhoc_info" parameter of its POST request to the /token endpoint. The EDHOC_Information object MUST include the "session_id" field. This POST request MUST NOT include the "req_cnf" parameter. An example of such a request is shown in Figure 4.¶

The identifier "session_id" is assigned by AS as discussed in Section 3.2, and identifies an ongoing token series associated with the pair (AUTH_CRED_C, AUTH_CRED_RS). That is, previous access tokens in that series were issued by AS to C, as bound to AUTH_CRED_C and intended for RS as identified by AUTH_CRED_RS.¶

Note that the same "session_id" value might identify multiple ongoing token series, e.g., if those are associated with the same client but different resource servers. In this case, AS can use the "session_id" value together with other information such as the targeted audience (see Section 5.8.1 of [RFC9200]) and the authenticated identity of C, in order to determine the exact token series to which the new requested access token has to be added.¶

If the identifier specified in the "session_id" parameter of the POST request identifies multiple, ongoing token series of which C has an access token, then C MUST specify the "audience" parameter in the POST request. In particular, the value of the "audience" parameter MUST be the same value of the "audience" parameter in the POST request that C previously sent to AS, for requesting the first access token in the token series to which the new requested access token has to be added.¶

AS MUST verify that the received "session_id" identifies a token series to which a still valid access token issued for C and RS belongs. If that is not the case, the Client-to-AS request MUST be declined with the error code "invalid_request" as defined in Section 5.8.3 of [RFC9200].¶

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: application/ace+cbor
   Payload:
   {
     / audience /      5 : "tempSensor4711",
     / scope /         9 : "write",
     e'edhoc_info_param' : {
        e'session_id' : h'01'
     }
   }

3.2. Token Series

This document refers to "token series" as a series of access tokens that are sorted in chronological order of release and are characterized by the following properties:¶

• Issued by the same AS.¶

• Issued to the same C, and associated with the same authentication credential of C.¶

• Issued for the same RS as identified by the same authentication credential.¶

Upon a successful update of access rights (see Section 3.3.3), the new issued access token becomes the latest in its token series. When the latest access token of a token series becomes invalid (e.g., due to its expiration or revocation), the token series it belongs to ends.¶

In this profile, a token series comprises access tokens that are used between a given pair (C, RS), are bound to the same authentication credential AUTH_CRED_C of C, and specify the same value in the "session_id" field of the EDHOC_Information object (see Section 3.4) in their "edhoc_info" claim.¶

AS assigns the value of "session_id" when issuing the first access token of a new series. That "session_id" value remains fixed throughout the series lifetime.¶

When assigning the "session_id" value, AS MUST ensure that it was not used in a previous series whose access tokens share both the following properties with the access tokens of the new series, irrespective of the used ACE profile:¶

• issued to the same client C; and¶

• issued for the same RS.¶

In case the access token is issued for a group-audience (see Section 6.9 of [RFC9200]), what is defined above applies, with the difference that the token series is associated with all the RSs in the group-audience, as indicated by their respective AUTH_CRED_RS.¶

3.3. AS-to-C: Response

After verifying the POST request to the /token endpoint and that C is authorized to access protected resources at RS, AS responds as defined in Section 5.8.2 of [RFC9200], with potential modifications as detailed below.¶

When using this profile, consistent with what is specified in Section 3.1, the payload of the response from AS MUST be encoded in CBOR [RFC8949], i.e., the response has media-type "application/ace+cbor".¶

If the request from C was invalid or not authorized, AS returns an error response as described in Section 5.8.3 of [RFC9200].¶

AS can signal that the use of EDHOC and OSCORE as per this profile is REQUIRED for a specific access token, by including the "ace_profile" parameter with the value "coap_edhoc_oscore" in the access token response. This means that C MUST use EDHOC with RS and derive an OSCORE Security Context, as specified in Section 4.2. After that, C MUST use the established OSCORE Security Context to protect communications with RS, when accessing protected resources at RS according to the authorization information indicated in the access token. Usually, it is assumed that constrained devices will be pre-configured with the necessary profile, so that this kind of profile signaling can be omitted.¶

According to this document, the AS provides the access token to C, by specifying it in the "access_token" parameter of the access token response. An alternative workflow where the access token is uploaded by AS directly to RS is described in [I-D.ietf-ace-workflow-and-params].¶

When issuing the first access token of a token series, AS MUST include the following data in the response to C.¶

• The "edhoc_info" parameter conveying an EDHOC_Information object (see Section 3.4). The EDHOC_Information object MUST include the "session_id" field specifying the identifier of the token series which the issued access token belongs to.¶

  The EDHOC_Information object MAY include additional fields (see Section 3.4) to convey information about RS. This information is based on knowledge that AS has about RS, e.g., from a previous onboarding process, with particular reference to what RS supports as EDHOC peer.¶

  In case the access token is issued for a group-audience (see Section 6.9 of [RFC9200]), the information specified in the EDHOC_Information object refers to the group-audience as a whole. Therefore, it is appropriate for AS to define group-audiences comprising RSs that are all aligned in terms of supported EDHOC features and configurations.¶

• A unique identification of the authentication credential of RS, AUTH_CRED_RS. This is specified in the "rs_cnf" parameter defined in [RFC9201]. AUTH_CRED_RS can be transported by value or referred to by means of an appropriate identifier.¶

  When issuing the first access token ever to a pair (C, RS) using a pair of corresponding authentication credentials (AUTH_CRED_C, AUTH_CRED_RS), it is expected that the response to C includes AUTH_CRED_RS by value.¶

  When later issuing further access tokens to the same pair (C, RS) using the same AUTH_CRED_RS, it is expected that the response to C includes AUTH_CRED_RS by reference.¶

  For AUTH_CRED_RS, its authentication credential type MUST be one of those supported by EDHOC. Consequently, the "rs_cnf" parameter MUST specify a confirmation method suitable for the type of AUTH_CRED_RS. That is, the same considerations about AUTH_CRED_C and the "req_cnf" parameter made in Section 3.1 hold for AUTH_CRED_RS and the "rs_cnf" parameter.¶

When issuing an access token for dynamically updating access rights (i.e., the access token is not the first in its token series), the response from AS MUST NOT include the "edhoc_info" and "rs_cnf" parameters (see Section 3.3.3).¶

Figure 5 shows an example of an AS response. The "rs_cnf" parameter specifies the authentication credential of RS, as an X.509 certificate transported by value in the "x5chain" field. The access token and the authentication credential of RS have been truncated for readability.¶

   Header: Created (Code=2.01)
      Content-Format: application/ace+cbor
      Payload:
      {
        / access_token / 1 : h'8343a1010aa2044c53...0f6a'
          / remainder of access token (CWT) omitted for brevity /,
        / ace_profile / 38 : e'coap_edhoc_oscore',
        / expires_in /   2 : 3600,
        / rs_cnf /      41 : {
          e'x5chain' : h'3081ee3081a1a00302...77bc'
            / remainder of the credential omitted for brevity /
        }
        e'edhoc_info_param' : {
          e'session_id'    : h'01',
          e'methods'       : [0, 1, 2, 3],
          e'cipher_suites' : 0
        }
      }

   {
    / aud /   3 : "tempSensorInLivingRoom",
    / iat /   6 : 1563451500,
    / exp /   4 : 1563453000,
    / scope / 9 :  "temperature_g firmware_p",
    / cnf /   8 : {
      e'x5chain' : h'3081ee3081a1a00302...77bc'
        / remainder of the credential omitted for brevity /
    }
    e'edhoc_info_claim' : {
      e'session_id'    : h'01',
      e'methods'       : [0, 1, 2, 3],
      e'cipher_suites' : 0
    }
  }

3.4. EDHOC_Information

EDHOC_Information is an object including information that guides two peers towards executing the EDHOC protocol. In particular, the EDHOC_Information is defined to be serialized and transported between nodes, as specified by this document, but it can also be used by other specifications.¶

In the "coap_edhoc_oscore" profile of the ACE-OAuth framework, which is specified in this document, the EDHOC_Information object MUST be encoded as CBOR. However, for easy applicability to other contexts, we define also the JSON encoding.¶

The EDHOC_Information can be encoded either as a JSON object or as a CBOR map. The set of common fields that can appear in an EDHOC_Information can be found in the IANA "EDHOC Information" registry defined in Section 14.9 for extensibility. The initial set of parameters defined in this document is specified below. All parameters are optional.¶

Table 1 provides a summary of the EDHOC_Information parameters defined in this section.¶

• session_id: This parameter identifies a 'session' which the EDHOC information is associated with, but does not necessarily identify a specific EDHOC session. In this document, "session_id" identifies a token series. In JSON, the "session_id" value is a Base64 encoded byte string. In CBOR, the "session_id" type is a byte string, and has label 0.¶

• methods: This parameter specifies a set of supported EDHOC methods (see Section 3.2 of [RFC9528]). If the set is composed of a single EDHOC method, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one EDHOC method. In JSON, the "methods" value is an integer or an array of integers. In CBOR, the "methods" is an integer or an array of integers, and has label 1.¶

• cipher_suites: This parameter specifies a set of supported EDHOC cipher suites (see Section 3.6 of [RFC9528]). If the set is composed of a single EDHOC cipher suite, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one EDHOC cipher suite. In JSON, the "cipher_suites" value is an integer or an array of integers. In CBOR, the "cipher_suites" is an integer or an array of integers, and has label 2.¶

• message_4: This parameter indicates whether the EDHOC message_4 (see Section 5.5 of [RFC9528]) is supported. In JSON, the "message_4" value is a boolean. In CBOR, "message_4" is the simple value "true" or "false", and has label 4.¶

• comb_req: This parameter indicates whether the combined EDHOC + OSCORE request defined in [RFC9668]) is supported. In JSON, the "comb_req" value is a boolean. In CBOR, "comb_req" is the simple value "true" or "false", and has label 5.¶

• uri_path: This parameter specifies the path component of the URI of the EDHOC resource where EDHOC messages have to be sent as requests. In JSON, the "uri_path" value is a string. In CBOR, "uri_path" is a text string, and has label 6.¶

• osc_ms_len: This parameter specifies the size in bytes of the OSCORE Master Secret to derive after the EDHOC session, as per Appendix A.1 of [RFC9528]. In JSON, the "osc_ms_len" value is an integer. In CBOR, the "osc_ms_len" type is unsigned integer, and has label 7.¶

• osc_salt_len: This parameter specifies the size in bytes of the OSCORE Master Salt to derive after the EDHOC session, as per Appendix A.1 of [RFC9528]. In JSON, the "osc_salt_len" value is an integer. In CBOR, the "osc_salt_len" type is unsigned integer, and has label 8.¶

• osc_version: This parameter specifies the OSCORE Version number that the two EDHOC peers have to use when using OSCORE. For more information about this parameter, see Section 5.4 of [RFC8613]. In JSON, the "osc_version" value is an integer. In CBOR, the "osc_version" type is unsigned integer, and has label 9.¶

• cred_types: This parameter specifies a set of supported types of authentication credentials for EDHOC (see Section 3.5.2 of [RFC9528]). If the set is composed of a single type of authentication credential, this is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one type of authentication credential. In JSON, the "cred_types" value is an integer or an array of integers. In CBOR, "cred_types" is an integer or an array of integers, and has label 9. The integer values are taken from the "EDHOC Authentication Credential Types" registry defined in [RFC9668].¶

• id_cred_types: This parameter specifies a set of supported types of authentication credential identifiers for EDHOC (see Section 3.5.3 of [RFC9528]). If the set is composed of a single type of authentication credential identifier, this is encoded as an integer or a text string. Otherwise, the set is encoded as an array, where each array element encodes one type of authentication credential identifier, as an integer or a text string. In JSON, the "id_cred_types" value is an integer, or a text string, or an array of integers and text strings. In CBOR, "id_cred_types" is an integer or a text string, or an array of integers and text strings, and has label 10. The integer or text string values are taken from the 'Label' column of the "COSE Header Parameters" registry [COSE.Header.Parameters].¶

• eads: This parameter specifies a set of supported EDHOC External Authorization Data (EAD) items, identified by their ead_label (see Section 3.8 of [RFC9528]). If the set is composed of a single ead_label, this is encoded as an unsigned integer. Otherwise, the set is encoded as an array of unsigned integers, where each array element encodes one ead_label. In JSON, the "eads" value is an unsigned integer or an array of unsigned integers. In CBOR, "eads" is an unsigned integer or an array of unsigned integers, and has label 11. The unsigned integer values are taken from the 'Label' column of the "EDHOC External Authorization Data" registry defined in [RFC9528].¶

• initiator: This parameter specifies whether the EDHOC Initiator role is supported. In JSON, the "initiator" value is a boolean. In CBOR, "initiator" is the simple value "true" (0xf5) or "false" (0xf4), and has label 12.¶

• responder: This parameter specifies whether the EDHOC Responder role is supported. In JSON, the "responder" value is a boolean. In CBOR, "responder" is the simple value "true" (0xf5) or "false" (0xf4), and has label 13.¶

• max_msgsize: This parameter specifies the admitted maximum size of EDHOC messages in bytes. In JSON, the "max_msgsize" value is an unsigned integer. In CBOR, "max_msgsize" is an unsigned integer and has label 14.¶

• coap_cf: This parameter specifies whether it is required that CoAP messages include the CoAP Content-Format Option with value 64 (application/edhoc+cbor-seq) or 65 (application/cid-edhoc+cbor-seq) as appropriate, when the message payload includes exclusively an EDHOC message possibly prepended by an EDHOC connection identifier (see Sections 3.4.1 and A.2 of [RFC9528]). In JSON, the "coap_cf" value is a boolean. In CBOR, "coap_cf" is the simple value true (0xf5) or false (0xf4), and has label 15.¶

• ep_id_types: This parameter specifies a set of supported types of endpoint identities for EDHOC. If the set is composed of a single type of endpoint identity, this is encoded as an integer. Otherwise, the set is encoded as an array, where each array element encodes one type of endpoint identity as an integer. In JSON, the "ep_id_types" value is an integer or an array of integers. In CBOR, "ep_id_types" is an integer or an array of integers, and has label 16. The integer values are taken from the 'CBOR Label' column of the "EDHOC Endpoint Identity Types" registry defined in Section 14.10 of this document.¶

• transports: This parameter specifies a set of supported means for transporting EDHOC messages. If the set is composed of a single means for transporting EDHOC messages, this is encoded as an integer. Otherwise, the set is encoded as an array, where each array element encodes one means for transporting EDHOC messages as an integer. In JSON, the "transports" value is an integer or an array of integers. In CBOR, "transports" is an integer or an array of integers, and has label 17. The integer values are taken from the 'Transport ID' column of the "EDHOC Transports" Registry defined in Section 14.11 of this document.¶

• trust_anchors: This parameter specifies a collection of supported trust anchors for performing authentication. According to what is specified within the collection, these trust anchors are used for different purposes, e.g., for verifying authentication credentials of other EDHOC peers in EDHOC sessions.¶

  More in detail, the collection of trust anchors is composed of one or more sets. Each set includes one or more trust anchors to use for one specific purpose associated with that set.¶

  In particular, each set is composed of pairs, each of which specifies a trust anchor type and an identifier of a trust anchor of that type. If the set is composed of a single pair, this pair is specified as a single item. If the set is composed of multiple pairs, these pairs are specified as elements of an array.¶

  Trust anchor purposes are selected from the "EDHOC Trust Anchor Purposes" registry defined in Section 14.12 of this document. Trust anchor types are selected from the "EDHOC Trust Anchor Types" registry defined in Section 14.13 of this document.¶

  In JSON, the "trust_anchors" value is an object with one or more outer entries, each of which is associated with a trust anchor purpose. The following applies for each outer entry:¶

  • The outer entry's key specifies the associated trust anchor purpose taken from the 'Name' column' of the "EDHOC Trust Anchor Purposes" registry.¶

  • The outer entry's value is an object or an array of at least two objects. Each object includes one inner entry, specifying the pair for a trust anchor TA of type TYPE. The inner entry is formatted as follows:¶

    • The inner entry's key specifies the TA's type TYPE taken from the 'Name' column of the "EDHOC Trust Anchor Types" registry.¶

    • The inner entry's value is the identifier of TA, whose encoding depends on TYPE. Such an encoding is what results from applying the conversion in Section 6.1 of [RFC8949] to the CBOR encoding of the identifier of TA when "trust_anchors" is encoded in CBOR (see below).¶

  In CBOR, the "trust_anchors" value is a map and has label 18. The map includes one or more outer entries, each of which is associated with a trust anchor purpose. The following applies for each outer entry:¶

  • The outer entry's key specifies the associated trust anchor purpose encoded as a CBOR integer, with integer value taken from the 'CBOR label' column of the "EDHOC Trust Anchor Purposes" registry.¶

  • The outer entry's value is a map or an array of at least two maps. Each map includes one inner entry, specifying the pair for a trust anchor TA of type TYPE. The inner entry is formatted as follows:¶

    • The inner entry's key specifies the TA's type TYPE encoded as a CBOR integer, with integer value taken from the 'CBOR label' column of the "EDHOC Trust Anchor Types" registry.¶

    • The inner entry's value specifies the identifier of TA, whose encoding depends on TYPE and is specified by the 'Value type' column of the "EDHOC Trust Anchor Types" registry, for the registry entry that has TYPE as value of the 'Name' column.¶

An example of JSON EDHOC_Information is given in Figure 7.¶

   "edhoc_info" : {
       "session_id"    : b64'AQ==',
       "methods"       : 1,
       "cipher_suites" : 0,
       "trust_anchors" : {
         "edhoc_cred" : [
           { "c5u" : "coap://certs.c509.example" },
           { "x5u" : "coap://certs.x509.example" }
         ]
       }
   }

An example of CBOR EDHOC_Information is given in Figure 8.¶

   e'edhoc_info_param'  : {
     e'session_id'    : h'01',
     e'methods'       : 1,
     e'cipher_suites' : 0,
     e'trust_anchors' : {
       e'edhoc_cred' : [
         { e'c5t_ta_type' : [-15, h'81DC2F32CB87E163'] },
         { e'c5u_ta_type' : "coap://certs.c509.example" },
         { e'x5t_ta_type' : [-15, h'79F2A41B510C1F9B'] },
         { e'x5u_ta_type' : "coap://certs.x509.example" }
       ]
     }
   }

The CDDL grammar describing the CBOR EDHOC_Information is:¶

EDHOC_Information = {
  ?  0 => bstr,                   ; id
  ?  1 => int / array,            ; methods
  ?  2 => int / array,            ; cipher_suites
  ?  3 => true / false,           ; message_4
  ?  4 => true / false,           ; comb_req
  ?  5 => tstr,                   ; uri_path
  ?  6 => uint,                   ; osc_ms_len
  ?  7 => uint,                   ; osc_salt_len
  ?  8 => uint,                   ; osc_version
  ?  9 => int / array,            ; cred_types
  ? 10 => int / tstr / array,     ; id_cred_types
  ? 11 => uint / array,           ; eads
  ? 12 => true / false,           ; initiator
  ? 13 => true / false,           ; responder
  ? 14 => uint,                   ; max_msgsize
  ? 15 => true / false,           ; coap_ct
  ? 16 => int / array,            ; ep_id_types
  ? 17 => int / array,            ; transports
  ? 18 => map,                    ; trust_anchors
  * int / tstr => any
}

4.1. EAD items for Access Token and Session Identifier

This document defines EAD items (see Section 3.8 of [RFC9528]) for transporting an access token or a session identifier in EDHOC.¶

• EAD_ACCESS_TOKEN = (ead_label, ead_value), where:¶

  • ead_label is the integer value TBD registered in Section 14.8.¶

  • ead_value is a CBOR byte string equal to the value of the "access_token" field of the access token response from AS (see Section 3.3).¶

  This EAD item is critical, i.e., it is used only with the negative value of its ead_label, indicating that the receiving RS must progress the protocol using the received access token, or else abort the EDHOC session (see Section 3.8 of [RFC9528]). A client or resource server supporting the profile of ACE defined in this document MUST support this EAD item.¶

  EAD_ACCESS_TOKEN is used only when uploading the first access token of a token series, but not for the update of access rights (see Section 4.6).¶

  Editor's note: Add example.¶

• EAD_SESSION_ID = (ead_label, ead_value), where:¶

  • ead_label is the integer value TBD registered in Section 14.8.¶

  • ead_value is a CBOR byte string equal to the value of the "session_id" field within the EDHOC_Information object specified by AS in the "edhoc_info" parameter of the response from the /token endpoint, when issuing the first access token of a token series (see Section 3.3).¶

  This EAD item is critical, i.e., it is used only with the negative value of its ead_label, indicating that the receiving RS must progress the protocol using the access token associated with the identifier specified in "ead_value" and with the AUTH_CRED_C used in the EDHOC session, or else abort the EDHOC session (see Section 3.8 of [RFC9528]). A client or resource server supporting the profile of ACE defined in this document MUST support this EAD item.¶

  EAD_SESSION_ID is used only if the access token has been provisioned to RS and is valid, but there is a need to establish a (new) OSCORE Security Context between C and RS through EDHOC.¶

  Editor's note: Add example.¶

4.2. EDHOC Session

In order to mutually authenticate and establish secure communication for authorized access according to the profile described in this document, C and RS run the EDHOC protocol augmented with an access token. During the EDHOC session, C specifies the access token to RS by value as conveyed in EAD item EAD_ACCESS_TOKEN, or by reference through a session identifier SESSION_ID conveyed in the EAD item EAD_SESSION_ID (see Section 4.1).¶

As per Appendix A.2 of [RFC9528], EDHOC can be transferred over CoAP using either the forward or the reverse message flow, thus manifesting the two possible mappings between the ACE roles (client and resource server) and the EDHOC roles (Initiator and Responder), whereas the CoAP roles (client and server) remain the same. The choice of message flow and corresponding mapping depends on the deployment setting and in particular on which identity to protect the most, since EDHOC protects the identity of the Initiator against active attackers.¶

In case the EDHOC forward message flow is used (see Section 4.3), C acts as EDHOC Initiator, and the access token MUST be specified by value or by reference in the EAD_3 field of EDHOC message_3. In case the EDHOC reverse message flow is used (see Section 4.4), C acts as EDHOC Responder, and the access token MUST be specified by value or by reference either in the EAD_2 field of EDHOC message_2 or in the EAD_4 field of EDHOC message_4. By doing so, the access token or the associated session identifier gets at least the same confidentiality protection by EDHOC as provided to the authentication credential used by C in the EDHOC session (see Section 9.1 of [RFC9528]).¶

When RS processes the EAD item EAD_ACCESS_TOKEN or EAD_SESSION_ID, RS MUST verify that the authentication credential AUTH_CRED_C that C specifies in the ID_CRED_X field during the EDHOC session is the same authentication credential correlated with the EAD item. If such a verification fails, RS MUST abort the EDHOC session. Note that:¶

• The ID_CRED_X field in question is the ID_CRED_I or ID_CRED_R field, when using the EDHOC forward or reverse message flow, respectively.¶

• If the processed EAD item is EAD_ACCESS_TOKEN, then the authentication credential correlated with the EAD item is specified in the 'cnf' claim of the access token conveyed in the EAD item.¶

• If the processed EAD item is EAD_SESSION_ID, then the authentication credential correlated with the EAD item is specified in the 'cnf' claim of an access token stored at the RS, which is associated with the authentication credential specified by ID_CRED_X and with the SESSION_ID conveyed in the EAD item.¶

RS MUST have successfully validated the access token before completing the EDHOC session. If completed successfully, then the EDHOC session is associated with both the access token and the pair (SESSION_ID, AUTH_CRED_C). If the EAD item used in the EDHOC session is EAD_ACCESS_TOKEN, then SESSION_ID is specified by the "session_id" field, within the EDHOC_Information object specified by the "cnf" claim of the access token.¶

Any previous EDHOC session associated with the same access token and with the same pair (SESSION_ID, AUTH_CRED_C) MUST be deleted. The OSCORE Security Context derived from that EDHOC session MUST also be deleted.¶

Depending on the message flow used, the EDHOC messages will be carried either in CoAP POST requests or in CoAP 2.04 (Changed) responses, as detailed in Appendix A.2 of [RFC9528].¶

C MUST target the EDHOC resource at RS with the URI path specified in the "uri_path" field (if present) of the EDHOC_Information object within the access token response received from AS, through which C obtained the first access token of the token series (see Section 3.1). If the "uri_path" field is not present in that EDHOC_Information object, C assumes the target resource at RS to be the well-known EDHOC resource at the path /.well-known/edhoc.¶

RS has to ensure that no requests can be performed on an EDHOC resource other than for running the EDHOC protocol. Specifically, it SHOULD NOT be possible to perform any other operation than POST on an EDHOC resource.¶

4.3. Forward Message Flow

This section details the case where the EDHOC forward message flow is used (see Appendix A.2.1 of [RFC9528]), i.e., where C acts as the Initiator I and RS acts as the Responder R.¶

Consistently with the EDHOC forward message flow, C sends EDHOC message_1 and EDHOC message_3 to an EDHOC resource at RS, as CoAP POST requests. RS sends EDHOC message_2 and (optionally) EDHOC message_4 as CoAP 2.04 (Changed) responses.¶

4.4. Reverse Message Flow

This section details the case where the EDHOC reverse message flow is used (see Appendix A.2.2 of [RFC9528]), i.e., where C acts as the Responder R and RS acts as the Initiator I.¶

Consistently with the EDHOC reverse message flow, C sends a trigger message, EDHOC message_2, and (optionally) EDHOC message_4 to RS as CoAP POST requests. RS sends EDHOC message_1 and EDHOC message_3 as CoAP 2.04 (Changed) responses.¶

Exactly one of the EAD items EAD_ACCESS_TOKEN or EAD_SESSION_ID MUST be included in either the EAD_2 field of EDHOC message_2 or the EAD_4 field of EDHOC message_4. If this is not the case, RS MUST abort the EDHOC session.¶

Specific instructions for the different messages are provided in the following subsections.¶

4.5. OSCORE Security Context

Once successfully completed the EDHOC session, C and RS derive an OSCORE Security Context, as defined in Appendix A.1 of [RFC9528]. In addition, the following applies:¶

• The length in bytes of the OSCORE Master Secret (i.e., the oscore_key_length parameter, see Appendix A.1 of [RFC9528]) MUST be the value specified in the "osc_ms_size" field (if present) within the EDHOC_Information object specified by:¶

  • The "edhoc_info" parameter of the access token response that C received from AS, through which C obtained the first access token of the token series (see Section 3.1).¶

  • The "edhoc_info" claim of the access token provisioned to RS (see Section 3.3.1).¶

• The length in bytes of the OSCORE Master Salt (i.e., the oscore_salt_length parameter, see Appendix A.1 of [RFC9528]) MUST be the value specified in the "osc_salt_size" field (if present) within the EDHOC_Information object specified by:¶

  • The "edhoc_info" parameter of the access token response that C received from AS, through which C obtained the first access token of the token series (see Section 3.1).¶

  • The "edhoc_info" claim of the access token provisioned to RS (see Section 3.3.1).¶

• C and RS MUST use the OSCORE version specified in the "osc_version" field (if present) within the EDHOC_Information object specified by:¶

  • The "edhoc_info" parameter of the access token response that C received from AS, through which C obtained the first access token of the token series (see Section 3.1).¶

  • The "edhoc_info" claim of the access token provisioned to RS (see Section 3.3.1).¶

• RS associates the latest EDHOC session and the derived OSCORE Security Context with the stored access token, which is bound to the authentication credential AUTH_CRED_C used in the EDHOC session. The access token is also associated with the pair (SESSION_ID, AUTH_CRED_C), where SESSION_ID is the identifier of the token series to which the access token belongs.¶

If supported by C, C MAY use the EDHOC + OSCORE combined request defined in [RFC9668], unless the EDHOC_Information object specified by the "edhoc_info" parameter of the access token response included the "comb_req" field encoding the CBOR simple value "false" (0xf4).¶

In the combined request, both EDHOC message_3 and the first OSCORE-protected application request are combined together in a single OSCORE-protected CoAP request, thus saving one round trip. This requires C to derive the OSCORE Security Context with RS already after having successfully processed the received EDHOC message_2 and before sending EDHOC message_3. An example is provided in Appendix A.2.¶

4.6. Update of Access Rights

If C has a valid OSCORE Security Context associated with a valid access token at RS, then C can request from AS an update of the access rights as described in Section 3.1.¶

If the request is granted, then AS generates a new access token containing updated access rights for C (see Section 3.3.3), in the same token series of the current access token (see Section 3.2).¶

According to this document, AS provides the new access token to C (see Section 3.3) for further uploading to RS. Alternatively, the new access token can be uploaded by AS directly to RS, as described in [I-D.ietf-ace-workflow-and-params].¶

If all validations are successful, C can access protected resources at RS according to the updated access rights, using the previously established OSCORE Security Context.¶

The rest of this section describes the message exchange for the uploading of the new access token from C to RS.¶

4.7. Discarding the OSCORE Security Context

There are a number of cases where C or RS have to discard the OSCORE Security Context that they share, and may establish a new one (see Section 4.8).¶

C MUST discard the current OSCORE Security Context shared with RS when any of the following occurs.¶

• The OSCORE Sender Sequence Number space of C is exhausted.¶

• The access token associated with the OSCORE Security Context becomes invalid, for example, due to expiration or revocation.¶

• C receives a number of unprotected 4.01 (Unauthorized) responses to OSCORE-protected requests, which are sent to RS and protected using the same OSCORE Security Context. The exact number of such received responses needs to be specified by the application. This can happen, for example, due to lack of storage at RS, which then sends the "AS Request Creation Hints" message (see Section 5.3 of [RFC9200]).¶

• The authentication credential of C (of RS) becomes invalid, e.g., due to expiration or revocation, and it was used as AUTH_CRED_C (AUTH_CRED_RS) in the EDHOC session to establish the OSCORE Security Context.¶

RS MUST discard the current OSCORE Security Context shared with C when any of the following occurs:¶

• The OSCORE Sender Sequence Number space of RS is exhausted.¶

• The access token associated with the OSCORE Security Context becomes invalid, for example, due to expiration or revocation.¶

• The authentication credential of C (of RS) becomes invalid (e.g., due to expiration or revocation), and it was used as AUTH_CRED_C (AUTH_CRED_RS) in the EDHOC session to establish the OSCORE Security Context.¶

After a new access token is successfully uploaded to RS and a new OSCORE Security Context is established between C and RS, messages still in transit that were protected with the previous OSCORE Security Context might not be successfully verified by the recipient, since the old OSCORE Security Context might have been discarded. This means that messages sent shortly before C has uploaded the new access token to RS might not be successfully accepted by the recipient.¶

Furthermore, implementations may want to cancel CoAP observations at RS, if registered before the new OSCORE Security Context has been established. Alternatively, applications need to implement a mechanism to ensure that, from then on, messages exchanged within those observations are going to be protected with the newly derived OSCORE Security Context.¶

4.8. Establishing a New OSCORE Security Context

The procedure of provisioning a new access token to RS specified in this section applies to various cases when an OSCORE Security Context shared between C and RS has been deleted, for example as described in Section 4.7.¶

Another exceptional case is when there is still a valid OSCORE Security Context but it needs to be updated, e.g., due to a policy limiting its use in terms of time or amount of processed data, or to the imminent exhaustion of the OSCORE Sender Sequence Number space. In this case, C and RS SHALL attempt to run the KUDOS key update protocol [I-D.ietf-core-oscore-key-update], which is a lightweight alternative independent of ACE and EDHOC that does not require the uploading of an access token. If KUDOS is not supported, then C and RS falls back to EDHOC as outlined above.¶

In either case, C and RS establish a new OSCORE Security Context that replaces the old one and will be used for protecting their communications from then on. In particular, RS MUST associate the new OSCORE Security Context with the current (potentially re-uploaded) access token. Furthermore, the SESSION_ID identifying the token series to which the access token belongs to remains unchanged, even if C and RS have established a new EDHOC session. Unless C and RS re-run the EDHOC protocol, they preserve their OSCORE identifiers, i.e., their OSCORE Sender/Recipient IDs.¶

4.9. Access Rights Verification

RS MUST follow the procedures defined in Section 5.10.2 of [RFC9200]. That is, if RS receives an OSCORE-protected request targeting a protected resource from C, then RS processes the request according to [RFC8613], when Version 1 of OSCORE is used. Future specifications may define new versions of OSCORE, which AS can indicate C and RS to use by means of the "osc_version" field of the EDHOC_Information object (see Section 3).¶

If OSCORE verification succeeds and the target resource requires authorization, RS retrieves the authorization information using the access token associated with the OSCORE Security Context. Then, RS MUST verify that the authorization information covers the target resource and the action intended by C on it.¶

4.10. Access Token Invalidity

When an access token becomes invalid (e.g., due to its expiration or revocation), RS MUST delete the access token and the associated OSCORE Security Context, and MUST notify C with an error response with code 4.01 (Unauthorized) for any long running request, as specified in Section 5.8.3 of [RFC9200].¶

4.11. Authentication Credential Invalidity

If an authentication credential AUTH_CRED_C of C is invalidated (e.g., it expires), then the following applies:¶

• RS MUST delete all the stored access tokens that specify AUTH_CRED_C in the "cnf" claim.¶

• C MUST delete every stored access token such that C obtained the first access token of the same series through the response to an access token request specifying AUTH_CRED_C, e.g., in the "req_cnf" parameter (see Section 3.1).¶

• RS and C MUST abort and purge all the EDHOC sessions that used AUTH_CRED_C and successfully completed, as well as the OSCORE Security Context derived from those sessions (see Section 4.7).¶

If an authentication credential AUTH_CRED_RS of RS is invalidated (e.g., it expires), then the following applies:¶

• C MUST delete every stored access token such that C obtained the first access token of the same series through an access token response specifying AUTH_CRED_RS, e.g., in the 'rs_cnf' parameter (see Section 3.3).¶

• C MUST delete every stored access token that C specified (by value or be reference) during an EDHOC session that used AUTH_CRED_RS and successfully completed.¶

• RS and C MUST abort and purge all the EDHOC sessions that used AUTH_CRED_RS and successfully completed, as well as the OSCORE Security Context derived from those sessions (see Section 4.7).¶

4.12. EDHOC Session Invalidity

If an EDHOC session is aborted and purged for other reasons than those in Section 4.11, then RS and C that established the session MUST delete the OSCORE Security Context derived from that session (see Section 4.7).¶

4.13. Using AS Request Creation Hints

When replying to an unauthorized resource request message from a client, RS can send an unprotected AS Request Creation Hints message as a 4.01 (Unauthorized) error response (see Section 5.3 of [RFC9200]).¶

The message payload can specify a number of parameters that help the sender client acquire a valid access token from AS. These parameters include "audience" and "scope".¶

When using this profile and running EDHOC per its reverse message flow (see Section 4.4), RS acts as EDHOC Initiator. A compelling reason to do so is the wish to protect the identity of RS against active attackers, consistently with the EDHOC security properties.¶

However, the identity protection achieved through EDHOC can be defeated if RS exposes information such as audience and scope, when specifying the corresponding parameters in an unprotected AS Request Creation Hints message.¶

Therefore, if RS supports the EDHOC reverse message flow and sends an AS Request Creation Hints, the following applies:¶

• The message payload MUST NOT include the "audience" parameter.¶

• The message payload SHOULD NOT include the "scope" parameter, unless its value cannot contribute to expose the identity of RS.¶

6.1. Ordered Chain of X.509 Certificates

The confirmation method "x5chain" specifies an ordered array of X.509 certificates [RFC5280]. The semantics of "x5chain" is like that of the "x5chain" COSE Header Parameter specified in [RFC9360].¶

6.2. Unordered Bag of X.509 Certificates

The confirmation method "x5bag" specifies a bag of X.509 certificates [RFC5280]. The semantics of "x5bag" is like that of the "x5bag" COSE Header Parameter specified in [RFC9360].¶

6.3. Hash of an X.509 Certificate

The confirmation method "x5t" specifies the hash value of the end-entity X.509 certificate [RFC5280]. The semantics of "x5t" is like that of the "x5t" COSE Header Parameter specified in [RFC9360].¶

6.4. URI Pointing to an Ordered Chain of X.509 Certificates

The confirmation method "x5u" specifies the URI [RFC3986] of an ordered chain of X.509 certificates [RFC5280]. The semantics of "x5u" is like that of the "x5u" COSE Header Parameter specified in [RFC9360].¶

6.5. Ordered Chain of C509 Certificates

The confirmation method "c5c" specifies an ordered array of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5c" is like that of the "c5c" COSE Header Parameter specified in [I-D.ietf-cose-cbor-encoded-cert].¶

6.6. Unordered Bag of C509 Certificates

The confirmation method "c5b" specifies a bag of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5b" is like that of the "c5b" COSE Header Parameter specified in [I-D.ietf-cose-cbor-encoded-cert].¶

6.7. Hash of a C509 Certificate

The confirmation method "c5t" specifies the hash value of the end-entity C509 certificate [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5t" is like that of the "c5t" COSE Header Parameter specified in [I-D.ietf-cose-cbor-encoded-cert].¶

6.8. URI Pointing to an Ordered Chain of C509 Certificates

The confirmation method "c5u" specifies the URI [RFC3986] of a COSE_C509 containing an ordered chain of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. COSE_C509 is defined in [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5u" is like that of the "c5u" COSE Header Parameter specified in [I-D.ietf-cose-cbor-encoded-cert].¶

6.9. CWT Containing a COSE_Key

The confirmation method "kcwt" specifies a CBOR Web Token (CWT) [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and possibly other claims. The semantics of "kcwt" is like that of the "kcwt" COSE Header Parameter specified in [RFC9528].¶

6.10. CCS Containing a COSE_Key

The confirmation method "kccs" specifies a CWT Claims Set (CCS) [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and possibly other claims. The semantics of "kccs" is like that of the "kccs" COSE Header Parameter specified in [RFC9528].¶

7.1. Ordered Chain of X.509 Certificates

The confirmation method "x5c" specifies an ordered array of X.509 certificates [RFC5280]. The semantics of "x5c" is like that of the "x5c" JSON Web Signature and Encryption Header Parameter specified in [RFC7515], with the following difference. The public key contained in the first certificate is the proof-of-possession key and does not have to correspond to a key used to digitally sign the JWS.¶

7.2. Unordered Bag of X.509 Certificates

The confirmation method "x5b" specifies a bag of X.509 certificates [RFC5280]. The semantics of the "x5b" is like that of the "x5c" JWT confirmation method defined in Section 7.1, with the following differences. First, the set of certificates is unordered and may contain self-signed certificates. Second, the composition and processing of "x5b" are like for the "x5bag" COSE Header Parameter defined in [RFC9360].¶

7.3. Hash of an X.509 Certificate

The confirmation method "x5t" specifies the hash value of the end-entity X.509 certificate [RFC5280]. The semantics of "x5t" is like that of the "x5t" JSON Web Signature and Encryption Header Parameter specified in [RFC7515].¶

7.4. URI Pointing to an Ordered Chain of X.509 Certificates

The confirmation method "x5u" specifies the URI [RFC3986] of an ordered chain of X.509 certificates [RFC5280]. The semantics of "x5u" is like that of the "x5u" COSE Header Parameter specified in [RFC9360], with the following difference. The public key contained in the first certificate is the proof-of-possession key and does not have to correspond to a key used to digitally sign the JWS.¶

7.5. Ordered Chain of C509 Certificates

The confirmation method "c5c" specifies an ordered array of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5c" is like that of the "x5c" JWT confirmation method defined in Section 7.1, with the following difference. Each string in the JSON array is a base64-encoded (Section 4 of [RFC4648] - not base64url-encoded) C509 certificate.¶

7.6. Unordered Bag of C509 Certificates

The confirmation method "c5b" specifies a bag of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5b" is like that of the "c5c" JWT confirmation method defined in Section 7.5, with the following differences. First, the set of certificates is unordered and may contain self-signed certificates. Second, the composition and processing of "c5b" is like for the "c5b" COSE Header Parameter defined in [I-D.ietf-cose-cbor-encoded-cert].¶

7.7. Hash of a C09 Certificate

The confirmation method "c5t" specifies the hash value of the end-entity C509 certificate [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5t" is like that of the "x5t" JWT confirmation method defined in Section 7.3, with the following differences. First, the base64url-encoded SHA-1 thumbprint is computed over the C509 certificate. Second, the public key contained in the C509 certificate does not have to correspond to a key used to digitally sign the JWS.¶

7.8. URI Pointing to an Ordered Chain of C509 Certificates

The confirmation method "c5u" specifies the URI [RFC3986] of COSE_C509 containing an ordered chain of C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. COSE_C509 is defined in [I-D.ietf-cose-cbor-encoded-cert]. The semantics of "c5u" is like that of the "x5u" JWT confirmation method defined in Section 7.4, with the following differences. First, the URI refers to a resource for the C509 certificate chain. Second, the public key contained in one of the C509 certificates and acting as proof-of-possession key does not have to correspond to a key used to digitally sign the JWS.¶

7.9. CWT Containing a COSE_Key

The confirmation method "kcwt" specifies a CBOR Web Token (CWT) [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and possibly other claims. The format of "kcwt" is the base64url-encoded serialization of the CWT.¶

7.10. CCS Containing a COSE_Key

The confirmation method "kccs" specifies a CWT Claims Set (CCS) [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and possibly other claims. The format of "kcwt" is the base64url-encoded serialization of the CWT.¶

14.1. ACE Profiles Registry

IANA is asked to add the following entry to the "ACE Profiles" registry, following the procedure specified in [RFC9200].¶

• Name: coap_edhoc_oscore¶

• Description: Profile for delegating client authentication and authorization in a constrained environment by establishing an OSCORE Security Context [RFC8613] between resource-constrained nodes, through the execution of the lightweight authenticated key exchange protocol EDHOC [RFC9528].¶

• CBOR Value: TBD (value between 1 and 23)¶

• Reference: [RFC-XXXX]¶

14.2. OAuth Parameters Registry

IANA is asked to add the following entry to the "OAuth Parameters" registry.¶

• Name: edhoc_info¶

• Parameter Usage Location: token request and token response¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

14.3. OAuth Parameters CBOR Mappings Registry

IANA is asked to add the following entry to the "OAuth Parameters CBOR Mappings" registry, following the procedure specified in [RFC9200].¶

• Name: edhoc_info¶

• CBOR Key: TBD (value between 1 and 255)¶

• Value Type: map¶

• Reference: [RFC-XXXX]¶

• Original Specification: [RFC-XXXX]¶

14.4. JSON Web Token Claims Registry

IANA is asked to add the following entries to the "JSON Web Token Claims" registry, following the procedure specified in [RFC7519].¶

• Claim Name: edhoc_info¶

• Claim Description: Information for EDHOC session¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

14.5. CBOR Web Token (CWT) Claims Registry

IANA is asked to add the following entries to the "CBOR Web Token (CWT) Claims" registry, following the procedure specified in [RFC8392].¶

• Claim Name: edhoc_info¶

• Claim Description: Information for EDHOC session¶

• JWT Claim Name: edhoc_info¶

• Claim Key: TBD (value between 1 and 255)¶

• Claim Value Type: map¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

14.6. JWT Confirmation Methods Registry

IANA is asked to add the following entries to the "JWT Confirmation Methods" registry, following the procedure specified in [RFC7800].¶

• Confirmation Method Value: x5c¶

• Confirmation Method Description: An ordered chain of X.509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.1 of [RFC-XXXX]¶

• Confirmation Method Value: x5b¶

• Confirmation Method Description: An unordered bag of X.509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.2 of [RFC-XXXX]¶

• Confirmation Method Value: x5t¶

• Confirmation Method Description: Hash of an X.509 certificate¶

• Change Controller: IETF¶

• Reference: Section 7.3 of [RFC-XXXX]¶

• Confirmation Method Value: x5u¶

• Confirmation Method Description: URI pointing to an ordered chain of X.509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.4 of [RFC-XXXX]¶

• Confirmation Method Value: c5c¶

• Confirmation Method Description: An ordered chain of C509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.5 of [RFC-XXXX]¶

• Confirmation Method Value: c5b¶

• Confirmation Method Description: An unordered bag of C509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.6 of [RFC-XXXX]¶

• Confirmation Method Value: c5t¶

• Confirmation Method Description: Hash of a C509 certificate¶

• Change Controller: IETF¶

• Reference: Section 7.7 of [RFC-XXXX]¶

• Confirmation Method Value: c5u¶

• Confirmation Method Description: URI pointing to a COSE_C509 containing an ordered chain of C509 certificates¶

• Change Controller: IETF¶

• Reference: Section 7.8 of [RFC-XXXX]¶

• Confirmation Method Value: kcwt¶

• Confirmation Method Description: A CBOR Web Token (CWT) containing a COSE_Key in a 'cnf' claim and possibly other claims¶

• Change Controller: IETF¶

• Reference: Section 7.9 of [RFC-XXXX]¶

• Confirmation Method Value: kccs¶

• Confirmation Method Description: A CWT Claims Set (CCS) containing a COSE_Key in a 'cnf' claim and possibly other claims¶

• Change Controller: IETF¶

• Reference: Section 7.10 of [RFC-XXXX]¶

14.7. CWT Confirmation Methods Registry

IANA is asked to add the following entries to the "CWT Confirmation Methods" registry, following the procedure specified in [RFC8747].¶

• Confirmation Method Name: x5chain¶

• Confirmation Method Description: An ordered chain of X.509 certificates¶

• JWT Confirmation Method Name: x5c¶

• Confirmation Key: TBD (value between 24 and 255)¶

• Confirmation Value Type: COSE_X509¶

• Change Controller: IETF¶

• Reference: Section 6.1 of [RFC-XXXX]¶

• Confirmation Method Name: x5bag¶

• Confirmation Method Description: An unordered bag of X.509 certificates¶

• JWT Confirmation Method Name: x5b¶

• Confirmation Key: TBD (value between 24 and 255)¶

• Confirmation Value Type: COSE_X509¶

• Change Controller: IETF¶

• Reference: Section 6.2 of [RFC-XXXX]¶

• Confirmation Method Name: x5t¶

• Confirmation Method Description: Hash of an X.509 certificate¶

• JWT Confirmation Method Name: x5t¶

• Confirmation Key: TBD (value between 1 and 23)¶

• Confirmation Value Type: COSE_CertHash¶

• Change Controller: IETF¶

• Reference: Section 6.3 of [RFC-XXXX]¶

• Confirmation Method Name: x5u¶

• Confirmation Method Description: URI pointing to an ordered chain of X.509 certificates¶

• JWT Confirmation Method Name: x5u¶

• Confirmation Key: TBD (value between 1 and 23)¶

• Confirmation Value Type: uri¶

• Change Controller: IETF¶

• Reference: Section 6.4 of [RFC-XXXX]¶

• Confirmation Method Name: c5c¶

• Confirmation Method Description: An ordered chain of C509 certificates¶

• JWT Confirmation Method Name: c5c¶

• Confirmation Key: TBD (value between 24 and 255)¶

• Confirmation Value Type: COSE_C509¶

• Change Controller: IETF¶

• Reference: Section 6.5 of [RFC-XXXX]¶

• Confirmation Method Name: c5b¶

• Confirmation Method Description: An unordered bag of C509 certificates¶

• JWT Confirmation Method Name: c5b¶

• Confirmation Key: TBD (value between 24 and 255)¶

• Confirmation Value Type: COSE_C509¶

• Change Controller: IETF¶

• Reference: Section 6.6 of [RFC-XXXX]¶

• Confirmation Method Name: c5t¶

• Confirmation Method Description: Hash of a C509 certificate¶

• JWT Confirmation Method Name: c5t¶

• Confirmation Key: TBD (value between 1 and 23)¶

• Confirmation Value Type: COSE_CertHash¶

• Change Controller: IETF¶

• Reference: Section 6.7 of [RFC-XXXX]¶

• Confirmation Method Name: c5u¶

• Confirmation Method Description: URI pointing to a COSE_C509 containing an ordered chain of C509 certificates¶

• JWT Confirmation Method Name: c5u¶

• Confirmation Key: TBD (value between 1 and 23)¶

• Confirmation Value Type: uri¶

• Change Controller: IETF¶

• Reference: Section 6.8 of [RFC-XXXX]¶

• Confirmation Method Name: kcwt¶

• Confirmation Method Description: A CBOR Web Token (CWT) containing a COSE_Key in a 'cnf' claim and possibly other claims¶

• JWT Confirmation Method Name: kcwt¶

• Confirmation Key: TBD (value between 1 and 23)¶

• Confirmation Value Type: COSE_Messages¶

• Change Controller: IETF¶

• Reference: Section 6.9 of [RFC-XXXX]¶

• Confirmation Method Name: kccs¶

• Confirmation Method Description: A CWT Claims Set (CCS) containing a COSE_Key in a 'cnf' claim and possibly other claims¶

• JWT Confirmation Method Name: kccs¶

• Confirmation Key: TBD (value between 1 and 23)¶

• Confirmation Value Type: map / #6(map)¶

• Change Controller: IETF¶

• Reference: Section 6.10 of [RFC-XXXX]¶

14.8. EDHOC External Authorization Data Registry

IANA is asked to add the following entries to the "EDHOC External Authorization Data" registry defined in Section 10.5 of [RFC9528].¶

• Name: ACE-OAuth Access Token¶

• Label: TBD (value between 24 and 255)¶

• Description: An Access Token as used in the ACE-OAuth framework [RFC9200]¶

• Reference: [RFC-XXXX], Section 4.1¶

• Name: Session ID¶

• Label: TBD (value between 1 and 23)¶

• Description: The identifier of an EDHOC session¶

• Reference: [RFC-XXXX], Section 4.1¶

14.9. EDHOC Information Registry

IANA is requested to create a new "EDHOC Information" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

The registration policy is either "Private Use", "Standards Action with Expert Review", "Specification Required" per Section 4.6 of [RFC8126], or "Expert Review" per Section 4.5 of [RFC8126]. "Expert Review" guidelines are provided in Section 14.14.¶

All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126], with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, review and approval by the designated expert are also required, in order for the WG chairs to determine that the conditions for early allocation are met (see step 2 in Section 3.1 of [RFC7120]).¶

The columns of the registry are:¶

• Name: A descriptive name that enables easier reference to this item. Because a core goal of this document is for the resulting representations to be compact, it is RECOMMENDED that the name be short.¶

  This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts determine that there is a compelling reason to allow an exception. The name is not used in the CBOR encoding.¶

• CBOR label: The value to be used as CBOR abbreviation of the item.¶

  The value MUST be unique. The value can be a positive integer, a negative integer, or a string. Integer values between -256 and 255 and strings of length 1 are designated as "Standards Action with Expert Review". Integer values from -65536 to -257 and from 256 to 65535 and strings of maximum length 2 are designated as "Specification Required". Integer values greater than 65535 and strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶

• CBOR type: The CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.¶

• Registry: The registry that values of the item may come from, if one exists.¶

• Description: A brief description of this item.¶

• Specification: A pointer to the public specification for the item, if one exists.¶

This registry will be initially populated by the values in Table 1. In the "Specification" column, the value for all of these entries will be [RFC-XXXX] and [RFC9528].¶

14.10. EDHOC Endpoint Identity Types Registry

IANA is requested to create a new "EDHOC Endpoint Identity Types" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per Section 4.6 of [RFC8126]. "Expert Review" guidelines are provided in Section 14.14.¶

All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126], with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].¶

The columns of this registry are:¶

• Name: This field contains the name of the EDHOC endpoint identity type.¶

• CBOR label: The value to be used to identify this EDHOC endpoint identity type. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -24 to 23 are designated as "Standards Action with Expert Review". Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required". Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".¶

• Description: This field contains a short description of the EDHOC endpoint identity type.¶

• Reference: This field contains a pointer to the public specification for the EDHOC endpoint identity type.¶

This registry has been initially populated with the values in Table 2.¶

14.11. EDHOC Transports Registry

IANA is requested to create a new "EDHOC Transports" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per Section 4.6 of [RFC8126]. "Expert Review" guidelines are provided in Section 14.14.¶

All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126], with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].¶

The columns of this registry are:¶

• Transport ID: The value to be used to identify this means for transporting EDHOC messages. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -24 to 23 are designated as "Standards Action with Expert Review". Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required". Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".¶

• Name: This field contains the name of the means for transporting EDHOC messages.¶

• Description: This field contains a short description of the means used for transporting EDHOC messages.¶

• Reference: This field contains a pointer to the public specification for the means used for transporting EDHOC messages.¶

This registry has been initially populated with the values in Table 3.¶

14.12. EDHOC Trust Anchor Purposes Registry

IANA is requested to create a new "EDHOC Trust Anchor Purposes" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per Section 4.6 of [RFC8126]. "Expert Review" guidelines are provided in Section 14.14.¶

All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126], with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].¶

The columns of this registry are:¶

• Name: This field contains the descriptive name of the trust anchor purpose, to enable easier reference to the item. These names MUST be unique.¶

• CBOR label: This field contains the value used to identify the trust anchor purpose. These values MUST be unique. The value can be an unsigned integer or a negative integer. Different ranges of values use different registration policies:¶

  • Integer values from -24 to 23 are designated as "Standards Action with Expert Review".¶

  • Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required".¶

  • Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".¶

• Description: This field contains a short description of the trust anchor purpose.¶

• Reference: This field contains a pointer to the public specification for the trust anchor purpose.¶

This registry has been initially populated with the values in Section 10.¶

14.13. EDHOC Trust Anchor Types Registry

IANA is requested to create a new "EDHOC Trust Anchor Types" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].¶

The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per Section 4.6 of [RFC8126]. "Expert Review" guidelines are provided in Section 14.14.¶

All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126], with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].¶

The columns of this registry are:¶

• Name: This field contains the descriptive name of the type of trust anchor, to enable easier reference to the item. These names MUST be unique.¶

• CBOR label: This field contains the value used to identify the type of trust anchor. These values MUST be unique. The value can be an unsigned integer or a negative integer. Different ranges of values use different registration policies:¶

  • Integer values from -24 to 23 are designated as "Standards Action with Expert Review".¶

  • Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required".¶

  • Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".¶

• Value type: This field contains the CBOR type for the value portion of the label.¶

• Description: This field contains a short description of the type of trust anchor.¶

• Reference: This field contains a pointer to the public specification for the type of trust anchor.¶

This registry has been initially populated with the values in Table 5.¶

14.14. Expert Review Instructions

"Standards Action with Expert Review", "Specification Required", and "Expert Review" are three of the registration policies defined for the IANA registries established in this document. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.¶

Expert reviewers should take into consideration the following points:¶

• Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts need to make sure that the object of registration is clearly defined in the corresponding specification. Entries that do not meet these objective of clarity and completeness must not be registered.¶

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.¶

• Specifications are required for the "Standards Action with Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.¶

• Experts should take into account the expected usage of fields when approving point assignment. Documents published via Standards Action can also register points outside the Standards Action range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.¶

15.1. Normative References

[COSE.Header.Parameters]

IANA, "COSE Header Parameters", <https://www.iana.org/assignments/cose/cose.xhtml#header-parameters>.

[I-D.ietf-cose-cbor-encoded-cert]

Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-ietf-cose-cbor-encoded-cert-12, 8 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-12>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC4291]

Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/rfc/rfc4291>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7120]

Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/rfc/rfc7120>.

[RFC7252]

Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8323]

Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/rfc/rfc8323>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8613]

Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/rfc/rfc8613>.

[RFC8742]

Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, <https://www.rfc-editor.org/rfc/rfc8742>.

[RFC8747]

Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, <https://www.rfc-editor.org/rfc/rfc8747>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9200]

Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, <https://www.rfc-editor.org/rfc/rfc9200>.

[RFC9201]

Seitz, L., "Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)", RFC 9201, DOI 10.17487/RFC9201, August 2022, <https://www.rfc-editor.org/rfc/rfc9201>.

[RFC9203]

Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9203, DOI 10.17487/RFC9203, August 2022, <https://www.rfc-editor.org/rfc/rfc9203>.

[RFC9360]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, <https://www.rfc-editor.org/rfc/rfc9360>.

[RFC9528]

Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, <https://www.rfc-editor.org/rfc/rfc9528>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

[RFC9668]

Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and G. Selander, "Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024, <https://www.rfc-editor.org/rfc/rfc9668>.

15.2. Informative References

[I-D.ietf-ace-coap-est-oscore]

Selander, G., Raza, S., Furuhed, M., Vučinić, M., and T. Claeys, "Protecting EST Payloads with OSCORE", Work in Progress, Internet-Draft, draft-ietf-ace-coap-est-oscore-06, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-oscore-06>.

[I-D.ietf-ace-workflow-and-params]

Tiloca, M. and G. Selander, "Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework", Work in Progress, Internet-Draft, draft-ietf-ace-workflow-and-params-03, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-workflow-and-params-03>.

[I-D.ietf-core-groupcomm-bis]

Dijk, E. and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-13, 24 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-13>.

[I-D.ietf-core-oscore-id-update]

Höglund, R. and M. Tiloca, "Identifier Update for OSCORE", Work in Progress, Internet-Draft, draft-ietf-core-oscore-id-update-02, 8 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-id-update-02>.

[I-D.ietf-core-oscore-key-update]

Höglund, R. and M. Tiloca, "Key Update for OSCORE (KUDOS)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-key-update-09, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-key-update-09>.

[I-D.ietf-lake-authz]

Selander, G., Mattsson, J. P., Vučinić, M., Fedrecheski, G., and M. Richardson, "Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA)", Work in Progress, Internet-Draft, draft-ietf-lake-authz-03, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-lake-authz-03>.

[I-D.serafin-lake-ta-hint]

Serafin, M. and G. Selander, "Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-serafin-lake-ta-hint-00, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-serafin-lake-ta-hint-00>.

[RFC4949]

Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/rfc/rfc4949>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9147]

Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/rfc/rfc9147>.

A.1. Workflow without Optimizations

The example below shows a simple interaction between C and RS: C and RS run EDHOC wherein C uploads the access token to RS, and then accesses a protected resource at RS.¶

A.2. Workflow with Optimizations

The example below builds on the example in Appendix A.1, while additionally using the EDHOC + OSCORE request defined in [RFC9668] when running EDHOC both with AS and with RS.¶

This interaction between C and RS consists of only two roundtrips to upload the access token, run EDHOC, and access the protected resource at RS.¶

D.1. Version -06 to -07

• Renamed id_ep_types as ep_id_types.¶

• Revised rules for the AS to assign session ID values.¶

• Added explicit validation of AUTH_CRED_C at AS.¶

• "edhoc_info" only in AS-to-C response for first token in a series.¶

• With a group-audience, "edhoc_info" refers to the whole audience.¶

• Defined parameters for the EDHOC_Information object:¶

  • Parameters moved here from draft-ietf-lake-app-profiles.¶

  • New parameter "trust_anchors".¶

• Access Token Request/Response messages must be encoded in CBOR.¶

• Explicit statement on admitted confirmation methods.¶

• First token in a series: the "cnf" claim uses the same confirmation method of the "req_cnf" request to /token.¶

• Revised examples in CBOR diagnostic notation.¶

• With a group-audience, the reverse message flow can use a roll call.¶

• Matching authentication credentials from ID_CRED_X and EAD item.¶

• Handling authentication credentials and EDHOC session that become invalid.¶

• Limited use of ACE Request Creation Hints when supporting the EDHOC reverse message flow.¶

• Changed CBOR abbreviations to not collide with existing codepoints.¶

• Updates and fixes in the IANA considerations.¶

• Updated references.¶

• Clarifications and editorial improvements.¶

D.2. Version -05 to -06

• The access token can be uploaded through EDHOC in EAD_3, EAD_2, or EAD_4.¶

• Ruled out the upload of the access token to the /authz-info endpoint over an unprotected channel.¶

• Defined an EDHOC EAD item for transporting a Session ID.¶

• Provided more details and added example of dynamic update of access rights.¶

• Defined in detail the use of the EDHOC reverse message flow.¶

• Provided details on access token invalidity.¶

• Revised examples with message exchanges.¶

• Clarifications and editorial improvements.¶

D.3. Version -04 to -05

• CBOR diagnostic notation uses placeholders from a CDDL model.¶

• Only CWTs are supported as access tokens in this profile.¶

• The alternative workflow of ACE is only mentioned as an example.¶

• Clarified that both the EDHOC forward and reverse message flows are possible.¶

• Consistent with the used EDHOC message flow, the access token can be in the EAD item of any EDHOC message.¶

• Explicit registration policies for the new IANA registry.¶

• Fixes in the IANA considerations.¶

• Editorial fixes and improvements.¶

D.4. Version -03 to -04

• Fixed column name and prefilling of the "EDHOC Information" registry.¶

• Added EDHOC_Information Parameters originally in draft-tiloca-lake-app-profiles-00.¶

• Removed the case of transporting access token in EAD_1¶

• Removed redundant normative text¶

• Clarifications of association between access token, session_id, EDHOC session and OSCORE security context¶

• Updated references.¶

• Editorial fixes and improvements.¶

D.5. Version -02 to -03

• Restructured presentation of content.¶

• Simplified description of the use of EDHOC_Information.¶

• Merged the concepts of EDHOC "session_id" and identifier of token series.¶

• Enabled the transport of the access token also in EDHOC EAD_3.¶

• Defined semantics of the newly defined CWT/JWT Confirmation Methods.¶

• Clarifications and editorial improvements.¶

D.6. Version -01 to -02

• Removed use of EDHOC_KeyUpdate.¶

• The Security Context is updated either by KUDOS or a rerun of EDHOC.¶

• The alternative workflow (AS token posting) is specified in separate draft.¶

• Fixed and updated examples.¶

• Editorial improvements.¶

D.7. Version -00 to -01

• Fixed semantics of the ead_value for transporting an Access Token in the EAD_1 field.¶

• Error handling aligned with EDHOC.¶

• Precise characterization of the EDHOC execution considered for EDHOC-KeyUpdate.¶

• Fixed message exchange examples.¶

• Added appendix with profile requirements.¶

• Updated references.¶

• Clarifications and editorial improvements.¶