14:40:22 RRSAgent has joined #vcwg 14:40:22 logging to https://www.w3.org/2022/10/05-vcwg-irc 14:40:25 RRSAgent, make logs Public 14:40:26 please title this meeting ("meeting: ..."), ivan 14:40:41 Meeting: Verifiable Credentials Working Group Telco 14:40:41 Date: 2022-10-05 14:40:41 Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2022Oct/0000.html 14:40:41 chair: brent 14:40:41 ivan has changed the topic to: Meeting Agenda 2022-10-05: https://lists.w3.org/Archives/Public/public-vc-wg/2022Oct/0000.html 14:57:54 TallTed has joined #vcwg 14:58:31 mprorock has joined #vcwg 14:59:08 selfissued has joined #vcwg 14:59:49 brent_ has joined #vcwg 14:59:52 present+ 15:00:00 present+ 15:00:08 present+ 15:00:16 present+ mprorock 15:00:26 present_ davidc 15:00:34 present+ davidc 15:00:34 present+ 15:01:08 present+ 15:01:50 present+ cabernet 15:01:50 present+ kristina 15:02:04 present+ mccown 15:02:15 present+ elfors 15:02:30 present+ dlongley 15:02:48 present+ kevin 15:02:52 dwaite has joined #vcwg 15:02:56 kristina has joined #vcwg 15:02:59 present+ gabe 15:03:00 present+ 15:03:00 decentralgabe has joined #vcwg 15:03:01 present+ 15:03:05 present+ 15:03:17 present+ GeunHyung_Kim 15:03:47 Geun-Hyung has joined #vcwg 15:03:53 present+ 15:03:57 present+ manu 15:03:59 kdeangs1 has joined #vcwg 15:04:02 sebastianelfors has joined #vcwg 15:04:20 cabernet has joined #vcwg 15:04:26 present+ 15:04:29 scribe+ 15:05:08 oliver has joined #vcwg 15:05:08 present+ oliver 15:05:16 JoeAndrieu has joined #vcwg 15:05:18 present+ JoeAndrieu 15:05:22 q+ 15:05:24 brentz: bulk of time talking about concrete proposals for the core data model, as time permits at the end we will do triage for known issues 15:05:35 Jeremie has joined #vcwg 15:05:51 present+ by_caballero 15:05:55 manu: a quick report from rebooting might be useful, a few items which may be useful to the group 15:06:02 Jeremie__ has joined #vcwg 15:06:05 present+ dmitri 15:06:39 present+ gnatran 15:07:23 Steve_mccown: introductions; just recently joined, from anonymity labs, working for quite a while with sovrin, DIF 15:07:47 gnatran has joined #vcwg 15:08:00 present+ 15:08:06 Topic: Work Item status updates/PRs 15:08:17 q+ to report out on Data Integrity. 15:08:24 ack manu 15:08:24 manu, you wanted to report out on Data Integrity. 15:08:26 https://github.com/w3c/vc-data-integrity/ 15:08:29 present+ 15:08:31 DavidC has joined #vcwg 15:08:36 present+ 15:08:37 https://github.com/w3c/vc-data-integrity/pulls 15:09:23 +1 manu - we are probably just inside a month for an FPWD, especially now that i am done with travel for a bit 15:09:36 https://github.com/w3c/vc-data-integrity/pulls 15:09:49 manu: VC Data integrity - a number of pull requests which have been processed over the last 2-3 weeks, filling out parts of the specification, thanks to efforts so far, 2-3 more weeks of work before FPWD, ask for review of current PRs 15:10:14 manu: PRs seem to be getting adequate review 15:11:04 q+ 15:11:14 q- 15:11:19 q+ to report out on VC Data Model spec. 15:11:50 ack manu 15:11:50 manu, you wanted to report out on VC Data Model spec. 15:11:53 https://github.com/w3c/vc-data-model/pulls 15:11:54 Mike_Jones: clean up of various pieces of text, looking to discussions today of data model as that may affect how we map VC-JWT to the VCDM. Discussions with co-editors on FPWD timeline 15:12:23 Orie has joined #vcwg 15:12:27 https://github.com/w3c/vc-data-model/pull/924 15:12:27 present+ 15:13:30 manu: VCDM spec, scripts for vocabulary generation as PR, PR. #924 has a fair bit of discussion, quite a number of issues, encouraged to create PRs for issues 15:14:24 https://github.com/w3c/vc-jws-2020/pull/24 15:14:28 Steve_McCown has joined #vcwg 15:14:35 Orie: JWS2020 has one open PR, call to get reviews 15:15:09 present+ 15:15:21 Orie: Ready to kick off FPWG process with guidance 15:15:26 q+ 15:15:29 q+ to question timing. 15:15:58 ack ivan 15:16:11 present+ 15:16:44 ack manu 15:16:44 manu, you wanted to question timing. 15:16:48 Ivan: synchronizing publication with other work items, including data integrity, may make things simpler 15:17:25 manu: +1, we don't have to time all of them together, VC-JWT is separate, Data Integrity and JWS2020 can be done at the same time 15:17:43 Topic: RWoT 15:18:12 q+ dmitri to report out on rendering 15:18:22 q+ oliver to report out on holder binding 15:18:23 https://www.weboftrust.info/ 15:18:37 brentz: reasonably well attended meeting, rebooting web of trust is one of the early communities instrumental to decentralized identity and DID work 15:18:39 q+ manu to report out on known authority lists (trusted issuer lists / trust registries) 15:18:42 https://github.com/WebOfTrustInfo/rwot11-the-hague/tree/master/draft-documents 15:19:06 brentz: a decent of attendees had been there previously, not a lot of first-timers, a number of work items which could tie into this WG 15:19:41 +1 to a NOTE on correlation best practices/advice. 15:19:46 brentz: personally involved in a paper about correlation which might be publishable by a note in this group, call to put ability to correlate in the hands of the subject vs isusers/verifiers 15:20:11 ack oliver 15:20:11 oliver, you wanted to report out on holder binding 15:21:03 q? 15:21:04 oliver: holder binding presentation at TPAC, at rebooting had a bit of discussion over the three days 15:21:18 https://github.com/w3c/vc-data-model/pull/795 15:21:18 ^Stephen's issue 15:21:33 oliver: came up with a proposal and tried to understand how the proposal would work against various holder binding use cases, including requirement catering to enterprise 15:21:44 q+ 15:21:44 +1 to presenting the paper to the VCWG. 15:21:45 oliver: after we finish paper, would like to present to group 15:22:09 ack manu 15:22:09 manu, you wanted to report out on known authority lists (trusted issuer lists / trust registries) 15:22:20 ack dmirti 15:22:28 ack dmitri 15:22:28 dmitri, you wanted to report out on rendering 15:22:52 manu: dmitri's group, Charles, and others worked on the rendering efforts - took rendering paper and came up with a demo on using a templated SVG to render a verifiable credential 15:23:11 manu: could end up adding a property to the VC data model 15:23:20 https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/rendering-vcs-snapshot-9-27-22.md 15:24:02 https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/title-tbd-issuer-verifier-list.md 15:24:37 manu: also discussion on how to link one VC to another VC using a link and a hash, a problem some have been trying to solve/standardize. 15:24:38 manu: Another group including trust over ip, and others on trusted issuer/verifier list, node authorities, trust registry - how do you know whether to trust a credential that has been issued, should you engage with a verifier, 15:24:53 manu: another month or so on that paper to finish up 15:24:56 ack DavidC 15:25:08 I was part of the issuer/verifier discussion too. 15:25:18 @manu, could you add any additional groups/epeople associated with those topics? 15:26:02 q+ 15:26:19 DavidC: proposal to introduce a new role, issuee, a kind of holder who can pass credentials to other people. Holder is variable while the issuee is a fixed participating entity 15:26:30 i/manu: another/manu: We worked w/ Keio, Fraunhoffer, TNO, Bloqzone, Spherity, and Digital Bazaar on the paper./ 15:26:42 ack TallTed 15:26:56 -> Issue referred to by DavidC https://github.com/w3c/vc-data-model/issues/932 15:27:06 TallTed: recommends DavidC proposal to be in another issue 15:27:06 q+ 15:27:31 ack decentralgabe 15:27:35 TallTed: separately concerned about the value of this - that there is not a confusion of holder and subject broadly 15:27:36 It also sounds like it overlaps w/ holder binding discussion. 15:28:02 gabe: confusion of holder vs subject surfaced in delegated credential discussions 15:28:33 Topic: Concrete Proposals for Core Data Model 15:29:25 ref: delegated creds - https://github.com/w3c/vc-data-model/issues/930, multi subject - https://github.com/w3c/vc-data-model/issues/931, multi issuer - https://github.com/w3c/vc-data-model/issues/932 15:29:49 q+ 15:29:57 ack manu 15:30:03 https://github.com/w3c/vc-data-model/issues/929 15:30:27 TallTed: "Issuee" is not material to any of #930, #931, #932. "Issuee" should get its own issue. 15:30:49 q+ 15:30:51 manu: attempt at a number of proposals - some discussion over those proposals with a couple of +1's, some back-and-forth with Orie, wondering if the best approach is to put proposals forward to see if there's agreement 15:31:13 https://github.com/w3c/vc-data-model/issues/929#issuecomment-1267030853 15:31:43 +1 to make VCs easier to use and develop 15:32:20 manu: there are a number of things which make JSON-LD processing mandatory, one idea here would be to not allow JSON-LD expanded form - only bald JSON-LD is one in compacted form 15:32:48 +1 to easier to use and develop 15:32:52 manu: another, have @context use URLs and recommend against inline contexts 15:33:14 -1 to guidance against inline context - see comments in issue re twitter and other discussions on schema.rg 15:33:37 manu: finally, a discussion about @vocab and make it easier for developers to pick up and use without the first thing to do being to define a JSON-LD document. 15:33:41 shawnb has joined #vcwg 15:33:51 -> JSON-LD compact form definition https://www.w3.org/TR/json-ld11/#compacted-document-form 15:34:09 manu: a suggestion by Orie that its RDF, my proposal is it is JSON-LD which is a superset of RDF, others that it is JSON-only 15:34:09 q? 15:34:13 My proposal titled "It's time to let JSON be JSON" is at https://github.com/w3c/vc-data-model/issues/929#issuecomment-1267697526 15:34:14 ack selfissued 15:34:35 q+ 15:35:33 selfissued: after discussions with a lot of people including at TPAC, there is ample evidence that there are developers who get it wrong if they use @context, and who would be happy with a more typical JSON model. The current text is halfway between, requiring an @context without requiring JSON-LD. The simplest way to resolve this is to define two kinds of credentials - ones which include @context and are JSON-LD, and ones which don't and are JSON 15:36:12 ack Orie 15:36:13 +1 Mike 15:36:19 selfissued: it is a little unfortunate if we have two representations, but that is what we are seeing. We should restrict the usage of @context if the data is not JSON-LD, and require it if it is 15:36:48 +1 to two clearly different kinds, w/ @context and without 15:37:17 Orie: appreciate comment about developers, various skillsets mean that some struggle with certain technologies while others find it easier. We should strive to make it easier to implement for unskilled developers. 15:37:19 +1 orie - ietf vs w3c and a place for all things 15:37:43 +1 to point out that restricting context would be a violation of JWT's extensibility framework 15:38:21 +100 Orie 15:38:22 -1 (splitting into two different formats) that will guarantee a non-interoperable VC ecosystem. 15:38:23 q+ to point out that restricting context would be a violation of JWT's extensibility framework 15:38:28 +1 to Orie 15:38:39 -1 to splitting into two different formats 15:38:43 q+ 15:38:52 q+ 15:39:13 present+ nadalin 15:39:18 -1 to splitting into two different formats, if don't want data model constraints and open world decentralized semantics, use a JWT -- that already exists. 15:39:20 +1 semantics are important to this work 15:39:33 +1 on semantics being important and are a key differentiator here. 15:39:43 q+ 15:39:55 Orie: COSE/JOSE work in IETF, have their place in signing unstructured data. To the original point on implementation complexity, should be trivial to implement but should have value in implementing. Combining things together means that they lose the value of their specificity. My value in Verifiable credentials is that they provide semantic data. 15:39:58 q+ to note that the extensibility model proposed for JSON-without-@context does not scale for the proposed use cases: https://github.com/w3c/vc-data-model/issues/929#issuecomment-1268585146 15:40:20 https://lists.w3.org/Archives/Public/public-credentials/2022Sep/0253.html 15:40:33 Orie: example of a mill test report signed by a steel company in Mexico - want them to choose between using VC-JWT or Data Integrity - but regulators consuming the document should have the same semantic data at the end 15:41:21 Orie: mission we are on is to create an open world model for structured semantic data, treating this work as an extension of COSE/JOSE with a few new terms doesn't solve these objectives or help issuers and verifiers. 15:41:23 +1 to what Orie is saying. 15:41:24 +1 to Orie 15:41:27 q- 15:41:27 +1 Orie 15:41:38 +1 to Orie (or plus infinity) 15:41:51 q? 15:42:37 ack JoeAndrieu 15:42:37 JoeAndrieu, you wanted to point out that restricting context would be a violation of JWT's extensibility framework 15:42:39 JoeAndrieu: comment on selfissued's comment - if the extensibility model is to just add whatever terms to the JSON to extend it, why not allow @context. 15:42:41 ack mprorock 15:42:53 Example of awesome work at IETF, on signing arbitrary data... https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign 15:43:05 q+ nadalin 15:43:09 +q 15:43:12 My comment on the JSON-only extensibility model is at https://github.com/w3c/vc-data-model/issues/929#issuecomment-1268585146 15:43:32 +1 to adding @vocab to the core data models v2 context. 15:43:47 mprorock: applause to Orie on comments, a reasonable proposal is that @context is required given the semantic nature of work - however, it is important to recognize that there are a large body of use cases existing in the wild that also utilize some of the properties of JSON-LD like @vocab 15:44:13 q+ impact of @context on secure processing by JSON tools 15:44:14 -1 to adding @vocab in core context, but +1 to add it in a "poc/developer" context. 15:44:24 q? 15:44:27 +1 to adding @vocab in some way that makes it easy for less skilled developers to use, not necessarily in the core context, but perhaps in another context that can be used and will signal its usage to simple processors (that just read the `@context` strings) 15:44:29 ack selfissued 15:44:39 q+ impact of context on security with JSON tools 15:44:43 q+ to impact of context on security with JSON tools 15:44:59 I should also note that @vocab prevents developer errors in terms of what is getting signed or not 15:45:11 It creates errors as well -- :) 15:45:31 However, there is a way to address this concern and we shouldn't conflate that discussion w/ the core data model discussion. 15:45:41 selfissued: not trying to change JSON extensibility model, as it is a claim with specific meaning that could conflict. We should register it as a claim in the IANA JWT claim registry. You need to use claims in the way they are registered. If you use @context, use it as it is defined. 15:45:45 +1 to registering JWT claims, -1 to thinking that IANA registries are the only way to understand claims... we are literally here to break that cycle. 15:46:06 +1 orie 15:46:19 +1 orie 15:46:21 +1 to letting @context be used as intended, and allowed anywhere in the JSON serialization 15:46:27 +1 to Orie 15:46:52 luckily we don't need a new standard to "just sign JSON or CBOR" :) 15:47:09 q? 15:47:15 nor do we need a new JWT spec, it's there, if people don't want semantics -- use that. :) 15:47:29 don't forget about signing with "sd-jwt" :) 15:47:36 or jwp! :) 15:47:42 or acdcs 15:47:51 or AnonCreds 15:48:00 selfissued: Orie made a point that signing things should be a distinct activity from the type of data which is signed - we are defining what is signed, whether with JOSE, COSE, Data Integrity. The value we are adding is in defining the additional claims which are in a typical VC, and what they mean 15:48:01 my comments here: https://github.com/w3c/vc-data-model/issues/929#issuecomment-1268527033 <-- use the right tool for your use case ... if that's a JWT, use one, if it's a VC, use a VC ... but these aren't the same things and shouldn't be made to be the same. 15:48:09 ack manu 15:48:09 manu, you wanted to note that the extensibility model proposed for JSON-without-@context does not scale for the proposed use cases: 15:48:11 ... https://github.com/w3c/vc-data-model/issues/929#issuecomment-1268585146 15:48:16 this is why we shouldn't let the core data model be "wagged" by a security format. 15:48:23 JWT spec cannot be used as-is to do a JSON-encoded VC 15:48:39 q+ 15:48:48 ? we use it in 1.1... not sure what you mean kristina. 15:48:50 q+ about dividing the ecosystem 15:48:58 there is a 3rd proposal on the table: @context + @vocab in core data model 15:49:04 https://w3c-ccg.github.io/traceability-vocab/#credentials 15:49:07 q+ to discuss about dividing the ecosystem 15:49:12 manu: the problem here is that we are discussing splitting the ecosystem into two communities with different extensibility models. JSON-LD uses identifiers which do not require a central registry, while JSON would defines claims in a centralized registry. 15:49:34 Don't look at us... look at schema.org, GS1, UN CEFACT, CHEBI, QUDT, FIBO, etc... 15:49:48 manu: if you just look at the traceability work, the amount of claims necessary would be massive. Argument is to go register claims in a centralized registry at IANA, use reverse domain names, etc. 15:50:00 +1 to domain-specific terms, managed by each domain, as they wish. No need to centralize everything into a single registry. That's an anti-pattern we're trying to fix here. 15:50:07 manu: that approach has been discussed time and time again and that approach just does not scale 15:50:16 Look at how people are aleady using the open world capabilities of JSON-LD in industry today... look at knowledge graphs... look at OntoText and Neo4j. 15:51:17 manu: the ramifications of splitting the data model into two things with different extensibility will split the ecosystem, and is one of the greatest things we could do to damage the ecosystem today. Today, some people are doing it wrong but things like @vocab could be used to help 15:51:30 ack nadalin 15:51:32 @orie: JWT spec defines the claims, but there is a need for a profile like vc-data-model or an ID Token section in oidc to make those claims meaningful - iss/iat/etc are all optional in the JWT spec itself 15:51:41 i don't understand how a "vanilla JSON 'VC' that doesn't have data model constraints and uses a centralized claims registry" would be different from a JWT -- what would we be doing here? 15:51:43 If I am forced to include @context, but I do nothing to actually use it and none of the relying parties for my use-case rely upon it then what purpose does it serve? *Requiring* it isn't something I can fully support, but I can absolutely see the value in it for some use-cases, so I'm more than happy to optionally use it. 15:52:08 present+ shawnb 15:52:14 kristina: ahh yes, we have the "securing specs" to handle those profiles / mappings. 15:52:14 +1 shawnb.. 15:52:39 shawnb if you don't use use @context, what's your extensibility story? 15:52:42 shawnb: when you read a spec that says what the context is (what the mappings are) and you hard code your software to look for its URL identifier and its mappings, you don't have to programmatically process it. 15:52:52 Guys... you can sign JSON today... with JOSE... why are you here if you just want to process JSON and JWTs / JWS ? 15:52:52 s/shawnb: when/shawnb, when/ 15:53:00 @orie: umm securing is how to secure/sign; JWT body of what is signed is separate - why JWT and JWS are separate.. 15:53:01 +1 to Orie 15:53:05 +1 to Orie 15:53:11 +1 to Orie 15:53:13 +1 shawnb 15:53:16 nadalin: not proposing to get rid of @context, it should be optional whether you use it or not. You have troubles today because people find they are not needing it - but you are forcing the parser and logic to understand it. Mandating @context has made the world more complex - you don't need it while processing just JSON and JWTs. As far as interoperability is concerned - you hurt interoperability by forcing people to go down this route. 15:53:21 q? 15:53:22 s/@orie:/Orie,/ 15:53:23 Orie, it's not how to sign, but the body of what's being signed.. 15:53:27 ack kdeangs1 15:53:29 q+ for at least one concrete proposal. :) 15:53:34 ack kdeangs 15:53:42 -1 to "hurting interop"... its like saying OIDC hurts interop.... profiling does not hurt interop, in enables it. 15:53:55 +1 orie (to his -1) 15:54:02 +1 to Orie 15:54:20 kdeangs: if we have an envelope model, where we use @context as a wrapper for the verifiable credential model where inside the envelope the issuer can do what they please. 15:54:30 scribe+ 15:54:37 @manu I don't need semantic meaning to have extensibility in the datamodel. 15:54:40 ack dwaite 15:54:40 dwaite, you wanted to impact of context on security with JSON tools 15:55:16 dlongley - if I do that then what purpose does @context serve for my software in processing the payload? 15:55:17 shawnb not sure what your use case is, but maybe JOSE / COSE is a better fit for it ? 15:55:18 dwaite: One of the issues I have with @context environmens where people are not ready to handle it, @vocab are not ignorable, especially within data integrity and cnaonicalization of RDF, as well as without it, you wind up having two different data models for the same piece of data and that matters in a security context. 15:55:24 semantic meaning on what a VC itself means is important 15:55:40 Orie - yes, generally speaking it is. 15:55:43 shawnb: it's like adding a type definitions file to make JS into TypeScript 15:55:52 q? 15:56:01 zakim, close the queue 15:56:01 ok, brentz, the speaker queue is closed 15:56:07 q+ to talk about 'admin' things before closing 15:56:21 You should use JOSE / COSE... if they are better fit for your use case... You should not try and make everyone use them, if you don't understand their usecases. 15:56:52 shawnb: the `@context` URL says "these are the types used in here" -- and if your software knows that context, it doesnt' have to do any transforms, it only accepts JSON marked with that `@context` value. 15:56:59 dwaite: If you have multiple ways of expressing things and people understand that in different ways, someone might thing an object property means something specific vs. someone processing @context thinks theres an extra value there, downloading things dynamically, changes semantics as they are processing it and that's a serious security issue where you can craft messages are meant to be secure but can be interpreted in different ways by different people, 15:56:59 where we're not encouraging processing as data, you haven't comitted to valid semantic model for extensions where JSON developers are using static things - explosion of complexity. We are not giving people the flexibility to do both sets of tools, we are requiring them to understand security ramifications looking at data in different ways. 15:57:03 q- 15:57:03 ack selfissued 15:57:04 selfissued, you wanted to discuss about dividing the ecosystem 15:57:09 Orie: Agree, I'm not trying to make everyone use them. 15:57:09 do I need to scribe back? 15:57:21 Imagine telling everyone that category theory and type safe languages are bad, because you can use python and javascript. 15:57:45 selfissued: We already have a split ecosystem, there are two camps, we should support both well than to be halfway inbetween that serves no one. 15:57:58 selfissued: responding to manu's comment - the community is already divided. We have those who speak JSON-LD correctly and those who are not. We are better off recognizing that vs leaving things halfway between 15:58:03 -1 to "there are 2 camps"... there are people who use JOSE / COSE and there are people who use them and the VC Data Model. 15:58:59 ivan: admin things - propose to set up a second IRC channel, since this channel is meant for minutes and not side discussions and is published. 15:59:51 rrsagent, draft minutes 15:59:51 I have made the request to generate https://www.w3.org/2022/10/05-vcwg-minutes.html ivan 16:00:06 regrets+ 16:00:53 zakim, end meeting 16:00:53 As of this point the attendees have been selfissued, brentz, ivan, mprorock, davidc, TallTed, shigeya, cabernet, kristina, mccown, elfors, dlongley, kevin, gabe, dwaite, 16:00:56 ... decentralgabe, GeunHyung_Kim, Geun-Hyung, manu, oliver, JoeAndrieu, by_caballero, dmitri, gnatran, juancaballero, Orie, Jeremie, Steve_McCown, nadalin, shawnb 16:00:56 RRSAgent, please draft minutes 16:00:56 I have made the request to generate https://www.w3.org/2022/10/05-vcwg-minutes.html Zakim 16:00:58 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:01:02 Zakim has left #vcwg 16:01:04 rrsagent, bye 16:01:04 I see no action items