[OpenID4VCI] remove c_nonce from the token endpoint

[peppelinux]

Another breaking change is on the way
openid/OpenID4VCI#199

[peppelinux]

in italy we have implemented that for the wallet AS but not for the OIDC impl.

I'm requirement driven and then I feel neutral with the solution, afaik the discussion could be moved towards having a PoP with dpop/mtls and removing c_nonce.

While moving to DPoP/mTLS and leaving c_nonce optional would inflate the specs, we could use pop just with dpop, but at the same time making dpop/mtls mandatory will impacts the token endpoint as well.

in italy we have implemented dpop for the access token pop and c_nonce for the jwk pop to be used to the credential endpoint.

even id we use dpop only without c_nonce or c_nonce without dpop or these two together, the token endpoint response must then be extended for security reasons.

probably c_nonce was born to simplify things, considering dpop more complex (even if more generalized and usable for different contexts).

@asharif1990 WDYT?

[asharif1990]

in italy we have implemented that for the wallet AS but not for the OIDC impl.

I'm requirement driven and then I feel neutral with the solution, afaik the discussion could be moved towards having a PoP with dpop/mtls and removing c_nonce.

While moving to DPoP/mTLS and leaving c_nonce optional would inflate the specs, we could use pop just with dpop, but at the same time making dpop/mtls mandatory will impacts the token endpoint as well.

in italy we have implemented dpop for the access token pop and c_nonce for the jwk pop to be used to the credential endpoint.

even id we use dpop only without c_nonce or c_nonce without dpop or these two together, the token endpoint response must then be extended for security reasons.

probably c_nonce was born to simplify things, considering dpop more complex (even if more generalized and usable for different contexts).

@asharif1990 WDYT?

from my point of view, I am in favor of keeping c_nonce as an optional as it is better than to get it as a consequence of an error from the AS. I think by mandating the DPoP and keeping c_nonce as optional we are not going to bring the complexity. Because they are serving different purposes. While the DPoP as you mentioned served as a PoP of Access token to avoid the problem of using a Stolen Access Token, the latter provides a way to avoid the key proof replay. I would say that returning the c_nonce from the AS token endpoint and/or credential endpoint is better than a method to obtain it through an error.

[peppelinux]

your though fits perfectly with the specialization of different parameters for different purposes and I fully agree with you

[fmarino-ipzs]

@peppelinux this issue is no longer applicable. I'm closing it.