ACE Working Group                                            G. Selander
Internet-Draft                                         J. Preuß Mattsson
Intended status: Standards Track                                Ericsson
Expires: 23 April 2025                                         M. Tiloca
                                                              R. Höglund
                                                                    RISE
                                                         20 October 2024


   Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for
    Constrained Environments (OSCORE) Profile for Authentication and
            Authorization for Constrained Environments (ACE)
                 draft-ietf-ace-edhoc-oscore-profile-06

Abstract

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

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-
   profile/.

   Discussion of this document takes place on the Authentication and
   Authorization for Constrained Environments (ace) Working Group
   mailing list (mailto:ace@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/ace/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/ace/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ace-wg/ace-edhoc-oscore-profile.





Selander, et al.          Expires 23 April 2025                 [Page 1]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 23 April 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Client-AS Communication . . . . . . . . . . . . . . . . . . .  10
     3.1.  C-to-AS: POST to /token endpoint  . . . . . . . . . . . .  10
     3.2.  Token Series  . . . . . . . . . . . . . . . . . . . . . .  12
     3.3.  AS-to-C: Response . . . . . . . . . . . . . . . . . . . .  13
       3.3.1.  Access Token  . . . . . . . . . . . . . . . . . . . .  15
       3.3.2.  Processing in C . . . . . . . . . . . . . . . . . . .  17
       3.3.3.  Update of Access Rights . . . . . . . . . . . . . . .  17
     3.4.  EDHOC_Information . . . . . . . . . . . . . . . . . . . .  17
   4.  Client-RS Communication . . . . . . . . . . . . . . . . . . .  22
     4.1.  EAD items for Access Token and Session Identifier . . . .  23
     4.2.  EDHOC Session . . . . . . . . . . . . . . . . . . . . . .  24
     4.3.  Forward Message Flow  . . . . . . . . . . . . . . . . . .  25



Selander, et al.          Expires 23 April 2025                 [Page 2]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


       4.3.1.  EDHOC message_1 . . . . . . . . . . . . . . . . . . .  25
       4.3.2.  EDHOC message_2 . . . . . . . . . . . . . . . . . . .  25
       4.3.3.  EDHOC message_3 . . . . . . . . . . . . . . . . . . .  25
     4.4.  Reverse Message Flow  . . . . . . . . . . . . . . . . . .  26
       4.4.1.  Trigger Message . . . . . . . . . . . . . . . . . . .  27
       4.4.2.  EDHOC message_1 . . . . . . . . . . . . . . . . . . .  27
       4.4.3.  EDHOC message_2 . . . . . . . . . . . . . . . . . . .  27
       4.4.4.  EDHOC message_3 . . . . . . . . . . . . . . . . . . .  27
       4.4.5.  EDHOC message_4 . . . . . . . . . . . . . . . . . . .  27
     4.5.  OSCORE Security Context . . . . . . . . . . . . . . . . .  28
     4.6.  Update of Access Rights . . . . . . . . . . . . . . . . .  29
       4.6.1.  C-to-RS: POST to /authz-info endpoint . . . . . . . .  29
       4.6.2.  RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . .  30
     4.7.  Discarding the OSCORE Security Context  . . . . . . . . .  31
     4.8.  Establishing a New OSCORE Security Context  . . . . . . .  32
     4.9.  Access Rights Verification  . . . . . . . . . . . . . . .  32
     4.10. Access Token Invalidity . . . . . . . . . . . . . . . . .  33
   5.  Secure Communication with AS  . . . . . . . . . . . . . . . .  33
   6.  CWT Confirmation Methods  . . . . . . . . . . . . . . . . . .  33
     6.1.  Ordered Chain of X.509 Certificates . . . . . . . . . . .  33
     6.2.  Unordered Bag of X.509 Certificates . . . . . . . . . . .  34
     6.3.  Hash of an X.509 Certificate  . . . . . . . . . . . . . .  34
     6.4.  URI Pointing to an Ordered Chain of X.509 Certificates  .  34
     6.5.  Ordered Chain of C509 Certificates  . . . . . . . . . . .  34
     6.6.  Unordered Bag of C509 Certificates  . . . . . . . . . . .  34
     6.7.  Hash of a C509 Certificate  . . . . . . . . . . . . . . .  34
     6.8.  URI Pointing to an Ordered Chain of C509 Certificates . .  34
     6.9.  CWT Containing a COSE_Key . . . . . . . . . . . . . . . .  35
     6.10. CCS Containing a COSE_Key . . . . . . . . . . . . . . . .  35
   7.  JWT Confirmation Methods  . . . . . . . . . . . . . . . . . .  35
     7.1.  Ordered Chain of X.509 Certificates . . . . . . . . . . .  35
     7.2.  Unordered Bag of X.509 Certificates . . . . . . . . . . .  35
     7.3.  Hash of an X.509 Certificate  . . . . . . . . . . . . . .  35
     7.4.  URI Pointing to an Ordered Chain of X.509 Certificates  .  36
     7.5.  Ordered Chain of C509 Certificates  . . . . . . . . . . .  36
     7.6.  Unordered Bag of C509 Certificates  . . . . . . . . . . .  36
     7.7.  Hash of a C09 Certificate . . . . . . . . . . . . . . . .  36
     7.8.  URI Pointing to an Ordered Chain of C509 Certificates . .  36
     7.9.  CWT Containing a COSE_Key . . . . . . . . . . . . . . . .  37
     7.10. CCS Containing a COSE_Key . . . . . . . . . . . . . . . .  37
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  37
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  38
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  39
     10.1.  ACE Profiles Registry  . . . . . . . . . . . . . . . . .  39
     10.2.  OAuth Parameters Registry  . . . . . . . . . . . . . . .  39
     10.3.  OAuth Parameters CBOR Mappings Registry  . . . . . . . .  40
     10.4.  JSON Web Token Claims Registry . . . . . . . . . . . . .  40
     10.5.  CBOR Web Token (CWT) Claims Registry . . . . . . . . . .  40



Selander, et al.          Expires 23 April 2025                 [Page 3]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


     10.6.  JWT Confirmation Methods Registry  . . . . . . . . . . .  41
     10.7.  CWT Confirmation Methods Registry  . . . . . . . . . . .  43
     10.8.  EDHOC External Authorization Data Registry . . . . . . .  46
     10.9.  EDHOC Information Registry . . . . . . . . . . . . . . .  47
     10.10. Expert Review Instructions . . . . . . . . . . . . . . .  48
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  49
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  49
     11.2.  Informative References . . . . . . . . . . . . . . . . .  52
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  53
     A.1.  Workflow without Optimizations  . . . . . . . . . . . . .  55
     A.2.  Workflow with Optimizations . . . . . . . . . . . . . . .  59
   Appendix B.  Profile Requirements . . . . . . . . . . . . . . . .  61
   Appendix C.  CDDL Model . . . . . . . . . . . . . . . . . . . . .  62
   Appendix D.  Document Updates . . . . . . . . . . . . . . . . . .  63
     D.1.  Version -05 to -06  . . . . . . . . . . . . . . . . . . .  63
     D.2.  Version -04 to -05  . . . . . . . . . . . . . . . . . . .  64
     D.3.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  64
     D.4.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  65
     D.5.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  65
     D.6.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  65
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  66
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  66

1.  Introduction

   This document defines the "coap_edhoc_oscore" profile of the ACE-
   OAuth framework [RFC9200].  This profile addresses a "zero-touch"
   constrained setting where authenticated and authorized operations can
   be performed with low overhead without endpoint specific
   configurations.

   Like in the "coap_oscore" profile [RFC9203], also in this profile a
   client (C) and a resource server (RS) use the Constrained Application
   Protocol (CoAP) [RFC7252] to communicate, and Object Security for
   Constrained RESTful Environments (OSCORE) [RFC8613] to protect their
   communications, but this profile uses the Ephemeral Diffie-Hellman
   Over COSE (EDHOC) protocol [RFC9528] to establish the OSCORE Security
   Context.  The processing of requests for specific protected resources
   is identical to what is defined in the "coap_oscore" profile.

   When using this profile, C accesses protected resources hosted at RS
   with the use of an access token issued by a trusted authorization
   server (AS) and bound to an authentication credential of C.  This
   differs from the "coap_oscore" profile, where the access token is
   bound to a symmetric key used to derive the OSCORE Security Context.
   Whereas [RFC9200] recommends the use of CBOR Web Tokens (CWTs)
   [RFC8392] as access tokens, this profile requires it, see
   Section 3.3.1.



Selander, et al.          Expires 23 April 2025                 [Page 4]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   An authentication credential can be a raw public key, e.g., encoded
   as a CWT Claims Set (CCS, [RFC8392]); or a public key certificate,
   e.g., encoded as an X.509 certificate [RFC5280] or as a CBOR encoded
   X.509 certificate (C509, [I-D.ietf-cose-cbor-encoded-cert]); or a
   different type of data structure containing the public key of the
   peer in question.

   The ACE protocol establishes what those authentication credentials
   are, and may transport the actual authentication credentials by value
   or uniquely refer to them.  If an authentication credential is pre-
   provisioned or can be obtained over less constrained links, then it
   suffices that ACE provides a unique reference such as a certificate
   hash (e.g., by using the COSE header parameter "x5t", see [RFC9360]).
   This is in the same spirit as EDHOC, where the authentication
   credentials may be transported or referenced in the ID_CRED_x message
   fields (see Section 3.5.3 of [RFC9528]).

   In general, AS and RS are likely to have trusted access to each
   other's authentication credentials, since AS acts on behalf of RS as
   per the trust model of ACE.  Also, AS needs to have some information
   about C, including the relevant authentication credential, in order
   to identify C when it requests an access token and to determine what
   access rights it can be granted.  However, the authentication
   credential of C may potentially be conveyed (or uniquely referred to)
   within the request for access that C makes to AS.

   The establishment of an association between RS and AS in an ACE
   ecosystem is out of scope, but one solution is to build on the same
   primitives as used in this document, i.e., EDHOC for authentication
   and OSCORE for communication security, using for example
   [I-D.ietf-lake-authz] for onboarding RS with AS, and
   [I-D.ietf-ace-coap-est-oscore] for establishing a trust anchor in RS.
   A similar procedure can also be applied between C and AS for
   registering a client and for the establishment of a trust anchor.

1.1.  Terminology

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

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




Selander, et al.          Expires 23 April 2025                 [Page 5]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   RESTful terminology follows HTTP [RFC9110].

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

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

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

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

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

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

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

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

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




Selander, et al.          Expires 23 April 2025                 [Page 6]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


2.  Protocol Overview

   This section gives an overview of how to use the ACE framework
   [RFC9200] together with the lightweight authenticated key exchange
   protocol EDHOC [RFC9528].  By doing so, the client (C) and the
   resource server (RS) generate an OSCORE Security Context [RFC8613]
   associated with authorization information, and use that security
   context to protect their communications.  The parameters needed by C
   to negotiate the use of this profile with the authorization server
   (AS), as well as the OSCORE setup process, are described in detail in
   the following sections.

   RS maintains a collection of authentication credentials.  These are
   associated with OSCORE Security Contexts and with authorization
   information for all clients that RS is communicating with.  The
   authorization information is used to enforce policies for processing
   requests from those clients.

   The ACE framework describes how integrity protected authorization
   information propagates from AS to RS.  This profile describes how C
   requests from AS an access token, including authorization
   information, for the resources it wants to access on RS, by sending
   an access token request to the /token endpoint at AS, as specified in
   Section 5.8 of [RFC9200].

   If the request is granted, then AS may send back an access token in a
   response to C, or upload the access token directly to RS as described
   in the alternative workflow defined in
   [I-D.ietf-ace-workflow-and-params].  The latter is not detailed
   further here.

   After that, C and RS executes the EDHOC protocol.  C uses the
   authentication credential of RS provided by AS.  If C has retrieved
   an access token, it is included as External Authorization Data (EAD)
   in the EDHOC protocol, see Section 3.8 of [RFC9528].  RS uses the
   authentication credential of C bound to and provided in the access
   token.  The EDHOC session is detailed in Section 4.2.

   If C and RS successfully complete the EDHOC protocol and the
   validations of authentication credentials, they are mutually
   authenticated and derive the OSCORE Security Context as per
   Appendix A.1 of [RFC9528].

   Figure 1 outlines an example of the message flow.  A more detailed
   description of the message flow is shown in Appendix A.1.






Selander, et al.          Expires 23 April 2025                 [Page 7]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   From then on, C effectively gains authorized and secure access to
   protected resources on RS with the established OSCORE Security
   Context, for as long as there is a valid access token.  When RS
   receives a request from C protected with an OSCORE Security Context
   derived from an EDHOC session implementing this profile, then that
   OSCORE Security Context is used to retrieve the uniquely associated
   access token determining the access rights of C.

   The OSCORE Security Context is discarded when an access token
   (whether the same or a different one) is used to successfully derive
   a new OSCORE Security Context for C.

      C                            RS                       AS
      |                            |                         |
      | <==== Mutual authentication and secure channel ====> |
      |                            |                         |
      +-------- POST /token  ------------------------------->|
      |                            |                         |
      |<--------------------------------- Access Token ------+
      |                               + Access Information   |
      |                            |                         |
      +------- POST /edhoc  ------>|                         |
      |     (EDHOC message_1)      |                         |
      |                            |                         |
      |<------ 2.04 Changed -------+                         |
      |     (EDHOC message_2)      |                         |
      |                            |                         |
   / Derivation of OSCORE          |                         |
   Security Context /              |                         |
      |                            |                         |
      +------- POST /edhoc  ------>|                         |
      |   (EDHOC message_3 with    |                         |
      |   access_token in EAD_3)   |                         |
      |                            |                         |
      |                / Derivation of OSCORE                |
      |                  Security Context /                  |
      |                            |                         |
      +----- OSCORE Request ------>|                         |
      |                            |                         |
      |<---- OSCORE Response ------|                         |
      |                            |                         |

      Figure 1: Protocol Outline using the EDHOC Forward Message Flow.

   While the OSCORE Security Context and access token are valid, C can
   contact AS to request an update of its access rights, by sending a
   similar request as described above to the /token endpoint.  This
   request also includes a "session identifier" (see Section 3.4)



Selander, et al.          Expires 23 April 2025                 [Page 8]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   provided by AS in the response to the initial access request, which
   allows AS to retrieve the data it previously shared with C.  The
   session identifier is assigned by AS and used to identify a series of
   access tokens, called a "token series" (see Section 3.2).

   If C has retrieved an access token for updating its access rights
   belonging to the same token series, then it transfers the access
   token to RS using the /authz-info endpoint as specified in
   Section 5.10 of [RFC9200] where the CoAP exchange is protected by the
   previously established OSCORE security context, see Section 4.6.  If
   the access token is valid, RS replies to the request with a 2.01
   (Created) response.

   Upon successful update of access rights, the new issued access token
   becomes the latest in its token series, but the session identifier
   remains the same.  When the latest access token of a token series
   becomes invalid (e.g., when it expires or gets revoked), that token
   series ends.

   Figure 2 outlines the message flow for updating access rights.

      C                            RS                       AS
      |                            |                         |
      | <====         Existing security context        ====> |
      |                            |                         |
      +-------- POST /token  ------------------------------->|
      |                            |                         |
      |<--------------------------------- Access Token ------+
      |                               + Access Information   |
      |                            |                         |
      +--- POST /authz-info  ----->|                         |
      |  (OSCORE protected with    |                         |
      |   access_token in payload) |                         |
      |                            |                         |
      |               / Updated access rights /              |
      |                            |                         |
      |<------ 2.04 Changed -------+                         |
      |                            |                         |
      |                            |                         |
      +----- OSCORE Request ------>|                         |
      |                            |                         |
      |<---- OSCORE Response ------|                         |
      |                            |                         |

           Figure 2: Protocol Outline for Updating Access Rights.






Selander, et al.          Expires 23 April 2025                 [Page 9]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


3.  Client-AS Communication

   The following subsections describe the details of the POST request
   and response to the /token endpoint between C and AS.

   In this exchange, AS provides C with the access token, together with
   a set of parameters that enable C to run EDHOC with RS.  In
   particular, these include information about the authorization
   credential of RS, AUTH_CRED_RS, transported by value or uniquely
   referred to.

   The access token is securely bound to the authentication credential
   of C, AUTH_CRED_C, by including it or uniquely referring to it in the
   access token.

   AUTH_CRED_C is specified in the "req_cnf" parameter defined in
   [RFC9201] of the POST request to the /token endpoint from C to AS,
   either transported by value or uniquely referred to.

   The request to the /token endpoint and the corresponding response can
   include EDHOC_Information, which is a CBOR map object containing
   information related to an EDHOC implementation, see Section 3.4.
   This object is transported in the "edhoc_info" parameter registered
   in Section 10.2 and Section 10.3.

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

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

   The client MUST send this POST request to the /token endpoint over a
   secure channel that guarantees authentication, message integrity, and
   confidentiality (see Section 5).  When using this profile, it is
   RECOMMENDED to use CoAP, EDHOC, and OSCORE in order to reduce the
   number of libraries that C has to support.

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












Selander, et al.          Expires 23 April 2025                [Page 10]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

   Figure 3: Example of C-to-AS POST /token request for an access token.

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

   The identifier "session_id" is assigned by AS as discussed in
   Section 3.2, and, together with other information such as audience
   (see Section 5.8.1 of [RFC9200]), can be used by AS to determine the
   token series to which the new requested access token has to be added.
   Therefore, the session_id MUST identify the pair (AUTH_CRED_C,
   AUTH_CRED_RS) associated with a still valid access token previously
   issued for C and RS by AS.

   Editor's note: When retrieving the access token it is required to
   consider the pair (session id, AUTH_CRED_C).  Here it is stated that
   the session id identifies the pair (AUTH_CRED_C,AUTH_CRED_RS).  Why
   then isn't the session id sufficient for retrieving the access token,
   considering it identifies AUTH_CRED_C?

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










Selander, et al.          Expires 23 April 2025                [Page 11]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

       Figure 4: Example of C-to-AS POST /token request for updating
                     access rights to an access token.

3.2.  Token Series

   This document refers to "token series" as a series of access tokens
   sorted in chronological order as they are released, characterized by
   the following properties:

   *  issued by the same AS

   *  issued to the same C, and associated with the same authentication
      credential of C

   *  issued for the same RS, identified by the same authentication
      credential

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

   In this profile, a token series is characterized by access tokens
   used between a given pair (C, RS) having the same "session_id" in the
   EDHOC_Information (see Section 3.4) and bound to the same
   authentication credential AUTH_CRED_C of C.

   AS assigns the "session_id" to the EDHOC_Information when issuing the
   first access token of a new series and that "session_id" remains
   fixed throughout the series lifetime.  When assigning the identifier,
   AS MUST ensure that it was not used in a previous series whose access
   tokens share the following properties with the access tokens of the
   new series:

   *  i) issued for the same RS; and



