]> RISE AB

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

Ericsson AB

Torshamnsgatan 23 Kista 164 40 Sweden goran.selander@ericsson.com

Security ACE Working Group Internet-Draft This document updates the Authentication and Authorization for Constrained Environments (ACE) framework, for which it defines a method to enforce bidirectional access control by means of a single access token. Therefore, this document updates RFC 9200. 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 The Authentication and Authorization for Constrained Environments (ACE) framework defines an architecture to enforce access control for constrained devices. A client (C) requests an assertion of granted permissions from an authorization server (AS) in the form of an access token, then uploads the access token to the target resource server (RS), and finally accesses protected resources at the RS according to the permissions specified in the access token. The ACE framework has as main building blocks the OAuth 2.0 framework , the Constrained Application Protocol (CoAP) for message transfer, Concise Binary Object Representation (CBOR) for compact encoding, and CBOR Object Signing and Encryption (COSE) for self-contained protection of access tokens. Separate profile documents define in detail how the participants in the ACE architecture communicate, especially as to the security protocols that they use. Profiles of ACE include, for instance, those defined in , , , , and In some deployments using the ACE framework, two devices DEV1 and DEV2 might wish to access each other's protected resources. That is, DEV1 wishes to access protected resources hosted at DEV2 and DEV2 wishes to access protected resources hosted at DEV1. In such a case, bidirectional access control can clearly be achieved by means of two separate access tokens, each of which is used to enforce access control in one direction. That is:

• A first access token is requested by and issued to DEV1, for accessing protected resources at DEV2. With respect to this access token, DEV1 is an ACE client, while DEV2 is an ACE RS.
• A second access token is requested by and issued to DEV2, for accessing protected resources at DEV1. With respect to this access token, DEV2 is an ACE client, while DEV1 is an ACE RS.

The two access tokens have to be separately requested and handled by DEV1 and DEV2, separately uploaded at DEV1 and DEV2, and separately managed by the AS that has issued them (e.g., for providing token introspection, retiring access tokens when they become invalid, or notifying about early token revocation ). While this model results in a clean split between the two directions of access control, it also yields substantial interactions and communication overhead for both DEV1 and DEV2. Therefore, it can be desirable to achieve the same bidirectional access control without such downsides, by means of a single access token that is requested by and issued to a single device. This document enables that by updating as follows:

• It defines additional parameters and encodings for the OAuth 2.0 token endpoint at the AS (see ). These parameters include:
  • "rev_audience", used by C to provide the AS with an identifier of itself as the reverse audience, and by the AS to optionally confirm that identifier in a response to C. A corresponding access token claim, namely "rev_aud", is also defined in this document.
  • "rev_scope", used by C to ask the AS that the requested access token specifies additional access rights as the reverse scope, allowing the access token's audience to accordingly access protected resources at C. This parameter is also used by the AS to provide C with the access rights that are actually granted as the reverse scope to the access token's audience. A corresponding access token claim, namely "rev_scope", is also defined in this document.
• It defines a method for the ACE framework to enforce bidirectional access control by means of a single access token (see ), building on the two new parameters "rev_audience" and "rev_scope" as well as on the corresponding new access token claims "rev_aud" and "rev_scope".

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 the ACE framework as well as with the terms and concepts related to CBOR Web Tokens (CWTs) . 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). Readers are also expected to be familiar with the terms and concepts related to CoAP , Concise Data Definition Language (CDDL) , CBOR , and COSE . 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. Furthermore, this document uses the following term originally defined in .

• Token series: a set of access tokens, all of which are bound to the same proof-of-possession (PoP) key and are sequentially issued by the same AS for the same pair (client, audience) per the same profile of ACE. A token series ends when the latest access token of that token series becomes invalid (e.g., when it expires or gets revoked). Profiles of ACE can provide their extended and specialized definition, e.g., by further taking into account the public authentication credentials of C and the RS.

CBOR and CDDL are used in this document. CDDL predefined type names, especially bstr for CBOR byte strings and tstr for CBOR text strings, are used extensively in this document. Examples throughout this document are expressed in CBOR diagnostic notation as defined in 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'rev_audience' : "rs1", e'rev_scope_param' : h'00ff'} stands for {56 : "rs1", 57 : h'00ff'}. 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.

New ACE Parameters The rest of this section defines a number of additional parameters and encodings for the OAuth 2.0 token endpoint at the AS.

