The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework

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.¶

Readers are expected to be familiar with the terms and concepts related to Concise Binary Object Representation (CBOR) [RFC8949], COSE [RFC9052][RFC9053], CoAP [RFC7252], OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. These especially include:¶

• Group Manager, as the entity responsible for a set of groups where communications among members are secured with Group OSCORE.¶

• Authentication credential, as the set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].¶

  Members of an OSCORE group have an associated authentication credential in the format used within the group. As per Section 2.4 of [I-D.ietf-core-oscore-groupcomm], an authentication credential provides the public key as well as a comprehensive set of information related to the public key algorithm, including, e.g., the elliptic curve used (when applicable).¶

Readers are also expected to be familiar with the terms and concepts described in the ACE framework for authentication and authorization [RFC9200], as well as in the OSCORE profile of ACE [RFC9203]. The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. In particular, this includes client (C), resource server (RS), and authorization server (AS).¶

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

Additionally, this document makes use of the following terminology.¶

• Pairwise-only group: an OSCORE group that uses only the pairwise mode of Group OSCORE (see Section 8 of [I-D.ietf-core-oscore-groupcomm]).¶

1.2. Notations

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 parameters' keys 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 8 of Appendix B. For example, {e'context_id_param': h'abcd0000', e'salt_input_param': h'00'} stands for {71: h'abcd0000', 72: h'00'}.¶

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 8 of Appendix B. Finally, please delete this note.¶

2.1. Pre-Conditions

Using Group OSCORE to protect message exchanges between the client and the resource servers (RSs) requires that the client and the RSs have joined the same OSCORE group. This especially includes the derivation of the Group OSCORE Security Context and the assignment of unique Sender IDs to use in the group. Nodes can join the OSCORE group through the respective Group Manager, e.g., as specified in Section 6 of [I-D.ietf-ace-key-groupcomm-oscore].¶

The client needs to join the OSCORE group before requesting an access token that indicates the client's authorization and access rights in the group. After the client and RSs have joined the group, this profile enforces access control for the client to access resources on those RSs, by securely communicating with Group OSCORE.¶

Depending on the limited information initially available, the client may have to first discover the exact OSCORE group used by the RSs for the resources of interest, e.g., by using the approach defined in [I-D.tiloca-core-oscore-discovery].¶

2.2. Requesting an Access Token

This profile requires that the client requests an access token from the AS for the resource(s) that it wants to access at the RS(s), by using the token endpoint as specified in Section 5.8 of [RFC9200].¶

In general, different RSs can be associated with different authorization servers, even if the RSs are members of the same OSCORE group. However, assuming proper configurations and trust relationships, it is possible for multiple RSs associated with the same AS to be part of a single audience (i.e., a group-audience, see Section 6.9 of [RFC9200]). In such a case, the client can request a single access token intended for the group-audience, hence to all the RSs included therein. A particular group-audience might be defined as including all the RSs in the OSCORE group.¶

When requesting the first access token of a token series, the client MUST include in the access token request to the AS the Group Identifier of the OSCORE group, together with its own Sender ID and authentication credential used in that group. The AS MUST include these pieces of information in the access token issued for the client.¶

In such an access token request, the client can also include a proof-of-possession (PoP) evidence to prove possession of the private key corresponding to its own authentication credential to the AS. The PoP evidence is computed over a PoP input uniquely related to the secure communication association between the client and the AS. Including the PoP evidence is OPTIONAL under particular circumstances and is REQUIRED otherwise (see Section 3.2).¶

If the request from the client is granted, then the AS can include the issued access token in the access token response to the client, or instead upload the access token directly to the RS as per the Short Distribution Chain (SDC) workflow defined in [I-D.ietf-ace-workflow-and-params]. This document focuses on the former option (also shown in the example in Figure 1), while the latter option is not detailed further here.¶

The access token request and response exchanged between the client and the AS MUST be confidentiality-protected and MUST ensure authenticity. In this profile, it is RECOMMENDED to use OSCORE [RFC8613] between the client and the AS, to reduce the number of libraries that the client has to support. Other protocols fulfilling the security requirements defined in Sections 5 and 6 of [RFC9200] MAY alternatively be used, such as TLS [RFC8446] or DTLS [RFC9147].¶

2.3. Access Token Uploading

After having obtained the access token from the AS, the client uploads the access token to the RS, by sending a POST request to the authz-info endpoint and using the mechanisms specified in Section 5.10 of [RFC9200]. When using this profile, the communication that C has with the authz-info endpoint is not protected.¶

When verifying the first access token of a token series (see Section 5.10.1.1 of [RFC9200]), the RS joins the pertaining OSCORE group if it has not already (see Section 4.2 for further details).¶

If the access token is valid, the RS replies to the POST request with a 2.01 (Created) response. Also, the RS associates the access token with the Recipient Context pertaining to the client, within the Group OSCORE Security Context used in the OSCORE group. In practice, the RS maintains a collection of Security Contexts with associated authorization information, for all the clients that it is currently communicating with. The authorization information is a policy that is used as input when processing requests from those clients to access resources at the RS.¶

After that, the RS associates the access token with the following pieces of information: i) the identifier of the token series which the access token belongs to; ii) the target audience for which the access token is issued; and iii) the authentication credential of the client in the OSCORE group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]). Such pieces of information are specified by corresponding elements of the access token (see Section 3.4).¶

The above has considered an access token intended for a single RS. However, as discussed in Section 2.2, an access token can be intended for a group-audience including multiple RSs in the OSCORE group. In such a case, the client could efficiently upload the access token to many or all of those RSs at once (e.g., over IP multicast), after which each RS individually performs the same steps described above.¶

2.4. Secure Communication