Selander, et al.          Expires 23 April 2025                [Page 12]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  ii) bound to the same authentication credential AUTH_CRED_C of the
      requesting client (irrespectively of how the AUTH_CRED_C is
      identified in the access tokens).

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

3.3.  AS-to-C: Response

   After verifying the POST request to the /token endpoint and that C is
   authorized to access, AS responds as defined in Section 5.8.2 of
   [RFC9200], with potential modifications as detailed below.  If the
   request from C was invalid or not authorized, AS returns an error
   response as described in Section 5.8.3 of [RFC9200].

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

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

   When issuing any access token, AS MUST send the following data in the
   response to C.

   *  The "session_id" field of EDHOC_Information, which is the
      identifier of the token series which the issued access token
      belongs to.

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







Selander, et al.          Expires 23 April 2025                [Page 13]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

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

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

   When issuing the first access token of a token series, AS MAY send
   EDHOC_Information related to RS, see Section 3.4, in corresponding
   fields of the response to C.  This information is based on knowledge
   that AS has about RS, e.g., from a previous onboarding process, with
   particular reference to what RS supports as EDHOC peer.

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

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

     Figure 5: Example of AS-to-C Access Token response with EDHOC and
                              OSCORE profile.




Selander, et al.          Expires 23 April 2025                [Page 14]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


