search

w3c / vc-data-model

W3C Verifiable Credentials v2.0 Specification
https://w3c.github.io/vc-data-model/
Other
300 stars 109 forks source link

VPs and timestamps? #877

Closed vdods closed 2 years ago

vdods commented 2 years ago

There's currently no specification for timestamps in VPs, meaning that presenters can't mitigate the risk of replay attack by limiting their presentation validity to a short window during which the verifier verifies the VP.

What's the intended workflow regarding timestamp verification here? For example, is validFrom and validUntil only for the credential, and the presentation doesn't have any timestamp? Or are presentations meant to carry timestamps also? It looks like some signatures have a "created" field, but AFAIK (and I'm not an expert on signature formats) that's not required, so (1) retrieving the signature creation timestamp would be ad-hoc at best, and unreliable at worst, and (2) it doesn't give a way for the signer to limit validity duration to mitigate replay attack risk.

Relevant, useful convo: https://github.com/spruceid/ssi/issues/387

David-Chadwick commented 2 years ago

The fact that the VCDM does not define timestamps for VPs does not mean that they cannot have them, as VPs are as infinitely extensible as VCs. Our implementation has taken the pragmatic approach of using the same start and end time properties for VPs as for VCs. It might not be standardised yet, but it has a fair chance of being so I would suggest.

msporny commented 2 years ago

There's currently no specification for timestamps in VPs, meaning that presenters can't mitigate the risk of replay attack by limiting their presentation validity to a short window during which the verifier verifies the VP.

There are two mechanisms that can be used to mitigate replay attacks at the digital signature layer. For Data Integrity (was: Linked Data Signatures), all proofs are required to contain a created timestamp:

https://w3c-ccg.github.io/data-integrity-spec/#signatures

How much time is allowed to pass before a signature is seen as invalid by a verifier is up to the verifier to determine. Our implementations tend to use 5 minutes (to account for clock skew between systems).

The other mechanisms that the Data Integrity spec uses to prevent replays are the domain and nonce properties:

https://w3c-ccg.github.io/data-integrity-spec/#signatures

The presentation request protocols typically request that presentations contain at least a domain (set by verifier) and challenge (set by verifier) values:

https://w3c-ccg.github.io/vp-request-spec/#did-authentication-request

I expect most/all of these things to be buttoned down when the new VC2WG starts up (in a few months).

selfissued commented 2 years ago

Given that JWTs and Data Integrity have such mechanisms, I don't think we need to do this in VPs themselves.

iherman commented 2 years ago

The issue was discussed in a meeting on 2022-08-24

View the transcript #### 3.2. VPs and timestamps? (issue vc-data-model#877) _See github issue [vc-data-model#877](https://github.com/w3c/vc-data-model/issues/877)._ **Kristina Yasuda:** So the next issue ... the ask was, could we have a timestamp in VP to prevent replay attacks? … I think Manu and David Chadwick have been talking about there already being something in VP there. **Manu Sporny:** I think we already cover this concept around timestamp / of when a VP is created. JWTs have multiple ways of expressing a datetime and DI also has that as well. … I don't remember if they were asking about validUntil/validFrom or something like that on the presentation itself. I don't think Lee and David were asking for that. I think timestamp verification has to do with protection around the VP and both JWT and DI have protections for that. I don't think there's anything to do here. **Kristina Yasuda:** I think I agree. Any objections to mark this pending closed based on Manu's explanation? > *Michael Jones:* [https://github.com/w3c/vc-data-model/issues/877#issuecomment-1225895943](https://github.com/w3c/vc-data-model/issues/877#issuecomment-1225895943). **Manu Sporny:** One more item -- just so it gets in the record. We also have the concept of challenges and nonce in the variety of the protocols. Lee said -- "what about things to mitigate replay attacks?". Well, we have nonces and challenges and creation dates for the signatures in every security mechanism we're contemplating. **Kristina Yasuda:** You also put that in your comment, right? … I see Mike is agreeing with you. … Let's move onto the next issue. > *Kristina Yasuda:* substopic: [https://github.com/w3c/vc-data-model/issues/860](https://github.com/w3c/vc-data-model/issues/860). **Kristina Yasuda:** I think you're asking how we include claims attested to by the user? **Joe Andrieu:** That's right. One of the examples in the VC use cases... Citizenship by Parentage has the citizen / holder making statements about how different VCs relate together. … It's his birth certificate with his Mom's passport, etc. He needs to be able to make a statement that these VCs are related. One option is to create a VC where he does that. It seems it could be appropriate for the holder to make some claims like that. … I know there's some background that JSON-LD has an open world model and you can just do whatever you want, but it wouldn't be interoperable. **Manu Sporny:** I totally agree with the use case being a valid one -- I'm wondering about the extra complexity. … One of the options is to define self-attested credentials. Just create another VC in the presentation. … Option two is to create another way to express this in the VP. > *Kristina Yasuda:* +1 to using Cs. > *Kristina Yasuda:* *VCs. **Manu Sporny:** I'm worried about adding to the complexity in the VP. I'd like to keep that as simple as we can. … If we can model it and it makes sense to use a VC then let's just do that and maybe talk about it in the implementation guide vs. add complexity. **Dave Longley:** Yes, going to agree with Manu. We have primitives around interop here, VC can make any claims we want to -- seems we can re-use that primitive here and make self-attested claims. When we already have the primitive that does the job, we should continue to use it unless there is a strong reason to do something new. **Michael Jones:** Given that's Joe's on the call... I tried to read the issue last night but I was confused. It sounded like you wanted a schema for these claims. There wasn't a clear ask for these particular properties or attributes. … I think I get it now, but this issue at least needs to be clarified because I couldn't tell what it was about last night. **Joe Andrieu:** I appreciate the feedback. **Kristina Yasuda:** Based on the comments we've heard using VCs, is that acceptable or do you want to continue the conversation? **Joe Andrieu:** It's a good question. No one has voiced support for the idea -- maybe there isn't support in the community but also maybe it's just a new idea. … If we're going to allow this behavior I think we should standardize it and if we're not, that's a shift away from an open world. **Kristina Yasuda:** I think there's interest, I agree with Manu's comment to give people to think about this and come back to it. … Do you mind renaming the issue so it's clear it's about the mechanism itself? **Joe Andrieu:** Yes, I'll edit it right now. **Kristina Yasuda:** One more issue for today...
brentzundel commented 2 years ago

No objections after marked pending close, closing