The client can send a CoAP request protected with Group OSCORE [I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast request targeting the RS [RFC7252], or a one-to-many group request (e.g., over IP multicast) [I-D.ietf-core-groupcomm-bis] targeting the OSCORE group where the RS is also a member.¶

To this end, the client uses the Group OSCORE Security Context already established upon joining the OSCORE group, unless it has a more recent Security Context that has been established in the group as a result of a group rekeying (see Section 12.2 of [I-D.ietf-core-oscore-groupcomm]).¶

When the client sends to the RS a request protected with the Group OSCORE Security Context and the RS successfully verifies the request, the RS authenticates the client as a legitimate member of the OSCORE group. After that, if the target resource requires authorization, the RS performs access rights verification as per the access token associated with the Recipient Context pertaining to the client, which was used to verify the request and is included in the Group OSCORE Security Context used in the group.¶

The RS may send a response back to the client, also protecting it with Group OSCORE.¶

3.1. Preliminary Operations

The following considers a client that is a member of an OSCORE group G with GID* as current Group Identifier (Gid), within which the client currently has SID* as Sender ID and uses a public authentication credential AUTH_CRED_C that specifies the PoP key K.¶

The client MUST perform the following steps, before requesting an access token to be bound to AUTH_CRED_C (hence to the PoP key K) and to be associated with the client's membership in group G through the values GID* and SID*.¶

1. The client checks whether it is a member of any two OSCORE groups G1 and G2 such that all the following conditions hold.¶

   • Both groups have GID* as current Gid.¶

   • The client uses SID* as Sender ID in both groups.¶

   • The client uses the same AUTH_CRED_C in both groups.¶

2. If such two groups G1 and G2 are found at Step 1, then the client moves to Step 3. Otherwise, the client terminates this algorithm and proceeds with requesting the access token as defined in Section 3.2.¶

3. The client can choose to terminate this algorithm and perform it again later on.¶

   Alternatively, the client can alter its current group memberships, in order to ensure that two groups like G1 and G2 cannot be determined. To this end, the client has two available options.¶

   • The client leaves some of the OSCORE groups that could be determined as groups like G1 and G2, e.g., as specified in Section 9.11 of [I-D.ietf-ace-key-groupcomm-oscore].¶

   • The client obtains a new Sender ID in some of the OSCORE groups that could be determined as groups like G1 and G2. To this end, the client can request a new Sender ID in a group to the Group Manager responsible for that group, e.g., as specified in Section 9.2 of [I-D.ietf-ace-key-groupcomm-oscore]. Alternatively, the client can re-join a group, thereby obtaining a new Sender ID in that group.¶

   Finally, the client moves to Step 1.¶

3.2. 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 6).¶

When requesting the first access token of a token series, the POST request is formatted as the analogous Client-to-AS request in the OSCORE profile of ACE (see Section 3.1 of [RFC9203]), with the following additional parameters that MUST be included in the payload.¶

• 'context_id', defined in Section 3.2.1 of this document. This parameter specifies the Gid (i.e., the ID Context) of an OSCORE group whose intended members are both the client and the RS(s) in the audience for which the access token is asked to be issued. In particular, the client wishes to communicate with the RS(s) in that audience using the Group OSCORE Security Context associated with that OSCORE group.¶

• 'salt_input', defined in Section 3.2.2 of this document. This parameter includes the Sender ID that the client has in the OSCORE group whose Gid is specified in the 'context_id' parameter above.¶

• 'req_cnf', defined in Section 3.1 of [RFC9201]. This parameter follows the syntax from Section 3.1 of [RFC8747] and its inner confirmation value specifies the authentication credential AUTH_CRED_C that the client uses in the OSCORE group. The public key included in the authentication credential will be used as the PoP key bound to the access token.¶

  The inner confirmation value of the 'req_cnf' parameter MUST specify AUTH_CRED_C as transported by value.¶

  At the time of writing this specification, acceptable formats of authentication credentials in Group OSCORE are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].¶

  Further formats may be available in the future and would be acceptable to use as long as they comply with the criteria compiled in Section 2.4 of [I-D.ietf-core-oscore-groupcomm]. In particular, an authentication credential has to explicitly include the public key as well as a comprehensive set of information related to the public key algorithm, including, e.g., the elliptic curve used (when applicable).¶

  Note that C might have previously uploaded AUTH_CRED_C to the Group Manager as provided within a chain or a bag (e.g., as the end-entity certificate in a chain of certificates). For example, such uploading can rely on the 'client_cred' parameter of a Join Request or of an Authentication Credential Update Request sent to the Group Manager as specified in Sections 6.1 and 9.4 of [I-D.ietf-ace-key-groupcomm-oscore].¶

  In such a case, the inner confirmation value of the 'req_cnf' parameter MUST specify AUTH_CRED_C as provided within the same chain or bag.¶

  [ As to CWTs and CCSs, the CWT Confirmation Methods 'kcwt' and 'kccs' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ]¶

  [ As to X.509 certificates, the CWT Confirmation Methods 'x5bag' and '5chain' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ]¶

  [ As to C509 certificates, the CWT Confirmation Methods 'c5b' and 'c5c' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ]¶

Furthermore, the payload of the request can include exactly one of the two following parameters, specifying a proof-of-possession (PoP) evidence computed by the client.¶

• 'client_cred_verify', defined in Section 3.2.3 of this document, specifying the client's PoP evidence as a signature, which is computed as defined later in this section. This parameter MUST NOT be included if the OSCORE group is a pairwise-only group.¶

• 'client_cred_verify_mac', defined in Section 3.2.4 of this document, specifying the client's PoP evidence as a MAC, which is computed as defined later in this section. This parameter MUST NOT be included if the OSCORE group is not a pairwise-only group.¶

The PoP evidence can be used by the AS to achieve proof of possession of the client's private key, i.e., to verify that the client indeed owns the private key associated with the public key within AUTH_CRED_C.¶

When preparing the POST request, the client might know that the AS has previously achieved proof of possession of the private key in question. In such a case, it is OPTIONAL for the client to compute the PoP evidence and to specify it in the 'client_cred_verify' or 'client_cred_verify_mac' parameter of the POST request.¶

If the client believes that the AS has not previously achieved proof of possession of the private key in question or that such proof was achieved but does not hold anymore, then the client MUST compute the PoP evidence as defined below and MUST specify it in the 'client_cred_verify' or 'client_cred_verify_mac' parameter of the POST request.¶

In order to compute the PoP evidence, the client MUST use as PoP input the byte representation of an information that uniquely represents the secure communication association between the client and the AS. It is RECOMMENDED that the client uses the following as PoP input.¶

• If the client and the AS communicate over TLS 1.2 [RFC5246] or DTLS 1.2 [RFC6347], the PoP input is an exporter value computed as defined in Section 4 of [RFC5705], using the following inputs:¶

  • The exporter label "EXPORTER-ACE-PoP-Input-Client-AS" registered in Section 12.6 of this document.¶

  • The empty 'context value', i.e., a 'context value' of zero-length.¶

  • 32 as length value in bytes.¶

• If the client and the AS communicate over TLS 1.3 [RFC8446] or DTLS 1.3 [RFC9147], the PoP input is an exporter value computed as defined in Section 7.5 of [RFC8446], using the following inputs:¶

  • The exporter label "EXPORTER-ACE-PoP-Input-Client-AS" registered in Section 12.6 of this document.¶

  • The empty 'context_value', i.e., a 'context_value' of zero-length.¶

  • 32 as 'key_length' in bytes.¶