3.3.1.  Access Token

   To avoid the complexity of different encodings, an access token of
   this profile SHALL be a CBOR Web Token (CWT), see [RFC8392].  When
   issuing any access token of a token series, AS MUST specify the
   following data in the associated claims of the access token:

   *  The "session_id" field of EDHOC_Information, with the same value
      specified in the response to C from the /token endpoint.

      EDHOC_Information MUST be transported in the "edhoc_info" claim,
      defined in Section 10.5.

   *  The authentication credential AUTH_CRED_C that C specified in its
      POST request to the /token endpoint (see Section 3.1), in the
      "cnf" claim.

      In the access token, AUTH_CRED_C can be transported by value or
      uniquely referred to by means of an appropriate identifier,
      regardless of how C specified it in the request to the /token
      endpoint.  Thus, the specific field carried in the access token
      claim and specifying AUTH_CRED_C depends on the specific way used
      by AS.

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

      When later issuing further access tokens to the same pair (C, RS)
      using the same AUTH_CRED_C, it is expected that AUTH_CRED_C is
      identified by reference.

   When issuing the first access token of a token series, AS MAY specify
   additional EDHOC_Information data (see Section 3.4) in the
   "edhoc_info" claim of the access token.  Specifically, if the
   following EDHOC_Information data are specified in the response to C
   from the /token endpoint, they MUST be included with the same values
   in the access token.

   *  osc_ms_len: The size of the OSCORE Master Secret.  If it is not
      included, the default value from Appendix A.1 of [RFC9528] is
      assumed.

   *  osc_salt_len: The size of the OSCORE Master Salt.  If it is not
      included, the default value from Appendix A.1 of [RFC9528] is
      assumed.




Selander, et al.          Expires 23 April 2025                [Page 15]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  osc_version: The OSCORE version.  If it is not included, the
      default value of 1 (see Section 5.4 of [RFC8613]) is assumed.

   The access token needs to be protected for various reasons.  To
   prevent manipulation of the content, it needs to be integrity
   protected.  RS needs to be able to verify that the access token is
   issued by a trusted AS (source authentication).  Depending on the use
   case and deployment, the access token may need to be confidentiality
   protected, for example, for privacy reasons.

   AS protects the access token using a COSE method (see [RFC9052]) as
   specified in [RFC8392].  Depending on the audience, there may be
   different ways to most appropriately ensure the confidentiality of an
   access token.  For an audience comprising a single RS, the CWT Claims
   Set may be wrapped in COSE_Encrypt / COSE_Encrypt0.  Instead, if the
   access token needs to be read by multiple RSs, then the CWT Claims
   Set may be wrapped in COSE_Sign / COSE_Sign1 and confidentiality
   protection is applied during transport, by including the access token
   in the EAD_3 field of EDHOC message_3 sent by C to RS, when using the
   EDHOC forward message flow (see Section 4.2).

   Figure 6 shows an example CWT Claims Set, including the relevant
   EDHOC parameters in the "edhoc_info" claim.  The "cnf" claim
   specifies the authentication credential of C, as an X.509 certificate
   transported by value in the "x5chain" field.  The authentication
   credential of C has been truncated for readability.

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

         Figure 6: Example of CWT Claims Set with EDHOC parameters.







Selander, et al.          Expires 23 April 2025                [Page 16]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


3.3.2.  Processing in C

   When receiving an access token response including the "rs_cnf"
   parameter, C checks whether it is already storing the authentication
   credential of RS, namely AUTH_CRED_RS, specified in "rs_cnf" by value
   or reference.

   If this is not the case, C retrieves AUTH_CRED_RS, either using the
   "rs_cnf" parameter or some other trusted source.  After that, C
   validates the actual AUTH_CRED_RS.  In case of successful validation,
   C stores AUTH_CRED_RS as a valid authentication credential.
   Otherwise, C MUST delete the access token.

3.3.3.  Update of Access Rights

   If C has a valid OSCORE Security Context associated with a valid
   access token, then C can send a request to AS for updating its access
   rights while preserving the same OSCORE Security Context.

   If the request is granted, then AS generates a new access token,
   where the "edhoc_info" claim MUST include only the "session_id"
   field.  The access token is provisioned to RS either via C as
   specified in this document, or directly as described in
   [I-D.ietf-ace-workflow-and-params].  In either case, the access token
   response from the AS to C MUST NOT include the "rs_cnf" parameter.

   EDHOC_Information including the "session_id" field needs to be
   specified in the new access token in order for RS to identify the old
   access token to supersede, as well as the OSCORE Security Context
   already shared between C and RS and to be associated with the new
   access token.

3.4.  EDHOC_Information

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

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

   The EDHOC_Information can be encoded either as a JSON object or as a
   CBOR map.  The set of common fields that can appear in an
   EDHOC_Information can be found in the IANA "EDHOC Information"



Selander, et al.          Expires 23 April 2025                [Page 17]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   registry (see Section 10.9), defined for extensibility, and the
   initial set of parameters defined in this document is specified
   below.  All parameters are optional.

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

   +===============+=======+=======+================+==================+
   | Name          | CBOR  | CBOR  | Registry       | Description      |
   |               | label | type  |                |                  |
   +===============+=======+=======+================+==================+
   | session_id    | 0     | bstr  |                | Identifier of    |
   |               |       |       |                | a session        |
   +---------------+-------+-------+----------------+------------------+
   | methods       | 1     | int   | EDHOC Method   | Set of           |
   |               |       | or    | Type Registry  | supported        |
   |               |       | array |                | EDHOC methods    |
   +---------------+-------+-------+----------------+------------------+
   | cipher_suites | 2     | int   | EDHOC Cipher   | Set of           |
   |               |       | or    | Suites         | supported        |
   |               |       | array | Registry       | EDHOC cipher     |
   |               |       |       |                | suites           |
   +---------------+-------+-------+----------------+------------------+
   | message_4     | 3     | True  |                | Support for      |
   |               |       | or    |                | EDHOC            |
   |               |       | False |                | message_4        |
   +---------------+-------+-------+----------------+------------------+
   | comb_req      | 4     | True  |                | Support for      |
   |               |       | or    |                | the EDHOC +      |
   |               |       | False |                | OSCORE           |
   |               |       |       |                | combined         |
   |               |       |       |                | request          |
   +---------------+-------+-------+----------------+------------------+
   | uri_path      | 5     | tstr  |                | URI-path of      |
   |               |       |       |                | the EDHOC        |
   |               |       |       |                | resource         |
   +---------------+-------+-------+----------------+------------------+
   | osc_ms_len    | 6     | uint  |                | Length in        |
   |               |       |       |                | bytes of the     |
   |               |       |       |                | OSCORE Master    |
   |               |       |       |                | Secret to        |
   |               |       |       |                | derive           |
   +---------------+-------+-------+----------------+------------------+
   | osc_salt_len  | 7     | uint  |                | Length in        |
   |               |       |       |                | bytes of the     |
   |               |       |       |                | OSCORE Master    |
   |               |       |       |                | Salt to derive   |
   +---------------+-------+-------+----------------+------------------+



Selander, et al.          Expires 23 April 2025                [Page 18]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   | osc_version   | 8     | uint  |                | OSCORE version   |
   |               |       |       |                | number to use    |
   +---------------+-------+-------+----------------+------------------+
   | cred_types    | 9     | int   | EDHOC          | Set of           |
   |               |       | or    | Authentication | supported        |
   |               |       | array | Credential     | types of         |
   |               |       |       | Types Registry | authentication   |
   |               |       |       |                | credentials      |
   |               |       |       |                | for EDHOC        |
   +---------------+-------+-------+----------------+------------------+
   | id_cred_types | 10    | int   | COSE Header    | Set of           |
   |               |       | or    | Parameters     | supported        |
   |               |       | tstr  | Registry       | types of         |
   |               |       | or    |                | authentication   |
   |               |       | array |                | credential       |
   |               |       |       |                | identifiers      |
   |               |       |       |                | for EDHOC        |
   +---------------+-------+-------+----------------+------------------+
   | eads          | 11    | uint  | EDHOC External | Set of           |
   |               |       | or    | Authorization  | supported        |
   |               |       | array | Data Registry  | EDHOC External   |
   |               |       |       |                | Authorization    |
   |               |       |       |                | Data (EAD)       |
   |               |       |       |                | items            |
   +---------------+-------+-------+----------------+------------------+
   | initiator     | 12    | True  |                | Support for      |
   |               |       | or    |                | the EDHOC        |
   |               |       | False |                | Initiator role   |
   +---------------+-------+-------+----------------+------------------+
   | responder     | 13    | True  |                | Support for      |
   |               |       | or    |                | the EDHOC        |
   |               |       | False |                | Responder role   |
   +---------------+-------+-------+----------------+------------------+

                   Table 1: EDHOC_Information Parameters

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









Selander, et al.          Expires 23 April 2025                [Page 19]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

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

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

   *  comb_req: This parameter indicates whether the combined EDHOC +
      OSCORE request defined in [I-D.ietf-core-oscore-edhoc]) is
      supported.  In JSON, the "comb_req" value is a boolean.  In CBOR,
      "comb_req" is the simple value "true" or "false", and has label 5.

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

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

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








Selander, et al.          Expires 23 April 2025                [Page 20]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

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

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

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

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



