Verifiable Credentials Working Group Telco — Minutes

Date: 2024-01-03

See also the Agenda and the IRC Log

Attendees

Present: David Chadwick, Greg Bernstein, Phillip Long, Gabe Cohen, Ted Thibodeau Jr., Brent Zundel, David Lehn, Will Abramson, David Chadwick, Dmitri Zagidulin, Michael Jones, Joe Andrieu, Benjamin Young

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Gabe Cohen, Manu Sporny

Content:

Brent Zundel: agenda today is straightforward. work item status updates. look at PRs. as necessary, as time permits do triage. as time permits do issue discussion.
… hope to resolve all open PRs. esp. those before PR. if not mergeable will close them or flag as necessary. out of time!

1. Work Item status updates/PRs.

Brent Zundel: first up: status updates for work items.

Manu Sporny: VCDM - we have PRs for every before CR issue. most have been out a week, some 5 days. will close or merge. then we can be ready for CR.
… DI specs - number of PRs with normative changes that were going to trigger a 2nd CR. we agreed to do that in December. J. Yaskin asked for interface changes b/w VCDM and all securing specs. He made a good set of changes re:that interface.
… those changes went in yesterday and need some cleanup. Will trigger a 2nd CR for all DI specs. Need another week for cleanup, then up to us when to go to the 2nd CR.

Manu Sporny: On bitstring status: https://github.com/w3c/vc-bitstring-status-list/pulls.

Manu Sporny: Bitstring Status List - there are 20 PRs raised over the past weeks. Address every before CR issue that we know of (35 issues). Will close about 20 of them if we merge them in. Many not controversial.
… some renaming of terms, some at risk issue markers. Brent - leave more than 7 day merge b/c of holidays? when can we start to merge? do have a decent bit of review (3-4 people for each). good for the group to get another 7 days before merge.
… once we merge then Bitstring Status List will be ready for CR AFAIK.
… for VC-JOSE-COSE both I and David Chadwick have gone through fully. Found about 11 concerns. Number need to be fixed before. Created issues and marked accordingly.

Brent Zundel: for a review period - open for another week is fine. merging this week also fine.

Manu Sporny: ack. will leave it to at least the call next week.

David Chadwick: for JOSE-COSE, one Manu marked as post-CR should be pre-CR. hope we get to discuss them today.

Gabe Cohen: Can’t give a proper status update now, MikeJ did some work over the break, haven’t had a chance to discuss Manu and David’s concerns yet. We’ll meet this week and have a better update next week.

Brent Zundel: will be running through VCDM PRs.

Brent Zundel: https://github.com/w3c/vc-data-model/pulls?q=is%3Apr+is%3Aopen+label%3Abefore-CR+sort%3Aupdated-asc.

