01:15:31 gkellogg has joined #vcwg 01:21:43 gkellogg_ has joined #vcwg 01:37:48 gkellogg has joined #vcwg 01:53:02 gkellogg has joined #vcwg 02:00:00 manu_ has joined #vcwg 02:09:50 gkellogg has joined #vcwg 02:26:34 gkellogg has joined #vcwg 02:33:00 gkellogg has joined #vcwg 02:49:48 gkellogg has joined #vcwg 02:54:13 gkellogg has joined #vcwg 03:02:07 gkellogg has joined #vcwg 03:15:22 Brent has joined #vcwg 03:15:58 Zakim, end the meeting 03:15:58 As of this point the attendees have been TallTed, identitywoman, kristina, oliver, ivan, manu_, dlongley, andres, GeunHyung_Kim, campbell, gabe, Phil, decentralgabe, brent, ?, 03:16:01 ... mprorock, selfissued, dwaite, shigeya, JoeAndrieu, mahmoud, will, markus, sam, przemek, griffin, PaulDietrich, brentz, dmitriz, markus_sabadello, PhilFariller, orie, drummond, 03:16:01 ... mccown, DavidC, drummond_ 03:16:01 RRSAgent, please draft minutes 03:16:02 I have made the request to generate https://www.w3.org/2023/02/15-vcwg-minutes.html Zakim 03:16:09 I am happy to have been of service, Brent; please remember to excuse RRSAgent. Goodbye 03:16:09 Zakim has left #vcwg 03:20:20 gkellogg has joined #vcwg 03:38:59 gkellogg has joined #vcwg 03:56:26 gkellogg has joined #vcwg 04:16:33 gkellogg has joined #vcwg 04:33:42 gkellogg has joined #vcwg 04:43:15 gkellogg has joined #vcwg 04:49:12 gkellogg_ has joined #vcwg 04:52:35 gkellogg has joined #vcwg 05:08:47 gkellogg has joined #vcwg 05:26:06 gkellogg has joined #vcwg 05:34:49 gkellogg has joined #vcwg 05:51:04 gkellogg has joined #vcwg 06:00:22 gkellogg has joined #vcwg 06:05:41 gkellogg_ has joined #vcwg 06:21:57 gkellogg has joined #vcwg 06:31:25 gkellogg has joined #vcwg 06:40:50 gkellogg has joined #vcwg 06:53:14 gkellogg has joined #vcwg 06:54:24 gkellogg has joined #vcwg 06:55:23 gkellogg_ has joined #vcwg 06:58:35 gkellogg has joined #vcwg 07:03:03 gkellogg_ has joined #vcwg 07:04:11 gkellogg has joined #vcwg 07:16:22 ivan has joined #vcwg 07:19:28 gkellogg has joined #vcwg 07:36:14 gkellogg has joined #vcwg 08:18:36 gkellogg has joined #vcwg 08:30:50 gkellogg has joined #vcwg 08:37:13 gkellogg_ has joined #vcwg 08:55:53 gkellogg has joined #vcwg 09:04:40 gkellogg has joined #vcwg 09:23:07 gkellogg has joined #vcwg 09:39:06 gkellogg has joined #vcwg 09:56:21 gkellogg has joined #vcwg 10:05:28 ivan has joined #vcwg 10:08:25 gkellogg has joined #vcwg 13:46:40 RRSAgent has joined #vcwg 13:46:40 logging to https://www.w3.org/2023/02/15-vcwg-irc 13:46:41 RRSAgent, make logs Public 13:46:44 please title this meeting ("meeting: ..."), ivan 13:47:12 Meeting: Verifiable Credentials Working Group F2F, 2nd day 13:47:12 Date: 2022-09-16 13:47:57 Agenda: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.p23 13:48:20 ivan has changed the topic to: Meeting agenda 2023-02-16: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.p23 13:48:34 chair: brent, kristina 13:48:55 present+ 13:57:46 present+ 13:58:22 s/Date: 2022-09-16/Date: 2022-09-15/ 13:58:42 TallTed has changed the topic to: Meeting agenda 2023-02-15: https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.p23 13:59:48 manu_ has joined #vcwg 14:00:15 present+ identitywoman 14:01:00 present+ 14:01:21 present+ 14:01:46 present+ dmitriz 14:01:55 GeunHyung_Kim has joined #vcwg 14:02:02 decentralgabe has joined #vcwg 14:02:03 present+ 14:02:04 present+ 14:02:05 present+ 14:02:09 mprorock has joined #vcwg 14:02:10 present+ 14:02:15 present+ 14:02:19 Phil-ASU has joined #vcwg 14:02:48 Paul_Dietrich_GS1 has joined #vcwg 14:03:24 Orie has joined #vcwg 14:03:37 present+ Phil-ASU 14:03:37 present+ andres 14:04:12 Phil_F has joined #vcwg 14:04:15 kristina has joined #vcwg 14:04:20 present+ 14:04:46 present+ 14:07:30 scribe+ 14:07:48 present+ campbell 14:07:54 present+ Paul_Dietrich_GS1 14:08:15 present+ kristina 14:09:52 present+ oliver 14:09:57 zakim, who is here? 14:09:57 Present: brent, ivan, identitywoman, TallTed, dlongley, dmitriz, manu_, GeunHyung_Kim, shigeya, decentralgabe, mprorock, Phil-ASU, andres, kristina, Orie, campbell, 14:09:57 present+ 14:09:58 Still need a scribe for second session 14:10:00 ... Paul_Dietrich_GS1, oliver 14:10:00 On IRC I see kristina, Phil_F, Orie, Paul_Dietrich_GS1, Phil-ASU, mprorock, decentralgabe, GeunHyung_Kim, manu_, RRSAgent, Zakim, brent, TallTed, dmitriz, ivan, dlongley, cel, 14:10:00 ... saysaywhat, csarven, shigeya, hadleybeeman, bigbluehat, Dongwoo, stonematt, dlehn, npd, w3c_modbot, stenr_, cel[h], ounfacdo, manu, bumblefudge, cel[m], rhiaro 14:10:07 present+ 14:10:09 present+ Paul_Dietrich_GS1 14:10:27 present+ przemek 14:10:33 BC has joined #vcwg 14:10:35 tzviya has joined #vcwg 14:10:39 present+ samsmith 14:10:45 present+ samsmith 14:10:57 samsmith has joined #vcwg 14:11:02 present+ 14:11:03 present+ 14:11:22 andres has joined #vcwg 14:11:24 present + 14:11:30 present+ 14:11:31 q 14:11:32 scribe- 14:12:43 will has joined #vcwg 14:12:51 Paul has just un-scribed himself 14:12:57 JoeAndrieu has joined #vcwg 14:13:01 present+ 14:13:03 scribe+ 14:13:23 brent: Welcome to day 2 14:13:36 ... Agenda with 2 topics plus issues 14:13:49 ...data integrity then VC-jwt 14:14:04 ... focus on decisions and concrete steps to move forward 14:14:11 ... jump right in. Manu? 14:14:24 manu: Not that many slides 14:14:35 ... basically a status update today for Data Integrity 14:14:37 przemek has joined #vcwg 14:14:42 present+ 14:14:45 ... Identify the remaining difficult decisions 14:14:53 ... then set where we go from here, actual timeline 14:15:10 ... Today. We have adopted the base specification 14:15:25 ... introduces base concepts, cryptosuites, privacy consideration 14:15:34 ... Data Integrity is not just a linked data thing 14:15:46 ... you can use it on pure JSON, pure CBOR, and linked data 14:15:58 ... biggest different with JWT is the canonicalization 14:16:16 ... Thats because we want to sign over the semantics, with signatures that are immune to changes in space 14:16:43 ... For example, schema.org will start consuming information off websites we want to enable that to be exposable with data integrity 14:16:58 ... So a major difference is that canonicalization aka transformation, then signing 14:17:17 ... We've adopted the base spec, and also a basic security vocabulary 14:17:27 ... FPWD of VC Data Integrity 14:17:38 ... Adopted JSONWebSignature2020 and EdDSA Cryptosuite 14:17:42 note that "security vocabulary cleanup" is not yet done, it has only started... 14:17:47 ... first FPWD of vc-jws-2020 14:17:52 ... That's where we are today. 14:18:00 ... We've also have a bunch of plugfest 14:18:08 ... work been going since 2012 14:18:19 ... interop testing and test suites 14:18:33 ... Things to do in next ~6 months 14:18:43 ... FPWD of EdDSA Cryptosuite 14:18:54 ... Big question is are we going to do ECDSA cryptosuite? 14:19:01 ... Must complete test suites 14:19:12 ... Issue processing (not much controversial there) 14:19:35 ... Snapshottable CRs? We're close. Should be doable within the next 6 months 14:19:37 q+ 14:19:46 ... but lets talk about that strategy 14:19:59 ... perhaps go earlier to first CR knowing we plan on a revised, 2nd PR 14:20:07 ack ivan 14:20:18 manjaroi3 has joined #vcwg 14:20:26 ivan: on the to do list, we still have a lot of work on the security vocabulary cleanup. 14:20:32 selfissued has joined #vcwg 14:20:33 manu: yes. +1 14:20:39 present+ 14:20:50 ... Thank you. Ivan is the one who did almost all the vocabulary clean up into a new format. 14:21:03 ivan: i hope in a few weeks I'll be able to work on it again 14:21:21 manu: we may need some focus time. not sure if that's a special topic call for those interested in cleaning up that vocabulary 14:21:29 ... that's it for roadmap status update 14:21:45 ... Here are the results of the Jobs for the Future (JFF) plugfest 14:22:05 ... I'm bringing this up because the EdDSA cryptosuite was the most used, both 2018 and 2020 14:22:19 ... that's one thing to talk about. do we want to kill of the 2018 version? (I want to) 14:22:38 ... There were 17 different issuers (although not 17 implementations) 14:22:51 ... 6 different libraries 14:22:55 ... 8 different wallets generating DID Auth signatures 14:23:10 ... then the issuers were signing the VCs themselves with EdDSA 14:23:26 ... one of the challenges here is going to be getting to the newest data integrity proof thing 14:23:34 lost audio :( 14:23:36 lost audio 14:25:15 dwaite has joined #vcwg 14:25:18 present+ 14:26:04 brentz has joined #vcwg 14:26:05 manu: we've got enough people implementing this stuff. we just need to convince them to upgrade 14:26:21 ... that should be straightforward as there isn't much change. should be simple 14:27:41 manu: test suites! We have preliminary suites for VC Data Integrity, EdDSA Cryptosuite, JSONWebSignature2020 14:28:05 ... we have a mix in library that can test base layer VC data integrity then also specific profiles 14:28:25 ... currently powered by making calls against the VC-API and asking the issuer to issuer, then it checks those signatures 14:28:30 ... it calls verify locally 14:28:39 q+ to explain the difference for jws-2020 14:28:45 ... we could make it so it calls verify on other endpoitns (VC API), but we aren't doing that yet 14:29:03 ... There is an NxN matrix that tests all issuers against all verifiers 14:29:19 ... Orie want to give background on JSONWebSignature2020 14:29:21 ack ivan 14:29:26 orie: the test suite is at DIF. 14:29:26 ack Orie 14:29:26 Orie, you wanted to explain the difference for jws-2020 14:29:38 ... basically about implementation interoperbility 14:29:43 ... uses docker 14:29:58 ... so each implementation builds a CLI and generates outputs from the implementations 14:30:09 ... and then verifies the output with just one verifier 14:30:20 ... You produce a payload, we verified this payload. 14:30:31 ... Not statement by statement. Kind of a file-based verification 14:30:39 ... Like the test vectors for COSE 14:30:52 ... The tests are dynamically generated from inputs 14:31:05 ... outputs shows which vendors passed which pieces 14:31:30 ... it has a bunch of suites, and each implementation gets tested against the ones it supports 14:31:45 manu: there is a question about how to test things for W3C 14:32:04 ... traditionally its about testing the normative requirements to verify interoperability to the spec 14:32:32 ... it hasn't really been about making sure things actually work together 14:32:47 The VC Data Integrity test suite, covers the normative statements part, the crypto suites make sure the sign and verify are interoperable. 14:33:21 ... The Data Integrity chart. The test name on the left is the spectext that is being tested 14:33:37 ... "proof field MUST exist at top-level of data object" 14:33:47 ... Every crypto suite tests those data integrity tests 14:34:06 ... Then each cryptosuite has its own set of test vectors 14:34:33 ... This is showing we are actually testing the verification statements, not just the validity of the signature 14:34:49 ... At the bottom is the matrix (Section 2.5) 14:35:02 ... we have everyone issue a credential, then test it against every verifier. 14:35:14 ... we don't have to do this for this working group, but it is a great demonstration of interop 14:35:19 ... That's our proposal for how we do testing 14:35:29 ... Fairly easy to crank these tests out because its modular 14:35:37 q+ 14:35:48 ... Using that suite and the tests in current form. I assert we can get to CR within the next 6 months easily 14:35:51 ack ivan 14:36:11 ivan: to get to CR we have to also go through horizontal review. That might take a long time 14:36:23 manu: that's a good point. We should start horizontal review in the next few months 14:36:31 ivan: The next FEW DAYS 14:36:48 manu: if I remember, we don't need to be finished, but historically it has always been a rush 14:36:55 ivan: yes, it's always a pain 14:37:14 brent: one thing the reviwers HATE is to review a spec that can't change because its going into CR 14:37:24 manu: open question on EcDSA 14:37:40 ... need to align with last language in the spec 14:37:48 ... For each feature, we are looking for at least two checkmarks 14:38:00 ... Not a very high bar. We could go higher: 3 or 4 or 5 14:38:31 ty 14:38:32 ... Given that we have 17 implementers or half that for reusing code. So we have at least 6. 14:38:36 ... We aren't at risk 14:38:55 ... Next JFF plugfest is in the next few months. We can use that to get support for cryptosuites 14:39:04 ... Here's the discussion: The big rocks 14:39:26 ... This is the thing with discussion to day 14:39:36 ... JCS instead of URDNA? 14:39:58 ... Need in put on these four 14:40:02 q+ to talk about mythical proofChains 14:40:32 ... first thing, should all the cryptosuites support JSON canonicalization in addition to UDRNA? Issue #25 14:40:58 ... The reason for this is so that people that want to do JSON only can use JCS. That requires no RDF 14:41:28 ... The other argument is that URDNA is going through standardization at W3C, multiple implementations, 14:41:37 ... but not a machine verified proof. 14:41:58 ... that proof doesn't always happen, but its a good idea. it's hard and will take 6-9 months 14:42:44 ... This is not a limiting factor anywhere else (IETF) 14:42:44 ... Most crypto we use doesn't have these proofs 14:42:54 ... If we find some flaw in URDNA, then the canonicalization group doesn't feel it would be catastrophic, but it would be nice to have that backup 14:43:03 ... so JCS would be a good backup 14:43:19 ... so every suite has the option to use JCS 14:43:33 ... Should all of the suites have this kind of dual support? 14:43:36 q+ 14:43:37 q+ 14:43:42 ... Thoughts? 14:43:52 q+ to ask about the status of JCS 14:43:54 orie: I want to talk about proof chains 14:43:59 ... I just really want them to exist 14:44:28 ... In data integrity proofs where we've seen interop, you can't get that nested proof, which is easy with JWT. Let's get that into DI 14:44:29 ack Orie 14:44:29 Orie, you wanted to talk about mythical proofChains 14:44:47 ... Either finish or cut 14:44:53 ack selfissued 14:45:10 selfissued: I queued for the suggestion that maybe we support multiple canonicalization 14:45:19 subtopic: Canoncalization schemes 14:45:21 ... "Standards is the process of making the choices that don't matter" 14:45:42 ... Do you call things XYZ or PDQ? It often doesn't matter EXCEPT that there is agreement 14:45:53 q+ to say speak to the value of JCS in the context of suites 14:46:00 ... If there are choices, different developers will make different choices and that harms interop 14:46:01 https://github.com/w3c/vc-di-eddsa/issues/25 14:46:07 ... First and foremost, decide 14:46:08 ack mprorock 14:46:25 q+ to say i agree with Mike except that i think the advice applies to 'doing the same thing different ways' 14:46:33 mprorock: There's a thread about X.509 where choices were allowed and now there is chaos. 14:46:45 ... I am an acknowledged horrible editor on this spec. 14:46:51 ... Because the spec itself bothers me. 14:47:04 ... I brough this up when we first looked at x.509 stuff coming in 14:47:33 ... There exist already defined stuff. I am concerned at the root level that perhaps we merge JCS2020 merged with the spec 14:47:56 ... with VC-JWT (make sure it works). That might be a different path. 14:48:18 ... At this point, I don't know how to make it something I would want to continue to work on and implement. That concerns me. 14:48:42 ... Instead of working on product, go do this complicated thing. And I'm familiar with the work 14:48:54 ... yes we can go to CR, but maybe we should simplify first 14:49:09 ... Maybe that's a later step, but it feels like we keep kicking the can down the road 14:49:23 ... Do I think there are practical things we can do? Yes. Pick one. 14:49:36 ... Proofchains: nice to see. 14:49:44 ... Others seem mostly simple. 14:50:07 ... But this meta thing: we never resolved possibly being bound to the IANA jose, so let's not use it in DI 14:50:08 ack brentz 14:50:08 brentz, you wanted to ask about the status of JCS 14:50:19 brent: Whats the status of JCS 14:50:37 the question is: how stable is JCS? 14:50:46 selfissued: its conditional RFC. Personal submission because JSON working group didn't like it 14:50:53 ... its informational 14:51:29 q+ to ask about jcs 14:51:31 q? 14:51:34 ack Orie 14:51:34 Orie, you wanted to say speak to the value of JCS in the context of suites 14:51:56 orie: with DI Proofs, there is a set of things that when you create it, you must do, including defining canonicalization 14:52:05 ... I've created a lot of DI suites over the year. 14:52:19 ... Every time you create one you HAVE to state the canonicalization 14:52:28 ... most have been URDNA, but some have been JCS 14:52:49 q+ to ask about removing optionality 14:52:50 ... To say you MUST define the canonicalization, but only show URDNA, that's a problem 14:53:07 ... We have 90% URDNA. 14:53:37 ... to me the extensibility is better supported by actually supporting JCS as proof of choice 14:53:52 ... If we only give one example, it's essentially not giving people a choice 14:54:16 q+ to bring up Mastadon/fediverse for why JCS might be interesting. 14:54:22 ... We should either support extensibility with a second option, or get rid of the optionality 14:54:48 ... for DI proofs to be valuable, then need to have different features than existing systems (JOSE, COSE, X.509) 14:54:56 ... JCS could help in that regard. 14:55:25 ... We could separate different cryptosuites. Some with URDNA, some with JCS. Same crypto, but different canonicalization. 14:55:42 ... This shows the different options. The best we could to demonstrate value with those examples. 14:55:51 ... Whether or not those options take off isn't the point. 14:56:05 ... From a design perspective, it's important for data integrity to have distinctive value 14:56:11 ack dlongley 14:56:11 dlongley, you wanted to say i agree with Mike except that i think the advice applies to 'doing the same thing different ways' 14:56:28 dlongley: I agree with a lot of Orie. I also agree with Mike's comments about making decisions. 14:56:47 ... There are good arguments to be made that these algorithms don't do the same things. They make important choices 14:57:06 ... I don't think suites MUST be able to support both, but its a good idea 14:57:21 ... about making decisions and reusing tech. It's important to understand the design features. 14:57:22 For the record I don't think a single suite should support both... I think a single suite MUST make a choice, so the implementation burden for the suite is minimized. 14:57:40 ... we wouldn't be here if we thought JWTs and VCs are the same 14:57:58 ... We spent a decade to get the VC work going forward because they do something different 14:58:05 ack decentralgabe 14:58:05 decentralgabe, you wanted to ask about jcs 14:58:19 q+ 14:58:20 q+ to talk about JCS 14:58:22 https://www.rfc-editor.org/rfc/rfc8785 14:58:28 ack mprorock 14:58:28 mprorock, you wanted to ask about removing optionality 14:58:30 decentralgabe: I'm not against supporting JCS, but I'm curious about the arguments 14:58:57 mprorock: To Gabe's question. Some of this goes to optionality. If we have extensibility, we should demonstrate choice 14:59:12 ... But let's look at DI, it's about signing "the meaning" 14:59:32 ... The practical value I see is that signing with URDNA, that I'm signing the transformed NQuads. 14:59:43 ... If that meaning changes over time, that signature should break 14:59:49 q+ 14:59:54 ... JCS doesn't get at that meaning. 15:00:05 q+ to value prop for JCS 15:00:14 ... To my mind, unless we can come up with the value of JCS, we should just get rid of the optionality 15:00:31 ... But if we are going to keep optionality, JCS looks like the best candidate 15:00:42 ... There have been so many times this has been attempted. 15:00:52 ... If you look at the XML stuff... 15:00:55 q? 15:01:05 ... It's concerning to me to have the optionality unless we can state the value of it 15:01:08 mkhraisha has joined #vcwg 15:01:17 brent: 15 min to break 15:01:34 manu: I'm concerned we aren't going to get to the "easier" items. Can we put a pin in this and talk about proof chains. 15:01:57 ... also different about JWS2020 uniqueness would be good to discuss 15:02:21 ... dequeing myself. Can we wrap this topic up? 15:02:23 q- 15:02:35 ack selfissued 15:02:57 JSON is UTF-8 15:02:59 selfissued: problems with JCS. If you're not canonicalizing floating point numbers, it's easy. 15:03:13 ... Unicode might also be a challenge 15:03:18 https://www.ietf.org/standards/process/informational-vs-experimental/ diffs on stds track vs informational 15:03:37 ... From my point of view Unicode canonicalization is not something you'd do in a JSON scheme, you'd do it at application layer 15:03:54 ... my preference if we had to choose would be JCS over URDNA 15:03:55 ack dwaite 15:04:41 dwaite: building on Mike's comment. When you canonicalize, you're trying to deal with syntax. With XML, the rules were smarter than the developers 15:05:04 ... these different systems need to give them their sense of the data and not just integrity 15:05:18 ... one is outputing NQUADs, one is outputing JSON 15:05:19 +1 dwaite 15:05:23 ack Orie 15:05:23 Orie, you wanted to talk about JCS 15:05:25 ... At the end of the process, they get different data 15:05:28 q+ to move on 15:05:43 orie: in URDNA, when data type is JSON, JSON is used internally 15:05:52 ... The other comment: what's the value of JCS? 15:06:03 ... Why transform JSON into a hashable format? 15:06:30 ... It's because the structure and syntax of JSON. If you want to sign something, if you're dealing with ordering, you get different hashes, so it matters where that happens. 15:07:00 ... The sidetree protocol (which did:ion uses) uses JCS because it uses hashes and we didn't want the storage layer to be hackable at the storage layer 15:07:06 +1 to Orie 15:07:28 ... Microsoft's ion implementation seems to be doing well (that's to godiddy.com lists) 15:07:39 ... JCS has a use when used for that purpose 15:07:49 ... It's basically about that hashes. 15:07:56 +1 to not letting overreaction culture in the security community dismiss valid and useful use cases and features 15:08:13 ... Saying that I like data structures that always hash to a different value... that doesn't make me super happy about JSON 15:08:32 ... It shows up in these places where we have different signatures and you have do design around this possibility. 15:08:41 ... you BETTER think about that, because it is fundamental to JSON 15:09:00 ... There are places you don't care because you're just signing over bytes. Or you might, because you're reconstructing options over time. 15:09:02 subtopic: JWS-2020 and Other Cryptosuites 15:09:12 ... JSONWebSignature, what's different? 15:09:15 ... Not a lot. 15:09:47 ... It uses URDNA. It's signs not the raw canonicalization, but a detached JSON signature that has a header, concatenated with createVerify bytes 15:09:58 ... that's different than using just the createVerify bytes. 15:10:11 ... That adds bytes, but also flexibilty 15:10:38 ... I floated on the list a while ago that JSONWebSignature2020 could be different 15:10:58 ... we like IANA, we like detached, but perhaps we want a different canonicalization. 15:11:16 ... since its' about "JSON" we can use a JSON native canonicalization 15:11:38 ... I would like to focus on just the JSON, and NOT do URDNA 15:11:50 mkhraisha has joined #vcwg 15:11:56 ... This would make JSONWebSignature obviously different 15:12:09 ... folks don't agree. and obviously we'd need consensus to change it 15:12:14 ack manu_ 15:12:14 manu_, you wanted to move on 15:12:24 q+ to ask in the case of jcs if the context changes the sig breaks? 15:12:26 manu: I just put myself to suggest we move on. 15:12:51 ... Thoughts: I think its important to use JCS. 15:12:56 ... Do we want alternatives? 15:13:10 ... As a customer, there is a desire to have a backup in the Edwards sutie (EdDSA) 15:13:10 q+ to talk about mastodon / fediverse 15:13:21 mkhraisha has joined #vcwg 15:13:22 ... our company is probably going to do it with or without the WG. 15:13:31 ... It'll be up to the WG to decide if that's worth while 15:13:51 ... I don't think it's a difficult change (adding JCS) 15:13:55 q+ to go on break 15:14:00 ... Could do it with several of the suties 15:14:03 zakim, close the queue 15:14:03 ok, brentz, the speaker queue is closed 15:14:13 ... That would mean EdDSA would have two variations of the data integrity proof 15:14:34 ack mkhraisha 15:14:34 mkhraisha, you wanted to ask in the case of jcs if the context changes the sig breaks? 15:14:36 ... not sure what that means to support the IANA variations for JSON WebSignature 15:15:06 mkhraisha: something about does the current situation break ? 15:15:25 manu: it still verifies, but the underlying information model can change without you 15:15:48 ack Orie 15:15:48 Orie, you wanted to talk about mastodon / fediverse 15:15:50 mkhraisha: if somebody changes the context to exclude a word, it doesn't break in JCS 15:16:11 orie: there was comment about one of the first DI proofs was mastodon and fediverse 15:16:21 ... there was a recent proposal to rekindle that with JCS 15:16:30 ... There are folks thinking about this, other than just us. 15:16:39 ... What's interesting: They aren't signing VCs 15:16:44 q+ to speak about mastodon 15:16:54 ... So, for data integrity proofs, they aren't using VCs, but its a similar approach 15:17:18 ... The comment about... if DB is going to create raw signature for everything, then a different canonicalization... 15:17:24 ... Is that an industry intention? 15:17:42 ... Is that correct, than we can withdraw JCS and handle that differently. 15:17:50 ack brentz 15:17:50 brentz, you wanted to go on break 15:18:02 ... If the only difference is the header saying us IANA, that isn't worth the effort to standardize 15:18:12 brent: moving to break 15:18:24 ... keep talking over break. come back with solutions 15:18:49 zakim, open the queue 15:18:50 ok, brentz, the speaker queue is open 15:29:37 JoeAndrieu has joined #vcwg 15:29:48 present+ 15:34:43 brent has joined #vcwg 15:34:50 q? 15:37:27 manu_ has joined #vcwg 15:37:34 scribe+ 15:37:44 dwaite has joined #vcwg 15:37:49 present+ 15:37:51 decentralgabe has joined #vcwg 15:38:15 Schedule adjusted to have an extra session this afternoon 15:38:16 rrsagent, draft minutes 15:38:18 I have made the request to generate https://www.w3.org/2023/02/15-vcwg-minutes.html ivan 15:38:25 q? 15:38:27 q+ 15:38:35 q+ to add a proposal 15:38:50 ack mprorock 15:38:50 mprorock, you wanted to add a proposal 15:38:50 q- 15:38:58 manu_: asked Mike Prorock to prose 15:40:18 mkhraisha has joined #vcwg 15:41:11 mprorock: proposes abandoning JWS 2020 and redirect folks to VC-JWT to use JOSE signing approaches (PR #51) 15:41:13 The proposal, is to not use jws-2020 anymore, and just use https://github.com/w3c/vc-jwt/pull/51 for securing `credential+ld+json`. 15:41:14 test prop: Abandon JWS2020 in favor of pointing to VC-JWT 15:41:41 q+ 15:41:42 mprorock: It would allow us to make the existing specs better. 15:41:48 ack manu_ 15:42:01 manu_: I think it makes it cleaner and reduced optionality 15:42:01 manjaroi3 has joined #vcwg 15:42:05 q+ 15:42:13 ack Orie 15:42:19 Orie: Happy to be an editor of just one of these 15:42:43 q+ 15:42:52 ack mprorock 15:42:53 Orie: looking forward to working on only one work item 15:43:05 q+ to ask about how we plan to point 15:43:18 q+ 15:43:21 q+ 15:43:31 q+ to note we m ight not need a formal proposal for this. 15:43:32 brent: ask about what "pointing" to vc-JWT. what is the methodology? 15:43:35 ack brent 15:43:35 brent, you wanted to ask about how we plan to point 15:44:07 ack mprorock 15:44:09 mprorock: We can add a header to the JWS document to point to vc-jwt. 15:44:13 ack Orie 15:44:29 q+ 15:44:54 Orie: Agree with proposal to update the readme. Is there a formal document change to link them together? Would be weird to advance vc-jwt with a pointer to a FPWD 15:45:01 ack manu_ 15:45:01 manu_, you wanted to note we m ight not need a formal proposal for this. 15:45:32 manu_: we might not need a formal proposal. Can we move forward without a proposal and vote? 15:45:37 ack ivan 15:46:33 PROPOSAL: Abandon JWS2020 in favor of pointing to VC-JWT using the JWS 2020 Readme and text in VC-JWT 15:46:34 ivan: In the old days a working draft was converted into a note. Make a clear resolution that this document does not go to rec. 15:46:39 +1 15:46:41 +1 15:46:41 +1 15:46:42 +1 15:46:44 +1 15:46:46 +1 15:46:46 +1 15:46:46 +1 15:46:47 +1 15:46:48 +1 15:46:48 +1 15:46:49 +1 15:46:50 +1 15:46:55 _1 15:47:01 +1 15:47:13 LOL - it's a special ++ 15:47:34 RESOLVED: Abandon JWS2020 in favor of pointing to VC-JWT using the JWS 2020 Readme and text in VC-JWT 15:48:07 manu_: lets go down the remaining bulleted items. 15:48:19 Phil_F has joined #vcwg 15:48:28 manu_: no FPWD yet, but its ready so I am suggesting we cut an FPWD as soon as we can. 15:48:52 manu_: Now that JWS 2020 is removed, it strengthens the argument for a EcDSA suite. 15:49:24 manu_: reviewing timeline from the slide 87 15:49:36 subtopic: Data Integrity Roadmap 15:49:43 q+ to ask about feature freeze 15:49:49 q+ 15:50:10 manu_: Try to get chained proofs in there before CR 15:50:39 q+ 15:50:48 ack JoeAndrieu 15:50:48 JoeAndrieu, you wanted to ask about feature freeze 15:50:48 manu_: Because we have CR snapshots, we can try to get into CR by June and then snapshot or two by the end of the year to get to PR by the end of the year. Any Issues with this> 15:51:35 JoeAdrieu: Questiona about feature freeze in May. 15:51:47 manu_: Aligns with test suites 15:51:51 ack mprorock 15:52:20 mprorock: I would like call out of a horizontal review on this schedule. Could run a proposal to lock additional features today. 15:52:56 mprorock: this makes CR3 in December reasonable. 15:53:03 ack ivan 15:53:27 ivan: don't understand the comment on CR snapshot? 15:53:47 test proposal: only additional features for data integrity add chained proofs add language for MUST specify canon method as MAY be JCS or URDNA 15:53:53 q+ 15:53:55 manu_: Correction CR draft snapshots. 15:54:28 note of this timeline needs horiz review, and is probably 30 days too aggressive at minimum 15:54:35 q? 15:54:48 brent: Use to be you go into CR and start over if you make changes. Now the process allows for more fluidity. You create a snapshot as you go into CR and you can make changes (non normative). i 15:55:00 big practical difference: you can use echidna for a cr draft and you cannot use it for cr snapshot :-) 15:55:06 brent: Sounds to me like Mike (p) is proposing feature freeze. 15:55:15 q+ to say feature freeze is too early 15:55:19 q+ 15:55:21 q+ 15:55:30 ack brent 15:55:31 brent: Not that they are finished but that they are a locke set 15:55:33 ack JoeAndrieu 15:55:33 JoeAndrieu, you wanted to say feature freeze is too early 15:56:05 JoeAndrieu: Don't think we are ready for a feature freeze today: For example when you send a proto VC to a signer. 15:56:18 JoeAndrieu: Wants to have a conversation on this before a feature freeze. 15:56:19 ack mprorock 15:56:58 mprorock: Strongly objects to any additional other than a path to feature freeze with the two things discussed above. Cool things could come from these items, but we can't add anything complex. 15:57:02 ack manu_ 15:57:29 manu_: Don't want to make this decision today. Pretty sure major things are in the spec (except what Joe said). No issue will calling freeze soon. 15:57:53 manu_: Totally forgot about BBS 15:58:01 q+ 15:58:03 manu_: people are actively working on this and and putting it out there. 15:58:07 ack Orie 15:58:45 Orie: crypto layer is still going through IETF and that could take a long time. Data integrity CCG draft is not likely to change. Could adopt a CCG draft in its current format and hold until IETF finishes. 15:58:57 q+ 15:59:02 ack mprorock 15:59:29 @orie yep, an "unprotected" property will do the job. The goal is to have that property as a standard, so that issuer services ignore it (or never receive it) and holders know that it doesn't travel with the VC, but is somewhere in the proof. 15:59:33 +1 to mprorock and orie 15:59:34 q? 15:59:35 mprorock: Note that with BBS draft, it was beat up and led to the current work at IETF. Fine with bringing this into the features as long as its held until IETF completes 15:59:37 q+ to say the same thing about sd-jwt and jw[p 15:59:46 brent: Moving on to the topic of VC-JWT 15:59:57 Topic: VC-JWT 16:00:01 ack Orie 16:00:01 Orie, you wanted to say the same thing about sd-jwt and jw[p 16:01:06 Orie: presentation about VC JWT, PRs, and take temperature of SD-JWT 16:01:45 Orie: review of registered claim names. Make better use of registered claim names. Examples shown on slide. 16:03:43 Orie: public claim names. Collision resistant names are important. 16:05:04 Orie: private Claim names. Not registered. Imaging all kinds of other names to include in token that you dont care to go to a registry. 16:05:08 q+ 16:05:38 Orie: We can agree to interpret these claim names consistently. They are subject to collusion and used with caution 16:06:08 Orie: organization_id may be an example of both good and bad 16:06:13 ack mprorock 16:06:57 mprorock: Note these important things. Tend to see this between parties trying something out. Also see in developer docs that publish private claims with rules. 16:07:18 mprorock: Expect that we see similar things with VC-JWT. Developer docs with private claims. 16:08:08 mprorock: The other callout from previous slide. This isn't unique to private claims, JSON-LD addresses with vocabs, but there are other mechanisms 16:08:25 Orie: Example from slide 91 PR #44 16:08:58 q+ to note that this is a JWT... not a credential nor a VC -- missed that in the PR. 16:09:18 Orie: Walking through example with differences between ld+json and +jwt 16:09:37 q? 16:09:54 https://github.com/w3c/vc-jwt/pull/50 16:10:08 q+ to ask why have we changed the cty of the thing we are securing? Why isn't it credential-ld-json? 16:10:23 Orie: You can have properties in JSON. Everyone expects that they can be ignored if you don't understand them. 16:10:53 Orie: the JSON @context member is allowed and not required 16:11:09 q+ 16:11:11 Reminder that folks on remote don't understand what "this" is 16:11:13 q+ 16:11:16 ack manu_ 16:11:16 manu_, you wanted to note that this is a JWT... not a credential nor a VC -- missed that in the PR. 16:11:48 manu_: I missed this when reviewing PR 33. All of a sudden we made @context optional. Secondly, its not a verifiable credential or credential. Its arbitrary JSON (a JWT claim set). 16:12:02 manu_: I think its highly problematic. Missed during a review. 16:12:02 q+ 16:12:21 +1 manu 16:12:25 +1 manu 16:12:28 manu_: massive -1. Believes this is the wrong thing to do. 16:12:36 q+ 16:12:41 Orie: Would you prefer we call them credentials 16:12:42 q- 16:12:46 manu-: I prefer we call them JWTs 16:12:50 ack JoeAndrieu 16:12:50 JoeAndrieu, you wanted to ask why have we changed the cty of the thing we are securing? Why isn't it credential-ld-json? 16:12:50 q+ to ask what manu would add 16:13:09 JoeAndrieu: We don't have an unsecured media type for a credential claim set. 16:13:55 Orie: the cty property that has been adopted has a -1.1. The one shown here doesn't have this. 16:14:16 JoeAndrieu: I don't understand why we are talking about a credential claim set that are not a VC 16:14:51 JoeAndrieu: This feels out of scope. It feels like a different thing being secured. 16:15:13 Orie: are you talking bout credential-claim-set versus credential+ld+json? 16:15:37 q+ to note that we have a data model and conformance requirements. 16:15:57 https://w3c.github.io/vc-data-model/#terminology 16:16:06 credential: credential A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects. 16:16:06 JoeAndrieu: definition of what a VC is is not what is at point. VC data model defines a VC but that is not this (slide). 16:16:37 Orie: There is two parts of the spec to review together. First is the definition. Second is every normative statement that is a requirement. Those are what a VC is. 16:16:52 kristina has joined #vcwg 16:16:55 present+ 16:16:59 JoeAndrieu: Do you believe the stuff on the right meet those requirements? 16:17:06 Orie: Lets start with the definition 16:17:24 q+ 16:17:24 q? 16:17:26 ack ivan 16:18:00 ivan: say the say thing as Joe. The right hand side is not what we defined in the VC data model, except for the context which is optional. 16:18:06 q+ 16:18:18 ivan: This is ok, but not what this working group is working on. I don't see how this comes into the picture. 16:18:31 ack dlongley 16:19:02 q+ Orie 16:19:03 dlongley: Agree with manu, Joe and ivan on this. Getty very confused on the processing rules to understand this. Would have to go back to some mapping rules which I though we were moving away from 16:19:04 +1 with Ivan, Joe and Manu - this is out of scope. 16:19:29 ack selfissued 16:19:30 dlongley: looks complicated and out of scope for the group 16:19:51 s/ +1 with Ivan/ ... +1 with Ivan/ 16:20:00 selfissued : this came out of a desire to have VC-JWT to be simpler than in 1.1 16:21:05 selfissued: There have been mappings that keep the VC identifier and the JWT identifier. This can been a complexity nightmare for implementors. 16:21:10 https://w3c.github.io/vc-jwt/#relation-to-the-verifiable-credentials-data-model 16:21:14 i'm +1 for recommending against using the "instead of" mapping and using encapsulation or just having the content be a credential directly, those are both reasonably clean, IMO 16:21:48 selfissued: It was the view of the editors to have no mapping rules. So we created for v2 a native JWT representation of VC. No question that they are credentials and verifiable. They don't use all the claims from the VC data mode. 16:21:55 q? 16:22:09 q+ to agree that mapping was a mistake 16:22:13 selfissued: this makes it simpler than 1.1. It admits the mapping was a mistake and that we should use native claims directly 16:22:20 ack mprorock 16:22:21 mprorock, you wanted to ask what manu would add 16:22:47 kgriffin has joined #vcwg 16:22:51 mprorock: a couple ways this discussion can go. Initially read the definition. Pasted into the minutes. 16:23:28 mprorock: Read from section 1.1 in VC-JWT. Relation to the VC data model. Defines encoding rules to covert. Defines how to make use of VC-JWT specific claim names. 16:23:51 mprorock: I think that if we already have registered claims in JWT (mapping) lets use them. 16:24:22 mprorock: however, suspect that there are things in the VC data model, where it says it MUST have something that do not have registered claim names. 16:24:27 a simplistic summary of what a verifiable credential is not a normative definition of the actual, interoperable data model 16:24:44 mprorock: There are stuff not covered by registered claim names. These are the things that make VCs VCs. 16:25:15 mprorock: question for group. What example would make this a VC? Duplicate values? Context? Can we get this info. 16:25:28 ack manu_ 16:25:28 manu_, you wanted to note that we have a data model and conformance requirements. and to agree that mapping was a mistake 16:25:32 q? 16:25:56 lost audio 16:26:03 lost sound 16:26:07 damn audio! just after "way to go at this"! 16:26:18 manu_: Normative languuage in the spec and these are not in the VC-JWT example. 16:26:40 very persuasive 16:27:06 https://w3c.github.io/vc-data-model/#conformance 16:27:13 manu_: We have a conformance specification and states clearly what forms a conformant document. 16:27:24 brentz has joined #vcwg 16:27:25 from the spec: A conforming document is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections 4. Basic Concepts, 5. Advanced Concepts, and 6. Syntaxes of this document MUST be enforced. 16:27:26 q+ 16:27:31 manu_: The thing on the right is not any of these things. 16:27:49 q++ 16:27:55 q- + 16:27:59 manu_; The thing on the right is a JWT claim set and not what this group does. Feels like describing a JWT and trying to call it a VC. 16:28:06 q+ 16:28:19 manu_: What is the use case here? Totally agree that mapping was a bad idea. 16:28:35 +1 mapping was bad :) 16:28:59 manu_: not in our charter to do this. unless we want to come up with mappings again. 16:29:04 ack decentralgabe 16:29:12 From the 1.1 spec: "Verifiable credentials represent statements made by an issuer in a tamper-evident and privacy-respecting manner." 16:29:34 decentralgabe: What will it take to make more sections normative to prevent layering. 16:30:04 q+ to ask what decisions need to be made so we can move forward. 16:30:04 decentralgabe: oops (lawyering) Agrees this is not a VC as described today. 16:30:32 decentralgabe: necessary to have a native JWT implementation of VC. 16:30:43 ack andres 16:30:44 decentralgabe: There is a conception of a VC that encapsulates a JWT that is not just a JWT 16:31:22 And "Credentials represent statements made by an issuer." 16:31:53 andres: My interpretation. Normative pieces are: must be a context. must have a credential subject. When manu referred to mappings is this what you mean? 16:31:58 manu_: yes 16:32:03 will_ has joined #vcwg 16:32:27 andres: If we step away from JSON and support protos. What does that mean for names? (protobufs) 16:32:31 q+ to automatic mapping... and CBOR-LD 16:32:42 ack Orie 16:33:11 choosing a number of statements that are intended to help the reader understand at a less-technical level what something is in a specification (*any* spec) ... does not change the rest of the spec or what normative parts are needed for interop and conformance 16:33:28 q+ 16:33:48 Orie: VC-JWT today describes the mapping from vc-credential+ld+json to a JWT. These rules say that properties can be omitted that are required in the core data model 16:34:10 Q- my comment is about the requirement of the context file which I'll make tomorrow during that discussion. 16:34:37 big +1 to what orie is saying here 16:34:44 Orie: implemented 1.1 VC-JWT and 1.1 data integrity. mapping problem in 1.1 was a real problem. 16:35:13 q- ... will comment tomorrow about context 16:35:33 q? 16:35:41 q- Phil-ASU 16:35:45 +1 ... the VC-JWT 1.1 mapping "optionality" was a good example of not "just making a choice in a standards group" when two things do the same thing... and clearly "in addition to" was better and should have been chosen. 16:35:47 Orie: in 2.0 we described 1.1 better. We also gave unique names to the content. We should make arguments clear as this is the beginning of a rational debate. 16:36:00 q? 16:36:20 Orie: Is this a zero sum game for branding of what a VC is. If core data model says it must be JSON, then it prevents alot of futures people want to get to. 16:36:44 -1 to shutting the door vs. saying v2 only does X. 16:36:59 even bigger +1 to what orie is saying here 16:37:00 q+ to note that we're not shutting the door on anything that is compact binary. 16:37:04 Orie: Concerned that it may be pigeonholed into a dead end if we can talk about binary ... 16:37:14 q? 16:37:46 Orie: concurred there are numerous problems in the 1.1 vc-jwt. they cannot implement it. additional information needs to be contained to have interoperability that is not in the specific. 16:38:04 e.g. of what orie is saying - that difficulty in implementation is part of what lead to jws2020 16:38:05 Orie: intention is to clearly communicate what working group members want. 16:38:12 q+ to reduce optionality 16:38:46 Orie: better to describe what people are doing rather than tell them to use long names when its their best practice to use short names. 16:38:48 sometimes there will be conflicts with technologies and choices have to be made. 16:38:50 ack selfissued 16:38:50 q+ to say our job is to make choices. at the level of data model having two fundamentally different objects would not serve interoperability. Securing VCs with JWT is a great idea. Redefining a seconday VC representation to do so is not. 16:39:07 selfissued: agree with co-editor (Orie). 16:39:21 Phil_F has joined #vcwg 16:39:42 dmitriz has joined #vcwg 16:39:44 q- 16:39:45 q+ to say that VC-JWT 1.1 involved a mapping that produced a valid credential 16:39:46 q+ to say that you put `vc` in a JWT, that's what made it a VC -- it had wrapping metadata 16:39:50 q+ 16:39:53 selfissued: VC 1.1 spec has a representation as a JWT. 16:40:19 selfissued: Have an opportunity to embrace other representation of credentials that will come out whether or not we do it here. 16:40:29 selfissued: Already have experience that mapping creates more problems than it solves. 16:40:53 selfissued: much like we worked on a native JWT implementation of a credential, we might need to develop a CBOR representation. 16:41:13 selfissued: Hope this parallels the JWT representation. 16:41:24 selfissued: reading from 1.1 spec ... 16:41:49 selfissued: reading definitions of credentials and verifiable credentials 16:42:24 ack mprorock 16:42:33 selfissued: takes objection to the statement that they are not verifiable credentials. Take objection to the statement that this is not what the group does. Please accept that these are VCs made by this work group. 16:42:33 q+ Orie 16:42:54 mprorock: Note that this is still a draft. Merging 44 doesn't mean the workgroup has done this. 16:43:21 mprorock: this is not a VC because its not encoded as a JWT with a signature. we would need to see that. 16:43:56 mprorock: What is the bare minimum of a VC and compare with this. There are gaps with what are presented on the right hand side between it and a VC. 16:44:13 mprorock: But if there is a registered claim mapped to the same meaning, why would we duplicate that. 16:44:41 mprorock: I want to be able to use this with bigger data and consistently and right now that is difficult. 16:44:58 mprorock: side with Manu that we should mandate the inclusion of a context. 16:45:13 q+ 16:45:21 mprorock: semantics are important when processing this data as an interconnected graph 16:45:59 q+ to ask is the argument against this being a claim that credential subject is not its own object but rather is flattened to the main object? 16:46:04 ack manu_ 16:46:04 manu_, you wanted to automatic mapping... and CBOR-LD and to note that we're not shutting the door on anything that is compact binary. and to reduce optionality and to say that you 16:46:07 ... put `vc` in a JWT, that's what made it a VC -- it had wrapping metadata 16:46:58 manu_: We have mentioned binary expression of VC multiple times. This exists today as CBOR-lD and it is deployed and working. These arguments about binary are not convincing at all. That mechanism does do mapping leveraging the context. 16:47:13 q+ to say we will wind up with 1.1 equivalent problems if we don't align with cbor and cose sign1 16:47:23 manu_: we took this approach because of the open world model and can't expect that every term is managed by a working group. 16:47:56 manu_: they do automated mapping from the data model to an arbitrary middle format. When you verify you back into JSON just like the data model. 16:48:10 manu_: much less problem if that was the approach we are taking here, but we are not. 16:48:43 manu_: We are saying that manual mapping was a bad idea and we should never do it again. Automated mapping has worked well. 16:48:53 whats the difference between manual mapping and automated mapping? 16:48:58 I think the distinction between 'manual mapping' and 'automated mapping' is kind of murky.. 16:50:06 manu_: if we have a different context for a JWT you could keep the JWT names and there would be an automated mapping because of the context the JWT people can ignore that would reconcile this method. 16:50:24 manu_: There would have to be some automated mapping of some kind. But this proposal feels dead in the water to me. 16:50:31 q+ to clarify if automated mapping means using LD to do it, vs defining it by hand 16:50:32 manu_: demonstrated that we can get to binary already 16:50:59 decentralgabe has joined #vcwg 16:51:03 q+ 16:51:08 +1 manu, throughout 16:51:08 ack JoeAndrieu 16:51:09 JoeAndrieu, you wanted to say our job is to make choices. at the level of data model having two fundamentally different objects would not serve interoperability. Securing VCs with 16:51:09 manu_: normative statements in the document are not satisfied. Just because we merged doesn't mean we agreed. 16:51:09 so is it the LD part that is the issue (or lack of it in the example)? 16:51:11 ... JWT is a great idea. Redefining a seconday VC representation to do so is not. 16:51:34 JoeAndrieu: I don't think this was merged with consensus. 16:52:02 JoeAndrieu: as Manu said we do have CBOR LD. Pure FUD if we say we can't get to CBOR. We can get there. 16:52:35 JoeAndrieu: This is not a W3C VC. In the W3C VC working group, they mean W3C VCs, which it is not. Does not meet the normative requirements in the VCDM. 16:53:21 JoeAndrieu: as we have said before, our job is to make choices. Having two fundamentally different data models is not effective. 16:53:49 JoeAndrieu: We must agree on the single model of the thing that we are securing with our different data integrity methods. 16:53:51 +1 to JoeAndrieu 16:53:52 ack dlongley 16:53:52 dlongley, you wanted to say that VC-JWT 1.1 involved a mapping that produced a valid credential 16:54:25 dlongley: Agree with Joe. I dont think that this limits us to add more in version 3. 16:54:36 q- 16:54:45 dlongley: we could pick any spec and ignore normative statements and say it meets the spec. 16:55:08 dlongley: For example we could grab the opening statement from the JWT spec interpret this 16:55:48 dlongley: The VC-JWT 1.1 rules met the requirements of the VCDM. 16:56:10 identitywoman has joined #vcwg 16:56:23 dlongley: Sometime when you coming two technologies to get their benefits, there will be conflicts and you have to chose between them. That's oK and part of the standards process 16:56:24 decentralgabe has joined #vcwg 16:56:31 q+ 16:56:37 can you hear me ok? 16:56:39 one second 16:56:40 present+ davidc 16:56:44 /me no audio 16:57:01 ack dmitriz 16:57:43 dmitriz: discuss mprorocks early question. What would the right side have to look like 16:57:43 DavidC has joined #vcwg 16:57:43 dmitriz: It would have to have the required VC fields. issuer and credential subject 16:58:14 dmitriz: the claims about the subject and VC must be separated on different nesting levels. Right side would have to maintain this. 16:58:22 dmitriz: name in this example is the name of the VC not the name of the subject 16:58:22 gkellogg has joined #vcwg 16:58:31 dmitriz: given that our goal is compactness, there are ways of making context required and keeping it compact, like CBOR-LD. 16:59:07 dmitriz: summary: Not all the required fields, and makes context optional. 16:59:33 dmitriz: iss is a string only. but VCDM is an object. 16:59:47 another important requirement: "Libraries or processors that support JSON-LD can process the @context property using full JSON-LD processing as expected." 17:00:15 rrsagent, draft minutes 17:00:16 I have made the request to generate https://www.w3.org/2023/02/15-vcwg-minutes.html ivan 17:00:23 resuming ~1pm ET 17:00:51 +1 dmitriz, dlongley 17:05:21 ivan has joined #vcwg 17:12:56 q? 17:13:04 q+ 17:50:06 dmitriz has joined #vcwg 17:50:27 dwaite has joined #vcwg 17:55:50 selfissued has joined #vcwg 17:55:55 present+ 17:57:36 decentralgabe has joined #vcwg 18:00:06 brent has joined #vcwg 18:00:10 present+ 18:01:13 scribe- 18:01:21 present+ 18:01:23 manu_ has joined #vcwg 18:01:34 q? 18:01:47 q? 18:02:56 JoeAndrieu has joined #vcwg 18:03:05 q- 18:03:13 Phil_F has joined #vcwg 18:03:27 q+ to note automatic mapping is a valid way of getting to/from VCs. 18:04:31 mkhraisha has joined #vcwg 18:04:58 scribe+ 18:06:05 andres has joined #vcwg 18:07:07 will has joined #vcwg 18:07:12 q+ to talk about not restricting ourselves with current language 18:07:15 samsmith has joined #vcwg 18:07:24 present + 18:07:46 present+ 18:12:33 You're asking too much of AI - we can't even get calendars right. 18:13:35 ack Orie 18:14:37 Orie: we've been talking about data integrity and JWT as the only ways to secure the core data model - in 1.1 there was this other thing we talked about - CL signatures and other things. That existed back then, there was similar questions about whether it was or not a Verifiable Credential. Historical context, not new that we've had trouble determining whether something is a verifiable credential. 18:15:28 Orie: CBOR-LD is not a verifiable credential but a transformation on verifiable credentials, similar to GZIP. Talked a bit over lunch, hidden in that is some important next-step types of things. A mapping to and from a VC is different from a native format. 18:16:40 Orie: the other thing we discussed over lunch, there seems to be some amount of consensus that mappings were important for understanding whether you are talking about a verifiable credential. There is trivial mapping, such as credential+ld+json - these bytes are a credential. That trivial mapping seems to have some type of agreement. 18:17:56 Orie: if mapping is fundamental to what a credential is, how can we constrain that (mapping) to get further agreement. If I have opaque blocks that I feed into a black box, if I get out something that looks like credential+ld+json, that may be acceptable. How much of that black box needs to be exposed, and what does this opaque format look like -w hat sort of constraints do you have. 18:18:13 Orie: sidesteps the native conversation somewhat 18:18:24 ack dwaite 18:18:25 scribe+ 18:18:31 +1 to the fuzzy idea of something that goes into / comes out of a black box as a credential+ld+json (and securing that content) being a verifiable credential 18:18:40 q? 18:19:02 dwaite: Just wanted to clarify something... MikeP said @context is one of the required fields, mapping layer from JSON to RDF, if issuer isn't there, it will just map to something that isn't an issuer. It's the specification that creates those additional requirements. 18:19:17 (also has to be an object, in addition to url) 18:19:45 q+ 18:19:58 ack mprorock 18:19:58 mprorock, you wanted to say we will wind up with 1.1 equivalent problems if we don't align with cbor and cose sign1 18:19:59 dwaite: oneo f the requirments we could have is it has to be a URL with same semantics... difference between binary and native formats... when you talk about CBOR as a compression algorithm in a QR Code, ifyou talk about IOT devices as json or RDF processing model, but thy need to include URDNA, it becomes a bit untenable, wont work for some deployments, not enough physical size. 18:21:44 mprorock: lead to possible proposal - if we can reliable go from one format into a VC-compliant document, thats ok then to say "this is a VC". Some of this has been presented before - but we could define a vocabulary that takes in VC data model and then defines the terms that have a direct correspondence in a JWT, and uses them as defined by the context in verifiable credentials - must downselect certain capabilities 18:22:46 q- 18:22:55 mprorock: if that is a viable path, the other implied option is to say since we are already down selecting and since this is version 2, we could state that it must not contain a context in the vc-jwt itself - but if you are going to call it a vc-jwt, this is the context that is to be used in that conversion such that you get a compliant vc data model document 18:23:03 kristina has joined #vcwg 18:23:07 q? 18:23:17 zakim, who is here? 18:23:17 Present: brent, ivan, identitywoman, TallTed, dlongley, dmitriz, manu_, GeunHyung_Kim, shigeya, decentralgabe, mprorock, Phil-ASU, andres, kristina, Orie, campbell, 18:23:21 ... Paul_Dietrich_GS1, oliver, Phil_F, przemek, samsmith, JoeAndrieu, selfissued, dwaite, davidc 18:23:21 On IRC I see kristina, samsmith, will, andres, mkhraisha, Phil_F, JoeAndrieu, manu_, brent, decentralgabe, selfissued, dwaite, dmitriz, DavidC, identitywoman, przemek, tzviya, BC, 18:23:21 ... Paul_Dietrich_GS1, Phil-ASU, mprorock, GeunHyung_Kim, RRSAgent, Zakim, TallTed, dlongley, cel, saysaywhat, csarven, shigeya, hadleybeeman, bigbluehat, Dongwoo, stonematt, 18:23:23 ... dlehn, npd, w3c_modbot, stenr_, cel[h], ounfacdo, manu, bumblefudge, cel[m], rhiaro 18:23:48 like an implied context... 18:23:48 mprorock: the advantage is that we can have things which just look like a normal JWT - possibly with additional required properties, that can always go back to VC data model. It also sets up from a CBOR standpoint to use those existing mappings for already defined claims, and use those existing encodings 18:23:55 present+ 18:24:11 manjaroi3 has joined #vcwg 18:24:24 would have to see the details of what Mike Prorock is saying, but the general theory seems like there may be a way to have that work, at least for some use cases 18:24:47 mprorock: implicit XSLT, but dislike it compared to other options such as not having semantics about things in core VC. 18:24:57 q- 18:25:25 ack selfissued 18:25:35 +1 to ... any credential+ld+json => magic transformation => JWT => magic untransformation => same credential+ld+json 18:26:33 selfissued: I apreciate efforst to engineer a path forward, helpful to have face-to-face meetings to incubate such ideas. Could live with that mapping - that cynical Mike could then say you could define a mapping that concrete implementations choose not to use (to VC data model). 18:26:38 ack DavidC 18:27:39 we heard it on Zoom just fine! 18:28:27 DavidC: party A has a document in the VC Data Model, has the subject and optional attributes - they put a proof on it - JSON-LD, JWT proof. Pass it to party B, strips off that proof, passes it back to A. They will end up with the same document they started with *nods* 18:29:05 q? 18:31:51 DavidC: the issuance time, are not in the data model. The crypto can a different lifetime (in JWT) than the credential claims themselves - a driving privilege may be good for decades, while several licenses may need to be renewed over the years. The id of the credential becomes the issuer, then the VC property contains the VCDM. 18:31:51 (the only thing that gets lost in most automated mappings, is the timezone on the 3 timestamps) 18:31:51 that is 1.1 approach 18:31:51 since JWT expresses timestamps as epoch seconds. and timezone is lost 18:31:51 +1 dimitriz - the spec needs text around these items, e.g. zulu time 18:31:51 he said NGI-Atlantic before mentioning JFF 18:31:51 DavidC: We have shown this between issuers and verifiers JFF plugfest - ran through schema rules and conformed to VCDM. Put the entire VCDM and put it into the VC claim 18:31:51 brentz has joined #vcwg 18:31:51 q? 18:31:51 ack manu_ 18:31:51 manu_, you wanted to note automatic mapping is a valid way of getting to/from VCs. 18:32:04 Orie has joined #vcwg 18:32:19 present+ 18:32:37 DavidC's approach sounds viable 18:32:59 @dlongley - wait, DavidC's approach is the 1.1 approach, no? 18:33:06 dmitriz: it's a tweak on it 18:33:13 what's the tweak? 18:33:15 q+ 18:33:23 dmitriz: get rid of "instead of" is the biggest most important tweak 18:33:30 q+ 18:33:53 manu_: +1 , value in certain kinds of mapping. Previous mapping did not work out well. Two proposals - David Chadwick's approach is to copy without omitting, Mike Prorock's suggestion is to define a mapping for fields to and from claims set. Concerned that translations have problems, such as dates and issuer strings. You would end up with something that looks more like a JWT. Feel David Chadwick's approach is cleaner due to separations 18:33:54 ack samsmith 18:34:43 q? 18:34:52 samsmith: make a modified proposal - like the idea of implied @context, it allows for a broader adoptability of VCs - if for not other reason that if you made a graph; one axis people who benefit from primary intent of linked data, with end-to-end semantic interoperability 18:35:13 samsmith: secured with data integrity or other proof. But for many implementations that provides little benefit with a lot of cost 18:36:16 samsmith: on other axis, we have security - applications that find linked data proofs sufficient and appropriate for their needs, other find they do not benefit from a linked data representation (and need another form of security) or the data integrity proof is insufficient for their needs 18:37:16 samsmith: so you now have four quadrants, but only one is satisfied when RDF is a representation. We can argue whether they are important, and if so that is the will of the working group. If we agree those others need to exist, then the implied @context helps us get there. 18:37:44 q+ to ask if we are open to debating optionality of @context at this time? 18:37:46 sound like a given "intermediate securing format" can do whatever it wants ... as long as when credential+ld+json (which always has `@context`) gets transformed ... it's lossless; you always get it back again as the same credential+ld+json. 18:38:22 +1 to Joe's point, I think Sam's current point is off topic 18:39:00 samsmith: you would not get the benefit of the intermediate representation. Been arguing we should have a layered approach, the cryptographic operations are distinct from the usability of the claim set. NIST does a good job where they separate IAL and AAL (assurance levels). When we talked yesterday about the issuer binding etc assurances, we are using that NIST model where you have assurance levels. What we didn't say is what authenticator assuran[CUT] 18:39:55 samsmith: but those don't belong in a claim set, they have to do with the authenticator. They may have something to do with the subject - and can be linked by the same identifier. By conflating the two, we create confusion. By making that distinction, we make it clearer for others to consume what we are defining. 18:40:18 samsmith: that means authenticators are metadata, and are not in the claim set or intermediate representation 18:40:33 q+ 18:41:05 ack DavidC 18:42:02 DavidC: point out that mike's proposal is flawed from a security perspective - the issuance and expiry of the credential are not the same of the credential are the same as the JWT. The previous example of the driving license. If you do mappings between them, you will get in trouble. 18:43:14 provide a vocabulary and set of rules (e.g. around epoch time) that describes registered claims in JWTs in json-ld, and add other definitions as required that must be present in the JWT - this context must be used to translate from a JWT to a valid VC 18:43:14 q- 18:43:26 ack mprorock 18:44:22 mprorock: doesn't disagree with David - there are mappings between some of the registered claims, and how you can do those with a JWT - it is not 1:1. There is this notion that certain other data fields would be necessary there. This gives us the opportunity to identify those, possibly add new claims if needed. Provides us a way to reconcile these two things. 18:44:24 ack JoeAndrieu 18:44:24 JoeAndrieu, you wanted to ask if we are open to debating optionality of @context at this time? 18:44:50 > this context must be used to translate from a JWT to a valid VC 18:45:15 mprorock, so now everyone who uses vc-jwt needs to do the transformation using context..? 18:45:32 I filed https://github.com/w3c/vc-jwt/issues/53 to cover the 3 kinds of mapping I heard. 18:45:40 JoeAndrieu: defer some comments on optional @context. Highlight something DavidC touched on - which is the conflation of real world credential lifetime and the VC lifetime. In my case I would argue that his example is incorrect - the lifetime on my physical driving license is that of the physical credential and not the driving privilege on at a DMV. A bunch of the JFF folks 18:46:02 JoeAndrieu: used the ID of the diploma, we need to resolve that 18:46:24 @JoeAndrieu. I know how. The metadata of the proof is separate from the metadata of the credential 18:46:28 JoeAndrieu: if @context is not required in that VC property, how do you round-trip on a credential with a custom @context. 18:46:50 q+ 18:47:05 mprorock: if you go from a VC in JSON-LD to a VC-JWT,... 18:47:14 JoeAndrieu: so I think it may fail that black box 18:47:15 zakim, close the queue 18:47:15 ok, kristina, the speaker queue is closed 18:47:21 ack DavidC 18:47:22 ack DavidC 18:47:41 DavidC: think I know how to solve this issue - the claims about the subject and in the VCDM are distinct from the claims used for the proof 18:48:21 to clarify you mean metadata about credential subject vs metadata about vc? 18:48:22 DavidC: a number of incidents where we talk about claims of the VC that are actually metadata of the credential, has its own metadata such as its serial number or issuance data 18:48:22 See this issue filed by ivan.... seems relevant: https://github.com/w3c/vc-data-model/issues/1044 18:48:56 DavidC: think JFF got it right when they put the certificate identifier as the credential identifier, each proof would have a different identifier but the credential data would have the same number 18:49:24 subtopic: https://github.com/w3c/vc-jwt/issues/53 18:50:26 Orie: (slides) SD-JWT VC? Relevant slides to feature freeze and mapping conversations, as well as to the governance framework and 'what the world things' about verifiable credentials 18:51:05 wrt signing json-ld payload using sd-jwt: https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/212 18:51:08 feedback welcome 18:51:38 Orie: temperature gauge emoji indicates that we are trying to gauge enthusiasm. Potential debate over typ/cty 18:51:50 q+ 18:52:07 zakim, open the queue 18:52:07 ok, kristina, the speaker queue is open 18:52:12 q+ DavidC 18:52:43 Orie: how can these parameters help us here. content type (cty) vc+sd+jwt - draw attention to the payload side of this window, 'cnf' claim may be related to holder binding 18:53:18 Orie: Feature Freeze is Coming 18:53:57 don't think sd-jwt vp makes sense.... 18:54:09 slide should be advanced 18:54:13 Orie: VP question - you haven't seen a VP-JWT yet, we have statements in VC-JWT which refine those rules, restating them. 18:54:57 Orie: want to ask - for SD-JWT, does the VP format look different or similar to VC-JWT, is there a way to indicate the entire token is a presentation rather than a kind of payload. 18:56:06 Orie: JOSE-WG is back, asked IETF to work on standardizing JSON Web Proofs, CFRG is working on BLS 12-381 some intention for JWP to use that 18:56:31 Orie: pointing this out to be clear that this is all separate from the item on whether BBS should be brought in before feature freeze 18:57:12 q+ to advocate for blackbox security. I think we can do SD within the LD data model. I'd like to explore that rather than define a new base object that needs securing. 18:57:28 Orie: May decide to bring it in if JOSE WG finishes, or if it is deferred after rechartering independent of IETF. 18:57:45 ack DavidC 18:57:46 selfissued: JOSE is chartered to work more broadly than just JWP, working on algorithm review 18:58:36 q+ 18:58:53 DavidC: quite like the SD-JWT work now, it has significantly improved, IMHO better than the ISO way of doing this. I think we should regard a SD-JWT as a different proofing mechanism of a verifiable credential data model document . We should define how you convert a VCDM to and from SD-JWT. That should be done within our working group rather than the IETF. The current IETF example is not a good example - doesn't even have an @context 18:59:24 DavidC: I think that is what we should do, think it would be valuable work. 18:59:28 ack JoeAndrieu 18:59:28 JoeAndrieu, you wanted to advocate for blackbox security. I think we can do SD within the LD data model. I'd like to explore that rather than define a new base object that needs 18:59:31 ... securing. 19:00:13 ietf sd-jwt-vc example is for `credential-claims-set+json` in v2 :P 19:00:50 JoeAndrieu: echoing what David said. I think it is important that we minimize the root data objects that we are securing using properties/proof types in credential+ld+json. That is what is coming out of Merkle world at reboot. Can we do the selective disclosure on the current VCDM with minimal changes. Concerned if the right side of the slide (SD-JWT) has the black box model. Once they disclose, they can't convert back to the VC 19:01:38 JoeAndrieu: selectively disclosed terms on the recipient can't jam it into the original VC because it is not there 19:01:50 q+ 19:06:25 DavidC: when it converted back you get a VCDM of the revealed bits only, the signature is over the whole lot. 19:06:25 ack mprorock 19:06:25 my suggestion would be let's not talk about VPs with sd-jwts 19:06:25 +1 19:06:25 i mean VP that uses sd-jwt mechanism to selectively release claims in a VP 19:06:25 jwt-vp can contain sd-jwt-vc, no worries 19:06:25 The VP should be the way of selectively disclosing bits of the SD-JWT 19:06:25 mprorock: the closer we keep or provide for translation for normal JWTS, CWTs, and stuff like that - the easier it is to leverage this stuff immediately when it comes out without a lot of work. When I think of cross-ecosystem work between IETF and W3C, that is one of the advantages and one of the reasons I've been pushing for something which is both a JWT and a VC. 19:06:25 ack dwaite 19:06:25 dwaite: Talking about a black box model, we don't have to have more permutations / combiations. Black box would be a part of the proofing mechanism, that's how selective disclosure works. 19:06:25 dwaite: For anything that's not an RDF canonicalization model. 19:06:25 where are we with content types for presentations..? 19:07:06 q? 19:07:10 Orie: JWP - has somewhat the same model as SD-JWT, where the holder derives a presentation and presents that forward. BBS Data integrity proofs have that property as well. Similar in that they have a 1st credential representation which is the full credential as given by the issuer, and a second form which is presented to the verifier 19:07:56 Orie: claims piece - not sure this is still part of JWP, idea that I can tell you the kinds of fields which are in my progressive disclosure payload, may know information about what a credential is without selective disclosure 19:07:57 q+ 19:08:41 Orie: gets into how much you are required to reveal, which is a similar concept on all formats. The type of data integrity proof protected credential is revealed, that type communicates some of the properties you would expect. There's field names in SD-JWT and JWP 19:09:22 Orie: there seems to be a bit of a key/value pair concept repeating here, they don't always play super-nice together. You might need to transform an object to get key-value pairs. You have to be careful when you do that mapping and with that guidance. 19:09:46 Orie: the more the DM constrains the mapping, the more the other side has to constrain things, which was the sort of thing that made people really unhappy with 1.1 19:09:47 ack dwaite 19:10:15 q+ 19:10:28 dwaite: JWP is early, its in flux, the claims part is a part of JPT JSON Proof Tokens, that would have the most bikeshedding. 19:11:26 dwaite: We have the flexibility to say that this claims isn't needed, a different mechanism could be used, even down the point where you say the payload is NQuads. The claims on this slide are an effort to get what you get from JWTs today. This is in flux and possibly at a lower level than we'd want, similar to conversations about the body being a JWT claim set or JSON-LD. 19:11:42 ack kristina 19:13:11 kristina: update on SD-JWT side: the approach has changed quite a bit since TPAC; there have been a lot of improvements to the format. The current approach has implementations - contrary to previous approach, the current approach might not need explicit guidance to use with verifiable credentials as long as you understand the sd-jwt claims. Feedback welcome on whether this hypothesis is true or not 19:13:11 q+ 19:13:28 q+ to ask about SD-JWT vs. BBS in this group? 19:13:52 kristina: there is a market need to answer what is a SD-JWT VC. Either we say look at both specs together because it is clear, or if not we need to decide which working group that work happens in 19:13:56 ack dwaite 19:14:09 q+ to respond to manu 19:14:57 dwaite: From what I've seen of SD-JWT, it would be more of handling claim set and JSON-LD without defining rules beyond how to take SD-JWT how pieces have been redacted/filled in as a JSON document and interpret that as JSON. Given that we have content types that are JSON, where pieces can be adjusted, there might not be guidance there. There could be guidance around selective disclosure requirements and how things are mandatory to disclose. 19:15:07 dwaite: That's probably where people would still need guidance. 19:15:07 ack manu_ 19:15:07 manu_, you wanted to ask about SD-JWT vs. BBS in this group? 19:15:08 +1 19:15:17 q+ 19:15:28 generally +1 to dwaite 19:15:33 for those interested: https://docs.google.com/presentation/d/1h4za0rEf2FFd3ZvpN8kIfTR15jF9GPQMXAZ7miIwJpg/edit#slide=id.g18679a2d900_0_0 19:15:44 q+ 19:15:47 manu_: the differences between SD-JWT, BBS into the group, what is the overlap, how do they differentiate from one another. BBS is designed so that you can do selective disclosure but not do repeatable signatures 19:15:49 q+ orie 19:15:50 q- 19:16:47 samsmith has joined #vcwg 19:16:54 q 19:17:13 manu_: one of them seems to have better properties than the other, with the problem with BBS being on a different path, not NIST crypto. Highlighting that this question on differentiation is going to come up. Imagine SD-JWT's reason would be NIST crypto. If we pull BBS+ in, people will understand that it is not NIST approved, signals that some parties may issue it even if they can't accept it, JWP is hardest to answer 19:17:58 ack brentz 19:17:59 brentz, you wanted to respond to manu 19:18:11 manu_: feels like we need to have all these conversations in the next 1.5-2 months, doesn't feel like we will have stable enough representations to go into CR in the next four months. Which may be ok, but then we are already thinking about re-chartering to including that work 19:19:38 q? 19:19:44 brentz: Likes to do everything - mdoc, SD-JWT, BBS, etc. Having said that, company roadmap includes a VC-spec compliant, BBS-protected selective disclosure JWP. May need to see about resourcing to get those specified 19:19:46 ack mprorock 19:19:55 IETF is march 25th 19:20:27 q+ on sd-jwt 19:21:27 kgriffin has joined #vcwg 19:21:28 mprorock: fortunately, IETF meeting coming up - we can talk about things in a note if it feels that something will not make it. Things like SD-JWT are very interesting to me. I think we can be very practical, the week after IETF if they have not gotten a signal from IETF, we table it. I think we have enough to go in and get a usable 2.0 spec. 19:21:55 mprorock: maybe we recharter or go into maintenance mode, until we have input documents ready 19:21:56 ack orie 19:22:02 zakim, close the queue 19:22:02 ok, kristina, the speaker queue is closed 19:22:56 Orie: for SD-JWT, the ability to do selective disclosure with the existing toolchain and support for the object data model are all really important. A major distinguishing factor with SD-JWT, JWP with BBS, Data Integrity for BBS. JWP: waiting for IETF, DI you are waiting for IETF and doing canonicalization. 19:23:50 Orie: Totally fine to decide we are not going to get to JWP in this charter, may not get to BBS+DI in this charter, it would be a massive mistake to not get SD-JWT into the current structure some way due to the positioning of it within the ecosystem and path to deployment on existing technologies 19:24:01 ack BC 19:24:01 BC, you wanted to comment on sd-jwt 19:24:32 BC: following a bit - intent on SD-JWT is to operate on a claim set with the ability to redact claims within that set. It shouldn't be disallowed, 19:24:43 lost you brian, be prepared to repeat 19:26:19 BC: the goal of SD-JWT is to be almost drop-in usage for existing JWT, really just a redaction technique for content in claims themselves. Almost as though VC-JWT could just leverage SD-JWT without any particular guidance in place 19:26:19 q+ 19:29:42 resuming 14:45 ET? 19:33:34 reconvening in 17min - around 2:50 19:47:37 kgriffin has joined #vcwg 19:47:38 manu_ has joined #vcwg 19:47:49 q 19:48:10 zakim, open the queue 19:48:10 ok, kristina, the speaker queue is open 19:48:12 q? 19:48:21 we are resuming 19:48:26 brent has joined #vcwg 19:48:39 JoeAndrieu has joined #vcwg 19:49:52 dwaite has joined #vcwg 19:50:11 selfissued has joined #vcwg 19:50:11 people can hear us, right? 19:50:14 Phil_F has joined #vcwg 19:50:18 present+ 19:50:21 scribe+ 19:50:40 Paul_Dietrich_GS1 has joined #vcwg 19:50:45 present+ 19:50:47 kristina: We talked about data integrity, we talked about VC-JWT 19:51:07 ... There may be confusion about how SD-JWT relates to the other things 19:51:26 topic: acdc 19:51:41 s/SD-JWT/ACDC 19:51:46 Phil_F: A question came up about the proposal to have an assumed @context 19:52:10 ... For ACDCs we could create a proposal on how to secure VCs with ACDCs 19:52:31 ... We wondered if the assumed @context will go into the VCDM spec 19:52:38 q+ to note dangers of assumed contexts. 19:52:51 ... ACDCs would be peers to JWTs and data integrity 19:53:17 samsmith: ACDCs are proof containers 19:53:51 ... If you want to include a full-blown VCDM object into an ACDC proof, you could do that 19:54:06 ... The ACDC itself doesn't care what's in its payload 19:54:24 q+ to ask about credential+ld+json 19:54:34 ... They're used to secure ISDL documents, for instance, which will never be JSON 19:54:51 iXBRL documents 19:55:11 q+ 19:55:12 Xml Business Reporting Language 19:55:17 kristina: Thanks for bringing clarity on that topic 19:55:20 ack manu_ 19:55:20 manu_, you wanted to note dangers of assumed contexts. 19:55:43 manu: We haven't had the discussion about an assumed @context yet 19:56:01 ... The problem about an assumed @context is then you're locked into that version forever 19:56:01 q- 19:56:13 ... It can solve some problems and it can create some problems 19:56:22 ack brent 19:56:22 brent, you wanted to ask about credential+ld+json 19:56:58 q? 19:57:13 brent: Are we talking about specifically securing VCDM objects or also other types 19:57:16 smccown has joined #vcwg 19:57:21 Topic: Ready for PR Issues 19:57:26 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22ready+for+PR%22 19:57:30 Phil_F: We also want to secure other content types 19:57:39 Orie has joined #vcwg 19:57:48 present+ 19:58:16 subtopic: https://github.com/w3c/vc-data-model/issues/965 19:59:42 manu: As David Chadwick pointed out earlier, there are different kinds of issuance dates 20:00:13 ... There is the credential issuance date and the signing date 20:00:16 q+ 20:00:29 DavidC: The proof should have its own issuance date and expiration date 20:00:37 q+ 20:00:38 ... That's different from what's in the credential 20:01:04 kristina: There is agreement that these are separate 20:01:18 ... That's true both about the credential and how it's secured 20:01:35 ... This issue isn't clear enough on this point. I'd like to close it. 20:01:49 ... We need guidance in the spec on the differences 20:02:01 DavidC: If we do that, that would solve everything 20:02:07 ack Orie 20:02:07 q- 20:02:11 kristina: Would you like to do a PR, David? 20:02:13 ack JoeAndrieu 20:02:20 DavidC: Yes, I'd be glad to do a PR 20:02:48 JoeAndrieu: There's a real-world thing I have called a bachellors of science 20:03:15 ... That's different than the credential representing the bachellors 20:03:51 will has joined #vcwg 20:03:54 JoeAndrieu: There is naming confusion between the three things 20:04:03 kristina: Is there an issue for that? 20:04:18 the diploma is distinct from the degree 20:04:23 JoeAndrieu: We need to find a way to talk about this 20:04:35 subtopic: https://github.com/w3c/vc-data-model/issues/956 20:04:45 s/the diploma/TallTed: the diploma/ 20:04:45 DavidC: When I do the PR, Joe, you can suggest edits to the wording 20:05:20 manu: I need to get to this 20:05:22 subtopic: https://github.com/w3c/vc-data-model/issues/952 20:05:42 q? 20:06:19 kristina: We want to see concrete text to make progress 20:06:30 dmitriz: This is the concrete text 20:06:35 ... It's ready for discussion 20:06:47 ... The proposal is there under straw proposal 20:07:17 kristina: I'm assigning this to Dmitri 20:07:47 the "credential" related issues: https://github.com/w3c/vc-data-model/issues/1009 and https://github.com/w3c/vc-data-model/issues/991 and https://github.com/w3c/vc-data-model/issues/1012 20:07:55 brent: Once it's ready for concrete changes to the spec, raise the PR 20:08:19 kristina: We're getting into feature freeze. If you want this in V2 it needs to happen soon. 20:08:24 subtopic: https://github.com/w3c/vc-data-model/issues/950 20:08:30 decentralgabe has joined #vcwg 20:08:48 decentralgabe: There is a PR 20:08:52 https://github.com/w3c/vc-data-model/pull/1023 20:09:11 subtopic: https://github.com/w3c/vc-data-model/issues/946 20:09:40 kristina: This needs clarification in the spec 20:09:54 ... Is anyone willing to write the clarifying text 20:09:58 manu: I can try 20:09:59 q+ 20:10:37 q+ to share thoughts on id 20:11:02 Orie: He's asking about what you should expect it to be and how should you handle it 20:11:10 ack DavidC 20:11:14 ... This is related to the URL vs. URI confusion 20:11:32 DavidC: I have an issue with the "parts of" wording 20:11:47 (the question that almost all devs new to VCs ask is - 1) is 'id' required? 2) is it /supposed/ to be globally unique? Or can I use like a database row # for the id? 20:11:51 ... The credential schema should be one thing 20:12:05 ... There's a disagreement there 20:12:10 q+ to question WhatWG situation 20:12:31 q+ 20:12:36 ... I don't think there's agreement that Gabe's proposal should be accepted 20:12:39 ack dmitriz 20:12:39 dmitriz, you wanted to share thoughts on id 20:12:51 dmitriz: Maybe this text belongs more in the Implementation Guide 20:12:59 ... I think we want to add it in the spec 20:13:13 ... Is it required and must it be globally unique? 20:13:34 ... We need guidance to say that it's not required and that it should be globally unique 20:13:40 q+ to say the PR that yesterday we said would be raised will address this 20:13:47 ack JoeAndrieu 20:13:47 JoeAndrieu, you wanted to question WhatWG situation 20:13:48 ... If absent, use the signature string as an ID 20:14:11 JoeAndrieu: We call them URIs. We refer to RFC 3986. 20:14:48 dwaite: There's a normative reference to the WhatWG specification 20:15:38 kristina: If you'd like to revisit, please file an issue 20:15:57 ack brent 20:15:57 brent, you wanted to say the PR that yesterday we said would be raised will address this 20:16:18 brent: Yesterday we had a discussion about IDs 20:16:26 q+ 20:16:32 q+ 20:16:40 subtopic: https://github.com/w3c/vc-data-model/issues/935 20:16:42 ack Orie 20:17:07 Orie: Developers copy the examples and change them 20:17:31 There are several problems in our examples that make them not valid JSON-LD 20:17:52 ... I want them to have no @vocab-extended terms 20:18:23 ack manu_ 20:18:27 ... This issue is an attempt lead developers gently into this reality 20:18:29 q? 20:18:47 manu: We need to give people a nice gentle introduction 20:18:58 ... Maybe this belongs in the Implementer's Guide 20:19:19 ... The base verifiable credential is pretty much useless 20:19:58 ... I'm concerned that people won't be patient and read through all three examples 20:20:30 ... I'm concerned about adding examples that are not where we want people to end up 20:20:34 I think that starting with basic boilerplate and gradually getting more complex is something I find useful when reading specs. 20:20:40 Orie: I agree with that statement 20:21:06 q? 20:21:07 q+ 20:21:20 manu: Our present examples try to exercise too many spec features 20:21:29 Orie: The first example cannot have two contexts 20:21:29 ack will 20:21:53 q+ 20:22:11 ack Paul_Dietrich_GS 20:22:29 q+ 20:22:34 Paul_Dietrich_GS1: As a developer, I will search the examples for the features I want 20:22:34 +1000 specs can /never/ have too many examples 20:22:44 q+ to wonder if we can use real world examples now... like OB, trace, etc? 20:22:45 ... I'm a fan of having numerous examples 20:22:47 ack TallTed 20:23:22 ack manu_ 20:23:22 manu_, you wanted to wonder if we can use real world examples now... like OB, trace, etc? 20:23:29 TallTed: We can include links to spec text that we want people to read in the examples 20:23:44 q+ 20:24:05 manu: Let's use some real-world examples 20:24:24 ... For instance, a simple open badge example 20:24:29 q+ to suggest not biasing towards domains in our examples 20:24:54 manu: If they copy/paste them, they're going to work 20:25:39 manu: It's a lot of work to go through the spec and revise the examples 20:25:51 ... We can have a "start here" section 20:26:22 ... It would be good to have a section in the spec saying how to move through the developer cycle 20:26:48 q+ 20:26:49 kristina: I disagree with real-world examples in the core spec. But it's fine to have them in an annex. 20:26:51 +1 kristina 20:26:53 q- 20:26:57 ... We don't want to distract readers 20:27:22 ack 20:27:25 ack kristina 20:27:26 That's the approach we use in the SD-JWT spec 20:27:27 ack DavidC 20:27:50 DavidC: I think I've now received conflicting instructions 20:27:59 q+ 20:28:03 ... I was asked to describe the terms of use used by Train 20:28:16 ack kristina 20:28:36 kristina: I see them as being different 20:29:02 ... Adding properties one by one demonstrates that they're useful 20:29:03 q+ to propose a section on what Orie wants... "How to get started with VCs" 20:29:11 ack manu_ 20:29:11 manu_, you wanted to propose a section on what Orie wants... "How to get started with VCs" 20:29:14 brentz has joined #vcwg 20:29:18 I think its a judgement call, and its possibly a good idea to start with a real world example for scenarios we have never seen... 20:29:39 if that is possible... 20:30:05 manu: If we have a section on "how to get started" that builds things up bit by bit it can be early 20:30:29 Orie: I will do individual PRs for the examples 20:30:35 phil_asu has joined #vcwg 20:30:46 present+ 20:31:21 samsmith has joined #vcwg 20:31:25 https://github.com/w3c/vc-data-model/issues/919 20:31:47 kristina: What's the status of this, Gabe? 20:31:56 q? 20:32:03 ack JoeAndrieu 20:32:04 decentralgabe: I don't think there's consensus. I can close it. 20:32:22 JoeAndrieu: I think this has been taken over by the assurance conversation. 20:33:15 subtopic: https://github.com/w3c/vc-data-model/issues/909 20:33:33 manu: We had consensus to define a directory of related work 20:33:57 q+ 20:33:57 subtopic: https://github.com/w3c/vc-data-model/issues/890 20:34:01 ack Orie 20:34:38 Orie: A problem occurs if, as an issuer, I commit to a credential schema then present to you a selectively disclosed credential that doesn't match the schema that I committed to 20:34:52 ... This is best addressed by explaining the situation to people 20:35:00 q+ to ask imp guide 20:35:10 ... And you can design your schema so nothing bad happens 20:35:17 ... That's the best we can do 20:35:36 q+ oliver 20:35:40 DavidC: This can be solved by making every property optional because then everything conforms to the schema 20:35:42 q+ 20:35:47 q+ to say what is optional is an issuer choice 20:35:48 ... But that's not right for mandatory fields 20:35:49 ack brent 20:35:49 brentz, you wanted to ask imp guide 20:36:09 brent: This sounds like potentially a better fit for the Implementer's Guide 20:36:37 ack oliver 20:36:43 ... It can say that the schema you're issuing to needs to allow selective disclosure on the other end 20:37:09 ack dwaite 20:37:12 Oliver: There's another possible solution using JSON schemas 20:37:27 ... For instance, it can express "one of", "many of", etc. 20:37:57 dwaite: There may be different requirements for the full-blown credential and the credential you present to people 20:38:18 ... You either need a schema that can represent both or two schemas or to decide that one of them is out of scope 20:38:18 ack JoeAndrieu 20:38:18 JoeAndrieu, you wanted to say what is optional is an issuer choice 20:38:37 JoeAndrieu: What you just said hurt my brain in a good way 20:38:59 ... The issuer has to decide what is selectively disclosable 20:39:01 q+ 20:39:12 ack Orie 20:39:26 ... The issuer has to put it into the math to enable it 20:39:29 q+ 20:39:46 q+ 20:39:53 Orie: The issuer can express its intention for mandatory-to-disclose fields and protect them 20:40:02 q+ 20:40:16 ... We can write a description of how it works 20:40:35 ack samsmith 20:40:39 ... The credential schema may be useful for this 20:40:50 kgriffin has joined #vcwg 20:41:15 samsmith: In ACDC we use the combination operations of JSON schema, including nesting 20:41:16 q+ to say shouldn't the verifier be setting the schema? 20:41:28 q- 20:41:32 ... This gives the presenter a high degree of flexibility 20:41:41 ack DavidC 20:42:00 q+ 20:42:03 DavidC: in the evidence work we've done, the evidence contains the name & address of the subject 20:42:29 ack brentz 20:42:29 brentz, you wanted to say shouldn't the verifier be setting the schema? 20:42:34 ... Sometimes unintended disclosure can occur 20:42:38 what david is saying is correct, but probably an example is needed to communicate it best. 20:42:39 q? 20:42:43 q+ 20:42:57 brent: This is happening with a different mental model of what the issuer needs to do 20:43:17 ... In my mental model, the verifier knows the schema because it's public information 20:43:37 ... As a verifier, I can request the subset of the information that I want 20:43:52 ... described as a JSON schema 20:44:00 ... It's a different mental model 20:44:14 And the holder can choose to disclose what they wish in that response to the verifier? 20:44:21 samsmith: You can do both together. That's how we do it. 20:44:48 brent: What's actually happening is the intersection 20:44:49 ack kristina 20:44:49 For the notes, https://identity.foundation/presentation-exchange/#presentation-definition 20:45:00 kristina: I think both are needed 20:45:14 +1, both are needed 20:45:17 ... What is in scope for the data model document is the schema for the issuer 20:45:40 ... How the verifier asked the wallet for what it wants is more at the protocol layer 20:45:44 q+ to respond to kristina 20:45:46 ... This is a really complicated topic 20:46:06 ... We're now implementing systems with selective disclosure 20:46:14 ... We're realizing how many things it touches 20:46:17 q+ 20:46:26 +1 kristina 20:46:30 ack smccown 20:46:40 ... We should try to describe the aspects that people need to consider when using selective disclosure 20:46:48 q+ to be concerned about giving guidance w/o having concrete mechanisms that are deployed/deploying. 20:47:21 smccown: They may need to see that I live in the state. They don't need to know my organ donor status. 20:47:40 ack brentz 20:47:40 brentz, you wanted to respond to kristina 20:47:46 ... Without selective disclosure, we'll give them everything in hopes they don't use everything 20:47:50 q? 20:47:57 ... I want selective disclosure to be the norm 20:48:42 brent: Sometimes the verifier won't use the schema because it doesn't care 20:48:48 ack JoeAndrieu 20:49:05 JoeAndrieu: I think we're talking about four different schemas at least 20:49:14 ... 1. The JSON-LD schema 20:49:24 2. A schema describing derivable claims 20:49:39 s/JSON-LD schema/credential schema/ 20:50:10 ... 3. The verifier's desired schema as a result of a presentation request 20:50:26 ... 4: The intersection of 2 and 3 20:50:36 ack manu_ 20:50:36 manu_, you wanted to be concerned about giving guidance w/o having concrete mechanisms that are deployed/deploying. 20:50:48 manu: I'm concerned that we're waving our hands around this 20:50:55 ... A number of us are working on these things 20:51:08 ... They're not in protocols. They're not in implementations. 20:51:23 i disagree, we have this functionality in 1.1, and people are already using this property without good guidance. 20:51:28 q+ to disagree 20:51:34 ... Just like we added things to VC 1.0 that we're now taking out because we haven't figured out how to use them 20:51:35 q+ to disagree 20:51:47 ... It's OK to see "We're working on these things" 20:51:48 +1 to Manu's concern that we need to understand the four perspectives on use cases in the real world. 20:51:49 ack brentz 20:51:49 brentz, you wanted to disagree 20:52:05 brent: I disagree that this isn't in protocols and implementations 20:52:19 ... Anyone who has implemented Presentation Change has done this 20:52:22 How about a selective disclosure use case for the Holder's local address? The local library doesn't care about age, but they do care about residence. This is because local residents can usually use the library for free while non-residents often need to pay a fee. 20:52:29 ... We've implemented this. It's what we're using. 20:52:39 ... Maybe the VC spec could talk about this. 20:52:42 q+ 20:52:44 q+ 20:52:47 ack Orie 20:52:47 Orie, you wanted to disagree 20:53:04 Orie: I disagree that we shouldn't provide guidance 20:53:17 ... There are interoperable implementations using these properties 20:53:47 ... I've worked on Joe's cases #1, #2, and #3 20:54:06 q+ are we talking about presentation protocols in the core data model spec, then? 20:54:11 ack selfissued 20:54:11 #4 is presentation submission from the Presentation Exchange spec 20:54:11 q+ to are we talking about presentation protocols in the core data model spec, then? 20:54:14 scribe+ 20:54:15 ... Even if the guidance is just a heads-up that these things are happening in the wild, it's useful to say that to people 20:54:19 q+ 20:54:22 q? 20:54:29 zakim, close the queue 20:54:29 ok, kristina, the speaker queue is closed 20:54:56 selfissued: brent, you talked about people using presentation exchange in protocols, that's certainly true. I will put on my charter hat and said we intentionally put specification of protocols out of scope. I'm fine saying "this is how things are done in some protocols" without picking winners. 20:55:21 brentz: Yes, I was speaking to more of the how in the data model not in protocol perspective. 20:55:23 brent: I'm talking about saying what objects are passed back and forth - not how they are passed back and forth 20:55:25 q? 20:55:31 ack phil_asu 20:56:08 phil_asu: Are we saying that the holder's response to the verifier can choose to add or omit claims? 20:56:10 Orie: yes 20:56:21 ack manu_ 20:56:21 manu_, you wanted to are we talking about presentation protocols in the core data model spec, then? 20:56:31 It depends, but generally case 2 and case 4 address those concerns 20:56:35 manu: I wanted to underscore the points Mike Jones made 20:56:42 i am uncomfortable saying deny/accept, i am ok saying this is when the schema can be used 20:56:53 deny/accept is policy... 20:56:54 q+ to touch on the necessary issuer decision about what is or is not selectively disclosable 20:57:00 ... It's fine to talk about data elements used in protocols 20:57:06 q? 20:57:12 ... But we should not slide down the slope to defining protocols 20:57:19 ack DavidC 20:57:38 DavidC: The current credential schema addresses Joe's #1 20:57:54 ... We add a new property, which is the disclosable schema. That's #2. 20:58:02 ... That's where the VCDM ends 20:58:10 ... That's my concrete proposal 20:58:11 The concrete proposal is good, even if i don't agree with it. 20:58:28 manu: Is the "disclosable" property being used today? 20:58:37 DavidC: No - it doesn't exist today 20:58:55 Orie: This would make it unambiguous 20:59:09 q+ 20:59:16 JoeAndrieu: If we don't have implementations, we'll have to cut the work anyway 20:59:32 DavidC: We have to specify things for people to implement them 20:59:58 DavidC: I have implemented #1 21:00:19 ... There's the problem that the verifier receives a credential that doesn't conform to the schema 21:00:31 q? 21:00:45 ... We'd say what the schema is that the holder would get and what the schema is that the verifier would get 21:00:52 How is the issuer going to be in a position to know what any given verifier needs? 21:00:53 brent: Assigned to Orie 21:01:28 https://github.com/w3c/vc-data-model/issues/887 21:01:30 https://github.com/w3c/vc-data-model/issues/887 21:01:40 manu: If someone else wants to take #887, that's fine 21:01:56 kristina: all of the other ready-for-PR issues have assigned people 21:02:23 kristina: If anyone else wants to jump in, that would help offload work from the editors 21:02:24 dmitriz_ has joined #vcwg 21:02:30 Orie: We need easier issues! 21:02:58 kristina: (previewed tomorrow's agenda) 21:03:19 ... There is some terminology causing confusing that we should probably discuss 21:03:46 Bayside Marketplace 401 Biscayne Blvd, Miami, FL 33132, USA 21:03:50 430 pm 21:04:09 have fun everyone! 21:04:37 rrsagent, draft minutes 21:04:39 I have made the request to generate https://www.w3.org/2023/02/15-vcwg-minutes.html kristina 21:04:56 zakim, end meeting 21:04:56 As of this point the attendees have been brent, ivan, identitywoman, TallTed, dlongley, dmitriz, manu_, GeunHyung_Kim, shigeya, decentralgabe, mprorock, Phil-ASU, andres, kristina, 21:04:59 ... Orie, campbell, Paul_Dietrich_GS1, oliver, Phil_F, przemek, samsmith, JoeAndrieu, selfissued, dwaite, davidc, mkhraisha, Paul_Dietrich_GS, phil_asu 21:04:59 RRSAgent, please draft minutes 21:05:01 I have made the request to generate https://www.w3.org/2023/02/15-vcwg-minutes.html Zakim 21:05:07 I am happy to have been of service, kristina; please remember to excuse RRSAgent. Goodbye 21:05:07 Zakim has left #vcwg 21:05:11 rrsagent, bye 21:05:11 I see no action items