# Next steps on the EDHOC profile of ACE

Draft: https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/

Github repo: https://github.com/ace-wg/ace-edhoc-oscore-profile

[toc]

## Exporting the N_S challenge in ACE application profiles (TODO)

### Background

The EDHOC transport profile has ruled out the uploading of the access token to the /authz-info endpoint at the RS.

This creates a complication for the two ACE application profiles for group communication defined in:

* https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore
* https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-pubsub-profile

When using those application profiles, the client typically uploads the access token to the /authz-info endpoint of the KDC (acting as RS) and obtains in return some information.

This information includes a nonce 'kdcchallenge' that the client will use as the N_S challenge when proving possession of its own private key, e.g., when later sending a Join Request to the KDC.

When using the EDHOC transport profile in combination with one of those ACE application profiles, the client does not interact with the /authz-info endpoint, as it uploads the access token to the KDC by running EDHOC with the KDC. Therefore, the client cannot obtain N_S and practically cannot join the group as unable to provide possession of its own private key.

### Precedents

The two ACE application profiles are already defining an alternative way for the client and the KDC to agree on the same N_S value, in case the DTLS transport profile is used and the access token is uploaded within a Handshake message.

In practice, N_S is computed as an exporter value from the (D)TLS session used by the client and the KDC. To this end, one new TLS exporter label has been defined for each of the two ACE application profiles. See:

* https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-18#section-6.1.1
* https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-pubsub-profile-01#section-4.1.1.2

### Solution

The EDHOC transport profile can define how N_S is computed in the context of those ACE application profiles, using an approach analogous to that used for the DTLS transport profile.

As a rough sketch of the text for a new section about this:

> The EDHOC and OSCORE profile specified in the present document can be used in combination with application profiles of ACE for key provisioning for group communication [RFC9594], such as [I-D.ietf-ace-key-groupcomm-oscore] and [I-D.ietf-ace-coap-pubsub-profile].
>
> That is, the EDHOC and OSCORE profile is used by a client and an RS that acts as Key Distribution Center (KDC) responsible for a security group. In such a case, the following holds for determining the N_S challenge used in those application profiles.
>
> * In the ACE application profile [I-D.ietf-ace-key-groupcomm-oscore], when the provisioning of the access token to the Group Manager (i.e., the KDC) has relied on the EDHOC and OSCORE profile of ACE specified in this document and the access token was specified in the EAD item ACE-OAuth Access Token (see Section 4.1), then N_S is derived using the EDHOC_Exporter interface defined in Appendix A.1 of RFC 9528.
>
> Specifically, N_S is exported from the EDHOC session associated with the access token and established between the client and the Group Manager. Furthermore:
> * The 'exporter_label' parameter is EXPORTER_LABEL_TBD_26, which is registered in Section TBD of this document.
> * The 'context' parameter is h'' (0x40), i.e., the empty CBOR byte string.
> * The 'length' parameter is 32, i.e., the intended length of N_S in bytes.
>
> * In the ACE application profile [I-D.ietf-ace-coap-pubsub-profile], when the provisioning of the access token to the KDC has relied on the EDHOC and OSCORE profile of ACE specified in this document and the access token was specified in the EAD item ACE-OAuth Access Token (see Section 4.1), then N_S is derived using the EDHOC_Exporter interface defined in Appendix A.1 of RFC 9528.
>
> Specifically, N_S is exported from the EDHOC session associated with the access token and established between the client and the KDC. Furthermore:
>
> * The 'exporter_label' parameter is EXPORTER_LABEL_TBD_27, which is registered in Section TBD of this document.
>
> * The 'context' parameter is h'' (0x40), i.e., the empty CBOR byte string.
>
> * The 'length' parameter is 32, i.e., the intended length of N_S in bytes.

Then, for the IANA registrations of the two EDHOC_Exporter labels:

> IANA is asked to register the following entries in the "EDHOC Exporter Labels", within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group.
>
>
> * Label: 26 (suggested value)
>
> * Description: Derived N_S challenge for key provisioning for Group OSCORE using the ACE framework
>
> * Change Controller: IETF
>
> * Reference: [RFC-XXXX]
>
> <br>
>
> * Label: 27 (suggested value)
>
> * Description: Derived N_S challenge for key provisioning for CoAP Pub-Sub using the ACE framework
>
> * Change Controller: IETF
>
> * Reference: [RFC-XXXX]

Notes:

* The references to [I-D.ietf-ace-key-groupcomm-oscore] and [I-D.ietf-ace-coap-pubsub-profile] will have to be normative. Considering the current status of the three documents involved, this seems to be the best option.

* As to the suggested values for the EDHOC_Exporter labels, it feels unnecessary to use the precious range 0-22, and the range 24-32767 should work just fine. In that range, currently available values start from 26.

## IANA early review before IETF 124

https://mailarchive.ietf.org/arch/msg/ace/Yb4k5hB_vK7BN4c_W0Z3uxhzOmI/

> Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about this document:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-09
>
> Sections 14.10-14.13 say, "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]."
>
> However, Section 14.9 says, "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])."
>
> Is this difference intentional? IANA will always ask experts to review early allocations that would require expert review for permanent allocation. However, the need to record this wasn't anticipated when RFC 7120 made Specification Required registries eligible for early registration. (It has been recorded in draft-baber-ianabis-rfc7120bis.)

MT: The text used in Sections 14.10-14.13 should also be used in Section 14.9.

That's the phrasing that we are consistently using in all documents when creating a new IANA registry that also uses registration policies augmented with Expert Review.

The text in Section 14.9 is likely a remnant from previous versions of that text that I forgot to update in that section.

## Use of plain COSE_Key (TODO)

https://mailarchive.ietf.org/arch/msg/ace/DMvrF8-Z9Cxojqk5sERX2cq1cHY/

Christian suggested to allow that 'req_cnf', 'rs_cnf', and 'cnf' can specify "COSE_Key" (1) as CWT Confirmation Method.

