-
assigned issue to
7 How is the VC replay is being addressed?
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)
-
-
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.
-
Having said that I added a text to a PR #116. https://bitbucket.org/openid/connect/commits/78a118067e3eb84fc30fc3ecf564a87db401afcb
Note: This specification does not support presentation of a VC that is not cryptographically protected by a VP. The presentation itself is bound to the transaction as described in this section.
-
- changed status to open
2022-01-27 SIOP call
-
- changed status to resolved
addressed in PR #116
-
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.
-
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.
-
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.
-
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’siss
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.
-
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.
-
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.
-
The “from” is precisely defined the spec (see https://openid.bitbucket.io/connect/openid-connect-4-verifiable-presentations-1_0.html#name-security-considerations), the “to” varies among credential formats. Therefore the spec defines the objective and gives an example for JWT-based VPs. Since we intend OIDC4VPs to be format agnostic I don’t see how we can be any more precise.
-
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.
-
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 theiss
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.
-
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.
-
This is being covered in PR #489. resolving after that PR is merged.
-
- changed status to resolved
PR #489 merged
- Log in to comment
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?