How does the wallet obtain the nonce for issuing sender-constrained access token?

[andprian]

OID4VCI states that

7.2 The Credential Issuer MAY provide a DPoP nonce in an HTTP header as defined in Section 8.2 of [RFC9449].

8.2 is about obtaining a new nonce, so I suppose one should rather follow clause 8. Authorization Server-Provided Nonce for the initial nonce, that indicates that the nonce is returned in an error response to the token request

On the other hand, HAIP states:

Sender-constrained access token: MUST support DPoP as defined in [RFC9449]. Note that this requires Wallets to be prepared to handle the DPoP-Nonce HTTP response header from the Credential Issuer's Nonce Endpoint, as well as from other applicable endpoints of the Credential Issuer and Authorization Server.

I do not understand why support of RFC9449 requires the wallet to handle something from the nonce endpoint.

It seems to me that some clarification would be beneficial here. Can we clearly state how the wallet obtains the first nonce (from the token request as in RFC9449 or nonce endpoint?) and how the nonce is renewed afterwards?

[jogu]

As per https://www.rfc-editor.org/rfc/rfc9449.html#section-8.2 the token endpoint can return a use_dpop_nonce error requiring the request to be resubmitted with a new nonce.

The wallet can (but doesn't have to) get the dpop nonce from the Nonce Endpoint. The AS can (but doesn't have to) return a dpop nonce from the Nonce Endpoint that would be valid at the token endpoint.

If the AS doesn't provide a working dpop nonce via the nonce endpoint, or the wallet doesn't use that dpop nonce, then you get the default (mandatory to implement) dpop behaviour of getting the nonce in an error from the token endpoint.

Suggestions on how to clarify the text are very welcome!

[andprian]

The wallet can (but doesn't have to) get the dpop nonce from the Nonce Endpoint. The AS can (but doesn't have to) return a dpop nonce from the Nonce Endpoint that would be valid at the token endpoint.

Is there a way for the AS to signal that the sender-constrained access token works also with nonces from the nonce endpoint?

Also, it seems to me that what you are saying ("The wallet can (but doesn't have to) get the dpop nonce from the Nonce Endpoint.") contradicts what is stated in HAIP, starting from Note :

Sender-constrained access token: MUST support DPoP as defined in [RFC9449]. Note that this requires Wallets to be prepared to handle the DPoP-Nonce HTTP response header from the Credential Issuer's Nonce Endpoint, as well as from other applicable endpoints of the Credential Issuer and Authorization Server.

If the AS doesn't provide a working dpop nonce via the nonce endpoint, or the wallet doesn't use that dpop nonce, then you get the default (mandatory to implement) dpop behaviour of getting the nonce in an error from the token endpoint.

In practice, is there a reason for anyone to support this feature via additional mechanisms other than what is specified in the RFC 9449?
And if the mechanism in RFC 9449 is to be understood as mandatory, VCI should reference clause 8 directly, not 8.2 which only refers to getting a new nonce, not the initial one.