



LAKE Working Group                                             M. Tiloca
Internet-Draft                                                R. Höglund
Intended status: Standards Track                                 RISE AB
Expires: 8 January 2026                                      7 July 2025


   Coordinating the Use of Application Profiles for Ephemeral Diffie-
                       Hellman Over COSE (EDHOC)
                    draft-ietf-lake-app-profiles-02

Abstract

   The lightweight authenticated key exchange protocol Ephemeral Diffie-
   Hellman Over COSE (EDHOC) requires certain parameters to be agreed
   out-of-band, in order to ensure its successful completion.  To this
   end, application profiles specify the intended use of EDHOC to allow
   for the relevant processing and verifications to be made.  In order
   to ensure the applicability of such parameters and information beyond
   transport- or setup-specific scenarios, this document defines a
   canonical, CBOR-based representation that can be used to describe,
   distribute, and store EDHOC application profiles.  Furthermore, In
   order to facilitate interoperability between EDHOC implementations
   and support EDHOC extensibility for additional integrations, this
   document defines a number of means to coordinate the use of EDHOC
   application profiles.  Finally, this document defines a set of well-
   known EDHOC application profiles.

Discussion Venues

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

   Discussion of this document takes place on the Lightweight
   Authenticated Key Exchange Working Group mailing list
   (lake@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/lake/.

   Source for this draft and an issue tracker can be found at
   https://github.com/lake-wg/app-profiles.

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



Tiloca & Höglund         Expires 8 January 2026                 [Page 1]

Internet-Draft         EDHOC Application Profiles              July 2025


   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 8 January 2026.

Copyright Notice

   Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  EDHOC_Application_Profile . . . . . . . . . . . . . . . . . .   6
   3.  Identifying EDHOC Application Profiles by Profile ID  . . . .   8
     3.1.  In Web Linking  . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  In the EDHOC_Information Object . . . . . . . . . . . . .  10
       3.2.1.  Use in the EDHOC and OSCORE Profile of the ACE
               Framework . . . . . . . . . . . . . . . . . . . . . .  11
   4.  Additional Parameters for Web Linking . . . . . . . . . . . .  13
   5.  Advertising Supported EDHOC Application Profiles during an
           EDHOC Session . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  In EDHOC Message 1 and Message 2  . . . . . . . . . . . .  15
       5.1.1.  Content Restrictions  . . . . . . . . . . . . . . . .  17
     5.2.  In the EDHOC Error Message  . . . . . . . . . . . . . . .  18
   6.  Advertising Supported EDHOC Application Profiles using SVCB
           Resource Records  . . . . . . . . . . . . . . . . . . . .  19
   7.  Well-known EDHOC Application Profiles . . . . . . . . . . . .  21
     7.1.  Well-Known Application Profile MINIMAL_CS_2 . . . . . . .  22
     7.2.  Well-Known Application Profile MINIMAL_CS_0 . . . . . . .  22
     7.3.  Well-Known Application Profile BASIC_CS_2_X509  . . . . .  22
     7.4.  Well-Known Application Profile BASIC_CS_0_X509  . . . . .  23
     7.5.  Well-Known Application Profile BASIC_CS_2_C509  . . . . .  23
     7.6.  Well-Known Application Profile BASIC_CS_0_C509  . . . . .  23
     7.7.  Well-Known Application Profile INTERMEDIATE_CS_2  . . . .  23
     7.8.  Well-Known Application Profile INTERMEDIATE_CS_0  . . . .  24



Tiloca & Höglund         Expires 8 January 2026                 [Page 2]

Internet-Draft         EDHOC Application Profiles              July 2025


     7.9.  Well-Known Application Profile EXTENSIVE  . . . . . . . .  24
   8.  Identifiers of Well-known EDHOC Application Profiles  . . . .  25
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
     10.1.  Media Type Registrations . . . . . . . . . . . . . . . .  27
     10.2.  CoAP Content-Formats Registry  . . . . . . . . . . . . .  28
     10.3.  Target Attributes Registry . . . . . . . . . . . . . . .  28
     10.4.  EDHOC Information Registry . . . . . . . . . . . . . . .  31
     10.5.  EDHOC External Authorization Data Registry . . . . . . .  31
     10.6.  EDHOC Error Codes Registry . . . . . . . . . . . . . . .  31
     10.7.  DNS SVCB Service Parameter Keys (SvcParamKeys) . . . . .  32
     10.8.  EDHOC Application Profiles Registry  . . . . . . . . . .  32
     10.9.  Expert Review Instructions . . . . . . . . . . . . . . .  33
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  34
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  34
     11.2.  Informative References . . . . . . . . . . . . . . . . .  37
   Appendix A.  CDDL Model . . . . . . . . . . . . . . . . . . . . .  37
   Appendix B.  Document Updates . . . . . . . . . . . . . . . . . .  38
     B.1.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  38
     B.2.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  39
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  40
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

1.  Introduction

   Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] is a lightweight
   authenticated key exchange protocol, especially intended for use in
   constrained scenarios.  A main use case for EDHOC is to establish a
   Security Context for Object Security for Constrained RESTful
   Environments (OSCORE) [RFC8613].

   In order to successfully run EDHOC, the two peers acting as Initiator
   and Responder have to agree on certain parameters.  Some of those are
   in-band and communicated through the protocol execution, during which
   a few of them may even be negotiated.  However, other parameters have
   to be known out-of-band, before running the EDHOC protocol.

   As discussed in Section 3.9 of [RFC9528], applications can use EDHOC
   application profiles, which specify the intended usage of EDHOC to
   allow for the relevant processing and verifications to be made.  In
   particular, an EDHOC application profile may include both in-band and
   out-of-band parameters.

   In order to ensure the applicability of such parameters and
   information beyond transport- or setup-specific scenarios, this
   document also defines the EDHOC_Application_Profile object, i.e., a
   canonical, CBOR-based representation that can be used to describe,
   distribute, and store EDHOC application profiles as CBOR data items



Tiloca & Höglund         Expires 8 January 2026                 [Page 3]

Internet-Draft         EDHOC Application Profiles              July 2025


   (see Section 2).  The defined representation is transport- and setup-
   independent, and avoids the need to reinvent an encoding for the
   available options to run the EDHOC protocol or the selection logic to
   apply on those.

   The CBOR-based representation of an EDHOC application profile can be,
   for example: retrieved as a result of a discovery process; or
   retrieved/provided during the retrieval/provisioning of an EDHOC
   peer's public authentication credential; or obtained during the
   execution of a device on-boarding/registration workflow.

   Furthermore, in order to facilitate interoperability between EDHOC
   implementations and to support EDHOC extensibility for additional
   integrations (e.g., of external security applications, handling of
   authentication credentials, and message transports), this document
   defines a number of means to coordinate the use of EDHOC application
   profiles, that is:

   *  The new IANA registry "EDHOC Application Profiles" defined in
      Section 10.8, where to register integer identifiers of EDHOC
      application profiles to use as corresponding Profile IDs.

   *  The new parameter "ed-prof" defined in Section 3.1.  This
      parameter is employed to specify an EDHOC application profile
      identified by its Profile ID and can be used as target attribute
      in a web link [RFC8288] to an EDHOC resource, or as filter
      criterion in a discovery request to discover EDHOC resources.

      For instance, the target attribute can be used in a link-format
      document [RFC6690] describing EDHOC resources at a server, when
      EDHOC is transferred over the Constrained Application Protocol
      (CoAP) [RFC7252] (see Appendix A.2 of [RFC9528] as well as
      [RFC9668]).

   *  The new parameter "app_prof" defined in Section 3.2 for the
      EDHOC_Information object specified in
      [I-D.ietf-ace-edhoc-oscore-profile].  This parameter is employed
      to specify a set of EDHOC application profiles, each identified by
      its Profile ID.

      For instance, the parameter can be used in the EDHOC and OSCORE
      profile [I-D.ietf-ace-edhoc-oscore-profile] of the ACE framework
      for authentication and authorization in constrained environments
      (ACE) [RFC9200], in order to indicate the EDHOC application
      profiles supported by an ACE resource server.






