14:59:32 RRSAgent has joined #vcwg 14:59:32 logging to https://www.w3.org/2021/10/26-vcwg-irc 14:59:42 zakim, start the meeting 14:59:42 RRSAgent, make logs Public 14:59:44 please title this meeting ("meeting: ..."), brent 14:59:58 shigeya has joined #vcwg 15:00:08 meeting: Verifiable Credentials Working Group TPAC part 1 15:00:16 chair: Brent Zundel 15:01:40 burn has joined #vcwg 15:01:44 Agenda: https://www.w3.org/events/meetings/8954d07a-b7e5-414e-8e4d-23dd7ec62de2#agenda 15:01:44 clear agenda 15:01:44 agenda+ Welcome/Introductions/Logistics 15:01:44 agenda+ Scribe selection 15:01:44 agenda+ Agenda Review 15:01:44 agenda+ Review of Current Charter 15:01:46 agenda+ Next Steps for New Charter 15:01:49 agenda+ Leaving maintenance mode 15:01:51 agenda+ V2 items and the new charter 15:01:53 agenda+ Verifiable Credentials Data Model v2.0 15:01:56 agenda+ Are there necessary/desired changes not currently reflected by any issues? 15:01:59 agenda+ Other ideas for improvements 15:02:01 agenda+ Other Recommendations and WG Notes 15:02:04 agenda+ Verifiable Credentials Working Group ( View Calendar) 15:02:06 agenda+ Download as ics 15:03:16 TallTed has changed the topic to: VCWG @ TPAC 2021-10-26 Agenda: https://www.w3.org/events/meetings/8954d07a-b7e5-414e-8e4d-23dd7ec62de2#agenda (second half collides with CCG @ TPAC) 15:03:58 ryuichi has joined #vcwg 15:04:31 scribe+ 15:04:47 Geun-Hyung has joined #vcwg 15:04:50 brent: plan for today: briefly review current charter, talk about next steps for new charter. 15:04:50 present+ 15:04:59 ... bulk of conversation: VC Data Model 2.0 15:05:01 present+ 15:05:23 brent: Goal is to make sure that what we want to work and what are chartered to work on have enough overlap. 15:05:31 ... Then ... will have more conversation 15:05:38 present+ 15:05:45 topic: Intros 15:05:46 present+ 15:06:01 brent: Please say where you are joining from and what company you represent 15:06:29 jay: I'm happy to join this VC, I'm coming from the W3C KO, also I'm a researcher for DID / blockchain work and other VC work. 15:07:13 scribe+ 15:07:21 PeterAnderson: I'm working for the Danish agency for digitization. We're looking into using verifiable credentials. Not part of the WG, just an observer. 15:07:22 cel: I'm charles Lehner from Spruce systems 15:07:28 ... working on VCs and DIDs 15:07:52 jeff: Hi, I'm Jeffe Jaffe, W3C CEO. I'm just making my rounds to various meetings at TPAC 15:07:57 brent: Very good to have you with us 15:08:13 kdenhartog has joined #vcwg 15:08:20 present+ 15:08:38 burn: Hi, I'm Dan Burnett. Executive director of Ethereum Enterprise Alliance. here as an invited expert. One of the original editors of the W3C Spec. Co-chairing WG with Brent. 15:08:50 dlongley: Hi, I'm Dave Longley with Digital Bazaar. We do a lot of work with VCs and DIDs. 15:09:04 Eric: Hi, I'm from Cleveland, Ohio. Here from Igalia, as an observer. 15:09:09 s/Ethereum Enterprise/Enterprise Ethereum/ 15:09:30 Geun-Hyung: Hi, I'm from ... South Korea. First time participating in this WG. I have participated in the DID WG. I am interested in Self-Sovereign Identity. 15:10:30 kdenhartog: Hi, I'm Kyle Den Hartog. I work for a startup in New Zealand called MATTR, working on DIDs and VCs. I'm one of the editors of the v1.1 and v1.2 work. 15:10:36 brent: Thanks, WRT timezones 15:11:01 manu: Hi, Manu Sporny from Digital Bazaar. One of the editors of the DID spec, and the VC spec, and some Linked Data Integrity work. 15:11:19 Ned: Hi, I'm from Intel, monitoring the direction of the group, trying to see how the tech fits into the bigger picture of things. 15:11:57 PhilArcher: Hi, I'm Phil Archer from GS1 Global. I've taken on a role to coordinate in this area. I'm involved in the work, passively. Involved in Asia Pacific... We should have been involved before. 15:12:41 shigeya: Hi, from Keio University. I'm part of the DID WG. First time to attend VCWG as a member. Interested in usage of VCs. Hope to have fun with this WG. 15:13:27 s/the work, passively/the DID work, passively/ 15:13:39 Shinta: Hi, Shinta Sato, I'm working for the .jp registry. 15:13:58 s/Keio University/Keio University. I'm attending as a member, not as W3C like Jay/ 15:13:58 s/Involved in Asia Pacific/I note the particular interest here from Asia Pacific. We're seeing that at GS1 as well/ 15:14:14 TallTed: Hi, I'm Ted Thibodeau from OpenLink Software. Involved in standards work for many years. Considering as a "thorn in paw" 15:14:23 present+ 15:14:35 wayne: Hi, I'm Wayne Chang, one of the co-chairs of the VCWG. Working on Spruce on VCs working with blockchain accounts. 15:14:49 present+ 15:15:24 brent: Hi, I'm Brent Zundell, working for Evernym. Contributed source code... Involved in W3C for 5+ years. Co-chair of DID WG and of VC WG. Involved in Credentials Community Group. Happy to be with you. 15:15:30 I work at Gooroomee. 15:15:35 s/Considering as a/I have sometimes been known as a professional/ 15:15:38 brent: Questions about the set of the meeting before jumping in? 15:15:47 q+ 15:15:51 present+ 15:15:52 ... We'll be using IRC to handle queue. 15:15:55 bmay_ has joined #vcwg 15:15:56 present+ 15:15:57 ... Type present+ 15:15:58 present+ 15:16:00 present+ 15:16:07 present+ 15:16:08 q? 15:16:19 ack manu 15:16:29 manu: Folks joined late... to do intros? 15:16:34 brent: Thanks, I see 15:17:05 bmay_: I work for a company called Distillery, developing audiences for Ad Tech. Learning about trust models and auth models on the web, to understand what privacy and a private web looks like going forward. 15:17:30 PamDingle: I'm Pam Dingle... [mic issues] 15:18:01 DanBuchner: Hi, I work for standards and research at Microsoft for DID and related work. 15:18:22 pamdingle: I work for Microsoft - as Director of Identity Standards, hello! 15:18:35 brent: Zakim created agenda items... 15:18:42 Topic: Review of Current Charter 15:19:04 https://www.w3.org/2017/vc/WG/charter.html 15:19:07 brent: Verifiable Credentials Working Group Charter ^ 15:19:11 Peter_B_Andersen has joined #vcwg 15:19:31 shinta has joined #vcwg 15:19:40 ... Not our current charter... 15:20:02 https://www.w3.org/2020/12/verifiable-credentials-wg-charter.html 15:20:10 ... Actually our current charter ^ 15:21:02 ... Scope is straightforward. Maintaining the VC Data Model Rec. Published as Rec near end of 2019. Our job has been for last few years has been to collect reports of errata, to find and address them, and do editorial cleanup. That's been the limit of it. 15:22:05 ... Due to significant overlap between this WG and other WGs (e.g. DID WG), for first year we were pretty dormant, addressing errata. Last several months have been more active, preparing revised rec, addressing editorial changes. 15:22:18 ... Goal is to release revised recommendation by end of year. 15:22:21 q? 15:22:24 q+ 15:22:26 ... Questions about what to do next? 15:22:31 ack manu 15:23:07 manu: We have talking about the v1 and v1.2 specs on the agenda... I'm planning we'll talk about challenges we've had in scheduling when that work will go out, reviews, refining. I expect we would talk about that... is that valid? 15:23:09 brent: Yes 15:23:28 ... Tomorrow is revised spec day. Everything we have done, need to do, and want to do. 15:23:34 q+ 15:23:44 ack phila_ 15:23:59 phila_: May I ask... I think no, but... is this the time now, today, to talk about scope of next charter? 15:24:16 ... And some of the problems we at GS1 see for this group to address, that are non-trivial, or...? 15:24:22 brent: That is what we are here to discuss today. 15:24:28 phila_: Thanks, I will contribute when it's time. 15:24:38 Topic: Next Steps for New Charter 15:25:08 https://github.com/w3c/vc-wg-charter 15:25:13 brent: The current draft is here ^ 15:25:59 ... This is a GitHub repository. We have been processing issue and raising PRs. The stage of this is that I stole text from a number of other charters, threw them into this draft charter, passed it around for feedback, incorporated feedback, and did that a couple more times. That's the status of it. 15:26:31 ... The contents of this proposed charter reflect a number of rounds of feedback. But it's not final by any means. Not yet gone to AC for review, not announced officially. Just a draft for participants in the WG. 15:26:41 ... Those who plan to participate in this WG are trying to hammer it out. 15:27:01 ... The scope described in the draft charter is pretty straightforward. We want to keep building on the experience we've gained over the last few years of implementing and deploying verifiable credentials 15:27:29 ... to extend the foundations of the first rec, within the scope of data models, registries..., algorithms for expression and verification of proofs using existing cryptographic primitives 15:27:46 ... Our of scope is specifying new cryptographic primitives, or specific supporting infrastructure 15:27:56 s/Our of/Out of/ 15:28:07 ... That is the current text for what is in and out of scope. 15:28:44 ... Deliverables: two: VC Data Model 2.0, and VC Linked Data Integrity 1.0 specification, to express proofs for bounded linked data integrity documents (e.g. VCs) 15:28:55 ... Primarily VC Data Model 2.0 for the second hour of today's meeting. 15:29:15 ... Other deliverables: non-normative notes, test suites for different credential proof types - expanding on the original test suite 15:29:37 ... Looking for a note for a presentation request data model, storing VCs..., exploring aspects of privacy around VCs 15:29:52 ... Another possible note: an API for VC exchange, we feel that would be in-scope. 15:30:09 q+ 15:30:16 q+ 15:30:18 ... This is a large set of deliverables, an ambitious set of work, but we feel that with the participants we anticipate being involved, it is a doable set of work. 15:30:27 ... Feedback is welcome 15:30:29 ack phila_ 15:30:36 q+ to note that "Verifiable Credential Linked Data Integrity 1.0" might be misunderstood as "too limited" 15:31:12 phila_: I'm very conscious of the fact that we (GS1) have not been involved in the VC work to date. We have been exploring our expected use of them... plan to issue credentials of our own. Plan to work with certification bodies. We see VCs as an important part of data infrastructure around the work. 15:31:19 q+ on multilingual support 15:31:35 ... Back in time... working at Ursim, Manu trying to get this work, I said nope... but then they got support and then it happened. 15:31:47 ... Conscious of that... but pleased to be here 15:31:54 ... The thing we need fixed is not in this charter, that's a worry 15:32:21 ... What state is this in? Should we invest in it? Others are... putting a lot of money in it... But which flavor of VC should we use? We're only going to build one, not 3 or 4 or 5... 15:33:07 ... What I'm looking for in this charter which I'm not seeing - please correct if I'm missing the point... We have different ecosystems... permathread of JSON vs JSON-LD... Hyperledger/IDUnion way of doing things... KERI DIDs - a different set altogether... what should I build? 15:33:21 ... Don't know yet... want to contribute to discussion to know what to build. We want to build it. 15:33:29 q+ manu2 to try to respond to what should we build 15:33:36 q- manu2 15:33:39 ack manu 15:33:39 manu, you wanted to note that "Verifiable Credential Linked Data Integrity 1.0" might be misunderstood as "too limited" 15:33:40 ack manu 15:34:09 manu: Linked data integrity 1.0 item... how we got there. When originally talking about rechartering this group, it would just be about VC Data Model. 15:34:27 pam has joined #vcwg 15:35:01 ... But when we tried to do linked data integrity work in the semantic web community, there was pushback... Multiple things we were trying to do... RDF Canonicalization, and Envelope formats for digital signatures. Not new cryptography, just to package up the digital signature to allow for new types of proofs, such as DLT-anchored proofs, merkel proofs, things that are not necessarily digital 15:35:03 signatures... 15:35:28 ... Two people objected strongly enough to that work... One a rep from Google... We didn't feel it could be resolved well. So we split the work up. 15:35:46 ... RDF Dataset Canonicalization hashing to be done in the semantic web group, great. 15:35:52 q+ 15:36:04 ... Linked data integrity: trying to do it just scoped for verifiable credentials. 15:36:07 q+ to try to respond to Phil 15:36:27 ... The solution is a generalized solution. Concern is that by titling it for VCs it is just a one-off solution, rather than a generalized solution for signing linked data. 15:36:33 specifically, the issue was with "unbounded data sets" -- and the solution was only ever for "bounded data sets anyway" -- such as VCs. 15:36:49 ... Raising this as a concern, to put it on the record... The intent is to focus on VC use cases, but to create a generalized solution for any bounded linked data document. 15:37:03 ... Want to make sure we don't accidentally make it only usable for VCs 15:37:11 ack shigeya 15:37:11 shigeya, you wanted to comment on multilingual support 15:37:21 q+ manu to try to respond to "what should we build" 15:37:58 shigeya: The kind of specification input for internationalization mentioned - lack of multilingual support... We need both English and Japanese in a single verifiable credential. 15:38:10 ... Without that, we need a domestic credential and an international credential... that's not useful. 15:38:23 ... I wonder if we can add multi-lingual support to credentials. 15:38:26 q+ to speak to "internationalization and multilingual support" <-- we have it today, but no good examples 15:38:37 ... In certain kinds of internationalization software, you can add something like gettext... 15:39:01 ... But for credentials, you surely need to cover the entire thing under the signature. We need to find a way to implement this multi-lingual support. 15:39:11 ... I hope it can be done in harmony with the current spec. 15:39:13 ack wayne 15:39:36 wayne: For the next chapter of verifiable credentials, I would like to see further definition around representations for proofs, whether for the embeddable proofs, or the VC encoded as JWT. 15:39:48 ... David Chadwick mentioned being able to strip that metadata 15:40:17 ... We're very interested in having embeddable signatures and better definition around that. We've encountered signatures not using RDF canonicalization, although our software supports both. 15:40:39 ack brent 15:40:39 brent, you wanted to try to respond to Phil 15:40:43 ... Some want to use JWTs... Also zero-knowledge cryptography in the data model... Want to see this in next charter 15:40:56 brent: I've met with the KERI folks and the ACDC folks 15:41:10 ... Specifically to ask, what changes do you see necessary for the next VC spec, to be more in alignment. 15:41:29 ... What it came down to is that the data model itself, even as it exists in 1.0, is flexible enough to be usable in those communities. 15:42:05 ... But the framing of the VC Data Model, and a lot of the concepts built into it, may need to be adjusted to better display alignment - but that it should be possible for them to produce essentially a ACDC VC Profile, if that makes sense. 15:42:27 ... I haven't yet heard anyone mention anything that I feel would be outside the current draft charter scope 15:42:43 phila_: That makes sense. I'm fully comfortable having a model that can be expressed in different ways. 15:43:06 ... Nevertheless, it does mean that if we are in the process... We're a global organization, federation, GS1 Australia independent of GS1 US, etc. 15:43:25 ... The exchange API in the charter... is that a way to take in a JSON-LD+BBS+ credential, and have it work with Hyperledger? 15:43:31 ... We've found that these things don't interoperate... 15:43:40 ... We want to do it... but please don't make us build 3 or 4 different systems. 15:43:42 ack manu 15:43:42 manu, you wanted to try to respond to "what should we build" and to speak to "internationalization and multilingual support" <-- we have it today, but no good examples 15:43:44 brent: Very fairly said. 15:43:55 manu: To respond to Phil's concerns, I certainly share them 15:44:07 ... Because we've seen some success with the VC 1.0 spec, there is this desire to expand it to doing more. 15:44:19 ... What we're seeing proposed in the current charter is more variability, not less. 15:44:27 ... I think that is the root of what Phil is concerned about. Certainly is for me. 15:44:37 ... I expect we may have no choice but to define that variability. 15:45:05 ... Different axise: JSON vs JSON-LD, going on forever... Only consensus has been to try to support both, in an awkward way, so people could choose not to support JSON-LD 15:45:15 ... But folks not happy with that, wanting to pick one or the other 15:45:29 ... The WG keeps being pulled into a state of awkwardly allowing both. 15:45:58 q+ to mention mDL, ICAO, etc formats 15:46:05 ... Other axis: how to do the digital signature: embedded or external. Again we could not come to consensus, proposed to do it both ways: external (JWT), or with linked data integrity. More optionality. 15:46:18 ... We keep saying we want a unified infrastructure, but innovating at the edges 15:46:23 ... Not making the hard decisions we need to 15:46:31 ... In an ideal world there would be one data model and expression mechanism 15:46:47 ... We didn't decide that, some think that's good, but it generated an enormous amount of work... Similar trap here 15:46:56 ... We all know the best decision is to give people one choice, that would force interoperability 15:47:07 ... But I don't think the group is ready to make that sort of hard decision 15:47:12 q? 15:47:14 q+ 15:47:15 ... Unfortunately that results in what Phil is concerned about 15:47:27 ... We feel the pain... Our customers want all the options, because we don't know what to pick. 15:47:47 ack kdenhartog 15:47:47 kdenhartog, you wanted to mention mDL, ICAO, etc formats 15:47:47 ... Our charter kicks the can down the road so that hopefully the market will make the decision for us. 15:47:53 q+ 15:48:06 skip for now 15:48:08 I'll come back 15:48:17 ack wayne 15:48:29 wayne: I just wanted to follow up about Manu's comments about flexibility. How we're doing it at Spruce... 15:49:05 q+ 15:49:12 ... Because it doesn't have to be a JWT, we can have conformant VCs working with blockchain accounts, 10s of millions of active users. We can cryptographically bind credentials to blockchain accounts using the proof section... Very valuable to us in our use cases, preventing creator fraud by doing so. 15:49:27 ... Being able to conform to the data model is great. Wouldn't want to not be conformant anymore... 15:49:27 ack phila_ 15:49:48 phila_: Thank you for the responses. I suppose, I take that point Wayne, once you build something, you don't want to change it - that's why we're afraid to build it. 15:50:06 q+ to note "API" is under development -- VC API -- not ready, yes, very important. 15:50:10 ... The last mentioned deliverable, the API for VC exchange, as one in a long list of non-normative deliverables - may have potentially more importance 15:50:39 ... Doesn't matter what system you use, there is an API you can use, put this in and get that out... could be any of these different flavors. Realistic, to get us past this point? 15:50:47 ack kdenhartog 15:51:17 dbuc__ has joined #vcwg 15:51:17 kdenhartog: Yes, also worth mentioning that outside the realm of where many of us operate are very similar aspects of technology, such as mDL (mobile driver license) at ISO, also ICAO (passports) 15:51:19 present+ 15:51:21 q+ to say the order of the deliverables does not reflect anything but the order they were thought of 15:51:25 q+ 15:51:33 ... effectively achieving the same product outcomes, but doing it in different standardized ways, maybe with different key infrastructure. 15:51:53 ... Remains relevant to ask ourselves if that fits with our work, in scope, to align with, or just let exist outside our realm of thinking. 15:51:54 ack manu 15:51:54 manu, you wanted to note "API" is under development -- VC API -- not ready, yes, very important. 15:52:06 manu: Yes, to follow up with what Phil said about API development... 15:52:18 ... I think I understand at a high level what Phil wants... That work is being incubated in parallel. 15:52:43 https://w3c-ccg.github.io/vc-api/ 15:52:46 ... Good news: there is a partial solution in the works, getting a lot of effort, the VC API. Multiple implementations, a test suite, weekly meetings to talk about the VC API (right now it's HTTP-based) 15:52:55 ... We meet every Tuesday at 4pm Eastern 15:53:16 ... It's not ready... It's implemented by multiple vendors, interopping, but under heavy debate of what it should or should not do. 15:53:28 ... We should pull it into the VCWG, but it's still in incubation... 15:53:33 ... Not mature enough yet 15:54:02 ... Will we ever have something that can translate from one digital signature format to another... In rare cases maybe, but in general you can't translate signatures between formats very easily. 15:54:20 q+ to say you can translate signatures without also transferring the root of trust 15:54:29 ... So unfortunately it's premature to propose that work... We are working on it, making painful progress, but expect another year or 1.5 years before ready to move into a WG 15:54:31 Thanks manu 15:54:51 ... Also want to highlight what Wayne said, I agree with everything said, but I want to say something controversial... We could pick one or two of these things. 15:54:52 kristina_ has joined #vcwg 15:54:57 q+ 15:55:11 ... There is one that addresses all the use cases, and another that is popular, implemented in industry, but does not address all the use cases we are thinking of 15:55:17 ... This is the linked data integrity vs JWT debate 15:55:31 ... My suggestion is to not use JWTs... they solve near-term problems but not long-term 15:55:58 ... If we had to make a hard decision, we should drop JWTS, support some version of it in linked data integrity... But I don't think that would happen... there would be formal objections 15:56:04 ... Similar for JSON vs JSON-LD 15:56:21 ack brent 15:56:21 brent, you wanted to say the order of the deliverables does not reflect anything but the order they were thought of and to say you can translate signatures without also 15:56:23 ... Trying to get it so the charter would not get formal objections. That is resulting in too much optionality, causing pain to GS1 members 15:56:25 ... transferring the root of trust 15:56:36 q+ Kristina 15:56:46 brent: Just to note that the order of deliverables in the draft charter is not reflective of anything. 15:56:51 ... Also want to invite PRs 15:57:02 q- Kritstina 15:57:13 q- Kristina 15:57:14 ... One of the best ways for these conversations to continue is for an issue to be raised in the draft charter repository, or even a PR for what you think the draft charter should say 15:57:18 ... Please don't hesitate to do that 15:57:41 ... Also to slightly tweak what Manu said, that it's not possible to translate a signature... It's not possible without transferring the root of trust 15:57:51 ... For vaccination credentials, there is the VCI SMART Card style... 15:58:06 ... and the VCI Blueprint style... more complicated 15:58:26 ... Good Health Pass said could convert a SMART Card into another VC 15:58:36 Again thank you all - very helpful 15:58:38 ... Possible to do, but significant caveats. 15:58:41 ack dbuc__ 15:58:42 if i understood brent correctly, i.e., an intermediary can resign and convert a VC from one format to another 15:58:45 I agree with Brent's correction -- he is right, I was sloppy with my language, that is a legitimate strategy. 15:59:00 I was trying to say "the signature itself cannot be transformed to keep the same issuer" 15:59:10 dbuc__: To Phil's topic about transferrance/exchange of credentials... There have been several groups working on the Presentation Exchange spec, which works across VC HTTP API, across Aries, and across OIDC 15:59:23 ... Just a data model, not a full protocol, but made to be embeddable across that. 15:59:23 yes, that is what I meant, and the intermediary becomes a new root of trust 15:59:27 ... Could look to standardize that? 15:59:32 so there may be a place in the market for parties to function as these trusted intermediaries that will convert formats. 15:59:39 ... It doesn't have a "pick my thing" requirement... No contention 15:59:45 ack kristina_ 16:00:12 kristina_: To follow about the APIs comment... Manu spoke about VC HTTP API. There is work in the OIDC Foundation about OIDC for VP, uses Presentation Exchange, works across JSON and JSON-LD, embedded and external signatures 16:00:16 ... Adopts OIDC API protections 16:00:29 ... Leverage OpenID Connect... Most importantly, it works and is ready to go. 16:00:56 ... Also there is work on standardizing issuance using OpenID Connect... requires binding to user's DID, potentially a similar request syntax but new requirements... work ready to go, ready to collaborate 16:01:16 ... Second thing: I hear people talking about market forces. Maybe we want to see where those market forces are going before we flesh out the VC Spec. 16:01:26 ... Looks like we don't have enough guidance to solve the hardest problems in the spec. 16:02:10 brent: Meeting for one hour... free-form... touched on the agenda items... Has this format been sufficiently satisfying and rewarding, to continue, or prefer more focused conversation? 16:02:18 q+ to note format is good, on concrete changes for "Other Deliverables". 16:02:28 ack manu 16:02:28 manu, you wanted to note format is good, on concrete changes for "Other Deliverables". 16:02:35 present+ 16:02:50 q+ to pick a new scribe 16:03:06 manu: For charter, I suspect Digital Bazaaar would be supportive as-is. Section 2.2 Other Deliverables, we list things but don't explain what they are... 16:03:11 nms has joined #vcwg 16:03:19 ... I think we should note what those things are... To have test suites we need specs, at least as notes. 16:03:31 ... We may want to say specifications / "notes" for verifiable credential proof types 16:03:40 ... Talk about linked data integrity stuff and JWT stuff, as things we intend to produce 16:04:08 ... The reason to say intend to produce as Notes is the expectation that those notes will eventually be pulled into a rechartering, to becomes standards/recommendations that the group wants to publish 16:04:16 ack brent 16:04:16 brent, you wanted to pick a new scribe 16:04:17 ... Should put notes in other potential deliverables 16:04:57 scribe: phila_ 16:04:58 plh has joined #vcwg 16:05:04 scribe+ phila_ 16:05:17 brent: Welcomes Ivan 16:05:20 present+ 16:06:15 brent: Encourages open discussion 16:06:33 zakim, who is here? 16:06:33 Present: Geun-Hyung, cel, jeff, jay, kdenhartog, phila_, shigeya, dlongley, bmay_, burn, brent, manu, dbuc__, TallTed, plh 16:06:36 On IRC I see plh, nms, kristina_, dbuc__, pam, shinta, Peter_B_Andersen, kdenhartog, Geun-Hyung, ryuichi, burn, shigeya, RRSAgent, Zakim, brent, phila_, TallTed, jay, tzviya, ivan, 16:06:36 ... jeff, dlehn, manu, dlongley, bigbluehat, stonematt, hadleybeeman, agendabot, wayne, cel, rhiaro 16:06:38 q+ to mention mDL :P 16:06:44 ack manu 16:06:44 manu, you wanted to mention mDL :P 16:07:14 manu: My read of the groups seems to be that people are OK with the charter, modulo people uneasy about us not picking a winner 16:07:29 ... there are things that industry is expecting us to weigh in on. One is mDL 16:07:47 ... is this compatible? Competing? May want to do some outreach 16:08:11 ... Some of us are more involved in mDL than others. Anyone got plans towards convergence? 16:08:34 ... Reqs coming into DHS may create confusion 16:08:46 Kristina has joined #vcwg 16:08:56 q+ 16:09:02 ... Doesn't mean that we have to change the charter. But outreach is a part of what we do 16:09:17 ... We have a lot to do in the next charter 16:09:32 subtopic: VC and mDL/other efforts 16:10:04 ack Kristina 16:10:05 brent: How should (if at all) to address those things 16:10:22 Kristina: What would be the concrete ideas for convergence of mDL into VCs? 16:10:31 ...Those two are different standards. 16:10:54 ... VC is a data model. mDL is a full spec including data transport, handshakes etc 16:11:13 ... there's not a full overlap 16:11:26 ... Do we just want the model included? Or more of the whole thing? 16:11:50 q+ to note concrete solutions -- embedding mDL in VC, expressing mDL data model as VC, signature format, etc. -- full ecosystem interop 16:11:56 ack manu 16:11:56 manu, you wanted to note concrete solutions -- embedding mDL in VC, expressing mDL data model as VC, signature format, etc. -- full ecosystem interop 16:12:29 manu: I thik that touches on some of the things we could do. The mDL spec has a data model in it. The simplest thing we could do is show how to express an mDoc in a VC data model 16:12:34 present+ yasuda 16:12:42 ... Does the ISO group pull that in? OR do we demo that? 16:13:27 ... Second part is that there are devices that can sign the mDoc... [missed a bit] ... holding the smae info, or, demonstrate how we can wholly just take an mDoc, data payload, and put it into a VC 16:14:04 ... further up the stack - not everything, not all the protocol mechs are defined. Verification not defined for example. No open APIs, proprietary APis as a result 16:14:35 ... So maybe we need to show how W3C open standards, maybe with VC API, to issue an mDL in a VC-compatible format? 16:14:41 q? 16:15:09 manu: It feels like tat's important work to be done but it also feels like a distraction 16:15:13 q+ 16:15:21 ack Kristina 16:15:22 s/tat's/that's/ 16:15:44 Kristina: The current mDL spec is not that friendly. Transport is over NFC, Bluetooth etc. 16:16:17 ... There is work happening to make it more friendly but driven by device spec. Hard to pull away from that tendancy to Web-friendly mechs 16:16:59 ... so... I think what Manu has just described, there's not much dependency on ISO, (well, there's a JSON-friendly data model), but the mobile OS providers have concerns about chip capabilities to sign 16:17:39 q+ 16:17:49 ack manu 16:17:51 brent: Any more comments on this subtopic? 16:18:02 manu: I wasn't expecting you to say that. That's great. 16:18:14 rumor (from David Chapman?) had it mDL v2 data model was aiming to be fully VC compatible if not fully VC based 16:18:34 manu: But it raiss the question as to whether W3C should be doing anything in this space. Some companies would like that. SDOs tend to try not to step on people's toes 16:18:49 ... the main thing you said was that there may not be as much of a dependency n ISO as some people thought 16:19:01 s/Chapman/Chadwick/ 16:19:34 brent: Noodles around possible subtopics 16:19:54 s/Chadwick?)/Chadwick)/ 16:20:03 q+ 16:20:17 ack kdenhartog 16:20:24 kdenhartog: Something I've not seen... 16:20:48 ... right now the way in wich a relying party is able to process a VC that's been delegated to another party. 16:20:57 ... is not clear. There's a lot left to implementer choices 16:21:21 ... I think it would be of interest to look at those processing models. delegation? Holder transfer? 16:21:22 subtopic: VC delegation and guardianship 16:21:44 q+ to say "delegation -- don't do it." :P 16:21:53 brent: Tjose who are implementing delegation and guardianship - is there something in the spec that would be helpful? What problems do you see? 16:21:58 ack manu 16:21:58 manu, you wanted to say "delegation -- don't do it." :P 16:22:10 manu: You should not do delegation using VCs. 16:22:16 +1 16:22:41 manu: But... this is the concept that people believe that you can hand someone's a driver's licence and that guardian is now able to use it 16:23:05 ... I think it's difficult. What's being delegated is your authority to do something 16:23:29 q+ 16:23:41 manu: There are auth capabilities and there are things that you use to get those authorization, but from a tech standpoint, they are different. Need a bright line between the two 16:23:59 manu: Here be dragons (paraphrase) 16:24:15 i'd say: people can't literally *be* other people :) they can only act on their behalf -- authority is delegated not identity / attributes ... and so represent authority via VCs, represent identity / attributes (claims about subjects). 16:24:37 s/so represent/so DONT represent/ 16:24:44 manu: We should def talk about guardianship. But I don't know how many of us have those kinds of use cases 16:24:57 q+ 16:24:58 brent: Pauses discussion to welcome new people 16:25:13 zakim, who is here? 16:25:13 Present: Geun-Hyung, cel, jeff, jay, kdenhartog, phila_, shigeya, dlongley, bmay_, burn, brent, manu, dbuc__, TallTed, plh, yasuda 16:25:16 On IRC I see Kristina, plh, nms, pam, shinta, Peter_B_Andersen, kdenhartog, Geun-Hyung, ryuichi, burn, shigeya, RRSAgent, Zakim, brent, phila_, TallTed, jay, tzviya, ivan, jeff, 16:25:16 ... dlehn, manu, dlongley, bigbluehat, stonematt, hadleybeeman, agendabot, wayne, cel, rhiaro 16:25:28 q+ to comment on guardianship 16:25:35 ack kdenhartog 16:25:42 kdenhartog: Just t respond to Manu. I agree very much 16:26:10 ... Some of my blog posts have been intentionally ironic. It's a necessary topic as the spec current has text that suggests it might be good 16:26:22 q+ to express lack of understanding 16:26:34 kdenhartog: To your point about lack of use cases - Director credentials - where someone acts on behalf of an org 16:26:46 Yes, and I strongly disagree with those aspects of the spec (that say delegation is something you should do with VCs). :) 16:26:55 ... there is no clear distinction between a guardianship approach cf. a delegated approach. 16:26:59 They are in an appendix, and I was hoping we could have removed that from the spec before publishing it. 16:27:37 ack burn 16:27:37 burn, you wanted to comment on guardianship 16:27:39 kdenhartog: Get us going down this path to say it's dangerous and point out how to apply the tech in the legit use cases 16:28:10 burn: I wanted to make a comment on guardianship. When Manu said there may not be many with use cases... having been a legal guardian for many years... 16:28:23 ... the mental model is almost exactly the same as a parent-child. 16:28:34 q+ 16:28:42 ... But you have authority to act in essentially all ways on behalf of another person 16:28:45 I didn't mean to say "use cases", I meant to say "actively working on guardianship" -- as in implementing it into their products... I'm just concerned that w/o direct implementer feedback that we might do damage. 16:28:54 ack brent 16:28:54 brent, you wanted to express lack of understanding 16:28:57 s/do damage/do harm/ 16:29:38 brent: This isn't reflective of my own views - my understanding of where the confusion may lie, it's not in ... the VC can be used to authorise certain capabilities 16:29:50 q+ 16:30:17 ... expression of the authn is separate from the VC. There is confusion as to why the VC can't then be used as a vehicle for the expression of that authn 16:30:26 ack kdenhartog 16:30:48 kdenhartog: Another aspect.. understanding that a mobile wallet is acting in a way as a digital guardian on behalf of the subject 16:31:03 q+ to note "VCs are the wrong tool for the job when it comes to authorization -- not because it can't be done, but because people will misuse it." 16:31:12 ... I frame it that way bc what happens when a malicious wallet comes into play 16:31:55 ... In that regard it made me realise that trying to represent transferring a credential between a user's devices is effectively a guardianship relationship 16:32:01 ack dlongley 16:32:03 ... I;m transferring to myself 16:32:23 dlongley: VCs allow you to make claims about subjects, irrespective of the verifier. 16:32:40 dlongley: The VC doesn't represent the permission 16:33:24 ... If you want to be able to to delegation... you might need a new vocabulary to describe invocation of authority from elsewhere 16:33:33 ack manu 16:33:33 manu, you wanted to note "VCs are the wrong tool for the job when it comes to authorization -- not because it can't be done, but because people will misuse it." 16:33:39 +1 that conceptual approach is where I'd like to see us go Dave 16:33:56 If we do want to tackle this work in V2 work 16:34:03 manu: To add to Dave... VCs are the wrong tool for the job when it comes to auth. But they're so close! Wouldn't it be great if we could 16:34:16 manu: There are nuances that really matter 16:34:20 kdenhartog: you don't want to mix identity and authority :) 16:34:32 ... The concern is that not everyone will understand those nuances and therefore misuse VCs 16:34:33 having a single technology for both could be very dangerous 16:34:49 manu: They'll confuse and mix cred with auth 16:34:59 manu: Adds attack surfaces 16:35:25 manu: Please don't do that, it will lead to abuse of the data model. Be clear on the differences 16:35:32 q+ 16:35:40 ack kdenhartog 16:36:07 kdenhartog: Is this something that we want to include in the charter? To allow the WG to decide how to handle it? 16:36:08 q+ to note -- I think it's something we want to remove from the spec -- the idea that you should do this. 16:36:36 brent: I think if we feel that it's important then it could be added to the charter. Or it could be on issue on the VC Data model repo 16:36:40 ack manu 16:36:40 manu, you wanted to note -- I think it's something we want to remove from the spec -- the idea that you should do this. 16:37:18 manu: I think it's something we should remove from the spec. It currently hints that delegation can be used. It's in an appendix so what harm can it do? Well, quite a lot. 16:37:32 Sounds good, I'm good with that approach Manu 16:37:35 ... maybe put it in the implementation guide and explain the nuances 16:38:12 brent: In recognition of TPAC... my hope is to end this meeting in about 12 minutes from now 16:38:17 You could, if needed, add to the charter that normative guidance around use of VCs for delegation will be produced. 16:38:37 (understanding that that guidance may be "don't make this mistake") 16:38:41 brent: We could jump into the issues labelled as deferred to v2? 16:38:53 Topic: V2 issues 16:39:06 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adefer-v2 16:39:40 brent: These are currently open in the VC Data model repo. Most of them came from the current WG as we decided what we were allowed to work on. 16:39:54 ... Several of these don't qualify as errata 16:40:12 brent: There are a number of larger topics 16:40:24 ... Like the idea of binding a VC to a subject or a holder 16:40:32 ... the whole JSON/JSON-LD issue 16:40:43 ... What is a nonce Should we say more about it? 16:40:55 q+ 16:41:02 brent: Which is these do you particularly care about? 16:41:06 ack kdenhartog 16:41:16 kdenhartog: I think there's a set of classic problems. General context updates that need to occur 16:41:48 kdenhartog: Changes of context we consider a breaking change and therefore out of scope. So we need to continue the JSON-LD work so it behaves as expected 16:41:54 ... and we can add new features 16:42:09 q+ 16:42:19 ack manu 16:42:54 manu: I'm expecting a fairly decent JSON-LD context restructuring in V2. Like taking th crypto suite out and making a separate resource. 16:43:12 ... So there's a context for creds, and a separate one for proofs 16:43:53 ... The good news is that the WG would be chartered to work on that. This group has the authority to make the decisions 16:44:41 manu: I want to go back to something that shigeya said earlier, on multi-lingualism. That's one reason for using JSON-LD. We do have a mech for expressing multiple translations of terms in a VC. That's there now 16:44:55 manu: We haven't see many multi-lingual VCs issued 16:45:05 q+ to say or folks are using overlays 16:45:11 ack brent 16:45:11 brent, you wanted to say or folks are using overlays 16:45:14 Thanks manu. 16:45:14 phila_: We'd def want that. Multilingualism key feature of our work in APAC 16:45:38 brent: Here's the schema that the VC is using, and here's the overlay to handle languages 16:46:08 Yeah, perhaps we should add multilingual examples into the spec. 16:46:21 brent: The current version of the spec doesn't cover this enough. Knowledge of JSON-LD is assumed to include knowledge of how to do multi-lingual VCs 16:46:38 brent: 28 is a healthy number of issues for a WG to start with 16:46:39 q+ vc-extension-registry 16:46:49 ack cel 16:47:00 https://github.com/w3c-ccg/vc-extension-registry 16:47:05 cel: What about the VC extension registry. Is that still being maintained? 16:47:11 +1 thanks for bringing that up 16:48:12 brent: One of the reasons that the non-normative doc list includes registries for data models... that includes briging the VC extension registry into the VCWG and formulating it as a Note. If W3C process covers registries by then, we might do that 16:48:14 q+ to confirm that brent's understanding is aligned with mine -- we'll have to do that, and I expect it to follow hard lessons learned from the DID Spec Registries. 16:48:16 brent: Def within scope 16:48:21 ack manu 16:48:21 manu, you wanted to confirm that brent's understanding is aligned with mine -- we'll have to do that, and I expect it to follow hard lessons learned from the DID Spec Registries. 16:48:26 manu: +1 to Brent. 16:48:27 q- vc-extension-registry 16:48:44 manu: My expectation is that we'll learn from the lessons in the DID registry work 16:48:57 RRSAgent: draft minutes 16:48:57 I have made the request to generate https://www.w3.org/2021/10/26-vcwg-minutes.html phila_ 16:49:27 brent: Tomorrow's meeting will focu primarily on what's left for v1.1/1.2. What can get done under our existing charter 16:49:43 brent: Thanks to scribes 16:49:54 s/focu /focus / 16:49:54 brent: Thanks to observers and contributors 16:50:33 brent: The VC WG Charter is under development. Please raise issues if you think it needs more work. We want to present it to the AC and them to say yes! 16:50:41 RRSAgent: Draft minytes 16:50:41 I'm logging. I don't understand 'Draft minytes', phila_. Try /msg RRSAgent help 16:50:43 rrsagent, draft minutes 16:50:43 I have made the request to generate https://www.w3.org/2021/10/26-vcwg-minutes.html ivan 16:50:44 RRSAgent: Draft minutes 16:50:44 I have made the request to generate https://www.w3.org/2021/10/26-vcwg-minutes.html phila_ 16:51:14 zakim, end meeting 16:51:14 As of this point the attendees have been Geun-Hyung, cel, jeff, jay, kdenhartog, phila_, shigeya, dlongley, bmay_, burn, brent, manu, dbuc__, TallTed, plh, yasuda 16:51:17 RRSAgent, please draft minutes 16:51:17 I have made the request to generate https://www.w3.org/2021/10/26-vcwg-minutes.html Zakim 16:51:19 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:51:23 Zakim has left #VCWG 16:51:57 rrsagent, bye 16:51:57 I see no action items