italia / eudi-wallet-it-docs

Italian EUDI Wallet Technical Specifications
Creative Commons Zero v1.0 Universal
55 stars 18 forks source link

[OpenID4VCI] remove c_nonce from the token endpoint #183

Closed peppelinux closed 6 months ago

peppelinux commented 8 months ago

Another breaking change is on the way https://github.com/openid/OpenID4VCI/pull/199

peppelinux commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

fmarino-ipzs commented 6 months ago

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