• If the client and the AS communicate over OSCORE [RFC8613], the PoP input is the output PRK of an HKDF-Extract step [RFC5869], i.e., PRK = HMAC-Hash(salt, IKM).¶

  In particular, given the OSCORE Security Context CTX shared between the client and the AS, then the following applies.¶

  • 'salt' takes (x1 | x2), where | denotes byte string concatenation, while x1 and x2 are defined as follows.¶

    • x1 is the binary representation of a CBOR data item. If CTX does not specify an OSCORE ID Context, the CBOR data item is the CBOR simple value null (0xf6). Otherwise, the CBOR data item is a CBOR byte string, with value the OSCORE ID Context specified in CTX.¶

    • x2 is the binary representation of a CBOR byte string. The value of the CBOR byte string is the OSCORE Sender ID of the client, which the client stores in its Sender Context of CTX and the AS stores in its Recipient Context of CTX.¶

  • 'IKM' is the OSCORE Master Secret specified in CTX.¶

  • The used HKDF is the HKDF Algorithm specified in CTX.¶

  The following shows an example of input to the HMAC-Hash() function.¶

  On the client side, the OSCORE Security Context shared with the AS includes:¶

  ID Context: 0x37cbf3210017a2d3 (8 bytes)
  
  Sender ID: 0x01 (1 byte)
  
  Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
  

  ¶

  Then, the following holds.¶

  x1 (Raw value) (8 bytes)
  0x37cbf3210017a2d3
  
  x1 (CBOR Data Item) (9 bytes)
  0x4837cbf3210017a2d3
  
  x2 (Raw value) (1 bytes)
  0x01
  
  x2 (CBOR Data Item) (2 bytes)
  0x4101
  
  salt (11 bytes)
  0x4837cbf3210017a2d34101
  
  IKM (16 bytes)
  0x0102030405060708090a0b0c0d0e0f10
  

  ¶

It is up to applications or future specifications to define what is used as PoP input in further alternative settings.¶

After that, the client computes the PoP evidence as follows.¶

• If the OSCORE group is not a pairwise-only group, the PoP evidence MUST be a signature. The client computes the signature over the PoP input, by using the same private key and signature algorithm that it uses for signing messages in the OSCORE group. The client's private key is the one associated with the client's authentication credential used in the OSCORE group and specified in the 'req_cnf' parameter above.¶

• If the OSCORE group is a pairwise-only group, the PoP evidence MUST be a MAC computed as follows, by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps [RFC5869].¶

  MAC = HKDF(salt, IKM, info, L)¶

  The input parameters of HKDF are as follows.¶

  • salt takes as value the empty byte string.¶

  • IKM is computed as a cofactor Diffie-Hellman shared secret (see Section 5.7.1.2 of [NIST-800-56A]), using the ECDH algorithm that is used as Pairwise Key Agreement Algorithm in the OSCORE group. The client uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the AS. For X25519 and X448, the procedure is described in Section 5 of [RFC7748].¶

    The client's private key is the one associated with the client's authentication credential used in the OSCORE group and specified in the 'req_cnf' parameter above. The client may obtain the Diffie-Hellman public key of the AS during its registration process at the AS.¶

  • info takes as value the PoP input.¶

  • L is equal to 8, i.e., the size of the MAC, in bytes.¶

An example of the POST request is shown in Figure 2.¶

Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: 19 (application/ace+cbor)
Payload:
{
  / audience /        5 : "tempSensorInLivingRoom",
  / scope /           9 : "read",
    e'context_id_param' : h'abcd0000',
    e'salt_input_param' : h'00',
  e'client_cred_verify' : h'c5a6...f100' / elided for brevity /,
  / req_cnf /         4 : {
    e'kccs' : {
      / sub / 2 : "42-50-31-FF-EF-37-32-39",
      / cnf / 8 : {
        / COSE_Key / 1 : {
          / kty /  1 : 2 / EC2 /,
          / crv / -1 : 1 / P-256 /,
          / x /   -2 : h'd7cc072de2205bdc1537a543d53c60a6
                         acb62eccd890c7fa27c9e354089bbe13',
          / y /   -3 : h'f95e1d4b851a2cc80fff87d8e23f22af
                         b725d535e515d020731e79a3b4e47120'
        }
      }
    }
  }
}

In the example above, the client specifies that its authentication credential in the OSCORE group is the CCS shown in Figure 3.¶

{
  / sub / 2 : "42-50-31-FF-EF-37-32-39",
  / cnf / 8 : {
    / COSE_Key / 1 : {
      / kty /  1 : 2 / EC2 /,
      / crv / -1 : 1 / P-256 /,
      / x /   -2 : h'd7cc072de2205bdc1537a543d53c60a6
                     acb62eccd890c7fa27c9e354089bbe13',
      / y /   -3 : h'f95e1d4b851a2cc80fff87d8e23f22af
                     b725d535e515d020731e79a3b4e47120'
    }
  }
}

Later on, the client might want to update its access rights with respect to the same target audience for which the first access token was issued.¶

As long as the client is a member of the OSCORE group and the latest access token of a token series is still valid, the client can contact the AS to ask for updating its access rights, through a process more efficient than that used for the first access token of the token series.¶

When doing so, the POST request sent to the token endpoint is like the one defined above, with the differences compiled below. An example of such a request is shown in Figure 4.¶

• The request MUST include the 'token_series_id' parameter defined in [I-D.ietf-ace-workflow-and-params].¶

  The 'token_series_id' parameter encodes a token series identifier that is assigned by the AS as discussed in Section 3.3 and identifies an ongoing token series associated with the pair (AUTH_CRED_C, Aud). That is, previous access tokens in that series were issued by the AS to the client, as bound to AUTH_CRED_C and intended for the target audience Aud (see Section 5.8.1 of [RFC9200]).¶

  Note that the same 'token_series_id' value might identify multiple ongoing token series, e.g., if those are associated with the same client but different audiences. Therefore, the AS uses the 'token_series_id' value together with other information such as the targeted audience and the authenticated identity of the client, in order to determine the exact token series to which the new requested access token has to be added.¶

• The 'audience' parameter MUST be included in the POST request, if it was included in the POST request that the client previously sent to the AS for requesting the first access token in the token series to which the new requested access token has to be added. If the 'audience' parameter is included in the present POST request, its value MUST be the same value of the 'audience' parameter in that previous POST request.¶

• The request MUST NOT include any of the following parameters: 'context_id', 'salt_input', 'client_cred_verify', 'client_cred_verify_mac', and 'req_cnf'.¶

If the access token request specifies the 'token_series_id' parameter together with any of the parameters 'context_id', 'salt_input', 'client_cred_verify', 'client_cred_verify_mac', and 'req_cnf', the Client-to-AS request MUST be declined with the error code "invalid_request" as defined in Section 5.8.3 of [RFC9200].¶