Tiloca & Höglund         Expires 8 January 2026                 [Page 4]

Internet-Draft         EDHOC Application Profiles              July 2025


      This parameter is also used in the EDHOC_Application_Profile
      object defined in this document, in order to encode the Profile ID
      of the EDHOC application profile described by an instance of that
      object.

   *  Additional parameters that provide information about an EDHOC
      application profile.  These parameters correspond to elements of
      the EDHOC_Information object and are to be used as target
      attributes in a web link to an EDHOC resource, or as filter
      criteria in a discovery request to discover EDHOC resources (see
      Section 4).

   *  A new EDHOC External Authorization Data (EAD) item (see
      Section 5.1) and a new error code for the EDHOC error message (see
      Section 5.2).  When running EDHOC, a peer can use those in order
      to advertise the EDHOC application profiles that it supports to
      the other peer.

   *  The use of SVCB Resource Records (RR) [RFC9460][RFC9461] to
      advertise the support for EDHOC and for EDHOC application profiles
      of a given server (see Section 6).

   Finally, this document defines a set of well-known EDHOC application
   profiles (see Section 7).  These application profiles are meant to
   reflect what is most common and expected to be supported by EDHOC
   peers, while they are not to be intended as "default" application
   profiles or as a deviation from what is mandatory to support for
   EDHOC peers (see Section 8 of [RFC9528]).  On the other hand, they
   provide implementers and users with a quick overview of the several
   available options to run the EDHOC protocol and of their most
   expected combinations.

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.

   The reader is expected to be familiar with terms and concepts defined
   in EDHOC [RFC9528], and with the use of EDHOC with CoAP [RFC7252] and
   OSCORE [RFC8613] defined in [RFC9668].

   Concise Binary Object Representation (CBOR) [RFC8949] 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.



Tiloca & Höglund         Expires 8 January 2026                 [Page 5]

Internet-Draft         EDHOC Application Profiles              July 2025


   CBOR data items are represented using the CBOR extended diagnostic
   notation as defined in Section 8 of [RFC8949] and Appendix G of
   [RFC8610] ("diagnostic notation").  Diagnostic notation comments are
   used to provide a textual representation of the parameters' keys and
   values.

   In the CBOR diagnostic notation used in this document, constructs of
   the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME
   in the CDDL model shown in Figure 6 of Appendix A.  For example,
   {e'methods' : [0, 1, 2, 3], e'cipher_suites': 3} stands for {1 : [0,
   1, 2, 3], 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 6
   of Appendix A.  Finally, please delete this note.

2.  EDHOC_Application_Profile

   This section defines the EDHOC_Application_Profile object, which can
   be used as a canonical representation of EDHOC application profiles
   for their description, distribution, and storage.

   An EDHOC_Application_Profile object is encoded as a CBOR map
   [RFC8949].  All elements that can be included in the
   EDHOC_Application_Profile object are elements that can be included in
   the CBOR-encoded EDHOC_Information object specified in Section 3.4 of
   [I-D.ietf-ace-edhoc-oscore-profile].  In particular, they use the
   same CBOR abbreviations from the 'CBOR label' column of the IANA
   registry "EDHOC Information" defined in
   [I-D.ietf-ace-edhoc-oscore-profile].

   By construction, an EDHOC_Application_Profile object conveys
   information that pertains to the execution of EDHOC.  This includes,
   e.g., information about transporting and processing EDHOC messages
   during an EDHOC session.  An EDHOC_Application_Profile object does
   not convey information that does not play a role in completing an
   EDHOC execution.  For instance, this includes the size of outputs of
   the EDHOC_Exporter interface (see Section 4.2.1 of [RFC9528]), or
   properties and features of protocols other than EDHOC itself that
   build on the results from an EDHOC session (e.g., the version of the
   application protocol subsequently used).

   The CBOR map encoding an EDHOC_Application_Profile object MUST
   include the element "app_prof" defined in Section 3.2 of this
   document, as well as the elements "methods" and "cred_types" defined
   in Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].



Tiloca & Höglund         Expires 8 January 2026                 [Page 6]

Internet-Draft         EDHOC Application Profiles              July 2025


   The value of the element "app_prof" is the unique identifier of the
   EDHOC application profile described by the instance of the
   EDHOC_Application_Profile object in question.  The identifier is
   taken from the 'Profile ID' column of the "EDHOC Application
   Profiles" registry defined in this document and encoded as a CBOR
   integer.

   The CBOR map MUST NOT include the following elements: "session_id",
   "uri_path", "initiator", "responder", and "trust_anchors".  A
   consumer MUST ignore those elements if they are included in the
   EDHOC_Application_Profile object.

   The CBOR map MAY include other elements.

   Furthermore, consistent with Sections 8 and A.1 of [RFC9528] and with
   Section 5.4 of [RFC8613], the following applies:

   *  If the element "cipher_suites" is not present in the CBOR map,
      this indicates that the EDHOC application profile uses the EDHOC
      cipher suites 2 and 3, and possibly other cipher suites.

   *  If the element "id_cred_types" is not present in the CBOR map,
      this indicates that the EDHOC application profile uses "kid" as
      type of authentication credential identifiers for EDHOC, and
      possibly other types of authentication credential identifiers.

   *  The absence of any other elements in the CBOR map MUST NOT result
      in assuming any value.

   If an element is present in the CBOR map and the corresponding entry
   in the IANA registry "EDHOC Information" specifies "NP" (non-
   prescriptive) in the 'Type' column and "True or False" in the 'CBOR
   type' column, then the following applies.  An EDHOC peer that adheres
   to the EDHOC application profile in question is required or not to
   support the property or feature of EDHOC associated with the element
   in the CBOR map, if that element encodes the CBOR simple value true
   (0xf5) or false (0xf4), respectively.  For example, the presence of
   the parameter "comb_req" denotes whether EDHOC peers adhering to the
   EDHOC application profile have to support the EDHOC + OSCORE combined
   request defined in [RFC9668], or instead do not have to but might if
   they are willing to.

   If an element present in the CBOR map specifies an information that
   is intrinsically a set of one or more co-existing alternatives, then
   all the specified alternatives apply for the EDHOC application
   profile in question.  For example, the element "cipher_suites" with
   value the CBOR array [0, 2] means that, in order to adhere to the
   EDHOC application profile in question, an EDHOC peer has to implement



Tiloca & Höglund         Expires 8 January 2026                 [Page 7]

Internet-Draft         EDHOC Application Profiles              July 2025


   both the EDHOC cipher suites 0 and 2, because either of them can be
   used by another EDHOC peer also adhering to the same EDHOC
   application profile.

   The CDDL grammar describing the EDHOC_Application_Profile object is:

   EDHOC_Application_Profile = {
         1 => int / array,    ; methods
         6 => int / array,    ; cred_types
        23 => int,            ; app_prof
      * int / tstr => any
   }

     Figure 1: CDDL Definition of the EDHOC_Application_Profile object

3.  Identifying EDHOC Application Profiles by Profile ID

   This document introduces the concept of Profile IDs, i.e., integer
   values that uniquely identify EDHOC application profiles, for which
   an IANA registry is defined in Section 10.8.

   This section defines two parameters to convey such Profile IDs, i.e.:

   *  The parameter "ed-prof" for web linking [RFC8288] (see
      Section 3.1).

   *  The parameter "app_prof" of the EDHOC_Information object specified
      in [I-D.ietf-ace-edhoc-oscore-profile] (see Section 3.2).

      As defined in Section 2, Profile IDs are also conveyed by the
      parameter "app_prof" in the EDHOC_Application_Profile object, in
      order to identify the EDHOC application profile described by a
      given instance of that object.

   As defined later in this document, Profile IDs can be used to
   identify EDHOC application profiles also:

   *  Within certain EDHOC messages sent during an EDHOC session by a
      peer that supports such EDHOC application profiles (see
      Section 5).

   *  When using SVCB Resource Records (RR) [RFC9460][RFC9461] to
      advertise the support for EDHOC and for EDHOC application profiles
      of a given server (see Section 6).







