Verifiable Credentials Working Group Telco — Minutes
Date: 2023-10-18
See also the Agenda and the IRC Log
Attendees
Present: Hiroyuki Sano, Ivan Herman, Phillip Long, Paul Dietrich, Brent Zundel, Ted Thibodeau Jr., Dave Longley, Manu Sporny, Orie Steele, David Chadwick, Joe Andrieu, Greg Bernstein
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Manu Sporny, Orie Steele
Content:
Brent Zundel: Welcome everyone, let’s get started. This is the VCWG regular call.
… We are going to be doing work item status updates, look at a few PRs, and rest of our time discussing issues.
… As mentioned during special topic call yesterday, the Chairs are going to be a bit more aggressive about declaring lack of consensus on PRs. If we do not have a clear path forward to consensus, the Chairs are going to strongly recommend closing PRs and that will lead to us re-examining underlying issues so group can determine whether or not those issues can be addressed in this iteration of the WG.
… We expect this might lead to some issues that people care about being marked as one that we cannot address and will need to be addressed by a future group.
… Any changes to agenda?
Manu Sporny: No changes to the agenda recommended.
1. Work Item status updates/PRs.
Brent Zundel: Updates on work items, PRs, core data model PRs?
Manu Sporny: as discussed on special topic call.
Manu Sporny: https://github.com/w3c/vc-data-integrity/pulls.
Manu Sporny: there are 2 new PRs on vc-data-integrity.
Manu Sporny: see https://github.com/w3c/vc-data-integrity/pull/213.
Manu Sporny: adds internationalization and commentary.
Manu Sporny: see https://github.com/w3c/vc-data-integrity/pull/214.
Manu Sporny: clarified the details of the multibase data type.
… hoping for more reviews.
… plan to cut CR after these are merged.
… PRs will be merged by Friday.
… all the data integrity specs have exist criteria, seeking implementations, etc.
… by this Friday we should have CR ready documents for all data integrity documents.
… I ran all the checks.
Brent Zundel: Thanks for the update.
Ivan Herman: This was not the final review for CR, this was the first CR review – knowing PLH and Yves, there might be more comments.
Brent Zundel: The accelerated timeline, please review these PRs so we can merge them by Friday.
… I don’t see Gabe on – any updates for vc-json-schema?
Orie Steele: See this PR: https://github.com/w3c/vc-json-schema/pull/220.
Ivan Herman: I saw PRs from Gabe, same level as other CR documents that Manu talked about… exit criteria is in status section, we’ll wait for some feedback from i18n before it can continue… essentially on same level as Data Integrity specs.
Brent Zundel: Please review the PR, we want to merge sooner than 1 week window so vc-json-schema can be ready for CR.
… Any updates for other work items?
Manu Sporny: The renaming for the status list spec will happen by the end of this weekend.
… We need to do a manual publication after that.
… I will prioritize vc-data-model first, then status list.
… Also, for BBS, Greg and I will help edit, not many changes from ecdsa-sd, so we’ll try that direction to see how things go.
Orie Steele: Been thinking about multiple status list details and wanted to ask, multistatus list representation stuff, is that going to block us, is it ready to go? I know MikeP was most interested in that work. I’m not sure if it is going to hold stuff back. Does anyone have context/awareness about scenario w/ multiple statuses or single list? Is it progressing? Do we cut it to publish document? Possibly longer conversation.
Manu Sporny: I spoke to Mike.
… I promised we would keep the multistatus list stuff in the spec.
… we can put the at risk marker in on it.
… if we don’t see implementations, we’ll cut it from the spec.
… there seems to be enough there that we could remove it if we need to.
… mike said he has implementations, we’ll find out in CR.
… I share Orie’s concerns, but it seems structured ok as is.
… we seem to be ok to remove it, if necessary.
… ecdsa-sd is also marked as “at risk” and could be removed.
Brent Zundel: Any other updates on work items? I think we have updates from all of them except vc-jose-cose.
1.1. Fate of the controller document.
Orie Steele: There is currently no open PRs for vc-jose-cose – we wanted to work with keys / controller documents. There is an open issue wrt. controller documents - how do we specify it? Separate spec? We’d like to cite a document, any other changes that have happened since we last discussed? In general, key identifiers and controller documents are blocking spec from progressing.
Manu Sporny: we could unblock by.
… if the data integrity transitions happens on November 7th, we could cite the data integrity section as being in CR.
… we could decide to split the spec up, and publish the controller document bit out as a separate document.
… as long as the content is the same, the document can start out in the candidate recommendation phase.
… then people can just cite the data integrity spec defined controller document.
… no normative changes would be made.
… thats one approach we could take.
Ivan Herman: I am not sure whether that’s doable or not, I have never met this kind of problem before. If we really want to do this, we have to write this down and ask PLH… I cannot say yes/no right now.
… Brent, any thoughts?
Brent Zundel: My read of the process doesn’t really touch on this… the process doesn’t say we can’t. It also doesn’t explicitly say “that’s fine” – this is an edge case that’s not in the process document.
… We’d have to write down our intentions and get an OK from Philippe.
Orie Steele: I’m glad that this path is on the table, my understanding is that this path was always on the table. We could have decided to do this before sending DI to CR, we could make changes before CR – then we don’t have extra process question.
… Open question, can we just publish a different document?
… Citing Data Integrity of controller documents w/o making normative changes is unlikely to satisfy a neutral shared interpretation of controller documents. When I adjusted the controller document language, there were DI details there, also ZCAP, encryption, etc… not specific to VCs, but are present in the document.
… I’m not sure if we did take splitting at CR approach that that would work. I’m happy to help however I can, mostly just looking for options, appreciate that this is one option.
Ivan Herman: Answering one question Orie had, might answer what Manu said. Yes, at any time, we have right to reorganize our deliverables – we can merge documents, split documents, we have the right to do so. No problem there. The only problem is that if there is a new document, then what is its status? Is it a WD, CR, or something else?
… The problem is that this is related to patent policy, if you have a new document which hasn’t been around before, even if it was a part of something, starts a new patent policy cycle… usually done when you do a FPWD.
… That’s why FPWD is such an important step, if we take out this part from CR, then it has to go to FPWD to start the patent policy process even if what we can do, after six weeks, we go to CR right away.
… I suspect that’s the case.
Orie Steele: My preference would be to introduce the controller document as a new document, FPWD, and clean up the content before trying to send it to CR.
Brent Zundel: With that interpretation of process, alongside Orie’s concerns that normative changes might be required, it sounds like even if we pull that section out during CR, the stuff we pull out would have to start out as a FPWD.
… That would give us opportunity to do patent review and normative changes.
… As a path forward, how do folks feel about that?
Manu Sporny: I’m ok w/ that as a path forward … -1 for taking that section out now.
Ivan Herman: Brent, it seems like we have a mind meld going on. I wanted to ask same thing… cleanest thing if we go that way is to take that part out now, that’s what we would go into CR with. That would mean we have to do FPWD of that document, quick, could publish almost at same time as CR for other documents.
Orie Steele: I agree with Ivan and Brent.
Dave Longley: -1 to hold up DI, +1 to issue marker to decouple.
Manu Sporny: I am a -1 to holding up data integrity yet again.
… instead we could allow data integrity to go forward, and add a market that it would be replaced by another document that would not change the controller document.
… normative changes might not get consensus, and that would then prevent the documents from advancing.
… I would be a -1 to jeopardizing CR for data integrity… I prefer to put a marker, that says the WG is working on a controller document, and data integrity might refer to that spec in the future.
… the only difference here is that it decouples things.
Brent Zundel: Nothing you said is incompatible with what I was suggesting, I think we’re aligned.
Dave Longley: +1 to an issue marker saying the controller document section might have a new reference with the same normative statements (or some subset of them having moved, some others specific to data integrity remaining in the DI spec) based on a new controller document being based on the DI spec.
Ivan Herman: That seems fine, there might be some eyebrows raised. To play devils’ advocate, removing one section from VCDI by itself is a quick thing to do.
… I don’t see that as jeopardizing the CR, you can do it in no time.
… How much time should we take to go through editorial trouble to turn it into a proper document?
… We are preparing final version of CR now, by this weekend, this may be doable. I don’t know, not an editor of the document.
Dave Longley: the current controller document consensus is based on it being in the data integrity spec, moving it could unsettle that in some unforeseen way.
Orie Steele: I guess cutting into the meat of Manu’s comment, the assertion is that the WG might not come to consensus of controller document, and current version of controller document becomes TR, then controller document as defined in DI has same normative changes that WG couldn’t come to consensus on. It’s possible that current document doesn’t reflect WG consensus, we’ve been following process, there is a difference here in terms of consensus – agree with consensus comment Manu is making, if it’s a concern, better to tackle it head on because it’ll turn into an issue later.
Manu Sporny: ivan, i think its more complicated that just removing the section.
… that would break references.
… we would need to update those references to a new location.
… we would need to address the FPWD side of the new document.
… it would take much time to do this.
… this would also have to be balanced against the core data model and status list PRs.
… so, its seeming like not something we should rush.
Ivan Herman: I understand, Manu.
Manu Sporny: lets not extract the section from the document, for now, lets just duplicate the content.
… and try to reconcile the content in the future.
Dave Longley: +1 to Manu.
Manu Sporny: lets proceed with the plan.
Brent Zundel: I want to note that the controller document section of DI has consensus as it pertains to DI. I’m not concerned about group consensus of that section. I agree that extracting it is more complicated.
Orie Steele: I agree with Manu, I think this is probably the best path forward.
Dave Longley: +1 to Brent.
Brent Zundel: My recommendation as a path forward is: Let’s add issue markers to that section in DI so that can move forward. In meantime, we can publish a FPWD of a controller document, that should be minimal, goal of that spec is to define general document that vc-jose-cose draw from, if that spec is successful, then changes indicated in DI can be acted upon and vc-jose-cose can point to the new controller document spec. Does anyone disagree with that path forward?
Orie Steele: +1 on “Data Controller Document Spec “ : ).
Orie Steele: vc-jose-cose already has a section, we should add a similar marker to it… https://w3c.github.io/vc-jose-cose/#controller-documents.
Ivan Herman: First of all, I accept Manu’s arguments against doing it now.
… My understanding, what Manu is proposing is slightly different from what Brent is saying. vc-jose-cose should have similar section, along the lines of what they want to have there, and so issue statement that we would add – good to have formalization for it – is that another document produced by the group has a similar section and WG is considering merging those two approaches into one independent document.
Dave Longley: +1 to say we’re trying to create a separate document with the pieces that are in common.
Dave Longley: to allow common reference.
Ivan Herman: To make the message clear, we have two versions of similar concepts and we’re trying to see if we can merge them into one separate document, or something of that sort. Not say “we’re planning to take it into a separate document”, but “we’re trying to align between two specifications”.
Orie Steele: +1 dlongley’s comment.
Manu Sporny: agree with the proposed course of action.
Phillip Long: +1.
Dave Longley: +1 to this plan.
Brent Zundel: Anyone opposed to this course of action? If not, we’re going to proceed.
Manu Sporny: No opposition to the plan.
2. Issue Discussion.
2.1. Encourage the use of OHTTP (issue vc-data-model#1267)
See github issue vc-data-model#1267.
Brent Zundel: This doesn’t have an assignee, came up during privacy review.
Manu Sporny: I can take this PR.
Orie Steele: I suggest we not do a PR for that, and instead close the issue.
Manu Sporny: 2-3 weeks, someone else do a PR before I get to it.
Dave Longley: could mark it after / during CR too instead.
Manu Sporny: This came from security/privacy review… it might be bad to just close it since it came from horizontal review.
Brent Zundel: Yes, we could ignore it, but neither of those options are the way things ought to be done.
… Thanks for volunteering, manu.
2.2. are domain and range correct for all properties in data model? (issue vc-data-model#1263)
See github issue vc-data-model#1263.
Brent Zundel: What’s the status of this?
Ivan Herman: This turned messy since end of August, including new versions of vocabulary/diagrams, which have been merged.
… My proposal would be to close this issue because it’s become unmanageable. Someone should take up responsibility of looking at spec and vocab and answer the original question, is domain/range correct yes/no, or if there are changes needed?
Brent Zundel: not sure I agree w/ proposal to close issue.
Ivan Herman: There are some issues there / discussion, that have been put into changes.
… That’s difficult to follow. Diagrams have been updated, vocabularies have been updated.
Brent Zundel: We would open a new issue to make sure domain/range matches what’s in the data model?
… TallTed, this is your issue, would you be opposed to that course of action?
Orie Steele: Is there a link to the diagram that landed? I feel the diagram in the issue is helpful.
Ted Thibodeau Jr.: I would not be opposed to a new issue that doesn’t have the history, don’t know how beneficial? Opposed to closing. We need a tracking issue.
Orie Steele: +1 TallTed.
Brent Zundel: Agree, this is something that needs to be completed.
Ivan Herman: What I proposed is what Ted proposed.
Phillip Long: +1 to open this issue fresh.
Ivan Herman: Create a new issue to check domain/range.
Brent Zundel: Ivan, can you open the new issue?
Ivan Herman: Yes. And I will then close this one.
2.3. Internationalization Review for VCDM 2.0 (issue vc-data-model#1155)
See github issue vc-data-model#1155.
Brent Zundel: This issue tracks that i18n review happened. We had a meeting w/ i18n folks.
Ivan Herman: I think there is still a PR coming wrt. i18n issues in the document. The setting of default language/direction.
… That should be put into a PR and eventually merged, when that’s done, we can close this.
Manu Sporny: we are tracking that issue, separately.
David Chadwick: +1 ivan.
Manu Sporny: I don’t recall when we can close horizontal review issues.
… review happened, other issues were created, i think we can close this.
… the items they raised are tracked in other issues.
Brent Zundel: Thanks, that’s my understanding as well. I’m going to close this issue after minutes are generated.
Phillip Long: Just a note that there are 4 “applicable” items in the internationalization review.
Brent Zundel: Ok, end of call, thanks everyone.
… Reminder that the chairs are going to become considerably more aggressive determining when we don’t have consensus on PRs. Our timeline is overdue.