The AS MUST verify that the received 'token_series_id' identifies a token series to which a still valid access token belongs, such that the access token is issued to the client and is intended for the audience specified by the 'audience' parameter of the POST request, if present therein, or for the default audience associated with the client otherwise. 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: 19 (application/ace+cbor)
Payload:
{
  / audience /             5 : "tempSensorInLivingRoom",
  / scope /                9 : "write",
    e'token_series_id_param' : h'3a'
}

3.3. 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 client C and associated with the same authentication credential of C, namely AUTH_CRED_C.¶

• Issued for the same target audience.¶

Upon a successful update of access rights (see Section 3.4.2), 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 client C and target audience, are bound to the same authentication credential AUTH_CRED_C of C, and specify the same token series identifier, e.g., as value of the 'tokens_series_id' claim (see Section 3.4.1).¶

The AS assigns the token series identifier when issuing the first access token of a new series. That token series identifier remains fixed throughout the series lifetime.¶

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

• Issued to the same client C, irrespective of the specific AUTH_CRED_C bound to the access token; and¶

• Issued for the same RS as identified by the targeted audience.¶

If the access token is issued for a group-audience (see Section 6.9 of [RFC9200]), the token series is associated with all the resource servers in the group-audience. In such case, what is defined above applies, with the difference that the resource servers as identified by the targeted group-audience are collectively considered.¶

3.4. AS-to-C: Response

After having verified the POST access token request to the token endpoint and that the client is authorized to obtain an access token aligned with the request, the AS proceeds as defined below.¶

In the following, an authentication credential is denoted as "confirmed" if and only if the AS has achieved proof of possession of the private key associated with the public key of that authentication credential and such proof still holds. Otherwise, an authentication credential is denoted as "non confirmed".¶

If the access token request specifies none of the parameters 'token_series_id', 'client_cred_verify', and 'client_cred_verify_mac', then the AS performs the following steps.¶

• The AS considers the authentication credential AUTH_CRED_C specified in the 'req_cnf' parameter of the access token request.¶

• If the AS currently knows AUTH_CRED_C as "confirmed", then the AS considers proof of possession of the client's private key to be achieved and it takes no further actions in this respect.¶

  The AS might already have achieved proof of possession when establishing a secure communication association with the client, or when processing a previous access token request conveying the same AUTH_CRED_C.¶

  Alternatively, a further entity in a trust relationship with the AS might have already achieved proof of possession of the private key and informed the AS about that. Building on that trust relationship, the AS considered AUTH_CRED_C to be "confirmed" from then on.¶

• If the AS does not currently know AUTH_CRED_C as "confirmed", then the AS MUST consider the access token request to be invalid.¶

If both the 'client_cred_verify' and 'client_cred_verify_mac' parameters are present, then the AS MUST consider the access token request to be invalid.¶

If the access token request specifies either the 'client_cred_verify' parameter or the 'client_cred_verify_mac' parameter, then the AS MUST verify the proof-of-possession (PoP) evidence specified therein. In particular, the AS proceeds as follows.¶

• As PoP input, the AS uses the same value that the client used (see Section 3.2).¶

• As public key of the client, the AS uses the one included in the authentication credential AUTH_CRED_C that is specified in the 'req_cnf' parameter of the access token request.¶

  This requires the AS to support the format of AUTH_CRED_C, i.e., the format of authentication credential that is used in the OSCORE group where the client uses that authentication credential.¶

  Practically, this is not an issue, since the same format is used by RSs in that group and an RS supporting this profile is expected to be registered only at an AS that supports the formats of authentication credential that the RS supports.¶

• If the access token request includes the 'client_cred_verify' parameter, this specifies the PoP evidence as a signature. Then, the AS verifies the signature by using the public key of the client.¶

  This requires the AS to support the signature algorithm and curve (when applicable) that are used in the OSCORE group where the client uses the authentication credential AUTH_CRED_C that is specified in the 'req_cnf' parameter of the access token request.¶

  Practically, this is not an issue, since the same algorithm and curve (when applicable) are used by RSs in that group and an RS supporting this profile is expected to be registered only at an AS that supports the signature algorithms and curves (when applicable) that the RS supports.¶

• If the access token request includes the 'client_cred_verify_mac' parameter, this specifies the PoP evidence as a Message Authentication Code (MAC).¶

  Then, the AS recomputes the MAC through the same process taken by the client when preparing the value of the 'client_cred_verify_mac' parameter for the access token request (see Section 3.2), with the difference that the AS uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the client. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the access token request.¶

  This requires the AS to support the ECDH algorithm that is used as Pairwise Key Agreement Algorithm in the OSCORE group where the client uses the authentication credential AUTH_CRED_C that is specified in the 'req_cnf' parameter of the access token request.¶

  Practically, this is not an issue, since the same ECDH algorithm is used by RSs in that group and an RS supporting this profile is expected to be registered only at an AS that supports the ECDH algorithms that the RS supports.¶

If the verification of the PoP evidence succeeds, then the AS considers AUTH_CRED_C to be "confirmed" from then on.¶

Instead, if the verification of the PoP evidence fails, then the AS MUST consider the access token request to be invalid. Also, the AS MUST consider AUTH_CRED_C to be "non confirmed" from then on, until the AS again achieves proof of possession of the client's private key.¶

If the access token request was invalid or not authorized, then the AS MUST reply to the client with an error response as described in Section 5.8.3 of [RFC9200].¶

Instead, if all verifications are successful, the AS replies to the client with an access token response as defined in Section 5.8.2 of [RFC9200]. In particular:¶

• The AS can signal that the use of Group OSCORE as per this profile is REQUIRED for the issued access token, by including the 'ace_profile' parameter with the value "coap_group_oscore" in the access token response. The client MUST use Group OSCORE towards all the resource servers for which this access token is valid, when accessing protected resources at those resource servers 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.¶

• The AS MUST NOT include the 'cnf' parameter in the access token response.¶

• The AS MUST NOT include the 'rs_cnf' parameter defined in [RFC9201] in the access token response. In general, the AS is not aware of the authentication credentials (and public keys included thereof) that the RSs use in the OSCORE group. Instead, the client is able to retrieve the authentication credentials of other group members from the responsible Group Manager, both upon joining the group or later on as a group member, e.g., as specified in Sections 6 and 9.3 of [I-D.ietf-ace-key-groupcomm-oscore].¶

• If the issued access token is the first one of a token series, the AS MUST include the 'token_series_id' parameter defined in [I-D.ietf-ace-workflow-and-params] in the access token response, specifying the identifier of the token series which the access token belongs to.¶