Tiloca & Höglund         Expires 8 January 2026                 [Page 8]

Internet-Draft         EDHOC Application Profiles              July 2025


3.1.  In Web Linking

   Section 6 of [RFC9668] defines a number of target attributes that can
   be used in a web link [RFC8288] with resource type "core.edhoc" (see
   Section 10.10 of [RFC9528]).  This is the case, e.g., when using a
   link-format document [RFC6690] describing EDHOC resources at a
   server, when EDHOC is transferred over CoAP [RFC7252] as defined in
   Appendix A.2 of [RFC9528].  This allows a client to obtain relevant
   information about the EDHOC application profile(s) to be used with a
   certain EDHOC resource.

   In the same spirit, this section defines the following additional
   parameter, which can be optionally specified as a target attribute
   with the same name in the link to the respective EDHOC resource, or
   among the filter criteria in a discovery request from a client.

   *  'ed-prof', specifying an EDHOC application profile supported by
      the server.  This parameter MUST specify a single value, which is
      taken from the 'Profile ID' column of the "EDHOC Application
      Profiles" registry defined in Section 10.8 of this document.  This
      parameter MAY occur multiple times, with each occurrence
      specifying an EDHOC application profile.

   When specifying the parameter 'ed-prof' in a link to an EDHOC
   resource, the target attribute rt="core.edhoc" MUST be included.

   If a link to an EDHOC resource includes occurrences of the target
   attribute 'ed-prof', then the following applies.

   *  The link MUST NOT include other target attributes that provide
      information about an EDHOC application profile (see, e.g.,
      Section 6 of [RFC9668] and Section 4 of this document), with the
      exception of the target attribute 'ed-ead' that MAY be included.

      The recipient MUST ignore other target attributes that provide
      information about an EDHOC application profile, with the exception
      of the target attribute 'ed-ead'.

   *  If the link includes occurrences of the target attribute 'ed-ead',
      the link provides the following information: when using the target
      EDHOC resource as per the EDHOC application profile indicated by
      any occurrence of the target attribute 'ed-prof', the server
      supports the External Authorization Data (EAD) items that are
      specified in the definition of that EDHOC application profile, as
      well as the EAD items indicated by the occurrences of the target
      attribute 'ed-ead'.





Tiloca & Höglund         Expires 8 January 2026                 [Page 9]

Internet-Draft         EDHOC Application Profiles              July 2025


   The example in Figure 2 shows how a CoAP client discovers two EDHOC
   resources at a CoAP server, and obtains information about the
   application profile corresponding to each of those resources.  The
   Link Format notation from Section 5 of [RFC6690] is used.

   The example assumes the existence of an EDHOC application profile
   identified by the integer Profile ID 500, which is supported by the
   EDHOC resource at /edhoc-alt and whose definition includes the
   support for the EAD items with EAD label 111 and 222.

   Therefore, the link to the EDHOC resource at /edhoc-alt indicates
   that, when using that EDHOC resource as per the EDHOC application
   profile with Profile ID 500, the server supports the EAD items with
   EAD label 111, 222, and 333.

      REQ: GET /.well-known/core

      RES: 2.05 Content
          </sensors/temp>;osc,
          </sensors/light>;if=sensor,
          </.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;
              ed-method=0;ed-cred-t=1;ed-cred-t=3;ed-idcred-t=4;
              ed-i;ed-r;ed-comb-req,
          </edhoc-alt>;rt=core.edhoc;ed-prof=500;ed-ead=333

                          Figure 2: The Web Link.

3.2.  In the EDHOC_Information Object

   Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile] defines the
   EDHOC_Information object, as including information that guides two
   peers towards executing the EDHOC protocol, and defines an initial
   set of its parameters.

   This document defines the new parameter "app_prof" of the
   EDHOC_Information object, as summarized in Table 1 and described
   further below.

   +==========+=======+========+===================+===================+
   | Name     | CBOR  | CBOR   | Registry          | Description       |
   |          | label | type   |                   |                   |
   +==========+=======+========+===================+===================+
   | app_prof | 23    | int    | EDHOC Application | Set of supported  |
   |          |       | or     | Profiles Registry | EDHOC Application |
   |          |       | array  |                   | Profiles          |
   +----------+-------+--------+-------------------+-------------------+

              Table 1: EDHOC_Information Parameter "app_prof"



Tiloca & Höglund         Expires 8 January 2026                [Page 10]

Internet-Draft         EDHOC Application Profiles              July 2025


   *  app_prof: This parameter specifies a set of supported EDHOC
      application profiles, identified by their Profile ID.  If the set
      is composed of a single EDHOC application profile, its Profile ID
      is encoded as an integer.  Otherwise, the set is encoded as an
      array of integers, where each array element encodes one Profile
      ID.  In JSON, the "app_prof" value is an integer or an array of
      integers.  In CBOR, "app_prof" is an integer or an array of
      integers, and has label 23.  The integer values are taken from the
      'Profile ID' column of the "EDHOC Application Profiles" registry
      defined in Section 10.8 of this document.

3.2.1.  Use in the EDHOC and OSCORE Profile of the ACE Framework

   Section 3 of [I-D.ietf-ace-edhoc-oscore-profile] defines how the
   EDHOC_Information object can be used within the workflow of the EDHOC
   and OSCORE transport profile of the ACE framework for authentication
   and authorization in constrained environments (ACE) [RFC9200].

   In particular, the AS-to-C Access Token Response includes the
   parameter "edhoc_info", with value an EDHOC_Information object.  This
   allows the ACE authorization server (AS) to provide the ACE client
   (C) with information about how to run the EDHOC protocol with the ACE
   resource server (RS) for which the access token is issued.

   Similarly, the access token includes the corresponding claim
   "edhoc_info", with value an EDHOC_Information object.  This allows
   the AS to provide the ACE RS with information about how to run the
   EDHOC protocol with the ACE client, according to the issued access
   token.

   In turn, the EDHOC_Information object can include the parameter
   "app_prof" defined in this document.  This parameter indicates a set
   of EDHOC application profiles associated with the EDHOC resource to
   use at the RS, which is either implied or specified by the parameter
   "uri_path" within the same EDHOC_Information object.

   If the EDHOC_Information object specified as value of "edhoc_info"
   includes the "app_prof" parameter, then the following applies.

   *  The object MUST NOT include other parameters, with the following
      exceptions:

      -  The parameter "eads".

      -  The parameters that are not allowed in the
         EDHOC_Application_Profile object defined in Section 2.





Tiloca & Höglund         Expires 8 January 2026                [Page 11]

Internet-Draft         EDHOC Application Profiles              July 2025


         These include the parameter "session_id", which the
         EDHOC_Information object has to include (see Sections 3.3 and
         3.3.1 of [I-D.ietf-ace-edhoc-oscore-profile]).

      C and RS MUST ignore other parameters that are not admitted if
      they are present in the EDHOC_Information object.

   *  The object might provide an information that corresponds to an
      EDHOC_Information prescriptive parameter (see Section 3.4 of
      [I-D.ietf-ace-edhoc-oscore-profile]), e.g., "message_4" or
      "max_msgsize".  The type of a parameter is indicated in the 'Type'
      column of the corresponding entry in the IANA registry "EDHOC
      Information" (see [I-D.ietf-ace-edhoc-oscore-profile]).

      If the object specifies such an information multiple times, then
      each occurrence of that information MUST convey exactly the same
      content.  This MUST take into account prescriptive parameters that
      are included: i) as elements of the EDHOC_Information object; or
      ii) as elements of an EDHOC_Application_Profile object (see
      Section 2) encoding an EDHOC application profile, which is
      identified by its Profile ID specified in the "app_prof" parameter
      of the EDHOC_Information object.

      A consumer MUST treat as malformed an EDHOC_Information object
      that does not comply with the restriction above.

   *  If the EDHOC_Information object specified in the parameter
      "edhoc_info" of the AS-to-C Access Token Response includes the
      parameter "eads", then the following applies.

      When using the target EDHOC resource as per any EDHOC application
      profile indicated by the parameter "app_prof", the ACE RS for
      which the access token is issued supports the EAD items that are
      specified in the definition of that EDHOC application profile, as
      well as the EAD items indicated by the parameter "eads".

   *  If the EDHOC_Information object specified in the claim
      "edhoc_info" of the access token includes the parameter "eads",
      then the following applies.

      When using the target EDHOC resource as per any EDHOC application
      profile indicated by the parameter "app_prof", the ACE client to
      which the access token is issued supports the EAD items that are
      specified in the definition of that EDHOC application profile, as
      well as the EAD items indicated by the parameter "eads".