rev_audience The "rev_audience" parameter can be used in an access token request sent by C to the token endpoint at the AS (see ) as well as in an access token response sent as a reply by the AS (see ). In particular, the following applies:

• The "rev_audience" parameter is OPTIONAL in an access token request. The presence of this parameter indicates that C wishes the requested access token to specify additional access rights. These access rights are intended for the access token's audience to access protected resources at C. That is, C is the access token's reverse audience. This parameter specifies such reverse audience as a text string identifier of C. When the access token request is encoded in CBOR, the value of this parameter is encoded as a CBOR text string. When the access token request is encoded in JSON, the value of this parameter is encoded as a JSON string.
• The "rev_audience" parameter is OPTIONAL in an access token response. If present, it has the same meaning and encoding that it has in the access token request.

Fundamentally, this parameter has the same semantics of the "audience" parameter used in the ACE framework, with the difference that it conveys an identifier of C as a host of protected resources to access, according to the access rights that are granted as the reverse scope to the access token's audience. The use of this parameter is further detailed in .

rev_scope The "rev_scope" parameter can be used in an access token request sent by C to the token endpoint at the AS (see ) as well as in an access token response sent as a reply by the AS (see ). In particular, the following applies:

• The "rev_scope" parameter is OPTIONAL in an access token request. The presence of this parameter indicates that C wishes the requested access token to specify additional access rights. These access rights are intended for the access token's audience to access protected resources at C. That is, C is the access token's reverse audience. This parameter specifies such access rights as the reverse scope. When the access token request is encoded in CBOR, the value of this parameter is encoded as a CBOR text string or a CBOR byte string. When the access token request is encoded in JSON, the value of this parameter is encoded as a JSON string.
• The "rev_scope" parameter is OPTIONAL in an access token response. If present, this parameter specifies the access rights that the AS has actually granted as the reverse scope to the access token's audience, for accessing protected resources at C (i.e., at the access token's reverse audience).

Fundamentally, this parameter has the same semantics of the "scope" parameter used in the ACE framework, with the difference that it conveys the access rights that are requested/granted as the reverse scope for/to the access token's audience to access protected resources at the access token's reverse audience. The use of this parameter is further detailed in .

Bidirectional Access Control The rest of this document considers two devices DEV1 and DEV2 that wish to access each other's protected resources. Specifically, it defines a method that DEV1 and DEV2 can use to enforce bidirectional access control by means of a single access token. It is assumed that the access token is requested by and issued to DEV1 acting as an ACE client. The access token is intended to specify access rights concerning both the access of DEV1 to protected resources hosted at DEV2 and the access of DEV2 to protected resources hosted at DEV1. In particular:

• The access token expresses access rights according to which the requesting ACE client DEV1 can access protected resources hosted at the ACE RS DEV2. For this first direction of access control, the following applies:
  • The target DEV2 is specified by means of the "audience" parameter and the corresponding access token claim "aud".
  • The access rights are specified by means of the "scope" parameter and the corresponding access token claim "scope". The access rights granted to DEV1 are in accordance with the authorization policies configured for DEV2 that are evaluated by the AS to issue the access token.
  This is the original, primary direction of access control, over which the ACE client DEV1 that requests the access token wishes to obtain access rights for accessing protected resources at the ACE RS DEV2. This requires the ACE client DEV1 to act as a CoAP client and the ACE RS DEV2 to act as a CoAP server.
• The same access token can additionally express access rights according to which the ACE RS DEV2 can access protected resources hosted at the ACE client DEV1. For this second direction of access control, the following applies:
  • The target DEV1 is specified by means of the "rev_audience" parameter defined in and the corresponding access token claim "rev_aud" (see ).
  • The access rights are specified by means of the "rev_scope" parameter defined in and the corresponding access token claim "rev_scope" (see ). The access rights granted to DEV2 are in accordance with the authorization policies configured for DEV1 that are evaluated by the AS to issue the access token.
  This is the new, secondary direction of access control, over which the ACE client DEV1 that requests the access token also wishes that access rights are granted for the ACE RS DEV2 to access resources at DEV1. This requires the ACE client DEV1 to also act as a CoAP server and the ACE RS DEV2 to also act as a CoAP client.

Like for the original case with a single direction of access control, the access token is uploaded to the ACE RS DEV2, which processes the access token as per and according to the profile of ACE used by DEV1 and DEV2. The protocol workflow is detailed in the following and , for the case where only one authorization server or two authorization servers are involved, respectively.