• If the issued access token is not the first one of a token series, the AS MUST NOT include the 'token_series_id' parameter in the access token response.¶

According to this document, the AS includes the 'access_token' parameter in the access token response, specifying the issued access token. The alternative Short Distribution Chain (SDC) workflow where the access token is uploaded by the AS directly to the RS is described in [I-D.ietf-ace-workflow-and-params].¶

Figure 5 shows an example of access token response, where the access token has been truncated for readability.¶

Header: Created (Code=2.01)
Content-Format: 19 (application/ace+cbor)
Payload:
{
  / access_token /         1 : h'8343a1010aa2044c...00'
                               / elided for brevity /,
  / ace_profile /         38 : e'coap_group_oscore',
  / expires_in /           2 : 3600,
    e'token_series_id_param' : h'3a'
}

{
  / aud /                3 : "tempSensorInLivingRoom",
  / iat /                6 : 1719820800,
  / exp /                4 : 2035353600,
  / scope /              9 : "temperature_g firmware_p",
  / ace_profile /       38 : e'coap_group_oscore',
  e'token_series_id_claim' : h'3a'
       e'context_id_claim' : h'abcd0000',
       e'salt_input_claim' : h'00',
  / cnf /           8 : {
    e'kccs' : {
      / sub / 2 : "42-50-31-FF-EF-37-32-39",
      / cnf / 8 : {
        / COSE_Key / 1 : {
          / kty /  1 : 2 / EC2 /,
          / crv / -1 : 1 / P-256 /,
          / x /   -2 : h'd7cc072de2205bdc1537a543d53c60a6
                         acb62eccd890c7fa27c9e354089bbe13',
          / y /   -3 : h'f95e1d4b851a2cc80fff87d8e23f22af
                         b725d535e515d020731e79a3b4e47120'
        }
      }
    }
  }
}

A9                                      # map(9)
   03                                   # unsigned(3)
   76                                   # text(22)
      74656D7053656E736F72496E4C6976696E67526F6F6D
      # "tempSensorInLivingRoom"
   06                                   # unsigned(6)
   1A 66826200                          # unsigned(1719820800)
   04                                   # unsigned(4)
   1A 79510800                          # unsigned(2035353600)
   09                                   # unsigned(9)
   78 18                                # text(24)
      74656D70657261747572655F67206669726D776172655F70
      # "temperature_g firmware_p"
   18 26                                # unsigned(38)
   05                                   # unsigned(5)
   18 2A                                # unsigned(42)
   41                                   # bytes(1)
      3A
   18 33                                # unsigned(51)
   44                                   # bytes(4)
      ABCD0000
   18 34                                # unsigned(52)
   41                                   # bytes(1)
      00
   08                                   # unsigned(8)
   A1                                   # map(1)
      0B                                # unsigned(11)
      A2                                # map(2)
         02                             # unsigned(2)
         77                             # text(23)
            34322D35302D33312D46462D45462D33372D33322D3339
            # "42-50-31-FF-EF-37-32-39"
         08                             # unsigned(8)
         A1                             # map(1)
            01                          # unsigned(1)
            A4                          # map(4)
               01                       # unsigned(1)
               02                       # unsigned(2)
               20                       # negative(0)
               01                       # unsigned(1)
               21                       # negative(1)
               58 20                    # bytes(32)
                  D7CC072DE2205BDC1537A543D53C60A6
                  ACB62ECCD890C7FA27C9E354089BBE13
               22                       # negative(2)
               58 20                    # bytes(32)
                  F95E1D4B851A2CC80FFF87D8E23F22AF
                  B725D535E515D020731E79A3B4E47120

4.1. C-to-RS POST to authz-info Endpoint

The client uploads the access token to the authz-info endpoint of the RS, as defined in Section 5.10.1 of [RFC9200].¶

4.2. RS-to-C: 2.01 (Created)

The RS MUST verify the validity of the uploaded access token T_NEW as defined in Section 5.10.1 of [RFC9200], with the following additions.¶

The RS retrieves from T_NEW the pieces of information (SeriesId_NEW, Aud_NEW, AuthCred_NEW), where: SeriesId_NEW is the identifier of the token series which the access token belongs to; Aud_NEW is the audience targeted by the access token; and AuthCred_NEW is the client's authentication credential AUTH_CRED_C, specified by value or by reference.¶

The RS checks whether it is storing an access token T_OLD that is associated with the analogous pieces of information (SeriesId_OLD, Aud_OLD, AuthCred_OLD) such that: SeriesId_NEW is equal to SeriesId_OLD; Aud_NEW is equal to Aud_OLD; and AuthCred_NEW is equal to or is a valid reference to AuthCred_OLD as AUTH_CRED_C specified by value.¶

If the RS finds such an access token T_OLD, the RS performs the actions specified in Section 4.4.¶

Otherwise, the RS performs the steps specified below. The following refers to the access token T_NEW and assumes it to be a CWT.¶

• The RS checks that the claims 'context_id', 'salt_input', and 'cnf' are included in the access token. In particular, the RS checks that the 'cnf' claim specifies the client's authentication credential as transported by value.¶

  If any of these claims are missing, malformed, or non-conformant, the RS MUST consider the access token invalid and MUST reply with a 4.00 (Bad Request) error response.¶

  Otherwise, the RS retrieves from the access token:¶

  • GID* as the Gid of the OSCORE group, which is specified in the 'context_id' claim.¶

  • SID* as the Sender ID that the client has in the OSCORE group, which is specified in the 'salt_input' claim.¶

  • AUTH_CRED_C* as the authentication credential that the client uses in the OSCORE group, which is specified in the inner confirmation value of the 'cnf' claim.¶

• The RS joins the pertaining OSCORE group identified by GID*, if it is not already a member. If the RS is intended to be a member of multiple groups and different Group Managers are responsible for those groups, the RS needs to perform the above through all such Group Managers under which there is a group identified by GID*.¶

  By performing the operation specified in Section 9.10 of [I-D.ietf-ace-key-groupcomm-oscore] for the realization of Group Manager defined in that document, the RS can rely on GID* to retrieve from the Group Manager the group name and the URI of the group-membership resource at the Group Manager for joining the group.¶

  Note that, due to the RS joining the group, the Group Manager performs a group rekeying if required by the application (see Section 12.2 of [I-D.ietf-core-oscore-groupcomm]). This results in changing the Gid used in the group, which is handled as defined later below.¶

  Irrespective of what is indicated by the access token, the process by which the RS joins OSCORE groups has to be aligned and consistent with the set of groups that the RS intends to be a member of and is authorized to join at the responsible Group Manager.¶

  If the RS attempts and fails to join the OSCORE group identified by GID*, the RS MUST reply with a 5.00 (Internal Server Error) error response.¶