Tiloca & Höglund         Expires 8 January 2026                [Page 12]

Internet-Draft         EDHOC Application Profiles              July 2025


4.  Additional Parameters for Web Linking

   Building on what is defined and prescribed in Section 6 of [RFC9668],
   this section defines additional parameters for web linking [RFC8288],
   which can be used to obtain relevant pieces of information from the
   EDHOC application profile associated with an EDHOC resource.

   These parameters can be optionally specified as target attributes
   with the same name in a link with resource type "core.edhoc" (see
   Section 10.10 of [RFC9528]) targeting an EDHOC resource, or as filter
   criteria in a discovery request from a client.

   When specifying any of the parameters defined below in a link to an
   EDHOC resource, the target attribute rt="core.edhoc" MUST be
   included.

   *  'ed-max-msgsize', specifying the admitted maximum size of EDHOC
      messages in bytes.  This parameter MUST specify a single unsigned
      integer value.

   *  'ed-coap-ct', specifying that CoAP messages have to include the
      CoAP Content-Format Option with value 64 (application/edhoc+cbor-
      seq) or 65 (application/cid-edhoc+cbor-seq) as appropriate, when
      the message payload includes exclusively an EDHOC message possibly
      prepended by an EDHOC connection identifier (see Sections 3.4.1
      and A.2 of [RFC9528]).  A value MUST NOT be given to this
      parameter and any present value MUST be ignored by the recipient.

   *  'ed-epid-t', specifying a type of endpoint identity for EDHOC
      supported by the server.  This parameter MUST specify a single
      value, which is taken from the 'CBOR Label' column of the "EDHOC
      Endpoint Identity Types" registry defined in
      [I-D.ietf-ace-edhoc-oscore-profile].  This parameter MAY occur
      multiple times, with each occurrence specifying a type of endpoint
      identity for EDHOC.

   *  'ed-tp', specifying a means for transporting EDHOC messages
      supported by the server.  This parameter MUST specify a single
      value, which is taken from the 'Transport ID' column of the "EDHOC
      Transports" registry defined in
      [I-D.ietf-ace-edhoc-oscore-profile].  This parameter MAY occur
      multiple times, with each occurrence specifying a means for
      transporting EDHOC messages.

   *  'ed-ta-edcred-uuid', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a UUID [RFC9562].  This parameter MUST
      specify a single value, which is the UUID in its string format



Tiloca & Höglund         Expires 8 January 2026                [Page 13]

Internet-Draft         EDHOC Application Profiles              July 2025


      (see Section 4 of [RFC9562]).  This parameter MAY occur multiple
      times, with each occurrence specifying one trust anchor
      identifier.

   *  'ed-ta-edcred-kid', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a binary key identifier.  This parameter
      MUST specify a single value, which is the base64url-encoded text
      string of the binary representation of the key identifier.  This
      parameter MAY occur multiple times, with each occurrence
      specifying one trust anchor identifier.

   *  'ed-ta-edcred-c5t', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a hash of a C509 certificate
      [I-D.ietf-cose-cbor-encoded-cert].  This parameter MUST specify a
      single value, which is the base64url-encoded text string of the
      binary representation of the certificate hash encoded as a
      COSE_CertHash [RFC9360].  This parameter MAY occur multiple times,
      with each occurrence specifying one trust anchor identifier.

   *  'ed-ta-edcred-c5u', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a URI [RFC3986] pointing to a C509
      certificate [I-D.ietf-cose-cbor-encoded-cert].  This parameter
      MUST specify a single value, which is the URI pointing to the
      certificate.  This parameter MAY occur multiple times, with each
      occurrence specifying one trust anchor identifier.

   *  'ed-ta-edcred-x5t', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a hash of an X.509 certificate [RFC5280].
      This parameter MUST specify a single value, which is the
      base64url-encoded text string of the binary representation of the
      certificate hash encoded as a COSE_CertHash [RFC9360].  This
      parameter MAY occur multiple times, with each occurrence
      specifying one trust anchor identifier.

   *  'ed-ta-edcred-x5u', specifying the identifier of a trust anchor
      supported by the server for verifying authentication credentials
      of other EDHOC peers, as a URI [RFC3986] pointing to an X.509
      certificate [RFC5280].  This parameter MUST specify a single
      value, which is the URI pointing to the certificate.  This
      parameter MAY occur multiple times, with each occurrence
      specifying one trust anchor identifier.






Tiloca & Höglund         Expires 8 January 2026                [Page 14]

Internet-Draft         EDHOC Application Profiles              July 2025


5.  Advertising Supported EDHOC Application Profiles during an EDHOC
    Session

   The rest of this section defines means that an EDHOC peer can use in
   order to advertise the EDHOC application profiles that it supports to
   another EDHOC peer, when running EDHOC with that other peer.

   Such means are an EDHOC EAD item (see Section 5.1) and an error code
   for the EDHOC error message (see Section 5.2).

5.1.  In EDHOC Message 1 and Message 2

   This section defines the EDHOC EAD item "Supported EDHOC application
   profiles", which is registered in Section 10.5 of this document.

   The EAD item MAY be included:

   *  In the EAD_1 field of EDHOC message_1, in order to specify EDHOC
      application profiles supported by the Initiator.

   *  In the EAD_2 field of EDHOC message_2, in order to specify EDHOC
      application profiles supported by the Responder.

   When the EAD item is present, its ead_label TBD_EAD_LABEL MUST be
   used only with negative sign, i.e., the use of the EAD item is always
   critical (see Section 3.8 of [RFC9528]).

   The EAD item MUST NOT occur more than once in the EAD fields of EDHOC
   message_1 or message_2.  The recipient peer MUST abort the EDHOC
   session and MUST reply with an EDHOC error message if the EAD item
   occurs multiple times in the EAD fields of EDHOC message_1 or
   message_2.

   The EAD item MUST NOT be included in the EAD fields of EDHOC
   message_3 or message_4.  In case the recipient peer supports the EAD
   item, the recipient peer MUST silently ignore the EAD item if this is
   included in the EAD fields of EDHOC message_3 or message_4.

   The EAD item MUST specify an ead_value, as a CBOR byte string with
   value the binary representation of a CBOR sequence [RFC8742], namely
   APP_PROF_SEQ.  The CBOR sequence is composed of one or more items,
   whose order has no meaning.

   Each item of the CBOR sequence MUST be either of the following:







Tiloca & Höglund         Expires 8 January 2026                [Page 15]

Internet-Draft         EDHOC Application Profiles              July 2025


   *  A CBOR integer, specifying the Profile ID of an EDHOC application
      profile.  The integer value is taken from the 'Profile ID' column
      of the "EDHOC Application Profiles" registry defined in
      Section 10.8 of this document.

      This item of the CBOR sequence indicates that the message sender
      supports the EDHOC application profile identified by the Profile
      ID.

   *  A CBOR array including at least one element.  In particular:

      -  The first element MUST be a CBOR integer, specifying the
         Profile ID of an EDHOC application profile.  The integer value
         is taken from the 'Profile ID' column of the "EDHOC Application
         Profiles" registry.

      -  Each of the elements following the first one MUST be a CBOR
         unsigned integer, specifying the ead_label of an EAD item.

      This item of the CBOR sequence indicates that the message sender
      supports:

      -  The EDHOC application profile PROFILE identified by the Profile
         ID in the first element of the array; and

      -  The EAD items identified by the ead_label in the elements
         following the first one, in addition to the EAD items that are
         specified in the definition of the EDHOC application profile
         PROFILE.

   *  An EDHOC_Information object encoded in CBOR, i.e., as a CBOR map
      (see Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile]).

      The EDHOC_Information object MUST NOT include the element
      "app_prof" and MUST NOT include elements that are not allowed
      within the EDHOC_Application_Profile object defined in Section 2,
      with the exception of the element "trust_anchor" that MAY be
      included.  The recipient peer MUST ignore elements that are not
      allowed if they are present in the EDHOC_Information object.

      This item of the CBOR sequence indicates that the message sender
      supports an EDHOC application profile consistent with the pieces
      of information specified by the EDHOC_Information object.

   When composing ead_value, the sender peer MUST comply with the
   content restrictions specified in Section 5.1.1.





