19:54:26 RRSAgent has joined #vcwg 19:54:26 logging to https://www.w3.org/2022/12/07-vcwg-irc 19:56:12 brent has changed the topic to: Meeting Agenda 2022-12-07 https://www.w3.org/events/meetings/c5abcc63-337b-4ebb-97af-7cc2fb63de11/20221207T150000 19:56:22 zakim, start the meeting 19:56:22 RRSAgent, make logs Public 19:56:23 please title this meeting ("meeting: ..."), brent 19:56:34 Meeting: Verifiable Credentials Working Group Telco 19:56:47 Chair: Brent Zundel 19:56:52 present+ 19:57:42 mprorock has joined #vcwg 20:00:17 markus_sabadello has joined #vcwg 20:00:44 DavidC has joined #vcwg 20:00:54 present+ 20:01:28 present+ 20:01:57 present+ 20:02:30 present+ 20:02:31 JoeAndrieu has joined #vcwg 20:02:47 jeremie has joined #vcwg 20:02:54 Orie has joined #vcwg 20:02:55 present+ 20:02:57 present+ 20:03:25 Brian has joined #vcwg 20:04:06 decentralgabe has joined #vcwg 20:04:10 present= 20:04:13 TallTed has joined #vcwg 20:04:21 present+ 20:04:45 przemek has joined #vcwg 20:05:13 dwaite has joined #vcwg 20:05:21 scribe+ 20:05:30 present+ 20:05:39 present+ 20:05:42 present+ 20:06:05 brent: starting with an agenda review...announcing the next F2F meeting. asking for status updates for work items. review PRs. bulk of the meeting: StatusList2020 as a possible work item for the group. if time..issue discussion 20:06:13 brent: any additions or changes from the group? 20:06:14 q+ 20:06:23 ack manu 20:06:55 present+ 20:07:15 manu: don't know how to say this...we'll get to it with pull requests. related to the @context discussion. as an editor, difficult to have PRs with this out there. have a suggestion for the editors to 'get unstuck'... can talk to when we get to PRs. "how do we get to progress in the face of a big unknown hanging over the group? 20:07:31 brent: any first timers, introductions or reintroductions? 20:07:58 Brian: Brian Richter. have a company Aviary Tech. in the CCG + DIF. first time here as an Invited Expert. 20:08:40 brent: f2f meeting for the VCWG. in Feb, 14-16 in recognition that Feb is still winter. planning to hold it in Miami 20:08:55 brent: ... please jump on if you have any questions, all details we have at this point 20:09:07 Topic: Work Item status updates/PRs 20:09:09 q+ 20:09:20 ack manu 20:09:20 brent: Work item status updates & PRs. please jump on the queue if you have an update 20:09:33 https://github.com/w3c/vc-data-model/pulls 20:09:43 subtopic: https://github.com/w3c/vc-data-model/pull/969 20:10:17 manu: VCDM first. two PRs - one is nonTransferrable property. do not merge is listed on it. some discussion, but need more. changes of it making it in are fairly slim. don't know what the group should do with prs like this. can leave it open. hasn't been much progress 20:10:21 subtopic: https://github.com/w3c/vc-data-model/pull/987 20:11:04 ... next item: 987; adds presentationSchema, by David Chadwick. good discussion. still some things being asked for. 3 people continuing to request changes. expect David to keep engaging to move it forward 20:11:18 https://github.com/w3c/vc-data-integrity/pulls 20:11:33 s/changes of it making it in/chances of it making it in/ 20:11:52 ... other than that, no new PRs. VC data integrity: no new pull requests. difficult to write PRs when the topic of "make @context optional" hangs over the group. need to find consensus and move on 20:11:59 selfissued has joined #vcwg 20:12:06 present+ 20:12:43 ... other option - if no objections from the group - let's assume we don't have consensus on making @context optional in future PRs, at least I raise, and will run on that basis until we have consensus on that item. putting that to the group - if no objections, and assuming @context is not optional, we can get back to raising PRs 20:12:50 ... questions on that approach? 20:13:05 q+ 20:13:06 +1 to proceed with current PRs as if we don't have consensus on making `@context` optional (as we don't.. so just an acknowledgment of present reality) 20:13:16 ack DavidC 20:13:32 q+ 20:13:58 DavidC: give people a heads up. a number of different issues that overlap with one. that is - what is the actual data model? what is the credential metadata? what is the proof? how are they related? quite a biggie. affects a lot of the properties, i.e. the issuanceDate - is it a property of the proof or the credential 20:14:06 ack Orie 20:14:46 mkhraisha has joined #vcwg 20:15:09 Orie: agree with what DavidC said. have 2 components: core data model and securing the core data model formats. has big impacts on securing the core data model formats. coming back to Manu's point. even if we proceed with making PRs in the core data model assuming the TR looks as it is today, we will still have these issues come up in the 'securing the core data model' for reasons DavidC mentioned. 20:15:12 +1 orie 20:15:34 ... helpful to have a special topic call about "where metadata is present in the core data model" and securing the core data model 20:15:45 Phil has joined #vcwg 20:15:47 brent: heard no one speak against your suggestion. clear to proceed as you intend 20:15:53 manu: thank you 20:16:08 brent: other work items to give status updates or PRs? 20:16:27 Orie: no additional prs in either of the work items that I am an editor of (JsonWebSignature2020, VC-JWT) 20:16:41 Topic: Status List 2020 20:16:57 q+ to provide some background for the group 20:17:01 present+ 20:17:15 subtopic: https://github.com/w3c/vc-data-model/issues/974 20:17:19 brent: move to remaining topic. StatusList2020. have an issue open ^ 20:17:26 ack manu 20:17:26 manu, you wanted to provide some background for the group 20:18:08 manu: providing background. the VCDM has a property called 'credentialStatus' purpose is to tell you what the status of the credential is -- revoked, suspended, something else. this mechanism allows an issuer to issue a cred and still have the ability to say the credential is still valid or no longer valid 20:18:38 q+ to talk about how this helps us achieve one of our group goals 20:18:39 ... can think of something like an employeeId credential, issued to an employee - they have it in their mobile phone, at some point they change jobs away from that employer. the issuer then revokes the credential saying 'they are no longer at the company' 20:19:03 Status List 2021: https://w3c-ccg.github.io/vc-status-list-2021/ 20:19:26 ... we did not define a concrete representation to do this in v1 of the work. there is an item VCStatusList2021 incubated in the CCG link in chat. a number of implementations. people seem to be OK with the latest version of it. we do not expect drastic changes to the spec at this point. there is a test suite for the spec. 20:19:48 Karen has joined #vcwg 20:19:55 ... this issue suggests adopting the status list 2021 from the CCG. suggested a month ago, more depth today 20:19:58 ack brent 20:19:58 brent, you wanted to talk about how this helps us achieve one of our group goals 20:20:46 q+ to agree with "it's fine, it's not great" :) 20:20:54 q+ 20:21:02 q- later 20:21:11 brent: properties in the VCDM that do not have a normative way to fulfill. do not love statuslist2020, but it is fine. people feel similarly. solid and basic way of providing what a credential status is. char hat off -- in full support of us considering this as a work item. chair hat on -- point of this is to decide whether it is a work item 20:21:14 q+ 20:21:18 q- later 20:21:19 ... what do you think about bringing it in, or what that means? 20:21:23 ack mprorock 20:21:44 just to be clear, the issue says "StatusList2021" (not 2020) 20:22:14 mprorock: I am in the "it's fine" camp, it's not ideal. have not seen anything practical, better, more widely deployed, tested. natural if we are going to bring in a status list ... this is what 2021 enables. i have to reiterate my hatred for dates in titles 20:22:20 Link to current test suite: https://w3c-ccg.github.io/status-list-2021-test-suite/ 20:22:25 brent: apologies, it is StatusList2021 20:22:30 ack Orie 20:23:09 Orie: #1 - we have to define at least one of these things to keep the credential status property in the data model. been said, but it's important. have a number of concerns with this work item. have not seen a version that supports vc-jwt or other security assertion formats 20:23:11 q+ 20:23:43 q+ 20:23:57 q+ to say the work is there for us to do regardless of whether we are bringing this in now or not 20:23:59 ... this item like so many other items, assumes a core data that is subject to dispute. not appropriate to bring it in at this time. expands the scope of the group, new work. not sure how to resolve issues with this suite if @context being optional is handled in a different manner. appreciate Manu's comment, but do not feel comfortable until it's resolved 20:24:01 ack manu 20:24:01 manu, you wanted to agree with "it's fine, it's not great" :) 20:24:45 manu: supportive of what Orie said. want to roll back to "it's fine but not great." everyone is lukewarm about it. we want a more aggressive privacy option. been viewed as 'adequate' not amazing. effectively good enough. 20:24:49 +1 to StatusList2021 being "adequate, but not great" :) 20:25:18 ... we could do better in the future if we were willing to do more advanced crypto. people have not reacted violently against 2021's herd privacy approach. just ok - but that's fine 20:25:25 scribe+ 20:25:32 ack decentralgabe 20:25:48 decentralgabe: I just wanted to respond to Orie's comment, we do have an implementation that works w/ VC-JWT and I can add an example to existing draft if that's helpful. 20:25:53 scribe+ 20:25:53 ack DavidC 20:26:12 q+ 20:26:17 q+ 20:26:28 DavidC: coming back to the point last time i spoke. big issue about the data model. credentialStatus should not be a part of the data model, because it's bound to a proof. cannot have it bound...the status should be a part of the proof and not bound to the core data model 20:26:30 ack brent 20:26:30 brent, you wanted to say the work is there for us to do regardless of whether we are bringing this in now or not 20:26:37 q+ in case manu doesnt say what i plan on saying 20:26:54 q+ to make a statement in case manu doesnt say what i plan on saying 20:27:06 brent: the work is there for us to do regardless of whether we bring it in now. up to the working group whether we bring it in now. not bringing it in now doesn't mean it's not there for us to do 20:27:08 ack manu 20:27:39 q+ to talk to David's question 20:27:57 manu: to respond to DavidC: no it has nothing to do with the proof. it makes more sense...credentialStatus has to do with the credential itself, not about the proof. it is about the fact that you are issued a uni diploma, and whether it is valid or not, regardless of cryptographic protection on any of the data. business rules, not cryptography 20:27:58 +1 to manu 20:27:59 ack Orie 20:28:44 Orie: agree current interpretation is consistent with what Manu said. DavidC may be onto something. if not to be handled as business validation logic, could be handled as part of the proof. could be relevant to the proof section, not credential metadata. comes back to "what is the core data model" do we have a clear understanding of the differences b/w these things. 20:29:08 q+ to point out that in order to decide what direction to take StatusList2021 in the group, it would need to be in the group. 20:29:23 q- 20:29:25 q+ 20:29:31 ... current StatusList2021 - it is a property of the credential. after credential verification of the status list, a verifier can dereference and do checking. it is a business process the verifier could ignore (e.g. check signature, not status). 20:29:44 seems the question is: "are you revoking a digital signature ... or a credential?" (or could there be *both* of these things? and is that too complicated?) 20:30:26 +1 to Orie where credential status is handled the same regardless of securing format 20:30:30 +1 20:30:31 ... if checking the proof/status is a part of the verification process. in Jose/cose use the crit header. ... how are we going to address these scenarios if we have more than 1 core data model or security format? want credential status checking to be handled consistently. data integrity proofs and jose/cose formats around the same core data model. not clear the best path for the item 20:30:36 ack JoeAndrieu 20:30:36 JoeAndrieu, you wanted to talk to David's question 20:31:56 JoeAndrieu: want to elevate DavidC's point to a conversation we haven't fully engaged with yet. What is a "Credential" vs "Verifiable Credential." we have a disconnect. my sense - a credential without a proof is a "credential" it is in json and maybe a proto-vc. with a proof it's a verifiable credential. there's another thing in the real world called credentials that people use VCs to represent (e.g. a bachelors degree) 20:32:03 +1 Joe 20:32:10 +1 to Joe 20:32:36 ... has nothing to with a VC. there is a weird semantic disconnect. don't know where we should come down. in the JFF plugfest, people created the id of the cred as the real id, not the id of the digital object 20:32:42 ack brent 20:32:42 brent, you wanted to point out that in order to decide what direction to take StatusList2021 in the group, it would need to be in the group. 20:32:49 Q+ 20:33:05 brent: to StatusList2021 - we can decide the direction if we bring it in as a work item 20:34:11 yes, it's different in VCs -- VCs aren't x509s ... 20:34:11 ack DavidC 20:34:17 DavidC: thanks Manu for point of CredStatus could be the status of the degree. want to point out in x509, revocation is entirely with the digital signed cert. says we need to have 2 different representations (David Longley hinted in chat). still needs to be a cryptographic revocation list, e.g. if a university lost its private key the cred could still be valid. need two separate revocation mechanisms 20:34:18 ack Phil 20:34:22 q+ to note that StatusList2021 could serve both purposes! :) 20:35:34 Phil: Phil Long from T3. from the edu perspective Joe described. in edu, has never been an opportunity for a cred to be shared with anybody at all. if it is an "official credential." the only source of truth has been the institution itself/registrar. any time anyone has a presentation about their degree or transcript to a 3rd party it needs to come from the institution/registrar, since they're the only one's considered author 20:35:34 itative 20:35:42 @manu it could if there is flag to say which revocation it is referring to 20:36:02 That flag already exists, DavidC :) 20:36:21 @manu. Excellent!! 20:36:26 It's called "statusPurpose" -- https://w3c-ccg.github.io/vc-status-list-2021/#statuslist2021entry 20:36:43 ... credentials are making this tamper evident, which allows this interaction to change. conversation with national student clearing house. they agreed to put a signature on a degree VC which is a 'sufficient verification of truth' and does not need to come from an institution itself. distinction is important - verifiable means you can hand it to a 3rd party. treated as authentic and original 20:36:47 To be clear, I disagree that this is something that should exist in the proof, but we can have that discussion later :) 20:36:50 ack manu 20:36:50 manu, you wanted to note that StatusList2021 could serve both purposes! :) 20:37:47 manu: responding to DavidC question about cred or proof. StatusList2021 is agnostic to where it is placed. just a status list. could be about a credential, proof, sheep. doesn't matter where it shows up. it is just a bit field and you flip bits. though, I disagree you should put this in proof metadata. if the group wants to do this, it can serve both purposes 20:39:05 q+ 20:39:07 brent: is the work item in the scope of the charter? is it supported by at least 3 participants from different organizations? yet to poll. should we adopt it? does not require strong consensus. will not be taking a proposal today to bring it in as a work item. may do so during the next call. any other questions/comments/concerns? 20:39:17 ack Orie 20:39:28 Orie: we ran a proposal to adopt ecdsasignature2020 a week ago, did we follow the process then? 20:39:56 brent: 2 weeks ago. in response to the resulting conversation about that work item..resulting in the chairs establishing this process. the process just mentioned did not exist during that conversation. it came into being as a result 20:40:01 q+ 20:40:08 ack TallTed 20:40:55 TallTed: no strong feelings on the work item. probably should be taken up. something like it will be necessary. another one will serve roughly the same purpose and we'll have to do it. abundantly clear to me and the people in this group that we have some glaring issues with the existing data model and what is really going on 20:41:35 ... as we were discussing a few weeks ago re: validFrom/until attributes, we have 4 dates instead of 2, but may be 6 or 8. tracks with crypto/payload validity. don't have a strong enough picture in my head to go down the list 20:42:39 ... brief back and forth with DavidC. basic stick figure diagrams of the cred metadata, the Credential, the proof, proof metadata. not the only 4 we need to talk about. need to spend some focused time on that. could be a zoom whiteboard or F2F - open to ideas. sooner we do it the better off everyone will be. the result will be breaking changes 20:43:00 Topic: Issue Discussion 20:43:10 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc 20:43:20 brent: next topic, issue discussion. sorted in order we will be covering them 20:43:34 subtopic: https://github.com/w3c/vc-data-model/issues/931 20:43:42 ... first issue #931, representing multi subjects in the data model 20:44:04 q+ 20:44:13 ack TallTed 20:44:22 decentralgabe: may be better suited to have a discussion than an issue 20:44:36 TallTed: no please. discussion is arguable worse. could be more confusing than just reading a thread of an issue. 20:44:43 q+ 20:46:06 brent: completely forgot that i wanted to talk about how we wanted to start using discussions. we are planning on moving some issues to the 'discussions' tab and making more use of that. see how it goes to move those issues forward. the editors have the authority to make that decision (move to discussion). the issue should be a discussion/question, not proposing specific solutions. once a discussion develops to a certain poin 20:46:06 t, a related issue could be raised 20:46:07 q+ 20:46:20 q+ to support "we need another place for open, non-concrete conversations" 20:46:37 ... to propose specific changes to the data model. should have said that earlier. considering this as a tool. let's talk about this for a couple minutes. 20:46:46 subtopic: discussion 20:46:47 ... will create another sub topic to free us 20:46:52 ack brent 20:46:55 ack TallTed 20:47:22 TallTed: one of the big failures of this 'discussion' thing github made is that it is not easy to see the things added to the 'discussion' since the last time you looked at it. no useful indicator of 'i read this but not that' 20:48:32 ... in order to track the whole discussion you need to scroll down slowly and see what replied have been added. i know issues dont thread the discussion and it is challenging to keep up with that. nothing will keep up with ntp did if you had a good news reader. this is one of the worst re-inventions i've seen - and i've seen a lot. i will try to participate if things go there...will be a headache. curmudgeon out! 20:48:34 ack manu 20:48:34 manu, you wanted to support "we need another place for open, non-concrete conversations" 20:49:13 "meta issues" == make a meta tag 20:49:22 +1 to TallTed, was going to suggest the same thing 20:49:39 manu: I think what Ted is saying has value. issues raised aren't concrete issues on the spec. not exactly questions. more like philosophical conversations without changes in the spec. to boil it down - would you disagree with marking something as a "conversation" Ted? may not result in anything actionable 20:49:41 q+ 20:50:17 +1 a "conversation" tag on some issue(s) would likely work 20:50:24 ... the thread to date may not result in anything actionable, but people should talk until it is clear there is something actionable there. the editors have had a hard time looking at these issues, saying "i want that conversation to continue, but it's so nebulous/vague, have no idea where it's going, let them keep talking...may get to some spec text changes" 20:50:28 or pushing that thread to mailing list instead of github 20:50:37 "not ready for WG review" / "discussion only" label or something. 20:50:40 ... category of a discussion. would you object to a label for conversation? 20:50:44 +1 to "conversation" tag 20:50:50 TallTed: no objection. some things are meant for the mailing list and not github yet 20:50:52 +1 to conversation tag over github discussions 20:50:52 ack Orie 20:51:36 Orie: conversations should probably happen on the mailing list. from an editorial perspective. wherever conversations happen, important they happen. people should come to a shared mental model to get to concrete changes. once concrete changes then an issue should be created with a clear title and description 20:51:38 +1 to ensuring we can mark conversations in a way that gets out of the editors' way *somehow* 20:51:50 q+ to ask if we should more strictly regulate issue creation moving forward 20:51:53 q+ to note that it's hard to point back to things when they're on the mailing list -- speaking as a huge fan of mailing lists from 1993-2015. 20:52:13 q+ to ask and what would that mean 20:52:18 ... if that happens midway through a 2000 comment thread it can be hard for the editors to pull that out. regardless need a clear issue that is easy an actionable. can happen on the mailing list or issue. the clear intention issue should refer to the discussion 20:52:22 +1 concrete change suggestion *might* belong in an issue, or might proceed straight to PR, if there's something like consensus on "this is the action we should try" 20:52:38 +1 "conversation"-tagged issues should produce other issues that aren't conversations but real concrete issues / proposals 20:52:38 ... make sure everything is linked together and clear to the editors what the action is 20:52:42 ack brent 20:52:42 brent, you wanted to ask if we should more strictly regulate issue creation moving forward and to ask and what would that mean 20:53:18 brent: better to more strictly regulate issue creation. do folks agree? what does it mean? try out discussions? label? mailing list? some combo? let's find agreement 20:53:18 ack manu 20:53:18 manu, you wanted to note that it's hard to point back to things when they're on the mailing list -- speaking as a huge fan of mailing lists from 1993-2015. 20:53:21 q+ 20:54:03 manu: hard to police people opening issues. need criteria and judgement calls against them. let's try to process based on what the WG feels is the priority. slight pushback on regulation and criteria. other things we need to spend our time doing. 20:54:06 every message to the mailing list is archived, with a URL, so it shouldn't be *that* hard to point back 20:54:54 +1 to tracking this as github issues (email record is hard to spin-up) 20:54:55 ... also speak against putting things on the mailing list. say this as a die-hard supporter from the 90s. GitHub is great at linking and cross-linking. that has really benefitted the standards making process. don't want to lose that. mailing list conversation is fine but feels ephemeral, even if it's not. hard to point back to a 10yr old conversation. much easier in GitHub 20:55:05 +1 to Manu's concerns 20:55:13 I'd be very surprised if anyone needs to point back to a 10 year old conversation relative to this group's work 20:55:43 ... want to make sure we keep that. can achieve all these things by having a tag 'conversation' and give chairs/editors leeway to tag things. we will get to a point in the WG where we can't address every issue. we'll have to say we've run out of time for some, and the issues will be shifted to the next issue. 20:55:53 q? 20:55:55 s/next issue/next version 20:55:57 ack Orie 20:56:20 q+ 20:56:32 +1 orie 20:56:53 q+ to say mailing list is great for announcements and calls, github for rehydrating 20:56:55 Orie: fine as long as there is a clearly way to distinguish issues editors will take action on vs have a discussion on. could turn the discussion feature off. if we don't intend to use the mailing list, we should turn it off, or use the mailing list to send out issues..drive them to come to some resolution. conversations and clear actions needed 20:57:00 the WG mailing lists will, and should, never go away. 20:57:03 ack brent 20:57:35 brent: have a question label - indicates someone should jump on and answer it. have agreement to create a 'conversations' label. may or may not result in a concrete representation. will move forward 20:57:37 ack JoeAndrieu 20:57:37 JoeAndrieu, you wanted to say mailing list is great for announcements and calls, github for rehydrating 20:57:50 +1 Joe 20:58:06 JoeAndrieu: want to say the mailing list is best for announcements. Requests for feedback too. not great for long discussions 20:58:21 brent: will bring up StatusList2021 next week. please jump on issue #931 in the meantime. 20:58:33 ... see you next week and thank you to Gabe 20:58:35 scribe- 20:59:01 zakim, who is here? 20:59:01 Present: decentralgabe, dwaite, markus_sabadello, jeremie, TallTed, selfissued, dlehn 20:59:03 On IRC I see mkhraisha, selfissued, dwaite, przemek, TallTed, Brian, Orie, jeremie, JoeAndrieu, DavidC, mprorock, RRSAgent, Zakim, brent, dmitriz, tzviya, dlehn1, cel, csarven, 20:59:03 ... shigeya, w3c_modbot, npd, cel[h], bumblefudge, cel[m], stenr, dlehn, dlongley, manu, stonematt, Dongwoo, bigbluehat, hadleybeeman, rhiaro 21:00:11 present+ mkhraisha przemek Brian Orie JoeAndrieu DavidC mprorock dmitriz Phil 21:00:15 zakim, who is here? 21:00:15 Present: decentralgabe, dwaite, markus_sabadello, jeremie, TallTed, selfissued, dlehn, mkhraisha, przemek, Brian, Orie, JoeAndrieu, DavidC, mprorock, dmitriz, Phil 21:00:18 On IRC I see mkhraisha, selfissued, dwaite, przemek, TallTed, Brian, Orie, jeremie, JoeAndrieu, DavidC, mprorock, RRSAgent, Zakim, brent, dmitriz, tzviya, dlehn1, cel, csarven, 21:00:18 ... shigeya, w3c_modbot, npd, cel[h], bumblefudge, cel[m], stenr, dlehn, dlongley, manu, stonematt, Dongwoo, bigbluehat, hadleybeeman, rhiaro 21:00:27 zakim, end the meeting 21:00:27 As of this point the attendees have been decentralgabe, dwaite, markus_sabadello, jeremie, TallTed, selfissued, dlehn, mkhraisha, przemek, Brian, Orie, JoeAndrieu, DavidC, 21:00:30 ... mprorock, dmitriz, Phil 21:00:30 RRSAgent, please draft minutes 21:00:30 I have made the request to generate https://www.w3.org/2022/12/07-vcwg-minutes.html Zakim 21:00:32 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 21:00:36 Zakim has left #vcwg 21:00:41 rrsagent, byt 21:00:41 I'm logging. I don't understand 'byt', brent. Try /msg RRSAgent help 21:00:45 rrsagent, bye 21:00:45 I see no action items