• Based on the OSCORE Security Contexts that it stores, the RS builds GROUPS as the set of OSCORE groups such that all the following conditions hold, for each group G in the set.¶

  • The RS is a member of the group G.¶

  • The audience targeted by the access token is consistent with using the group G for accessing protected resources hosted by the RS.¶

  • The group G has GID' as current Gid. In particular, GID' is determined as below.¶

    • If, following the early verification of the access token, the RS has joined the group G as identified by GID* (see above), GID' is the Gid that the Group Manager has provided to the RS as a result of the group joining. In this case, GID' might be different from GID*, if the Group Manager has performed a group rekeying due to the RS joining the group.¶

    • If, following the early verification of the access token, the RS has retrieved from the Group Manager updated keying material associated with the group G as identified by GID* (e.g., as specified in Section 9.1 of [I-D.ietf-ace-key-groupcomm-oscore]), GID' is the Gid that the Group Manager has provided to the RS. In this case, GID' might be different from GID*, if the Group Manager previously performed a group rekeying process that the RS had missed.¶

    • If none of the above applies, GID' is equal to GID*¶

  If no such group is found, the RS MUST consider the access token invalid and MUST reply with a 4.00 (Bad Request) error response.¶

  Otherwise, for each of the N >= 1 groups G in the set GROUPS, the RS MUST request to the corresponding Group Manager the authentication credential that the client uses in G, specifying SID* in the request sent to the Group Manager, e.g., as specified in Section 9.3 of [I-D.ietf-ace-key-groupcomm-oscore].¶

  When receiving a successful response from each of the Group Managers, the RS MUST check whether the client's authentication credential AUTH_CRED_C retrieved from the Group Manager is equal to AUTH_CRED_C* retrieved from the access token. In the case that AUTH_CRED_C* is provided within a chain or a bag, but AUTH_CRED_C is not provided within the same chain or bag, then the RS MUST NOT determine AUTH_CRED_C* and AUTH_CRED_C to be equal.¶

  If any of the following conditions holds, the RS MUST consider the access token invalid and MUST reply to the client with a 5.03 (Service Unavailable) error response.¶

  • None or more than one of the Group Managers provide the RS with a successful response where the conveyed AUTH_CRED_C is equal to AUTH_CRED_C*.¶

  • After having performed a maximum, pre-configured number of attempts or after a maximum, pre-configured amount of time has elapsed, less than N Group Managers have sent a successful response to the RS.¶

  The process above is successful if and only if the RS receives a successful response from all the N Group Managers, and exactly one of such responses conveys AUTH_CRED_C equal to AUTH_CRED_C*. This ensures that there is only one OSCORE group G* such that: the client and the RS are both its members; it has GID' as current Gid; and the client uses SID* as Sender ID in the group. In turn, this will ensure that the RS can bound the access token to such single OSCORE group G*.¶

If the operations above are successful, the access token is valid, and further checks on its content are successful, then the RS proceeds as follows.¶

• The RS considers the Group OSCORE Security Context identified by GID' and used in the OSCORE group G* determined above.¶

• If the Group OSCORE Security Context is not including a Recipient Context pertaining to the client (i.e., with Recipient ID equal to SID* and authentication credential equal to AUTH_CRED_C*), then the RS derives such Recipient Context and adds it to the Group OSCORE Security Context.¶

• The RS associates the access token with the Recipient Context pertaining to the client, within the Group OSCORE Security Context used in the OSCORE group G*.¶

• The RS associates the access token with the tuple (SeriesId, Aud, AuthCred), where:¶

  • SeriesId is the identifier of the token series which the access token belongs to, as indicated by the 'token_series_id' claim of the access token.¶

  • Aud is the target audience, as indicated by the 'aud' claim of the access token.¶

  • AuthCred is the authentication credential that the client uses in G*, i.e., AUTH_CRED_C*.¶

Finally, the RS MUST send a 2.01 (Created) response to the client, as defined in Section 5.10.1 of [RFC9200].¶

As defined in Section 5, a possible change of the client's authentication credential requires the client to upload to the RS a new access token bound to the new authentication credential.¶

4.3. Client-RS Secure Communication

As members of the OSCORE group, both the client and the RS have established the related Group OSCORE Security Context to securely communicate in the group. Therefore, they can simply start to securely communicate using Group OSCORE, without deriving any additional keying material or security association.¶

It can happen that the client or the RS deletes an access token, e.g., when the access token has expired or has been revoked.¶

If the RS deletes an access token, this MUST NOT result in the RS deleting the associated Recipient Context pertaining to the client from the Group OSCORE Security Context used in the OSCORE group.¶

If the client deletes an access token, this MUST NOT result in the client deleting the associated Group OSCORE Security Context used in the OSCORE group. The client MAY request a new access token from the AS, to be uploaded to the RS for re-enabling access to protected resources.¶

4.4. Update of Access Rights

With reference to the stored access token T_OLD and the latest uploaded access token T_NEW considered in Section 4.2, the RS proceeds as follows.¶

• The RS associates T_NEW with the same tuple (SeriesId, Aud, AuthCred) with which T_OLD was associated.¶

• The RS associates T_NEW with the Recipient Context pertaining to the client that is included within the Group OSCORE Security Context used in the OSCORE group pertaining to T_NEW, i.e., the same Recipient Context with which T_OLD was associated.¶

• The RS supersedes T_OLD with T_NEW.¶

Finally, the RS MUST reply with a 2.01 (Created) response, as defined in Section 5.10.1 of [RFC9200].¶

4.5. Access Rights Verification

The RS MUST follow the procedures defined in Section 5.10.2 of [RFC9200]. If an RS receives a request protected with Group OSCORE from a client, the RS processes the request according to [I-D.ietf-core-oscore-groupcomm], using the Recipient Context pertaining to the client that is included within the Group OSCORE Security Context used in the group.¶

If the Group OSCORE verification succeeds and the target resource requires authorization, the RS retrieves the authorization information from the access token associated with the Recipient Context used to verify the request.¶

Then, the RS MUST verify that the action requested on the resource is authorized.¶

If the RS has no valid access token for the client, the RS MUST reject the request and MUST reply to the client with a 4.01 (Unauthorized) error response.¶

If the RS has an access token for the client but no actions are authorized on the target resource, the RS MUST reject the request and MUST reply to the client with a 4.03 (Forbidden) error response.¶