Tiloca & Höglund         Expires 8 January 2026                [Page 16]

Internet-Draft         EDHOC Application Profiles              July 2025


   The recipient peer MUST abort the EDHOC session and MUST reply with
   an EDHOC error message if ead_value is malformed or does not conform
   with the format defined above.

   The CDDL grammar describing ead_value for the EAD item "Supported
   EDHOC application profiles" is shown in Figure 3.

   ead_value = << APP_PROF_SEQ >>

   ; This defines an array, the elements of which
   ; are to be used in the CBOR Sequence APP_PROF_SEQ:
   APP_PROF_SEQ = [1* element]

   element = profile_id / profile_id_with_eads / EDHOC_Information

   profile_id = int

   profile_id_with_eads = [profile_id, 1* uint]

   ; The full definition is provided in
   ; draft-ietf-ace-edhoc-oscore-profile
   EDHOC_Information : map

          Figure 3: CDDL Definition of ead_value for the EAD item
                   "Supported EDHOC application profiles"

5.1.1.  Content Restrictions

   When the sender peer composes ead_value of the EDHOC EAD item
   "Supported EDHOC application profiles", the following applies.

   It is possible that ead_value provides an information that
   corresponds to an EDHOC_Information prescriptive parameter (see
   Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile]), e.g.,
   "message_4" or "max_msgsize".  The type of such a parameter is
   indicated in the 'Type' column of the corresponding entry in the IANA
   registry "EDHOC Information" (see
   [I-D.ietf-ace-edhoc-oscore-profile]).

   If ead_value specifies such an information multiple times, then each
   occurrence of that information MUST convey exactly the same content.
   With reference to the CBOR sequence APP_PROF_SEQ defined in
   Section 5.1, the enforcement of these content restrictions MUST take
   into account prescriptive parameters that are included:

   *  As elements of an EDHOC_Information object specified within
      APP_PROF_SEQ; or




Tiloca & Höglund         Expires 8 January 2026                [Page 17]

Internet-Draft         EDHOC Application Profiles              July 2025


   *  As elements of an EDHOC_Application_Profile object encoding an
      EDHOC application profile, which is identified by its Profile ID
      specified within APP_PROF_SEQ.

   If the Responder receives the EAD item in the EAD_1 field of EDHOC
   message_1 and intends to include the EAD item in the EAD_2 field of
   EDHOC message_2, then the Responder MUST further take into account
   the presence of such information in the received EAD item when
   composing ead_value.

   A consumer MUST treat as malformed an EDHOC_Information object that
   does not comply with the restrictions above.

5.2.  In the EDHOC Error Message

   This section defines the error code TBD_ERROR_CODE, which is
   registered in Section 10.6 of this document.

   Error code TBD_ERROR_CODE MUST only be used when replying to EDHOC
   message_1.  If an EDHOC error message with error code TBD_ERROR_CODE
   is received as reply to an EDHOC message different from EDHOC
   message_1, then the recipient of the error message MUST ignore what
   is specified in ERR_INFO.

   The Responder MUST NOT abort an EDHOC session exclusively due to the
   wish of sending an error message with error code TBD_ERROR_CODE.
   Instead, the Responder can advertise the EDHOC application profiles
   that it supports to the Initiator by means of the EAD item "Supported
   EDHOC application profiles" defined in Section 5.1, specifying it in
   the EAD_2 field of the EDHOC message_2 to send in the EDHOC session.

   When replying to an EDHOC message_1 with an error message, the
   Responder has to consider the reason for which it is aborting the
   EDHOC session and MUST NOT specify error code TBD_ERROR_CODE if a
   different, more appropriate error code can be specified instead.  For
   example, if the negotiation of the selected cipher suite fails (see
   Section 6.3 of [RFC9528]), the error message MUST NOT specify error
   code TBD_ERROR_CODE, since the error message intended to be used in
   that case specifies error code 2 (Wrong selected cipher suite) and
   conveys SUITES_R as ERR_INFO.

   When using error code TBD_ERROR_CODE, the error information specified
   in ERR_INFO MUST be a CBOR byte string with value the binary
   representation of a CBOR sequence APP_PROF_SEQ.  This CBOR sequence
   has the same format and semantics of the one used for ead_value of
   the EAD item "Supported EDHOC application profiles" (see
   Section 5.1).




Tiloca & Höglund         Expires 8 January 2026                [Page 18]

Internet-Draft         EDHOC Application Profiles              July 2025


   The recipient peer MUST silently ignore elements of the CBOR sequence
   APP_PROF_SEQ that are malformed or do not conform with the intended
   format.

6.  Advertising Supported EDHOC Application Profiles using SVCB Resource
    Records

   Given a server, its support for EDHOC and for EDHOC application
   profiles can be advertised using SVCB Resource Records (RR)
   [RFC9460][RFC9461].

   To this end, this document specifies the SvcParamKeys "edhocpath" and
   "edhoc-app-prof", which are defined below and are registered in
   Section 10.7.

   *  "edhocpath" - The SvcParamKey "edhocpath" is single-valued and its
      value MUST be a CBOR data item PATH_OUTER, which MUST be a CBOR
      byte string PATH_BSTR or a CBOR array.  In the latter case, the
      array MUST include at least two elements, each of which MUST be a
      CBOR byte string PATH_BSTR.  The SVCB RR MUST be considered
      malformed if the SvcParamValue ends within PATH_OUTER or if
      PATH_OUTER is malformed.

      The value of each CBOR byte string PATH_BSTR is the binary
      representation of a CBOR sequence PATH_SEQ composed of zero or
      more CBOR text strings.  In particular, each PATH_SEQ specifies
      the URI path of an EDHOC resource at the server, with each CBOR
      text string within that PATH_SEQ specifying a URI path segment.

      If PATH_OUTER is a CBOR array, it MUST NOT include any two
      elements that specify the same URI path.

      The CDDL grammar describing the value of the SvcParamKey
      "edhocpath" is shown in Figure 4.

      Editor's note: consider to add the same explanation about the
      chosen encoding for the URI path as a CBOR sequence that is given
      in Section 3.2 of draft-ietf-core-dns-over-coap-15.

   *  "edhoc-app-prof" - The SvcParamKey "edhoc-app-prof" is single-
      valued and its value MUST be a CBOR data item APP_OUTER, which
      MUST be a CBOR byte string APP_BSTR or a CBOR array.  In the
      latter case, the array MUST include at least two elements, each of
      which MUST be a CBOR byte string APP_BSTR.  The SVCB RR MUST be
      considered malformed if the SvcParamValue ends within APP_OUTER or
      if APP_OUTER is malformed.





Tiloca & Höglund         Expires 8 January 2026                [Page 19]