Selander, et al.          Expires 23 April 2025                [Page 21]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

   An example of JSON EDHOC_Information is given in Figure 7.

      "edhoc_info" : {
          "session_id"    : b64'AQ==',
          "methods"       : 1,
          "cipher_suites" : 0
      }

                Figure 7: Example of JSON EDHOC_Information

   The CDDL grammar describing the CBOR EDHOC_Information is:

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

4.  Client-RS Communication

   This section describes the exchange between C and RS, including the
   execution of the EDHOC protocol, and the uploading of the access
   token from C to RS.  The alternative workflow, where AS uploads the
   access token directly to RS, is described in
   [I-D.ietf-ace-workflow-and-params].









Selander, et al.          Expires 23 April 2025                [Page 22]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   C and RS run the EDHOC protocol (see Section 4.2), and C uploads the
   access token in an EAD field (see Section 4.1) of an EDHOC message.
   Once successfully completed the EDHOC session, C and RS derive an
   OSCORE Security Context (see Section 4.5).  OSCORE protects the
   communication when C accesses resources at RS, as per the access
   rights specified in the access token (see Section 4.9).

   Detailed examples are given in Appendix A.

4.1.  EAD items for Access Token and Session Identifier

   This document defines EAD items (see Section 3.8 of [RFC9528]) for
   transporting access token and session idenfier in EDHOC.

   *  EAD_ACCESS_TOKEN = (ead_label, ead_value), where:

      -  ead_label is the integer value TBD registered in Section 10.8,
         and

      -  ead_value is a CBOR byte string equal to the value of the
         "access_token" field of the access token response from AS, see
         Section 3.3.

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

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

   Editor's note: Add example.  Value for ead_label not from lowest
   range, suggested value 26.

   *  EAD_SESSION_ID = (ead_label, ead_value), where:

      -  ead_label is the integer value TBD registered in Section 10.8,
         and

      -  ead_value is a CBOR byte string equal to the value of the
         "session_id" field of EDHOC_Information (see Section 3.4).

   This EAD item is critical, i.e., it is used only with the negative
   value of its ead_label, indicating that the receiving RS must process
   the protocol with the access token associated with this session_id



Selander, et al.          Expires 23 April 2025                [Page 23]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   and with the AUTH_CRED_C used in the EDHOC session, or else abort the
   EDHOC session (see Section 3.8 of [RFC9528]).  A client or resource
   server supporting the profile of ACE defined in this document MUST
   support this EAD item.

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

   Editor's note: Add example.  Value for ead_label from lowest range.

4.2.  EDHOC Session

   In order to mutually authenticate and establish secure communication
   for authorized access according to the profile described in this
   document, C and RS run the EDHOC protocol augmented with an access
   token, or reference thereof - the session identifier, carried in an
   EAD item, either EAD_ACCESS_TOKEN or EAD_SESSION_ID, see Section 4.1.

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

   In case of the EDHOC forward message flow, the access token / session
   id MUST be included in the EAD field of EDHOC message_3 (EAD_3).  In
   case of the EDHOC reverse message flow, the access token / session id
   MAY be included in the EAD field of EDHOC message_2 (EAD_2) or
   message_4 (EAD_4).  In this way the access token / session id gets at
   least the same confidentiality protection by EDHOC as provided to the
   authentication credential used by C, see Section 9.1 of [RFC9528].

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

   C MUST target the EDHOC resource at RS with the URI path specified in
   the "uri_path" field of the EDHOC_Information in the access token
   response received from AS (see Section 3.1), if present.  Otherwise,
   C assumes the target resource at RS to be the well-known EDHOC
   resource at the path /.well-known/edhoc.






Selander, et al.          Expires 23 April 2025                [Page 24]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   RS has to ensure that attackers cannot perform requests on the EDHOC
   resource, other than sending EDHOC messages.  Specifically, it SHOULD
   NOT be possible to perform any other operation than POST on an EDHOC
   resource.

4.3.  Forward Message Flow

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

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

4.3.1.  EDHOC message_1

   The processing of EDHOC message_1 is specified in Section 5.2 of
   [RFC9528].  Additionally, the following applies:

   *  The EDHOC method MUST be one of the EDHOC methods specified in the
      "methods" field (if present) in the EDHOC_Information of the
      access token response to C.

   *  The selected cipher suite MUST be an EDHOC cipher suite specified
      in the "cipher_suites" field (if present) in the EDHOC_Information
      of the access token response to C.

4.3.2.  EDHOC message_2

   The processing of EDHOC message_2 is specified in Section 5.3 of
   [RFC9528] with the following additions:

   *  The authentication credential CRED_R indicated by the message
      field ID_CRED_R is AUTH_CRED_RS.

4.3.3.  EDHOC message_3

   The processing of EDHOC message_3 is specified in Section 5.4 of
   [RFC9528] with the following additions:

   *  The authentication credential CRED_I indicated by the message
      field ID_CRED_I is AUTH_CRED_C.

   *  According to this profile, one of the EAD items EAD_ACCESS_TOKEN
      or EAD_SESSION_ID MUST be included in EAD_3.





Selander, et al.          Expires 23 April 2025                [Page 25]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  If EAD_3 includes the EAD item EAD_ACCESS_TOKEN then RS MUST
      ensure that the included access token is valid.  If EAD_3 includes
      the EAD item EAD_SESSION_ID then RS MUST ensure that the access
      token associated with the included session_id and with the
      AUTH_CRED_C used in the EDHOC session is valid.  The validation
      follows the procedure specified in Section 4.6.2.  If such a
      process fails, RS MUST reply to C with an EDHOC error message with
      ERR_CODE = 1 (see Section 6 of [RFC9528]), and it MUST abort the
      EDHOC session.

   RS MUST have successfully validated the access token before
   completing the EDHOC session.  If completed successfully, then the
   EDHOC session is associated with both the access token and the pair
   (session_id, AUTH_CRED_C).  Any previous EDHOC session associated
   with the same access token and with the same pair (session_id,
   AUTH_CRED_C) MUST be deleted.  The OSCORE Security Context derived
   from that EDHOC session MUST also be deleted.

   Editor's note: Instead of ERR_CODE = 1, consider to use ERR_CODE = 3
   "Access Denied" defined in draft-ietf-lake-authz

4.4.  Reverse Message Flow

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

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

   According to this profile, one of the EAD items EAD_ACCESS_TOKEN or
   EAD_SESSION_ID MAY be included either in EAD_2 or EAD_4.  If EAD_2
   and EAD_4 contain either EAD_ACCESS_TOKEN or EAD_SESSION_ID then the
   EDHOC session MUST be aborted.

   RS MUST have successfully validated the access token before
   completing the EDHOC session.  If completed successfully, then the
   EDHOC session is associated with both the access token and the pair
   (session_id, AUTH_CRED_C).  Any previous EDHOC session associated
   with the same access token and with the same pair (session_id,
   AUTH_CRED_C) MUST be deleted.  The OSCORE Security Context derived
   from that EDHOC session MUST also be aborted.

   Specific instructions for the different messages are included in the
   following subsections.





Selander, et al.          Expires 23 April 2025                [Page 26]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


4.4.1.  Trigger Message

   As specified in Appendix A.2.2 of [RFC9528], the trigger message
   consists of C making an empty POST request to the EDHOC resource at
   RS, intended to trigger a response containing EDHOC message_1.

4.4.2.  EDHOC message_1

   The processing of EDHOC message_1 is specified in Section 5.2 of
   [RFC9528].

4.4.3.  EDHOC message_2

   The processing of EDHOC message_2 is specified in Section 5.3 of
   [RFC9528] with the following additions:

   *  The authentication credential CRED_R indicated by the message
      field ID_CRED_R is AUTH_CRED_C.

   *  If EAD_2 includes the EAD item EAD_ACCESS_TOKEN then RS MUST
      ensure that the included access token is valid.  If EAD_2 includes
      the EAD item EAD_SESSION_ID then RS MUST ensure that the access
      token associated with the included session_id and with the
      AUTH_CRED_C used in the EDHOC session is valid.  The validation
      follows the procedure specified in Section 4.6.2.  If such a
      process fails, RS MUST reply to C with an EDHOC error message with
      ERR_CODE = 1 (see Section 6 of [RFC9528]), and it MUST abort the
      EDHOC session.

4.4.4.  EDHOC message_3

   The processing of EDHOC message_3 is specified in Section 5.4 of
   [RFC9528] with the following additions:

   *  The authentication credential CRED_I indicated by the message
      field ID_CRED_I is AUTH_CRED_RS.

4.4.5.  EDHOC message_4

   The processing of EDHOC message_4 is specified in Section 5.5 of
   [RFC9528] with the following additions:










Selander, et al.          Expires 23 April 2025                [Page 27]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  If EAD_4 includes the EAD item EAD_ACCESS_TOKEN then RS MUST
      ensure that the included access token is valid.  If EAD_4 includes
      the EAD item EAD_SESSION_ID then RS MUST ensure that the access
      token associated to the included session_id and AUTH_CRED_C is
      valid.  The validation follows the procedure specified in
      Section 4.6.2.  If such a process fails, RS MUST reply to C with
      an EDHOC error message with ERR_CODE = 1 (see Section 6 of
      [RFC9528]), and it MUST abort the EDHOC session.

   Editor's note: Instead of ERR_CODE = 1, consider to use ERR_CODE = 3
   "Access Denied" defined in draft-ietf-lake-authz