Scenario with One Authorization Server This section considers the scenario shown in , comprising the devices DEV1 and DEV2 as well as a single authorization server AS. In particular, AS is configured with authorization policies for DEV1 and DEV2, which are evaluated to issue an access token that expresses access rights for accessing protected resources hosted at DEV1 and DEV2, respectively. Consistent with that, both devices DEV1 and DEV2 are registered at AS, with permissions to access protected resources at the other device. In the following, DEV1 acts as an ACE client and DEV2 acts as an ACE RS. That is, DEV1 requests from AS an access token that has DEV2 as the intended audience.

Bidirectional Access Control with One Authorization Server. | C | +----+ +---+ ]]>

Access Token Request As to the access token request that DEV1 sends to AS, the following applies:

• The "audience" and "scope" parameters are used as defined in , according to the profile of ACE used by DEV1 and DEV2. In particular, "audience" specifies an identifier of DEV2, while "scope" specifies access rights that DEV1 wishes to obtain for accessing protected resources at DEV2. That is, the two parameters pertain to the primary direction of access control.
• The "req_cnf" parameter defined in can be included. When present, it specifies the key that DEV1 wishes to bind to the requested access token.
• The "rev_audience" and "rev_scope" parameters defined in and can be included. In particular, "rev_audience" specifies an identifier of DEV1, while "rev_scope" specifies access rights that DEV1 wishes DEV2 to obtain for accessing protecting resources at DEV1. That is, the two parameters pertain to the secondary direction of access control.

If DEV1 wishes that the requested access token also provides DEV2 with access rights pertaining to the secondary direction of access control, then the access token request has to include at least one of the two parameters "rev_audience" and "rev_scope".

Access Token Response When receiving an access token request that includes at least one of the two parameters "rev_audience" and "rev_scope", AS processes it as defined in , with the following additions:

