[Openid-specs-ab] Issue #1577: Cryptographic proof of possession nonce management (openid/connect)

[Tobias Looker]

New issue 1577: Cryptographic proof of possession nonce management
https://bitbucket.org/openid/connect/issues/1577/cryptographic-proof-of-possession-nonce

Tobias Looker:

The first valid c\_nonce value for a client is returned from the token endpoint, with subsequent c\_nonce values returned from the credential endpoint response when the presented nonce is invalid.

One observation that has been made is that extending the members present in the token endpoint response can be a barrier to certain implementations that want to make use of an unmodified authorisation server. Therefore if the initial nonce is not present in the token endpoint response, then where is it sourced from?

In my opinion there are few options we could consider

1. Leave it as is, implementations need to extend the token response object. Downside as discussed above
2. A seperate nonce endpoint which is the single endpoint where all nonces required for PoP’s would be sourced from. Downside a new round trip of req/res required to obtain the nonce.
3. Define that the initial c\_nonce value is the hash of the issued access\_token, credential endpoint will return a suitable error alongside a fresh nonce when the one supplied is no longer valid. Downside to this approach is that the initial nonces validity is entirely opaque to the client \(e.g it doesn’t know when it expires so it just has to try it\).
4. Dont return initial nonce from token endpoint, instead the client is expected to make a request to the credential endpoint omitting the nonce and expects the request to fail on purpose so it can obtain a valid nonce. Downside is sending knowingly invalid requests.

Also as a related FYI, there is some language to relax the normative statements around c\_nonce related to this PR that Oliver Terbu is going to submit a PR for

‌