c_nonce as access token claim

[aarmam]

I continue the discussion started in openid/OpenID4VCI#39

OAuth 2.0 doesn't require AT in JWT format, then the flow must be designed as the AT was opaque. Thus, the (un)security of the AT as a bearer token, having the c_nonce within It would reduce the security of the token endpoint, where the distinguished AT and c_nonce mades something you have (bearer) and something you know (c_nonce)

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?

Formally the credential endpoint is an RS, no matter if It is within the same node or not.

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.

We have a concrete proposal with the nonce endpoint as well, if confirmed we'll have It in a PR. The sole concern Is that we want to issue a single nonce and that's good for auth code flow but not for pre-authz code flow (we don't use, but It would be better using a solution usable even in other implementation profiles).

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.

[fmarino-ipzs]

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. If I got correctly your proposal, it only applies in case of JWT AT which is our case, but not in general. On the other hand, having a c_nonce in the token response is a more flexible approach. WDYT?

[aarmam]

If I got correctly your proposal, it only applies in case of JWT AT

Yes

In this case I don't see any advantages in having c_nonce in the AT, but maybe I'm missing something.

You are correct. In this case generated c_nonce can be trusted because Credential Issuer can query the generated nonce from the same database.

having a c_nonce in the token response is a more flexible approach. WDYT?

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.

[peppelinux]

@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

[peppelinux]

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

[peppelinux]

@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