vc-data-model
vc-data-model copied to clipboard
w3c
Presentations SHOULD expire
In general guidance on presentations is poor.
My understanding of them is that they are meant to be extremely short lived, and bound to a challenge provided by a verifier.
Therefore, they should expire in ... minutes?
If they don't expire quickly, the value of the subject / holder arguments seems less useful.
The core data model should define requirements for presentations better, and the "securing formats" should enforce them.
I don't think VCDM should do much, if anything at all, with expiration. Here are some reasons
First, the meaning of expiration is what a verifier chooses to do with its value. Consider a (paper) passport: for many situations, it's ok to present a passport that hasn't expired for more than 5 years. In other situations, it may not have expired. For requesting a visa to China it must be valid 6 more months after the date at which the requester states (s)he will enter the country.
Second, the contents of the field means whatever the issuing party decides it to mean (it is a business/information-level issue that shouldn't be answered in a tech spec).
Third, its hard to decide what it should be as there are use-cases for
- very short lived VCs (e.g. a VC that attests to the result of a remote integrity test of a wallet);
- very long lived VCs (e.g. a claim that one is 18+ years old).
Similar arguments hold for VPs. Apart from the short lived example you give, long lived ones can be very beneficial (assuming a privacy friendly revocation mechanism is in place such as the one proposed by Christiaan van Bruggen, which allows to privacy-friendly check for revocation of credentials in a presentation an arbitrary time after the presentation was created). The case is that a person can request a parking permit, an attestation of citizenship of a specific city, etc., that are all valid, not until such a cred expires, but until at least one of the VCs that was used to decide to issue the cred was revoked. This mechanism allows issuers of such creds to test every day/week/month/year whether or not the decision to issue the cred is still valid, enabling them to manage their resources (e.g. parking spaces) in an agile fashion, while unburdening people in that they no longer need to do all these re-applications.
[editor's call] diffence in approach - vc-jwt has exp claim which is recommended to be used, while data integrity does not have a claim for a proof expiration date.
suggested action would be to give a guidance in a core data model around expiration of VPs, and leave concrete mechanisms to data integrity and vc-jwt specs.
(discussion would benefit from a use-case that shows a need to expire a VP)
@Sakurann I have already raised an issue on data integrity that it should add an expiry time to the proof. see https://github.com/w3c/vc-data-integrity/issues/78
Personally, I don't think the guidance should go beyond
they are meant to be extremely short lived, and bound to a challenge provided by a verifier
Details are up to verifier policy and transport protocol.
Also its up to the holder as well, since the holder signs the VP and can decide what the duration should be.
The issue was discussed in a meeting on 2023-04-11
- no resolutions were taken
View the transcript
1.3. Presentations SHOULD expire (issue vc-data-model#937)
See github issue vc-data-model#937.
Kristina Yasuda: "Presentations SHOULD expire" opened by orie.
… reads bits of the issue.
Orie Steele: notes that the only normative requirements for a VP are that it must have a context and a type.
… current understanding (of speaker) is that they are either 1) syntactic sugar, or 2) unsecured semantic wrapper - not sure if intended to be secure, and if intended to be secure then there should be an expiration.
… basically don't stumble on a presentation 1yr after creation and then trust it.
… feels like VPs have not had sufficient loving and polish.
Kristina Yasuda: asks if anyone is willing to follow up on the issue to get it ready for PR.
Orie Steele: I don't see the value of Verifiable Presentations, they seem harmful and unrestricted..
Orie Steele: notes that he is not sure how to handle anything related to VPs since seldom discussed.
Manu Sporny: VPs are used as noted by Orie - don't feel like there is clear guidance to be made by the WG at this time - perhaps we say nothing.
… would be nice to talk about this, discuss ephemeral nature, etc - but we likely have more important fish to fry.
Orie Steele: IMO it is leading to very bad interop issues, nobody is implementing meaningful interoperability from the spec, since the spec only says they are JSON-LD..
Manu Sporny: happy to let it expire for now unless someone feels strongly about it.
Kerri Lemoie: agrees with orie and manu - need some work to even understand what VPs are.
… understands need for a container - have seen external containers defined bc of a lack of desire to use VPs because of lack of understanding.
Joe Andrieu: asks if we have multiple implementations of an expiration in VPs?.
… i think they are ephemeral and should be short lived.
… thinks we can't add an expiry without impls.
Orie Steele: notes that he has never seen an expiration and that there is a lot of copy paste, and addition of terms at will, or use of a DI proof, which just adds a proof and no expiry.
… concerned that way things are written implies that we intend for VPs not to expire.
Manu Sporny: wants to know if this is causing interop issues?.
… if not, let's move onto things causing interop.
Kristina Yasuda: volunteers to try and get some thoughts on this and perhaps / hopefully lead to a resolve - think there is a need to address security/expiry/etc.
Orie Steele: There are no interop issues with VPs since they have no "requirements"... You can't have meaningful interop other than implementing conformance to JSON-LD 1.1, with VPs....
The issue was discussed in a meeting on 2023-04-11
- no resolutions were taken
View the transcript
1.3. Presentations SHOULD expire (issue vc-data-model#937)
See github issue vc-data-model#937.
Kristina Yasuda: "Presentations SHOULD expire" opened by orie.
… reads bits of the issue.
Orie Steele: notes that the only normative requirements for a VP are that it must have a context and a type.
… current understanding (of speaker) is that they are either 1) syntactic sugar, or 2) unsecured semantic wrapper - not sure if intended to be secure, and if intended to be secure then there should be an expiration.
… basically don't stumble on a presentation 1yr after creation and then trust it.
… feels like VPs have not had sufficient loving and polish.
Kristina Yasuda: asks if anyone is willing to follow up on the issue to get it ready for PR.
Orie Steele: I don't see the value of Verifiable Presentations, they seem harmful and unrestricted..
Orie Steele: notes that he is not sure how to handle anything related to VPs since seldom discussed.
Manu Sporny: VPs are used as noted by Orie - don't feel like there is clear guidance to be made by the WG at this time - perhaps we say nothing.
… would be nice to talk about this, discuss ephemeral nature, etc - but we likely have more important fish to fry.
Orie Steele: IMO it is leading to very bad interop issues, nobody is implementing meaningful interoperability from the spec, since the spec only says they are JSON-LD..
Manu Sporny: happy to let it expire for now unless someone feels strongly about it.
Kerri Lemoie: agrees with orie and manu - need some work to even understand what VPs are.
… understands need for a container - have seen external containers defined bc of a lack of desire to use VPs because of lack of understanding.
Joe Andrieu: asks if we have multiple implementations of an expiration in VPs?.
… i think they are ephemeral and should be short lived.
… thinks we can't add an expiry without impls.
Orie Steele: notes that he has never seen an expiration and that there is a lot of copy paste, and addition of terms at will, or use of a DI proof, which just adds a proof and no expiry.
… concerned that way things are written implies that we intend for VPs not to expire.
Manu Sporny: wants to know if this is causing interop issues?.
… if not, let's move onto things causing interop.
Kristina Yasuda: volunteers to try and get some thoughts on this and perhaps / hopefully lead to a resolve - think there is a need to address security/expiry/etc.
Orie Steele: There are no interop issues with VPs since they have no "requirements"... You can't have meaningful interop other than implementing conformance to JSON-LD 1.1, with VPs....