Internet-Draft         EDHOC Application Profiles              July 2025


      The value of each CBOR byte string APP_BSTR is the binary
      representation of a CBOR sequence APP_PROF_SEQ, which has the same
      format and semantics specified in Section 5.1.  The SVCB RR MUST
      be considered malformed if APP_PROF_SEQ is malformed or does not
      conform with the format defined in Section 5.1.

      The CDDL grammar describing the value of the SvcParamKey "edhoc-
      app-prof" is shown in Figure 5.

      Each CBOR sequence APP_PROF_SEQ specifies a set of EDHOC
      application profiles that the server supports.

   If the SvcParamKey "edhoc-app-prof" is not present in the SVCB RR,
   then the SvcParamKey "edhocpath", if present, specifies the URI paths
   of EDHOC resources at the server.

   If the SvcParamKey "edhoc-app-prof" is present in the SVCB RR, then
   the following applies.

   *  If the SvcParamKey "edhocpath" is not present in the SVCB RR, then
      the value of the SvcParamKey "edhoc-app-prof" MUST be a CBOR byte
      string.

      The information specified by the SvcParamKey "edhoc-app-prof"
      pertains to the EDHOC resource at the server with URI path
      "/.well-known/edhoc".

   *  If the SvcParamKey "edhocpath" is present in the SVCB RR, then the
      following applies.

      -  If the value of the SvcParamKey "edhocpath" is a CBOR byte
         string, then the value of the SvcParamKey "edhoc-app-prof" MUST
         also be a CBOR byte string.

         The information specified by the SvcParamKey "edhoc-app-prof"
         pertains to the EDHOC resource at the server with URI path
         specified by the SvcParamKey "edhocpath".

      -  If the value of the SvcParamKey "edhocpath" is a CBOR array
         including N elements, then the value of the SvcParamKey "edhoc-
         app-prof" MUST also be a CBOR array including N elements.

         The information specified by the i-th element of the CBOR array
         within the SvcParamKey "edhoc-app-prof" pertains to the EDHOC
         resource at the server with URI path specified by the i-th
         element of the CBOR array within the SvcParamKey "edhocpath".





Tiloca & Höglund         Expires 8 January 2026                [Page 20]

Internet-Draft         EDHOC Application Profiles              July 2025


   A consumer MUST treat as malformed an SVCB RR, in case the
   SvcParamKeys "edhocpath" and "edhoc-app-prof", if present, do not
   comply with the format and restrictions defined above.

   edhocpath-value = PATH_OUTER

   PATH_OUTER = PATH_BSTR / [2* PATH_BSTR]

   PATH_BSTR = << PATH_SEQ >>

   ; This defines an array, the elements of which
   ; are to be used in the CBOR Sequence PATH_SEQ:
   PATH_SEQ = [* path_segment]

   path_segment = tstr

   Figure 4: CDDL Definition of the value of the SvcParamKey "edhocpath"

   edhoc-app-prof-value = APP_OUTER

   APP_OUTER = APP_BSTR / [2* APP_BSTR]

   ; The full definition of APP_PROF_SEQ
   ; is provided in Section 5.1
   APP_BSTR = << APP_PROF_SEQ >>

     Figure 5: CDDL Definition of the value of the SvcParamKey "edhoc-
                                 app-prof"

7.  Well-known EDHOC Application Profiles

   This section defines a set of well-known EDHOC application profiles
   that are meant to reflect what is most common and expected to be
   supported by EDHOC peers.

   The well-known application profiles are _not_ to be intended as
   "default" profiles to use, in case no other indication is provided to
   EDHOC peers.

   In particular, an EDHOC peer MUST NOT assume that, unless otherwise
   indicated, any of such profiles is used when running EDHOC through a
   well-known EDHOC resource, such as the resource at /.well-known/edhoc
   when EDHOC messages are transported as payload of CoAP messages (see
   Appendix A.2 of [RFC9528]).







Tiloca & Höglund         Expires 8 January 2026                [Page 21]

Internet-Draft         EDHOC Application Profiles              July 2025


   Building on the above, the well-known application profiles are _not_
   intended to deviate from what is mandatory to support for EDHOC
   peers, which is defined by the compliance requirements in Section 8
   of [RFC9528].

   The rest of this section defines the well-known application profiles,
   each of which is represented by means of an EDHOC_Application_Profile
   object (see Section 2) using the CBOR extended diagnostic notation.

   An entry for each well-known application profile is also registered
   at the "EDHOC Application Profiles" registry defined in Section 10.8
   of this document.

7.1.  Well-Known Application Profile MINIMAL_CS_2

   {
           e'methods' : 3, / EDHOC Method Type 3 /
     e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
        e'cred_types' : 1, / CWT Claims Set (CCS) /
     e'id_cred_types' : 4, / kid /
          e'app_prof' : e'APP-PROF-MINIMAL-CS-2'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 3 of [RFC9529].

7.2.  Well-Known Application Profile MINIMAL_CS_0

   {
           e'methods' : 3, / EDHOC Method Type 3 /
     e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
        e'cred_types' : 1, / CWT Claims Set (CCS) /
     e'id_cred_types' : 4, / kid /
          e'app_prof' : e'APP-PROF-MINIMAL-CS-0'
   }

7.3.  Well-Known Application Profile BASIC_CS_2_X509

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
        e'cred_types' : [1, 2], / CWT Claims Set (CCS)
                                and X.509 certificate /
     e'id_cred_types' : [4, 34], / kid and x5t /
          e'app_prof' : e'APP-PROF-BASIC-CS-2-X509'
   }





Tiloca & Höglund         Expires 8 January 2026                [Page 22]

Internet-Draft         EDHOC Application Profiles              July 2025


   This application profile is aligned with the example trace of EDHOC
   compiled in Section 3 of [RFC9529].

7.4.  Well-Known Application Profile BASIC_CS_0_X509

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
        e'cred_types' : [1, 2], / CWT Claims Set (CCS)
                                and X.509 certificate /
     e'id_cred_types' : [4, 34], / kid and x5t /
          e'app_prof' : e'APP-PROF-BASIC-CS-0-X509'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 2 of [RFC9529].

7.5.  Well-Known Application Profile BASIC_CS_2_C509

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
        e'cred_types' : [1, e'c509_cert'], / CWT Claims Set (CCS)
                                           and C509 certificate /
     e'id_cred_types' : [4, e'c5t'], / kid and c5t /
          e'app_prof' : e'APP-PROF-BASIC-CS-2-C509'
   }

7.6.  Well-Known Application Profile BASIC_CS_0_C509

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
        e'cred_types' : [1, e'c509_cert'], / CWT Claims Set (CCS)
                                           and C509 certificate /
     e'id_cred_types' : [4, e'c5t'], / kid and c5t /
          e'app_prof' : e'APP-PROF-BASIC-CS-0-C509'
   }

7.7.  Well-Known Application Profile INTERMEDIATE_CS_2











Tiloca & Höglund         Expires 8 January 2026                [Page 23]

