-
Notifications
You must be signed in to change notification settings - Fork 19
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
Clarification on the Credential Endpoint #313
Comments
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.
there comes in help the 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? |
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."
Could you please indicate in which cases the If the Issuer does not use the If the Issuer does send a
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. |
@andprian I have attempted to address your valuable comments in this PR: https://github.com/openid/OpenID4VCI/pull/323/files |
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:
I think the Issuer's behavior in such cases should be explicitly specified. |
|
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.
i would not say so... |
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. |
@paulbastian i think that last comment is more relevant to #331 ? |
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:
The text was updated successfully, but these errors were encountered: