[oidc4vci] Remove nonce endpoint

[Tobias Looker]

As is currently defined in https://openid.net/specs/openid-connect-4-verifiable-credential-issuance-1_0.html#section-6.3

“The Client MUST obtain a presentation nonce from the Issuer, when the Client needs to submit certain pre-obtained credentials to the Issuer to meet the requirements in one of the Issuer's Credential Manifests. The Client MUST bind credentials it is submitting to the received presentation nonce. This step is necessary to prevent submitted VCs from being replayed by a malicious Client.”

If the presentation of VC’s is scoped to the OP (e.g defines them as the domain/aud) and the OP keeps track of nonces it has seen before then replay attacks are mitigated without having to rely on server side generated nonce

[Kristina Yasuda]

We should avoid a design which requires state management by the Issuer server, because it becomes unmanageable by the large-scale implementations with millions of transactions.

As has been described in DPoP discussion in IETF, large-scale implementations prefer server-provided nonce because it allows the server not to store the nonce. Detailed description is in this comment (https://github.com/danielfett/draft-dpop/issues/92#issuecomment-1028196861), but for example what Microsoft does with server nonce in DPoP is to sign over current_time as JWS and use it as a nonce. When the nonce comes back, the server only need to validate the signature and that current_time is recent enough.

Therefore, I am in favor of keeping a nonce endpoint.

[Tobias Looker]

If the goal is to prevent a party from performing a malicious replay attack then I still don't think this solution guarantees that without some statement management, e.g I could still replay multiple VPs within the clockskew tolerance afforded by the server validating these “self style signed nonces”. Furthermore you can get the same guarantees without the server side nonce if you require the requestor to time bound the VP as strictly as the server would time bound validation of their nonce giving you the same protection with less interactivity. I’d also note that the server supplied nonces in DPoP are optional not required.

[Tobias Looker]

Put another way, in the microsoft model you referred to the nonce is not being checked for its uniqueness instead its being used as a signed time stamp from the server. If instead you put the same timestamp the VP (e.g when the VP was created “iat”) and validate that instead of the nonce against the server time, you have essentially the same replay attack protection.

[Pieter Kasselman]

Relying on the clock of the requestor creates additional clock synchronisation issues between the requestor and server (e.g. the requestor clock may be ahead of the server, or may be lagging by a significant amount). Keeping those in a reasonable level of synchronisation is not always practical, especially as the client scale in numbers.

DPoP defines the nonce as opaque to the client and leaves it up to the server to decide on implementation. DPoP does not prescribe or preclude any implementations and defines the nonce as opaque to the client. Using the signed server time as the nonce, or part of the nonce is one implementation that avoids some of the state management issues as well as the clock synchronisation issues (only the server clock needs to be taken into account), while mitigating against replay and pre-computed responses.

The use of server supplied nonces allows freshness checks while avoiding the clock synchronisation between requestor and server.

[Tobias Looker]

Understood thanks Pieter, I can see at scale (of client instances) how mitigating the clock sync issues is a benefit of a server generated nonce (if the server chooses to created a sign timestamp style nonces). However I will note that the nonce endpoint in DPoP is optional so is there an option within this protocol to make this optional? E.g be-able to present VP’s not featuring a server generated nonce?

[Michael Jones]

As for the DPoP server nonce being optional:

1. I expect that most security-conscious deployments will use it. (And those choosing to use DPoP instead of bearer tokens are already security conscious.)
2. We’ll see if it stays optional after our discussions in Vienna. It took a while for the OAuth WG to come to terms with the threats that the server nonce mitigates, but it seems to me that people are becoming more versed in the threats and more comfortable with the solution.

I see the server nonce in this spec as being very parallel to the DPoP nonce, both in mechanism and in motivation.

‌

‌

[Kristina Yasuda]

There is no equivalent to DPoP JWT in this specification, so server-side nonce becomes the only mechanisms we can use to prevent replay.

[Kristina Yasuda]

In the discussion with Torsten, Tobias and Daniel F, we agreed that it is very hard to prevent replay of a VP being sent in the Authorization Request, because `p_nonce` is not tied to the Authorization Request.

PR #134 to remove a nonce endpoint and the option to send a VP in the Authz request in general.

[Michael Jones]

Replay prevention matters. If we’re not going to do it with a server-supplied nonce, how are we going to do it? I would request that we not remove the nonce endpoint until we’ve figured this out and provided an alternative.

[Jeremie Miller]

If we adopt my suggestion in #1450, the holder can always use the access token as the nonce input to a presentation to secure it.

All presentation exchange interactions would be protected by the access token as well.

[Kristina Yasuda]

PR #134 removes not only the nonce_endpoint, but an entire option to submit a VC in the Authorization Request. It is done because even using nonce_endpoint proved to be challenging to prevent replay of such a VC without p_nonce being tied to the Authentication Request itself. What I mean is there is no way for the server to know if the client sending a VP with a p_nonce is the same client who received a p_nonce.

We initially modelled it after DPoP, but I think this use-case was different from DPoP, because in DPoP, server-provided nonce is to prevent the client to mint DPoP JWTs bound to the future time,

Though server-provided nonce in DPoP used at the authorization endpoint should have the same risk this p_nonce had…?

[Kristina Yasuda]

2022-Mar-17 SIOP call merged PR #134