1.1. Correct layering violations related to the proof property (pr vc-data-model#1397)

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

Brent Zundel: looking at 1397 (https://github.com/w3c/vc-data-model/pull/1397) - has been superseded by other PRs? is that correct.

Manu Sporny: next step is for Mike to look at the latest spec and see what the delta is. probably a minimal change set at this point.

1.2. Add requirement for securing mechanisms to have post-verification documentation. (pr vc-data-model#1392)

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

Brent Zundel: next up 1392. a couple of requests for changes.

Manu Sporny: believe Mike Jones is opposed to this PR. have asked Jeffery Yaskin if there’s other language that would work. Both Mike and Jeffery need to have a discussion on appropriate text. If can’t settle let’s close the issue + PR.

Brent Zundel: if someone wants to suggest a path forward please do, otherwise pending close.
… marking as pending close. hope within the 7 day window those opposed can work together and find a path forward.

1.3. Add embedded securing mechanism specification requirements (pr vc-data-model#1403)

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

Brent Zundel: next 1403: add embedded security mechanism specification requirements. believe changes have been addressed. will be merged soon.

1.4. Add RANGE_ERROR to list of potential errors. (pr vc-data-model#1405)

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

Michael Jones: sorry I am late. as a courtesy would appreciate stuff not being merged until Friday close of day so I and others who are just coming back have a chance to read.

Brent Zundel: no opposition to that.

Manu Sporny: +1 that was my plan.

Brent Zundel: On #1405: add RANGE_ERROR to list of potential errors. broad approvals at this point. straightforward PR.
… expect it to be merged by EOW.

Manu Sporny: slightly nervous. reworking some algs according to feedback. some questions re:where there’s errors should go, what links should be. a chance the errors can jump between specs. e.g. some more specific to the VCDM, or bitstring status list.
… considering putting in an AT RISK marker to note the errors might jump from spec to spec, just as a warning. the URLs might change based on impl. feedback. anyone opposed?

Brent Zundel: no opposition. you are good to proceed as suggested.

1.5. Refine status language and make credential status id optional. (pr vc-data-model#1401)

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

Brent Zundel: 1401: refine status language and make credential status id optional. large # of approvals. no requests for changes. expect it to be merged by EOW.

1.6. Update context to include latest BitstringStatusList changes. (pr vc-data-model#1406)

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

Brent Zundel: 1406: more recent. update context to include latest BitstringStatusList changes. open to discussion.

Manu Sporny: mostly a question to selfissued. I think Mike is opposed to the PR. tried to respond to the concerns. to paraphrase - feel it would be more modular to have status list in its own context. we decided a while ago to not do this to make devs lives easier.
… don’t have to pull in another context. doesn’t cost us much. does this impact your position?

Michael Jones: no not really. there were objections to that decisions (I was one). still object. do not have criteria for what does/nt go in the base context. always taken a position that the base context should be what’s in the base data model. context for status list, etc. otherwise it becomes a popularity contest, where we are now.

Manu Sporny: objective criteria: things this working group are working on. not a popularity context. it’s the set of specs this group is standardizing. includes vc-jose-cose, status list, other spec that we feel are applicable. that’s where we got to consensus. don’t agree with the characterization.
… if we don’t put this in as well then it is confusing. don’t follow what we had consensus on in the group.
… is this a formal objection? on which technical grounds?

Michael Jones: the problem is…by losing the modularity the context for the data model is dependent on every other spec finishing at the same time which isn’t realistic. we have dependencies on stuff with varying degrees of completeness. better off to have a context for each spec.

Manu Sporny: would be good to hear from others. what we’re trying to do is optimize. had complaints from implementers earlier on. we have statements to mitigate your concern Mike. once in CR things are locked pretty well and stable.
… once status list and VCDM are in CR then the values are stable. have mitigated the concerns. feels like we’re re-opening an old debate without new information being brought to light. would need to hear from others in the group about this.

Brent Zundel: chair hat fully on. I remember this debate. brought an issue myself. we had this conversation. the result was the context file is a collection of whatever folks feel is convenient for implementers. that’s why it includes vc-jose-cose, etc. that’s my understanding.

Dmitri Zagidulin: agree with you Mike that we should have clearly defined parameters of what goes into the context (shouldn’t be popularity). we do at the moment have these parameters: just the specs going to CR in this working group. no problem with this.

Phillip Long: The current PR #1406 seems like a reasonable compromise between those that want separate context files for everything & those that want to have fewer for just the specs in working group.

David Chadwick: I agree with Dmitri. if we have a spec lagging behind we have a problem. never goes to CR = no problem. goes to CR much later = problem, since a definition can change. boils down to how fast are they all progressing. are they at the same speed?

Brent Zundel: my recollection that we have language in the spec that addresses this (values can change before CR). please correct me if wrong.

David Chadwick: if one goes to CR much later then there would be a problem.

Brent Zundel: agree.

Manu Sporny: to address that problem the WG can choose to remove those values. if we are in that position we can have a discussion to keep the values or not.

Brent Zundel: for those who don’t like the ‘kitchen sink’ approach. that’s where we’re at now. would be a change to not continue adding to the sink.

1.7. Rename “Controller Document” to “Entity Document”. (pr vc-data-model#1396)

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

Brent Zundel: next PR: 1396 - rename “controller document” to “entity document”.
… a request for changes from Joe. conversation has continued back and forth. does not look like we have consensus. happy to take comments before marking pending close.

Manu Sporny: clearly disagreement on this item. the problem this creates is : what is the short name we publish, if we need to before VCDM v2 goes to CR. today, VCDM depends normatively on the controller document spec. we broke this out from DI. have yet to do FPWD with it.
… need to do at least 1 of 2 things. 1 - figure out the new short name, publish as a FPWD on the TR track for controller document. feels like a tall order.
… OR in the VCDM spec we could update the references to controller document -> data integrity with an AT RISK issue marker, noting we are publishing a new controller document spec.
… that allows us some breathing room, avoids debate for now. will not need to publish controller document as FPWD before taking VCDM before CR. easiest thing is to update refs and note they will change in the future.
… seems more difficult to have this debate which could take a few weeks, delay VCDM to CR for weeks or more.

Brent Zundel: proposed by Manu, update refs to the controller doc spec to point to the current text in the DI spec. with a note that we will update them.

Joe Andrieu: concerns: on semantics, feel entity name lost the relationship b/w that document and the VC. and introduces new semantics which I think are incorrect. could take a while to hash out.
… more concerned about time. introduced this after the VCDM feature freeze. think the language itself is good as long as it has a “we may not get to it” and can still publish the VCDM even if we don’t get closer on a new controller document spec.

Brent Zundel: my understanding that is the path we are on.

Michael Jones: I feel like I’m echoing Orie, but we shouldn’t be creating normative deps on the securing specs from the VCDM. full stop.

Gabe Cohen: +1 from me.

Manu Sporny: we already have normative dependencies. has been true for a while now. this is not new.

Michael Jones: not sure what you’re referring to. should not exacerbate the problem.

Manu Sporny: how does this exacerbate the problem? current controller doc is an exact copy+paste of what’s in the DI spec. there’s no difference in content currently. we would be adding text to outline our intention.
… e.g. point here today, will point somewhere else tomorrow. we don’t want to delay. could take another month to get the controller doc spec in shape. don’t see how this exacerbates the issue. helps us get VCDM v2 in CR sooner than later.

Michael Jones: exacerbates the problem by taking a normative dep on the controller document language in the DI spec. talked about this 2 months ago. agreed to break this out with you to a new spec. recognizing not everything in the DI language will survive.
… if you take a tentative decision, someone will say “we can’t reconsider this” - so not willing to do that.

Brent Zundel: I don’t believe it matters what we call this…it matters…but what we’re pointing to. we’re pointing to something with language specifying a document specifying properties. we’ve been calling it controller document, maybe should be called something else. what we call it matters a bit, but really not much.
… as long as it’s not the jelly bean spec! (might be more fun, though). right now the concern is we want to get to CR with the core data model. we are pointing normatively to a thing that’s not a thing.
… either need to make that thing a thing as fast as possible. or point to something else, fully intending to make that thing a thing.

Manu Sporny: position I’m arguing for is your second option. “we intend to make this thing a thing ASAP” - express our intent and move forward. 3rd option is to point to DID Core, which is a REC.
… have looked at references we have. we talk about very similar things. each of these sentences could point to DID Core, with a caveat that these fields can be URLs, not DIDs. that’s the only difference we’re talking about here.

Michael Jones: option, where I thought we were, wasn’t enumerated. there is language in each of the securing specs. we will leave it there until we pass CR. then we will pass CR and harmonize. I thought we were at a place where both security docs define this. no need in the core data model.

Manu Sporny: no that’s not where we are Mike. if you are OK with that…we can go in and modify where we reference controller doc in the spec and point to “as defined in VC JOSE COSE or VC DATA INTEGRITY” - that’s aligned with what you said, and I’m fine with that.

Michael Jones: yes, thank you. thought that’s where we landed.

Joe Andrieu: I’d like to see the aperture of that defined as “in securing specs…” to not exclude other securing specs.

Manu Sporny: I will raise a PR and Joe can try to modify the language.

Joe Andrieu: perfect.

Manu Sporny: just 3 instance with this language. then we are clear to go into CR rapidly.
… will raise a PR in lieu of 1396 that attempts this.

2. Issue Discussion.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+sort%3Aupdated-asc.

Brent Zundel: 5 min left. skipping issue triage. going to issue discussion.

2.1. Rewrite verification algorithm in a way that does not cause layer violations (issue vc-data-model#1377)

See github issue vc-data-model#1377.

Brent Zundel: there are 4 issues, let’s talk about them. first one 1377: Rewrite verification algorithm in a way that does not cause layer violations. looking for a quick status update. all have PR exists. can we successfully address this issue?

Manu Sporny: for 1377 believe the vast majority of the changes are already in. Need Mike (selfissued) to look and see what delta is remaining. Believe changes applied through other PRs.

Michael Jones: are there more that you believe impact my PR? should I try to resolve merge conflicts and see what happens?

Manu Sporny: try to resolve merge conflicts and see what’s left.

Michael Jones: ack.

Ted Thibodeau Jr.: Not just merge conflicts. A number of suggestions have not yet been acted on.

Brent Zundel: speaking to a pull request?

Ted Thibodeau Jr.: 1397.
… suggestions should be applied before the delta is analyzed/conflicts resolved.

Manu Sporny: quick heads up to selfissued, there are still some open PRs which impact your PR. just be aware of that. all listed in 1377.

Michael Jones: do those look like they’re going to land?

Manu Sporny: yes.

Michael Jones: thanks will look at those first.

2.2. Ensure credentialStatus id field is optional (issue vc-data-model#1398)

See github issue vc-data-model#1398.

Brent Zundel: 1398. Ensure credentialStatus id field is optional. Believe this is on track to be closed. PR 1401 is raised and on track.

2.3. Clarify embedded proof extension point (issue vc-data-model#1400)

See github issue vc-data-model#1400.

Brent Zundel: 1400 Clarify embedded proof extension point. also on track with this. expect it to be addressed by EOW.

2.4. Specify what kind of processing is safe on a returned document (issue vc-data-model#1388)

See github issue vc-data-model#1388.

Brent Zundel: finally Specify what kind of processing is safe on a returned document #1388 - not exactly sure the state of things here.

Manu Sporny: does not seem like this will make it. Jefferey asked us to make a change. selfissued is concerned about language being too vague. if we can’t find better language let’s close the PR and issue.

Brent Zundel: yes, have marked this PR as pending closed today.
… have gone through all before CR PRs and issues and got status updates. good meeting & conversation. please make progress on your tasks. feel free to reach out to editors & chair if need-be.
… during next weeks calls expect to take core data model to CR.