Verifiable Credentials Working Group Telco — Minutes

Date: 2023-04-26

Attendees

Present: Phillip Long, Sten Reijers, Shigeya Suzuki, Brent Zundel, Kristina Yasuda, David Chadwick, Gabe Cohen, Dave Longley, Manu Sporny, kevingriffin, Chris Abernethy, David Waite, David Lehn, Joe Andrieu, Ted Thibodeau Jr.

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Chris Abernethy

Kristina Yasuda: be on the lookout for new zoom url email.
… agenda is intros, proposal, then prs.

1. proposals.

Manu Sporny: we need to generate proposals for test suites, not necessarily now, but thoughts on when right time?
… do chairs have expectations regarding time frame for that?

Orie Steele: I’d love a repo for managing vc-jwt test suite.

Manu Sporny: Same for the data integrity ones…

Kristina Yasuda: perhaps next weeks vcwg or a special topic call in a few weeks?

Brent Zundel: agree, either way works.

Manu Sporny: I’m travelling for the next two weeks.

Kristina Yasuda: may 9th special topic call focus on test suites.

Manu Sporny: to clarify, I’m traveling and will be available starting the 15th.

Kristina Yasuda: 16th of may meeting for test suites.

2. work item status updates.

Manu Sporny: 18 open prs on vc-data-model, many stuck while we determine what to do about reserved properties table (#1097).
… we had special topic call regarding some of these PRs yesterday, please review call notes.

2.1. Remove section on Disputes; no one has implemented it. (pr vc-data-model#1087)

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

Manu Sporny: initial PR was to remove section entirely, after pushback new suggestion is to leave title with link to specification.

Orie Steele: +1 Brent.

Brent Zundel: we can remove as long as changelog reflects.

Ted Thibodeau Jr.: concerned that we are removing for lack of implementation, but there should have been independent implementations.

Manu Sporny: that was all non-normative.
… will change PR to remove section and put that in the changelog - will merge if no objections.

Chris Abernethy: (no objections were voiced).

2.2. Add first pass at reserved properties table (pr vc-data-model#1097)

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

Manu Sporny: some new PRs were added recently, suggest we deep dive on #1097.

Brent Zundel: agree we should, 5-10 minutes (ish), as there are other PRs and work items to look at - this would be time well spent.

Manu Sporny: #1100 is potentially important for the group, but I have not had time to review yet.
… bg regarding having merged reserved properties table.
… #1097 is language from Mike Prorock regarding what this table should contain.
… There are several ways to decide what this table means.
… 1. we need a mechanism for extension point definitions.
… what happens to existing sections in specs, e.g., ‘Evidence’, that is also now in this table as a reserved property?
… one proposal is that anything in the table is removed from the spec UNTIL it is demonstrated to the WG that there are two independent.
… implementations for a property at which time it would go back in the spec.
… 3. reserving json terms here, not vocab, what is happening here?
… one suggestion is that we are putting a term in the table and also urls for the vocab terms in here.
… e.g., evidence has an entry in the vocab (long url for credential namespace hashed evidence). we would define both here to specify it is reserved.
… it would show up in the vocab as reserved as well.

Orie Steele: I’m in favor of getting this into the place where it can be merged. it is doing too much now.
… reserving new terms, addressing previous terms not having implementations.
… we should focus on the latter “terms of use”, “refresh service”, “evidence”.
… all we need in the table is the json member and the URL, and only for terms shipped in v1 or v1.1 in the PR.
… this should get rid of objections, which are primarily about new terms being added, “confirmation method”, “presentations schema”, “render Method”.
… splitting gets easier to get consensus.

Brent Zundel: +1 to breaking this up into different PRs.

David Chadwick: regarding conformance test, the three already in 1.1 already have conformance tests since the are MUST fields.
… our implementation implemented both [sic] of them.
… only two tests are needed, one is that you send to a SUT, here is a cred with a type, if you accept that is proven that it works.
… second test is to send terms or evidence without a type, and implementation should reject it.
… these should be sufficient to say we have multiple independent implementations to prove these work.
… then people can test types from registry.

Manu Sporny: going with Orie’s suggestion, the concrete change request is “lets just deal with the things in the spec right now”, and then define URLs for that.
… I don’t know if I agree, because something has to have the normative definition for the vocab as it stands today.
… we might still need description in the URL because we are going to remove from the core spec and that is supposed to be normative.
… DavidC to your point, v1.1 and 1.0 did absolutely test that, and we are raising the bar - we need to see real usage and deployment of.
… this extension point. If we don’t have that it doesn’t belong in the core specification.

Kristina Yasuda: +1 manu.

David Chadwick: if you are going down to the type level, you are going to cut the group up into small groups, each of which may have implemented.
… one of the types - that seems unfair, as the rest of the datamodel is for everyone.
… it is going to be much harder to get multiple implementations of any particular type.

Brent Zundel: it was made clear when drafting the charter that the expectation was any normative statements would have an implementation.
… extensions from round 1 are moving to a table of reserved properties, until and unless there are normatively defined statements for the types.
… it will be problematic if there are terms in the data model that don’t point to a normatively defined type.

Dave Longley: +1 to ensure we enable innovation somehow (objectors should not be able to block it).

Brent Zundel: the bar needs to be raised for v2.

Manu Sporny: +1 to brent, if we don’t do something about this we will see formal objections when we try to exit to CR.
… chairs should as if anyone would formally object if we went down this path (primarily a question for DavidC).
… I will update the PR to reflect what I heard in the call today, and my expectation is that we need to merge or figure out which set of formal objections we are going to be happy with.

Orie Steele: even keeping the table of reserved terms is suspect, if you can’t use them without types, and we have no normative types… but it seems a good path forward, from where we are today.

David Chadwick: brent said he wants the types to be formally standardized, and this worries me. That will be very difficult.
… two orgs might agree and implement, and that would meet the two implementation bar.
… going back to X509, that introduce the first extension point.

Orie Steele: We have types for credentialSchema and credentialStatus, and proof, we have reserved predicates for the ones we don’t have as work items.

David Chadwick: standardizing the way to do extensions is the way to go, so people can experiment and some results will be come standards.

Manu Sporny: we are not saying you have to formally standardize things at these extension points.
… only that something has to exist on the web at a URL and there have to be two interoperable implementations.
… That is the bar for anything we do in the WG.

Phillip Long: manu just cleared up my concern.
… I was worried we were eliminating opportunities to experiment and try out, as for termsOfUse for example.
… as long as the bar is set as Manu described, I’m ok with that.

Manu Sporny: yes, Phil, that’s the bar that’s suggested.

Brent Zundel: responding to DavidC, from my point of view we have a standardized method of extending the datamodel - JSON-LD.
… we are allowing for certain named properties to be reserved so that the experimentation can be guided somewhat, but there is nothing.
… blocking people from experimenting as they want to.
… I could come to accept Manu’s bar, but fear that it is too low - we really need high standards for our standard.
… we need to be as interoperable as possible while also encouraging experimentation and growth.

Phillip Long: I don’t think a bar that supports experiments around reserved properties is too low. It’s actually crucial to the evolution of the standard.

Kristina Yasuda: direction we are going is splitting PR in two as discussed; still need to agree on the bar that is needed to “get back in” to the core DM.

Chris Abernethy: short discussion of fpwd for vc-jwt.

Manu Sporny: question - we said Orie was going to make his changes and wg was going to review… did anyone review?

Orie Steele: we didn’t make any changes, I sent email about this to the list. We were intending to make changes and met as editors and decided we didn’t need to make any changes.

2.3. Added the Multikey class (pr vc-data-integrity#93)

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

Manu Sporny: Next up is data integrity, couple of stuck PRs here.
… orie, I think you wanted group to be aware of multikey class added to vocab (vc-data-integrity #93).

Orie Steele: my question was, for context, there are references from new vc-di-bbs work item to this, so I’m trying to understand from a normative standpoint, can I reference.
… multikey from vc-di-bbs?
… wasn’t sure if group has decided to create normative key format.

Kristina Yasuda: would encourage the WG to review 1101 and 1100 before the next call.

Manu Sporny: I think the reference is fine, but agree we need to make a decision as a WG as to where the reference goes.
… multikey is the key format used in did:key, which has lots of implementations.

Orie Steele: Here is the todo, in vc-di-bbs that points to Multikey: https://w3c.github.io/vc-di-bbs/#multikey.

Manu Sporny: eddsa, ecdsa, maybe now bbs.
… we have been creating normative version of this in the cryptosuites themselves, e.g., here are the key formats this suite supports…
… I think the proposal right now is for each suite to keep defining sub-parts of multikey spec, and instead of spreading them around like that why don’t we put them into the data integrity specification (normatively) so that all suites can point to one place?

Orie Steele: +1 to everything Manu is saying, it feels like we have made improvements for key formats that align with how we now have DataIntegrityProof once, and we don’t define a new type for each new suite, multikey seems in that spirit.

Manu Sporny: Can a cryptosuite decide to define its own multikey identifier (probably have to do this in bbs).

Dave Longley: +1 to just put Multikey definition in the Data Integrity Proof spec as a key format that cryptosuites can use.

Orie Steele: +1 to (keeping) Multikey in data integrity, and citing it from vc-di-bbs (and others).

Orie Steele: +1 to allowing suites to not use Multikey.

Dave Longley: +1 to one place (data integrity spec).

Manu Sporny: any objections to putting multikey into data integrity spec?

Phillip Long: +1 to allow Multikey in the data integrity spec.

Chris Abernethy: (no objections voiced).

Manu Sporny: we will do that, and put def into data integrity spec.
… should cryptosuites be able to define key formats that they support? e.g., we support multi-key, but only “this subset”. Would anyone object to this?

Phillip Long: +1 to allowing cryptosuites to define public keys they support.

Dave Longley: +1 to allow cryptosuites to define key types they support.

Orie Steele: +1 to allow cryptosuites to define key types they support.

Chris Abernethy: (no objections voiced).

Manu Sporny: Orie does that address your concerns.

Orie Steele: yes.
… talking about clarification of @context.

Kristina Yasuda: encourage folks to keep reviewing PRs, 1100 and 1101 appear to be crucial.