1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

7 How is the VC replay is being addressed?

Issue #1423 resolved
Nat Sakimura created an issue

Section 7 talks about the presentation replay. However, it was not quite clear how the VC replay is being addressed from scanning the spec. It would help readers if it can be listed as a parallel to the presentation replay. Unless VC itself is bound to the subject of the presentation via subject identifier or a cryptographic proof or something like a nonce, it would seem trivially easy to replay as VCs are potentially going to be presented to many places.

e.g., making a structure like:

7.1. Preventing Replay Attacks
7.1.1 Prevention of the presentation replay
7.1.2 Prevention of the VC replay

‌

Comments (17)

  1. Torsten Lodderstedt

    The spec assumes that VCs are always provided within a cryptographically protected presentation The presentation itself is bound to the transaction as described (nonce and aud).

    Would adding text along those lines address your comment?

  2. Kristina Yasuda

    VCs are multi-use by nature, in other words, VCs are meant to be “replayed“. What differentiates “replay“ by a legitimate holder and a “replay“ by a malicious user is a binding is a VP, or any other mechanism of proof of possession of a VC. Sure, depending on a PoP mechanism, you may end up with with potential RP correlation, which is why ZKP/blinded signature work has attracted so much attention, but that does not change the replayable nature of VCs.

    We can add a text that this specification does not support presentation of bare VCs - throughout the text we are clear it’s VPs that we are talking about, but I would not be in favor of adding a text on “preventing“ VC replay.

  6. Nat Sakimura reporter
    • changed status to open

    Since VCs are multi-use, it cannot be bound to a nonce. Thus, the binding between the presentation and VC need to happen through other mechanisms. What I understand from the text in the PR #116 is that it is done through client_id but it is not obvious how it can actually be done just by reading it. A reference to a section that describing the actual mechanism of doing it would be great.

  7. Torsten Lodderstedt

    Since VCs are multi-use, it cannot be bound to a nonce.

    That’s correct. That’s why a verifiable credential is always presented with a verifiable presentation.

    (1) The binding between verifiable presentation and VC is achieved using a proof of possession of the key material the VC is bound to (by the VC issuer). (2) The verifiable presentation of the VC is bound to the actual OIDC TX and audience by the nonce and client_id.

    (1) The concept of VC and VP is described in the W3C VC spec and is an underlying concept of the OIDC4VPs spec. The concrete implementation, however, is specific to credential format and crypto scheme and out of scope for OIDC4VPs.

    (2) All presentation format have some sort of transaction binding and audience restriction. The concrete implementation, however, is specific to credential format and (sometimes) the crypto scheme. We therefore describe the concept and the requirements and give examples in section 7.1, but we cannot normatively require a certain solution.

  8. Stephane Durand

    Hi Torsten,

    I think we are in line but I’d like to reformulate your response to make sure:

    • VP is bound to the transaction by the nonce and the client by the audience value. VP is signed by the OP for authoring.
    • VP contains VCs which are multi-use and are generally issued by entities different from the OP. VC are signed by such other entities.
    • It is worth noting that proving ownership of a VC cannot rely on the VP signature only and therefore falls out of the scope of this specification.

    For example, proof of VP ownership can stem from:

    • The VC itself when the VC issuer “assigned” it to the OP crypo material
    • The VP signature when the OP can claim some attestations that would provide some trust on how the OP receives and protects VCs until using them in VPs.

    I was in particular concerned with the following statement because if one stops at reading it, they might feel that the problem is solved.

    The binding between verifiable presentation and VC is achieved using a proof of possession of the key material the VC is bound to (by the VC issuer)

    However, I don’t remember seeing in W3C’s VC nor in OIDC4VP that a VC has to be bound by its issuer to a certain key material and that possession of said key material should be provable. So while I agree with the principles in your proposition, their realization is highly dependent on design choices. (And you seem in line with that given your further comments.)

    I commented a note in PR116 that reflect this concern of mine.

  9. Kristina Yasuda

    The VC itself when the VC issuer “assigned” it to the OP crypo material

    Could you please elaborate what do you mean? using the same key to sign ID Token and VC? This might work in non-SIOP model, but then why would you use a VC? use userInfo or claims in the ID Token.

    I think we all agree that there are a lot of ways to “cryptographically“ prove possession of a VC other than “VP contains VCs“. That model where ownership of a VC is being proved by VC’s sub matching VP’s iss is unique to JWT-VCs. The PoP model becomes quite different for other formats like AnonCreds where there is no need to send the original VC to prove ownership of it. A derived VC that proves “possession of the key material the VC is bound to“ becomes a VP. Linked Data Proofs are the same I think.

    I don’t remember seeing in W3C’s VC nor in OIDC4VP that a VC has to be bound by its issuer to a certain key material 

    I think, de facto, the VCs, of which the user cannot cryptographically prove possession of (like Smart Health Cards) are out of scope of the specification at the moment.

  10. Stephane Durand

    The VC itself when the VC issuer “assigned” it to the OP crypo material

    As the VC is generated by the issuer, it could feature an ‘aud’ field when there is nothing that could relate to the ‘sub’ (as I didn’t see sub was a mandatory field of VC). Let this aud/sub be the SIOP owner then, as the VC is signed by the issuer, this binds the intended possession with the SIOP owner.

    I’m not sure what ID Token you are referring to because I expect VC is signed by VC issuer and ID Token by SIOP and these have different keys.

    I think, de facto, the VCs, of which the user cannot cryptographically prove possession of (like Smart Health Cards) are out of scope of the specification at the moment.

    That’s probably the real “misunderstanding” between us. I agree with your previous statement under the assumption that we are only considering VCs whose “possession” (I don’t like this word.. I don’t understand possession as me being entitled to use it, just that I have access to it) can be proven. But I didn’t see that assumption clearly mentioned and that was actually my point.

  11. Michael Jones

    We discussed this during the 24-Feb-22 SIOP special topic call. John observed that we need to say where the nonce comes from in the request and where it goes in the VP.

  13. Jeremie Miller Account Deactivated

    That’s probably the real “misunderstanding” between us. I agree with your previous statement under the assumption that we are only considering VCs whose “possession” (I don’t like this word.. I don’t understand possession as me being entitled to use it, just that I have access to it) can be proven.

    I agree that possession is an ambiguous term for this and should be avoided.

    But I didn’t see that assumption clearly mentioned and that was actually my point.

    There’s probably some implicit understanding by some that a presentation is not “verifiable” if it is just a straight copy of a VC. Like with Smart Health Cards, you are verifying the credential and not a presentation of it.

    Personally, my stance is that a presentation is only verifiable if it has a strong/cryptographic mechanism for replay prevention.

  14. Nat Sakimura reporter

    So, have there been any updates regarding this ticket?

    If it is out-of-scope of this document to describe the binding, then it should say so in the beginning, preferably in the section that explains the scope of this document, and not in the Appendix. Perhaps explaining it in the Abstract would do. Otherwise, I would create a new section, “2. Scope of this document.”

    Also, it would be reasonable to draw the attention of the reader to the fact that the sub of the VC and the iss of the VP must be equal in the case of JWT VCs.

    Additionally, it probably is a good idea to warn that there are VC/VP combinations that lack binding.

  15. Torsten Lodderstedt

    This topic should be covered in section 10.2. After just reading it again I think the text needs to be adopted to be inline with the latest revision of the spec (it still mentions VPs in ID Token, which we do not support any longer). We could also add more text re the different kinds of holder binding. We have some text in the issuance spec for that.

  18. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
Verifiable Presentation
Milestone
–
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!