4.5.  OSCORE Security Context

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

   *  The length in bytes of the OSCORE Master Secret (i.e., the
      oscore_key_length parameter, see Appendix A.1 of [RFC9528]) MUST
      be the value specified in the "osc_ms_size" field (if present) in
      the EDHOC_Information of the access token response to C, and of
      the access token provisioned to RS, respectively.

   *  The length in bytes of the OSCORE Master Salt (i.e., the
      oscore_salt_length parameter, see Appendix A.1 of [RFC9528]) MUST
      be the value specified in the "osc_salt_size" field (if present)
      in the EDHOC_Information of the access token response to C, and of
      the access token provisioned to RS, respectively.

   *  C and RS MUST use the OSCORE version specified in the
      "osc_version" field (if present) in the EDHOC_Information of the
      access token response to C, and of the access token provisioned to
      RS, respectively.

   *  RS associates the latest EDHOC session and the derived OSCORE
      Security Context with the stored access token, which is bound to
      the authentication credential AUTH_CRED_C used in the EDHOC
      session and with the session_id identifying the token series to
      which the access token belongs.

   If supported by C, C MAY use the EDHOC + OSCORE combined request
   defined in [I-D.ietf-core-oscore-edhoc], unless the "comb_req" field
   of the EDHOC_Information was present in the access token response and
   set to the CBOR simple value "false" (0xf4).  In the combined
   request, both EDHOC message_3 and the first OSCORE-protected
   application request are combined together in a single OSCORE-
   protected CoAP request, thus saving one round trip.  For an example,



Selander, et al.          Expires 23 April 2025                [Page 28]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   see Appendix A.2.  This requires C to derive the OSCORE Security
   Context with RS already after having successfully processed the
   received EDHOC message_2 and before sending EDHOC message_3.

4.6.  Update of Access Rights

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

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

   According to this document, AS provides the access token to C (see
   Section 3.3) for further uploading to RS.  Alternatively, the access
   token may be uploaded by AS directly to RS, as described in
   [I-D.ietf-ace-workflow-and-params].  If all validations are
   successful, C can access protected resources at RS according to the
   updated access rights using the previously established OSCORE
   Security Context.

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

4.6.1.  C-to-RS: POST to /authz-info endpoint

   C can update its access rights by uploading the updated access token
   to RS using CoAP [RFC7252] and the Authorization Information endpoint
   as described in Section 5.10.1 of [RFC9200].

   That is, C sends a POST request to the /authz-info endpoint at RS,
   with the request payload containing the access token without any CBOR
   wrapping.  As per Section 5.10.1 of [RFC9200], the Content-Format of
   the POST request MUST be "application/cwt" to reflect the format of
   the transported access token.

   C MUST protect the POST request using the current OSCORE Security
   Context shared with RS.

   Upon receiving an access token from C, RS MUST follow the procedures
   defined in Section 5.10.1 of [RFC9200].  That is, RS must verify the
   validity of the access token.  RS may make an introspection request
   (see Section 5.9.1 of [RFC9200]) to validate the access token.

   RS MUST check the following conditions:





Selander, et al.          Expires 23 April 2025                [Page 29]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  RS checks whether it stores an access token T_OLD, such that the
      "session_id" field of EDHOC_Information matches the "session_id"
      field of EDHOC_Information in the new access token T_NEW.

   *  RS checks whether the OSCORE Security Context CTX used to protect
      the request matches the OSCORE Security Context associated with
      the stored access token T_OLD.

   If both the conditions above hold, RS MUST replace the old access
   token T_OLD with the new access token T_NEW, and associate T_NEW with
   the OSCORE Security Context CTX.

   Note that C and RS do not execute the EDHOC protocol, they do not
   establish a new OSCORE Security Context, and AUTH_CRED_C remains the
   same.

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

   If all validations are successful, RS MUST reply to the POST request
   with a 2.01 (Created) response protected with the same OSCORE
   Security Context, with no payload.  The access token is stored such
   that it is possible to retrieve it based on "session_id" and
   AUTH_CRED_C.

   After that, C can access to protected resources at RS according to
   the updated access rights using the previously established OSCORE
   Security Context.

   Otherwise, RS MUST respond with a 4.01 (Unauthorized) error response.
   RS may provide additional information in the payload of the error
   response, in order to clarify what went wrong.

   As specified in Section 5.10.1 of [RFC9200], when receiving a valid
   access token with updated authorization information from C (see
   Section 4.6.1), it is recommended that RS overwrites the previous
   access token.  That is, only the latest authorization information in
   the access token received by RS is valid.  This simplifies the
   process needed by RS to keep track of authorization information for a
   given client.

   Editor's note: The following error case was described for unprotected
   POST /authz-info.  It seems not relevant anymore.

   If, instead, the access token is valid but associated with claims
   that RS cannot process (e.g., an unknown scope), or if any of the
   expected parameters is missing (e.g., any of the mandatory parameters
   from AS or the identifier "session_id"), or if any parameters
   received in the EDHOC_Information is unrecognized, then RS MUST



Selander, et al.          Expires 23 April 2025                [Page 30]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   respond with an error response code equivalent to the CoAP code 4.00
   (Bad Request).  In the latter two cases, RS may provide additional
   information in the payload of the error response, in order to clarify
   what went wrong.

4.7.  Discarding the OSCORE Security Context

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

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

   *  The OSCORE Sender Sequence Number space of C is exhausted.

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

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

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

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

   *  The OSCORE Sender Sequence Number space of RS is exhausted.

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

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

   After a new access token is successfully uploaded to RS, and a new
   OSCORE Security Context is established between C and RS, messages
   still in transit that were protected with the previous OSCORE
   Security Context might not be successfully verified by the recipient,



Selander, et al.          Expires 23 April 2025                [Page 31]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   since the old OSCORE Security Context might have been discarded.
   This means that messages sent shortly before C has uploaded the new
   access token to RS might not be successfully accepted by the
   recipient.

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

4.8.  Establishing a New OSCORE Security Context

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

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

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

4.9.  Access Rights Verification

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



Selander, et al.          Expires 23 April 2025                [Page 32]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

4.10.  Access Token Invalidity

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

5.  Secure Communication with AS

   As specified in the ACE framework (see Sections 5.8 and 5.9 of
   [RFC9200]), the requesting entity (RS and/or C) and AS communicates
   via the /token or /introspect endpoint.  When using this profile, the
   use of CoAP [RFC7252] and OSCORE [RFC8613] for this communication is
   RECOMMENDED.  Other protocols fulfilling the security requirements
   defined in Section 5 of [RFC9200] (such as HTTP and DTLS [RFC9147] or
   TLS [RFC8446]) MAY be used instead.

   If OSCORE is used, the requesting entity and AS need to have an
   OSCORE Security Context in place.  While this can be pre-installed,
   the requesting entity and AS can establish such an OSCORE Security
   Context, for example, by running the EDHOC protocol, as shown between
   C and AS by the examples in Appendix A.1 and Appendix A.2.  This also
   applies for communication between RS and AS, for example to protect
   the upload of access token from AS directly to RS as described in
   [I-D.ietf-ace-workflow-and-params].

6.  CWT Confirmation Methods

   This document defines a number of new CWT confirmation methods (see
   Section 10.7).  The semantics of each confirmation method is defined
   below.

6.1.  Ordered Chain of X.509 Certificates

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







Selander, et al.          Expires 23 April 2025                [Page 33]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


6.2.  Unordered Bag of X.509 Certificates

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

6.3.  Hash of an X.509 Certificate

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

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

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

6.5.  Ordered Chain of C509 Certificates

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

6.6.  Unordered Bag of C509 Certificates

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

6.7.  Hash of a C509 Certificate

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

6.8.  URI Pointing to an Ordered Chain of C509 Certificates

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



Selander, et al.          Expires 23 April 2025                [Page 34]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


6.9.  CWT Containing a COSE_Key

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

6.10.  CCS Containing a COSE_Key

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

7.  JWT Confirmation Methods

   This document defines a number of new JWT confirmation methods (see
   Section 10.6).  The semantics of each confirmation method is defined
   below.

7.1.  Ordered Chain of X.509 Certificates

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

7.2.  Unordered Bag of X.509 Certificates

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

7.3.  Hash of an X.509 Certificate

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






Selander, et al.          Expires 23 April 2025                [Page 35]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

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

7.5.  Ordered Chain of C509 Certificates

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

7.6.  Unordered Bag of C509 Certificates

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

7.7.  Hash of a C09 Certificate

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

7.8.  URI Pointing to an Ordered Chain of C509 Certificates

   The confirmation method "c5u" specifies the URI [RFC3986] of
   COSE_C509 containing an ordered chain of C509 certificates
   [I-D.ietf-cose-cbor-encoded-cert].  COSE_C509 is defined in
   [I-D.ietf-cose-cbor-encoded-cert].  The semantics of "c5u" is like
   that of the "x5u" JWT confirmation method defined in Section 7.4,
   with the following differences.  First, the URI refers to a resource
   for the C509 certificate chain.  Second, the public key contained in



Selander, et al.          Expires 23 April 2025                [Page 36]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   one of the C509 certificates and acting as proof-of-possession key
   does not have to correspond to a key used to digitally sign the JWS.

7.9.  CWT Containing a COSE_Key

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

7.10.  CCS Containing a COSE_Key

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

8.  Security Considerations

   This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework [RFC9200].
   Thus, the general security considerations from the ACE framework also
   apply to this profile.

   Furthermore, the security considerations from OSCORE [RFC8613] and
   from EDHOC [RFC9528] also apply to this specific use of the OSCORE
   and EDHOC protocols.

   As previously stated, once completed the EDHOC session, C and RS are
   mutually authenticated through their respective authentication
   credentials, whose retrieval has been facilitated by AS.  Also once
   completed the EDHOC session, C and RS have established a long-term
   secret key PRK_out enjoying forward secrecy.  This is in turn used by
   C and RS to establish an OSCORE Security Context.

   Furthermore, RS achieves confirmation that C has PRK_out (proof-of-
   possession) when completing the EDHOC session.  Rather, C achieves
   confirmation that RS has PRK_out (proof-of-possession) either when
   receiving the optional EDHOC message_4 from RS, or when successfully
   verifying a response from RS protected with the established OSCORE
   Security Context.










Selander, et al.          Expires 23 April 2025                [Page 37]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   OSCORE is designed to secure point-to-point communication, providing
   a secure binding between a request and the corresponding response(s).
   Thus, the basic OSCORE protocol is not intended for use in point-to-
   multipoint communication (e.g., enforced via multicast or a publish-
   subscribe model).  Implementers of this profile should make sure that
   their use case of OSCORE corresponds to the expected one, in order to
   prevent weakening the security assurances provided by OSCORE.

   When using this profile, it is RECOMMENDED that RS stores only one
   access token per client.  The use of multiple access tokens for a
   single client increases the strain on RS, since it must consider
   every access token associated with the client and calculate the
   actual permissions that client has.  Also, access tokens indicating
   different or disjoint permissions from each other may lead RS to
   enforce wrong permissions.  If one of the access tokens expires
   earlier than others, the resulting permissions may offer insufficient
   protection.  Developers SHOULD avoid using multiple access tokens for
   a same client.  Furthermore, RS MUST NOT store more than one access
   token per client per PoP-key (i.e., per client's authentication
   credential).

9.  Privacy Considerations

   This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework [RFC9200].
   Thus, the general privacy considerations from the ACE framework also
   apply to this profile.

   Furthermore, the privacy considerations from OSCORE [RFC8613] and
   from EDHOC [RFC9528] also apply to this specific use of the OSCORE
   and EDHOC protocols.

   An unprotected response to an unauthorized request may disclose
   information about RS and/or its existing relationship with C.  It is
   advisable to include as little information as possible in an
   unencrypted response.  When an OSCORE Security Context already exists
   between C and RS, more detailed information may be included.

   Except for the case where C attempts to update its access rights, the
   (encrypted) access token is sent in an unprotected POST request to
   the /authz-info endpoint at RS.  Thus, if C uses the same single
   access token from multiple locations, it can risk being tracked by
   the access token's value even when the access token is encrypted.

   The identifiers used in OSCORE, i.e., the OSCORE Sender/Recipient
   IDs, are negotiated by C and RS during the EDHOC session.  That is,
   the EDHOC Connection Identifier C_I of C is going to be the OSCORE
   Recipient ID of C (the OSCORE Sender ID of RS).  Conversely, the



Selander, et al.          Expires 23 April 2025                [Page 38]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   EDHOC Connection Identifier C_R of RS is going to be the OSCORE
   Recipient ID of RS (the OSCORE Sender ID of C).  These OSCORE
   identifiers are privacy sensitive (see Section 12.8 of [RFC8613]).
   In particular, they could reveal information about C, or may be used
   for correlating different requests from C, e.g., across different
   networks that C has joined and left over time.  This can be mitigated
   if C and RS dynamically update their OSCORE identifiers, e.g., by
   using the method defined in [I-D.ietf-core-oscore-key-update].

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

10.1.  ACE Profiles Registry

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

   *  Name: coap_edhoc_oscore

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

   *  CBOR Value: TBD (value between 1 and 255)

   *  Reference: [RFC-XXXX]

10.2.  OAuth Parameters Registry

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

   *  Name: "edhoc_info"

   *  Parameter Usage Location: token request and token response

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]






Selander, et al.          Expires 23 April 2025                [Page 39]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


10.3.  OAuth Parameters CBOR Mappings Registry

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

   *  Name: "edhoc_info"

   *  CBOR Key: TBD

   *  Value Type: map

   *  Reference: [RFC-XXXX]

10.4.  JSON Web Token Claims Registry

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

   *  Claim Name: "edhoc_info"

   *  Claim Description: Information for EDHOC session

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]

10.5.  CBOR Web Token (CWT) Claims Registry

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

   *  Claim Name: "edhoc_info"

   *  Claim Description: Information for EDHOC session

   *  JWT Claim Name: "edhoc_info"

   *  Claim Key: TBD

   *  Claim Value Type: map

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]





Selander, et al.          Expires 23 April 2025                [Page 40]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


10.6.  JWT Confirmation Methods Registry

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

   *  Confirmation Method Value: "x5c"

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

   *  Change Controller: IETF

   *  Reference: Section 7.1 of [RFC-XXXX]



   *  Confirmation Method Value: "x5b"

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

   *  Change Controller: IETF

   *  Reference: Section 7.2 of [RFC-XXXX]



   *  Confirmation Method Value: "x5t"

   *  Confirmation Method Description: Hash of an X.509 certificate

   *  Change Controller: IETF

   *  Reference: Section 7.3 of [RFC-XXXX]



   *  Confirmation Method Value: "x5u"

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

   *  Change Controller: IETF

   *  Reference: Section 7.4 of [RFC-XXXX]






Selander, et al.          Expires 23 April 2025                [Page 41]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  Confirmation Method Value: "c5c"

   *  Confirmation Method Description: An ordered chain of C509
      certificates

   *  Change Controller: IETF

   *  Reference: Section 7.5 of [RFC-XXXX]



   *  Confirmation Method Value: "c5b"

   *  Confirmation Method Description: An unordered bag of C509
      certificates

   *  Change Controller: IETF

   *  Reference: Section 7.6 of [RFC-XXXX]



   *  Confirmation Method Value: "c5t"

   *  Confirmation Method Description: Hash of a C509 certificate

   *  Change Controller: IETF

   *  Reference: Section 7.7 of [RFC-XXXX]



   *  Confirmation Method Value: "c5u"

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

   *  Change Controller: IETF

   *  Reference: Section 7.8 of [RFC-XXXX]



   *  Confirmation Method Value: "kcwt"

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




Selander, et al.          Expires 23 April 2025                [Page 42]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  Change Controller: IETF

   *  Reference: Section 7.9 of [RFC-XXXX]



   *  Confirmation Method Value: "kccs"

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

   *  Change Controller: IETF

   *  Reference: Section 7.10 of [RFC-XXXX]

10.7.  CWT Confirmation Methods Registry

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

   *  Confirmation Method Name: x5chain

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

   *  JWT Confirmation Method Name: "x5c"

   *  Confirmation Key: TBD

   *  Confirmation Value Type: COSE_X509

   *  Change Controller: IETF

   *  Reference: Section 6.1 of [RFC-XXXX]



   *  Confirmation Method Name: x5bag

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

   *  JWT Confirmation Method Name: "x5b"

   *  Confirmation Key: TBD

   *  Confirmation Value Type: COSE_X509




Selander, et al.          Expires 23 April 2025                [Page 43]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  Change Controller: IETF

   *  Reference: Section 6.2 of [RFC-XXXX]



   *  Confirmation Method Name: x5t

   *  Confirmation Method Description: Hash of an X.509 certificate

   *  JWT Confirmation Method Name: "x5t"

   *  Confirmation Key: TBD

   *  Confirmation Value Type: COSE_CertHash

   *  Change Controller: IETF

   *  Reference: Section 6.3 of [RFC-XXXX]



   *  Confirmation Method Name: x5u

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

   *  JWT Confirmation Method Name: "x5u"

   *  Confirmation Key: TBD

   *  Confirmation Value Type: uri

   *  Change Controller: IETF

   *  Reference: Section 6.4 of [RFC-XXXX]



   *  Confirmation Method Name: c5c

   *  Confirmation Method Description: An ordered chain of C509
      certificates

   *  JWT Confirmation Method Name: "c5c"

   *  Confirmation Key: TBD




Selander, et al.          Expires 23 April 2025                [Page 44]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  Confirmation Value Type: COSE_C509

   *  Change Controller: IETF

   *  Reference: Section 6.5 of [RFC-XXXX]



   *  Confirmation Method Name: c5b

   *  Confirmation Method Description: An unordered bag of C509
      certificates

   *  JWT Confirmation Method Name: "c5b"

   *  Confirmation Key: TBD

   *  Confirmation Value Type: COSE_C509

   *  Change Controller: IETF

   *  Reference: Section 6.6 of [RFC-XXXX]



   *  Confirmation Method Name: c5t

   *  Confirmation Method Description: Hash of a C509 certificate

   *  JWT Confirmation Method Name: "c5t"

   *  Confirmation Key: TBD

   *  Confirmation Value Type: COSE_CertHash

   *  Change Controller: IETF

   *  Reference: Section 6.7 of [RFC-XXXX]



   *  Confirmation Method Name: c5u

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

   *  JWT Confirmation Method Name: "c5u"




Selander, et al.          Expires 23 April 2025                [Page 45]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  Confirmation Key: TBD

   *  Confirmation Value Type: uri

   *  Change Controller: IETF

   *  Reference: Section 6.8 of [RFC-XXXX]



   *  Confirmation Method Name: kcwt

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

   *  JWT Confirmation Method Name: "kcwt"

   *  Confirmation Key: TBD

   *  Confirmation Value Type: COSE_Messages

   *  Change Controller: IETF

   *  Reference: Section 6.9 of [RFC-XXXX]



   *  Confirmation Method Name: kccs

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

   *  JWT Confirmation Method Name: "kccs"

   *  Confirmation Key: TBD

   *  Confirmation Value Type: map / #6(map)

   *  Change Controller: IETF

   *  Reference: Section 6.10 of [RFC-XXXX]

10.8.  EDHOC External Authorization Data Registry

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

   *  Name: ACE-OAuth Access Token



Selander, et al.          Expires 23 April 2025                [Page 46]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  Label: TBD

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

   *  Reference: [RFC-XXXX], Section 4.1



   *  Name: Session ID

   *  Label: TBD

   *  Description: The identifier of an EDHOC session

   *  Reference: [RFC-XXXX], Section 4.1

10.9.  EDHOC Information Registry

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

   As registration policy, the registry uses either "Standards Action
   with Expert Review", or "Specification Required" per Section 4.6 of
   [RFC8126], or "Expert Review" per Section 4.5 of [RFC8126].  Expert
   Review guidelines are provided in Section 10.10.

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

   The columns of the registry are:

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







Selander, et al.          Expires 23 April 2025                [Page 47]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

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

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

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

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

   *  Description: A brief description of this item.

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

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

