]> RISE AB

Isafjordsgatan 22 Kista 164 40 Kista Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 164 40 Kista Sweden rikard.hoglund@ri.se

Ericsson AB

Torshamnsgatan 23 Kista 164 40 Kista Sweden francesca.palombini@ericsson.com

Security ACE Working Group Internet-Draft This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information from the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving a message protected with Group OSCORE from the client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. Discussion Venues Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction A number of applications rely on a group communication model where a client can access a resource hosted at multiple resource servers at once, e.g., over IP multicast. Typical examples include switching of luminaires, control of actuators, and distribution of software updates. Secure communication in the group can be achieved by sharing a set of keying material, which is typically provided upon joining the group. For some of such applications, it could be acceptable to enforce access control in a straightforward fashion. That is, any client authorized to join the group, hence to obtain the group keying material, can also be implicitly authorized to perform any action at any resource hosted at any server in the group. An example of an application where such implicit authorization might serve well is a simple lighting scenario, where the lightbulbs are the servers and the user account on an app on the user's phone is the client. In this case, it might be fine to not require additional authorization evidence from any user account, if it is acceptable that any current group member is also authorized to switch on and off any light, or to check the status of any light. However, in different instances of such applications, the approach above is not desirable, as different group members are intended to have different access rights to resources hosted at other group members. For instance, enforcing access control in accordance with a more fine-grained approach is required in the two following use cases. As a first case, an application provides control of smart locks acting as servers in the group, where: a first type of client, e.g., a user account of a child, is allowed to only query the status of the smart locks; while a second type of client, e.g., a user account of a parent, is allowed to both query and change the status of the smart locks. Further similar applications concern the enforcement of different sets of permissions in groups with sensor/actuator devices, e.g., thermostats acting as servers. Also, some group members may even be intended as servers only. Hence, they must be prevented from acting as clients altogether and from accessing resources at other servers in the group, especially when attempting to perform non-safe operations. As a second case, building automation scenarios often rely on servers that, under different circumstances, enforce different levels of priority for processing received commands. For instance, BACnet deployments consider multiple classes of clients, e.g., a normal light switch (C1) and an emergency fire panel (C2). Then, a C1 client is not allowed to override a command from a C2 client, until the latter relinquishes control at its higher priority. That is: i) only C2 clients should be able to adjust the minimum required level of priority on the servers, so rightly locking out C1 clients if needed; and ii) when a server is set to accept only high-priority commands, only C2 clients should be able to perform such commands that are otherwise allowed also to C1 clients. Given the different maximum authority of different clients, fine-grained access control would effectively limit the execution of high- and emergency-priority commands only to devices that are in fact authorized to perform such actions. Besides, it would prevent a misconfigured or compromised device from initiating a high-priority command and lock out normal control. In the cases above, being a legitimate group member and storing the group keying material is not meant to imply any particular access rights. Instead, access control to the secure group communication channel and access control to the resource space provided by servers in the group should remain logically separated domains. This is aligned with the Zero Trust paradigm , which focuses on resource protection and builds on the premise that trust is never granted implicitly, but must be continually evaluated. In particular, Zero Trust protections involve "minimizing access to resources (such as data and compute resources and applications/services) to only those subjects and assets identified as needing access as well as continually authenticating and authorizing the identity and security posture of each access request." Furthermore, highlights how the Zero Trust goal is to "prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible", in order to "enforce least privileges needed to perform the action in the request." As a step in this direction, one can be tempted to introduce a different security group for each different set of access rights. However, this inconveniently results in additional keying material to distribute and manage. In particular, if the access rights pertaining to a node change, this requires evicting the node from the group, after which the node has to join a different group aligned with its new access rights. Moreover, the keying material of both groups would have to be renewed for their current members. Overall, this would have a non-negligible impact on operations and performance. Instead, a fine-grained yet flexible access control model can be enforced within the same group, by using the Authentication and Authorization for Constrained Environments (ACE) framework . That is, a client has to first obtain authorization credentials in the form of an access token and then upload it to the intended resource server(s) in the group, before accessing the target resources hosted at such resource server(s). The ACE framework delegates to separate profile documents how to secure communications between the client and the resource servers. However, each of the current profiles of ACE defined in relies on a security protocol that cannot be used to protect one-to-many group messages, for example sent over IP multicast. This document specifies the "coap_group_oscore" profile of the ACE framework, according to which a client uses the Constrained Application Protocol (CoAP) to communicate with one or multiple resource servers that are members of an application group and share a common set of resources. This profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) as the security protocol to protect messages exchanged between the client and the resource servers. Hence, it requires that both the client and the resource servers have previously joined the same OSCORE group. That is, this profile describes how access control is enforced for a client after it has joined an OSCORE group, to access resources hosted by other members of that group. The process for joining the OSCORE group through the respective Group Manager as defined in takes place before the process described in this document and is out of the scope of this profile. The client proves its authorization and access rights to the resource server(s) by using an access token bound to a key (the proof-of-possession key). This profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key used in the OSCORE group in question. Note that proof of possession is not achieved through a dedicated protocol element, but instead after the first message exchange protected with Group OSCORE. Furthermore, this profile provides proof of the client's membership to the OSCORE group, by binding the access token to information from the pre-established Group OSCORE Security Context, as well as to the client's authentication credential used in the group and including the client's public key. This allows the resource server(s) to verify the client's group membership upon reception of a message protected with Group OSCORE from that client. Object Security for Constrained RESTful Environments (OSCORE) specifies how to use CBOR Object Signing and Encryption (COSE) to secure CoAP messages. Group OSCORE builds on OSCORE to provide secure group communication and ensures source authentication: by means of digital signatures embedded in the protected message (when using the group mode); or by protecting a message with pairwise keying material derived from the asymmetric keys of the two peers exchanging the message (when using the pairwise mode).

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 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) , COSE , CoAP , OSCORE , and Group OSCORE . 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) , X.509 certificates , and C509 certificates . Members of an OSCORE group have an associated authentication credential in the format used within the group. As per , 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 , as well as in the OSCORE profile of ACE . The terminology for entities in the considered architecture is defined in OAuth 2.0 . 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 , 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" , 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 ).

