Verifiable Credentials Working Group Telco — Minutes

Date: 2022-09-07

See also the Agenda and the IRC Log

Attendees

Present: Kristina Yasuda, Brent Zundel, Ivan Herman, Chris Abernethy, Sebastian Elfors, Will Abramson, Dave Longley, Gabe Cohen, Justin Richer, Shigeya Suzuki, Manu Sporny, Michael Jones, Phil Archer, Mahmoud Alkhraishi, David Chadwick, Joe Andrieu, Shawn Butterfield, Snorre Lothar von Gohren Edwin, Orie Steele, Ted Thibodeau Jr.

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Michael Jones, Dave Longley

Content:


Manu Sporny: We could go over registry proposals.

Kristina Yasuda: The TPAC agenda is set.
… We’re using the regular Zoom link.
… People who have been asked to present should have received a deck to add slides to from Brent and me.

Brent Zundel: Please get your slides in as soon as possible.

Kristina Yasuda: please put the attendance here: https://docs.google.com/spreadsheets/d/1Du-3G4d08OWxW1fNtn_8BLNsAIT4GETvk7F7v_Mu_dA/edit#gid=179611341.

Brent Zundel: We have dinner reservations on Thursday evening.

Manu Sporny: woo, thank you Avast! Very generous to support the dinner :).

Brent Zundel: The restaurant is Joe Fortes.

Gabe Cohen: https://www.joefortes.ca/.

Kristina Yasuda: The convention is to cancel the WG meeting the week after TPAC.
… But RWoT is two weeks hence.
… So could we instead cancel the call two weeks after TPAC?
… There was agreement to do that.

1. PRs.

Kristina Yasuda: https://github.com/w3c/vc-data-model/pulls.

