Clarification on the Credential Endpoint

[andprian]

Section 7 states that "The Client can request issuance of a Credential of a certain type multiple times, e.g., to associate the Credential with different public keys/Decentralized Identifiers (DIDs) or to refresh a certain Credential."

Does this mean that the Issuer is obliged to accept such requests (same type but different public keys for example) with the same Access Token?

Also, what is the expected behavior when the Credential Request is sent multiple times with exactly the same Access Token and the same parameters every time? Should the Issuer:

1. Return the same Credential or
2. Generate a new Credential every time or
3. Reject the request if he already returned one such Credential?

[peppelinux]

Does this mean that the Issuer is obliged to accept such requests (same type but different public keys for example) with the same Access Token?

Yes, unless the access token is intended for multiple uses with a specific Resource Server, such as the Credential Endpoint.

The Credential Endpoint can issue multiple credentials if the authorization for that specific access token permits it (as specified in the authorization_details), using different JWT proofs for cryptographic key binding. Where the multiple JWT proofs are recommended for privacy reasons, to prevent credential linkability.

Also, what is the expected behavior when the Credential Request is sent multiple times with exactly the same Access Token and the same parameters every time?

there comes in help the c_nonce, that in some implementation profiles is mandatory.

Good points. From my personal perspective if the parameters are the same that would be a reply -> reject.

When the same credential is requested, with a different nonce but the same jwt_proof -> revocation of the previous one and issuance of the new one.

is this something to be further explored for the "implementation considerations" section, or for the security consideration one?

[andprian]

Yes, unless the access token is intended for multiple uses with a specific Resource Server, such as the Credential Endpoint.

OK, section 6.2 brings clarification stating that "The Authorization Server might decide to authorize issuance of multiple instances for each Credential requested in the Authorization Request."
But then for me the paragraph in Section 7 saying the Client can request issuance of a Credential of a certain type multiple times is not completely accurate. The Client can request this, but it is not guaranteed that the Issuer supports this.

there comes in help the c_nonce, that in some implementation profiles is mandatory.

Could you please indicate in which cases the c_nonce feature must be implemented by the Issuer? It seems to me that is always optional from the Issuer's point of view.

If the Issuer does not use the c_nonce , should he accept replies?

If the Issuer does send a c_nonce but does not refresh it in all subsequent responses he returns and the initial c_nonce is still valid, on what grounds can the Issuer reject a Credential Request with exactly the same parameters?

When the same credential is requested, with a different nonce but the same jwt_proof -> revocation of the previous one and issuance of the new one.

Would an Issuer be entitled to make the decision of revoking someone's Credential for these kind of technical reasons? There might be also legal considerations to take into account here.

I think it would be useful to explore these cases and not only from a security point of view but to bring clarity, because it is not clear how the Issuer is supposed to respond.

[peppelinux]

@andprian I have attempted to address your valuable comments in this PR: https://github.com/openid/OpenID4VCI/pull/323/files

[andprian]

The PR #323 clarifies some of the points I addressed but I still have 2 questions that remain regarding the Issuer's behavior. For a Credential Request with exactly the same parameters:

1. If the Issuer does not use the c_nonce, should he accept replies?
2. If the Issuer does send a c_nonce but does not refresh it in all subsequent responses he returns and the initial c_nonce is still valid, should he accept replies?

I think the Issuer's behavior in such cases should be explicitly specified.

[peppelinux]

1. this aims to be addressed here: https://github.com/openid/OpenID4VCI/pull/323/files#diff-1f424614b35a9899813079f1b1f6218631a2aedd993368ccb89bb81a9eda0289R701

2. it would be a bogus nonce issuance, here a PR aiming to clarify the requirements behind the c_nonce issuance

[Sakurann]

Does this mean that the Issuer is obliged to accept such requests (same type but different public keys for example) with the same Access Token?

Yes, unless the access token is intended for multiple uses with a specific Resource Server, such as the Credential Endpoint.

I would not say so... it is up to the issuer to define the lifetime of an access token, so if the issuer (AS) wants to allow the usage of the AT only to request a credential once, that is totally ok.

Also, what is the expected behavior when the Credential Request is sent multiple times with exactly the same Access Token and the same parameters every time? Should the Issuer:

Return the same Credential or
Generate a new Credential every time or
Reject the request if he already returned one such Credential?

there comes in help the c_nonce, that in some implementation profiles is mandatory.

i would not say so... c_nonce only ensures that the proof is one time use. it is up to the issuer to control the validity of the AT and the behavior. when the wallet is requesting issuance of the same credential bound to a different proof (if it is the same proof but a different c_nonce, sounds pretty sketchy..) and AT is still valid and is scoped for that, the issuer can issue another credential, or can reject, or force the wallet to get a new AT.

[paulbastian]

My opinion on this is, that we should limit optionality to make implementations easier. Access Token lifetimes have no guarantees, so I would not use "Access Token Hash" as an substitute for nonce. Also, the "jti" approach puts additional burden on the Credential Issuer. I propose to clarify that c_nonce in the proof is always required and it may either be provided by AS or Credential Issuer.

[Sakurann]

@paulbastian i think that last comment is more relevant to #331 ?