10.10.  Expert Review Instructions

   The IANA registry established in this document is defined as
   "Standards Action with Expert Review", "Specification Required", or
   "Expert Review", depending on the range of values for which an
   assignment is requested.  This section gives some general guidelines
   for what the experts should be looking for, but they are being
   designated as experts for a reason so they should be given
   substantial latitude.

   Expert reviewers should take into consideration the following points:

   *  Point squatting should be discouraged.  Reviewers are encouraged
      to get sufficient information for registration requests to ensure
      that the usage is not going to duplicate one that is already
      registered and that the point is likely to be used in deployments.



Selander, et al.          Expires 23 April 2025                [Page 48]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


      The zones tagged as private use are intended for testing purposes
      and closed environments; code points in other ranges should not be
      assigned for testing.

   *  Specifications are required for the Standards Action range of
      point assignment.  Specifications should exist for Specification
      Required ranges, but early assignment before a specification is
      available is considered to be permissible.  Specifications are
      needed for the first-come, first-serve range if they are expected
      to be used outside of closed environments in an interoperable way.
      When specifications are not provided, the description provided
      needs to have sufficient information to identify what the point is
      being used for.

   *  Experts should take into account the expected usage of fields when
      approving point assignment.  The fact that there is a range for
      Standards Track documents does not mean that a Standards Track
      document cannot have points assigned outside of that range.  The
      length of the encoded value should be weighed against how many
      code points of that length are left, the size of device it will be
      used on, and the number of code points left that encode to that
      size.

11.  References

11.1.  Normative References

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

   [I-D.ietf-core-oscore-edhoc]
              Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
              (EDHOC) with the Constrained Application Protocol (CoAP)
              and Object Security for Constrained RESTful Environments
              (OSCORE)", Work in Progress, Internet-Draft, draft-ietf-
              core-oscore-edhoc-11, 9 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              oscore-edhoc-11>.










Selander, et al.          Expires 23 April 2025                [Page 49]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

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

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

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

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

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

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

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

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

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



Selander, et al.          Expires 23 April 2025                [Page 50]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

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

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

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

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

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

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

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

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

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




Selander, et al.          Expires 23 April 2025                [Page 51]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

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

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

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

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

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

11.2.  Informative References

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











Selander, et al.          Expires 23 April 2025                [Page 52]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

   [I-D.ietf-core-oscore-key-update]
              Höglund, R. and M. Tiloca, "Key Update for OSCORE
              (KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
              core-oscore-key-update-08, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              oscore-key-update-08>.

   [I-D.ietf-lake-authz]
              Selander, G., Mattsson, J. P., Vučinić, M., Fedrecheski,
              G., and M. Richardson, "Lightweight Authorization using
              Ephemeral Diffie-Hellman Over COSE", Work in Progress,
              Internet-Draft, draft-ietf-lake-authz-02, 5 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lake-
              authz-02>.

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

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

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

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

Appendix A.  Examples

   This appendix provides examples where this profile of ACE is used.
   In particular:

   *  Appendix A.1 does not make use of use of any optimization.



Selander, et al.          Expires 23 April 2025                [Page 53]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  Appendix A.2 makes use of the optimizations defined in
      [I-D.ietf-core-oscore-edhoc], hence reducing the roundtrips of the
      interactions between the Client and the Resource Server.

   All these examples build on the following assumptions, as relying on
   expected early procedures performed at AS.  These include the
   registration of RSs by the respective Resource Owners as well as the
   registrations of Clients authorized to request access token for those
   RSs.

   *  AS knows the authentication credential AUTH_CRED_C of the Client
      C.

   *  The Client knows the authentication credential AUTH_CRED_AS of AS.

   *  AS knows the authentication credential AUTH_CRED_RS of RS.

   *  RS knows the authentication credential AUTH_CRED_AS of AS.

      This is relevant in case AS and RS actually require a secure
      association (e.g., for RS to perform token introspection at AS, or
      for AS to upload an access token to RS on behalf of the Client).

   As a result of the assumptions above, it is possible to limit the
   transport of AUTH_CRED_C and AUTH_CRED_RS by value only to the
   following two cases, and only when the Client requests an access
   token for RS in question for the first time when considering the pair
   (AUTH_CRED_C, AUTH_CRED_RS).

   *  In the Token Response from AS to the Client, where AUTH_CRED_RS is
      specified by the 'rs_cnf' parameter.

   *  In the access token, where AUTH_CRED_C is specified by the 'cnf'
      claim.

   Note that, even under the circumstances mentioned above, AUTH_CRED_C
   might rather be indicated by reference.  This is possible if RS can
   effectively use such a reference from the access token to retrieve
   AUTH_CRED_C (e.g., from a trusted repository of authentication
   credentials reachable through a non-constrained link), and if AS is
   in turn aware of that.

   In any other case, it is otherwise possible to indicate both
   AUTH_CRED_C and AUTH_CRED_RS by reference, when performing the ACE
   access control workflow as well as later on when the Client and RS
   run EDHOC.





Selander, et al.          Expires 23 April 2025                [Page 54]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


A.1.  Workflow without Optimizations

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

     C                                 AS                             RS
     |                                  |                              |
     |  EDHOC message_1 to /edhoc       |                              |
 M01 +--------------------------------->|                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_2                 |                              |
 M02 |<---------------------------------+                              |
     |  ID_CRED_R identifies            |                              |
     |     CRED_R = AUTH_CRED_AS        |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_3 to /edhoc       |                              |
 M03 +--------------------------------->|                              |
     |  ID_CRED_I identifies            |                              |
     |     CRED_I = AUTH_CRED_C         |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  Token request to /token         |                              |
     |  (OSCORE-protected message)      |                              |
 M04 +--------------------------------->|                              |
     |  'req_cnf' identifies            |                              |
     |     AUTH_CRED_C by reference     |                              |
     |                                  |                              |
     |                                  |                              |
     |  Token response                  |                              |
     |  (OSCORE-protected message)      |                              |
 M05 |<---------------------------------+                              |
     |  'rs_cnf' specifies              |                              |
     |     AUTH_CRED_RS by value        |                              |
     |                                  |                              |
     |  'ace_profile' specifies the     |                              |
     |  ACE profile "coap_edhoc_oscore" |                              |
     |                                  |                              |
     |  'edhoc_info' specifies:         |                              |
     |     {                            |                              |
     |       e'session_id' : h'01',     |                              |
     |       e'cipher_suites' : 2,      |                              |
     |       e'methods' : 3,            |                              |
     |       e'uri_path' : "/edhoc"     |                              |



Selander, et al.          Expires 23 April 2025                [Page 55]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


     |     }                            |                              |
     |                                  |                              |
     |  In the access token:            |                              |
     |  - the 'cnf' claim specifies     |                              |
     |    AUTH_CRED_C by value          |                              |
     |  - the 'edhoc_info' claim        |                              |
     |    specifies the same as         |                              |
     |    'edhoc_info' above            |                              |
     |                                  |                              |

      Possibly after chain verification, the Client adds AUTH_CRED_RS
      to the set of its trusted peer authentication credentials,
      relying on AS as trusted provider/

     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_1 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M06 +---------------------------------------------------------------->|
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_2                 |                              |
 M07 |<----------------------------------------------------------------+
     |  ID_CRED_R identifies            |                              |
     |     CRED_R = AUTH_CRED_RS        |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_3 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M08 +---------------------------------------------------------------->|
     |      EAD_3 contains access token |                              |
     |  ID_CRED_I identifies            |                              |
     |     CRED_I = AUTH_CRED_C         |                              |
     |     by reference                 |                              |
     |                                  |                              |

      Possibly after chain verification, RS adds AUTH_CRED_C
      to the set of its trusted peer authentication credentials,
      relying on AS as trusted provider/


     |                                  |                              |
     |  Access to protected resource    |                              |
     |  (OSCORE-protected message)      |                              |
     |  (access control is enforced)    |                              |
 M08 +---------------------------------------------------------------->|
     |                                  |                              |



Selander, et al.          Expires 23 April 2025                [Page 56]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


     |  Response                        |                              |
     |  (OSCORE-protected message)      |                              |
 M10 |<----------------------------------------------------------------+
     |                                  |                              |

      Later on, the access token expires ...
       - The Client and RS delete their OSCORE Security Context and
         purge the EDHOC session used to derive it (unless the same
         session is also used for other reasons).
       - RS retains AUTH_CRED_C as still valid,
         and AS knows about it.
       - The Client retains AUTH_CRED_RS as still valid,
         and AS knows about it.

     |                                  |                              |
     |                                  |                              |

      Time passes ...

     |                                  |                              |
     |                                  |                              |

      The Client asks for a new access token; now all the
      authentication credentials can be indicated by reference

      The price to pay is on AS, about remembering that at least
      one access token has been issued for the pair (Client, RS)
      and considering the pair (AUTH_CRED_C, AUTH_CRED_RS)

     |                                  |                              |
     |  Token request to /token         |                              |
     |  (OSCORE-protected message)      |                              |
 M11 +--------------------------------->|                              |
     |  'req_cnf' identifies            |                              |
     |     CRED_I = AUTH_CRED_C         |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  Token response                  |                              |
     |  (OSCORE-protected message)      |                              |
 M12 |<---------------------------------+                              |
     |  'rs_cnf' identifies             |                              |
     |     AUTH_CRED_RS by reference    |                              |
     |                                  |                              |
     |  'ace_profile' specifies the     |                              |
     |  ACE profile "coap_edhoc_oscore" |                              |
     |                                  |                              |
     |  'edhoc_info' specifies:         |                              |



Selander, et al.          Expires 23 April 2025                [Page 57]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


     |     {                            |                              |
     |       e'session_id' : h'05',     |                              |
     |       e'cipher_suites' : 2,      |                              |
     |       e'methods' : 3,            |                              |
     |       e'uri_path' : "/edhoc"     |                              |
     |     }                            |                              |
     |                                  |                              |
     |  In the access token:            |                              |
     |  - the 'cnf' claim specifies     |                              |
     |    AUTH_CRED_C by reference      |                              |
     |  - the 'edhoc_info' claim        |                              |
     |    specifies the same as         |                              |
     |    'edhoc_info' above            |                              |
     |                                  |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_1 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M13 +---------------------------------------------------------------->|
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_2                 |                              |
     |  (no access control is enforced) |                              |
 M14 |<----------------------------------------------------------------+
     |  ID_CRED_R specifies             |                              |
     |     CRED_R = AUTH_CRED_RS        |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_3 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M15 +---------------------------------------------------------------->|
     |      EAD_3 contains access token |                              |
     |  ID_CRED_I identifies            |                              |
     |     CRED_I = AUTH_CRED_C         |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  Access to protected resource /r |                              |
     |  (OSCORE-protected message)      |                              |
     |  (access control is enforced)    |                              |
 M16 +---------------------------------------------------------------->|
     |                                  |                              |
     |                                  |                              |
     |  Response                        |                              |
     |  (OSCORE-protected message)      |                              |
 M17 |<----------------------------------------------------------------+
     |                                  |                              |



Selander, et al.          Expires 23 April 2025                [Page 58]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


A.2.  Workflow with Optimizations

   The example below builds on the example in Appendix A.1, while
   additionally using the EDHOC+OSCORE request defined in
   [I-D.ietf-core-oscore-edhoc] when running EDHOC both with AS and with
   RS.

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

     C                                 AS                             RS
     |                                  |                              |
     |  EDHOC message_1 to /edhoc       |                              |
 M01 +--------------------------------->|                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_2                 |                              |
 M02 |<---------------------------------+                              |
     |  ID_CRED_R identifies            |                              |
     |     CRED_R = AUTH_CRED_AS        |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC+OSCORE request to /token  |                              |
 M03 +--------------------------------->|                              |
     |  - EDHOC message_3               |                              |
     |      ID_CRED_I identifies        |                              |
     |         CRED_I = AUTH_CRED_C     |                              |
     |         by reference             |                              |
     |  --- --- ---                     |                              |
     |  - OSCORE-protected part         |                              |
     |      Token request               |                              |
     |         'req_cnf' identifies     |                              |
     |         AUTH_CRED_C by reference |                              |
     |                                  |                              |
     |                                  |                              |
     |  Token response                  |                              |
     |  (OSCORE-protected message)      |                              |
 M04 |<---------------------------------+                              |
     |  'rs_cnf' specifies              |                              |
     |     AUTH_CRED_RS by value        |                              |
     |                                  |                              |
     |  'ace_profile' specifies the     |                              |
     |  ACE profile "coap_edhoc_oscore" |                              |
     |                                  |                              |
     |  'edhoc_info' specifies:         |                              |
     |     {                            |                              |



Selander, et al.          Expires 23 April 2025                [Page 59]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


     |       e'session_id' : h'01',     |                              |
     |       e'cipher_suites' : 2,      |                              |
     |       e'methods' : 3,            |                              |
     |       e'uri_path' : "/edhoc"     |                              |
     |     }                            |                              |
     |                                  |                              |
     |  In the access token:            |                              |
     |  - the 'cnf' claim specifies     |                              |
     |    AUTH_CRED_C by value          |                              |
     |  - the 'edhoc_info' claim        |                              |
     |    specifies the same as         |                              |
     |    'edhoc_info' above            |                              |
     |                                  |                              |

      Possibly after chain verification, the Client adds AUTH_CRED_RS
      to the set of its trusted peer authentication credentials,
      relying on AS as trusted provider

     |                                  |                              |
     |  EDHOC message_1 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M05 +---------------------------------------------------------------->|
     |                                  |                              |

      Possibly after chain verification, RS adds AUTH_CRED_C
      to the set of its trusted peer authentication credentials,
      relying on AS as trusted provider

     |                                  |                              |
     |  EDHOC message_2                 |                              |
 M06 |<----------------------------------------------------------------+
     |  ID_CRED_R identifies            |                              |
     |     CRED_R = AUTH_CRED_RS        |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC+OSCORE request to /r      |                              |
 M07 +---------------------------------------------------------------->|
     |  - EDHOC message_3               |                              |
     |      EAD_3 contains access token |                              |
     |      ID_CRED_I identifies        |                              |
     |         CRED_I = AUTH_CRED_C     |                              |
     |         by reference             |                              |
     |  --- --- ---                     |                              |
     |  - OSCORE-protected part         |                              |
     |      Application request to /r   |                              |
     |                                  |                              |




Selander, et al.          Expires 23 April 2025                [Page 60]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


      After the EDHOC processing is completed, access control
      is enforced on the rebuilt OSCORE-protected request,
      like if it had been sent stand-alone

     |                                  |                              |
     |  Response                        |                              |
     |  (OSCORE-protected message)      |                              |
 M08 |<----------------------------------------------------------------+
     |                                  |                              |

Appendix B.  Profile Requirements

   This section lists the specifications of this profile based on the
   requirements of the framework, as requested in Appendix C of
   [RFC9200].

   *  Optionally, define new methods for the client to discover the
      necessary permissions and AS for accessing a resource, different
      from the one proposed in [RFC9200]: Not specified

   *  Optionally, specify new grant types: Not specified

   *  Optionally, define the use of client certificates as client
      credential type: C can use authentication credentials of any type
      admitted by the EDHOC protocol, including public key certificates
      such as X.509 and C509 certificates.

   *  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: OSCORE

   *  Specify how the client and RS mutually authenticate: Explicitly,
      by successfully executing the EDHOC protocol, after which a common
      OSCORE Security Context is exported from the EDHOC session.  As
      per the EDHOC authentication method used during the EDHOC session,
      authentication is provided by digital signatures, or by Message
      Authentication Codes (MACs) computed from an ephemeral-static ECDH
      shared secret.

   *  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: proof-of-possession is first achieved by RS
      when successfully processing EDHOC message_3 during the EDHOC
      session with C, through EDHOC algorithms and symmetric EDHOC
      session keys.  Also, proof-of-possession is later achieved by C



Selander, et al.          Expires 23 April 2025                [Page 61]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


      when receiving from RS: i) the optional EDHOC message_4 during the
      EDHOC session with RS, through EDHOC algorithms and symmetric
      EDHOC session keys; or ii) the first response protected with the
      OSCORE Security Context established after the EDHOC session with
      RS, through OSCORE algorithms and OSCORE symmetric keys derived
      from the completed EDHOC session.

   *  Specify a unique ace_profile identifier: coap_edhoc_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 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 methods of token transport other than the
      authz-info endpoint: C can upload the access token when executing
      EDHOC with RS, by including the access token in the EAD_3 field of
      EDHOC message_3 (see Section 4.2).

