-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
c_nonce as access token claim #142
Comments
In Italy the Credential Issuer and the Authorization Server are the same entities. In this case I don't see any advantages in having c_nonce in the AT, but maybe I'm missing something. |
Yes
You are correct. In this case generated c_nonce can be trusted because Credential Issuer can query the generated nonce from the same database.
Yes only if Credential Issuer and the Authorization Server are the same entities. If they are different entities, then c_nonce can be trusted only if its included in AT claim. Or AS requests Nonce endpoint from Credential Issuer during Token endpoint request. Or Credential Issuer Credential Endpoint is requested two times, where first requests returns error with generated c_nonce. |
@aarmam a well known practice Is the issuance of the nonce as encrypted Sharing the sane private secreta between the nodes of the same cluster, when the nonce Is provided It can be decripted Having the c_nonce in the AT Is possible (nothing prevents you to not add It there or/and any other claim you like) and this doesn't produce any interop issue, since the flow happens with the same vci solution The only considerations i want to do in having c_nonce out of the at,Is that the at (bearer) represent what you have while the c_nonce represents what you know |
Someone would say that since the at Is a bearer, providing the nonce within It It would be like not providing the nonce at all, because this would represent another factor of outside of the bearer |
@aarmam I'm closing this issue according to the evidence that AT may be non-JWT and that also having the x_nonce outside the AT adds more security with a specific endpoint (credential endpoint) Please feeel free to open it again for any further consideration about this topic and thank you so much for this issue |
I continue the discussion started in openid/OpenID4VCI#39
Im not sure if I understand everyhing here. OAuth 2.0 allows using AT as JWT and this is how Italy's implementation is returning it in token endpoint. Currently c_nonce is also returned from token endpoint. So why would returning c_nonce as AT claim be unsecure? How exactly would including c_nonce in AT claim reduce security? The c_nonce is used to prevent replay so it is one time use only. The AT is sender-constrained so that only the authorized sender can use it. The AT jti claim is used to prevent replay. What am I missing?
If Credential Issuer (RS) and Authorization Server (AS) are the same entity (same server/database), then generated c_nonce can be trusted by Credential Issuer without requiring AS to request Nonce Endpoint from Credential Issuer.
The reason why I suggested using c_nonce as AT claim is when Credential Issuer (RS) and Authorization Server (AS) are not the same entity. If c_nonce is included in AT claim then the AS generated c_nonce can be trusted by Credential Issuer and AS does not have to make request to Nonce Endpoint.
The text was updated successfully, but these errors were encountered: