Add DPoP-Nonce to the nonce endpoint

[paulbastian]

It may be beneficial to optionally return a DPoP-Nonce header along the Nonce Endpoint response, so that the Wallet saves a roundtrip & cryptographic operations to fetch a nonce for DPoP protected access tokens.

[bc-pi]

Seems not unreasonable :)

[babisRoutis]

Hi @paulbastian

Sounds good to me. Something like the example bellow, I guess

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v

{
  "c_nonce": "wKI4LT17ac15ES9bw8ac4",
}

Have a couple questions:

1. To my understanding, c_nonce and DPoP-Nonce have different values. Can you please confirm?
2. How wallet (acting as oauth2 client) should treat this DPoP-Nonce? DPoP makes a distinction between Authorization Server-provided and Protected Resource-Provided DPoP-Nonce.

IMHO, wrt (2), this DPoP-Nonce is mainly a Protected Resource Provided. Yet, wallet should also use it as an authorization server provided value, in case the issuer acts also as an authorization server (no authorization_servers` to the metadata)

[bc-pi]

Hi @paulbastian

Sounds good to me. Something like the example bellow, I guess

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v

{
  "c_nonce": "wKI4LT17ac15ES9bw8ac4",
}

Have a couple questions:

1. To my understanding,  `c_nonce` and `DPoP-Nonce` have different values. Can you please confirm?

They can but aren't required to have different values.

2. How wallet (acting as oauth2 client) should treat this `DPoP-Nonce`? DPoP makes a distinction between [Authorization Server-provided](https://datatracker.ietf.org/doc/html/rfc9449#name-authorization-server-provid) and [Protected Resource-Provided](https://datatracker.ietf.org/doc/html/rfc9449#name-resource-server-provided-no) `DPoP-Nonce`.

IMHO, wrt (2), this DPoP-Nonce is mainly a Protected Resource Provided. Yet, wallet should also use it as an authorization server provided value, in case the issuer acts also as an authorization server (no authorization_servers` to the metadata)

The nonce endpoint is a Protected Resource so a DPoP-Nonce value it might return is only for Protected Resources on that server. It might also work at the authorization server when the authorization server is co-resident with the credential issuer but I don't think much, if anything, should be said in spec about that.

[babisRoutis]

@bc-pi
Thank for your feedback. And yes I agree with both comments

Indeed, it doesn't matter if the DPoP-Nonce is the same /or not with c_nonce. There will be different signing keys for each.

IMHO, if DPoP-Nonce will be included to the nonce response, spec should have a clarification like the one that you provided (that is, DPoP-Nonce is a Protected Resource-provided value).

[jogu]

I think the nonce endpoint is already permitted (by the DPoP RFC) to include a DPoP-Nonce header in it's response, so I'm not sure any normative text in OID4VP is required?

Is the suggestion then to add something non-normative just mentioning this is a possibility?

[tlodderstedt]

WG discussion: there is interested and support, asked Paul to file a PR