20:08:30 <RRSAgent> RRSAgent has joined #vcwg
20:08:30 <RRSAgent> logging to https://www.w3.org/2021/12/15-vcwg-irc
20:08:41 <brent> zakim, start the meeting
20:08:41 <Zakim> RRSAgent, make logs Public
20:08:43 <Zakim> please title this meeting ("meeting: ..."), brent
20:08:58 <rgrant> rgrant has joined #vcwg
20:09:12 <brent> meeting: Verifiable Credentials Working Group
20:09:37 <brent> chair: Brent Zundel
20:09:40 <cel> present+
20:09:59 <brent> present+
20:09:59 <dlongley> present+
20:10:03 <shigeya> present+
20:10:03 <manu> present+
20:10:09 <kdenhartog> present+
20:10:20 <dlongley> present+ DavidC
20:10:32 <kdenhartog> scribe+
20:10:54 <brent> Topic: VCWG Draft Charter
20:11:01 <brent> https://github.com/w3c/vc-wg-charter/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
20:11:10 <kdenhartog> brent: is there anything that people would like to add to the agenda? .... none heard
20:11:27 <kdenhartog> brent: first topic is Draft charter issues
20:11:33 <brent> subtopic: https://github.com/w3c/vc-wg-charter/issues/24
20:11:38 <kdenhartog> ... first issue is number 24
20:11:55 <kdenhartog> ... last time we said we'd close it so I move to close the issue any opposed?
20:12:12 <kdenhartog> ... none heard going to close this one
20:12:23 <kdenhartog> ... next issue is number 21
20:12:24 <DavidC> I did tell Mike last week about this
20:12:24 <brent> subtopic: https://github.com/w3c/vc-wg-charter/issues/21
20:12:49 <kdenhartog> ... manu I believe you have a PR open for this. Can you tell us about this?
20:12:53 <manu> There is a PR open to address this issue: https://github.com/w3c/vc-wg-charter/pull/32
20:13:04 <kdenhartog> manu: yeah there's a PR open for this
20:13:13 <rgrant> present+
20:13:36 <kdenhartog> ... 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
20:13:53 <kdenhartog> ... this means JWTs/LD-Proof and any other mechanism would be inscope as well
20:14:02 <kdenhartog> ... including things like JCS and other things like that
20:14:18 <kdenhartog> ... we can't invent new crypto here but can focus on how things get packaged up
20:14:21 <brent> q+ to ask about JWP
20:14:35 <kdenhartog> ... by calling this LD Integrity it's not accurately representing this
20:15:02 <brent> ack brent
20:15:02 <Zakim> brent, you wanted to ask about JWP
20:15:09 <kdenhartog> ... 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
20:15:19 <dlongley> q+
20:15:29 <kdenhartog> brent: Assuming the JWP work gets further along would you expect we could use that in here?
20:15:29 <brent> ack dlongley
20:16:00 <manu> q+ to note how we protect against that bad thing.
20:16:09 <kdenhartog> dlongley: 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
20:16:10 <kdenhartog> q+
20:16:14 <brent> ack manu
20:16:14 <Zakim> manu, you wanted to note how we protect against that bad thing.
20:16:30 <kdenhartog> manu: One thing we do to conteract that is to link specifically to the linked data proof spec
20:16:44 <kdenhartog> ... I can check in CCG about renaming but this should make it clear that we want it in scope
20:17:07 <kdenhartog> ... I'll add some clarifying language to explicitly list the things in scope
20:17:12 <manu> scribe+
20:17:14 <brent> ack kdenhartog
20:17:45 <manu> kdenhartog: 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?
20:17:46 <manu> q+
20:17:51 <brent> ack manu
20:18:11 <kdenhartog> manu: I believe the way it's scoped now is that we say all of the suites are non-normative
20:18:31 <kdenhartog> ... one second that might not be true
20:18:38 <kdenhartog> ... we don't say anything about the suites themselves
20:18:50 <kdenhartog> ... I think the intent was to note define specific suites
20:19:04 <kdenhartog> ... we'd publish notes and test suites for it but not define them normatively
20:19:08 <dlongley> -1 we shouldn't constrain ourselves to not being able to define any suites
20:19:11 <kdenhartog> ... but that might be the wrong way to go about it
20:19:12 <kdenhartog> q+
20:19:13 <dlongley> q+
20:19:18 <brent> ack kdenhartog
20:20:22 <manu> kdenhartog: I'm concerned that suites are being develoepd now in a way that makes it problematic.
20:20:47 <manu> kdenhartog: 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.
20:20:49 <brent> ack dlongley
20:20:53 <manu> q+ to specify registries.
20:21:09 <kdenhartog> dlongley: I don't think we should constrain ourselves to not being able to address these suites
20:21:33 <kdenhartog> ... 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 thesse
20:21:43 <kdenhartog> ... and that might avoid some of the issues that Kyle is bringing up
20:22:08 <brent> ack manu
20:22:08 <Zakim> manu, you wanted to specify registries.
20:22:11 <kdenhartog> ... we might be able to handle this, but my main point is that I don't think we should constrain ourselves to solve that
20:22:20 <kdenhartog> manu: There is a VC extension registry
20:22:37 <kdenhartog> ... I think we're probably going to end up making that in scope
20:23:00 <kdenhartog> ... I'd imagine doing all that to document that things are in process
20:23:16 <kdenhartog> ... to dlongley point I think the big question is how normative do we want to get about the suites
20:23:30 <kdenhartog> ... I think the idea was that we'd define a bunch of the suites as notes
20:23:49 <kdenhartog> ... part of the DID-Core objections are that you should have just taking things to CR and not gone further
20:24:11 <kdenhartog> ... so if we take that into consideration for this chartering we may follow a similar model
20:24:25 <kdenhartog> ... where we only take a suite to CR without saying we're going to work on all of these suites normatively
20:24:50 <kdenhartog> ... 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
20:25:11 <kdenhartog> ... this would allow us to make it clear that we're not overscoping our work
20:25:24 <kdenhartog> ... so we need to be careful about what we say we're going to do
20:25:55 <kdenhartog> ... 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
20:26:26 <kdenhartog> brent: How common is it for people to say we're only going to CR only?
20:26:43 <kdenhartog> manu: Not common it's only for CSS typically and other perma working groups
20:26:54 <dlongley> q+
20:26:59 <brent> ack dlongley
20:27:11 <kdenhartog> brent: with just my hat on I'm not sure going to only CR makes sense
20:27:34 <kdenhartog> dlongley: +1 I think it's best to say we're going to handle only a few suites
20:27:37 <manu> q+ to say, we can do that -- we'll focus on Ed25519 and BBS+.
20:27:49 <kdenhartog> Saying going only to PR seems like people could object to that
20:27:50 <brent> ack manu
20:27:50 <Zakim> manu, you wanted to say, we can do that -- we'll focus on Ed25519 and BBS+.
20:28:04 <dlongley> q+
20:28:07 <kdenhartog> manu: I think we could do that for Edwards curve but could be trickier for BBS+
20:28:29 <brent> q+ to respond bbs
20:28:33 <brent> ack dlongley
20:28:36 <kdenhartog> ... we'd need CFRG approval before we could reference them normatively and succeed in REC stage
20:28:41 <TallTed> TallTed has joined #vcwg
20:29:00 <brent> ack brent
20:29:00 <Zakim> brent, you wanted to respond bbs
20:29:09 <kdenhartog> dlongley: if we go with something a bit more general we could describe how you use a suite without having to specifically normatively define BBS+
20:29:32 <kdenhartog> brent: There's active work at DIF and they expect to have something to submit to the CFRG first quarter next year
20:29:33 <kdenhartog> q+
20:29:49 <kdenhartog> manu: Is there something we can point out?
20:29:58 <brent> ack kdenhartog
20:29:59 <kdenhartog> ... even if it's an ID that intends to go to CFRG
20:30:36 <brent> current draft of BBS+: https://identity.foundation/bbs-signature/
20:30:45 <TallTed> present+
20:30:59 <manu> q+ on argument around redundancy.
20:31:13 <brent> ack manu
20:31:13 <Zakim> manu, you wanted to comment on argument around redundancy.
20:31:19 <TallTed> TallTed has changed the topic to: Meeting Agenda 2021-12-15: https://www.w3.org/events/meetings/ff0d4cb2-c3fd-4d36-9b16-8f182efe4aa0/20211215T150000#agenda
20:31:20 <brent> zakim, who is here?
20:31:20 <Zakim> Present: cel, brent, dlongley, shigeya, manu, kdenhartog, DavidC, rgrant, TallTed
20:31:22 <Zakim> On IRC I see TallTed, rgrant, RRSAgent, Zakim, brent, DavidC, kdenhartog, loganporter, dmitriz, tzviya, shigeya, agendabot, juancaballero, cel[m], stonematt, dlehn, hadleybeeman,
20:31:22 <Zakim> ... bigbluehat, dlongley, manu, cel, wayne, rhiaro
20:31:39 <brent> present+ loganporter
20:31:55 <kdenhartog> manu: I think the response to the JWTs handling all of this is that you can't do multiple signatures together with JWTs today
20:32:11 <kdenhartog> ... the other issue is that we have a parallel RDF canonicalization WG
20:32:30 <kdenhartog> ... and that group is expecting the ability to not have to use only JWTs only
20:32:50 <kdenhartog> ... and with people already using this I think we have sufficient counter arguments for these things being brought up
20:32:57 <kdenhartog> ... and we've documented all that stuff
20:33:10 <kdenhartog> ... I think we're ok, but we'll see how it goes
20:33:12 <brent> q?
20:33:30 <kdenhartog> kdenhartog: I think that's a sufficient argument
20:33:41 <kdenhartog> manu: I guess the question is what do we want to do for this.
20:33:59 <kdenhartog> ... Do we want to update the description for this PR and describe focusing on Edwards and BBS+
20:34:25 <kdenhartog> ... and because this is a normative item we can then decide as a WG to decide how we want to split up that work
20:34:49 <kdenhartog> ... we'd have one description to define how to express VC integrity with a specific focus on Ed25519, BBS+, and JWTs
20:35:07 <DavidC> +1
20:35:09 <dlongley> +1 to what manu just said and to pointing to this discussion saying we meant to define LD suites
20:35:18 <kdenhartog> ... 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
20:35:30 <kdenhartog> brent: So what needs to change for that to happen?
20:35:57 <kdenhartog> manu: I need to change this PR to include it and I'll link to draft state input documents to cover this
20:36:04 <brent> subtopic: https://github.com/w3c/vc-wg-charter/issues/30
20:36:07 <kdenhartog> brent: If there's nothing else let's move to the next issue
20:36:58 <manu> kdenhartog: 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.
20:37:12 <manu> kdenhartog: Otherwise, ok to leave it out of scope and we can tackle it in time.
20:37:54 <manu> brent: Do we have to be specific about this being in scope?
20:38:25 <manu> kdenhartog: 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.
20:38:38 <manu> kdenhartog: Maybe when we list LDI, we specify multi proof sets?
20:38:59 <manu> kdenhartog: When we were talking about LDP, we were looking at specific proof suites, Edwards and BBS+ for multiproof systems.
20:39:00 <manu> q+
20:39:09 <brent> ack manu
20:39:13 <kdenhartog> manu: I'm trying to get a link
20:39:16 <DavidC> q+
20:39:21 <manu> https://w3c-ccg.github.io/ld-proofs/#multiple-proofs
20:39:30 <kdenhartog> ... for the LDP spec which includes section 7 with multiple proofs
20:39:41 <kdenhartog> ... but I'm not sure this addresses what you were talking about
20:40:34 <manu> kdenhartog: 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.
20:41:06 <manu> kdenhartog: 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
20:41:08 <manu> q+
20:41:12 <brent> ack DavidC
20:41:24 <dlongley> input doc on ld proofs should give us the space we need to work on multiple proofs on a single document
20:41:33 <kdenhartog> DavidC: Just two points, one is the current text is that appendix A refers to validation
20:41:35 <manu> agree, we can always add examples.
20:41:38 <kdenhartog> ... and this should say verification
20:42:05 <kdenhartog> ... 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
20:42:21 <kdenhartog> ... since one way of resolving this is to rely on a proof of possession in all of these
20:42:44 <kdenhartog> ... Do people remember this discussion and how we had two sperate views for this? I think that discussion would feed well into this
20:42:46 <brent> ack manu
20:43:15 <kdenhartog> manu: 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
20:43:21 <kdenhartog> ... so I think we're in safe territory
20:43:42 <kdenhartog> ... with respect to what DavidC I vaguely remember the discussion but none of the details
20:43:51 <kdenhartog> ... maybe the multiproof stuff brings that to the fore
20:43:59 <kdenhartog> ... and in a fairly normative way
20:44:02 <kdenhartog> q+
20:44:08 <dlongley> +1 multiproof in scope and talking about ID relationships and establishing proofs are in scope
20:44:09 <brent> ack kdenhartog
20:44:42 <manu> kdenhartog: 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.
20:45:24 <brent> subtopic: https://github.com/w3c/vc-wg-charter/issues/19
20:45:32 <kdenhartog> brent: One other issue to cover for this
20:45:56 <kdenhartog> shigeya: I posted examples yesterday for this and filed a PR for this and got feedback from Kyle and Manu
20:46:22 <kdenhartog> ... my proposal has two schemes to do translation and I think now what I'm trying to do is understand it better
20:46:33 <kdenhartog> ... the thing that I was wondering how to express new work items in the charter
20:46:44 <brent> related PR https://github.com/w3c/vc-wg-charter/pull/33/files
20:46:46 <kdenhartog> ... and I'm not sure if it's good now
20:47:15 <kdenhartog> ... If certain cituations we may want to have some sort of table like list to translate both the key and value
20:47:26 <kdenhartog> ... and I wanted to get further feedback on this
20:47:27 <kdenhartog> q+
20:47:33 <brent> ack kdenhartog
20:47:42 <manu> kdenhartog: Just to comment on the specifics of whether this is adequate.
20:48:14 <manu> kdenhartog: 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.
20:48:28 <kdenhartog> brent: any other comments, questions, concerns?
20:48:40 <kdenhartog> brent: Those were the VCWG draft charter issues
20:48:51 <kdenhartog> ... we've got about 10 minutes left for the other parts of the agenda
20:48:54 <brent> Topic: Review PRs
20:48:56 <kdenhartog> ... next topic is to review some PRs
20:49:02 <brent> https://github.com/w3c/vc-data-model/pulls?q=is%3Apr+is%3Aopen+label%3A%22v1.1+%28editorial%29%22+sort%3Aupdated-asc
20:49:17 <kdenhartog> Link to those are here and we've got 5 open
20:49:28 <kdenhartog> ... Manu can I turn this over to you?
20:49:28 <manu> https://github.com/w3c/vc-data-model/pull/780
20:49:38 <kdenhartog> manu: We've got one we should be able to resolve very quickly
20:49:39 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/780
20:49:50 <kdenhartog> ... we've tried so many things and we've landed on just deleting the subtitle
20:50:06 <kdenhartog> ... the suggestion is to just remove it and that seems to have the best consensus
20:50:14 <kdenhartog> ... no objections to this solution
20:50:21 <kdenhartog> ... so this is a final call for objections
20:50:27 <kdenhartog> ... if not I'll merge this on the call
20:50:33 <kdenhartog> brent: Any objections?
20:50:36 <kdenhartog> ... none heard
20:50:45 <kdenhartog> manu: That was 6 months in the making :)
20:51:02 <kdenhartog> manu: there's multiple that are just editorial that we can just skip
20:51:09 <brent> subtopic: other PRS
20:51:11 <manu> 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
20:51:45 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/847
20:51:51 <kdenhartog> manu: The only other one is 847
20:52:10 <kdenhartog> ... I think there was a question here and I didn't understand the resolution
20:52:12 <kdenhartog> q+
20:52:24 <brent> ack kdenhartog
20:52:33 <kdenhartog> q-
20:52:43 <kdenhartog> DavidC: I thought kdenhartog description was too narrow
20:52:50 <kdenhartog> ... I'd like the explanation to cover both
20:52:59 <manu> q+ to note it talks about JSON Schema as well?
20:53:15 <kdenhartog> .. when I read the original email it seemed to imply it was not only in the context of JSON-LD
20:53:19 <brent> ack manu
20:53:19 <Zakim> manu, you wanted to note it talks about JSON Schema as well?
20:53:26 <kdenhartog> ... and I think that's the only concern there
20:53:35 <kdenhartog> manu: My reading is that it covers all of that already
20:53:40 <kdenhartog> ... so I'm confused
20:53:52 <kdenhartog> ... since it does cover JSON, JSON-LD, and SHACL
20:54:02 <kdenhartog> ... so my question is what should it do differently?
20:54:36 <kdenhartog> DavidC: If you look at the text virtually every paragraph is about JSON-LD
20:54:41 <manu> q+
20:54:41 <kdenhartog> q+
20:54:44 <manu> q-
20:55:01 <kdenhartog> ... so I don't object to it being about JSON-LD so I was hoping it would cover JSON only as well
20:55:22 <kdenhartog> ... so I would like to specify that context are there to cover "aliases"
20:55:26 <brent> ack kdenhartog
20:56:11 <manu> kdenhartog: 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.
20:56:18 <manu> kdenhartog: However, if you have some suggested text, I can do that.
20:56:38 <kdenhartog> DavidC: The other thing I thought might be useful is type here
20:56:47 <kdenhartog> ... so I thought it would be useful to have another sentence about that
20:56:50 <manu> DavidC: 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?
20:56:50 <kdenhartog> q+
20:56:57 <brent> ack kdenhartog
20:57:45 <manu> kdenhartog: 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.
20:57:56 <manu> kdenhartog: Are you ok with that?
20:58:02 <dlongley> type and context provide semantics -- schema can be used to enforce shape
20:58:27 <kdenhartog> DavidC: All we can do is try and make it better?
20:58:43 <kdenhartog> ... please make it noted that I'll add a clarifying sentence or two to this text
20:58:53 <brent> action: DavidC will add a sentence or two to PR https://github.com/w3c/vc-data-model/pull/847
20:59:10 <kdenhartog> brent: Any other comments on this?
20:59:24 <kdenhartog> ... we didn't cover V1.1 issues and I believe all but one are assigned
20:59:31 <kdenhartog> ... if you have one assigned please work on it
20:59:42 <kdenhartog> ... reminder next meeting is January 12th of next year
20:59:47 <kdenhartog> ... thanks everyone for coming
21:00:04 <kdenhartog> ... and thanks for the work you're doing and happy holidays
21:00:42 <brent> zakim, end the meeting
21:00:42 <Zakim> As of this point the attendees have been cel, brent, dlongley, shigeya, manu, kdenhartog, DavidC, rgrant, TallTed, loganporter
21:00:44 <Zakim> RRSAgent, please draft minutes
21:00:44 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/15-vcwg-minutes.html Zakim
21:00:47 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
21:00:51 <Zakim> Zakim has left #vcwg
21:00:55 <brent> rrsagent, bye
21:00:55 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2021/12/15-vcwg-actions.rdf :
21:00:55 <RRSAgent> ACTION: DavidC will add a sentence or two to PR https://github.com/w3c/vc-data-model/pull/847 [1]
21:00:55 <RRSAgent>   recorded in https://www.w3.org/2021/12/15-vcwg-irc#T20-58-53