VC WG Telco — Minutes

Date: 2021-12-15

See also the Agenda and the IRC Log

Attendees

Present: Charles Lehner, Brent Zundel, Dave Longley, Shigeya Suzuki, Manu Sporny, Kyle Den Hartog, David Chadwick, Ryan Grant, Ted Thibodeau Jr., Logan Porter

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Kyle Den Hartog, Manu Sporny

Content:

Brent Zundel: https://github.com/w3c/vc-wg-charter/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc.

Brent Zundel: is there anything that people would like to add to the agenda? …. none heard.
… first topic is Draft charter issues.

1. VCWG Draft Charter.

1.1. Protocols and APIs should remain out of scope (issue vc-wg-charter#24)

See github issue vc-wg-charter#24.

Brent Zundel: first issue is number 24.
… last time we said we’d close it so I move to close the issue any opposed?.
… none heard going to close this one.

David Chadwick: I did tell Mike last week about this.

1.2. Verifiable Credential Linked Data Integrity work should happen in a Linked Data working group (issue vc-wg-charter#21)

See github issue vc-wg-charter#21.

Brent Zundel: manu I believe you have a PR open for this. Can you tell us about this?.

See github pull request vc-wg-charter#32.

Manu Sporny: yeah there’s a PR open for this.
… what it’s trying to do is make it clear that this next spec will be talking about data integrity for verifiable credentials in a more wholistic and normative way.
… this means JWTs/LD-Proof and any other mechanism would be in scope as well.
… including things like JCS and other things like that.
… we can’t invent new crypto here but can focus on how things get packaged up.
… by calling this LD Integrity it’s not accurately representing this.
… the specific reasons we’re doing this is because we want to be clear that we’re not just talking about Linked data integrity and making this about VC data integrity.

Brent Zundel: Assuming the JWP work gets further along would you expect we could use that in here?.

Dave Longley: My one concern with this PR is that we don’t want to convey that we’re only doing JWTs and want to make it clear the Linked Data proofs are in scope.

Manu Sporny: One thing we do to counteract that is to link specifically to the linked data proof spec.
… I can check in CCG about renaming but this should make it clear that we want it in scope.
… I’ll add some clarifying language to explicitly list the things in scope.

Kyle Den Hartog: I was thinking about… the proof section becomes obvious, I’m not sure to what degree we wanted to scope particular suites… with JWTs you don’t hit that as much, how do we want to handle scoping of that?.

Manu Sporny: I believe the way it’s scoped now is that we say all of the suites are non-normative.
… one second that might not be true.
… we don’t say anything about the suites themselves.
… I think the intent was to note define specific suites.
… we’d publish notes and test suites for it but not define them normatively.

Dave Longley: -1 we shouldn’t constrain ourselves to not being able to define any suites.

Manu Sporny: but that might be the wrong way to go about it.

Kyle Den Hartog: I’m concerned that suites are being developed now in a way that makes it problematic..
… Like there are 2020, 2021, 2022 suites being developed, taking longer than a year to stabilize – we need some sort of model to encompass the active work happening right now..

Dave Longley: I don’t think we should constrain ourselves to not being able to address these suites.
… we may be able to develop a versioning scheme that’s a bit of a middle ground where we create a few with common vocabs to describe these.
… and that might avoid some of the issues that Kyle is bringing up.
… we might be able to handle this, but my main point is that I don’t think we should constrain ourselves to solve that.

Manu Sporny: There is a VC extension registry.
… I think we’re probably going to end up making that in scope.
… I’d imagine doing all that to document that things are in process.
… to dlongley point I think the big question is how normative do we want to get about the suites.
… I think the idea was that we’d define a bunch of the suites as notes.
… part of the DID-Core objections are that you should have just taking things to CR and not gone further.
… so if we take that into consideration for this chartering we may follow a similar model.
… where we only take a suite to CR without saying we’re going to work on all of these suites normatively.
… and stay focused on a few that we take to CR and if we have good enough interop we can ask W3C to take it to REC later.
… this would allow us to make it clear that we’re not overscoping our work.
… so we need to be careful about what we say we’re going to do.
… this is to say we’ll change the description to say we’ll describe Edwards curve, BBS+, and JWTs but not take them fully to REC.

Brent Zundel: How common is it for people to say we’re only going to CR only?.

Manu Sporny: Not common it’s only for CSS typically and other perma working groups.

Brent Zundel: with just my hat on I’m not sure going to only CR makes sense.

Dave Longley: +1 I think it’s best to say we’re going to handle only a few suites.

Kyle Den Hartog: Saying going only to PR seems like people could object to that.

Manu Sporny: I think we could do that for Edwards curve but could be trickier for BBS+.
… we’d need CFRG approval before we could reference them normatively and succeed in REC stage.

Dave Longley: if we go with something a bit more general we could describe how you use a suite without having to specifically normatively define BBS+.

Brent Zundel: There’s active work at DIF and they expect to have something to submit to the CFRG first quarter next year.

Manu Sporny: Is there something we can point out?.
… even if it’s an ID that intends to go to CFRG.

Brent Zundel: See current draft of BBS+.

Manu Sporny: I think the response to the JWTs handling all of this is that you can’t do multiple signatures together with JWTs today.
… the other issue is that we have a parallel RDF canonicalization WG.
… and that group is expecting the ability to not have to use only JWTs only.
… and with people already using this I think we have sufficient counter arguments for these things being brought up.
… and we’ve documented all that stuff.
… I think we’re ok, but we’ll see how it goes.

Kyle Den Hartog: I think that’s a sufficient argument.

Manu Sporny: I guess the question is what do we want to do for this..
… Do we want to update the description for this PR and describe focusing on Edwards and BBS+.
… and because this is a normative item we can then decide as a WG to decide how we want to split up that work.
… we’d have one description to define how to express VC integrity with a specific focus on Ed25519, BBS+, and JWTs.

David Chadwick: +1.

Dave Longley: +1 to what manu just said and to pointing to this discussion saying we meant to define LD suites.

Manu Sporny: and if there’s ever a question about whether or not we meant to include Linked Data we can point back to these minutes to show we were very clear.

Brent Zundel: So what needs to change for that to happen?.

Manu Sporny: I need to change this PR to include it and I’ll link to draft state input documents to cover this.

1.3. standardize verification processes for a variety of well understood use cases (issue vc-wg-charter#30)

See github issue vc-wg-charter#30.

Kyle Den Hartog: Given the scope of the work, don’t know if we want to take this on now. Ok with leaving it undefined, can advocate inside WG for it if we have time for it..
… Otherwise, ok to leave it out of scope and we can tackle it in time..

Brent Zundel: Do we have to be specific about this being in scope?.

Kyle Den Hartog: We probably walk ourselves into problems if we go to REC… we weren’t being explicitly clear… multi-issuance and multi-proofs. Given that you can do multi-proofs in LDI, we could argue that it was a part of it at the out set, might make it unclear where we fell on that sort of stuff..
… Maybe when we list LDI, we specify multi proof sets?.
… When we were talking about LDP, we were looking at specific proof suites, Edwards and BBS+ for multiproof systems..

Manu Sporny: I’m trying to get a link.
… for the LDP spec which includes section 7 with multiple proofs.
… but I’m not sure this addresses what you were talking about.

Manu Sporny: https://w3c-ccg.github.io/ld-proofs/#multiple-proofs.

Kyle Den Hartog: yes, we did run into this problem, that’s exactly what I was thinking about – not clear, when writing suites, combine them into VP, how you prove that they’ve been bound to the same identity and both are presenting together vs. two independent subjects generating presentation..
… For example, mortgage, married couple signs independently, sign together on single document, you could do multi proofs, subjects different can sign same thing. Generic way to express those same proofs w/ multiple subjects not very clear at this point.

Dave Longley: input doc on ld proofs should give us the space we need to work on multiple proofs on a single document.

Manu Sporny: agree, we can always add examples..

David Chadwick: Just two points, one is the current text is that appendix A refers to validation.
… and this should say verification.
… and the second point that Kyle was saying is that it brings back if the IDs refers to the holders or the subject and I would hope that would come into this.
… since one way of resolving this is to rely on a proof of possession in all of these.
… Do people remember this discussion and how we had two separate views for this? I think that discussion would feed well into this.

Manu Sporny: Yeah to what kdenhartog and what has been said in chat I think we have space to make it clear that we can show how that’s done.
… so I think we’re in safe territory.
… with respect to what DavidC I vaguely remember the discussion but none of the details.
… maybe the multiproof stuff brings that to the fore.
… and in a fairly normative way.

Dave Longley: +1 multiproof in scope and talking about ID relationships and establishing proofs are in scope.

Kyle Den Hartog: In that case, I feel like it’s justified and in scope based on what we know about LDI and LDP to be able to say there is no necessary updates to the charter in order to close out this issue. This will fall in naturally to talk about these sorts of use cases..

1.4. Standardization of Multilingual Support (issue vc-wg-charter#19)

See github issue vc-wg-charter#19.

Brent Zundel: One other issue to cover for this.

Shigeya Suzuki: I posted examples yesterday for this and filed a PR for this and got feedback from Kyle and Manu.
… my proposal has two schemes to do translation and I think now what I’m trying to do is understand it better.
… the thing that I was wondering how to express new work items in the charter.

See github pull request vc-wg-charter#33.

Shigeya Suzuki: and I’m not sure if it’s good now.
… If certain citations we may want to have some sort of table like list to translate both the key and value.
… and I wanted to get further feedback on this.

Kyle Den Hartog: Just to comment on the specifics of whether this is adequate..
… I think the text added to charter makes it good enough, and things you’re discussing are things we can get feedback in WG. Good that you’re getting jump start on this, when adding text to spec, that’s where we can figure out what makes sense..

Brent Zundel: any other comments, questions, concerns?.
… Those were the VCWG draft charter issues.
… we’ve got about 10 minutes left for the other parts of the agenda.

2. Review PRs.

Brent Zundel: next topic is to review some PRs.

Brent Zundel: https://github.com/w3c/vc-data-model/pulls?q=is%3Apr+is%3Aopen+label%3A%22v1.1+%28editorial%29%22+sort%3Aupdated-asc.

Kyle Den Hartog: Link to those are here and we’ve got 5 open.

Brent Zundel: Manu can I turn this over to you?.

2.1. Clarified subtitle of Data Model (pr vc-data-model#780)

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

Manu Sporny: We’ve got one we should be able to resolve very quickly.
… we’ve tried so many things and we’ve landed on just deleting the subtitle.
… the suggestion is to just remove it and that seems to have the best consensus.
… no objections to this solution.
… so this is a final call for objections.
… if not I’ll merge this on the call.

Brent Zundel: Any objections?.
… none heard.

Manu Sporny: That was 6 months in the making :).
… there’s multiple that are just editorial that we can just skip.

2.2. other PRS.

Manu Sporny: These are editorial, we can skip them – https://github.com/w3c/vc-data-model/pull/849 https://github.com/w3c/vc-data-model/pull/850 https://github.com/w3c/vc-data-model/pull/851.

2.3. add section to differentiate between contexts and credential Schemas (pr vc-data-model#847)

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

Manu Sporny: The only other one is 847.
… I think there was a question here and I didn’t understand the resolution.

David Chadwick: I thought kdenhartog description was too narrow.
… I’d like the explanation to cover both.
… when I read the original email it seemed to imply it was not only in the context of JSON-LD, and I think that’s the only concern there.

Manu Sporny: My reading is that it covers all of that already.
… so I’m confused.
… since it does cover JSON, JSON-LD, and SHACL.
… so my question is what should it do differently?.

David Chadwick: If you look at the text virtually every paragraph is about JSON-LD.
… so I don’t object to it being about JSON-LD so I was hoping it would cover JSON only as well.
… so I would like to specify that context are there to cover “aliases”.

Kyle Den Hartog: I’m happy if you provide some additional comments like that so I can put that in. When I read your description, it seemed like a much larger thing - paragraph or two talking about JSON, since it wasn’t clear what you wanted in that text, easier to merge this and then have you add that text. If you’re just talking about a sentence or two, then we can add it..
… However, if you have some suggested text, I can do that..

David Chadwick: The other thing I thought might be useful is type here.
… so I thought it would be useful to have another sentence about that.
… It might also be useful to bring in type… how does type differ from schema if the type tells you, why do you need schema?.

Kyle Den Hartog: That would be useful, mainly because type has a strong binding to how JSON-LD works and if you don’t use types, things break. It should be useful in the context of typing having impact on semantics of data objects to data being dropped. With JSON Schema, you don’t run into those problems, static checking of data model. There is usefulness in describing that, I will see if I can add something..
… Are you ok with that?.

Dave Longley: type and context provide semantics – schema can be used to enforce shape.

David Chadwick: All we can do is try and make it better?.
… please make it noted that I’ll add a clarifying sentence or two to this text.

Action #1: add a sentence or two to PR https://github.com/w3c/vc-data-model/pull/847. (David Chadwick)

Brent Zundel: Any other comments on this?.
… we didn’t cover V1.1 issues and I believe all but one are assigned.
… if you have one assigned please work on it.
… reminder next meeting is January 12th of next year.
… thanks everyone for coming.
… and thanks for the work you’re doing and happy holidays.

3. Action Items