Internet-Draft         EDHOC Application Profiles              July 2025


   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 2, / EDHOC Cipher Suite 2 /
        e'cred_types' : [1, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                              X.509 certificate,
                                              and C509 certificate /
     e'id_cred_types' : [4, 14, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                         x5t, x5chain,
                                                         c5t, and c5c /
          e'app_prof' : e'APP-PROF-INTERMEDIATE-CS-2'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 3 of [RFC9529].

7.8.  Well-Known Application Profile INTERMEDIATE_CS_0

   {
           e'methods' : [0, 3], / EDHOC Method Types 0 and 3 /
     e'cipher_suites' : 0, / EDHOC Cipher Suite 0 /
        e'cred_types' : [1, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                                X.509 certificate,
                                                and C509 certificate /
     e'id_cred_types' : [4, 14, 34, 33, e'c5t', e'c5c'], / kid, kccs,
                                                         x5t, x5chain,
                                                         c5t, and c5c /
          e'app_prof' : e'APP-PROF-INTERMEDIATE-CS-0'
   }

   This application profile is aligned with the example trace of EDHOC
   compiled in Section 2 of [RFC9529].

7.9.  Well-Known Application Profile EXTENSIVE


















Tiloca & Höglund         Expires 8 January 2026                [Page 24]

Internet-Draft         EDHOC Application Profiles              July 2025


   {
           e'methods' : [0, 1, 2, 3], / EDHOC Method Types
                                        0, 1, 2, and 3 /
     e'cipher_suites' : [0, 1, 2, 3], / EDHOC Cipher Suites
                                        0, 1, 2, and 3 /
        e'cred_types' : [1, 0, 2, e'c509_cert'], / CWT Claims Set (CCS),
                                                 CWT, X.509 certificate,
                                                 and C509 certificate /
     e'id_cred_types' : [4, 14, 13, 34, 33, e'c5t', e'c5c'], / kid,
                                                             kccs, kcwt,
                                                             x5t,
                                                             x5chain,
                                                             c5t, and
                                                             c5c /
          e'app_prof' : e'APP-PROF-EXTENSIVE'
   }

   This application profile is aligned with the example traces of EDHOC
   compiled in Sections 2 and 3 of [RFC9529].

8.  Identifiers of Well-known EDHOC Application Profiles

   This document defines the following identifiers of well-known EDHOC
   application profiles.

   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
   with the RFC number of this specification and delete this paragraph.

    +=========+===================+======================+============+
    | Profile | Name              | Description          | Reference  |
    | ID      |                   |                      |            |
    +=========+===================+======================+============+
    | 0       | MINIMAL-CS-2      | Method 3; Cipher     | [RFC-XXXX] |
    |         |                   | Suite 2; CCS; kid    |            |
    +---------+-------------------+----------------------+------------+
    | 1       | MINIMAL-CS-0      | Method 3; Cipher     | [RFC-XXXX] |
    |         |                   | Suite 0; CCS; kid    |            |
    +---------+-------------------+----------------------+------------+
    | 2       | BASIC-CS-2-X509   | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 2;      |            |
    |         |                   | (CCS, X.509          |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | x5t)                 |            |
    +---------+-------------------+----------------------+------------+
    | 3       | BASIC-CS-0-X509   | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 0;      |            |
    |         |                   | (CCS, X.509          |            |
    |         |                   | certificates); (kid, |            |



Tiloca & Höglund         Expires 8 January 2026                [Page 25]

Internet-Draft         EDHOC Application Profiles              July 2025


    |         |                   | x5t)                 |            |
    +---------+-------------------+----------------------+------------+
    | 4       | BASIC-CS-2-C509   | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 2;      |            |
    |         |                   | (CCS, C509           |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | c5t)                 |            |
    +---------+-------------------+----------------------+------------+
    | 5       | BASIC-CS_0-C509   | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 0;      |            |
    |         |                   | (CCS, C509           |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | c5t)                 |            |
    +---------+-------------------+----------------------+------------+
    | 6       | INTERMEDIATE-CS-2 | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 2;      |            |
    |         |                   | (CCS, X.509/C509     |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | kccs, x5t, x5chain,  |            |
    |         |                   | c5t, c5c)            |            |
    +---------+-------------------+----------------------+------------+
    | 7       | INTERMEDIATE-CS-0 | Methods (0, 3);      | [RFC-XXXX] |
    |         |                   | Cipher Suite 0;      |            |
    |         |                   | (CCS, X.509/C509     |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | kccs, x5t, x5chain,  |            |
    |         |                   | c5t, c5c)            |            |
    +---------+-------------------+----------------------+------------+
    | 8       | EXTENSIVE         | Methods (0, 1, 2,    | [RFC-XXXX] |
    |         |                   | 3); Cipher Suites    |            |
    |         |                   | (0, 1, 2, 3); (CCS,  |            |
    |         |                   | CWT, X.509/C509      |            |
    |         |                   | certificates); (kid, |            |
    |         |                   | kccs, kcwt, x5t,     |            |
    |         |                   | x5chain, c5t, c5c)   |            |
    +---------+-------------------+----------------------+------------+

               Table 2: EDHOC Well-known Application Profiles

9.  Security Considerations

   TBD

10.  IANA Considerations

   This document has the following actions for IANA.





Tiloca & Höglund         Expires 8 January 2026                [Page 26]

Internet-Draft         EDHOC Application Profiles              July 2025


   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
   with the RFC number of this specification and delete this paragraph.

10.1.  Media Type Registrations

   IANA is asked to register the media type "application/edhoc-app-
   profile+cbor-seq".  This registration follows the procedures
   specified in [RFC6838].

   Type name: application

   Subtype name: edhoc-app-profile+cbor-seq

   Required parameters: N/A

   Optional parameters: N/A

   Encoding considerations: Must be encoded as a CBOR sequence [RFC8742]
   of CBOR maps [RFC8949].  Each element of each CBOR map is also
   defined as an element of the CBOR-encoded EDHOC_Information object
   from Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].

   Security considerations: See Section 9 of [RFC-XXXX].

   Interoperability considerations: N/A

   Published specification: [RFC-XXXX]

   Applications that use this media type: Applications that need to
   describe, distribute, and store a representation of an EDHOC
   application profile (see Section 3.9 of [RFC9528]).

   Fragment identifier considerations: N/A

   Additional information: N/A

   Person & email address to contact for further information: LAKE WG
   mailing list (lake@ietf.org) or IETF Applications and Real-Time Area
   (art@ietf.org)

   Intended usage: COMMON

   Restrictions on usage: None

   Author/Change controller: IETF

   Provisional registration: No




Tiloca & Höglund         Expires 8 January 2026                [Page 27]

Internet-Draft         EDHOC Application Profiles              July 2025


10.2.  CoAP Content-Formats Registry

   IANA is asked to add the following entry to the "CoAP Content-
   Formats" registry within the "Constrained RESTful Environments (CoRE)
   Parameters" registry group.

   Content Type: application/edhoc-app-profile+cbor-seq

   Content Coding: -

   ID: TBD (range 0-255)

   Reference: [RFC-XXXX]

10.3.  Target Attributes Registry

   IANA is asked to register the following entries in the "Target
   Attributes" registry within the "Constrained RESTful Environments
   (CoRE) Parameters", as per [RFC9423].

   *  Attribute Name: ed-max-msgsize

   *  Brief Description: The admitted maximum size of EDHOC messages in
      bytes

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-coap-ct

   *  Brief Description: Requested use of the CoAP Content-Format Option
      in CoAP messages whose payload includes exclusively an EDHOC
      message, possibly prepended by an EDHOC connection identifier

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-epid-t

   *  Brief Description: A supported type of endpoint identity for EDHOC

   *  Change Controller: IETF



Tiloca & Höglund         Expires 8 January 2026                [Page 28]

Internet-Draft         EDHOC Application Profiles              July 2025


   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-tp

   *  Brief Description: A supported means for transporting EDHOC
      messages

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-prof

   *  Brief Description: A supported EDHOC application profile

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-uuid

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      UUID

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-kid

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      binary key identifier

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]





Tiloca & Höglund         Expires 8 January 2026                [Page 29]

Internet-Draft         EDHOC Application Profiles              July 2025


   *  Attribute Name: ed-ta-edcred-c5t

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      hash of a C509 certificate

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-c5u

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      URI pointing to a C509 certificate

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-x5t

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      hash of an X.509 certificate

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Attribute Name: ed-ta-edcred-x5u

   *  Brief Description: Identifier of a supported trust anchor for
      verifying authentication credentials of other EDHOC peers, as a
      URI pointing to an X.509 certificate

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]






Tiloca & Höglund         Expires 8 January 2026                [Page 30]

Internet-Draft         EDHOC Application Profiles              July 2025


10.4.  EDHOC Information Registry

   IANA is asked to register the following entry in the "EDHOC
   Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].

   *  Name: app_prof

   *  CBOR label: 23 (suggested)

   *  CBOR type: int or array

   *  Registry: EDHOC Application Profiles registry

   *  Description: Set of supported EDHOC application profiles

   *  Specification: [RFC-XXXX][RFC9528]

10.5.  EDHOC External Authorization Data Registry

   IANA is asked to register the following entry in the "EDHOC External
   Authorization Data" registry within the "Ephemeral Diffie-Hellman
   Over COSE (EDHOC)" registry group defined in [RFC9528].

   *  Name: Supported EDHOC application profiles

   *  Label: TBD_EAD_LABEL (range 0-23)

   *  Description: Set of supported EDHOC application profiles

   *  Reference: [RFC-XXXX]