Appendix C.  CDDL Model

   This section is to be removed before publishing as an RFC.

























Selander, et al.          Expires 23 April 2025                [Page 62]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   ; ACE Profiles
   coap_edhoc_oscore = 4

   ; OAuth Parameters CBOR Mappings
   edhoc_info_param = 47

   ; CBOR Web Token (CWT) Claims
   edhoc_info_claim = 41

   ; CWT Confirmation Methods
   x5chain = 5
   x5bag = 6
   x5t = 7
   x5u = 8
   c5c = 9
   c5b = 10
   c5t = 11
   c5u = 12
   kcwt = 13
   kccs = 14

   ; EDHOC Information
   session_id = 0
   methods = 1
   cipher_suites = 2
   message_4 = 3
   comb_req = 4
   uri_path = 5
   osc_ms_len = 6
   osc_salt_len = 7
   osc_version = 8
   cred_types = 9
   id_cred_types = 10
   eads = 11
   initiator = 12
   responder = 13

                            Figure 8: CDDL model

Appendix D.  Document Updates

   This section is to be removed before publishing as an RFC.

D.1.  Version -05 to -06

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




Selander, et al.          Expires 23 April 2025                [Page 63]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

   *  Defined an EDHOC EAD item for transporting a Session ID.

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

   *  Defined in detail the use of the EDHOC reverse message flow.

   *  Provided details on access token invalidity.

   *  Revised examples with message exchanges.

   *  Clarifications and editorial improvements.

D.2.  Version -04 to -05

   *  CBOR diagnostic notation uses placeholders from a CDDL model.

   *  Only CWTs are supported as access tokens in this profile.

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

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

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

   *  Explicit registration policies for the new IANA registry.

   *  Fixes in the IANA considerations.

   *  Editorial fixes and improvements.

D.3.  Version -03 to -04

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

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

   *  Removed the case of transporting access token in EAD_1

   *  Removed redundant normative text




Selander, et al.          Expires 23 April 2025                [Page 64]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


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

   *  Updated references.

   *  Editorial fixes and improvements.

D.4.  Version -02 to -03

   *  Restructured presentation of content.

   *  Simplified description of the use of EDHOC_Information.

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

   *  Enabled the transport of the access token also in EDHOC EAD_3.

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

   *  Clarifications and editorial improvements.

D.5.  Version -01 to -02

   *  Removed use of EDHOC_KeyUpdate.

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

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

   *  Fixed and updated examples.

   *  Editorial improvements.

D.6.  Version -00 to -01

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

   *  Error handling aligned with EDHOC.

   *  Precise characterization of the EDHOC execution considered for
      EDHOC-KeyUpdate.

   *  Fixed message exchange examples.



Selander, et al.          Expires 23 April 2025                [Page 65]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2024


   *  Added appendix with profile requirements.

   *  Updated references.

   *  Clarifications and editorial improvements.

Acknowledgments

   The authors sincerely thank Christian Amsüss and Carsten Bormann for
   their comments and feedback.

   This work was supported by the Sweden's Innovation Agency VINNOVA
   within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020
   project SIFIS-Home (Grant agreement 952652).

Authors' Addresses

   Göran Selander
   Ericsson
   Email: goran.selander@ericsson.com


   John Preuß Mattsson
   Ericsson
   Email: john.mattsson@ericsson.com


   Marco Tiloca
   RISE
   Email: marco.tiloca@ri.se


   Rikard Höglund
   RISE
   Email: rikard.hoglund@ri.se
















Selander, et al.          Expires 23 April 2025                [Page 66]