Open paulbastian opened 2 weeks ago
Seems not unreasonable :)
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:
c_nonce
and DPoP-Nonce
have different values. Can you please confirm?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)
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.
@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).
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.