• If the access token request includes the "rev_scope" parameter but not the "rev_audience" parameter, then AS assumes that the identifier of DEV1 (i.e., the access token's reverse audience) is the default one, if any is defined.
• If the access token request includes the "rev_audience" parameter but not the "rev_scope" parameter, then AS assumes that the access rights requested as the reverse scope for DEV2 (i.e., the access token's audience) to access DEV1 are the default ones, if any are defined.
• AS checks whether the access rights requested as the reverse scope for DEV2 can be at least partially granted, in accordance with the configured authorization policies pertaining to the access from DEV2 to protected resources at DEV1. That is, AS performs the same evaluation that it would perform if DEV2 sent an access token request acting as an ACE client, with the intent to access protected resources at DEV1 that acts as an ACE RS. It is REQUIRED that such evaluation succeeds, in order for AS to issue an access token and reply to DEV1 with an access token response.

As to the access token response that AS sends to DEV1, the following applies:

• The "audience" and "scope" parameters are used as defined in and according to the profile of ACE used by DEV1 and DEV2. In particular, "audience" specifies an identifier of DEV2, while "scope" specifies the access rights that AS has granted to DEV1 for accessing protected resources at DEV2. The "scope" parameter has to be present in the access token response if:
  • It was present in the access token request and the access rights granted to DEV1 are different from the requested ones; or
  • It was not present in the access token request and the access rights granted to DEV1 are different from the default ones.
  If the "scope" parameter is not present in the access token response, then the granted access rights are those requested by the "scope" parameter in the access token request if present therein, or the default access rights otherwise.
• The "rs_cnf" parameter defined in can be included. When present, it specifies information about the public key that DEV2 uses to authenticate.
• The "rev_audience" parameter defined in can be included. When present, it specifies an identifier of DEV1 (i.e., the access token's reverse audience). If the "rev_audience" parameter is present in the access token response and it was also present in the access token request, then the parameter in the access token response MUST have the same value specified by the parameter in the access token request.
• The "rev_scope" parameter defined in can be included and specifies the access rights that AS has granted to DEV2 (i.e., the access token's audience) for accessing protected resources at DEV1 (i.e., the access token's reverse audience). The "rev_scope" parameter MUST be present in the access token response if:
  • It was present in the access token request and the access rights granted to DEV2 are different from the requested ones; or
  • It was not present in the access token request and the access rights granted to DEV2 are different from the default ones.
  If the "rev_scope" parameter is not present in the access token response, then the access rights granted to DEV2 are those requested by the "rev_scope" parameter in the access token request if present therein, or the default access rights otherwise.

The issued access token MUST include information about the reverse audience and reverse scope pertaining to the secondary direction of access control. In particular:

• The access token MUST contain a claim specifying the identifier of DEV1 (i.e., the access token's reverse audience). If the access token response includes the "rev_audience" parameter, then the claim specifies the same information conveyed by that parameter. Otherwise, the claim specifies the same information conveyed by the "rev_audience" parameter of the access token request if present therein, or the default identifier of DEV1 otherwise. When CWTs are used as access tokens, this information MUST be transported in the "rev_aud" claim registered in .
• The access token MUST contain a claim specifying the access rights that AS has granted to DEV2 (i.e., the access token's audience) for accessing protected resources at DEV1. If the access token response includes the "rev_scope" parameter, then the claim specifies the same information conveyed by that parameter. Otherwise, the claim specifies the same information conveyed by the "rev_scope" parameter of the access token request if present therein, or the default access rights for DEV2 to access DEV1 otherwise. When CWTs are used as access tokens, this information MUST be transported in the "rev_scope" claim registered in .

Scenario with Two Authorization Servers TBD

Access to Protected Resources As to the secure communication association between DEV1 and DEV2, its establishment and maintenance do not deviate from what is defined in the profile of ACE used by DEV1 and DEV2. Communications between DEV1 and DEV2 MUST rely on such secure communication association for both directions of access control, i.e., when DEV1 accesses protected resources at DEV2 and vice versa. After having received an access token response, DEV1 MUST maintain and enforce the information about the access rights granted to DEV2 and pertaining to the secondary direction of access control. In particular, DEV1 MUST prevent DEV2 from accessing protected resources at DEV1, in the case that access requests from DEV2 are not authorized as per the reverse scope specified by the issued access token, or after having purged the issued access token (e.g., following its expiration of revocation). As to maintaining and enforcing the information about the access rights granted to DEV1 and pertaining to the primary direction of access control, there is no deviation from what is defined in the ACE framework and the profile of ACE used by DEV1 and DEV2.

Practical Considerations When enforcing bidirectional access control by means of a single access token as defined in this document, the following considerations hold:

• The access token can be uploaded to the ACE RS DEV2 by the ACE client DEV1 per the original ACE workflow, or instead by the AS that has issued the access token per the Short Distribution Chain (SDC) workflow defined in .
• Since the access token is requested by the ACE client DEV1, only DEV1 can request for a new access token in the same token series, in order to dynamically update the access rights concerning its own access to protected resources hosted at DEV2 (on the primary direction of access control) and/or the access rights concerning the access of DEV2 to protected resources hosted at DEV1 (on the secondary direction of access control).

Security Considerations The same security considerations from the ACE framework apply to this document, together with those from the specific profile of ACE used. Editor's note: add more security considerations.

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

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

• Name: rev_audience
• Parameter Usage Location: token request and token response
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Name: rev_scope
• Parameter Usage Location: token request and token response
• 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.

• Name: rev_audience
• CBOR Key: TBD
• Value Type: text string
• Reference: [RFC-XXXX]
• Original Specification: [RFC-XXXX]

• Name: rev_scope
• CBOR Key: TBD
• Value Type: text string or 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.

• Claim Name: rev_aud
• Claim Description: The reverse audience of an access token
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Claim Name: rev_scope
• Claim Description: The reverse scope of an access token
• 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.

• Claim Name: rev_aud
• Claim Description: The reverse audience of an access token
• JWT Claim Name: rev_aud
• Claim Key: TBD (integer value between -256 and 255)
• Claim Value Type: text string
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

• Claim Name: rev_scope
• Claim Description: The reverse scope of an access token
• JWT Claim Name: rev_scope
• Claim Key: TBD (integer value between -256 and 255)
• Claim Value Type: text string or byte string
• Change Controller: IETF
• Reference: [RFC-XXXX, ]

References Normative References 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. 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. 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. IANA IANA IANA IANA 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 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. 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. 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 a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an authorization server to notify clients and resource servers (i.e., registered devices) about revoked access tokens. As specified in this document, the method allows clients and resource servers (RSs) to access a Token Revocation List (TRL) on the authorization server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on clients and RSs. 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 RISE AB Ericsson AB 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 that pertains to the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving the access token. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. 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 Concise Binary Object Representation (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.

CDDL Model

CDDL Model

Acknowledgments The authors sincerely thank and for their comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.