If the RS has an access token for the client but the requested action is not authorized, the RS MUST reject the request and MUST reply to the client with a 4.05 (Method Not Allowed) error response.¶

4.6. Storing Multiple Access Tokens per PoP Key

According to Section 5.10.1 of [RFC9200], an RS is recommended to store only one access token per proof-of-possession (PoP) key and to supersede such an access token when receiving and successfully validating a new one bound to the same PoP key.¶

However, when using the profile specified in this document, an RS might practically have to deviate from that recommendation and store multiple access tokens bound to the same PoP key, i.e., to the same public authentication credential of a client.¶

For example, this can occur in the following cases.¶

• The RS is the single RS associated with an audience AUD1 and also belongs to a group-audience AUD2 (see Section 6.9 of [RFC9200]).¶

  A client C with public authentication credential AUTH_CRED_C can request two access tokens T1 and T2 from the AS, such that:¶

  • T1 targets AUD1 and has scope SCOPE1; and¶

  • T2 targets AUD2 and has scope SCOPE2 different from SCOPE1.¶

  Both T1 and T2 are going to be bound to the same PoP key specified by AUTH_CRED_C.¶

  In fact, if the AS issues access tokens targeting a group-audience, then the above can possibly be the case when using any transport profile of ACE that supports asymmetric PoP keys. If so, the RS should be ready to store at minimum one access token per PoP key per audience it belongs to.¶

• The RS is a member of two OSCORE groups G1 and G2. In particular, the same format of public authentication credentials is used in both OSCORE groups.¶

  A client C with public authentication credential AUTH_CRED_C of such format, also member of the two OSCORE groups G1 and G2, can conveniently use AUTH_CRED_C as its public authentication credential in both those groups. Therefore, C can request two access tokens T1 and T2 from the AS, such that:¶

  • T1 targets RS and reflects the membership of C in G1, as per its claims "context_id" and "salt_input"; and¶

  • T2 targets RS and reflects the membership of C in G2, as per its claims "context_id" and "salt_input".¶

  Both T1 and T2 are going to be bound to the same PoP key specified by AUTH_CRED_C.¶

  When using the profile specified in this document, the RS should be ready to store at minimum one access token per PoP key per OSCORE group it is (going to be) a member of (although, per the previous point, even this can still be limiting).¶

• The RS uses both the profile specified in this document and a different transport profile of ACE that also relies on asymmetric PoP keys, e.g., the EDHOC and OSCORE profile defined in [I-D.ietf-ace-edhoc-oscore-profile].¶

  In such a case, a client C with public authentication credential AUTH_CRED_C can request two access tokens T1 and T2 from the AS, such that:¶

  • T1 targets RS and is meant to be used according to the Group OSCORE profile defined in this document; and¶

  • T2 targets RS and is meant to be used according to the EDHOC and OSCORE profile defined in [I-D.ietf-ace-edhoc-oscore-profile].¶

  Both T1 and T2 are going to be bound to the same PoP key specified by AUTH_CRED_C.¶

  When using multiple transport profiles of ACE that rely on asymmetric PoP keys, it is reasonable that the RS is capable to store at minimum one access token per PoP key per used profile (although, per the previous points, even this can still be limiting).¶

In order to keep the same spirit of the recommendation in Section 5.10.1 of [RFC9200] without impeding cases such as those outlined in the examples above, the following defines more fine-grained recommendations for the storage of access tokens at an RS when this profile is used.¶

• As to access tokens issued in accordance with this profile (i.e., specifying the profile "coap_group_oscore"), it is RECOMMENDED that an RS stores only one access token that:¶

  • is bound to a specific PoP key;¶

  • targets a specific audience; and¶

  • is related to a specific OSCORE group.¶

• As to access tokens issued in accordance with a different profile P that an RS may use in parallel with the profile defined in this document, it is RECOMMENDED that an RS stores only one access token that:¶

  • is issued in accordance with the profile P;¶

  • is bound to a specific PoP key;¶

  • targets a specific audience; and¶

  • is related to a specific secure association used by the client to protect communications with the RS.¶

In accordance with these recommendations, if an access token T_NEW does not differ in any of the respects above from an existing access token T_OLD stored at the RS, then T_NEW ought to supersede T_OLD by replacing the corresponding authorization information.¶

Not complying with these recommendations can additionally complicate (constrained) implementations of RSs, with respect to required storage and the validation of a protected request against the applicable, stored access tokens associated with the same client. That is, it increases the strain on an RS in determining the actual permissions of a client, e.g., if access tokens contradict each other and thus might lead the RS to enforce wrong permissions. Moreover, if one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection.¶

12.1. ACE Profiles Registry

IANA is asked to add the following entry to the "ACE Profiles" registry [IANA.ACE.Profiles] within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.¶

• Name: coap_group_oscore¶

• Description: Profile to secure communications between constrained nodes using the Authentication and Authorization for Constrained Environments framework, by enabling authentication and fine-grained authorization of members of an OSCORE group that use a pre-established Group OSCORE Security Context to communicate with Group OSCORE.¶

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

• Reference: [RFC-XXXX]¶

12.2. OAuth Parameters Registry

IANA is asked to add the following entries to the "OAuth Parameters" registry [IANA.OAuth.Parameters] within the "OAuth Parameters" registry group.¶

• Name: context_id¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

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

• Name: salt_input¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

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

• Name: client_cred_verify¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

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

• Name: client_cred_verify_mac¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

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

12.3. OAuth Parameters CBOR Mappings Registry

IANA is asked to add the following entries to the "OAuth Parameters CBOR Mappings" registry [IANA.OAuth.Parameters.CBOR.Mappings] within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in [RFC9200].¶

• Name: context_id¶

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

• Value Type: byte string¶

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

• Original Specification: [RFC-XXXX]¶

• Name: salt_input¶

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

• Value Type: byte string¶

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

• Original Specification: [RFC-XXXX]¶

• Name: client_cred_verify¶

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

• Value Type: byte string¶

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

• Original Specification: [RFC-XXXX]¶

• Name: client_cred_verify_mac¶

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

• Value Type: byte string¶

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

• Original Specification: [RFC-XXXX]¶

12.4. JSON Web Token Claims Registry

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

• Claim Name: context_id¶

• Claim Description: Client provided Context ID¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

• Claim Name: salt_input¶

• Claim Description: Client provided salt input¶

• Change Controller: IETF¶

• Reference: [RFC-XXXX]¶

12.5. CBOR Web Token (CWT) Claims Registry

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

• Claim Name: context_id¶

• Claim Description: Client provided Context ID¶

• JWT Claim Name: N/A¶

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

• Claim Value Type: byte string¶

• Change Controller: IETF¶

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

• Claim Name: salt_input¶