10.6.  EDHOC Error Codes Registry

   IANA is asked to register the following entry in the "EDHOC Error
   Codes" registry within the "Ephemeral Diffie-Hellman Over COSE
   (EDHOC)" registry group defined in [RFC9528].

   *  ERR_CODE: TBD_ERROR_CODE (range -24 to 23)

   *  ERR_INFO Type: app_profiles

   *  Description: Supported EDHOC application profiles

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]





Tiloca & Höglund         Expires 8 January 2026                [Page 31]

Internet-Draft         EDHOC Application Profiles              July 2025


10.7.  DNS SVCB Service Parameter Keys (SvcParamKeys)

   IANA is asked to add the following entries to the "Service Parameter
   Keys (SvcParamKeys)" registry within the "DNS Service Bindings
   (SVCB)" registry group.  The definition of these parameters can be
   found in Section 6.

   *  Number: 11 (suggested)

   *  Name: edhocpath

   *  Meaning: EDHOC resource path

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]



   *  Number: 12 (suggested)

   *  Name: edhoc-app-prof

   *  Meaning: Supported EDHOC application profiles

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]

10.8.  EDHOC Application Profiles Registry

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

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

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



Tiloca & Höglund         Expires 8 January 2026                [Page 32]

Internet-Draft         EDHOC Application Profiles              July 2025


   The columns of this registry are:

   *  Profile ID: This field contains the value used to identify the
      EDHOC application profile.  These values MUST be unique.  The
      value can be a positive integer or a negative integer.  Different
      ranges of values use different registration policies [RFC8126].
      Integer values from -24 to 23 are designated as "Standards Action
      With Expert Review".  Integer values from -65536 to -25 and from
      24 to 65535 are designated as "Specification Required".  Integer
      values smaller than -65536 and greater than 65535 are marked as
      "Private Use".

   *  Name: This field contains the name of the EDHOC application
      profile.

   *  Description: This field contains a short description of the EDHOC
      application profile.

   *  Reference: This field contains a pointer to the public
      specification for the EDHOC application profile.

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

10.9.  Expert Review Instructions

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

   Expert reviewers should take into consideration the following points:

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










Tiloca & Höglund         Expires 8 January 2026                [Page 33]

Internet-Draft         EDHOC Application Profiles              July 2025


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

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

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

11.  References

11.1.  Normative References

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

   [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-14, 23 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              cbor-encoded-cert-14>.






Tiloca & Höglund         Expires 8 January 2026                [Page 34]

Internet-Draft         EDHOC Application Profiles              July 2025


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

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

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/rfc/rfc6690>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

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

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

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/rfc/rfc8288>.





Tiloca & Höglund         Expires 8 January 2026                [Page 35]

Internet-Draft         EDHOC Application Profiles              July 2025


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

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

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

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

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [RFC9461]  Schwartz, B., "Service Binding Mapping for DNS Servers",
              RFC 9461, DOI 10.17487/RFC9461, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9461>.

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

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



Tiloca & Höglund         Expires 8 January 2026                [Page 36]

Internet-Draft         EDHOC Application Profiles              July 2025


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

11.2.  Informative References

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

   [RFC9423]  Bormann, C., "Constrained RESTful Environments (CoRE)
              Target Attributes Registry", RFC 9423,
              DOI 10.17487/RFC9423, April 2024,
              <https://www.rfc-editor.org/rfc/rfc9423>.

   [RFC9529]  Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,
              and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over
              COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9529>.

Appendix A.  CDDL Model

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






















Tiloca & Höglund         Expires 8 January 2026                [Page 37]

Internet-Draft         EDHOC Application Profiles              July 2025


   ; EDHOC Information
   methods = 1
   cipher_suites = 2
   cred_types = 6
   id_cred_types = 7
   app_prof = 23

   ; EDHOC Application Profiles
   APP-PROF-MINIMAL-CS-2 = 0
   APP-PROF-MINIMAL-CS-0 = 1
   APP-PROF-BASIC-CS-2-X509 = 2
   APP-PROF-BASIC-CS-0-X509 = 3
   APP-PROF-BASIC-CS-2-C509 = 4
   APP-PROF-BASIC-CS-0-C509 = 5
   APP-PROF-INTERMEDIATE-CS-2 = 6
   APP-PROF-INTERMEDIATE-CS-0 = 7
   APP-PROF-EXTENSIVE = 8

   ; COSE Header Parameters
   c5t = 22
   c5c = 25

   ; EDHOC Authentication Credential Types
   c509_cert = 3

                            Figure 6: CDDL model

Appendix B.  Document Updates

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

B.1.  Version -01 to -02

   *  Revised order of sections.

   *  Use of parameters aligned with corresponding updates in draft-
      ietf-ace-edhoc-oscore-profile.

   *  EAD item "Supported EDHOC application profiles":

      -  It can be used only in a critical way.

      -  Improved semantics of ead_value.

      -  Content restrictions to avoid inconsistent information.

   *  Use of the parameter "app_prof" in draft-ietf-ace-edhoc-oscore-
      profile:



Tiloca & Höglund         Expires 8 January 2026                [Page 38]

Internet-Draft         EDHOC Application Profiles              July 2025


      -  Improved co-existence with other parameters.

      -  Content restrictions to avoid inconsistent information.

   *  Error handling:

      -  EAD item "Supported EDHOC application profiles" occurring
         multiple times in EDHOC message_1 or message_2.

      -  EAD item "Supported EDHOC application profiles" in EDHOC
         message_3 or message_4.

      -  Invalid ead_value in EAD item "Supported EDHOC application
         profiles".

      -  Invalid information in EDHOC error message with new error code.

   *  Fixed encoding of ERR_INFO for the EDHOC error message with the
      new error code.

   *  EDHOC_Application_Profile object

      -  Clarified scope.

      -  Clarified meaning of boolean parameters that are non-
         prescriptive.

      -  Forbid the presence of the element "trust_anchors".

   *  Advertisement of Supported EDHOC Application Profiles using SVCB
      Resource Records.

   *  Updated integer abbreviations for the EDHOC_Information
      parameters.

   *  Editorial improvements.

B.2.  Version -00 to -01

   *  Clarified motivation in the abstract and introduction.

   *  Moved definition of EDHOC_Information parameters to draft-ietf-
      ace-edhoc-oscore-profile.

   *  Renamed ed-idep-t x as ed-epid-t.

   *  Content-Format abbreviated as "ct" (not "cf").




Tiloca & Höglund         Expires 8 January 2026                [Page 39]

Internet-Draft         EDHOC Application Profiles              July 2025


   *  CBOR abbreviation of "app_prof" changed to 23.

   *  Added preamble on identifying application profiles by Profile ID.

   *  Defined target attributes "ed-ta-*" for specifying supported trust
      anchors.

   *  Defined new EAD item and error code to advertise supported EDHOC
      application profiles.

   *  Defined how to handle non admitted parameters.

   *  Renamed well-known EDHOC application profiles.

   *  Updated IANA considerations:

      -  Suggested range 0-255 for CoAP Content-Format ID.

      -  Requested registration for target attributes "ed-ta-*".

      -  Removed requests for registration of removed parameters.

   *  Updated references.

   *  Editorial improvements.

Acknowledgments

   The authors sincerely thank Christian Amsüss, Geovane Fedrecheski,
   Michael Richardson, Göran Selander, and Brian Sipos for their
   feedback and comments.

   The target attributes "ed-ta-*" for specifying supported trust
   anchors build on a proposal originally described in
   [I-D.serafin-lake-ta-hint].

   This work was supported by the Sweden's Innovation Agency VINNOVA
   within the EUREKA CELTIC-NEXT project CYPRESS.

Authors' Addresses

   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   SE-16440 Stockholm Kista
   Sweden
   Email: marco.tiloca@ri.se




Tiloca & Höglund         Expires 8 January 2026                [Page 40]

Internet-Draft         EDHOC Application Profiles              July 2025


   Rikard Höglund
   RISE AB
   Isafjordsgatan 22
   SE-16440 Stockholm Kista
   Sweden
   Email: rikard.hoglund@ri.se













































Tiloca & Höglund         Expires 8 January 2026                [Page 41]