(Christian: EDHOC seems to imply this already in https://www.rfc-editor.org/rfc/rfc9528.html#name-authentication-credentials , bullet 4.1. This seems to also be aligned with RFC9201, where in Figure 1, there is a req_cnf that contains a naked COSE key.)

When doing so, the consumer of 'req_cnf', 'rs_cnf', or 'cnf' must build a CCS including only the claim 'cnf', which takes the same value specified as COSE Key in the received confirmation method. This building operation effectively consists in prepending the four bytes 0xa108a101 to the received "naked" COSE Key.

(Christian: Yes.)

The result from the previous step (i.e., the COSE Key minimally "dressed" as a CCS) is used as authentication credential in EDHOC, transported with a 'kccs' COSE header parameter when specified by value in ID_CRED_X.

(Christian: Yes, although I kind'a doubt that a credential already expressed in some other place would be transported by value here.)

If so, I wonder if saving 4 bytes per credential is worth it, and I'm interested to hear more opinions.

(Christian: I think this is not just about the overhead but also about consistency with the documents in which the pattern has been used.)

## Christian's review of version -09 (TODO)

https://mailarchive.ietf.org/arch/msg/ace/ft4Z0wifXil5ft2WTLKv1WpBGM8/

## Message exchange diagram for the Request Creation Hints transported in EAD item example (TODO)

Let's add this

## Terminology: Style for names of EAD items (TODO)

Shall we go for variable-like naming such as "EAD_ACCESS_TOKEN", or more human-readable style like "ACE-OAuth Access Token", or keep both?

Now we have a mix in the IANA considerations for "EDHOC External Authorization Data Registry":
* Name: ACE-OAuth Access Token
* Name: Session ID
* Name: EAD_CRED_BY_VALUE
* Name: EAD_REQUEST_CREATION_HINTS
https://ace-wg.github.io/ace-edhoc-oscore-profile/draft-ietf-ace-edhoc-oscore-profile.html#name-edhoc-external-authorizatio
(Table was fixed for v-09)

We also mix in the document by calling "ACE-OAuth Access Token" as "EAD_ACCESS_TOKEN" and "Session ID" as "EAD_SESSION_ID"

**GS** Maybe we can have a convention for converting between name in IANA registry and variable?
Access Token -> EAD_ACCESS_TOKEN
Session ID -> EAD_SESSION_ID

## Early allocation of codepoints for CWT confirmation methods (TODO)

To be asked to the ACE Chairs: it would be good to have early registration (RFC 7120) of the codepoints for the registrations of:

* ACE Profiles

https://www.rfc-editor.org/rfc/rfc9200.html#section-8.8
(Values -256..255 are registered as Standards Action)

coap_edhoc_oscore

* CBOR Web Token (CWT) Claims

https://www.rfc-editor.org/rfc/rfc8392.html#section-9.1
(Values -256..255 are registered as Standards Action)

edhoc_info (claim)

* CWT Confirmation Methods

https://www.rfc-editor.org/rfc/rfc8747.html#section-7
(Values are registered as Specification Required. It's fine in this case, since this specification is intended to be published as RFC.)

x5chain
x5bag
x5t
x5u
c5c
c5b
c5t
c5u
kcwt
kccs

As to other things that we are requesting to register in already existing registries, we cannot request an early registration for those. That is:

* OAuth Parameters CBOR Mappings

https://www.rfc-editor.org/rfc/rfc9200.html#section-8.10
(Excluding Private Use, values are only -65536 or greater, and those are all registered as Expert Review. So the early registration is not possible. However, we can just request the registration sooner than later.)

edhoc_info (parameter)

## Consideration: RS belonging to multiple audiences (TODO)

An RS might support multiple EDHOC ciphersuites and EDHOC methods, This means that RS needs to have multiple own authentication credentials, each to be used with different combinations of ciphersuites and methods.

For example, RS might support ciphersuites 0 and 2, as well method 0 and 3. This means that RS needs to have 4 authentication credentials, irrespective of their specific type:

* One for EdDSA with curve Ed25519 to use with method 0

* One for ECDSA with curve P-256 to use with method 0

* One for ECDSA with curve P-256 to use with method 3

* One for curve X25519 to use with method 3

Building on that, RS should belong to one audience for each of its authentication credentials.

When C requests an access token to the AS, C requests the access token for the specific audience such that the corresponding RS' authentication credential is consistent with C's authentication credential provided in the Access Token Request.

Before requesting an access token to AS, C is supposed to separately discover what RS supports and the right audience for which requesting the access token.

The former can be achieved by pre-configuration of C, or through the means defined in draft-ietf-lake-app-profiles.

The latter can be achieved by pre-configuration of C. Starting an EDHOC session with RS even before requesting an access token doesn't really help about this: in that EDHOC session, C can asks RS for Request Creation Hints information securely provided in an EAD item (i.e., the new one to be proposed), but this is not supposed to include "audience" (see the earlier point about this topic).

## Discuss pros/cons of access token in an EAD item in a security consideration (TODO)

See also https://github.com/ace-wg/ace-edhoc-oscore-profile/issues/8

While fundamentally considering a dedicated EAD item, the access token can be included in principle in any EDHOC message sent by the ACE Client.

The idea is to leave freedom to choose what exactly to do, while discussing the differences in terms of security and privacy properties.

**GS-25-06-30** Section 4.2 already contains some information on this topic which we can reference rather than repeat. Group audience is not covered.

Christian started this sort of reasoning in the Github issue linked above. The following text gives some more information along those lines.

### EDHOC Forward message flow

When using the EDHOC forward message flow, it makes sense to specify the Access Token in an EAD item only in EDHOC message_3, but not in EDHOC message_1, which is what we are defining already.

After all, message_1 provides no guarantee whatsoever, and the ACE Client is better off to upload the Access Token to the /authz-info endpoint at RS altogether, which is now not allowed.

Also, message_1 would expose the content of the access_token (hence the identity of C, which can be the EDHOC Initiator!), unless the AS always encrypts the access token, which is not something realistic to expect.

The advantage of using EDHOC message_3 is that the Access Token would also be encrypted by EDHOC. This spares the AS from encrypting the Access Token between itself and the RS(s) in the targeted audience. In case the Access Token is for a group-audience, the AS still needs to sign it.

### EDHOC Reverse message flow

The Access Token can be transported in an EAD item of EDHOC message_2 or message_4, with different properties and implications discussed below.

**Using the EAD item in EDHOC message_2**

This makes sense if C is willing to provide the Access Token to RS even before having authenticated that RS, i.e., before that RS chooses its CRED_I to use in the following EDHOC message_3.

Specifically in the case of a group-audience, using EDHOC message_2 makes sense when the AS provides C with the Access Token, together with the parameters 'aud2' and 'rs_cnf2'. Building on that, C uploads the Access Token through EDHOC message_2 at a RS without knowing which exact RS it is. However, C will learn about it when checking the CRED_I determined from EDHOC message_3 against the authentication credentials specified in rs_cnf2.

There is a privacy caveat: if the Access Token is not also encrypted by the AS, then an RS that is not a member of the group-audience will be able to read it.

(In a very general sense, this same downside holds also if C uploads over multicast a non-encrypted Access Token issued for a group-audience, which is now not allowed in this profile. This is a general problem. Solving it requires to encrypt the Access Token with a group key shared between the AS and the current RSs in the group-audience; in turn, this means managing that group key, i.e., revoking it and distributing a new one upon changes in the membership of the group-audience. This is a general issue that one day we should consider addressing from a broad, framework point of view)

**Using the EAD item in EDHOC message_4**

Using EDHOC message_4 makes sense if RS wants to authenticate C upon receiving EDHOC message_2, based on the CRED_R retrieved from/through EDHOC message_2. Only in case of positive authentication can RS continue with EDHOC message_3, after which C authenticates the RS, and then sends EDHOC message_4 including the access token conveying CRED_R again.

This is a hard split between the early authentication of C upon receiving EDHOC message_2 at the RS, and the late verification of the access rights of C upon receiving EDHOC message_4 at the RS.

This opens again for considering the use of the CoAP EDHOC option defined in RFC 9668, for combining into a single OSCORE-protected request sent by C both EDHOC message_4 and the first OSCORE-protected application request from C to the RS.

The same mechanics from RFC 9668 should work just as well. It was concluded to not do it in RFC 9668, and instead to define it in a separate document in CoRE if really needed.

## For future document: consider EDHOC PSK and EDHOC resumption (FOR FUTURE DOCUMENT - CAN WAIT)

Read through the document with the EDHOC PSK mindset to allow for a smooth update later, as the work in draft-ietf-lake-edhoc-psk proceeds.

A later, separate document can update this profile to support the execution of EDHOC based on a pre-shared symmetric key.

During the presentation about draft-ietf-lake-edhoc-psk at the LAKE session of IETF 124, Christian said:

> I'm looking forward to using this in an ACE-OSCORE style scenario -- that'll give confidentiality against a present-day AS, and decrypt-later protection unless the AS stores the keys (and gets compromised later)

Early thoughts:

- Like already in ACE for secret PoP keys, no group audiences!
- Like already in ACE for secret PoP keys, the AS MUST encrypt the access token
- Forward message flow -> access token in EAD_1
- Reverse message flow -> access token in EAD_2
- Unclear if we want to allow the uploading of the access token to /authz-info in this case.
- Unlike in the main EDHOC profile, it is not possible to upload the access token in an already protected EDHOC message anyway, since both EDHOC message_1 and message_2 are not protected. Therefore, even though it requires an additional round trip, uploading the access token to /authz-info is just as secure as doing it with an EAD item during the EDHOC session.

In addition to the above, the discussed update is also about ensuring that all keeps working even when EDHOC session resumption is used, irrespective of how the first session was run (i.e., when C authenticates itself through a symmetric PoP key or a public authentication credential).

This requires additional associations and handling at the RS. Intuitively:

* The pair (session_id, AUTH_CRED_C) is generalized to consider AUTH_CRED_C as either:
* The public authentication credential of C that was used in the first session; or
* The "external" symmetric key that was used by C and RS in the first session. This symmetric key is generated by the AS.

* The pair above is bound to:
* As usual, the EDHOC session and the OSCORE Security Context derived from it. If EDHOC resumption is used, the EDHOC session and the derived OSCORE Security Context are always the most recent in the chain of EDHOC sessions.
* As usual, the access token associated with the chain of EDHOC sessions, such that its "cnf" claim specifies the AUTH_CRED_C used in the first EDHOC session.
* As a new thing, the latest EDHOC resumption symmetric key (if any).

When running an EDHOC resumption, the client still includes the "Session ID" EAD item in an EDHOC message. The extended associations listed above allow RS to retrieve: i) the intended access token; and ii) the associated latest EDHOC session to refer to and to replace once completed the ongoing one.

# Points below are DONE for version v-09

## Editorial: diff appendix from v -08 to v -09 (DONE)

* Parameter "cnf" explicitly forbidden in the Access Token Response.
* Clarification about content of "cnf" claim in the access token.
* RS must support the CoAP Uri-Path-Abbrev Option and its value abbreviating /.well-known/edhoc.
* Example of Request Creation Hints provided in EAD item.
* Examples showing content of the 4 new EAD items.
...

**RH-25-10-19** The points above, plus some of the WAIT or still TODO points from below can be presented during the ACE session during IETF 124.

## Procedural: link from the Datatracker to the Github repo (DONE - Rikard will do when submitting)

See also https://github.com/ace-wg/ace-edhoc-oscore-profile/issues/6

* Ask the ACE Chairs to add a link to the Github repo also in the metadata of the Datatracker entry for the draft, or do when submitting (see examples in other Datatracker entries)

`github_repo https://github.com/ace-wg/ace-edhoc-oscore-profile (Working Group Repo)`

## ACE Request Creation Hints in EAD item (DONE, 75ef837 and e90eb6d7 - DONE, DONE - Rikard)

**MT-2025-06-29** I guess that the right commit is 75ef837 , right?
**GS-25-06-30** Right, I'm off-by-one in commits, fixed.

===

**GS-2025-07-03** EAD_y is defined.

===
**MT-2025-06-29**

* In Figure 9

s/? ead_value = bstr/? ead_value = bstr .cbor

See, e.g., https://www.rfc-editor.org/rfc/rfc8613#section-5.4

* More generally, the map keys are taken from the "ACE Authorization Server Request Creation Hints" registry.

* "in EDHOC messages between C to RS"

Perhaps it means: "in the following EDHOC EAD fields exchanged between C and RS"

* "to respond in the next EDHOC message with the same EAD item containing AS Request Creation Hints."

Suggested: "to include in the next EDHOC message the same EAD item with ead_value encoding the AS_request_creation_hints map."

* s/messages_3/message_3

* "However, since EDHOC message_2 ... matching the privacy policy of the application."

Sure; do we actually want to use "SHOULD NOT" or similar about including "scope" and "audience" if the EAD item from RS is in message_2?

* I guess that the EAD item is meant to be used always as non-critical.

**GS-25-06-30** updated in 43b3b2b

**MT-2025-06-30** Thanks; fixed a few typos in https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/51733d71383245fe5f8fec5d179c4c9bbe87bc8b

**MT-2025-06-30** Proposed rephrasing:

OLD
Since EDHOC message_2 is only protected against passive attackers, the "audience" and "scope" of the EAD item with AS Request Creation Hints SHOULD NOT be included in EAD_2.

NEW
Since EDHOC message_2 is only protected against passive attackers, the AS_request_creation_hints map SHOULD NOT include "audience" and "scope" when present in the EAD item conveyed in the EAD_2 field.

**GS-25-07-03**

===

See also: https://github.com/ace-wg/ace-edhoc-oscore-profile/issues/10

Christian pointed out that, when using this profile, C might not know in advance which AS to contact, nor the specific audience (and scope) for which it should request an access token.

In short: he asks to think about having C running EDHOC with RS before having obtained an access token, and having RS providing C with an EAD item (typically in message_2), specifying the same information of a Request Creation Hints error response.

More in detail, he says:

> When a client wants to establish an EDHOC context through this profile, it may not yet know the relevant AS-and-audience combination to get a token with.
>
> Would it make sense to send request creation hints in an EAD2 item? (I think yes).
>
> Would this document be the right place to allocate that number? (Don't know).
>
> Should that EAD item contain a mechanism to solicit it? (Probably yes: Like we're moving towards using app-profiles so that servers can send ID_CRED_R as a reference unless the initiator asks to, a client might send RCH without a value to solicit the RCH).

There is a lot to unpack here. I think this should look as follows, starting with the EDHOC forward message flow.

1. Without having an access token yet, C sends EDHOC message_1, including in EAD_1:

* A new EAD item EAD_X, here specifying no ead_value.

By doing so, C is asking RS to include the same EAD item in EAD_2, specifying the information that would be included in a Request Creation Hints response.

It makes sense to have EAD_X defined in this document.

* A new EAD item EAD_Y, asking RS to specify its authentication credential AUTH_CRED_RS by value in ID_CRED_R.

The definition of such an EAD item was discussed in the past, as a way to fully address an issue that is only partially addressed by the EDHOC ERR_CODE 3 (Unknown Credential Referenced).

I don't think that this new EAD item belongs to draft-ietf-lake-app-profiles either, since it's not about an application profile of EDHOC or about what is permanently supported by an EDHOC peer. Instead, it is about a particular preference of an EDHOC peer for a particular EDHOC session with a particular other EDHOC peer.

This EAD item has general use in EDHOC. However, it can be defined in this document where a need has emerged, instead of having a separate (admittedly, more visible) document which this profile would normatively depend on.

2. RS replies with EDHOC message_2, including in EAD_2:

* The new EAD item EAD_X, whose CBOR byte string specified as ead_value encodes the same information that would have been included in a Request Creation Hints response to an unauthorized request sent to RS. This information particularly includes the URI to the /token endpoint at the AS, and can also include the nonce "cnonce".

Note that C has not made an actual request with a specific request method and targeting a specific application resource. That is, RS does not know yet what resources C is actually interested in accessing later on. Hence, the information specified in this EAD_X item is not expected to include "audience" and "scope".

3. C requests an access token for the right audience and scope from the right AS, based on the information from EAD_X within EDHOC message_2, like if C had received a Request Creation Hints response.

C is already supposed to know the right audience and scope to specify in the Access Token Request, as that information is not expected to be provided by RS in the EAD_X item of message_2. There can also be default audience and scope set at the AS to use, if none is specified by C in its Access Token Request.

Note: this step is "interesting" to implement. The side processing of EAD_X at C has to switch to a totally different interaction with the AS, during which the EDHOC session is suspended.

4. C sends EDHOC message_3, specifying the access token in EAD_3 as value of the EAD item "ACE-OAuth Access Token".

5. If the protected request from C for accessing a resource at RS is not authorized per the issued access token, then RS replies with a protected error response. Within that error response, RS can provide C with information that would have been specified in a Request Creation Hints response. This time, that information includes audience and scope too. Then, C can follow-up requesting a new access token that dynamically updates accesss rights accordingly.

Note that this applies also if C uses the EDHOC + OSCORE combined request (see RFC 9668), hence combining EDHOC message_3 with the first OSCORE-protected request to access a protected resource at RS.

If, instead, the reverse message_flow is used, then the following differences apply:

* EAD_X and EAD_Y are included in EDHOC message_2 by C, in order to ask RS to provide the Request Creation Hints information and to specify AUTH_CRED_RS by value in ID_CRED_I, respectively.

* EAD_X is included in EDHOC message_3 by RS, with value the Request Creation Hints information.

* After receiving EDHOC message_3, C requests the access token to the AS, based on the information from EAD_X in message_3.

* Finally, C sends EDHOC message_4, specifying the access token in EAD_4 as value of the EAD item "ACE-OAuth Access Token".

All the above is in order to have a protected and authenticated information acting as Request Creation Hints, unlike what happens with the original, unprotected Request Creation Hints response.

If it is acceptable for C to obtain that information from RS as unprotected, then C is just better off relying on the original approach of ACE, by simply sending an unprotected request to a resource at RS and receiving an unprotected Request Creation Hints response, instead or running EDHOC so early.

**RH-25-10-19**: Done in commit https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/1026050928d0432389ca66ce0b6c788f307a4297
Small fix in: https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/e95a6ec099844f2244e6d45bed03dde4a98acaa8
Latest commit: https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/fe640b88644a1dcb27ba2167ac68bcf5203ed91f

## Section 4.13 & 4.14 - Add examples for EAD items EAD_REQUEST_CREATION_HINTS & EAD_CRED_BY_VALUE (CHECK - Rikard)

Done in commit: https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/de9e48d83d3b14d0325832b3d21b3b5df2a38a7f

Updated in commit: https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/95bc17e18ae786f3e0524caef3fc623c9ba9c51f

## Section 4.1 - Add examples of EAD items EAD_ACCESS_TOKEN and EAD_SESSION_ID (CHECK - Göran)

Per the Editor's notes, add examples for the EAD items EAD_ACCESS_TOKEN and EAD_SESSION_ID.

GS: Examples added, but dependent on IANA allocations. New Editor's notes added.

Commit: https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/031d3f81283d0044df39dc7ee404e2eb7583413e

RH: Did small fix in https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/f30abd67359725f5659fd2208e2de4445ac66be2

## Prevent AS from forcing a different AUTH_CRED_C (DONE - Rikard)

The DTLS profile in RPK mode admits the following.

After C specifies its public key in 'req_cnf' of the Access Token Request, the AS can either:

* Specify that public key in the 'cnf' claim of the access token, and not include the 'cnf' parameter in the Access Token Response.

In this case, C uses the public key that it specified in the Access Token Request as its RPK during the DTLS handshake with RS.

* Select a different public key of C that it already knows, include that public key in the 'cnf' claim of the access token, and include the 'cnf' parameter in the Access Token Response specifying that public key.

In this case, C uses its public key from the 'cnf' parameter in the Access Token Response as its RPK during the DTLS handshake with RS.

In this EDHOC and OSCORE profile, we are are already supporting the first case, but not saying anything about the second case.

Should we explicitly forbid the second case, and limit the profile to the first case only?

**GS-25-06-30** Yes.

**RH-25-10-09** I would limit it to the first case.

Commit: https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/e0c40bcf155b5869503af2db144096d5de0e0f17
(**MT-25-10-18**: see suggested rephrasing at https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/e0c40bcf155b5869503af2db144096d5de0e0f17#r168169706

**RH-25-10-18** Updated in commit https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/e3c9359eed4d31cc9c57b46d4d623b6db4e74c2d. This point is DONE.

**MT-25-10-18**: Related point: The "cnf" parameter is explicitly forbidden in the Access Token Response.

Commit: https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/e26ff521c817ecd7272891e2bc353905876dd7d0

## Make use of what Christian is defining in draft-ietf-core-uri-path-abbrev (DONE - Marco)

https://datatracker.ietf.org/doc/draft-ietf-core-uri-path-abbrev/

Normatively refer to the draft and explain what can be achieved by using it.

Mandate support of the new CoAP option and of the codepoint that abbreviates "/.well-known/edhoc", by an RS using this profile.

Commits:

* https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/d6898500913df4be269130096df15d049ecd5599
* https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/968011cd3175d917c33993f195e9b12b9cddddd0

# All points from here are DONE or NO CHANGE since earlier versions

## Editorial: "RS" vs. "the RS" (NO CHANGE)

This document is consistently using "RS" (without article).

RFC 9200 and the other profiles use "the RS" instead. Should we do the same here?

(RFC 9200 also uses "the C", while the other profiles use "the client")

**GS-25-06-30** The approach here a conscious decision: "the client (C)", "the resource server (RS)" and "the authorization server (AS)" is defined in the beginning and then abbreviations are used. No article needed IMHO.

## Section 3.4 (DONE, c80f61a and 441dd71)

**MT-2025-06-29** The right commit should be c80f61a , right?
**GS-25-06-30** Yes, fixed.

Change the description of the parameter "message_4".

OLD:
> Support for EDHOC message_4

NEW:
> Required use of EDHOC message_4

For consistency, the definition of the parameter "coap_ct" can also start with "Required" instead of the current "Requested".

**MT-2025-06-29** "Mandatory use" looks good. We have to make the update also for "coap_ct" as mentioned above. So its description would also say "Mandatory use of ..." instead of "Requested use of ...". Done in https://github.com/ace-wg/ace-edhoc-oscore-profile/commits/main/

**GS-25-06-30** OK!

## Section 3.4 (DONE, c391c36)

Remove the parameters "osc_ms_len" and "osc_salt_len", also later on as to their registration and use.

These parameters are fundamentally related to the size of the output of the EDHOC_Exporter interface. Therefore, they establish a bad pattern that results in redundancy and aliasing with respect to the "EDHOC Exporter Labels" registry.

While removing these parameters will prevent the AS from enforcing an off-band agreement between C and RS about the size of (selected) outputs of EDHOC_Exporter, the new planned draft with Elsa is intended to provide a better and more flexible approach for an in-band agreement through an EAD item when running EDHOC.

## Section 3.4 (DONE, c391c36)

Remove the parameter "osc_version", also later on as to its registration and use.

Just like the parameters "osc_ms_len" and "osc_salt_len" mentioned in the previous point, this parameter does not pertain to EDHOC, but to a protocol that can be used after EDHOC (i.e., OSCORE in this case).

As discussed, this information (and possibly more, like encrypting the OSCORE Partial IV or not) can instead be negotiated in-band when running EDHOC, using a separate EAD item equivalent to the ALPN extension of the TLS ClientHello. That EAD item would be used by the two EDHOC peers to agree on what protocol is used after EDHOC, and possibly according to what parameters.

## Section 3.4 (DONE, 9c37da7)

Partition the different parameters of the EDHOC_Information object into two sets, so that each parameter is categorized as either "Normative" or "Informative".

The category of each parameter is practically indicated by a new column to add to the "EDHOC Information" IANA registry where these parameters are registered.

This classification is useful for the work done in draft-ietf-lake-app-profiles, which re-uses the namespace provided by the "EDHOC Information" IANA registry and also specifies particular uses of the EDHOC_Information object defined in the present document.

After revisiting the current parameters of the EDHOC_Information object as discussed in the comments above, the remaining parameters should be classified as follows.

Normative:
* session_id
* message_4
* uri_path
* max_msgsize
* coap_ct

Informative:
* All the other ones

Eventually went for prescriptive and non-prescriptive.

## Consistently have KUDOS as informative reference (DONE, c245af5)

KUDOS (draft-ietf-core-oscore-key-update) is currently an informative reference as intended.

However, a statement about it in Section 4.8 uses "SHALL". This effectively makes KUDOS a normative reference, which is undesirable.

Instead, we can relax the statement, so that KUDOS can correctly remain an informative reference. It is sufficient to mention KUDOS just as a possible way to do key update without running a new EDHOC session (of course, the downside is that KUDOS does not involve a Diffie-Hellman exchange).

**MT-2025-06-29** Simply using "MAY" instead of "SHALL" might not be enough, see Note 1 in https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/

The new sentence is making it OPTIONAL for C and RS to run KUDOS. This requires the reader to have an understanding of KUDOS as an optional feature of this specification, which in turn makes KUDOS a normative reference.

Esko raised the same issue for a number of references in Group OSCORE (e.g., draft-ietf-ace-key-groupcomm-oscore). We managed to keep them informative by avoiding normative language around them and presenting them as just an example of something more general.

In this case, maybe something like this can work.

OLD
In this case, C and RS MAY 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 uploading of an access token. If KUDOS is not supported, then C and RS falls back to EDHOC as outlined above.

NEW
In this case, C and RS MAY attempt to alternatively run a commonly supported key update protocol. An example is the lightweight key update protocol KUDOS {{I-D.ietf-core-oscore-key-update}}, which is independent of ACE and EDHOC and does not require the uploading of an access token. If C and RS do not both support a key update protocol to use for updating their still valid OSCORE Security Context, then C and RS fall back to EDHOC as outlined above.

**GS-25-06-30** Another attempt in aeaf1ac

**MT-2025-06-30** Thanks; fixed some nits in https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/80ca342d1fd92cf44f7521560a79357e5a0166c7

## Section 4.4 (DONE, 2f71a98)

Define the following requirement

In this profile of ACE, if RS implements the EDHOC reverse message flow, then RS MUST implement EDHOC message_4.

Rationale: if the EDHOC reverse message flow is used, C can choose whether to include the access token in EDHOC message_2 or message_4. The decision might also be on a per-access-token basis, e.g., depending on the specifically targeted audience. Therefore, RS must simply be ready for that to happen.

**MT-2025-06-29** Looks good.

## Informative reference to -workflow-and-params (DONE, 4d5bca6)

draft-ietf-workflow-and-params has defined a method for:

* AS to ask C to provide AUTH_CRED_C by value in the Access Token Request.
* C to ask AS to provide AUTH_CRED_RS by value in the Access Token Response.

This is useful in case AS ( C ) forgets the authentication credential of C (RS), in which case it is not useful to specify that credential by reference.

In order to keep the reference to draft-ietf-workflow-and-params informative, a possible phrasing to use can be the following (in Sections 3.1 and 3.3):

> A way for AS to ask C to provide its authentication credential AUTH_CRED_C by value in the Access Token Request is defined in {{I-D.ietf-ace-workflow-and-params}}.

and

> A way for C to ask AS to provide the authentication credential of RS AUTH_CRED_RS by value in the Access Token Response is defined in {{I-D.ietf-ace-workflow-and-params}}.

**MT-2025-06-29**

Alternative phrasing (even more "example-oriented"):

> AS could explicitly ask C to provide its authentication credential AUTH_CRED_C by value in the Access Token Request, e.g., by relying on the coordination method defined in {{I-D.ietf-ace-workflow-and-params}}.

and

> C could explicitly ask AS to provide AUTH_CRED_RS by value in the Access Token Response, e.g., by relying on the coordination method defined in {{I-D.ietf-ace-workflow-and-params}}.

**GS-25-06-30** Done in 27e7481

**MT-2025-06-30** Thanks; fixed some nits in https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/80ca342d1fd92cf44f7521560a79357e5a0166c7

**GS-25-06-30** Looks fine, I change this issue to DONE

## Authentication Credentials in Messages between C and AS (ADDRESSED IN ANOTHER DRAFT)

**Note**: This actually applies in general to the ACE framework. Therefore, this is better defined in the document draft-ietf-ace-workflow-and-params

This profile of ACE is the first one introducing public authentication credentials transported by reference, i.e., in parameters of messages exchanged between C and the AS, or within an access token.

Ideally, the transport of public authentication credentials by value in the ACE workflow is expected to happen only in the following cases.

* CASE 1. The public authentication credential of C (AUTH_CRED_C) in the Access Token Request from C to the AS, when C asks the AS for an access token bound to AUTH_CRED_C for the first time ever, irrespective of the target audience.

* CASE 2. The public authentication credential of C (AUTH_CRED_C) within the access token issued for a target audience, when the AS issues an access token for that target audience and bound to AUTH_CRED_C for the first time ever.

* CASE 3. The public authentication credential of RS (AUTH_CRED_RS) in the Access Token Response from the AS to C, when C asks the AS for an access token to access resources at that RS for the first time ever. Besides considering a single RS, this can be generalized to a group-audience comprising multiple RSs, each with its AUTH_CRED_RS.

In any other case, C and AS are expected to specify authentication credentials by reference, assuming that the reference can be understood by the other party, which stores the previously obtained authentication credential by value.

However, the other party might have deleted the authentication credential, hence becoming unable to process the reference, and needing to obtain the authentication credential by value again. The following discusses how this can happen, by fundamentally requesting a new provisioning of the relevant authentication credential by value.

The solution to this issue is now defined in draft-ietf-ace-workflow-and-params, in the interest of the ACE framework at large. This profile might ignore mentioning this specific issue, in order to avoid a normative reference to -ace-workflow-and-params. Instead, it can keep the current informative reference to -ace-workflow-and-params, as more broadly covering not only the alternative workflow, but also other new features of the ACE framework.

### Pertaining to Case 1 - The AS has forgotten AUTH_CRED_C

In this case, there is an issue when C requests an access token by sending to the AS an Access Token Request, specifying AUTH_CRED_C by reference in the parameter "req_cnf".

Proposed solution: the AS replies with a 5.00 (Internal Server Error) error response, whose payload specifies a new error code "Unknown credential referenced".

The error code has first to be registered in the IANA registry "OAuth Extensions Errors", and the corresponding CBOR abbreviation has to be registered in the IANA registry "OAuth Error Code CBOR Mappings". Per the update made in draft-ietf-ace-workflow-and-params, this error code is expected to be used not in the legacy error data structure defined in RFC 9200, but rather in a concise-problem-details data item.

When C receives such a response with that error code, C can send a new Access Token Request to the AS, specifying AUTH_CRED_C by value in the parameter "req_cnf".

### Pertaining to Case 2 - The RS has forgotten AUTH_CRED_C

There should be nothing to do about the ACE framework at large here.

Instead, it should be about RS telling C to provide AUTH_CRED_C by value during the establishment of their secure association based on AUTH_CRED_C and AUTH_CRED_RS.

For example, with reference to the EDHOC and OSCORE profile, RS can abort the EDHOC execution and send C an EDHOC error message with ERR_CODE 3 (Unknown credential referenced), in case C specifies AUTH_CRED_C by reference in its outgoing EDHOC message.

Note that, as Christian noted in https://mailarchive.ietf.org/arch/msg/lake/Aq2KEecA1PnX5rXHBYLytoXLuqw/ , ERR_CODE 3 does not cover all possible situations, and additional means have to be defined in EDHOC to ensure that this issue is always addressed.

### Pertaining to Case 3 - C has forgotten AUTH_CRED_RS

In this case, there is an issue when C requests an access token, and the Access Token Response from the AS specifies AUTH_CRED_RS by reference in the parameter "rs_cnf".

(This can be generalized to the case where the target audience is a group audience, and the Access Token Response includes the parameter "rs_cnf2" specifying by reference an authentication credential that C has forgotten.)

Proposed solution: C sends a new Access Token Request to the AS, whose payload also includes the parameter "rs_cnf" with value `true` (0xf5).

This requires to update RFC 9201, in order to extend the semantics of the "rs_cnf" parameter. The extension is about admitting the use of "rs_cnf" also in Access Token Requests, and with only possible value `true` (0xf5). When doing so, C asks the AS to provide AUTH_CRED_RS by value in the "rs_cnf" parameter of the Access Token Response.

If the AS receives an Access Token Request specifying the parameter "rs_cnf" with value `true` (0xf5), then the successful Access Token Response must specify AUTH_CRED_RS by value in the "rs_cnf" parameter.

(As a generalization to a group-audience, all the authentication credentials specified as elements of the "rs_cnf2" parameter of the Access Token Response have to be specified by value)

**===Possible extension===**

There is also the opposite case where C does have AUTH_CRED_RS, but the AS does not know about that early knowledge.

For example, before having requested any access token to access RS, C might have been pre-configured with AUTH_CRED_RS. Alternatively, C might have obtained AUTH_CRED_RS from RS during an early execution of EDHOC where C asked RS to provide AUTH_CRED_RS by value.

When C requests an access token from the AS to access RS, the AS will provide AUTH_CRED_RS by value in the "rs_cnf" parameter of the Access Token Response, since it does not know that C has AUTH_CRED_RS already.

Instead, it is desirable for C to override what is the good, default behavior of the AS and to not have AUTH_CRED_RS by value in the Access Token Response.

To this end, the "rs_cnf" parameter extended as above to use in the Access Token Request can be further extended as follows to take the following two values:

* `false` (0xf4), indicating that the successful Access Token Response must specify AUTH_CRED_RS in the "rs_cnf" parameter. In particular, AUTH_CRED_RS should be specified by reference, or exceptionally by value in case the AS cannot specify a reference.

* `null` (0xf6), indicating that the successful Access Token Response can omit the "rs_cnf" parameter.

### Other cases

* The AS forgets about AUTH_CRED_RS

This is something that has to be fixed by (an administrator on behalf of) the resource owner associated with the RS, in order to provide the AS again with AUTH_CRED_RS.

## Security considerations on using the cnf kccs/kcwt (DONE af354bf4)

Add security considerations on the use of kccs as kcwt confirmation method.

GS: How about just referencing the relevant security considerations of EDHOC?

MT: That might work. Useful text is in the following two pagraphs in https://datatracker.ietf.org/doc/html/rfc9528#name-implementation-consideratio

> Similar considerations as for certificates are needed for CWT/CCS. The endpoints are responsible for verifying the integrity and validity of CWT/CCS and to handle revocation. The application needs to determine what trust anchors are relevant and have a well-defined trust-establishment process. A self-signed certificate / CWT or CCS appearing in the protocol cannot be a trigger to modify the set of trust anchors. One common way for a new trust anchor to be added to (or removed from) a device is by means firmware upgrade. See [RFC9360] for a longer discussion on trust and validation in constrained devices.
>
> Just like for certificates, the contents of the COSE header parameters 'kcwt' and 'kccs' defined in Section 10.6 must be processed as untrusted inputs. Endpoints that intend to rely on the assertions made by a CWT/CCS obtained from any of these methods need to validate the contents. For 'kccs', which enables transport of raw public keys, the data structure used does not include any protection or verification data. 'kccs' may be used for unauthenticated operations, e.g., trust on first use, with the limitations and caveats entailed; see Appendix D.5.

RH (2024-06-13): We discussed and it seems a simple reference to the relevant section in the EDHOC RFC is sufficient.

MT (2025-03-06): Good text is also in https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-edhoc-03#section-6.3 :

> When other types of credentials are used such as CWT/CCS, the application needs to have a clear trust-establishment mechanism and identify the pertinent trust anchors [RFC9528].

## Overview of methods for uploading the Access Token by value (DONE)

Somewhere early in the document, it's helpful to give the reader an early guide through the different ways for uploading an access token by value to RS.

This can be in the same spirit of what is done in https://datatracker.ietf.org/doc/html/draft-ietf-core-observe-multicast-notifications-11#section-3

(The following assumes the use of the EDHOC forward message flow. If the EDHOC reverse message flow is used instead, then replace "EAD_3" with "EAD_2 or EAD_4")

We have fundamentally two methods:

* In EDHOC message_3, include the access token in the new EAD item "ACE-OAuth Access Token" when running EDHOC with RS.

It can be used only by C and only for the first token in a token series, i.e., it cannot be used for updating access rights.

It can be used only in the original workflow, unless C obtains the access token from the AS anyway, and then uses this method in an EDHOC session to (re-)upload the access token after the AS has already uploaded it or attempted and failed.

* Upload the Access Token through a protected POST request to /authz-info at RS

It can be used in both ACE workflows. In the original workflow, it can be used by C only for dynamically updating access rights. In the alternative workflow, it can be used by the AS both for the first access token in a token series and for dynamically updating access rights.

Consistent with the design above, an access token MUST NOT be uploaded to the /authz-info endpoint over an insecure channel.

Without requiring access tokens to be necessarily encrypted by the AS, this ensures that the identity of C is never leaked by either ACE workflow, which is especially desired when EDHOC is run with its forward message flow (i.e., C is the EDHOC Initiator).

**Original ACE workflow - Client point-of-view**

* First Access Token in a token series
* Inclusion in the EAD item of EDHOC message_3
* As intended, terminating a token series coincides with terminating an EDHOC session, and the two concepts are tighly bound together (also by means of the "session_id" parameter).

* Non-first Access Token in a token series
* Protected POST to the /authz-info endpoint
* The exchange is protected with the OSCORE Security Context shared by C and RS, and associated with the token series and the corresponding EDHOC session.

When using the alternative workflow, the Client plays a role in uploading the Access Token only in case the AS fails uploading the Access Token to RS. In such a case, the AS provides the Client with the Access Token so that the Client can upload it to RS itself, according to what is summarized above.

**Alternative ACE workflow - AS point-of-view**

The AS uploads the Access Token to RS, by sending a protected POST request to the /authz-info endpoint. This applies both to the first token in a token series and for the case of update of access rights.

The exchange between the AS and RS is always protected with the secure communication association between the AS and RS, both when uploading a first and non-first Access Token.

As discussed in https://notes.ietf.org/ouQ0t9ZVRLaIXM3w-JGunw# , when the AS uploads a non-first Access Token, the AS explicitly tells RS that the Access Token in question is specifically about updating access rights.

This largely abstracts away from this particular ACE profile, and should better be defined in https://datatracker.ietf.org/doc/draft-ietf-ace-workflow-and-params/ , which can give additional details specific to different transport profiles of ACE.

**Alternative workflow - RS point-of-view**

When receiving a protected POST request to /authz-info that transports a new Access Token T_NEW, RS has to check whether the request is protected specifically with the secure communication association that it shares with the AS. If that's the case, the RS proceeds as follows.

* RS understands which is the Client on behalf of which T_NEW has been posted by the AS. This is possible by means of the 'cnf' claim in T_NEW, which specifies the Client's authentication credential AUTH_CRED_C, by value or by reference.

* RS understands whether this particular uploading is about starting a new token series, or instead about updating access rights.

This is possible by means of the "session_id" parameter, within the "edhoc_info" claim of T_NEW. That is, RS checks if it is storing an Access Token T_OLD such that: i) in its "edhoc_info" claim, T_OLD includes a "session_id" parameter with the same value specified in T_NEW; and ii) in its "cnf" claim, it specifies (by value or by reference) the same AUTH_CRED_C associated with T_OLD.

If an access token is found, then T_NEW is a non-first access token in a token series and is intended for dynamically updating access rights. Otherwise, if an access token is not found, then T_NEW is the first access token in a token series.

However, as also discussed in https://notes.ietf.org/ouQ0t9ZVRLaIXM3w-JGunw# , it's safer that the AS explicitly tells the RS if the uploaded Access Token is exactly intended for updating access rights, by means of an additional parameter included together with the Access Token within the POST request to /authz-info.

Then the RS performs as defined from "If both the conditions above hold ..." in https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-07#section-4.6.1

Note that, if the POST request is protected with a different secure communication association than the one shared with AS, then RS proceeds as it is already defined in https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-07#section-4.6

The above largely abstracts away from this particular ACE profile, and should better be defined in https://datatracker.ietf.org/doc/draft-ietf-ace-workflow-and-params/ , which can give additional details specific to different transport profiles of ACE.

## Early comments from Christian Amsüss (DONE)

https://mailarchive.ietf.org/arch/msg/ace/YHeJMEBEhBT4VGXAP-07D2gARZw/

GS: NO CHANGE as far as I understand.

## Section 3.1 - Proof-of-possession of C's private key at the AS (DONE, 7b8ecce, details in Group OSCORE profile)

===
**MT-2025-06-29**

* s/needs verify/needs to verify
* s/associated to/associated with
* s/have been established/have been accomplished
* s/AUTHCRED_C/AUTH_CRED_C
* s/trusted party/trusted party vouching for C to the AS
* "Otherwise, the Client-to-AS request MUST be declined with the error code "unsupported_pop_key" as defined in Section 5.8.3 of [RFC9200]."

In https://www.rfc-editor.org/rfc/rfc9200#section-5.8.3 , RFC 9200 defines the ACE error code "unsupported_pop_key" with a different meaning: the error code is used to tell C that RS is not able to process such public key of C:

> If the client submits an asymmetric key in the token request that the RS cannot process, the AS MUST reject that request with a response code equivalent to the CoAP code 4.00 (Bad Request), including the error code "unsupported_pop_key" specified in Table 3.

Actually, we are defining new error codes related to the new specific error causes:

- https://datatracker.ietf.org/doc/html/draft-ietf-ace-workflow-and-params-04#section-9.5 is already registering the "unknown_credential_referenced" error code, which the AS return to C when the Access Token Request includes AUTH_CRED_C by reference and the AS does not store AUTH_CRED_C by value. This is the "method" from draft-ietf-ace-workflow-and-params that is now being mentioned in Section 3.1 of this document.

- Also in draft-ietf-ace-workflow-and-params, we plan to register the new ACE error code "failed_pop_verification" in case the AS does not achieve/confirm proof-of-possession of the client's private key. See https://notes.ietf.org/ouQ0t9ZVRLaIXM3w-JGunw#New-ACE-error-code-for-the-error-response-from-token-TODO

Perhaps in this document we can just say something like this?

> Otherwise, the Client-to-AS request MUST be declined with an appropriate error code.

* About the concrete way for the AS to achieve proof-of-possession "in band" upon receiving the Access Token Request from C, we can closely mirror the approach defined in the Group OSCORE profile of ACE, see https://datatracker.ietf.org/doc/html/draft-ietf-ace-group-oscore-profile-04#section-3.2

**GS-25-06-30** I think the use of EDHOC will be the default so I propose to only give a pointer to this.

**MT-2025-06-30** The current pointer looks good and will hopefully be sufficient.

The use of EDHOC as default between C and AS helps the AS achieve proof-of-possession for one authentication credential of C, i.e., the one that C uses when running EDHOC with the AS. If that authentication credential is not suitable for all the intended RSs, then C has to use a different authentication credential with those. Then:

* C runs a separate EDHOC session with the AS using its alternative authentication credential, and will have to talk to the AS on the resulting separate OSCORE association when requesting an access token to be bound to that alternative authentication credential; or

* C keeps using the same OSCORE association with the AS established after the only EDHOC session with the AS, while explicitly providing (at least once) a proof-of-possession for any alternative authentication credential within the Access Token Request message, e.g., with a method like the one in draft-ietf-ace-group-oscore-profile.

We don't have to explain all this (yet), it's just to be aware.

**GS-25-06-30** Update in e06d2c0c

**MT-2025-06-30** Thanks; fixed some nits in https://github.com/ace-wg/ace-edhoc-oscore-profile/commit/233bca5f750cb2ca9747f5b4925392a1c18fe7fa

**GS-25-07-03** Looks good, are we done?

===

Section 3.1 "C-to-AS: POST to /token endpoint" is not discussing how the AS achieves proof-of-possession of the private key of C.

From [Section 3.1 of RFC 9201](https://datatracker.ietf.org/doc/html/rfc9201#name-client-to-as-request) when discussing the "req_cnf" parameter of the Access Token Request:

> Profiles of [RFC9200] using this specification MUST define the PoP method used by the AS if they allow clients to use this request parameter.

Thus, we have to specify how the AS achieves proof-of-possession of the Client's public key when receiving the Client's authentication credential by value in the 'req_cnf' parameter of the Access Token Request, in case the AS has not achieved proof-of-possession for the Client's private key yet.

The current examples in Appendix A are limited to 'req_cnf' specifying the Client's authentication credential AUTH_CRED_C by reference.

This is fine, but it silently assumes that the AS already achieved proof-of-possession of the corresponding private key in the past.

This could have happened, e.g., if the AUTH_CRED_C intended to use for running EDHOC with RS was also used to establish the secure association between the Client and the AS (through EDHOC, or through other means), during which establishment the AS authenticated the Client by means of AUTH_CRED_C and achieved proof-of-possession of the corresponding private key.

Alternatively, this could have happened because a further entity is in a trust relationship with the AS, already achieved proof-of-possession of the private key corresponding to AUTH_CRED_C, and informed the AS about having achieved such proof-of-possession. Building on that trust relationship, the AS simply considers the proof-of-possession of the private key corresponding to AUTH_CRED_C as achieved.

At a high-level, this can be addressed as below.

From C's point of view:

* If C has reason to believe that the AS is already storing AUTH_CRED_C (e.g., from previous interactions), then 'req_cnf' may specify AUTH_CRED_C by reference instead of by value.

* If C has reason to believe that the AS already achieved proof-of-possession of the private key corresponding to AUTH_CRED_C, then the Access Token Request may omit the proof-of-possession evidence for AUTH_CRED_C.

At the AS, a stored authentication credential AUTH_CRED_C is marked as confirmed or non confirmed, in case the AS has achieved proof of possession of the corresponding private key or not, respectively. (This also applies to authentication credentials that the AS has learned from sources different from Access Token Requests, e.g., during the establishment of a secure communication association.)

When the AS receives the Access Token Request, it retrieves AUTH_CRED_C from 'req_cnf':

* If 'req_cnf' specifies AUTH_CRED_C by reference and AS does not already store AUTH_CRED_C, then the AS returns an error response. (Here a new ACE error code is useful).

* If 'req_cnf' specifies AUTH_CRED_C by value, then the AS validates AUTH_CRED_C.

If the validation fails, then the AS deletes AUTH_CRED_C from its local storage if present therein, and returns an error message.

Otherwise, if the AS is not already storing AUTH_CRED_C, then the AS stores AUTH_CRED_C and marks it as non confirmed.

After that, the AS proceeds as follows:

* If the Access Token Request includes the proof-of-possession evidence for AUTH_CRED_C, then the AS attempts to verify the evidence.

If the verification fails, then the AS marks the stored AUTH_CRED_C as non confirmed and returns an error message.

Otherwise the AS marks the stored AUTH_CRED_C as confirmed and proceeds with processing the Access Token Request.

* If the Access Token Request does not include the proof-of-possession evidence for AUTH_CRED_C, then the AS checks how the stored AUTH_CRED_C is marked.

If the stored AUTH_CRED_C is marked as non confirmed, then the AS returns an error.

Otherwise, the AS proceeds with processing the Access Token Request.

The actual verification of the proof-of-possession evidence can work as defined below, based on the same methods currently used in the Group OSCORE profile, see https://datatracker.ietf.org/doc/html/draft-ietf-ace-group-oscore-profile-04#section-3.2

The considered construction has in turn been inherited from https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore, when achieving proof-of-possession for the public key of a group member or of the Group Manager. This is also flexible, since it works with authentication credentials intended for signing, or for key agreement, or for both.

[GS, June 5:] RFC 9201 requires this draft to "define the PoP method used by the AS". Would it be possible to provide options here, either do as in draft-tiloca-ace-group-oscore-profile or as in draft-ietf-lake-authz?

[MT, November 13:] Let's say that the AS receives an Access Token request, where 'req_cnf' specifies AUTH_CRED_C, by value or reference. This AUTH_CRED_C is such that it will work as CRED_I with the RS for which the requested Access Token is issued.

The AS might already have achieved PoP of AUTH_CRED_C in the past, e.g., by running EDHOC with C as Initiator and with exactly AUTH_CRED_C as CRED_I (this is irrespective of using specifically draft-ietf-lake-authz or not).

This is just an example of a broader set of situations where the AS has already achieved proof-of-possession for the Client's private key already and does not have to achieve it again.

In any other case, the AS has to, and it can do that as part of the processing of the Access Token request, by using the method in https://datatracker.ietf.org/doc/html/draft-ietf-ace-group-oscore-profile-03#section-3.2 mentioned above.

### In the DTLS profile

This aspect is somehow handled in the DTLS profile of ACE (RFC 9202), by recommending that the Client uses as PoP key the same public key used for establishing its secure association with the AS. That spares the AS to do anything special to achieve proof-of-possession. However:

* One can wander why, under such premises, 'req_cnf' must be included at all, as it is in the examples of RFC 9202.

* This is also assuming that the same public key that the Client uses with the AS is also eligible to use with the RS in their later DTLS handshake, i.e., as consistent with the algorithms that the Client would like to use and that the RS supports.

## Editorial: diff appendix from v -07 to v -08 (DONE)

* KUDOS is just an example of protocol to use for optional key update.
* message_4 is mandatory to support for an RS that supports the reverse message flow.
* Method in -workflow-and-params as example for coordinating the exchange of authentication credentials by value or reference.
* Revised initial set of EDHOC_Information parameters.
* Defined categorization of EDHOC_Information parameters.
* New EAD item for C to retrieve Request Creation Hints information from RS.
* Means for the AS to achive proof-of-possession of C's private key.
* Editorial improvements.
* ...

**GS-25-06-30** Copy-pasted this