Closed peppelinux closed 6 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?
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.
your though fits perfectly with the specialization of different parameters for different purposes and I fully agree with you
@peppelinux this issue is no longer applicable. I'm closing it.
Another breaking change is on the way https://github.com/openid/OpenID4VCI/pull/199