- edited description
Verifiable Presentations do not work outside of their own protocol.
This is sort-of a follow up to Tony’s concerns.
It may be that a work-around exists, but if so that needs to be explicitly documented. The following is a question i had on Slack with Orie and Tobias. It seems that VPs, on their own, do not prevent replay. They depend on the outer protocol. I hope that some one can create documentation on their use in SIOP that proves me (and Tony) wrong, but i haven’t been convinced. It seems to be an inherent defect in the VP data format. They are only valid within the protocol and not on their own.
(aside comment - we could fix that in SIOP by just adding an element to the VP)
Tobias posted a VP exchange & I responded to that.
Tom Jones 1 hour ago
I am not intimately familiar with the format, but since I don't see an aud or nonce, I don't understand how you propose to prevent replays.
Orie Steele (Transmute) 9 minutes ago
domain and challenge in the W3C VC Data Model address this exact concern (edited)
Orie Steele (Transmute) 8 minutes ago
https://www.w3.org/TR/vc-data-model/#example-2-a-simple-example-of-a-verifiable-presentation
w3.orgVerifiable Credentials Data Model 1.0Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
Tom Jones < 1 minute ago
@Orie Steele (Transmute) @Kristina (MSFT/MyData/OIDF) That might be a problem with SIOP. I think we need to get together on this.
Comments (13)
-
reporter -
+1 to what Orie said. That’s exactly the correspondence, in VPs.
aud
→ VP’sdomain
propertynonce
→ VP’schallenge
property. -
reporter Well that sounds to me like the VP cannot ever be embedded in anything then. It only ever fits its own protocol.
-
- changed status to open
-
- changed component to Verifiable Presentation
-
VP can be embedded in any transport protocol, we just need to specify in the transport protocol which property there maps to which VP’s property. There should be a text about it in OIDC4 VP draft. @Torsten Lodderstedt
-
I think Dmitri is completely right. The VPs shall be protected from replay by binding them to the transaction (nonce) and the intended audience (client_id).
For LD Proofs, this means
- “domain” set to “client_id” of the requesting client
- “challenge” set to “nonce” of the request
For JWT-based VPs, it’s a 101 mapping.
-
Proposal:
To prevent replay attacks, verifiable presentation cointainer objects MUST use
client_id
and if providednonce
from the Authentication Request. The values are passed through unmodified from the Authentication Request to the verifiable presentations. Note, these values MAY be represented in different claims according to the selected proof format denated by theformat
claim in the verifiable presentation container.Here is a non-normative example for
format='jwt_vp'
(only relevant part):{ "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21", "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5", "aud": "s6BhdRkqt3", "nonce": "343s$FSFDa-", "nbf": 1541493724, "iat": 1541493724, "exp": 1573029723, "vp": { "@context": [ "<https://www.w3.org/2018/credentials/v1",> "<https://www.w3.org/2018/credentials/examples/v1"> ], "type": ["VerifiablePresentation"], "verifiableCredential": [""] } }
In the example above,
nonce
is included as thenonce
andclient_id
as theaud
value in the proof of the verifiable presentation.Here is a non-normative example for
format='ldp_vp'
(only relevant part):{ "@context": [ ... ], "type": "VerifiablePresentation", "verifiableCredential": [ ... ], "proof": { "type": "RsaSignature2018", "created": "2018-09-14T21:19:10Z", "proofPurpose": "authentication", "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1", "challenge": "n-0S6_WzA2Mj", "domain": "s6BhdRkqt3", "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5 XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh 4vGHSrQyHUGlcTwLtjPAnKb78" } }
In the example above,
nonce
is included as thechallenge
andclient_id
as thedomain
value in the proof of the verifiable presentation. -
reporter where is the normative statement that backs up your assertion?
-
The language above is a proposal for a normative statement that I’d add to the OIDC Verifiable Presentation draft + non-normative examples.
-
corresponding PR #21
-
@tom propose to close this as PR #21 has been merged.
-
- changed status to resolved
Closing during the 15-Jun-21 call, since PR #21 addressed this issue.
- Log in to comment