Examples throughout this document are expressed in CBOR diagnostic notation as defined in and . 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 of . 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 of . Finally, please delete this note.

Protocol Overview This section provides an overview of this profile, i.e., of how to use the ACE framework for authentication and authorization when communications between a client and one or more resource servers are secured using Group OSCORE . Note that this profile of ACE describes how access control can be enforced for a node after it has joined an OSCORE group, to access resources hosted by other members in that group. In particular, the process of joining the OSCORE group through the respective Group Manager as defined in must take place before the process described in this document and is out of the scope of this profile. An overview of the protocol flow for this profile is shown in , where it is assumed that both the resource servers RS1 and RS2 are associated with the same authorization server AS. It is also assumed that the client C as well as RS1 and RS2 have previously joined an OSCORE group with Group Identifier (Gid) 0xabcd0000, and that they got assigned Sender ID (Sid) 0x00, 0x01, and 0x02 in the group, respectively. The names of messages coincide with those of when applicable. Messages in square brackets are optional.

Protocol Overview ] | | | | | | | | [<------ AS Request -------] | | | | Creation Hints | | | | | | | +-------- POST /token ----------------------------------------------->| | (aud: "RS1", Sid: 0x00, | | | | Gid: 0xabcd0000, ...) | | | | | | | |<---------------------------------------------- Access token T1 -----+ | | + Access Information | | | | | +----- POST /authz-info ------>| | | | (access_token: T1) | | | | | | | |<------- 2.01 Created --------+ | | | | | | +-------- POST /token ----------------------------------------------->| | (aud: "RS2", Sid: 0x00, | | | | Gid: 0xabcd0000, ...) | | | | | | | |<---------------------------------------------- Access token T2 -----+ | | + Access Information | | | | | +----- POST /authz-info ------------------>| | | (access_token: T2) | | | | | | | |<------ 2.01 Created ---------------------+ | | | | | +-- Group OSCORE Request --+-->| | | | (kid: 0x00, \ | | | | Gid: 0xabcd0000) \ | | | | `----------->| | | | | | | /proof of possession/ | | | | | |<--- Group OSCORE Response ---+ | | | (kid: 0x01) | | | | | | | /proof of possession/ | | | | | | | | | | | /Mutual authentication | | | between C and RS1/ | | | | | | | |<--- Group OSCORE Response ---------------+ | | (kid: 0x02) | | | | | | | /proof of possession/ | | | | | | | | | | | /Mutual authentication | | | between C and RS2/ | | | | | | | | ... | | | | | | | ]]>

Pre-Conditions Using Group OSCORE and this profile requires that both the client and the resource servers have previously 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 by using the approach defined in , which is also based on ACE. After the client and resource servers have joined the group, this profile provides access control for accessing resources on those resource servers, by securely communicating with Group OSCORE. As a pre-requisite for this profile, the client has to have successfully joined the OSCORE group where also the resource servers (RSs) are members. 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 .

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 . 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 ). 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. In the access token request to the AS, the client MUST include the Group Identifier of the OSCORE group, as well as 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 the 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 ). 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 . This document focuses on the former option (also shown in the example in ), 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 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 and of MAY alternatively be used, such as TLS or DTLS .

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 . When using this profile, the communication that C has with the authz-info endpoint is not protected. Editor's note: the above will have to be updated, once defined the dynamic update of access rights ( and ), in which case the access token is intended to be uploaded by means of a protected request to the authz-info endpoint. If the access token is valid, the RS replies to the POST request with a 2.01 (Created) response. Also, the RS associates the received access token with the Group OSCORE Security Context identified by the Group Identifier that is specified in the access token (see ). 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. After that, the RS stores the association between i) the authorization information from the access token; and ii) the Group Identifier of the OSCORE group together with the Sender ID and the authentication credential of the client in that group (see ). This binds the access token to the Group OSCORE Security Context of the OSCORE group. Finally, when the client communicates with the RS using the Group OSCORE Security Context, the RS verifies that the client is a legitimate member of the OSCORE group and especially the exact group member with the same Sender ID associated with the access token. This occurs when verifying a request protected with Group OSCORE, since the request includes the client's Sender ID and either it embeds a signature computed also over that Sender ID (if protected with the group mode), or it is protected by means of pairwise symmetric keying material derived from the asymmetric keys of the two peers (if protected with the pairwise mode). The above has considered an access token intended for a single RS. However, as discussed in , 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.

Secure Communication The client can send a CoAP request protected with Group OSCORE to the RS. This can be a unicast request targeting the RS , or a one-to-many group request (e.g., over IP multicast) 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 (e.g., by using the approach defined in ), unless it has a more recent Security Context that has been established in the group as a result of a group rekeying (see ). The RS may send a response back to the client, also protecting it with Group OSCORE.

Client-AS Communication This section details the access token request that the client sends to the token endpoint of the AS, as well as the related access token response. The access token MUST be bound to the public key of the client as proof-of-possession (PoP) key, which is included in the client's authentication credential specified in the 'cnf' claim of the access token.

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 .
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 (see ).
   • 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 (see ), or re-join a group thereby obtaining a new Sender ID in that group (see ).
   Finally, the client moves to Step 1.

C-to-AS: POST to Token Endpoint The Client-to-AS request is specified in . The client MUST send this POST request to the token endpoint over a secure channel that guarantees authentication, message integrity, and confidentiality. The POST request is formatted as the analogous Client-to-AS request in the OSCORE profile of ACE (see ), with the following additional parameters that MUST be included in the payload.

• 'context_id', defined in of this document. This parameter specifies the Gid, i.e., the ID Context of an OSCORE group that includes as members 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 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 . This parameter follows the syntax from , 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. 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) , X.509 certificates , and C509 certificates . Further formats may be available in the future and would be acceptable to use as long as they comply with the criteria compiled in . 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), by specifying it in the 'client_cred' parameter of a Join Request or of an Authentication Credential Update Request sent to the Group Manager (see Sections and of ). 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 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 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 or DTLS 1.2 , the PoP input is an exporter value computed as defined in , using the following inputs:
  • The exporter label "EXPORTER-ACE-PoP-Input-Client-AS" registered in 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 or DTLS 1.3 , the PoP input is an exporter value computed as defined in , using the following inputs:
  • The exporter label "EXPORTER-ACE-PoP-Input-Client-AS" registered in 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 , the PoP input is the output PRK of an HKDF-Extract step , 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: Then, the following holds.

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 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 . 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 ), 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 . 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 .

Example C-to-AS POST /token Request for an Access Token Bound to an Asymmetric Key

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

Example of client Authentication Credential as CWT Claims Set (CCS)

[ TODO: Specify how C requests a new access token that dynamically updates its access rights. (See for pre-requirements and a high-level direction) ]

'context_id' Parameter The 'context_id' parameter is an OPTIONAL parameter of the access token request message defined in . This parameter provides a value that the client wishes to use with the RS as a hint for a security context. Its exact content is profile specific.

'salt_input' Parameter The 'salt_input' parameter is an OPTIONAL parameter of the access token request message defined in . This parameter provides a value that the client wishes to use as part of a salt with the RS, for deriving cryptographic keying material. Its exact content is profile specific.

'client_cred_verify' Parameter The 'client_cred_verify' parameter is an OPTIONAL parameter of the access token request message defined in . This parameter provides a signature computed by the client to prove the possession of its own private key.

'client_cred_verify_mac' Parameter The 'client_cred_verify_mac' parameter is an OPTIONAL parameter of the access token request message defined in . This parameter provides a Message Authentication Code (MAC) computed by the client to prove the possession of its own private key.

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 neither the 'client_cred_verify' parameter nor the 'client_cred_verify_mac' parameter, 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 ).
• 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 ), 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 . Instead, if all verifications are successful, the AS replies to the client as defined in . In particular:

• The AS can signal that the use of Group OSCORE is REQUIRED for a specific 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. 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 'rs_cnf' parameter defined in . In general, the AS may not be aware of the authentication credentials (and public keys included thereof) that the RSs use in the OSCORE group. Also, 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, as defined in .
• According to this document, the AS includes the 'access_token' parameter specifying the issued access token in the access token response. The alternative Short Distribution Chain (SDC) workflow where the access token is uploaded by the AS directly to the RS is described in .

The AS MUST include the following information as metadata of the issued access token. The use of CBOR web tokens (CWT) as specified in is RECOMMENDED.

• The profile "coap_group_oscore". If the access token is a CWT, this is specified in the 'ace_profile' claim of the access token, as per .
• The salt input specified in the 'salt_input' parameter of the access token request. If the access token is a CWT, the content of the 'salt_input' parameter MUST be specified in the 'salt_input' claim of the access token defined in of this document.
• The Context ID input specified in the 'context_id' parameter of the access token request. If the access token is a CWT, the content of the 'context_id' parameter MUST be specified in the 'context_id' claim of the access token, defined in of this document.
• The authentication credential that the client uses in the OSCORE group, as specified in the 'req_cnf' parameter of the access token request (see ). If the access token is a CWT, the client's authentication credential MUST be specified in the 'cnf' claim, which follows the syntax from .

shows an example of such an AS response. The access token has been truncated for readability.

Example AS-to-C Access Token Response with the Group OSCORE Profile

shows an example CWT Claims Set, containing the client's public key in the group (as PoP key), as specified by the inner confirmation value in the 'cnf' claim.

Example CWT Claims Set

The same CWT Claims Set as in and encoded in CBOR is shown in , using the value abbreviations defined in and . The bytes in hexadecimal are reported in the first column, while their corresponding CBOR meaning is reported after the "#" sign on the second column, for easiness of readability. Editor's note: it should be checked (and in case fixed) that the values used below (which are not yet registered) are the final values registered by IANA.

Example CWT Claims Set Using CBOR Encoding

Update of Access Rights [ TODO: Specify how the AS issues an access token that dynamically updates the access rights of C. The following text outlines pre-requirements and a high-level direction. (This should be specified with content in the present section, as well as in and ). At the moment, this profile does not support the dynamic update of access rights for the client like other transport profiles of ACE do. This can be enabled by building on concepts defined in :

• "Token series" - In this profile, it would be specialized as a set of consecutive access tokens issued by the AS for the pair (C, AUD), where C is the client whose public authentication credential is bound to those access tokens, while AUD is the audience for which C requests those access tokens.
• "token_series_id" - This new parameter is defined in , as intended to be used in the access token request/response exchange between C and the AS. This parameter is meant to specify the unique identifier of a token series. A new, corresponding claim to include in access tokens is also defined in .

At a high-level, the above can enable the dynamic update of access rights as follows:

• Each access token in a token series includes the claim "token_series_id", with value the identifier of the token series that the access token belongs to.
• When issuing the first access token in a token series, the AS includes the parameter "token_series_id" in the access token response to the client, with value the identifier of the token series that the access token belongs to.
• When C requests from the AS an access token that dynamically updates its current access rights to access protected resources at the same audience, C sends to the AS an access token request such that:
  • It includes the parameter "token_series_id", with value the identifier of the token series for which the new access token is requested.
  • It does not include the parameters "context_id", "salt_input", and "client_cred_verify" or "client_cred_verify_mac".
• If the AS issues the new access token that dynamically updates the access rights of C, then the access token includes the claim "token_series_id", with value the identifier of the same token series for which the access token has been issued.

When receiving the new access token, the RS uses the value of the claim "token_series_id", and identifies the stored old access token that has to be superseded by the new one, as both belonging to the same token series. ]

'context_id' Claim The 'context_id' claim provides a value that the client requesting the access token wishes to use with the RS, as a hint for a security context. This claim specifies the value of the Context ID input, encoded as a CBOR byte string.

'salt_input' Claim The 'salt_input' claim provides a value that the client requesting the access token wishes to use as a part of a salt with the RS, e.g., for deriving cryptographic material. This claim specifies the value of the salt input, encoded as a CBOR byte string.

Client-RS Communication This section details the POST request and response to the authz-info endpoint between the client and the RS. The proof of possession required to bind the access token to the client is explicitly performed when the RS receives and verifies a request from the client protected with Group OSCORE, either with the group mode (see ) or with the pairwise mode (see ). In particular, the RS uses the client's public key bound to the access token, either when verifying the signature of the request (if protected with the group mode), or when verifying the request as integrity-protected with pairwise keying material derived from the two peers' authentication credentials and asymmetric keys (if protected with the pairwise mode). In either case, the RS also authenticates the client. Similarly, when receiving a protected response from the RS, the client uses the RS's public key either when verifying the signature of the response (if protected with the group mode), or when verifying the response as integrity-protected with pairwise keying material derived from the two peers' authentication credentials and asymmetric keys (if protected with the pairwise mode). In either case, the client also authenticates the RS. Mutual authentication is only achieved after the client has successfully verified the protected response from the RS. Therefore, an attacker using a stolen access token cannot generate a valid Group OSCORE message as protected through the client's private key, and thus cannot prove possession of the PoP key bound to the access token. Also, if a client legitimately owns an access token but has not joined the OSCORE group, it cannot generate a valid Group OSCORE message, as it does not store the necessary keying material shared among the group members. Furthermore, a client C1 is supposed to obtain a valid access token from the AS, as specifying its own authentication credential (and the public key included thereof) associated with its own private key used in the OSCORE group, together with its own Sender ID in that OSCORE group (see ). This allows the RS receiving the access token to verify with the Group Manager of that OSCORE group whether such a client indeed has that Sender ID and uses that authentication credential in the OSCORE group. As a consequence, a different client C2, also member of the same OSCORE group, is not able to impersonate C1 by: i) getting a valid access token, specifying the Sender ID of C1 and a different (made-up) authentication credential; ii) successfully uploading the access token to the RS; and then iii) attempting to communicate using Group OSCORE and impersonating C1, while also blaming C1 for the consequences of the interaction with the RS.

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 .

RS-to-C: 2.01 (Created) The RS MUST verify the validity of the access token as defined in , with the following additions.

• The RS checks that the claims 'context_id', 'salt_input', and 'cnf' are included in the access token. If any of these claims are missing or malformed, the RS MUST consider the access token invalid and MUST reply to the client 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 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 group G has GID* as current Gid.
  • The audience targeted by the access token is consistent with using the group G for accessing protected resources hosted by the RS.
  If no such group is found, the RS MUST consider the access token invalid and MUST reply to the client 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 (see ). 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 case 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 hold, 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 associates the authorization information from the access token with the Group OSCORE Security Context of the OSCORE group G*. In particular, the RS associates the authorization information from the access token with the quartet (GID, SaltInput, AuthCred, AuthCredGM), where:

• Gid is the Group Identifier of G* (i.e., GID*).
• SaltInput is the Sender ID that the client uses in G* (i.e., SID*).
• AuthCred is the authentication credential that the client uses in G* (i.e., AUTH_CRED_C*).
• AuthCredGM is the authentication credential of the Group Manager responsible for G* (see ).

The RS MUST keep this association up-to-date over time, as the quartet (GID, SaltInput, AuthCred, AuthCredGM) associated with the access token might change. In particular:

• If the OSCORE group is rekeyed (see and ), the Group Identifier also changes in the group and the new one replaces the current 'GID' value in the quartet (Gid, SaltInput, AuthCred, AuthCredGM).
• If the client requests and obtains a new OSCORE Sender ID from the Group Manager (see and ), the new Sender ID replaces the current 'SaltInput' value in the quartet (GID, SaltInput, AuthCred, AuthCredGM). Among the quartets corresponding to access tokens that are associated with a given Group OSCORE Security Context, the RS can always identify the correct quartet to update. For example, the RS can leverage the triple (GID, AuthCred, AuthCredGM) that played a role in the successful decryption and verification of a request protected with Group OSCORE and sent by the client with the newly obtained Sender ID.
• If the Group Manager of the OSCORE group changes its authentication credential, the new authentication credential of the Group Manager replaces the current 'AuthCredGM' value in the quartet (Gid, SaltInput, AuthCred, AuthCredGM). In order to obtain the latest authentication credential of the Group Manager, the RS can re-join the group (see ) or send a dedicated request to the Group Manager (see ).

As defined in , 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. Finally, the RS MUST send a 2.01 (Created) response to the client, as defined in .

Client-RS Secure Communication When previously joining the OSCORE group, both the client and the RS have already established the related Group OSCORE Security Context to securely communicate as group members. Therefore, they can simply start to securely communicate using Group OSCORE, without deriving any additional keying material or security association. If either of the client or the RS deletes an access token (e.g., when the access token has expired or has been revoked), it MUST NOT delete the related Group OSCORE Security Context. The client MAY request a new access token from the AS, to be uploaded to the RS for re-enabling access to protected resources for the client.

Client Side After having received the 2.01 (Created) response from the RS, following the POST request to the authz-info endpoint, the client can start communicating with the RS, by sending a request protected with Group OSCORE . When communicating with the RS to access the resources as specified by the authorization information, the client MUST use the Group OSCORE Security Context of the pertinent OSCORE group, whose Gid was specified in the 'context_id' parameter of the access token request.

Resource Server Side After successful validation of the access token as defined in and after having sent the 2.01 (Created) response, the RS can start to communicate with the client using Group OSCORE . When processing an incoming request protected with Group OSCORE, the RS MUST consider as the client's valid authentication credential only the one associated with the stored access token. As defined in , 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. For every incoming request, if Group OSCORE verification succeeds, the verification of access rights is performed as described in . If the RS receives a request protected with a Group OSCORE Security Context CTX, the target resource requires authorization, and the RS does not store a valid access token related to CTX, then the RS MUST reply with a 4.01 (Unauthorized) error response protected with CTX.

Update of Access Rights [ TODO: Specify the processing on the RS when receiving an access token that dynamically updates the access rights of C. (See for pre-requirements and a high-level direction) ]

Access Rights Verification The RS MUST follow the procedures defined in . If an RS receives a request protected with Group OSCORE from a client, the RS processes the request according to . 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 Group OSCORE Security Context. In particular, the RS retrieves the access token associated with the quartet (Gid, SaltInput, AuthCred, AuthCredGM), where:

• Gid is the Group Identifier of the OSCORE group, which is specified in the 'kid context' parameter of the CoAP OSCORE option in the received request. The RS maintains Gid in its Common Context within the Group OSCORE Security Context associated with the OSCORE group (see ).
• SaltInput is the Sender ID that the client has in the OSCORE group, which is specified in the 'kid' parameter of the CoAP OSCORE option in the received request. The RS maintains SaltInput in its Recipient Context associated with the client, within the Group OSCORE Security Context associated with the OSCORE group (see ).
• AuthCred is the authentication credential that the client uses in the OSCORE group. The RS maintains AuthCred in its Recipient Context associated with the client, within the Group OSCORE Security Context associated with the OSCORE group (see ).
• AuthCredGM is the authentication credential of the Group Manager responsible for the OSCORE group. The RS maintains AuthCredGM in its Common Context within the Group OSCORE Security Context associated with the OSCORE group (see ).

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.

Storing Multiple Access Tokens per PoP Key According to , 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 ). 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 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 . 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 .
  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 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.

Change of Client's Authentication Credential in the Group During its membership in the OSCORE group, the client might change the authentication credential that it uses in the group. When this happens, the client uploads the new authentication credential to the Group Manager, as defined in . After that, in order to continue communicating with the RS, the client MUST perform the following actions.

1. The client requests a new access token T_NEW to the AS, as defined in . In particular, when sending the access token request as defined in , the client specifies:
   • The current Group Identifier of the OSCORE group, as the value of the 'context_id' parameter.
   • The current Sender ID that it has in the OSCORE group, as the value of the 'salt_input' parameter.
   • The new authentication credential that it uses in the OSCORE group, as the inner confirmation value of the 'req_cnf' parameter.
   • Optionally, the proof-of-possession (PoP) evidence corresponding to the public key of the new authentication credential, as the value of the 'client_cred_verify' or 'client_cred_verify_mac' parameter. The possible omission of the PoP evidence is based on the same criteria that are defined in .
2. After receiving the access token response from the AS (see ), the client performs with the RS the same exchanges that are defined in .

When receiving the new access token T_NEW, the RS performs the same steps defined in , with the following addition in case the new access token is successfully verified and stored:

• The RS deletes any stored access token T_OLD such that the associated quartet (Gid, SaltInput, AuthCred, AuthCredGM) differs from the same quartet associated with T_NEW only as to the value of AuthCred.

Secure Communication with the AS As specified in the ACE framework (see Sections and of ), the requesting entity (client and/or RS) and the AS communicate via the token or introspect endpoint. The use of CoAP and OSCORE for this communication is RECOMMENDED in this profile. Other protocols fulfilling the security requirements defined in Sections and of (such as HTTP and DTLS or TLS) MAY be used instead. If OSCORE is used, the requesting entity and the AS are expected to have a pre-established Security Context in place. How this Security Context is established is out of the scope of this profile. Furthermore, the requesting entity and the AS communicate using OSCORE through the token endpoint as specified in and through the introspect endpoint as specified in .

Discarding the Security Context As members of an OSCORE group, the client and the RS may independently leave the group or be forced to, e.g., if compromised or suspected to be so. Upon leaving the OSCORE group, the client or RS also discards the Group OSCORE Security Context, which may anyway be renewed by the Group Manager through a group rekeying process (see ). The client or RS can acquire a new Group OSCORE Security Context by re-joining the OSCORE group, e.g., by using the approach defined in . In such a case, the client SHOULD request a new access token to be uploaded to the RS.

Guidelines on Using Multiple Profiles When using the profile defined in this document, access tokens are to be bound to a Group OSCORE Security Context, which is used to protect communications between the client and the RS(s) in the targeted audience by using the security protocol Group OSCORE. After having obtained an access token T1 for this profile and uploaded it to the RS (RSs) pertaining to the targeted audience, the client might want to establish a separate, pairwise OSCORE association with that RS (with one RS among those RSs). In order to do that, the client can ask the AS for a different access token T2 intended for that RS (for one RS among those RSs), as per the OSCORE profile defined in . Since the ACE framework does not allow the client to negotiate with the AS the profile to use, the client has instead to choose the use of the OSCORE profile, and to explicitly indicate it to the AS when requesting T2. To this end, the client could indicate its wish for an access token aligned with the Group OSCORE profile or with the OSCORE profile, by specifying one of two different audiences in the 'audience' parameter of the access token request to the AS. Assuming a proper configuration of the access policies at the AS, this is still conducive to a consistent evaluation of what is specified in the 'scope' parameter of the access token request against the access policies at the AS. For example, an RS registered as "rs1" at the AS can be associated with two audiences:

• "rs1_gp_osc", which the client can use to request an access token for the Group OSCORE profile and targeting (also) that RS. That is, the client specifies this audience when requesting the access token T1.
• "rs1_osc", which the client can use to request an access token for the OSCORE profile and targeting only that RS. That is, the client specifies this audience when requesting the access token T2.

Alternatively, the client could provide the AS with an explicit indication of the profile to use, according to which the AS is requested to issue an access token. For example, the client can rely on the 'ace_profile' parameter of the access token request, aligned with its revised semantics as specified in . Note that an RS has to be able to store at least one access token per PoP key. When specifically considering the Group OSCORE profile and the OSCORE profile, the RS can always store both corresponding access tokens T1 and T2, since they are always bound to different PoP keys. That is:

• In the Group OSCORE profile, the PoP key is the client's public key, which is included in the client's authentication credential specified in the 'cnf' claim of the access token.
• In the OSCORE profile, the PoP key is fundamentally an OSCORE Master Secret, which is specified within the OSCORE_Input_Material object of the 'cnf' claim of the access token.

The same approaches discussed above can be used in case the profile used for the access token T2 is instead the EDHOC and OSCORE profile defined in . In such a case, the same PoP key might be bound to both T1 and T2, i.e., if the client's public key is included both in the authentication credential that the client uses in the OSCORE group and in the authentication credential that the client uses as CRED_I (CRED_R) when running the EDHOC protocol in the forward (reverse) message flow (see ). provides considerations and recommendations on storing multiple access tokens per PoP key when using the Group OSCORE profile, also in parallel with alternative profiles.

CBOR Mappings The new parameters defined in this document MUST be mapped to CBOR types as specified in , using the given integer abbreviation for the map key. CBOR Mappings for New Parameters

Parameter name	CBOR Key	Value Type
context_id	TBD	byte string
salt_input	TBD	byte string
client_cred_verify	TBD	byte string
client_cred_verify_mac	TBD	byte string

The new claims defined in this document MUST be mapped to CBOR types as specified in , using the given integer abbreviation for the map key. CBOR Mappings for New Claims

Claim name	CBOR Key	Value Type
context_id	TBD	byte string
salt_input	TBD	byte string

Security Considerations This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework . Thus, the general security considerations from the ACE framework also apply to this profile. The proof-of-possession (PoP) key bound to an access token is always an asymmetric key, i.e., the public key included in the authentication credential that the client uses in the OSCORE group. This means that the same shared secret is never used as PoP key with possible multiple RSs. Therefore, it is possible and safe for the AS to issue an access token for an audience that includes multiple RSs (i.e., a group-audience, see ). In such a case, as per , the AS has to ensure the integrity protection of the access token by protecting it through an asymmetric signature. In addition, the used group-audience has to correctly identify all the RSs that are intended recipients of the access token and for which the single scope specified in the access token applies. As a particular case, the audience can refer to the OSCORE group as a whole, if the access token is intended for all the RSs in that group. Furthermore, this document inherits the general security considerations about Group OSCORE , as to the specific use of Group OSCORE according to this profile. Group OSCORE is designed to secure point-to-point as well as point-to-multipoint communications, providing a secure binding between a single request and multiple corresponding responses. In particular, Group OSCORE fulfills the same security requirements of OSCORE. Group OSCORE ensures source authentication of messages both in group mode (see ) and in pairwise mode (see ). When protecting an outgoing message in group mode, the sender uses its private key to compute a digital signature that is embedded in the protected message. The group mode can be used to protect messages sent to multiple recipients (e.g., over IP multicast) or to a single recipient. When protecting an outgoing message in pairwise mode, the sender uses a pairwise symmetric key that is derived from the asymmetric keys of the two peers exchanging the message. The pairwise mode can be used to protect only messages intended for a single recipient.

Privacy Considerations This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework . Thus the general privacy considerations from the ACE framework also apply to this profile. As this profile uses Group OSCORE, the privacy considerations from apply to this document as well. An unprotected response to an unauthorized request may disclose information about the RS and/or its existing relationship with the client. It is advisable to include as little information as possible in an unencrypted response. However, since both the client and the RS share a Group OSCORE Security Context, unauthorized yet protected requests are followed by protected responses, which can thus include more detailed information. Although it may be encrypted, the access token is sent in the clear to the authz-info endpoint at the RS. Thus, if the client uses the same single access token from multiple locations with multiple resource servers, it can risk being tracked through the access token's value. Note that, even though communications are protected with Group OSCORE, some information might still leak, due to the observable size, source address, and destination address of exchanged messages.

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace "[RFC-XXXX]" with the RFC number of this document and delete this paragraph.

ACE Profiles Registry IANA is asked to add the following entry to the "ACE Profiles" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in .

• 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]

OAuth Parameters Registry IANA is asked to add the following entries to the "OAuth Parameters" registry within the "OAuth Parameters" registry group, following the procedure specified in .

• Name: context_id
• Parameter Usage Location: token request
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Name: salt_input
• Parameter Usage Location: token request
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Name: client_cred_verify
• Parameter Usage Location: token request
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Name: client_cred_verify_mac
• Parameter Usage Location: token request
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

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

• Name: context_id
• CBOR Key: TBD (value between 1 and 255)
• Value Type: byte string
• Reference: [RFC-XXXX, ]
• Original Specification: [RFC-XXXX]

• Name: salt_input
• CBOR Key: TBD (value between 1 and 255)
• Value Type: byte string
• Reference: [RFC-XXXX, ]
• Original Specification: [RFC-XXXX]

• Name: client_cred_verify
• CBOR Key: TBD (value between 1 and 255)
• Value Type: byte string
• Reference: [RFC-XXXX, ]
• Original Specification: [RFC-XXXX]

• Name: client_cred_verify_mac
• CBOR Key: TBD (value between 1 and 255)
• Value Type: byte string
• Reference: [RFC-XXXX, ]
• Original Specification: [RFC-XXXX]

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

• 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]

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

• 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, ]

• 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, ]

TLS Exporter Label Registry IANA is asked to add the following entry to the "TLS Exporter Label" registry within the "Transport Layer Security (TLS) Parameters" registry group, following the procedure specified in and updated in .

• Value: EXPORTER-ACE-PoP-Input-Client-AS
• DTLS-OK: Y
• Recommended: N
• Reference: [RFC-XXXX, ]

References Normative References IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments (ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References RISE AB Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280, common certificate profiles and is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is over the CBOR encoding instead of the DER encoding, avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 and the same reduced size compared to X.509. The document also specifies CBOR encoded data structures for certificate (signing) requests and certificate request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698; the TLSA selectors registry is extended to include C509 certificates. Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. RISE AB Ericsson AB This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based on Message Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low.

Profile Requirements This appendix lists the specifications of this profile based on the requirements of the ACE framework, as requested in .

• Optionally, define new methods for the client to discover the necessary permissions and AS for accessing a resource, different from the one proposed in : Not specified.
• Optionally, specify new grant types: Not specified.
• Optionally, define the use of client certificates as client credential type: Not specified.
• Specify the communication protocol the client and RS must use: CoAP.
• Specify the security protocol the client and RS must use to protect their communication: Group OSCORE, by using a pre-established Group OSCORE Security Context.
• Specify how the client and the RS mutually authenticate: Explicitly, by possession of a common Group OSCORE Security Context and by either: usage of digital signatures embedded in messages, if protected with the group mode of Group OSCORE; or protection of messages with the pairwise mode of Group OSCORE, by using pairwise symmetric keys derived from the asymmetric keys of the two peers exchanging the message. Note that mutual authentication is not completed before the client has verified a Group OSCORE response using the corresponding Group OSCORE Security Context.
• Specify the proof-of-possession protocol(s) and how to select one, if several are available. Also specify which key types (e.g., symmetric/asymmetric) are supported by a specific proof-of- possession protocol: Group OSCORE algorithms; asymmetric keys verified and distributed by a Group Manager.
• Specify a unique ace_profile identifier: coap_group_oscore.
• If introspection is supported, specify the communication and security protocol for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE).
• Specify the communication and security protocol for interactions between the client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE).
• Specify if/how the authz-info endpoint is protected, including how error responses are protected: Not protected.
• Optionally, define other methods of token transport than the authz-info endpoint: Not defined.

CDDL Model

CDDL model

Document Updates

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.

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.

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.

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.

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.

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.

Acknowledgments contributed as a co-author of initial versions of this document. The authors sincerely thank , , , , , , and for their comments and feedback. The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).