1.1. Making explicit the binding of the holder to a VC (pr vc-data-model#795)

See github pull request vc-data-model#795.

Manu Sporny: 795 is going to remain open until we discuss the holder stuff at TPAC.

1.2. modify editors list (pr vc-data-model#922)

See github pull request vc-data-model#922.

Manu Sporny: 922 is a suggestion that we update the editors’ list.
… I have objected to the change because it removes people from the bibliography.
… The editors list is really long now.
… I suggest that we update respec to list the primary editors then et. al.

Brent Zundel: I have no wish to deprive people of credit.
… But our editors’ list is ginormous. I propose move people out of the list who are not actively editing now.
… Let’s move them into a Former Editors section. Respec can do that.

1.3. Remove proof from v2 context (pr vc-data-model#924)

See github pull request vc-data-model#924.

Brent Zundel: 924 Orie has suggested removing proof from the VC context.
… I suggest waiting until after TPAC.

1.4. Vocabulary synced with v2 context (pr vc-data-model#927)

See github pull request vc-data-model#927.

Brent Zundel: Finally, the last one remaining open is 927. Ivan updated the vocabulary to match the VC context.
… We need one more update of the PR by the editors.

Ivan Herman: For 927, I have a question there that it would be good to have an answer to.
… I don’t know whether the JSON schema should be deprecated.

Manu Sporny: It has been deprecated.

Ivan Herman: After that, then we can merge.

1.5. Adjusting some language for clarity and consistency (pr vc-data-integrity#35)

See github pull request vc-data-integrity#35.

Manu Sporny: On Data Integrity, we are waiting for changes from Mike Prorock.

1.6. Remove suites namespace from Multikey context url. (pr vc-data-integrity#49)

See github pull request vc-data-integrity#49.

Manu Sporny: Ginesh has a change to a potential direction we might go in after TPAC discussions.

Michael Jones: I’m not able to do that right now but do plan on paging that in before TPAC.

Kristina Yasuda: For JWT-VC there are two PRs open.
… These are the same PRs that Orie discussed last week.

2. Issues labeled as ‘to be discussed’.

Kristina Yasuda: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc.

2.1. Define policies for VC Extension Registry (issue vc-data-model#909)

See github issue vc-data-model#909.

Kristina Yasuda: Manu, can you update us on this?

Manu Sporny: We theoretically have a registry for VC Extensions registries.
… I took an action to propose answers to these questions.
… I modelled it on the DID registries.
… These are the initial rules. We will have two years to refine them.
… This is a starting point.

Manu Sporny: proposals are here: https://github.com/w3c/vc-data-model/issues/909#issuecomment-1236394966.

Manu Sporny: People should read these proposals before TPAC.
… The other thing to note about the proposals is that we’re trying to make the registries have a specific format.
… Registrants will fill out a form.
… Then we can create tooling.

Michael Jones: I have a question for Ivan and really for the W3C staff, I know that there have been action items for the W3C in the last few years to create registries and policies so WGs don’t have to manage their own registry entries, where are we on that, Ivan?

Ivan Herman: I think the only thing that does exist now, is a formal way of declaring something as a registry.
… I think the only thing that exists now is a formal way of declaring something as being a registry.
… The only thing that that entails today is that the policy of maintaining the registry has to be approved by the AC.

Manu Sporny: The first proposal provides this text: The VC Extensions Registry will be operated as a W3C Registry by the VCWG as defined in the W3C Process here: https://www.w3.org/2021/Process-20211102/#registries.

Michael Jones: First, confirming, there is no plan to develop the equivalent of IANA so there’s a neutral party for registries in W3C, right?

Ivan Herman: What you say is correct.

Justin Richer: +1 on using IANA and established processes.

Michael Jones: I’ll put this in the issue. The alternative is to use IANA, which is a neutral 3rd party which won’t do what the DID WG did and make value judgments about whether things are good or bad entries. An example of that is the WebAuthn WG established a tool to create registries for IANA.
… I want us to at least consider that since W3C has no registry mechanism of its own. My personal experience watching the DID WG try to maintain its own registries … I was horrified and we shouldn’t do that

Ivan Herman: I’m not aware of any attempt at the W3C to establish the equivalent of IANA, though I am not familiar with the details of what IANA means in this respect.

Michael Jones: I wanted to put some of that out for those on the call now and agree we should discuss at TPAC, I’m on the hook for doing a registries presentation already.

Shigeya Suzuki: +1 to mike.

Kristina Yasuda: The purpose of raising this was for people to be aware of the registry issue.

Phil Archer: When I add things to an IANA registry it basically just has to be in a stable document.
… It goes to a designated expert, often Mark Nottingham.
… It’s the process that ensures neutrality.

Manu Sporny: +1 to “the neutrality comes from the process”.

2.2. issuanceDate/expirationDate and validFrom/validUntil (issue vc-data-model#913)

See github issue vc-data-model#913.

Kristina Yasuda: validFrom … validUntil.

Michael Jones: There’s a discussion, which I understand predates my involvement about possibly deprecating issuedDate and replacing it with validFrom and possibly deprecating expirationDate and replacing it with validUntil.

See github pull request vc-data-model#927.

Michael Jones: There was a useful discussion on the issue about what use cases might exist for having a validFrom period that differs from the issuanceDate. In particular, the example was given of a future-dated coupon which starts being valid on maybe July 4th 2023 and is valid through July 4th 2024 but you could hand that out to people now. I understand that and it’s a reasonable thing to do.
… That said, I believe the predominant case is that stuff is valid when issued and that’s what we should optimize for. That’s the same that we did in JWTs.
… There’s typically always an issued at (iat) time and an expiration time. If you want it to be valid from a different time from the issuance then you add the optional claim to indicate that.
… If it ever valuable to have a valid until that is different from the expiration date – and no one has given a use case so I’d be happy to just leave expirationDate alone and not have that.

Manu Sporny: There are a couple of things wrapped up in this issue.
… Manu said that people thought that people couldn’t include a time.
… We put in a deprecation warning because of that.
… We said that we were going to rename it.
… The first issue is that we named these properties in a misleading way.
… The second issue is that there’s a strict difference between the validity period of a credential and when it was signed.

Orie Steele: +1 manu, we also want to separate “the data model” from “securing it”.

Manu Sporny: As Mike said, when a coupon was signed and when it becomes valid are different.
… Retailers need to distribute digital coupons before they come into play.
… This is a real retail use case.
… The other side of that is that the validity period of a credential can be different from the validity period of a digital signature.
… A passport or driver’s license has a validity period independent of the signature validity period.
… A driver’s license that has expired doesn’t change a person’s birthday.
… We shouldn’t conflate them.

David Chadwick: A UK driver’s license expires when you become 65.
… Whereas the signature will expire well before that.
… Some of these pertain to the claims and some pertain to the cryptography.

Orie Steele: The validity period for a credential is different from the validity period for crypto.

Orie Steele: +1 DavidC, all cryptography has a shelf life that does not match always match the life of the claims the issuer is making.

Michael Jones: I was going to advertise Orie’s presentation at TPAC, which is, I believe he’s going to explicitly talk about clear semantic distinctions between properties of the Verifiable Credential and properties of the signatures used to secure them.

Orie Steele: I will attempt to cover this in my TPAC talk, I make not promises for success.

Michael Jones: I think some of this discussion would be well informed by a clear separation of those two concerns. There may be relationships between the two sets of dates but we should be clear about them.

Manu Sporny: we have been clear in the textual description, some developers don’t have time to read specs. :).

Michael Jones: Also responding to a comment Manu made a few minutes ago – the fact that it’s called issuanceDate and that you couldn’t put a time, is a documentation time. We should just be clear in the definition what it means. That’s not sufficient for making a breaking change, we should just fix the documentation, not change the property name.

Ted Thibodeau Jr.: It’s not a documentation error. The documentation was quite clear.
… The humans will still make the mistakes.

Manu Sporny: +1 to what TallTed is saying, we have to take the human element into consideration here.

Ted Thibodeau Jr.: Documentation does not fix issues like this.

Michael Jones: If implementers aren’t using our specifications, there’s not much point in us writing them.

Ted Thibodeau Jr.: Humans are fallible. They do not recall everything they read.
… We are writing the spec for humans to implement them.
… What we can fix, we should fix.

Justin Richer: Naming things is hard. Really hard.

Ted Thibodeau Jr.: We can fix things by using better names.

Kristina Yasuda: It seems like people care a lot about this.
… Please read the specs and suggest ways to make things clearer.

2.3. Define “prover” in addition to “holder”. (issue vc-data-model#902)

See github issue vc-data-model#902.

Orie Steele: We created the spec to have a term for presenting.
… It’s important to acknowledge the different roles for being a holder.
… It’s dangerous to have terms in VPs that are undirected. The holder label is undirected.
… It would be better for the entity making the presentation to be able to assert that “I am presenting or I am receiving”.
… We want directed intentionality in the data model.
… That’s why we need additional terms related to the holder role.

Kristina Yasuda: There’s a suggestion to use presenter.

Joe Andrieu: It makes sense to add both recipient and presenter for what we’re currently calling holder.

Manu Sporny: +1 to defining the roles in a directional manner.

Joe Andrieu: That’s an iteration on this conversation.

Kristina Yasuda: There is a consensus to have two terms.

Manu Sporny: Are we talking about getting rid of holder or saying that holders have two things that they can do.

Orie Steele: +1 to the latter formulation manu.

Manu Sporny: I wondering if issuers can receive and present as well.
… It’s a question we have to answer for each of the current roles we have.

Joe Andrieu: We would benefit from keeping holder and clarifying it.

Brent Zundel: +1 Joe.

Joe Andrieu: The issuer/holder/verifier is a very powerful group of terms.
… We should elaborate on them.

Joe Andrieu: +1 to chat at TPAC.

Kristina Yasuda: This is the first time we’re talking about this issue.
… Let’s give people time to think about it.

2.4. ACDC (Authentic Chained Data Containers) in VC DM 2.0 (issue vc-data-model#895)

See github issue vc-data-model#895.

Kristina Yasuda: Authentic Chained Data Containers (ACDC).
… Sam Smith will give us a presentation on ACDC on the first day of our TPAC meetings.
… I’d like to move to issues without the tag Discuss.

3. Other issues.

Kristina Yasuda: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc.

3.1. Fix the vc-data-model namespace with https://www.w3.org/ns/vc/v2 (issue vc-data-model#758)

See github issue vc-data-model#758.

Kristina Yasuda: Issue: Fix the data model namespace.

Orie Steele: It seems that someone has fixed some parts of this recently.
… There are term definitions that we’re working to create.
… We want to be able to read the definitions for those terms.
… You can read them in the registry where they’re specified.
… You want to be able to click the link for a term definition and read the definition.
… We should make sure that our term links are clickable.

Ivan Herman: This is exactly what the vocabulary work does.
… Now it’s such that if you take the URL of a term, it will go there.
… Temporarily, the links go to the V1 vocabulary.
… Eventually we will point to the official V2 vocabulary.

Orie Steele: I suggest closing after PR is merged.

Ivan Herman: I think this issue can be closed.

Manu Sporny: We should wait until PR is merged.

Kristina Yasuda: We will close it after the PR is merged.

3.2. notTransferable property not defined in @context (issue vc-data-model#731)

See github issue vc-data-model#731.

Kristina Yasuda: There’s a lot of comments in the issue.

David Chadwick: I don’t know where this issue stands.

Manu Sporny: There’s a suggestion that we add a non-transferrable property to the context.
… The part of the spec that talked about non-transferrable was non-normative.
… I don’t know if there are new use cases or new data for this property.

Orie Steele: there are use cases for non transferable… see NFTs.

Manu Sporny: You can always add this by putting it in an extension context and using it.
… Do we want to define this in the base data model or is it something people should define if they need it.

Joe Andrieu: I think this is an unfortunate property and I don’t think we should support it.
… VCs are statements. It makes no sense to transfer statements.

Ivan Herman: +1 to JoeAndrieu.

Joe Andrieu: What does it mean to transfer the statement “The sky is blue”.

David Chadwick: Some of the plastic cards in my wallet are not transferrable.
… That’s why the property was invented.

Brent Zundel: what if the statement is, “the holder of this credential is my friend.” ?

Kristina Yasuda: It was a bit ambitious to try to tackle this in 5 minutes.
… Please review.
… See you all virtually or in person at TPAC!.