07:27:30 RRSAgent has joined #vcwg 07:27:34 logging to https://www.w3.org/2023/09/15-vcwg-irc 07:27:34 RRSAgent, make logs Public 07:27:35 please title this meeting ("meeting: ..."), ivan 07:27:45 Meeting: Verifiable Credentials Working Group F2F at TPAC, 2nd day 07:27:45 Date: 2023-09-15 07:27:45 Agenda: https://www.w3.org/events/meetings/76aed065-e52f-4cb3-9b8c-54582e75548a/ 07:27:45 chair: kristina, brent 07:27:45 ivan has changed the topic to: Meeting Agenda 2023-09-15: https://www.w3.org/events/meetings/76aed065-e52f-4cb3-9b8c-54582e75548a/ 07:28:24 present+ shigeya, dezell, pchampin, ivan, brent, 07:28:24 RRSAgent, draft minutes 07:28:26 I have made the request to generate https://www.w3.org/2023/09/15-vcwg-minutes.html TallTed 07:28:35 present+ 07:28:36 RRSAgent, make logs Public 07:28:44 present+ kristina 07:29:13 guest+ kaz 07:29:36 present+ gabe, andres 07:29:56 dezell has joined #vcwg 07:30:03 present+ David_Ezel 07:30:24 present+ David_Ezell 07:31:15 Jay has joined #vcwg 07:31:29 s/David_Ezel$// 07:31:33 kristina has joined #vcwg 07:31:37 present+ joe 07:31:37 brent has joined #vcwg 07:31:49 pauld_gs1 has joined #vcwg 07:31:54 present+ 07:32:11 Yen-Lin_Huang has joined #vcwg 07:32:36 hsano has joined #vcwg 07:32:38 present+ 07:32:54 present+ 07:32:58 decentralgabe has joined #vcwg 07:33:04 present+ 07:34:07 JoeAndrieu has joined #vcwg 07:34:17 present+ 07:34:25 present+ 07:34:58 y-sakuma has joined #vcwg 07:35:00 present+ 07:35:03 present+ 07:35:46 morimori_ has joined #vcwg 07:36:03 DavidC has joined #vcwg 07:36:09 present+ 07:36:52 cpn has joined #vcwg 07:37:18 doniv has joined #vcwg 07:37:49 marek has joined #vcwg 07:38:05 sgoto has joined #vcwg 07:38:28 scribe+ sgoto 07:38:31 1 .. 2 .. 3 .. testing scribing ... 07:38:35 present+ 07:38:53 dwaite has joined #vcwg 07:39:23 kaz has joined #vcwg 07:39:35 present+ Kaz_Ashimura 07:39:44 present+ Chris_Needham 07:40:10 Geun-Hyung has joined #vcwg 07:40:16 guest+ sgoto 07:40:28 present+ Ryuichi_Matsukura 07:40:36 brent: status list, presentation after the break from web wallets, conversation with ping, open issues with privacy reviews, after lunch break candidate rep for each specification, and then remaining time test suites 07:40:38 present+ GeunHyung_Kim 07:41:44 andres has joined #vcwg 07:41:49 Topic: VC-StatusList 07:41:57 https://github.com/w3c/vc-status-list-2021/labels/before-CR 07:41:58 q+ 07:42:17 ack manu 07:42:19 brent: vc status list, doesn't have open PRs, merged most recent one this morning, we need to determine what needs to be done, who is going to do it and by when ... 07:42:23 present+ 07:42:33 subtopic: https://github.com/w3c/vc-status-list-2021/issues/85 07:43:15 present+ 07:43:50 manu: issue 85 ... raises the question on whether or not to split the design space ... status list was on an easy trajectory .... then additions by folks in the supply chain traceability space ... modifying the single bit into a multi bit status ... to contain a message effectively, and then have an arbitrary number of messages with the particular status entry ... including links to documentation and business rules ... time to live ... variety of oth[CUT] 07:44:12 iirc it was already multi-bit, but the additions were the optional additional information and the ability to define statuses by those setting up the list. 07:44:20 ... in hindsight that has had unanticipated effects ... status list not as simple as before ... 07:44:55 q+ to ask about recommending simpler lists for people credentials? 07:44:55 LaurensDebackere has joined #vcwg 07:44:56 present+ 07:45:04 manu: if we want to do privayc preserving things, add noise to the bit, the width of the status list ... can affect how we'll add noise to the list ... you'd have to flip the right bits in a statistically significant way ... 07:46:12 s/privayc/privacy/ 07:46:21 manu: i'm suggesting that we create two different lists, one of them a very simple status list, much easier to do the privacy analysis on it ... and then have a separate status list, multi bit, with all of these other features ... different privacy characteristics ... "please be aware" ... i think it will be easier to write the specification ... 07:46:23 q? 07:46:26 ack brent 07:46:28 brent, you wanted to ask about recommending simpler lists for people credentials? 07:46:32 ack brent 07:46:34 q+ 07:46:42 q+ 07:47:25 brent: as far as the privacy concerns ... when issuing ... don't think the characterization of single bit vs multi bit is quite accurate .... it was always multi bit IIUC ... 07:47:28 q- 07:47:45 brent: suggestion on the floor to move in a different direction ... anyone opposed to having two different lists? 07:47:46 ack kristina 07:47:58 q+ 07:48:17 q+ 07:48:18 kristina: only raised recently, so not the moment to make decisions .... single bit vs multi bit doesn't seem like it would change the privacy analysis ... 07:48:25 q+ to speak to privacy 07:48:29 q+ to note privacy concerns w/ multibit 07:48:32 kristina: we need to understand a bit more before we arrive at a conclusion / agreement 07:48:32 ack andres 07:48:58 1+ to single type 07:49:00 andres: i agree with kristina .... i recommend that we don't have multiple types .... makes it hard for people to make a decision on which one to use ... 07:49:35 andres: if you are able to correlate with a single bit you'd also be able to correlate with multi bits ... 07:49:45 ack DavidC 07:50:04 q+ 07:50:11 q+ 07:50:22 there is interest to use multibit one for people too 07:50:38 whats the use case for that kristina ^ 07:50:47 -1 to binding singleBit/multiBit to the use-case 07:50:47 davidc: not sure i see a different problem with having two lists 07:50:47 ack JoeAndrieu 07:50:47 JoeAndrieu, you wanted to speak to privacy 07:51:08 even for people there are cases when more than 2 statuses needed 07:51:15 wonsuk has joined #vcwg 07:51:28 present+ Wonsuk_Lee 07:51:30 joeanbdrieu: i think it applies to more than the human privacy issue ... the bit shows up in other problems ... we could have solved this in other ways other than multi-bit ... 07:51:46 yes, but what's the use case for that ^ -- like, what statuses are we setting for people? 07:52:05 joeandrieu: with the multi bit you are checking ... i'm curious why you don't think single bit vs multi bits isn't the key of the concern ... 07:52:38 brent: framing it as a single bit vs multi bit is disingeneous 07:52:42 ack manu 07:52:42 manu, you wanted to note privacy concerns w/ multibit 07:52:49 manu: +1 what joe said ... 07:54:09 manu: on the privacy issue, when you expose more information on an entity ... things get dicier and dicier from a privacy perspective ... e.g. maybe it is the wrong framing ... happy to use other words ,... the concern here is that if we have, maybe a bigger conversation, when you have the possibility to have multiple bits ... of data on an individual ... having one bit of data is simpler than 10 different statuses on an individual ... 07:54:42 q+ to say still not seeing the need for more than a comment in the privacy considerations 07:55:04 manu: the person didn't show up because they didn't renew their driver's license ... shipping containers ... why was it held for inspection ... it can be OK for a non-person object, but certainly, more thought needs to be put for individuals ... 07:55:47 manu: this concept where we are going to have an arbitrary number of statuses associated of entities ... it makes the design space more complicated, in compariosn to single bit. either we split the design space ... another option, same dseign space ... 07:56:14 manu: then we have to be explicit about the dangers of having multiple bits, because you have more data points on the tntity .... ideally down to a single bit ... e.g. revoked or not, rather than reasons . 07:56:31 manu: if you are going to have 10 different reasons for why it was revoked ... you have to do that in a statistically different way ... 07:56:53 manu: these new changes have made it more complicated ... we have to think this through ... the easiest way i think is to have two different types ... 07:57:05 ack kristina 07:57:07 manu: the other approach is to have everything the same but gets more complicated 07:57:42 q+ 07:57:52 kristina: i seriously question the notion within the status list use case and specification that more data points about the user instead of just one bit being used rather than two bits for valid or invalid leads to more correlation ... that is not correlation comes from in the three party model ... it comes from the identifiers ... 07:58:11 kristina: correlation between the verifier, the issuer, privacy from whom? who are we violating the privacy? 07:58:28 kristina: are you worried about the verifier getting more information and therefore getting more? 07:58:38 q+ to note that multiple bits is about correlation of populations 07:58:44 kristina: if that's the issue, then we shouldn't be doing at all. so don't think the notion is accurate. 07:58:57 q+ to say it fundamentally correlates the bits 07:59:13 kristina: don't disagree that simple bit is simpler than many ... but it doesn't seem complicated enough to justify a new type ... 07:59:21 kristina: can we separate for people and not-people? 07:59:38 ack decentralgabe 07:59:52 decentralgabe: i agree with the sentiment that we should limit footguns ... 08:00:22 q- later 08:00:32 decentralgabe: i don't think privacy is a matter of opinion here ... we can get experts who can do a better priavcy analysis ... so suggestion is to reach out and report back to the group. 08:00:41 KevinDeanGS1 has joined #vcwg 08:00:49 q+ 08:00:51 decentralgabe: preference is to have a single option, makes implementation harder if we have many. 08:00:52 ack brent 08:00:52 brent, you wanted to say still not seeing the need for more than a comment in the privacy considerations 08:00:53 +1 to what gabe said 08:01:05 agree with gabe 08:01:11 q- later 08:02:04 ack JoeAndrieu 08:02:04 JoeAndrieu, you wanted to say it fundamentally correlates the bits 08:02:07 brent: back to concrete proposals, status list, the spec, be separated into two different types .... we don't have consensus to do that to make that change .... based on the conversation ... the argument that the work is greater if we don't split it isn't convicing to me .... seems like we'd have to do the same amount of work either way ... 08:02:17 joeandrie: +1, doesn't seem like consensus ... 08:02:18 zakim, close the queue 08:02:18 ok, kristina, the speaker queue is closed 08:03:04 joeandrieu: it could be different lists ... topologically, you'd have to look at the VC ... whereas if multi bit ... 08:03:11 joeandrieu: the topology could be that you have one VC that points to three lists ... revocation, suspension, etc 08:03:21 joeandrie: or you could have one VC with 3 bits ... 08:03:40 q? 08:03:45 joeandrieu: we are not going to get consensus atm. 08:03:45 ack KevinDeanGS1 08:03:58 there 3 bits are about the same user by design - they are correlated by design 08:04:13 +1 kevin 08:04:15 yes, and that's them problem ^ 08:04:26 s/them problem/the problem/ 08:04:30 +1 to information security ~= organizational privacy 08:04:35 why is intentional correlation a problem? what does it erode? 08:04:39 kevindeangs1: privacy application to individuals vs corporations ... corporations may have the same concerns ... that you could apply to personal data ... same concerns to non-human side of VCs .... 08:04:44 ack manu 08:04:44 manu, you wanted to note that multiple bits is about correlation of populations 08:05:14 ack KevinDeanGS1 08:05:24 ack KevinDeanGS 08:05:24 manu: understand that we are not going to get consensus to split ... so ... i'll proceed by trying to address this in spec text .... 08:05:29 q+ 08:05:52 manu: and privacy considerations ... this is one of the reasons pushing why pushing PRs and then dealing with the problem in the future ,.... 08:06:08 manu: in any case, i'll proceed by writing in the privacy consideration section ... 08:06:36 manu: one of the problems here is correlation of population ... the list is composed in a particular way ... what the populations may be doing ... 08:06:49 +1 this is why I frequently argue against merging something with known flaws that "we can sand off later" 08:07:11 brent: as to this issue, can it be closed? or should it remain open? 08:07:23 selfissued has joined #vcwg 08:07:26 present+ 08:07:33 manu: lets open a new one while we are here 08:08:19 brent: lets move on to our next issue 08:08:39 subtopic: https://github.com/w3c/vc-status-list-2021/issues/84 08:09:08 q+ 08:09:08 brent: suspension of a root credential should cause a child credential to fail .... does nayone have this problem too? 08:09:18 zakim, open the queue 08:09:20 ok, kristina, the speaker queue is open 08:09:23 brent: the relationship status ... question about statuses of multiple credneitals ... combinatorial status ... 08:09:28 KevinDeanGS1 q+ 08:09:33 brent: need to get recommendations or just chat? 08:09:41 q+ KevinDeanGS1 08:09:42 dmitriz has joined #vcwg 08:09:44 present+ 08:09:58 q+ 08:10:03 q+ 08:10:03 ack KevinDeanGS1 08:10:11 ack KevinDeanGS 08:10:43 q+ 08:10:43 q+ to note this is business logic outside of the core status list mechanism. 08:10:59 kevin: ... if my credential is revoked ... it may have an impact on credentials that i have issued ... 08:11:25 ack decentralgabe 08:11:25 kevin: ... any credentials i issued up to that point ... in rare circunstances it may affect credentials i issued in the past ... 08:11:34 gabe: that seems like a legitimate need ... 08:11:45 gabe: seems like a protocol-level decision ... 08:11:48 q+ to say I think this is already as supported in the specification as is appropriate. We only have a few mechanisms for automated validation (expiry, validation Method, etc.).. 08:11:50 ack brent 08:11:53 gabe: another spec another place may be better 08:12:08 brent: +1, agree that this is a problem, not sure that status list 2021 is the right place to do that specification 08:12:11 +1, agree this is about how the issuer manages multiple credential statuses 08:12:18 brent: not even sure if it is within the scope of the charter that it is ... 08:12:30 brent: we are short on time ,.. 08:12:35 more broadly dependent/complex validation logic is il-defined 08:12:36 ack manu 08:12:36 manu, you wanted to note this is business logic outside of the core status list mechanism. 08:12:46 q+ to say VCs were not designed for use as authorization mechanisms. To the extent they're being used as such, that's business logic, and outside the VCWG's purview. 08:12:48 manu: yes, i'd echo what gabe and brent and kristina had said on irc ... 08:13:16 manu: maybe this is langauge that could go in the VC data model ... i don't think this is something that the status list spec should talk about ,.... 08:13:24 manu: even if it does, it would have to be non-normative ... 08:13:30 What is relevant to status spec is that the multi-bit options for status could affect business logic during validation. 08:13:36 q? 08:13:50 brent: recommending that it remains open? 08:13:54 brent: or close? 08:13:59 manu: orie? 08:14:19 doniv has left #vcwg 08:15:02 manu: not pre-cr, post-cr ... my suggestion is seeing if orie objects to closing it ... 08:15:02 q? 08:15:07 kristina: we heard that there are use cases for that ... 08:15:28 ack JoeAndrieu 08:15:28 JoeAndrieu, you wanted to say I think this is already as supported in the specification as is appropriate. We only have a few mechanisms for automated validation (expiry, 08:15:30 takashi has joined #vcwg 08:15:31 ... validation Method, etc.).. 08:15:48 joe: i have the same quetstion ... what's the proposed mechanisms? i think this really goes in implementation guide ... 08:15:56 +1 to Joe 08:15:56 ack TallTed 08:15:56 TallTed, you wanted to say VCs were not designed for use as authorization mechanisms. To the extent they're being used as such, that's business logic, and outside the VCWG's 08:15:59 ... purview. 08:16:05 zakim, close the queue 08:16:05 ok, kristina, the speaker queue is closed 08:16:13 ted: VC allows me to know that "Joe said somehting" 08:16:31 s/ted/TallTed 08:16:33 q+ to speak to currency 08:16:37 q+ 08:16:46 ted: some metadata, dates, etc, but the full infrastructure that's required for whether something is revoked is not built into this, do not recommend it 08:16:57 zakim, open the queue 08:16:57 ok, kristina, the speaker queue is open 08:16:57 @TallTed - not sure I fully understand? credentialStatus is an integral part of VCs.. 08:17:00 brent: labelling it to "pending close", orie can comment and we can go from there 08:17:08 brent: unclear what normative changes would be required 08:17:16 brent: next, talking about 82 08:17:20 subtopic: https://github.com/w3c/vc-status-list-2021/issues/82 08:17:20 q+ 08:18:00 brent: intro, spec from april, fix for this is straightfoward, we need to go back to call vc status 2021 ... unless we as a group change the record name ... 08:18:10 dmitriz — What happens if your credentialStatus lookup fails? once? 3 times over 7 days? This is business logic. 08:18:21 brent: we either change it back or we have a formal resolution to change the name ... 08:18:26 brent: ivan and the editors ... 08:18:31 ack manu 08:18:57 manu: just need to change the name of the spec ... no longer vc stauts list 2021 ... use something less generic 08:19:04 dtluu has joined #vcwg 08:19:09 @TallTed - sure, that's business logic. I'm just wondering why you're saying "VCs weren't designed for this". business logic is a huge part of VC validation, it's absolutely designed for it 08:19:14 manu: maybe vc multi status list ... vc stream status list ... 08:19:23 manu: hesistant to change it today 08:19:25 manu: interested in time boxing it 08:19:27 brent: 2 mins 08:19:34 q+ 08:19:40 brent: if something can come up with a good name in the next 2 mins 08:19:41 I like`vc-bit-string-status-list` 08:19:47 ack kristina 08:19:53 kristina: why is this so complicated? why can't we just remove 2021 from the name? 08:19:57 brent: that would work 08:20:01 -1 08:20:01 +1 08:20:03 +` 08:20:05 brent: would that work for everybody? 08:20:08 brent: anyone opposed? 08:20:13 manu: yes, too generic 08:20:16 0 (prefer vc-bit-string-status-list) 08:20:47 manu: bit string status list 08:20:47 brent: anyone opposed? 08:20:47 dwaite_ has joined #vcwg 08:20:47 kristina: i do think you need status list of "what"? 08:21:05 brent: no one wants to die on the hill 08:21:08 brent: i'll draft a proposal 08:21:38 manu: there is also ... nevermind 08:21:45 what was manu's proposal? 08:21:50 joe: seems like misalignment between two names ... 08:23:49 ivan: lets not rename the doc in three months ... lets do them both at the same time ... 08:23:59 PROPOSAL: the new shortname is vc-bitstring-status-list 08:24:02 +1 08:24:04 +1 08:24:05 +1 08:24:05 wonsuk has joined #vcwg 08:24:05 +1 08:24:06 0 08:24:07 +1 08:24:07 +1 08:24:07 +1 08:24:09 +1 08:24:11 +0 08:24:12 0 08:24:12 +1 08:24:14 0 08:24:24 0 08:24:30 0 08:24:52 RESOLVED: the new shortname is vc-bitstring-status-list 08:24:52 brent: not seeing any opposition 08:24:55 brent: we are resolved 08:24:57 q+ 08:25:00 q+ 08:25:02 ack ivan 08:25:02 brent: practical level, who is going to fix the spec 08:25:10 ivan: who wants to help? 08:25:13 manu: i can help 08:25:22 manu: i can do the naming changes 08:25:40 ivan: i have put a comment into the issue where i summarized what we need to do in the COSE/JOSE change 08:25:56 brent: good conversation ... we still have like 25 issues to look at 08:26:02 brnet: and 30 mins to do it 08:26:14 s/brnet/brent/ 08:26:19 brent: if the editors have preferences for how to prioritize ... 08:26:26 brent: take advantage of the people in the room 08:26:38 brent: jumping into 81 08:26:42 manu: skip that 08:26:44 manu: 64 08:26:47 subtopic: https://github.com/w3c/vc-status-list-2021/issues/64 08:26:58 brentz has joined #vcwg 08:27:10 manu: need approval from the group to talk about potential http resopnse status codes ... request by mike jones 08:27:21 manu: if you do things with status lists with HTTP, what should you expect ... 08:27:27 manu: from HTTP status codes ... 08:27:37 present+ selfissued 08:27:45 manu: if you operate over http these are the things that you can expect to see from servers .... 08:27:59 q? 08:28:01 ack manu 08:28:10 manu: looking to see if anyone that would oppose to adding a section on operating over http and expecting http error codes 08:28:16 q+ 08:28:19 q+ 08:28:19 brent: any opposion as that for a path forward? 08:28:22 ack kristina 08:28:29 kristina: sgtm 08:28:57 kristina: when this was raised we deliberately didn't do right away ... what has changed? why is it ok to do this now? 08:29:00 ack JoeAndrieu 08:29:10 joe: just wanted to clariy, the intention is to not use non-normative language, right? 08:29:36 manu: what has changed, kristina, is that we figured out a way to do it without raising objections, a design pattern in the status list that people din't reject 08:29:39 it needs to be normative 08:30:03 manu: joe, if you are using HTTP these things MUST be done 08:30:07 +1 to normative. just wanted to understand the scope of the proposal 08:30:45 prefer normative, since we've found a way to do that. 08:30:45 manu: mike, wdyt, would you more normative language around this? 08:30:45 q? 08:30:45 mike: yeah 08:30:45 manu: as long as no one opposed, we'd use normative language 08:30:52 manu: i'll take that 08:31:03 subtopic: https://github.com/w3c/vc-status-list-2021/issues/58 08:31:05 manu: lets do 58 next 08:31:17 manu: should we use base64 or base64-url to encode the list 08:31:26 q? 08:31:28 manu: orie says we should say base64-url, anhyone opposed? 08:31:43 brent: no one on the queue, you are good to go 08:31:54 manu: neat, i can take it 08:32:24 subtopic: https://github.com/w3c/vc-status-list-2021/issues/44 08:32:41 manu: clarify the protocol .... for --- list ... 08:32:51 manu: unless anyone objects ... it should be http-over-url 08:32:59 manu: should be simple ... people can use different protocols ... 08:33:21 q+ to say no, it should be transport independent 08:33:28 i have not heard anyone sending status lists over PE 08:33:28 manu: should be experssed ... should be able to be retrieved over http ... anyone disagrees? 08:33:30 ack JoeAndrieu 08:33:30 JoeAndrieu, you wanted to say no, it should be transport independent 08:33:42 joe: binding a resource to its transport type is flawed ... not sure it makes sense ... 08:33:48 q+ 08:33:58 joe: if i see a status list ... it can be FTP ... 08:34:11 q+ 08:34:14 brent: i agree with you, and was happy when manu said SHOULD 08:34:16 ack brentz 08:34:19 ack andres 08:34:25 andres: i'd like to see HTTPS 08:34:30 brent: of course 08:34:31 q+ 08:34:37 ack kristina 08:35:07 kristina: do we also how the url is being fetched? post/get? 08:35:09 q+ 08:35:13 ack manu 08:35:43 manu: yeah, good questions ... this is where it gets complicated ... just say ... yon should use a HTTPS url, but that doesn't mean that you can't use FTP or ssh:// ... 08:36:14 manu: preferring to use oblivious http, rather than plain http ... that's where it gets more complicated .... recommending ... we'll just have to work on the details on the PR ... 08:36:24 manu: the more prescriptive we get the harder the PR is 08:36:33 q+ 08:36:35 manu: right place to work on that is in the PR ... would that work? 08:36:38 ack kristina 08:37:02 kristina: assuming you are the one writing the pr ... are you going to specify whether it is going to be a GET or POST? 08:37:08 manu: i think it is goin go tbe a GET 08:37:13 q+ 08:37:24 ack kristina 08:37:27 manu: lets say, a GET, ideally over oblivious HTTP, not query parameters, no fragment identifiers ... any objections 08:37:27 ? 08:37:35 kristina: hard to say right now if that works ... 08:38:04 kristina: sounds reasonable ... intuition feels like there is something out there already ... 08:38:23 subtopic: https://github.com/w3c/vc-status-list-2021/issues/14 08:38:27 manu: 14 08:38:46 i have questions on actually recommending OHTTP - it is still in draft in IETF. not comfortable with that 08:38:49 manu: asks if we can relax / remove the requirement on the minimum bit for the status list ... 08:38:55 manu: currently 16 KBs 08:39:13 manu: the concern here is around privacy .... providing at least a minimum ... 08:39:32 manu: do we want to leave the hard privacy decision to the implementors? 08:39:49 manu: some authors of the status list may pick minimum population sizes that do not provide hard privacy? 08:39:58 manu: or at least we could provide a floor 08:40:14 q+ 08:40:15 manu: do we want a minimum guaranteed privacy setting for these lists? 08:40:17 q+ to say some kind of floor is IMO necessary because people don't understand privacy and will make bad choices 08:40:26 manu: or do we want ot leave that open to authors? understanding that they can pick bad values 08:40:38 +1 keep the floor 08:40:43 ack kristina 08:40:46 q+ to strongly argue for a herd privacy floor 08:41:01 ack JoeAndrieu 08:41:01 JoeAndrieu, you wanted to say some kind of floor is IMO necessary because people don't understand privacy and will make bad choices 08:41:05 q+ to answer why the arbitrary number 08:41:07 joe: i agree that it is arbitrary 08:41:15 joe: but i do agree that we need a floor 08:41:23 joe: most people use defaults, should be a good one 08:41:34 ack manu 08:41:34 manu, you wanted to strongly argue for a herd privacy floor and to answer why the arbitrary number 08:41:40 manu: the current number is arbitrary 08:42:03 manu: we took 16 KBs and run through gzip .... seemed reasonable ... 08:42:17 manu: we could increase/decrease ... but very strongly arguing that we should have a decent floor 08:42:36 manu: since we are going to multibits ... we should try to get good defaults 08:42:51 manu: responding to dwait, the verifier shoud reject 08:42:58 q? 08:42:58 q+ 08:43:02 ack kristina 08:43:38 q+ 08:43:40 kristina: we can't make a decision right now, need input from implementors ... 08:43:51 ack JoeAndrieu 08:44:08 joe: we should ask a specific use case ... maybe it is an iot situation where size matters ... 08:44:41 joe: i'll add that comment 08:44:51 brent: action is to do nothing, see if we hear back 08:44:53 subtopic: https://github.com/w3c/vc-status-list-2021/issues/40 08:44:55 manu: 40 08:45:12 manu: decoys or noise when the initial publicatino happens and when you see updates 08:45:56 manu: concern is, adversary looking at the list, watching bits flip, downloading the list every 5 mins, they can see what percentage of your population is having things revoked or changed or modified and gives them insights into your population 08:45:57 q+ 08:46:20 manu: ... are operating ... they would undrestand ... 30% of the population broke the law in some way .... 08:46:27 manu: they can figure out what the population is doing .... 08:46:36 manu: one way to address this is to add noise to the list 08:47:21 describing the problem is sufficient 08:47:28 in privacy considerations 08:47:42 manu: implementor specific ... publisher of the list decides on how to add noise and in what order .... creates variation ... there is no one algorithm to add noise ... the downside is taht the implementor may not have privacy experts ... 08:47:53 manu: so easy for them get wrong and reveal more information 08:48:03 q+ 08:48:03 ack brentz 08:48:07 manu: do we want to tackle noise generation or do we want to leave that to implementors? 08:48:53 brent: this exists because of the architecture itself .... strongly in favor of option 2 ... even if we find a good way to do this, in a few weeks a better one would come up ... 08:49:12 brent: there are going to be confusion, but it doesn't feel like we have enough information in the gorup ... 08:49:21 ack kristina 08:49:22 brent: so, a note somewhere on how to go about noise 08:49:38 kristina: yeah, in general agree ... what mechanisms are currently used? 08:49:55 q+ to agree and move on to the next issue 08:49:59 ack manu 08:49:59 manu, you wanted to agree and move on to the next issue 08:50:13 it is hard 08:50:19 manu: they are not doing this at all, as far as we can tell. we heard it is on the roadmap, but no one is doing it 08:50:31 q+ to support it as implementation guidance 08:50:42 manu: e.g. revocation status list, you'd never want to flip a revocation bit, because that would give away that that entry is a decoy 08:50:57 manu: so you have to be careful. it becomes even more important with multi-bits. 08:51:11 well, driving licenses can be temporarily revoked for 30/60 days etc so flipping back is fine 08:51:24 manu: +1 to agree with everything that has been said so far, we don't have enough implementation experience to decide, 08:51:30 no advising, just describing the problem is sufficient 08:51:36 q? 08:51:46 manu: no specific recommendation for the path, but htings that implementors should be worried about 08:52:36 ack JoeAndrieu 08:52:36 JoeAndrieu, you wanted to support it as implementation guidance 08:52:39 brent: post cr and move on 08:52:54 joe: not to advise, really we haven't figured outk, but things to consider 08:53:03 subtopic: https://github.com/w3c/vc-status-list-2021/issues/51 08:53:07 manu: 51 08:53:21 manu: clarify if VC data model, what are we targeting? 08:53:40 q? 08:53:42 q+ 08:53:46 ack kristina 08:54:09 kristina: clarification i'm looking for is the shape of a status list 08:54:22 kristina: examples using VC data model, but no where in the doc it says that it must be compliant 08:54:29 kristina: is it reallly the VC data model? 08:54:43 kristina: doesn't seem like it needs to be compliant with the VC data model 08:54:51 kristina: doesn't have info about the holder ... 08:54:59 kristina: sitting on a HTTPS url 08:55:09 q+ to note it is being sent via issuer->holder->verifier -- that's definitely a use case. 08:55:09 kristina: i'd prefer if this was a simple JWT 08:55:24 kristina: not sure if i can convince this group to go in this direction 08:55:31 kristina: so looking for clarity 08:55:33 ack manu 08:55:33 manu, you wanted to note it is being sent via issuer->holder->verifier -- that's definitely a use case. 08:55:42 manu: yeah ... it is definitely VC data model 08:55:48 like what? 08:55:49 manu: we rely on a variety of things, in the status list 08:55:55 q+ to mention the shortname 08:55:56 manu: there is a use case where the holder takes this 08:56:03 manu: for the purpsoes of privayc protections 08:56:11 manu: so taht the verifier doesn't have to go out andfetch it 08:56:30 manu: to be clear, we depend on things like the issuer ... valid from and valid until ... credential subjects ... 08:56:40 manu: not easy to put into a JWT 08:56:46 manu: that said, you can encode it into a JWT 08:56:56 ack JoeAndrieu 08:56:56 JoeAndrieu, you wanted to mention the shortname 08:56:56 manu: but the data model, it is highly dependent on the VC data model 08:57:09 q+ 08:57:09 q+ 08:57:15 joe: first i thought that made sense kristina, but then realized that ... 08:57:17 ack kristina 08:57:43 kristina: the way i differentiate it ... it is independent of the data model of how the status list is expressed ... 08:57:51 kristina: for example, if there is a CBOR based credential 08:58:00 kristina: technically, the status list doesn't need to be CBOR 08:58:08 kristina: i've seem people that 08:58:19 q? 08:58:22 ack ivan 08:58:24 kristina: there is a sepearation of HOW things are expressed and WHAT things it epxresses 08:59:33 subtopic: https://github.com/w3c/vc-status-list-2021/issues/81 08:59:33 ack ivan 08:59:35 ivan: there are a number that are defined in the standard .... 08:59:51 ivan: rnage, domain, etc 08:59:57 that problem goes away if the status list credential is not a vcdm :P 08:59:58 q+ to suggest VC Vocabulary 09:00:03 s/rnage/range/ 09:00:08 ack manu 09:00:08 manu, you wanted to suggest VC Vocabulary 09:00:30 manu: two options: put in the VC vocabulary ... exists and is there ... another option is to create a different voacblary doc ... for the status list spec ... 09:00:31 q+ 09:00:34 manu: and put it in that 09:00:44 manu: on the fence on what to do ... 09:00:57 manu: the second approach seems cleaner ... but more pain ,.... vs just putting in the VC vocab easier to do 09:01:03 ack ivan 09:01:06 brent: anyone opposed to the VC vocab? 09:01:17 ivan: the crednetials vocab is already a collection in a sense 09:01:22 q+ to ask Ivan what he'd prefer :) 09:01:29 ivan: not to the VC DM only 09:01:38 ivan: so putting into that vocabulary is "clean enough" 09:01:51 ivan: not devoted into any of the two options 09:02:10 joe: just wanted to note that it is a VC and we support VCs over JWTs ... 09:02:16 brent: manu and ivan seem to be on the same page ... 09:02:23 manu: ivan, what would you prefer? 09:02:33 brent: the point is that that's a conversation beteween the two of you 09:02:43 ivan: inclined to put in the VC vocab 09:02:54 thanks you all for having me! 09:22:28 Jay has joined #vcwg 09:29:20 rbyers has joined #vcwg 09:30:30 selfissued has joined #vcwg 09:30:34 present+ 09:30:36 Vagner_NIC_Br has joined #VCWG 09:31:42 Jay has joined #vcwg 09:31:46 wonsuk has joined #vcwg 09:31:57 ivan has joined #vcwg 09:32:10 scribe+ 09:32:15 decentralgabe has joined #vcwg 09:32:15 present+ 09:32:17 present+ 09:32:21 present+ 09:32:28 pauld_gs1 has joined #vcwg 09:32:28 dezell has joined #vcwg 09:32:36 Topic: WICG and Web Wallets. 09:32:41 brentz: We have invited folks from the WICG to discuss Identity Credentials work. 09:32:44 present+ David_Ezell 09:33:07 rickByers: I work at Chrome, work with Sam Goto - work on Federated Identity -- Helen who works on Android. 09:33:45 rickByers: Some caveats -- I work on browser APIs, not a credential expert -- lots of specs, lots to learn, apologize for not engaging this group sooner. Realized that we ran forward without reaching out to you, apologize for that. 09:34:04 q? 09:34:07 https://docs.google.com/presentation/d/1mz7AUJLc9y7zOU7CfLCsBSt3dGIkN_x61tpoRaQCQko/edit?resourcekey=0-NhvH5WIUclnZZPyRSyyLqQ 09:34:25 marek has joined #vcwg 09:34:27 Bruno has joined #vcwg 09:34:33 rbyers: I'm here mostly representing chrome and androind, lots of different interests 09:34:34 scribejs, set rbyers Rick Byers 09:34:36 morimori has joined #vcwg 09:34:41 guest+ rbyers 09:34:44 ack manu 09:34:44 manu, you wanted to ask Ivan what he'd prefer :) 09:35:20 rbyers: I'm going to focus on Chrome goals, even though we're working w/ other browser vendors. This is just what we think this week... looking for feedback,, don't ake any of this as a guaranteed promise in any way. 09:35:24 andres has joined #vcwg 09:35:39 dwaite_ has joined #vcwg 09:35:47 rbyers: What we think our goals are: wallet discovery and invocation -- that's not a completely solved problem, trying to help websites request credentials from wallets 09:36:12 kaz has joined #vcwg 09:36:26 rbyers: we are not interested in trying to pick one wallet -- want a multi-wallet approach and easy for users to have multiple wallets -- we're worried about individual having credential, but they forget which wallet that credential is in... in some scenarios, they can go directly to credential. 09:37:04 rbyers: We're very concerned about privacy in general, we need meaningful consent from people before wallet is invoked -- high level principle is the more we can be confident that user understands the context, the lower friction we can have for user. 09:38:01 rbyers: We want to enable things that are difficult w/o browsers -- cross-device requests, like passkeys today, can make it seamless for websites... we want to enable competition and choice in credential formats and wallets -- one format vs. other format -- not proper position for platform to be in -- we need to enable level playing field, have issuers/users choose what's best for them. 09:38:06 q? 09:38:06 q+ 09:38:28 ack manu 09:38:33 see slides: https://docs.google.com/presentation/d/1mz7AUJLc9y7zOU7CfLCsBSt3dGIkN_x61tpoRaQCQko/edit?resourcekey=0-NhvH5WIUclnZZPyRSyyLqQ 09:38:46 sebastianelfors has joined #vcwg 09:39:30 manu: this all looks great. enabling consent, choosing wallets, etc. great to see chrome team engaged. 09:39:40 scribe+ brentz 09:39:58 ... also great to hear not picking winners on credential formats. maybe should pick protocols or query languages. 09:40:19 ... I've talked with sam before about CHAPI which is a plugin that does a lot of this. 09:41:03 ... are you planning on focusing on one way through to start? Like starting with mDL first and foremost? what is the charter like, are you looking at other formats like VCs etc.? 09:41:12 Youngmin_Ji has joined #vcwg 09:41:28 rbyers: It's true that when we started we were focused on mDL, but Sam convinced us that's the wrong approach thanks to work you (the grop) have been doing. 09:43:27 rbyers: Our current prototype is format agnostic, code doesn't know about formats at all, have to do minimum amount in chrome mto understand request to get meaningful consent, but we think that's minimal, don't see why we can't do that for VCs and mdocs at the same time, details to work out -- query language, our principle is we need to understand enough about query in browser to give low friction high confidence flow -- vs. option that might be a bit 09:43:27 scarier -- there is always mechanisms for wallets to alk directly to websites... QR Codes, custom URL schemes -- we need to create enough trust in our approach to have RPs to choose to use our APIs, but have scenarios where other routes are used. 09:43:27 rbyers: We are nervous about the long-term privacy in this space -- how do we defend our promise to users to protect them online. 09:43:27 q? 09:44:01 helen_ has joined #vcwg 09:44:26 rbyers: We feel the need to focus on pragmatic solutions that can be brought to market rapidly, we don't want to be barrier to innovation -- some use cases solved for users quickly while laying groundwork for innovation w/o browser involved. 09:44:58 rbyers: PING asked us to present on Tuesday -- browsers should be trying to block some of this stuff -- freedom of expression / choice -- tried to collect some of those arguments in deck w/ PING. 09:45:31 q+ to clarify where the work is happening 09:45:54 rbyers: considering adoping that as work item in WICG -- obviously a tension here, we won't get all of these properties, privacy, security, choice -- reasonable balance on space -- browser can make risk determiniation -- browser can't read a lot of information -- responses are encrypted, don't want to see that. trust wallet to do something on their behalf. 09:46:37 ack brentz 09:46:37 brentz, you wanted to clarify where the work is happening 09:46:37 rbyers: we accept that it's not the browsers role to see visibility into response from wallet. 09:46:37 brentz: The work is intended to be an item worked on in WICG? 09:46:37 rbyers: Yes, have a status on that. 09:47:33 rbyers: Where are we riht now -- we formed a new repo -- browser APIs, we can't even form a charter until we have a solid understanding w/o how things work in practice -- trial deployment experience -- incubating in WICG -- for a while, we had two repos, we agreed w/ apple to merge into single identity credential repo... two explainers -- we have a number of things to get through to get to possible API. 09:48:40 rbyers: got agreement at TPAC, haven't made much progress in last six months -- started weekly meeting in WICG where we try to reconcile that, scope is trying to narrow down explainer to have consensus on set of goals we're trying to solve for, what is sketch of API -- deployment experience helps us understand what it should look like. 09:49:01 q? 09:49:02 rbyers: We have origin trials in Chrome -- we have some itnerest in experimenting in Q1 2024 -- but that's a trial, we learn from that, time limited, then turn off and ship something -- if all goes well, learn from origin trial 3-6 months, then ship another API in 2024, subject to change. 09:49:05 Could you please also mail the Android Identity Credential presentation to the W3C VC WG mailing list? (That way it will also reach the persons who are not in the call.) 09:49:50 the link to the slides are included in the meeting minutes which will be sent to the list. 09:50:04 rbyers: To get a little more concrete, exact shape of API (things could change), we think we want to integrate w/ existing credential manager API -- Sam works on FedCM, there are a lot of use cases that might involve multiple sources of credentials -- give user choice of verifying age w/ mdoc or VC -- trying to integrate into web's credential management API 09:50:18 rbyers: If you're asking for identity, important to ask for that... 09:50:59 rbyers: you might have list of multiple providers, one could be FedCM -- or you could have other holders -- format is a string, we're going to parse it to ensure we understand meaning of request -- we will just point to other specs. 09:51:21 rbyers: We would like VC example -- part of what we're trying to show is under params, extra params could be arbitrary structured data that flows through to wallet. 09:51:50 rbyers: That's where lots of innovation can happen... but selector is something we have to agree on, information that browser reasons about wrt. risk signal -- how can user do this w/ low friction. 09:52:01 rbyers: for example, privacy perserving age attestion vs. DL number. 09:52:44 rbyers: So this demo is with androind age picker... which calls into wallet in sandbox -- wallet gets to see request and see which to send to user 09:53:03 rbyers: What labels are being requested -- isolated sandbox so wallet can't track user, but when individual consents, then wallet is invoked -- wallet app opens, confirmation/biomtrics happens. 09:53:04 q? 09:53:04 q+ 09:53:09 ack manu 09:54:46 manu: can the browser see inside the wallet? 09:55:13 ... what if wallets lie? 09:55:32 q+ on trustworthiness of wallets 09:56:01 rbyers: There is a tricky balance here, no we're not going to try to look inside some wallets, that code is run in mechanism that is sandbox. Our threat model is assuming user has chosen trustworthy wallet so our threat model doesn't include malicous wallets. Maybe there are legitimate scenarios that wallet matches on every credential. there is some check against that, if people are annoyed by that, they'll probably uninstall that wallet. Hopefully 09:56:01 that enables wallets that are acting in users interest. 09:56:34 ack npd 09:56:34 npd, you wanted to comment on trustworthiness of wallets 09:56:43 helen: Browser tries to create sandbox that allows wallet to resolve that information in framework so that gets propagated to browser, browser shouldn't be able to see into wallet contents. 09:57:23 npd: I don't understand what the trust model is here... my local government says tey have a wallet, download an app -- not sure it's a choice vs. that's what I'm supposed to use. Don't know how much trust user puts in all these pieces. Local government, app store, browser, site -- 09:58:02 helen: Just like Android Play store, if individual installs app -- there is also Play Store Policy to review to ensure that wallet app is ok... if we find malicious apps, we could do review of app and kick them out of market. 09:58:22 yeah basic trust model between issuer-holder-verifier does not change with this API ideally.. 09:58:34 +1 Kristina 09:59:27 rbyers: The threat model of this API is different from larger threat model -- larger conversation is bigger than this API, there are things we can do here... transparency... trust but verify, have browser involved in enabling civil discourse and public tradeoffs. You can have trusted communication w/ Android apps, we already have a model where we don't have much protection when website is colluding w/ app ... we don't have something to add here wrt. 09:59:28 how web-android works today. 10:00:07 npd: We want to do better than that, collusion might be the most common way this engagement could happen. 10:00:07 q+ 10:00:13 oooh ooh, at least we got an easy answer to that first question! :) 10:00:54 rbyers: We are committed to doing the work in the WICG, don't want to exclude mdoc folks, what's why we chose WICG instead of CCG... where would the proper WG be -- narrow down explainer and goals and imagine coming up w/ charter for WG. 10:00:54 rbyers: Calls not scheduled yet, start link will take you to github issue -- will try to pick meeting soon. 10:01:02 rbyers: Tim will try to select meeting place soon. 10:01:38 Topic: PING Review 10:01:42 Topic: PING 10:02:07 brentz: We welcome PING to discuss their review and other items as they see fit. 10:02:16 S/Topic: PING$// 10:02:22 npd: Happy to talk about review issues. 10:02:49 kristina: We have certain issues that we're trying to review and address the horizontal review from PING. 10:02:53 https://github.com/w3c/vc-data-model/labels/privacy-needs-resolution 10:03:17 The PING request for vc-jose-cose is https://github.com/w3cping/privacy-request/issues/125 10:04:02 brentz: for visibility and transparency's sake -- we've triaged most of these as during CR -- we don't think they'll result in normative changes to the spec, mostly guidance, do these items require normative changes? 10:04:08 The related security request is https://github.com/w3c/security-request/issues/60 10:04:23 brentz: Is what we've come up with amenable -- 1271 first 10:05:08 npd: Can we talk about process point there? W3C Proces is evolving, my impression is that in typical case all issues in wide review need to be addressed before transition to CR -- these things are normative these things are non-normative -- all issues need to be addressed. 10:05:41 subtopic: https://github.com/w3c/vc-data-model/issues/1267 10:05:44 q+ 10:05:49 q- 10:06:15 Sgoto_ has joined #Vcwg 10:06:16 scribejs, set npd Nick Doty 10:06:16 guest+ npd 10:06:23 brentz: This one is about use of OHTTP in the spec, as of yet, OHTTP isn't yet finished at IETF, can't reference it normatively, add encouragement that people make use of it when they can, when they make use of HTTP. 10:06:26 ack kristina 10:06:59 Sgoto2 has joined #Vcwg 10:07:15 kristina: Similar to brent, we do have concerns about pointing to OHTTP since it's a draft at IETF... don't know if it's mature enough to recommend it -- OHTTP should be used once it's ready, is something like that acceptable? 10:07:16 q+ 10:07:22 kristina: What are other WGs doing here? 10:08:40 that makes more sense 10:08:56 ack manu 10:08:58 npd: Rather than the specifics about OHTTP, it seems like recommendation is identifying when there is a threat about identifying IP address and using privacy preserving proxy, when you do that in a way that you can collude, use privacy preserving proxy... don't need to make normative reference to OHTTP, you can say when it's a threat and use privacy preserving proxy 10:10:50 manu: what about a CDN, would that work? 10:11:29 npd: Usually CDN works on behalf of issuer, so I don't think we'd say "that gives you privacy" -- some resources could be cached in a way that decreases how there is a request back to origin server, but I don't think we think about CDNs protecting you from colluding from server learning about the request. 10:11:53 brentz: I think we have enough direction to move forward on this issue... before CR w/o being assigned to it... otherwise, first thing we tackle before meeting again. 10:12:07 subtopic: https://github.com/w3c/vc-data-model/issues/1247 10:12:43 brentz: What is the plan for this item moving forward. 10:13:20 Jay has joined #vcwg 10:13:37 kristina: There needs to be a recommendation on how verifier stores/manages user data, we need something around that, something similar -- is that sufficient? Doing all we can at technology level, everything else at governance layer. 10:14:09 q+ 10:14:12 npd: I understand that some things have to be enforced elsewhere, is it standardized to communicate that something shouldn't be stored, or hope that receiver shouldn't know that things should be stored 10:14:13 ack kristina 10:14:14 q+ 10:14:44 q+ to meantion ToU 10:14:48 kristina: There are ways to communicate that -- intent to retain, but that's out of scope, we can only talk about data model and how to sign it, we could tell people to use protocols to use those features. 10:14:49 ack manu 10:15:05 q- 10:15:18 manu covered what I was going to say 10:17:11 npd: One of the challenges of having all these different layers/specs -- don't immediately have an idea on flags being needed in data model vs. protocol, where should that flag be? It just seems unlikely that we can expect receiver of the data to know how they should treat the data or user can make decision w/o having some promise about what they're going to do w/ the data. 10:17:15 manu: we have terms of use, but it is set to be deprecated 10:17:19 q+ 10:17:26 ack dmitriz 10:17:31 npd: We can't define how to enforce that in this group, we might want to figure out how to do that. 10:18:39 dmitriz: The thing that comes to mind here is know verifier list -- by having to present a trusted UI to the user "so and so company is requesting credentials" -- we need "known verifier lists" vs. "known issuer lists" for issuance. The data retention policy can be stated and monitored and legally enforced on that layer. Known verifier lists are coming down the pipeline eventually, something to think about. 10:19:26 subtopic: https://github.com/w3c/vc-data-model/issues/1246 10:20:09 This one is tricky w/ nature of charter, not chartered to deal w/ protocols, at same time, wondering what the best path forward is here. 10:20:17 s/This one is/brentz: This one is/ 10:20:21 q+ 10:21:19 q+ 10:21:51 npd: This is a relevant open question about whether the user by definition trusts the wallet or whether that wallet did something that doesn't protect their privacy. Again, I don't know what needs to be defined in which spec. Perhaps it's a protocol question, but we're in a situation where it's not clear -- is the wallet acting on behalf of user -- or is wallet a piece of software acting on some other entity's behalf -- user needs to protect 10:21:51 themselves from that piece of software. 10:21:56 selfissued_ has joined #vcwg 10:22:02 q? 10:22:04 present+ 10:22:15 q+ to say both with be trust (user agent or not) 10:22:15 ack dmitriz 10:22:15 npd: That is a question we're going to have to answer, don't know if it needs to be in this spec or not, which party is user agent. 10:22:48 dmitriz: From phrasing of the comment, that last sentence is to highlight trust boundary, would it be sufficient to highlight the trust boundary -- wallet is in position of power, it is a user agent, it should be treated as such? 10:22:54 ack kristina 10:23:46 ack JoeAndrieu 10:23:46 JoeAndrieu, you wanted to say both with be trust (user agent or not) 10:23:47 kristina: I do think we can address that, it's in scope, users are not directly tied to software they're using -- don't know if we should introduce term wallet, but adding a few sentences here should be appropriate. 10:23:59 do we actually use the term 'holder software'? 10:24:05 (I know we have 'holder') 10:24:14 I don't believe we do 10:24:20 JoeAndrieu: Our presumption is wallet is user agent, but people will need to use wallets under control of other entities, when you're acting on behalf of us, having understanding of trust boundaries allows one to understand risks when using technology. 10:24:28 +1 Joe 10:24:44 brentz: We could add some guidance, but at this layer there's not much we can do what we can enable/enforce. 10:24:46 q+ 10:24:56 ack manu 10:25:52 manu: We do have privacy/security considerations, we can state things in there. 10:26:06 subtopic: https://github.com/w3c/vc-data-model/issues/1245 10:26:43 brentz: Gabe can you let us know if you're ready to move forward on this? 10:27:15 decentralgabe: Issuers being considerate of information they're disclosing... can do PR soon. 10:28:22 npd: Just to clarify this, in some models, privacy pass -- separate attester and issuer, attester is doing detailed subject matter evaluation, pass on fact of user w/o passing information on -- if I pass on single claim from DL, you get claim and details about who signed it -- which authority issued the DL 10:29:07 q+ 10:29:15 npd: Who issued is more substantial than piece of information I'm revealing, user has asked for age -- and actually what is being rquested is not age, but what is sent i who government authority is. 10:29:24 ack manu 10:29:28 q+ to say the issuer is the authority 10:29:52 q+ 10:30:06 q- 10:30:29 this is what we wrote for SD-JWT: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-issuer-identifier 10:30:34 on the issuer identifier 10:31:05 ack brentz 10:31:33 manu: There are systems that exist, that takes in a identifying VC that translates to a privacy preserving VC, then uses the privacy-preserving VC. 10:32:31 there is a section https://w3c.github.io/vc-data-model/#issuer-cooperation-impacts-on-privacy 10:32:32 brentz: Yes, Gen is working on similar model, we can translate one VC to another to create that privacy preserving thing such as what TruAge does. Their trust in the system is what enables it to work. I do think that we need to, if we haven't already, note that trusting issuer can reveal thing sabout it, additional information there could help. 10:32:46 decentralgabe: I'll add more details in that section. 10:33:02 brentz: If there are no other comments on this issue, w/ VC data model, moving on to other items. 10:33:05 subtopic:https://github.com/w3c/vc-data-model/issues/1244 10:33:53 brentz: This is another type of variation on previous issue... don't know if path forward on this is much different from what we just talked about. Happy to hear thoughts from group on this item 10:34:02 q+ 10:34:29 DavidC has joined #vcwg 10:34:30 q+ 10:34:34 present+ 10:34:50 ack kristina 10:34:51 npd: When we have non-essential properties that can vary, if we have recommended set of thoe properties, everyone can follow them, users can be in single anonymity set -- do you need variation in these things, or can there be recommendation of "everyonen that does credential in this style, use these parameters"? 10:36:26 ack brentz 10:36:27 kristina: Yes, not sure I agree, don't know how realistic this is -- even if federated identity, information about user can be in SAML assertion, and each representation can be a standard, but we can't force everyone to use same VC to do the same thing -- unfortunately, there are disputes on how to express credential at multiple levels -- how is plain text about user claims being represented, what cryptsuites are used, at every level there are almost 10:36:28 religious debates on what the best way to do this, don't want to touch this. 10:36:30 q+ 10:37:54 brentz: With the VC model, and notion of selective disclosure on presentation, every issued VC is ideally following -- for example DL, on issuance side, we have commonality on structure and data provided. Requring presentation of subset of credential even on metadata part of it other than few that we've already agreed to. I'm not sure what we can do about this issue. 10:37:56 ack manu 10:38:56 manu: this one's tricky. I think what Nick is asking for: ina perfect world we could establish best practices for certain credentials. e.g., an age verification credential should have a correlatable issuer and should only express a large bucket age range. 10:39:53 q+ to say issuers MUST be correlatable 10:40:05 q+ 10:40:06 ... and the WG could work to create an age-verification credential template with that information. We're not chartered for that yet, so we will need to use security and privacy condsiderations sections. We do have a sections that strongly encourages data minimization, i.e., selective disclosure. 10:40:10 ack JoeAndrieu 10:40:10 JoeAndrieu, you wanted to say issuers MUST be correlatable 10:40:51 JoeAndrieu: The model for validation in VCs does require issuer to be correlatable to see if particular identifier is someone they should trust -- if I want to see if someone can drive, I can't take self-issued VC -- that's something that's baked into the model, we can't get past that part of correlation. 10:40:53 ack npd 10:41:11 npd: This is helpful, the verifier only has some list of people that they trust in order for system to be functional, understood. 10:41:42 +1 to group mechanisms to mitigate correlation of issuers 10:42:28 npd: We can say if you can "group" that trust in some way, that can help user in some way -- so issuer corelation dosn't happen. About formats, if you're going to try to group issuers, you could group these other things -- that should be the recommendation, grouup issuers, but also focus on grouping attributes -- unify formats so you can't track it back to original issuer. 10:42:36 what we have put in SD-JWT and have received positive feedback "To mitigate this issue, a group of issuers may elect to use a common Issuer identifier." 10:42:41 brentz: that's helpful, we have good path forward. 10:43:28 kristina: We've written something similar for SD-JWT, but can't do that tomorrow, can eventually do that. 10:43:41 brentz: ok, assigning kristina. 10:44:25 brentz: Ok, let's look at vc-jose-cose and time box for status list. 10:44:33 pauld_gs1 has joined #vcwg 10:44:59 The privacy and security self-review for vc-jose-cose is at https://github.com/w3c/vc-jose-cose/issues/93#issuecomment-1720985793 10:45:13 It contains references to the requests for review to PING 10:45:17 q+ 10:46:13 selfissued_: There are comments to PING requests, we haven't heard back from them, but we've done process action to move this forward. 10:47:47 ack selfissued_ 10:47:50 here is the self-review from statusl list: https://github.com/w3c/vc-status-list-2021/issues/77 10:47:57 privacy review request is only an hour old, so hasn't been completed yet :) 10:49:45 Group discusses status list PING review use case. 10:50:30 subtopic: https://github.com/w3c/vc-status-list-2021/issues/86 10:50:34 manu: 10:51:54 ... this issue concerns our credential revocation mechanism called a status list. It started out as a big bit string, each bit represented a single credential . If there were 100,000 credentials in the list, then that's your herd size. These are public on the web. 10:52:49 ... if an adversary looks at the string of bits, they can't link this to the original credential, so along with a big enough herd size this is okay. We are going to encourage adding noise so that things are obscured further. 10:54:01 ... as of a couple of months ago, multiple different statuses for a single credential are possible, so multiple bits for same credential. The example there is a shipping container that may have multiple status values defined by the issuer. The concern is that by having multiple status values you may be reducing the size of the herd. 10:54:53 ... Not sure what the general question is. There is an assertion that adding more bits about each credential in the list, then correlation becomes easier. Adding randomized data may be more difficult, etc. 10:55:08 whether there are 1bit per credential or 3bits per credential in the bitmap does not help the verifier to correlate any better 10:55:15 ... looking for general guidance from PING on this approach and any concerns there. 10:55:20 q? 10:57:07 npd: Revocation problem is something we see in other areas, it's a common privacy issue for person checking being revoked -- verifier that's checking if something is revoked -- one concern is you want this to be consistent, issuer gives out credential, check the list and one problem you're having is you want issuer saying list is same for all credentials, not unique URL -- that's a tracking issue -- single credential can be tracked (which is not good). 10:57:59 npd: That is a common problem on the Web, some IETF work going on on consistency of resources, increasing number of things that website providing information can provide key -- provides same information to everyone, different keys, different lists won't become uniquely identified -- can we use similar mechanisms for something like this, so issuer is giving out consistent list URL. 10:57:59 q+ 10:58:23 npd: Don't know, perhaps don't understand why revocation is in a public list? 10:58:54 brentz: The reason that it's public is so that there is less visibility on who is requesting it -- issuer hosts the list, gets less of an idea of where the lists are being used. 10:59:07 npd: Is goal to ensure verifier to know after the fact if something got revoked? 10:59:36 brentz: It would enable revocation/status changes to occur after issuance of credenial, reduce visibilty on where credntial goes -- enables verifier to get up to date status by querying momst current version of the list. 10:59:54 npd: i's not just at presentation time.... if I ever signed in w/ DL, at any future time they'll know if DL gets suspended? 10:59:58 brentz: That is correct. 11:00:11 npd: That seems scary to me. 11:00:20 q+ 11:00:23 +1 to scary 11:00:41 agree with the scary 11:00:45 npd: That doesn't seem like a goal, when I present my credential to an RP, they want to know it's valid, also they get to subscribe to changes to my DL? 11:00:55 ack manu 11:01:03 zakim, close the queue 11:01:03 ok, brentz, the speaker queue is closed 11:01:54 status list can be avoided with short lived creds but that kind of undermines the point of three party model 11:01:58 ack JoeAndrieu 11:02:29 JoeAndrieu: Manu said close to what I said -- you could provide proof of status, I don't think we handle that well -- conceptually, you could do that -- valid status you could check, but we haven't teased that out yet. 11:02:46 rrsagent, draft minutes 11:02:47 I have made the request to generate https://www.w3.org/2023/09/15-vcwg-minutes.html ivan 11:02:53 brentz: anything else for us before we break? 11:04:08 npd: Thanks for having me -- apologies for not coordinating better -- we are in situation where some privacy quetions are ecosystem wide, hard for any particular spec to answer it, but since they are going to increasingly occur, useful to us to work at an ecosystem level, who is being trusted where, where might privacy issues arise, so no individual spec author has to answer those questions. Perhaps we can work on it in this group or PING or overview 11:04:08 document somewhere so people can more easily reason about where privacy / security concerns arise. 11:04:28 kristina: There is trust model analysis going on, still in draft, still looking for input. 11:04:46 here is the trust/security that was the basis of a formal analysis: https://vcstuff.github.io/oid4vc-security-and-trust/draft-oid4vc-security-and-trust.html 11:04:53 wait when's next break end? 11:04:55 the formal analysis will be published soon too 11:04:59 rrsagent, draft minutes 11:05:00 I have made the request to generate https://www.w3.org/2023/09/15-vcwg-minutes.html ivan 11:05:44 ivan has joined #vcwg 11:06:30 dmitriz -- ~84 minutes from now 11:31:54 Jay has joined #vcwg 12:11:04 kaz has joined #vcwg 12:27:36 ivan has joined #vcwg 12:29:53 pauld_gs1 has joined #vcwg 12:30:45 dmitriz has joined #vcwg 12:31:10 scribe+ 12:31:20 andres has joined #vcwg 12:32:08 JoeAndrieu has joined #vcwg 12:32:48 brent has joined #vcwg 12:32:52 present+ 12:32:58 present+ 12:33:00 present+ pauld_gs1 12:33:02 kristi has joined #vcwg 12:33:06 decentra_ has joined #vcwg 12:33:08 present+ 12:33:11 present+ 12:33:21 selfissued has joined #vcwg 12:33:23 present+ 12:33:48 brent: core data model as 23 open issued labeled "before_cr". 5 labeled ready for PR. 18 that needs PRs. 12:34:26 A handy link: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+-label%3A%22ready+for+PR%22+-label%3A%22pr+exists%22 12:34:29 q+ 12:34:33 y-sakuma has joined #vcwg 12:34:44 brent: correction 9 have PR exist so there are only 9 that need resolution. 12:34:48 zakim, open the queue 12:34:48 ok, brent, the speaker queue is open 12:34:48 q+ 12:36:46 i/brent: core/Topic: CR status/ 12:37:26 brent: anticipate that candidate recommendation is likely to take a while. 28 days is the minimum 12:38:08 brent: we will be fortunate to find time for 2 CRs. If we don't go soon, we may not have time for more than one. 12:38:12 https://w3c.github.io/spec-releases/milestones/ 12:38:46 brent: ideal route is to have PR in my may. Working backwards, we need to be in CR now. Concern about 9 open issues. 12:39:01 s/in my may/in by may/ 12:39:05 q? 12:40:27 brent: goal of the session is, "What is the CR plan for each of these documents". 12:40:28 ack manu 12:41:31 manu: there is an expectation that all horizontal review comments are addressed before CR. Checked process and that does not seem to be the case. All comments in issue tracker don't fall into that category. nothing in the process says that that work needs to be done before CR. 12:41:56 ... an acknowledgement of Nicks assertions and we ended up re-categorizing issues as before CR when we didn't need to. 12:42:38 ... though there are 9 items here, some are horizontal tracking issues. If we have people raise PR on these issues it should be easy to transition into CR by October 12:42:58 present+ 12:43:46 q? 12:43:46 ... already have a test suite for it that exists with tests for all normative statements except for ones in the last few months. 12:44:06 ... modifications this time around are not that heavy and we have a test suite with a variety of tests in there already. Timeline looks realistic. 12:45:15 q+ 12:45:22 ack manu 12:45:36 brent: For the core data model, is it a reasonable expectation for for all ready-for-pr issues to have PRs in for review week of 25 sept. 12:46:23 manu: For ones assigned to me, yes. can't speak for others. Imagine for a lot of these is possible to have a PR in. The language one needs to get discussed as a group. The related resource one needs to be discussed as a group. 12:47:04 q+ 12:47:18 q+ to suggest 2nd week of October as "too late" 12:47:25 q= 12:47:28 Q+ 12:47:34 q- later 12:47:35 brent: At what point should we look at an issue and say we don't have time. I'm feeling like my definition of too late is earlier than others. Wants to have confidence and a plan in place to deal with lingering issues 12:47:37 ack andres 12:48:37 andres: For clarification, there is a risk that if we don't get through these when we go to CR, that might increase chances to repeat CR. 12:48:54 ack ivan 12:48:56 brent: as to which issues pose the most risk, I can't say. 12:49:42 q+ 12:49:50 ivan: Issue 870 is marked as pre-CR and open since Feb 2022. So far we are unable to find a consensus. Can we accept that we cannot find a consensus and close it. I remember this one, but there may be more. 12:49:51 ack manu 12:49:51 manu, you wanted to suggest 2nd week of October as "too late" 12:51:06 manu: by the second week of October, we can close the door and say that is it and leave remaining issues to be delayed to a future group. 870 feels medium risk to me. Related resource feels high risk. String value in Jose fields seems high risk. Everything else feels addressable or non normative guidance. 12:51:07 ack brent 12:51:42 q+ 12:51:49 ack manu 12:51:51 brent: Agree with almost everything except 870 which I consider high risk if we don't solve it in a way that appeals to reviewers. 12:52:08 q+ 12:52:09 manu: Meaning the only resolution is to remove from the spec and add it as a reserved or deprecated term. 12:52:23 ack dmitriz 12:52:24 brent: That is my preference. Either something normative or not be in the spec as a reserved term. 12:53:03 q+ 12:53:08 q+ to note https://w3c.github.io/vc-specs-dir/#evidence 12:53:08 q+ 12:53:16 ack ivan 12:53:17 dmitriz: We have addressed all the comments in 870 except the completely different issue which is range and domain for the vocabulary. We can in good conscience move these to a separate issue and close this one. 12:54:11 ack manu 12:54:12 manu, you wanted to note https://w3c.github.io/vc-specs-dir/#evidence 12:54:15 ivan: Removing the domain for the evidence property is easy to do, but I am not sure that there is consensus to close the issue if that is done. 12:54:19 the consensus on the domain/range issue is a completely different matter though 12:54:25 can we at /least/ split it out to its own issue? 12:55:20 manu: 1EdTech (sp) in a normative specification they publish use the evidence field. Can we site that as a concrete usage of the property by another standards settings group. 12:55:20 q+ 12:55:53 manu: to elaborate. We already have demonstration of 2 specification that use this property as an extension point. Is that enough? 12:55:53 ack brent 12:55:53 ack dmitriz 12:55:59 dmitriz: question for manu. The matter of evidence has been resolved. What remains is a completely different issue. 12:56:29 brent: What 870 has come to represent is the existence of the evidence extension in the spec and what we are going to do with it despite how this issue began. 12:57:02 ... if the group is comfortable saying that one way to do this is by using the education spec, then in my opinion we can keep the property in the spec. 12:57:24 We define it in the core spec, and here is an example of another standardization body using it: https://www.imsglobal.org/spec/ob/v3p0#evidence 12:58:15 q+ 12:58:20 brent: I am afraid its too late, if PRs are not submitted by the 2nd week of October then we have to drop these. 12:58:58 DavidC: I believe the education group has set the type and id field wrong. They have the type as a set. 12:59:07 type can always be a set... 12:59:08 q+ to note that we might get objections to certain issues not being resolved, but clearly, everyone knows that. 12:59:11 brent: This is another indication that we dont have consensus to point to this spec. 12:59:21 ack DavidC 12:59:26 Jem has joined #vcwg 12:59:32 ack manu 12:59:32 manu, you wanted to note that we might get objections to certain issues not being resolved, but clearly, everyone knows that. 12:59:33 q+ 12:59:40 brentz has joined #vcwg 12:59:49 q? 13:00:25 ack kristi 13:00:25 manu: some people who raise these issues might get upset, but we can proceed as stated. We can discuss the ed spec usage in the issue. 13:01:37 kristi: back to point on horizontal review issue. Chairs already told nick to address these before CR. My interpretation of the review process is that these issues are addressed before CR. The current plan is to address the normative and non-normative horizontal review comments before CR. 13:01:51 q+ to raise concerns about what was just stated. 13:01:53 q+ 13:02:00 ack manu 13:02:00 manu, you wanted to raise concerns about what was just stated. 13:02:03 brent: is there more before-cr issues to discuss, if not we will move on to the other specs. 13:02:11 qq+ 13:03:05 manu: concerns about the plan as a change to the goalpost. The resolution should hold. Can we keep the resolution, make the PRs as fast as we can 13:03:20 ack brentz 13:03:20 brentz, you wanted to react to manu 13:03:21 kristi: chairs will talk and report on the mailing list 13:03:32 manu: Having just read it I disagree with the interpretation of the process 13:03:38 ack decentra_ 13:03:54 decentralgabe: are the issues that we discussed for the privacy review still urgent to complete. 13:03:57 brent: yes 13:04:40 subtopic: VC JOSE-COSE 13:04:58 brent: move to vc-jose-cose and get a sense of what it takes to get that to CR. 13:06:43 selfissued: we don't have all that many issues or PRs without agreement. One is ready to merge after it ages out for a week. The big rock is to add DID support to the specification. 13:07:15 ... have not had a conversation with orie about possible next steps. We can look at issues and see if there are people assigned to all of them 13:08:20 brent: not sure if that is the best use of time right now. vc jose cose editors should get together and review the discussion of this week. Is it reasonable to have a CR plan presented by the editors in two weeks.tors 13:08:32 selfissued: yes. I can get together with orie and write things up. 13:08:52 brent: moving to vc-status-list 13:08:53 subtopic: vc status list 13:09:40 manu: VC status list still has a large number of issues. But given progress during TPAC, I think we got the biggest concerns addressed. That should make the remaining PRs easier. Its not realistic to go into CR before end of October, mid-November. 13:10:32 manu: as far as test suite is concerned, we had a test suite for single-bit status list, but now that we are doing a combined approach, the test suite will have to be re-written. This could potentially happen in parallel. 13:11:21 q+ 13:11:55 ack ivan 13:11:55 brent: co-chair has noted that getting to a first CR as quickly as is reasonably done anticipating that a second CR is needed. Rather than hurrying into a CR, the editors could have a plan in place that demonstrates the could have a single CR. Dont think that could happen for the core data model. 13:12:08 q+ to note that surviving CR with a single iteration for a v1.0 spec doesn't happen? :) 13:12:24 that is my fear 13:13:20 ivan: second CR may be misleading for folks that don't understand all the details. We enter CR with one document. There are two possibilities. We can update the CR draft. This is something we can do as easy as we do with the working draft. We can issues new CR snapshots, as many as we want, as often as we want, and that is not a huge deal. Except that is has to go through a slower publication mechanism (through me). 13:13:57 ... the only big difference is that the snapshot is issued when there is a major technical change that invalidates earlier test. Would not overestimate the weight of publishing additional CRs once we enter CR. 13:14:52 ... small, non normative, editorial changes that do not jeopardize testing can be done easily. 13:14:52 q+ 13:14:52 brent: each snapshop does require a minimum 28 day period. Meaning we can only do one every 28 days. 13:15:25 ivan: correct 13:15:25 ack manu 13:15:25 manu, you wanted to note that surviving CR with a single iteration for a v1.0 spec doesn't happen? :) 13:15:25 manu: keep in mind that we have CR drafts as soon as something merges to main. CRDs we can iterate quickly. 13:15:29 iivan: that is echidna 13:16:25 manu: once we are in CR we can iterate rapidly. We don't need to waste a CR snapshot for each change. We can pile them up until we feel strongly that we have what we need and are confident 13:17:34 q? 13:17:37 brent: to add nuance. Yes, we can introduce drafts rapidly and produce a snapshot when ready. but when making these changes we will need another snapshot. 13:17:46 q+ to 'cause I wasn't done making my point yet :) 13:17:55 ack TallTed 13:18:02 ivan: to give an example, we accumulated lots of change and when we want to go to PR we issue a snapshot 1 month before. 13:18:52 TallTed: the changes that we make to the CR draft do not have to be published to CR. Best if we did, but there is nothing that mandates that we must. the CR snapshot does not open a door for 28 in which we cannot publish another. It restarts the clock. 13:19:26 kristina has joined #vcwg 13:19:29 ack manu 13:19:29 manu, you wanted to 'cause I wasn't done making my point yet :) 13:19:30 present+ 13:19:33 brent: I was told this was frowned upon 13:19:35 zakim, close the queue 13:19:35 ok, kristina, the speaker queue is closed 13:20:26 manu: everyone want to finish on time or under time. If we get to CR and are seeing multiple implementations and progress, charter extensions are usually granted. I have not seen one declined in this instance. 13:22:21 zakim, open the queue 13:22:21 ok, kristina, the speaker queue is open 13:22:21 brent: for the core data model, we know the scope and have a plan. For jose-cose we are going to hear from the chairs by the next meeting. We heard VC status list is on track with more of plan laid out in the weeks ahead. Chairs need to consult regarding resolutions for data-integrity and how they are impacted by the knowledge we have for expectations for horizontal reviews. 13:22:21 topic: test suites 13:23:23 q+ to speak to test suites for the ones they're working on 13:23:23 brentz: every spec we bring to req track needs a test suite. Would like group to be aware of the plans for test suite. 13:23:23 ack manu 13:23:23 manu, you wanted to speak to test suites for the ones they're working on 13:23:47 q+ to talk about json schema test suites 13:23:54 manu: data model 2.0 data-integrity ecdsa and ecdsa all use the same test framework. All have multiple implementers. 13:25:31 ... plans to add docker support but we have to prioritize what we are implementing. Priorities are test coverage. one we have that, implement extra features such as supporting vc-jose-cose output format. I don't know if there are plans for cose signing. we can add support for that so we can extract the payload and test against vcdm 2.0. Work with game on docker support. questions? 13:25:35 q+ to ask how DI and VCDM are incorporated or not 13:25:36 q+ 13:25:46 ack brentz 13:25:46 brentz, you wanted to ask how DI and VCDM are incorporated or not 13:26:17 brentz: how are data integrity and vcdm test suited incorporated or not. When you test data integrity are you also testing the core data mode. 13:26:26 s/mode/model/ 13:27:59 manu: you make a call to a system and send it a payload which is a vcdm payload where you ask it to secure something and you get one back. Assumption is that the signer will do the tests in the vcdm. vcdm 2.0 test suite is supposed to be agnostic to the securing format. For data-itegrity test suite they care about the securing formats. Does that answer your question? 13:28:27 q+ to speak to spec -> test cases 13:28:36 andres: what does the process look like to go from spec to test case. Is that manual or automated. 13:28:41 ack andres 13:28:49 q- 13:28:58 ack manu 13:28:58 manu, you wanted to speak to spec -> test cases 13:30:25 manu: its a manual process. There are tools to extract normative statements, but they are not perfect. 13:30:50 subtopic: vc json schema 13:31:35 decentralgabe: currently there is an implementation somewhat like the test suites manu mentioned. But you have to implement a CLI in the docker container. This CLI can call through to your server or API. There is a set of tests, one for each normative statement, with a manual mapping. 13:32:23 ... I think its fairly straightforward and happy to work with manu on other test suites to align. Shopping around for folks with implementations to add to the test suite. 13:32:25 q? 13:32:26 +1 happy to work w/ decentralgabe on aligning how these things function, especially pulling their docker stuff in, if possible. 13:33:06 brentz: Do you know of other implementations aside from blocks'. 13:33:17 decentralgabe: transmute has one but have not written an implementation for the test suite. they will not implement both types. Looking for someone to implement both types. 13:33:22 subtopic: vc jose cose 13:33:47 q+ 13:33:51 ack manu 13:33:52 selfissued: orie has code, but I don't know what it does and doesn't do. 13:34:02 brentz: can you make this part of the CR plan 13:34:04 selfissued: yes 13:34:57 q+ 13:34:58 q+ 13:35:07 manu: Looked through the test suite and have concerns that it does not test the normative specifications. It has vectors but that not how test suites for W3C specification work. Add this to the list of things to discuss. 13:35:17 selfissued: understood. 13:35:34 kristina: I don't think the test are done yet. 13:35:51 q+ 13:35:54 selfissued: any W3C process or guidance on the way these tests need to be factored? 13:35:56 ivan: no 13:36:09 ack ivan 13:36:10 kristina: minimum, all the normative requirements must be tested. How they are tested is not specific. 13:37:02 q- 13:37:07 features must be tested, not necessarily normative statements, but all stamenets must be covered. 13:37:08 ivan: one possible organization of the testing is to start with the must statements and do one test for each. Its also OK to do a test that covers more than one must statement. There is no one-to-one requirement. However, if the second option is used, it must be documented. 13:37:14 ack manu 13:37:45 manu: note that the second approach can be painful because if someone fails one part but not another it creates arguments. advice. 13:38:05 brentz: is there any other conversation about vc-jose-cose test suites to have. 13:38:14 selfissued: not that I am aware of at this time. 13:39:02 topic: Use Cases 13:39:29 present+ 13:39:36 JoeAndrieu: we have a new focal use case contributed by Kevin. 13:39:40 present+ KevinDeanGS1 13:40:48 KevinDeanGS1: the use case GS1 put together focuses on the GS1 identification system. For those that are not, we are the barcode people. That numbering system is managed by GS1. There are a number of other supply chain standards for master data, supply chain data, traceability, and so one. 13:41:46 ... as part of our credentials in GS1 is a chain of credentials. GS1 grew up in the non connected era in 1970s. The system had to be developed to support unique identification without connectivity. 13:42:08 ... the core identification is managed in Brussels and then delegated to organizations around the world. 13:42:42 ... For example global delegates a number range to GS1 Canada, which delegates a subset to a company. 13:43:17 ... We end up with globally unique ID for trade items because the ranges issues are unique within the scope of the issuer of that range. 13:43:44 subtopic: https://github.com/w3c/vc-use-cases/issues/146 13:43:59 ... in order for the identifier to be valid, that chain of ranges must be valid. There are rare circumstances that companies go out of business and their right to issues identifiers from the range is revoked. 13:44:33 present+ 13:44:37 q? 13:44:52 ... a chain of GS1 credentials to identify a trade item. Also applies to anything else that uses a GS1 identifier, but we focus on a trade item as its the most common use of identifiers. 13:45:35 ... this use case has been provided by GS1 and we are happy to have our name there. \ 13:46:36 ... the use case addresses mergers and acquisitions. Its important that the GS1 license of the acquired company transfers ownership to the aquiring company. This doesn't invalidate any of the credentials generated previously. 13:47:03 ... this is because they were created at the time when the license was valid. 13:48:46 ... to break this down we consider the actors in the document. GS1 prefix is issued to the member organization (country). The GS1 company prefix is issues from a member organization to a member company (example company). 13:49:47 ... holders are typically the subject but could be other entities. In some cases large CPG companies have a separate company that manages digital assets including company prefixes. 13:50:18 morimori has joined #vcwg 13:50:18 ... the verifier is any trading partner that needs to validate the license. 13:50:52 q? 13:51:24 ... the GS1 prefix license is valid if issue by global office. the GS1 company prefix credential is valid if it points to a prefix license credential. The GS1 GTIN/key credential is valid if it points to a valid company prefix crednential. 13:51:57 ... examples are provided in the document. 13:52:07 selfissued has joined #vcwg 13:52:10 present+ 13:52:11 ... a more complete description is in a whitepaper on the website. These are still in proof of concept but are in use by other organization in their own proof of concepts. 13:52:13 q+ 13:52:14 q+ 13:52:18 ack manu 13:53:30 manu: are there thoughts you have on upgrading to VC 2.0 data model. We have things like related resource that might modify the way you are modeling data. 13:53:30 KevinDeanGS1: Its a priority item but it a question of resources. 13:53:30 manu: same for credential status. 13:54:08 KevinDeanGS1: there is. Credential status is one of the things we are really interested in. Its more than just revocation and suspension> 13:54:34 ... we will not put an expiry date into the credential as some companies maintain these licenses indefinitely. 13:55:50 ... we need some way of saying that this credential has been transfered. There is a new credential that replaces this credential. That may require following multiple validation paths. 13:56:16 Sounds like an HTTP 301 Moved Permanently redirect! 13:57:06 ... GS1 credentials are public, but its up to member companies whether they make their credentials public or not. 13:57:16 q? 13:57:18 manu: is that captured in the use case? 13:57:32 andres has joined #vcwg 13:57:35 KevinDeanGS1: We do talk about the transfer of license credentials. 13:58:06 gkellogg has joined #vcwg 13:58:09 scribe+ 13:58:15 https://github.com/gs1us-technology 13:58:19 ack pauld_gs 13:58:43 pauld_gs1: Just a quick plug -- if you go to GS1 US Github page, you'll see two libraries, based on open source library from Digital Bazaar -- the other library applies business rules. 13:59:00 pauld_gs1: We're starting to roll this stuff up into code -- read from programmers point of view to see how it works. 13:59:01 scribe- 13:59:12 https://ref.gs1.org/gs1/vc/data-model/ 13:59:25 present+ 13:59:58 subtopic: other items on use cases 14:00:13 JoeAndrieu: put out a call for contributions. Wants examples of usage, name, url. don't want to endorse, just show VCs that are used in production or prototype. 14:00:21 brentz: do you prefer this in an issue or directly 14:00:33 JoeAndrieu: issue, please. 14:00:53 brentz: Last topic is the GSMA liason statement. Announcement before a break. 14:01:08 scribe- 14:31:20 ivan has joined #vcwg 14:33:34 present+ 14:34:10 scribe+ 14:37:25 andres has joined #vcwg 14:37:39 Topic: GSMA Liaison statement 14:37:50 kristina: We have received a liaison statement from GSMA which will be discussing. 14:38:23 decentralgabe has joined #vcwg 14:38:55 kristina: Our data integrity BBS work is interesting to GSMA. This liaison statement is a request to coordinate work between our working group and GSMA. 14:39:14 kristina: One of the implications would be nominating contacts for the coordination. 14:40:15 q? 14:40:15 brent: We already have existing relationships with organisations such as ITU. In practice, this GSMA relationship could result in more reviews for our specifications. 14:40:22 ack JoeAndrieu 14:40:29 q+ to express support and note they asked some direct questions 14:40:43 JoeAndrieu: who do we reach out to? 14:40:44 ack manu 14:40:44 manu, you wanted to express support and note they asked some direct questions 14:40:51 brent: The chairs and staff contacts have that information. 14:41:47 manu: They are being pretty direct and asking specific question. I would expect that the GSMA would put forward invited experts. They are no longer a W3C member, which might complicate their involvement. 14:41:48 yes, GSMA will need to have an official venue to participate 14:42:11 manu: I don't know whether we need to respond before the liaison is set up. Ivan, what's the process here? 14:42:44 ivan: We set up the liaison first. 14:43:10 ivan: Brent should respond on behalf of the WG to the email. 14:43:31 q+ 14:43:50 Thank you to the Chairs for chairing and staff for staffing! Thank you Brent, Kristina, Ivan! 14:43:52 jyrossi has joined #vcwg 14:43:59 Thanks all! :) 14:44:09 rrsagent, draft minute 14:44:09 I'm logging. I don't understand 'draft minute', ivan. Try /msg RRSAgent help 14:44:56 rrsagent, draft minutes 14:44:57 I have made the request to generate https://www.w3.org/2023/09/15-vcwg-minutes.html ivan 15:03:15 bruno has joined #vcwg 17:03:23 Zakim has left #vcwg