• Claim Description: Client provided salt input¶

• JWT Claim Name: N/A¶

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

• Claim Value Type: byte string¶

• Change Controller: IETF¶

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

12.6. TLS Exporter Label Registry

IANA is asked to register the following entry in the "TLS Exporter Labels" registry [IANA.TLS.Exporter.Labels] within the "Transport Layer Security (TLS) Parameters" registry group, which is defined in Section 6 of [RFC5705] and updated in Section 12 of [RFC8447].¶

• Value: EXPORTER-ACE-PoP-Input-Client-AS¶

• DTLS-OK: Y¶

• Recommended: N¶

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

13.1. Normative References

[I-D.ietf-ace-key-groupcomm-oscore]

Tiloca, M. and F. Palombini, "Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-21, 14 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-21>.

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

Tiloca, M. and G. Selander, "Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework", Work in Progress, Internet-Draft, draft-ietf-ace-workflow-and-params-07, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-workflow-and-params-07>.

[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-18, 10 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-18>.

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

Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and R. Höglund, "Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23 December 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-28>.

[IANA.ACE.Profiles]

IANA, "ACE Profiles", <https://www.iana.org/assignments/ace/ace.xhtml#ace-profiles>.

[IANA.CWT.Claims]

IANA, "CBOR Web Token (CWT) Claims", <https://www.iana.org/assignments/cwt/cwt.xhtml#claims-registry>.

[IANA.JSON.Web.Token.Claims]

IANA, "JSON Web Token Claims", <https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.

[IANA.OAuth.Parameters]

IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters>.

[IANA.OAuth.Parameters.CBOR.Mappings]

IANA, "OAuth Parameters CBOR Mappings", <https://www.iana.org/assignments/ace/ace.xhtml#oauth-parameters-cbor-mappings>.

[IANA.TLS.Exporter.Labels]

IANA, "TLS Exporter Labels", <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels>.

[NIST-800-56A]

Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography - NIST Special Publication 800-56A, Revision 3", April 2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf>.

[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>.

[RFC5246]

Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/rfc/rfc5246>.

[RFC5705]

Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/rfc/rfc5705>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[RFC6347]

Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/rfc/rfc6347>.

[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>.

[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>.

[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>.

[RFC7748]

Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/rfc/rfc7748>.

[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>.

[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>.

[RFC8447]

Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/rfc/rfc8447>.

[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>.

[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>.

13.2. Informative References

[I-D.ietf-ace-edhoc-oscore-profile]

Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund, "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-edhoc-oscore-profile-10, 1 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-10>.

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

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

[I-D.tiloca-core-oscore-discovery]

Tiloca, M., Amsüss, C., and P. Van der Stok, "Discovery of OSCORE Groups with the CoRE Resource Directory", Work in Progress, Internet-Draft, draft-tiloca-core-oscore-discovery-19, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-tiloca-core-oscore-discovery-19>.

[NIST-800-207]

Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture - NIST Special Publication 800-207", August 2020, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf>.

[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>.

[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>.

[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>.

[RFC9202]

Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", RFC 9202, DOI 10.17487/RFC9202, August 2022, <https://www.rfc-editor.org/rfc/rfc9202>.

[RFC9431]

Sengul, C. and A. Kirby, "Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9431, DOI 10.17487/RFC9431, July 2023, <https://www.rfc-editor.org/rfc/rfc9431>.

[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>.

C.1. Version -06 to -07

• It is RECOMMENDED to use the OSCORE Group Manager defined in draft-ietf-ace-key-groupcomm-oscore.¶

• Major simplification in associating the access token with other information.¶

• Defined dynamic update of access rights through token series.¶

• Clarifications:¶

  • Processing of the access token at the RS.¶

  • The RS binds the access token to a specific Recipient Context.¶

  • Achieving proof of possession.¶

  • Details on proof of group membership.¶

  • Timing and consistency of group joining.¶

  • Latest group joining for the RS.¶

• Moved overview text about enforced access control to the appropriate subsection.¶

• Added references to IANA registries.¶

• Editorial improvements.¶

C.2. Version -05 to -06

• Replaced "GID" with "Gid".¶

• Mentioned revised semantics of the 'ace_profile' parameter.¶

• Added registrations to the "JSON Web Token Claims" IANA registry.¶

• Minor clarifications and editorial improvements.¶

C.3. Version -04 to -05

• Consistent mentioning of the optional presence of the PoP evidence in the access token request.¶

• Guidelines on updating the quartet (GID, SaltInput, AuthCred, AuthCredGM) at the RS when a client obtains a new Sender ID.¶

• Clarifications and editorial improvements.¶

C.4. Version -03 to -04

• Required that 'cnf' in the access token includes exactly what C uploaded to the Group Manager.¶

• Made the PoP evidence in the access token request optional.¶

• Better example value for audience, when indicating the profile to use.¶

• Placeholder: possible use of the 'ace_profile' parameter with extended semantics, for C to select the right profile.¶

• Suggested value ranges for codepoints to register.¶

• Aligned CBOR abbreviations to those used in other documents.¶

• Editorial fixes and improvements.¶

C.5. Version -02 to -03

• Lowercase "client", "resource server", "authorization server", and "access token".¶

• Consistent update of section numbers for external references.¶

• Mentioned that this profile can also use the ACE alternative workflow.¶

• Clarified that the client may ask for a new access token after the old one becomes invalid.¶

• Enforced uniqueness pre-requirements on the client's group membership before requesting an access token.¶

• Added checks on uniqueness of clients' group membership at the RS.¶

• Clarified the process of access right verification.¶

• Added fine-grained recommendations on storing multiple access tokens bound to the same PoP key.¶

• Added guidelines on using multiple profiles.¶

• Fixes in the IANA considerations.¶

• Editorial fixes and improvements.¶

C.6. Version -01 to -02

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

• Renamed the claim 'contextId_input' to 'context_id'.¶

• Revised examples.¶

• Placeholders and early direction for dynamic update of access rights.¶

• Added text on storing multiple access tokens per PoP key on the RS.¶

• Fixes in the IANA considerations.¶

• Editorial fixes and improvements.¶

C.7. Version -00 to -01

• Deleting an access token does not delete the Group OSCORE Security Context.¶

• Distinct computation of the PoP input when C and the AS use (D)TLS 1.2 or 1.3.¶

• Revised computation of the PoP input when C and the AS use OSCORE.¶

• Revised computation of the PoP evidence when the OSCORE group is a pairwise-only group.¶

• Clarified requirements on the AS for verifying the PoP evidence.¶

• Renamed the TLS Exporter Label for computing the PoP input.¶

• Editorial fixes and improvements.¶