15:05:19 RRSAgent has joined #vcwg 15:05:19 logging to https://www.w3.org/2022/09/15-vcwg-irc 15:05:21 RRSAgent, make logs Public 15:05:23 please title this meeting ("meeting: ..."), ivan 15:05:29 present+ mprorock 15:05:37 present+ 15:05:40 zoom.app says "An unknown error occurred ... Error Code: 100000502" and prompts to join thru browser (hate hate loathe despise overloading browser!) 15:05:48 Meeting: Verifiable Credentials Working Group F2F, 1st day 15:05:48 Date: 2022-09-15 15:05:48 Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2022Aug/0033.html 15:05:48 chair: kristina, brent 15:05:48 ivan has changed the topic to: Meeting Agenda 2022-09-15: https://lists.w3.org/Archives/Public/public-vc-wg/2022Aug/0033.html 15:05:51 brent_ has joined #vcwg 15:05:56 present+ 15:06:16 phila has joined #vcwg 15:06:28 present+ 15:06:38 present+ 15:07:40 Paul_Dietrich_GS1_ has joined #vcwg 15:07:43 Kosuke_Koiwai has joined #vcwg 15:08:10 hsano_ has joined #vcwg 15:09:03 SamSmith has joined #vcwg 15:09:44 SamSmith_ has joined #vcwg 15:10:01 I am getting a bad gateway on the zoom link 15:10:23 kristina has joined #vcwg 15:10:27 present+ 15:11:06 Jay has joined #vcwg 15:11:16 present+ 15:11:29 present+ 15:12:24 present+ 15:13:09 Orie has joined #vcwg 15:13:17 present+ 15:13:29 zoom seems to be 502 15:14:21 new zoom meeting room: 492 908 0639 15:14:25 passcode 2022 15:15:35 one click to join new room -- https://us02web.zoom.us/j/4929080639?pwd=VXN3ODE0U2x4TFhRK1RhODVBeW9ndz09 15:19:26 osamu has joined #vcwg 15:19:57 kdeangs1 has joined #vcwg 15:22:12 zoom just died 15:25:20 brent__ has joined #vcwg 15:25:26 I can't hear anything 15:25:58 scribe+ 15:26:09 Topic: Introductions and Welcome 15:26:44 brent_: Welcome everyone, we have a full agenda today and tomorrow. Let's start off with some logistics. 15:26:55 decentralgabe has joined #vcwg 15:27:40 brent_: We are meeting under W3C IPR protections, welcome to observers, but if you have not agreed to IPR policy, please don't share anything that concerns IPR. 15:28:07 brent_: We expect you to wear a mask, take your daily covid test, and practice good health practices throughout the day. 15:28:07 dezell has joined #vcwg 15:28:11 present+ 15:28:15 present+ 15:28:20 pchampin has joined #vcwg 15:28:23 kristina has joined #vcwg 15:28:26 present+ 15:28:26 slides: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.p4 15:28:29 brent_: We are going to have 4 scribes throughout the day, we have a sign up list. 15:28:30 mkhraisha has joined #vcwg 15:28:49 cabernet has joined #vcwg 15:28:53 present+ 15:29:22 brent_: Please jump into this slide if you're willing to scribe, if you want to jump in, please add yourself to the scribe list. 15:29:35 brent_: We are live in zoom and IRC, if you want to join the queue, we can add you to the queue. 15:29:40 brentz: I think that's mostly logistics 15:29:47 present+ 15:29:48 dwaite has joined #vcwg 15:29:48 ivan: please present+ if you are in IRC 15:29:48 present+ 15:29:48 present+ 15:29:50 present+ 15:29:50 present+ 15:29:52 present+ 15:29:59 present+ 15:30:01 present+ 15:30:07 present+ 15:30:17 present+ Pierre-Antoine_Champin 15:30:35 present+ Mahmoud_Alkhraishi 15:30:40 Topic: Agenda 15:30:44 present+ Hiroyuki Sano 15:30:53 present+ Chris_Abernethy 15:31:01 goto has joined #vcwg 15:31:15 DavidC has joined #vcwg 15:31:17 present+ 15:31:22 brentz: We are going to start out by talking about use cases. We will then break, then talk about transformations of core data model. 15:31:23 present+ 15:31:41 brentz: We've already decided to split up securing VCs into separate specifications, JWT and Data Integrity 15:32:06 brentz: In the core data model, properties for credential and verifiable credential. We are going to talk about where serialializations should go and where to specify them. 15:32:15 present+ Hiroyuki_Sano 15:32:21 brentz: Then break for lunch, then joint meeting with accessibiity WG, they want to talk about use cases that they have. 15:32:35 brentz: We'll spend the rest of first block of afternoon about cryptosuites and Data Integrity streamlining. 15:33:40 Awesome context setting Kristina. Thank you. 15:33:44 brentz: We'll finish off the day with VC Extensions registries, where should they go, then introduction to AC/DC. Full day today. These are the three primary topics that WG discussed as "the big questions" for the group. 15:34:14 kristina: We are not necessarily trying to reach conclusions, we want to know a direction so when we work through issues/PRs we have a direction, we can streamline conversations. Please be productive, talk to each other, don't try to block -- trying to be constructive and agree on direction so Editors and members are clear on next steps. 15:34:46 ivan: This is a big room, we all wear masks, there are people around table w/o english as primary language -- articulate, don't be super fast when you talk, please try to be loud. 15:35:00 brentz: If you are scribing, you have the power to stop the meeting. 15:35:08 brentz: (to ask people to repeat what they said) 15:35:28 Topic: Mission and Goals 15:35:46 brentz: Our mission is to make expressing, exchanging, VCs easier and more secure on the Web. It's what we're here for. 15:36:19 brentz: We have these deliverables in progress -- VC 2.0, Data Integrity, JWT, JWS2020. 15:37:02 brentz: This is what is in progress. 15:37:14 kristina: If people are familiar with Linked Data Proofs, that has been renamed to Data Integrity. 15:38:12 brentz: Some of these are in working draft stage, some are pre-FPWD, WD doesn't imply consensus, it's a working document to get comments and feedback. Once the group feels that the work has progressed, it's done, ready for implementation, we make it a candidate recommendation. 15:38:44 brentz: We enter CR when we feel it's feature complete, review by privacy, TAG, etc. In order to leave CR, we need implementations in place, normative requirements need multiple independent implementations. 15:39:10 takuya has joined #vcwg 15:39:36 brentz: once we have proof of implementation, we do proposed rec to see if rest of w3C agrees. REC doesn't mean done, it's "done enough" -- we are working to improve VC 1.1 REC. 15:39:42 justin_r has joined #vcwg 15:40:40 brentz: We have until June 2024, we need to go into PR by May 2024, it feels like a long way off, but it's not. We need to go into CR by september of 2023 to do a 2nd CR, we have about a year to get everything done with our primary specification. 15:40:58 brentz: This is also the timeline for every other normative spec, we need to have thigns wrapped up in a year, we have a lot of process to go through to finish them, etc. 15:41:15 brentz: This means that for primary spec, we are looking at march next year for feature freeze, that's about 6-7 months out. 15:41:59 brentz: Goals for this meeting is to make progress on core data model, transformation, border between DM and securing VCs, disposition of non-normative content, data integrity streamlining, vc registries, test suites. 15:42:22 q+ 15:42:40 ack kdeangs1 15:42:44 q? 15:42:52 kdeangs1: We've stated in charter that we're not comitted to backwards compatability. 15:42:53 q+ 15:42:56 ack kdeangs1 15:43:00 ack kdeangs 15:43:02 q- 15:43:07 +1 to breaking changes to fix things!... when we need to. 15:43:20 kristina: Yes, but we do not want to do breaking changes without deep consideration. 15:43:24 +1 esp. on the when we need to 15:43:28 kdeangs: Yes, we don't have to go in with a sledge hammer. 15:43:55 YanZhang has joined #vcwg 15:44:12 brentz: When you introduce yourself, name, and something interesting about yourself. 15:45:00 brentz: Hi, Brent Zundel, I'm here representing Norton Lifelock Avast Evernym. The song that was in my head was The Smiths, lyric was "if a double decker bus crashes into us to die by yourself is such as heavenly way to die" 15:45:10 brentz: I don't know why that was in my head. 15:45:40 Kristina: Hi Kristina, I represent Microsoft, song stuck in my head "Man on the Moon". 15:46:22 Cole_Davis: Hi Cole, Switchboard, I have had Miles Davis in my head. 15:47:06 Dave_longley: Hi Dave Longley, Digital Bazaar, the most recent song stuck in my head was "What does the Fox say", intersting trick, if you're able to do short jingle in your head, you can stop rememering the song by doing tat. 15:47:39 David_Chadwick: Hi David was on University of Kent, founded Verifiable Credentials LTD, bought by crossword cybersecurity director of identity. 15:48:01 David_lehn: David Lehn with Digital Bazaars, working w/ DIDs, VCs, etc for quite some time now. 15:48:25 Jay_Kishigama: Jay from W3C, song in my head ... 15:48:46 Kosuke: Kosuke from KDDI, BTS in my head at times. 15:49:16 s//is "Saturday in the Park by Chicago"/ 15:49:28 Prorock: Mike Prorock, Mesur.io work w/ VCs/DIDs "big city" in my head right now. 15:50:01 Orie: Orie Steele, CTO at Transmute, work with VCs/DIDs -- song in my head is Linkin Park -- crawling in my skin, these wounds they will not heal. 15:50:28 Osamu: Osamu, Osamu from Keio, overseeing some of this work there 15:50:59 Paul_Dietrick: Paul from GS1US, work in innovation group on digital identity work -- "I look just like Bob Dylan" 15:51:26 s/Paul_Dietrick/Paul_Dietrich_GS1_/ 15:51:44 Reisako_Hamano: Risako, software engineer at @@@ Japan. 15:51:51 scribe+ kristina 15:52:01 s/@@@/yahoo 15:52:08 Riosuke_Abe: Riosuke Abe from Keio, working on DID with Shigeya 15:52:54 Sam_Smith: Sam Smith independent general partner with Digital Trust Ventures, Prosapien, working in this space for a while, most recent work is with AC/DC and KERI and one adoption vector is VC / identifier credentials. 15:53:08 Uchi has joined #vcwg 15:53:13 ... was former interim chairman at Sovrin, Dwarf song from Misty Mountains. 15:53:20 Karen has joined #vcwg 15:53:32 present+ Karen Myers 15:53:45 TallTed: Ted Thobodeau, working with everything Linked Data, VC, DIDs, x509, etc. I have no song in my head, rejoicing in my heart from a new fridge. 15:54:07 Chris_Abernethy: I'm Chris with mesur.io working with VCs for supply chain interop. 15:54:30 JohnBradley: John from yubico, sex pistols god save the queen. 15:54:49 DavidWaite: David from Ping Identity, alternative have screaming trees I nearly lost you in my head. 15:55:23 s/Thobodeau/Thibodeau, OpenLink Software/ 15:55:46 Sebastian: Sebastian working id.now, recently working on electronic signatures, work with ETSI, EUDI, FIDO Alliance, interested in work here could reach entire population for EU eople. 15:56:06 Shigeya: Shigeya Suzuki from Keo, mom machine 15:56:16 s/mom/marble/ 15:56:20 present+ joe 15:56:20 present+ SamSmith_ 15:56:29 JoeAndrieu: Joe from VC Editor of Use Case document, song in my head, C&C music machine everybody dance now. 15:56:30 s/Riosuke_/Ryosuke/ 15:57:09 sebastianelfors has joined #vcwg 15:57:09 DavidEzell: David Ezell from Conexxus, song in my head steven sondheim from web side story, brilliant melody, dysptoian mood, onward christian soldiers. 15:57:23 TonyNadaline: tony Nadalin chair WebAuthn group, mr sandman 15:58:13 MikeJones: ike Jones from Microsofto, work on a variety of standards,, JSON web token, go out and clean stall for horse, often listen to music on headphones, blood sweat and tears, spinning wheel is running through my head, what goes up must come down. 15:58:30 present+ 15:58:54 phila: selfissued is being modest. See this tweet from Pam Dingle https://twitter.com/pamelarosiedee/status/1570137774686375936 15:59:00 KarenMyers: Karen with W3C, member outreach, business deelopment, new member steve McCowen from Anonyme, I'm his buddy today. We have had many new members join fro VCs. Song, red solo cup 15:59:35 VitorioB: I work for Okta, been in identity space for a coupel of decades, beliver in t... chang of season by green threater 15:59:44 RichardWorth: Richard from Capital One. 16:00:23 Yie: Yie working on blockchain, and working on VCs for payment, No music in my head. 16:00:49 SteveMcCown: Steve from Anonomy labs, brand new at W3C, what's stuck in my head, REM, end of the world as we know it and I feel fine. 16:01:08 Sakamoto: Tkuya from ... Working on trusted internet. 16:01:17 Mahmoud: Mahmoud from Mavennet, I have rumors from Fleetwood Mac 16:01:34 DavidCohen: David from Block/TBD, song in my head, ... scribe missed 16:01:51 Gabe, not David 16:02:06 Hiroki: Hiroki from Sony, standardization our member an't join tpac, i'm here to learn more about VC work 16:02:41 KevinDean: Kevin from GS1, co editor of VC use cases document, fun fact, from my university ... rented classic hearse with coffin and went into prom. 16:03:03 Yi has joined #vcwg 16:03:16 PhilArcher: Phil work with Kevin at GS1 and Paul, as retired radio jock, trying to fogget songs, LBC news theme is song in my head. 16:03:40 Manu: Hi Manu 16:04:02 SamGoto: Sam from Google Chrome, I have baby shark stuck in my head, my email is goto at google and chromium 16:04:34 PierreAntoine: Hi PA, work on RCH WG and DID WG, have a lot of interest in RDF nd linked data, song in my head, sound of silence, second voice and lyrics of that song. 16:05:18 Ivan: Ivan Herman, from W3C team, staff contact form this working group, was at DID WG to Pieerre, song in my head, flew into vancouver, blues guitar, joe bonamassa, kept me awake, I need to stay awayke, i needt his in my head. 16:05:28 WonsukLee from ETRI, member of DID WG 16:05:33 an earworm antidote for those who may need or want one, now or later: https://www.youtube.com/watch?v=KTCYLbFxTpI 16:05:41 cel: Hi Charles Lehner, from Credentials CG. 16:05:50 brentz: Thanks for everyone that introuced themselves 16:05:53 Topic: Real World Use Cases 16:05:56 present+ 16:06:20 Topic: Real World Use Cases 16:06:39 s/introuced/introduced/ 16:07:08 brentz: This is an open conversation, what feedback have we gotten with VCs, I grabbed examples, we know these things are being used for travel documentation, staff onboarding, customer relationships, age verification, supply chain tracking, education credentials, content authenticity, government ID, eKYC, what else? 16:07:27 slideset: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.p1 16:07:42 [slide 14] 16:08:17 oliver has joined #vcwg 16:08:19 kristina: I do have feelings about this tpic, not just VCs being used on left, we are doing v2, breaking changes are allowed, and we want to be careful with those, what were limitations with specification, how did specification help you to realize what you wanted to realize. How can we do better with updated specification? 16:08:24 present+ oliver_terbu 16:08:50 kristina: One of the biggest reasons, better standardize data integrity, updated data model is in scope, I do want to make sure we have enough implementation experience flowing in to reflect that 16:08:52 q+ 16:09:04 ack manu 16:09:05 scribe+ 16:09:15 q+ 16:09:16 manu: One of our biggest deployments is in retail age verification 16:09:28 JoeAndrieu has joined #vcwg 16:09:28 ... we found the model adequatem but big gaps in in-person presentation 16:09:38 present+ 16:09:47 ... getting the credential small enough to fit a small QR code was a big problem 16:10:03 yeah, per conversation above, mission says "on the web".. 16:10:03 manu: In-person presentation at PoS really hard with exiting software 16:10:22 manu: Other thing we've heard from retail, gov etc want their credential to look a certain way 16:10:36 ... they have no control over that. Adding a PNG makes the credential huge 16:10:43 ... WoT looking at presentation layer 16:10:58 can somebody share the zoom link? the one from the invite seems to be the wrong one. 16:11:05 ... we'd be fine if none of that happens here as external model works, but those are the buggets challenges we soo 16:11:07 ack sebastianelfors 16:11:11 s/soo/see/ 16:11:16 mccown has joined #vcwg 16:11:19 q+ to talk about DPPs 16:11:21 q+ to talk about connecting presentations of credentials to other presentations 16:11:27 I think CSS group in W3C was working on standardizing "visuals" which could be expanded to VCs too 16:11:52 s/contact form this/contact for this/ 16:11:53 sebastianelfors: Sebastian, EU has a large scale pilot going out, public tender, a consortium will be selected, each one focusing on use case, mobile driver's license, covid certificates, payments, we could add those. 16:12:19 ack phila 16:12:19 phila, you wanted to talk about DPPs 16:12:27 s/adequatem/adequate/ 16:13:19 DPP is Digital Product Passport 16:13:22 q+ to talk about display AND operability of unknown VC types 16:13:24 phila: To pick up presentation issue, like manu I'd be ok with it not done here, support existence of rpresentation layer, digital product passport, that should be VC, anything that goes with sale of goods in EU. They will want that to look like Digital Product Passport, presentation layer will be important, we may not need to specify it, we do need to include a hook wehere it can go. 16:13:27 just to note, when drafting the charter, we agreed "The normative specification of APIs or protocols" is out of scope, but yea, we can talk about those 16:13:29 ack mkhraisha 16:13:29 mkhraisha, you wanted to talk about connecting presentations of credentials to other presentations 16:13:54 mahmoud: When we're working with presentations, when it came to connecting set of credentials, no way to say "hey these six credentials are related to other credentials w/o issuing all of them together" 16:14:04 present+ mccown 16:14:11 brentz: Can you speak more to that? 16:14:20 mahmoud: I need a way to relate VCs/VPs together. 16:14:21 q? 16:14:27 ack JoeAndrieu 16:14:27 JoeAndrieu, you wanted to talk about display AND operability of unknown VC types 16:14:42 Kodajima has joined #vcwg 16:15:07 wonsuk has joined #vcwg 16:15:07 JoeAndrieu: I wanted to focus on presentaion effort, large and small, I want to see whole credential, how do we represent it in a way to select one of those? Related, confusion about how generic wallet can handle generic VCs it hasn't seen before, haven't dealt with interop to ensure that works well. 16:15:09 q+ 16:15:16 ack manu 16:15:21 s/ our member an't/; our member can't/ 16:15:38 There is also wallet rendering work happening at DIF: https://identity.foundation/wallet-rendering/ 16:15:41 manu: We'll hear more about this later today but the a11y folks have a lost of use cases they'd like us to consider. I am crossing the border and my ervice dog has its vax 16:15:59 ... preferences on websites, I#d like font to be > size X, contrast >= Y etc 16:16:03 s/ ike Jones from Microsofto/ Mike Jones from Microsoft/ 16:16:07 ... we don't have those in the UCR thay'll come in with 16:16:08 q+ 16:16:15 ack phila 16:16:21 s/ ervice / service / 16:16:24 ack phila 16:16:27 phila: Adding an issue to data model to add hook for presentation (visual or otherwise) 16:16:41 brentz: That was what I was hoping from for that conversation. 16:16:53 kristina: Let's discuss use cases with Joe. 16:17:02 Topic: Updating Use Cases 16:17:28 JoeAndrieu: What we've donen with use cases, what we're doing in next phase, kevin has stepped forward to help with use case. 16:18:22 s/donen/done/ 16:18:25 JoeAndrieu: Current document, we have four major roles, we identify user needs, we have 30 se cases, in 7 domains, have a paragraph. We have user tasks, actions that we expect what people need to do, there are 8 user tasks... issue, verify, assert, amend, etc. 16:18:44 JoeAndrieu: We have shifted some of the names here, these are the tasks that we have in the document, requirements motivatins needs. 16:18:45 https://w3.org/TR/vc-use-cases 16:19:06 s/ motivatins/, motivations,/ 16:19:41 JoeAndrieu: Then we have focal use cases, deeper dive on specific use cases, request us Citzienship, expert dive instructor to maintain ceritfication, inernatinal travel with minor, expnded background, wy this is intersting, who needs to trust whom and who is liable, and finally threat model. 16:19:57 JoeAndrieu: Understood threats, how system can erespond, we have user sequences, creating VC, using VC. 16:20:01 s/ wy / why / 16:20:13 JoeAndrieu: We have 5 example VCs, hat are probably out of date. We should look at current use cases. 16:20:16 s/ceritfication, inernatinal/certification, international/ 16:20:29 s/ hat / that / 16:20:58 q+ 16:21:18 q+ 16:21:19 JoeAndrieu: Lessons learned, amend -- we don't really amend, so maybe we can tkae that out. We have evidence, but no use cases, there are features that people want, in the fullness of time, we don't have us cases. Evidence we have one github convo about capturing the result of a DID Auth -- evidence to verifier that issuer had DID before issuing. 16:21:32 @joeandrieu created an issue about a month ago re:evidence https://github.com/w3c/vc-data-model/issues/919 16:21:48 JoeAndrieu: Present a VC of issuers authority in that particular domain, from state, DMV chartered by state. We don't have any examples, not well highlighted. 16:22:08 s/tkae/take/ 16:22:17 JoeAndrieu: how do you refer to a VC canonically? How do you link? 16:22:47 JoeAndrieu: We refer to identifiers in VCs but not VC about another VC. 16:23:13 JoeAndrieu: another lessons learned, it's hard to get contributions -- easy to get at beginning and end, but not much inbetween. 16:23:41 JoeAndrieu: Maybe we have a more regular rhythm with main call, perhaps keep conversation going, don't want to build tech and use cases, not most exciting thing to do. 16:24:18 JoeAndrieu: There is an understanding of VCs that they are statements from a knowable author, there are systems you can build, knowing statements and what you can do with credential, it's most problematic wrt. VCs should be an authorizatio or not. 16:24:30 JoeAndrieu: Not sure use cases are helping us there. 16:24:32 s/authorizatio/authorization/ 16:24:42 DavidC_ has joined #vcwg 16:24:45 JoeAndrieu: I've already talked about presentation layer. Queue? 16:24:49 ack kristina 16:25:22 Kosuke_Koiwai has joined #vcwg 16:25:46 kristina: Chair hat off, I heard you saying they are not about real life use cases but functions, but at same time, you talk about real life use cases, what is the rationale there, title of document 'use case" feels misleading, maybe it shoud be implementation guide. Might be requirements wishlist for data model. 16:26:12 JoeAndrieu: There are three sets of use cases, problem domain use cases -- tasks of issuing/revoking/asserting -- those are not tied to specific problem (like revocation) 16:26:26 ack phila 16:26:26 JoeAndrieu: Two different ways to look at same functinaltiy 16:26:37 s/functinaltiy/functionality/ 16:27:08 YanZhang has joined #vcwg 16:27:26 phila: I really wanted to make sure GS1 use cases were reflected, we have a lot of people here from Japan, are your use cases for Japan reflected properly here? I'm conscious of large number of people from Japan and Korea, are your needs reflected properly here? 16:27:47 Shigeya: there are several use cases missing, I think we need to add several. 16:27:54 q? 16:29:07 q+ 16:29:15 Vittorio: As an external person when I hear use cases, I'm confused a bit, I understand taxonomy of capabilities and class, there is one extra level that's useful, and that is actual usage. I hear often people point to european use case, they're exploring. Ethiopean airlines might have a few people using, if something is in production, that could iffiuse some of the criticism, you are talking about theoretical scenarios, vs. real world use cases. If you 16:29:15 have numbers, that's incredibly useful. 16:29:19 JoeAndrieu: Yes, I like that, thanks. 16:29:25 ack Jay 16:29:27 q+ 16:29:36 s/iffiuse/diffuse/ 16:29:45 here is the list of 13 use-cases Japanese governments are funding on VC/DIDs: https://www.nttdata-strategy.com/info/trusted_webR3_koubo/saitaku.html?fbclid=IwAR0kdOWKL7bdG_1hRX_HgNZ0GTbev2Atfs26dTjs0x9Ss4MTh7FhQzDL010 16:30:14 it's in japanese, but I think browser translate feature should do a fairly good job 16:30:15 Jay: Related to question from Shigeya, one of the Japanese and Korean language, There are some things in v2 that will help, Any use cases that requires support? 16:30:19 ack YanZhang 16:30:20 +1 to better language support in v2... we are very interested in that related to international supply chain documents. 16:30:25 ack me 16:30:46 DavidC has joined #vcwg 16:30:57 present+ 16:31:13 the actual framing is "Trusted Web", how a Japanese government expects to make Web more "trustworthy" without relying on the platforms. 16:31:22 but the technology expected is VC/DIDs 16:31:59 the Japanese gov is expecting cross-border collaboration, so if you have interest please reach out to shigeya or me (we are both on the advisory board) 16:32:01 1.42Mil USD (200mil JPY) on 13 projects. It's announced last Tuesday. 16:32:34 Yan: From digital twin WG, there are some useful things there. Right now VC standard is useful, at least 6 different projects, two ar deployed, there are challenges, but overall its pretty good. We are issuing diplomas based on VCs, actual academic performance. We also work with WiFi alliance globally, we are going to use DIDs and VCs to solve authentication problems for wifi network. From south africa, use VC for payment, VC had to be ZKP, some argument 16:32:34 in VC standard, which things to use, in that situation, VCs can support decentralized gateways. The current draft is useful, we are happy to discuss, with Canadian government, toxic chemical substance tracking in forest industry. 16:32:35 q+ 16:32:45 ack Paul_Dietrich_GS1_ 16:32:54 s/ ar / are / 16:33:23 Paul_Dietrich_GS1_: Use cases domain needs, question is around focus on B2B vs. B3C, business to consumer individual, individual to individual, was that reflective of what you say, or are there B2B use cases? 16:33:40 q+ 16:33:40 Thanks 16:33:44 JoeAndrieu: It was not intentional, would like more use cases for B2B, where work started, etc. 16:33:48 ack YanZhang 16:34:25 https://w3id.org/traceability <-- B2B Supply Chain uses cases 16:34:53 YanZhang: Payment is B2B, customer is merchant who is hiring a payment gateway to handle their payment, in that situation all transactions were processed on blockchain, prove to say you have money, their transaction history is on chain, otherwise compatible VC/VP to prove that you have enough money in payment gateway. That is important, implement VC, issuer side is a important part, you need SDK/library to integrate with ID systems. 16:36:40 q+ to clarify meaning of "replace amend with reference" 16:36:53 JoeAndrieu: Proposal for new content, real world deployments actual usage, need to understand how these are used in the wild, we can add that. We need to formally adopt this as a work item, hoops to jump through, myself and Kevin are willing to be Editors, with regard to actions, want to repace amend w/ reference, more important use case. A more open ended use case is store, retrieve issue present, ... it has to do with VC API, OIDC work, kevin has 16:36:53 talked a bit about evidence traceability. What about mobile/web integration, use cases that have that, and then accessibility -- huge oversight. 16:36:53 q+ 16:36:58 q+ to mention i18n 16:37:32 JoeAndrieu: Accessibility is a big gap, using VCs to make the lives of people with a11y lives better. We would like to get some use cases in about presenting VCs. 16:37:58 +1 to accessibility overlap, there are some really awesome accessibility features you can build by cleverly interpreting machine readable semantics. 16:37:59 ack TallTed 16:37:59 TallTed, you wanted to clarify meaning of "replace amend with reference" 16:38:17 TallTed: You said rplace amend with reference... fo documentation? amend is important. 16:38:27 s/rplace/replace/ 16:38:30 q+ 16:38:35 s/ fo / for / 16:38:44 JoeAndrieu: I did say replace, curious -- why is amend important? How do we conceptually amend a VC today? Handwave to say "we don't say this" -- we should discuss. 16:38:52 ack manu 16:38:53 manu, you wanted to mention i18n 16:39:07 how do you amend a VC without breaking a signature? feels like update/reissue are more accurate 16:39:07 manu: i18n - we have a full i18n solution in VCs but I don't think anyone's used it. 16:39:22 ... ?? has proposed an alternative solution that I think we're talking about later. 16:39:34 ack Orie 16:39:37 ... We have addressed i18n, but I don't think it has resulted in internationalized creds 16:40:19 q? 16:40:24 q+ 16:40:31 +1 to Orie's VC status list example 16:40:34 Orie: To comment on "amend", not interpreting it correctly, but one of the primary paces I've seen this applied, is revocation list block, you want a stable identifier for credential, but you are making changes to credential as things change status, maye revocation isn't right way to think of that, you can have credentials w multiple statuses, entry point has to be updated frequently to associated/related reference has been updated. Just clarifying. 16:40:36 ack JoeAndrieu 16:40:57 The spec says we refer to things by `id`. 16:40:57 s/ maye / maybe / 16:41:07 s/ w / with / 16:41:09 JoeAndrieu: hat has an interesting tie by back to how we refer to VCs. If a VC changes in a way a revocation list changes, VC doesn't have a way to be cognisant that they are te same thing -- then we could talk about that sort of update. 16:41:09 q+ 16:41:17 s/ hat has / that has / 16:41:18 q+ about canonical way to refer -- two ways 16:41:22 s/ te / the / 16:41:29 JoeAndrieu: If we use a hash, can't update. 16:41:35 q+ to about canonical way to refer -- two ways 16:42:07 +1 to stable identifiers for several version of a credential. 16:42:14 (the use case) 16:42:24 +1 Orie 16:42:37 there is a conversation on this topic in OpenID4VCI, raised by Tobias: https://bitbucket.org/openid/connect/issues/1563/managing-credentials-with-changing-claim 16:42:50 kdeangs1: There are use cases from GS1 that may need to use these references, there might need something at registry level... would be able to say VC has been replaced/amended. We might have use cases from others than GS1 that refer to this use case. If I change my name legally, there would be a replacement credential for identities. 16:42:54 ie how does the wallet know two credentials are the same type, just "updated" 16:42:58 ack manu 16:42:58 manu, you wanted to about canonical way to refer -- two ways 16:43:10 For the record we have this today related to "revocable" bills of lading / other supply chain oriented credentials. 16:43:29 q+ 16:43:42 manu: We have this concept of I want to point to a VC and use a crypto hash, that specific version, so we can detect any change, and there are other things about changing VCs 16:43:49 +1 to the separate immutable / content id use case. 16:44:08 ... We have at least 3 classes of use cases, one is covered. The one about the external one being changed is one we'll need to look at 16:44:09 ack YanZhang 16:44:22 cel[m] has joined #vcwg 16:44:47 +1 to update being necessary for a number of privacy preserving extensions to VCs. 16:45:13 YanZhang: Regarding updating VCs, long conversationw ith ZK SNARKS, in cryptography domain, snarks are propular. Essence of VCs generates action between different parties, always have timestamps, ZKSNARKS have simplest mechanism, but we might need something in time progress related to VCs, clear to be different between ZKSNARKs and other domains. 16:45:41 s/conversationw ith/conversation with/ 16:46:32 kdeangs1: Traceability - The Problem - GS1 are the "Barcode People". We manage barcodes worldwide, we have a large number of standards that speak to supply chain, it's about data, transactions, traceability, for us is more comprehensive than what most people think, poin of manufactur to when its received. 16:46:59 s/poin of manufactur/from point of manufacture/ 16:47:12 kdeangs1: What is traceability, about provenenannce, traceability is abou how it got here, what ingredience were used, when was it stored, who carried it, if it's produce -- was temperature maintained? 16:48:05 kdeangs1: from carrier to distributor to retailer to store, traceability can tell you everying along the wya. Bu discovering this data is difficult, large number of parties, fruit, grower aggregator distributor, prepared food product , traceability can go all the way back to ingredients farm. hard to know where data resides. 16:48:08 s/provenenannce/provenance/ 16:48:13 q+ 16:48:22 s/the wya/the way/ 16:48:22 kdeangs1: We can do 1 up 1 down to look one place up the chain or down the chain to understand one hop in the supply chain. 16:48:33 s/Bu /But / 16:48:46 kdeangs1: What if there were a discovery service that could respond to a broadcast request for traceability, who gets to ask the question? Consumer with product in hand? 16:49:08 kdeangs1: For example, if they have serial number, sparse number, some condience is someone asking has seen this item. 16:49:32 kdeangs1: what about trading partner, trading partners might get this information. Retailer, what if I want to ensure chain was maintained? 16:49:44 kdeangs1: Then there are regulators, they make the rules, they can see whatever they want. 16:49:44 q- 16:50:05 q+ to make a proposal 16:50:46 pchampin has joined #vcwg 16:50:54 kdeangs1: Next question, how is discovery service respond, even if they respond with something as simple as "yes I have data", that can reveal something with supply chain, that could compromise supply chain. if I know a distribution center has a useful product, no response timeout don't want to target supply chain center, want to avoid that. 16:51:05 SamSmith has joined #vcwg 16:51:13 Hello 16:51:30 kdeangs1: Once it's responded, whether it has data or not, how does it respond to query itself? Again, no resonse, filtered data, or no data -- all the ways discovery service can respond depending on who you are a how sensitive the data is. 16:51:45 s/a how/and how/ 16:52:23 present+ SamSmith 16:52:27 Another way of viewing traceablility is as a chain-of-custody of the data so one can proveance the data. 16:52:35 provenance 16:52:55 s/proveance/provenance/ 16:53:29 Supply chain manifests as they flow through customs are a common use case 16:53:33 kdeangs1: Where do we see VCs play a role, if I'm a manufacturer and have traceability data, who do I give it to, let's start with distributor, VC hat's issues, hey ar a distributor le them have the data. Retailer, if I'm giving out data as distributor, I can give data out. Distributor has relationshipi with retailer, manufactuer might do end run around distributor and sell directly to retailer. One of many use cases where you might not to publish lotts 16:53:33 of data. 16:54:07 s/lotts/lots/ 16:54:38 This is a prime reason ACDCs support chaining 16:54:42 kdeangs1: Supply Chain is a gold mine of VC use cases, FDA has regulations around KYC, pharmaceutical products should only be handled by authorized parties, to prove yourself to trading partner might require multiple credentials. Another VC showing authorization to handle certain classes of narcotics, then creditworthiness, another credential in GS1 ecosytem that identifies you as a trading partner. 16:54:50 phila: Our GS1 colleague Mark Harrison wrote a paper on End to End traceability using VCs https://gs1.github.io/EndToEndTraceability/GS1-WhitePaper-VerifiableCredentials-EPCIS-end-to-end-traceability.pdf 16:54:51 s/ le / let / 16:55:07 q? 16:55:38 q+ 16:55:49 q+ later 16:56:07 Vittorio: This is an interesting scenario, in a number of relationships that you express, your toekn between organizations vs. granted individuals, cardinality of relationships supplier vs. relationship between company X and Y, with Y can just give "this ser is part of my company". Rules of engagement is around federation. What are your thoughts on how VCs can improve on main scenario -- combinatorial exploion vs. org to org. 16:56:19 ack brentz 16:56:20 s/toekn/token/ 16:56:21 brentz, you wanted to make a proposal 16:56:22 kdeangs1: The answer is we don't know that we do, maybe we submit the use case and maybe VCs are not a viable solution 16:56:22 q+ 16:56:39 q+ to note that VCs remove the need for point to point integrations in many cases. 16:56:52 yi has joined #vcwg 16:56:52 q+ 16:57:54 VCs... distributing trust without having to distribute infrastructure 16:58:50 kdeangs1: We have been looking at these use cases and tech soutions weren't there at the time. In our evaluation of VCs, wha we really liked about them is disconnected nature of them, although in many use cases, you need online access for revocation checking and the like, th enature of VCs allows us to create self-assembling ecosystems and to work w/ other ecosystems to prove things in ways you can't do before without dictating a single model for 16:58:50 verification. The process for vaidating a trading partner, several different VC ecosysems, FDA certification, trading partner capabilities, four copletely separate VC ecosysems each with rules, verification and validation rules defined by their respective ecosysems that can be used to prove things about a potential trading partner more rapaidly than we could before. 16:58:57 q- 16:59:01 Another way of described this "disconneted" nature is an open loop authentication verification model. Where the verifier does not need to directly contact the issuer but can use a verifiable data structure. This enables open loop authorization models which is the primary different from access control moelds 16:59:05 PROPOSAL: We will update the Verifiable Credentials Use Cases, with Joe Andrieu and Kevin Dean as editors. 16:59:05 brentz: want to run a proposal. 16:59:11 +1 16:59:12 +1 16:59:12 +1 16:59:13 +1 16:59:14 +1 16:59:15 s/disconneted/disconnected/ 16:59:16 manu: +1 16:59:17 q- 16:59:17 +1 16:59:17 +1 16:59:19 +! 16:59:21 +1 16:59:24 +1 16:59:30 +1 16:59:39 +1 16:59:42 +1 16:59:54 RESOLVED: We will update the Verifiable Credentials Use Cases, with Joe Andrieu and Kevin Dean as editors. 17:00:00 ack brentz 17:00:36 ack YanZhang 17:00:36 JoeAndrieu: We welcome additional collaborators, if you have suggestions, lionel, reach out to us if you have use cases you want to have covered. 17:00:40 I want to mention about one of the use cases we analyzed at Trusted Web is supply-chain traceability related to the chemical composition of products and their exchanges. In certain cases, the participant needs privacy (trade secret) 17:00:46 Begin of break for 15 minutes. 17:00:48 present- 17:00:50 rrsagent, draft minutes 17:00:50 I have made the request to generate https://www.w3.org/2022/09/15-vcwg-minutes.html manu 17:02:12 present+ 17:04:06 phila_ has joined #vcwg 17:09:34 nms01 has joined #vcwg 17:17:09 yi has joined #vcwg 17:17:53 oliver has joined #vcwg 17:17:57 present+ oliver_terbu 17:18:02 mkhraisha has joined #vcwg 17:18:05 scribe+ 17:18:11 Geun-Hyung_Kim has joined #vcwg 17:18:20 selfissued has joined #vcwg 17:18:38 decentralgabe has joined #vcwg 17:18:47 present+ 17:18:54 kristina: trying to be careful and considerate as possible with my words, In VC datamodel v1 we have a data model, a serialization and proof sections, i.e. how do you sign those credentials 17:19:14 present+ 17:19:31 ...: in practice whats happening is there are implementations that are doing what some are calling JSON or Incomplete JSON-LD serialization, with the biggest difference is @context @vocab is used 17:19:42 dwaite has joined #vcwg 17:19:46 present+ 17:19:53 ...: either you have a valid @context or you do not, in which case you use out of band mechanisms to understand the claims 17:20:10 dezell has joined #vcwg 17:20:18 ...: in 1.1 all these components were in 1 document. The serialization might not have been explicit but it is there 17:20:19 present+ 17:20:44 Jay has joined #vcwg 17:20:51 disagree with the framing of this... does not represent consensus on v2 (wrt the data model / serialization side)... the securing side seems accurage. 17:21:03 ...: in 2.0 we are separating into different documents: Core Data model document, 2 Security Documents: JWT/Data Integrity. Under Data Integrity theres a number of other docs such as JWS2020 17:21:07 s/accurage/accurate/ 17:21:53 ...: what i really want to bring up is the SD-JWT use case, a json format that allows selective disclosure without advance crypto, theres JWP, CBOR, ACDC, and others. Where do these sit? 17:22:02 This slide mixes security and serialization incorrectly imo. 17:22:52 ...: This slide does not say we have to work on ALL of them, the question is do we want to have an extensibility point to open the path to these different represenations, or do we want to say ONLY JSON-LD is the appropriate serialization. 17:22:54 Fazio has joined #vcwg 17:22:55 JoeAndrieu has joined #vcwg 17:23:17 sgoto has joined #vcwg 17:23:25 s/advance/advanced/ 17:23:39 ...: Can we get on the same page? do we want extensibility point to find out which document is responsible for defining those. if we want to open up the door for SD-JWT is that under data model or under an SD-JWT document? 17:23:41 Did we not already decide that serialization was an open extensibility point? by means of the abstract data model? 17:23:54 present+ 17:23:56 ...: this is one of the framing that we have been discussing as chairs. 17:23:57 q+ 17:24:08 ack TallTed 17:24:25 q+ 17:24:31 ack manu 17:24:34 TallTed: I thought we already decided serialization is an open extensibility point, by virtue of the open data model that all serializations have to go to? 17:25:03 manu: We have not done that yet, we have done it, in the DID WG. There were many reactions, and many, including myself, have concluded that was a mistake. 17:25:13 My slides also address this... but there are parts of the framing Kristina presented which I do agree with. 17:25:19 ...: Question 1: Do we want to represent VCs in a variety of different syntaxes? I think yes. 17:25:43 ...: Possible second question: Do we want ot create a new abstract data model for VCs? big -1 on that. 17:26:27 ...: we do have a deployment demonstration right now, you take a VC, secure it as a JWT, and that seems to be working that way. in Data integrity theres examples of translating it to CBOR using CBOR-LD so that is possible 17:26:30 so instead of forcing translation thru an abstract data model, we force translation thru a physical data model? 17:26:49 s/ ot / to / 17:26:53 whether a VC is translated at one layer or another (e.g. for transmission or securing) doesn't mean that there shouldn't be one single representation "around" those things. 17:27:08 q+ 17:27:17 ...: the question really is: when do we need to do the transformation? we could look at the data integrity spec and the transformation part there, fundamentally, talking about a serialization in the core data model is probably the wrong layer. 17:27:27 ...: I suggest we push it out to security layer. 17:27:30 ack Orie 17:28:23 Orie: I am not in love with the grouping between serializations and the data model piece, but i agree with the intentions. I have my own reinterpretation of these components. I think there are serious flaw sin how we defined proof types in 1.1, my primary mission is fixing those flaws while preserving the data model features in 1.1 17:28:43 s/flaw sin/flaws in/ 17:28:54 Aisp has joined #vcwg 17:29:22 q+ 17:29:37 ...: what i mean is data model of 1.1 is valuable in its current form, and I would like to tap that value consistently for the two proof formats that were defined already in much the same way. This ties directly to the serialization questions being tied here. There is a risk of opening up additional points of optionality while addressing the abundance of optionality in security we have. Im concerned about tackling that prior to closing the is[CUT] 17:30:29 sebastianelfors has joined #vcwg 17:30:41 ...: like manu mentioned for JSON-LD to CBOR-LD theres a path, but that may not be the only binary path people are itnerested in, i do not believe it is a wise choice to start tackling this sserialization complexity now, its a question of prioritization. I am worried about adding too much scope. 17:30:53 q+ to note that JSON section in current spec is problematic. 17:30:58 ...: I think we can make improvements on the spec from 1.1 to 1.2 that are valuable before we tackle the harder bits 17:31:01 ack manu 17:31:01 manu, you wanted to note that JSON section in current spec is problematic. 17:31:16 s/sserialization/serialization/ 17:31:28 s/itnerested/interested/ 17:31:32 second most useless 17:31:40 manu: i will note that in the 1.0 and 1.1 we tried really hard that a full blown JSON-LD processor was not really necessary, we added a JSON section to the spec, which if i remember correctly Jritcher said its the most useless section. 17:31:49 ...: second most useless* 17:31:59 q+ to say the first if there's interest after 17:32:02 Karen has joined #vcwg 17:32:04 https://www.w3.org/TR/vc-data-model/#json 17:32:08 sb has joined #vcwg 17:32:09 ...: I think we need to look at that section to see if it is buying us anything. 17:32:18 ack justin_r 17:32:18 justin_r, you wanted to say the first if there's interest after 17:32:35 Justin: The most useless is extensions may allow, prohibit etc, this is a close second. 17:33:01 Kristina: If no other comments moving forward to Orie's Presentation 17:33:19 Orie: Hope my snarky attitude translates remotely. 17:34:09 Orie: extending where kristina left off, what are we doing to define the Data model in v1.1 and what are we doing to secure it, and at the end I will drift into a series of hand wavy proposals, trying to intro topics so we can talk about in WG calls. 17:34:17 mccown has joined #vcwg 17:34:29 ...: they will take a while, i suggest we get the lay of the land then begin solutioning. 17:34:46 i/scribe+/Topic: Serializations and the Core Data Model/ 17:35:00 ...: On the right hand side, you will see some version of GPT-3 of a true scotsman on an envelope. 17:35:18 ...: this speaks to the core data model and the branding problem associated with it! I hope the directness doesnt come in any way offensive 17:35:24 [slide #42 onwards] 17:35:25 https://github.com/w3c/verifiable-credentials/pull/42 : Updating the WG Web site 17:35:56 ...: we all have software we are relying on, I see a lot of topics that people are excited about that are somewhat unique to VCs and W3Cs, it seems unique to our community. 17:36:26 ...: one of them is semantics and graph theory, and the question ends up how many of this is related to browsers etc? 17:36:52 ...: This elaborates a bit further, what is the point of VCs? How do they reflect w3c values? why not do this work at IETF ISO DIF? 17:37:12 ...: what is the relationship between w3c values and the communities we're a part of? is semantic web dead? 17:37:38 ...: Ive seen privacy and accessibility considerations as a big consideration that is unique to W3C. 17:38:30 ...: framing this as a core data model, because it is a huge part of the core data model. What is the relationship between semantic web and v1.1 credentials at w3c. 17:38:51 ...: one of the questions is: What are we defining? whats to define here? its a question of Decentralization. 17:39:19 ...: how can issuer/holder/verifier agree without a central registry? what is the value of these claims? whats diff about claims in this specification and other specs that represent claims? 17:40:34 ...: Crediting mike jones for this, and this is something i have now come to believe: A new specification has to improve. When is innovation worth the switching cost? we have JSON awe have JOSE, we have CBOR and COSE. Why are we here? 17:40:51 s/awe/and/ 17:41:08 ...: why are we talking about another way to sign and secure things? why do we need another standard/WG? there answer must be we are doing something that is worth it. I believe we are, but we are disagreeing on what it is. 17:41:12 q+ 17:41:35 ack ivan 17:42:20 Ivan: non-w3c hat: I don't want to start the discussion of pros/cons of semantic web, or what semantic means. I prefer to use the term Linked Data, which has different connotations. 17:43:09 ...: for me the value of having the VCs being done using Linked Data standard, is that LD gives you pieces of graphs coming from X or Y, and by combining them I get something greater. 17:44:06 q+ 17:44:21 ...: these days it is not fashionable to say that, but if you look at knowledge graphs do, some people have to acknowledge that it came from semantic web. The question is, are we creating pieces of knowledge that is creating new value by adding it to the knowledge graph? I don't have the answer, but the use-case doc should probably have the use case where the link effect is relevant. 17:44:43 ...: I want to push back on using the word "semantic", I do not think we are interested in that. 17:44:55 ack SamSmith 17:46:13 SamSmith: I think there has been a very valuable contribution from the semantic web work, but the idea of knowledge graphs, and semantic inferencing goes back much further. There have been multiple branches of work in the field of automated reasoning that have been parallel to that for some time. it is entirely appropriate to discuss other models of knowledge graphs in the context of moving forward and in the context of Orie's presentation of[CUT] 17:46:14 q+ to talk about disambiguation more than graphs 17:46:54 ...: security, we should be able to talk without knives out. from my perspective, many other knowledge graphs include uncertainty as a first level citizen, which depends on directed edge knowledge graphs with weights. 17:47:36 ...: the work being done at w3c has precluded those types of knowledge graphs, and we should be open to them. we can do some things from security perspective if we take a different approach, and i'll mention it when it alk about ACDC 17:47:38 ack JoeAndrieu 17:47:38 JoeAndrieu, you wanted to talk about disambiguation more than graphs 17:47:47 s/ alk / talk / 17:48:11 s/ when it/ when I/ 17:48:35 q+ nadalin 17:48:37 Joe: I think the focus on graphs is a bit of a distraction. graphs are one way to represent data, the challenges of adding an adverb to an RDF triple. my point is there are debates about having a coherent graph about everything in the planet even makes sense. What does have value is the ability to disambiguate. 17:48:55 ...: that ability is far more valuable to get the data from multiple different sources. 17:48:58 ack nadalin 17:49:35 nadalin: I somewhat agree with Orie here. I believe that the core data model is the problem in that it tries to unify things. we already have JSON/CBOR/COSE, we should let them go as they are and not try to fit them in this core data model. 17:50:03 ...: they have their own data model, defined at IETF. We should not have to tie them to the VC model. 17:51:10 Orie: JSON CBOR, JSON LD, there are many data models that have value and adoption. 17:51:33 My point about using knowledge graph models that support uncertainty speaks directly to the ambiguity problem. Ambiguity is a quantifiable type of uncertainty. The hard problem of polysemy is not solvable without uncertainty measures on meaning drift between terminology corpus. 17:52:21 ...: Everyone has bias, I'm very passionate about many things sam mentioned, I get really excited about that work, sorry if semantic web is a triggering term. I believe in the original vision. I will continue to support the value of linkages between data, concepts and machine processing 17:52:44 ...: I want the core data model to provide a bridge to link the semantic web of the past to the semantic web of the future. 17:53:09 Reasoning with uncertainty is more robust than reasoning with certainty. Links that do not represent the uncertainty in the link limit the robustness of the inferences so traced. 17:53:25 ...: I am very much in favour of these graph structures, I love these things, in particular applying these technologies to supply chains, traceability etc. 17:53:27 +1 @mkraisha 17:53:38 Consider, "Webs of Semantics" or "Semantic Webs" ("Webs" intentionally plural!) instead of "*the* Semantic Web" ("One Web to Rule Them All, and With the Specifications, Blind Them!"). Main idea being, context lenses are important. 17:53:38 ...: You should hold me accountable to my bias. 17:54:57 ...: The core data model has many non-normative statements. This is the transition to talk about securing it. We should be able to clearly see what are my requirements? what do i have to understand? There is lots of value of the informative section, but I think there are so many of them that the value of the core data model is in jeopardy because of all the extranuous information. 17:54:57 if we don't we should probably have a placeholder issue to revisit non-normative sections in the data model document.. 17:55:57 ...: This is essentially Kristina's slide with my own bias. I think the core data model is RDF. The current v1 and 1.1, focus on a single serialization using JSON-LD, secured via either VC-JWT( which operates on JSON) and Data Integrity( which operates on JSON-LD) 17:56:06 RDF does not support weighted edges this is why I cannot use it. 17:56:26 ...: I understand there will be disagreements on the framing of previous slide. lets focus on that before we focus on securing it. 17:56:44 ...: there are parts that already start to create real trouble for us as a group: a few ideas are: 17:57:00 SamSmith, maybe RDF-star could support weighted edges? 17:58:03 ...: The idea of the signature/proof. These issuer/proof/created properties are not disambiguated from the core data model. The core data model is about defining the terms in a non-ambiguous model, some of these other properties are about the securing part and not so much the data model part. 17:58:15 +1 for clear layers 17:58:35 ...: I think clean layers are what we need, the blurry edges create lots of risk the VC-JWT in particular im worried about that edge. 17:58:44 +1 for clear layers 17:58:48 +1 I agree that in the slides these components are clearly separated, but in v1.1 they are not that clearly separately defined 17:58:57 ...: Second blurred line area: Content Type pieces. 17:59:35 ...: for VCs under current vc 1.1 model, what is the content type? different per signature type? I think we can use the patterns outlined in IETF and elsewhere to define a series of normative statements together. 18:00:33 ...: there are also issues with schema languages, in the current spec we have seen people use JSON-Schema, and JSON-LD, and there are problems because JSON-LD and JSON-Schema are not exactly the same thing. 18:00:36 q+ 18:01:16 ...: The issue is this can get into your way if you try to get into content-type negotiation. This is something that we really struggled with in the did-core work, because resolvers in DID-CORE have to have an accept header, which affects interop quite a bit. 18:01:18 tzviya has joined #vcwg 18:01:20 SamSmith_ has joined #vcwg 18:01:27 ...: this is an area we can easily run into issues that snowball. 18:01:38 ack ivan 18:02:22 q+ 18:02:34 q+ to note that we might want to focus on what people are implementing and let that drive the work. 18:02:44 Ivan: I want to avoid mixups, JSON Schema is great, its about defining constraints on the JSON structure. JSON LD and the context has nothing to do with that. To combine these two things in the same sentence invites confusion. its a mapping of JSON to RDF mapping, but its only a mapping and does not constraint and the vocab that is used is not about constraint 18:03:03 s/JSON LD/JSON-LD/ 18:03:25 ack decentralgabe 18:03:30 Orie: Super strongly agreed, if you think about semantics of JSON Schema properties, we already have these things in the spec and there is necessary cleanup and issues with overlap. 18:03:41 q+ 18:03:42 If we have clear layers we can use JSON Schema for the security layer that wraps a higher layer that includes JSON-LD. The JSON-LD is opaque to the lower layer with JSON Schema. 18:04:02 decentralgabe: JSONLD has been used out of necessity, and JSON Schema can be used instead, and wasn't because it wasn't defined properly. 18:04:14 q+ 18:04:19 s/JSONLD/JSON-LD/ 18:04:49 Orie: I would add one other note, I have seen people use JSON schema to create vocabs before, and I think Manu commented on this, but this is a thing people are doing it, the UN does this, others do similar work, mixing it together, might have confused people. We have to be careful here. 18:04:50 ack manu 18:04:50 manu, you wanted to note that we might want to focus on what people are implementing and let that drive the work. 18:05:05 q- 18:05:38 Manu: I'm having a hard time concrete decisions we're trying to make, this feels like a meta conversation we've been having for a while. I want to focus on implementations and actual deployments. I think its important to reflect, but fundamentally we have many implementers and we should focus on what they are doing. 18:05:53 ...: I want to understand where the conversation is going 18:06:14 ack TallTed 18:06:15 Orie: I'm not here to tell the WG what to do, im here to make everyone feel where we are. 18:06:58 Ted: I'm concerned that, these slides are doing more blurring than already exists. In a group where we're trying to increase clarity, what i'm seeing, both Orie's and Kristina's betrays a misunderstanding of the things on the slides. 18:07:25 ...: if we cannot understand the tools we are trying to work with we cannot clarify it for anyone else. For example there are 6 medai types one of which is legal i believe. 18:07:30 s/medai/media/ 18:07:32 ...: that makes it impossible to discuss 18:08:27 ...: i want to put boxes on misunderstandings based on prior output, because it helps us clarify it in the spec. That can be done in the spec either as a note or in the main spec, that doesn't really matter to me. Its difficult not to be upset at these media types because it violates how they are constructed. 18:09:06 Orie: Which core terms do we see in the core format? Link on left is the term in our spec, link on right is my best effort to map to VC-JWT language that i think is relevant. 18:09:41 ...: the point is we will go through this process potentially whenever we add a new security format, so we ought not to do this if at all possible. It could be that we must do it if we do a lot of securing in the core data format. 18:09:53 ...: we have to do this in the CORE DID model because of the translations we have to do. 18:10:27 ...: these mappings are expensive and complicated and the main point here is: who wants an unbounded number of mappings? we can have an infinite number of mappings that can become legal? 18:10:41 ...: this was a core point of concern from the DID objectors. 18:11:02 ...: please read teh private claim names in the associated IETF specs, and asking what is the relationship between them and our work. 18:11:18 private claim names: https://www.rfc-editor.org/rfc/rfc7519.html#section-4.3 18:11:22 (I think..) 18:11:27 ...: this is one interpretation of taking the did core route. which should align with kristina's slide. 18:11:49 s/ teh / the / 18:11:59 ...: we'll map RDF to infra and infra to CBOR and JSON and RDF will map to JSON-LD, and we get security that depends on the serialization we like. 18:12:08 q+ 18:12:37 q+ 18:12:41 q+ 18:12:53 ...: want to hear from folks who think infra went really well or not so well 18:13:05 ack justin_r 18:13:15 q+ to note experience using infra for core data model in DIDs. 18:13:26 justin_r: i'm not here to defend the use of infra specifically, i will say though that the concept of what we did in the did:core work is a good idea but it ended poorly 18:14:00 ...: one of the things that is really important here is that everything in and out of a serialization should be really tight and defined, and we had that, but a lot of the text got removed , over my protests. 18:14:54 ...: in my view that is where we lost lots of value. losing that tight coupling. In the json text says a "boolean must be a boolean" that is absurd, we can do this very stricly, the http header spec gives us a very good example of a very good serialization and very good parsing language. 18:15:24 ...: it does a really good job of saying "this is a boolean, this is what it looks like in this serialization" leaving open the door for other serializations. 18:16:01 ...: that was at the core of my argument for the representations language for DIDs VCs and all of this, lets not repeat the mistake of loose coupling that was done in did core, i DO see the value of having the two layers of existence 18:16:22 ack SamSmith_ 18:16:35 ...: if what we're talking about is a data model and not just a json-ld schema we should be able to go to multiple different serializations 18:16:39 mprorock has joined #vcwg 18:17:17 sam: +1 to strictness of serializations, very important to round-trip between different serialization, but where we have creep where some components are used to tunnel from one serialization to another that is problematic. 18:17:57 I think members of the industry have adopted tooling that is core to their business, if we cannot acomodate the major tooling sets, to get something that has interop across the industry we will run into the serialization wars. 18:18:24 s/acomodate/accomodate/ 18:18:29 ...: notably we do not have XML. We need to have enough flexibility to have serialization to reflect the major tooling stacks in the industry 18:19:11 ...: almost all of the fringe serializations have well defined round trip paths to the major ones, which means we only need to define the ones that are important and address those. 18:19:14 +1 the data model needs to go strictly in and out of these major stacks 18:19:17 ack manu 18:19:17 manu, you wanted to note experience using infra for core data model in DIDs. 18:19:21 q? 18:19:23 new serializations have to follow the same path 18:19:48 q+ to say abstract data model is a failure, in part because it is innately untestable. Only serializations can be tested. 18:20:03 manu: weren't you the one who campaigned for us to use infra? 18:20:24 q+ to comment that did core data model is trivial compared to vcdm 18:20:41 manu: to speak to abstract data model and did core spec. I continue to believe it is a massive mistake to do that, having been the one who had to take the JSON-LD rdf model, we had to invent a new data model in infra, we had to rewrite everything. and we were promised that we will have all these serializations, at the end of the day there was a semi attempt at CBOR, we ended up with two serializations JSON and JSON-LD with the only difference[CUT] 18:21:31 ...: @context and just about everyone ended up adding it. We spent months working on it, and to this day we do not have anything to show for it other than JSON and JSON-LD. Theoretically I agree, but in reality we have not seen any of that in the past. 18:21:55 q? 18:22:10 ...: very concerned of committing the WG to months of work. if you look at the chart up here what is the extensibility model for JSON or CBOR? is it @context? is there a new registry we need to create? 18:22:26 ...: that is my concern because it backfired on us in did core and fairly certain it will backfire here. 18:22:29 q? 18:22:31 ack JoeAndrieu 18:22:31 JoeAndrieu, you wanted to say abstract data model is a failure, in part because it is innately untestable. Only serializations can be tested. 18:22:32 q+ 18:23:05 Joe: I want to endorfe everything manu just said, i don't understand why the abstract data model was even considered. 18:23:08 phila_ has joined #vcwg 18:23:13 e/endorfe/endorse/ 18:23:29 s|e/endorfe/endorse/|| 18:23:33 s/endorfe/endorse/ 18:23:38 ...: the abstract data model is innately untestable, all we can test is serializations. 18:23:44 ack Orie 18:23:44 Orie, you wanted to comment that did core data model is trivial compared to vcdm 18:24:19 q+ to note that we need to try and reduce optionality, not increase it. 18:24:40 Orie: in general i agree with manu's comments about registering new representations of the data model. Its important to note that the two data models are pretty different. One is an open world type problem, while the other is more constrained. 18:25:53 ...: The abstract data model might work better for how do we return a specific key, its not just about how do we make a representation, its also about the cost on the tooling to manage all the representations. how do I get the representation i want from the resolver, how do i get the representation i want from the driver? this explodes when we have an infinite number of serializations to the data model. 18:26:03 +1 Orie 18:26:04 ...: I echo the words to the group, but i think its very different from did core. 18:26:07 ack selfissued 18:26:09 +1 orie 18:26:10 +1 Orie 18:26:13 +1 18:26:46 +1 to Orie 18:27:10 selfissued: I'll echo the point that only concrete serializations are testable. ultimately real software uses concrete serializations, we have to get these right and interop. I agree in the abstract with we don't want to support extensibility model, JSON-LD and JSON has one. 18:27:35 q+ to note "adding new fields" is a local extensibility model, not a global one -- and requires registries. 18:28:06 ...: atleast for those two things and also for CBOR that is true. a little later this afternoon, we'll talk about registries, and how they help define extensions. I agree we want to keep things simple, but there will be multiple representations, and we want to make them first class. 18:28:19 rrsagent, draft minutes 18:28:19 I have made the request to generate https://www.w3.org/2022/09/15-vcwg-minutes.html ivan 18:28:34 ...: if they are informed by a common perscription of what the normal fields are that should appear in the representations, but that is not testable. 18:28:37 so a model ... for the data ... that is abstracted .... đŸ¤” 18:28:42 ack manu 18:28:42 manu, you wanted to note that we need to try and reduce optionality, not increase it. and to note "adding new fields" is a local extensibility model, not a global one -- and 18:28:45 ... requires registries. 18:29:17 +1 reduce optionality 18:29:31 Manu: we need to reduce optionality. What we've seen is massively explode optionality. that is difficult for a new ecosystem to grapple with. the idea that we will have all these different types is a dangerous one. NxN matrix for interop is all that much more difficult. 18:29:34 I am not opposed to going JSON-LD only 18:30:12 Well.. speaking of implementations.. And pain points.. chairs hat completely off. knowledge graphs are great, but, in some use-case for VCs (ie verifying the user in external identity use case) linked data has been a little overkill... at least for now. 18:30:21 +1 to reduced optionality (especially at the "envelope" layer, that of the credential, without constraining the claims) 18:30:22 q+ 18:30:29 +1 Kristina 18:30:32 ...: we should optimize for reducing optionality. JSON has a local extensibility model, and it often requires you to have a spec that is published, and it requires you to have a centralized registry around. I'll note that alot of orgs that are using this work are focused on decentralization. forms of centralization are problematic 18:31:04 ack selfissued 18:31:10 q+ 18:31:28 ...: we have something that is working for us. I think anyone who is arguing for opening up optionality needs to defend how that is going to lead to a bigger tent. 18:32:04 selfissued: will respond to your comment about registries and centralization, this WG is a centralization point. we are the authority on defining what the VC is, its not evil its just practical. 18:32:23 q+ to challenge the presumed for a registry in a world where "anyone can say anything" 18:32:24 ...: likewise if you want global interop, you need to have it written down, thats just practical engineering. 18:33:03 Orie: Where do we feel like we should open the aperture and where do we feel like we shouldn't? 18:33:09 q 18:33:24 ...: this is my proposal, I think we should increase the aperture in the securing side, I think we should not increase it in the data model side. 18:33:25 present+ 18:33:29 dezell has joined #vcwg 18:33:39 q+ 18:34:05 present+ 18:34:27 ...: we have problems in the current document and draft, and would like to fix them prior to creating new ones. I think the group is asking for alternatives at the core data model layer, and I think that deserves its own charter, and we can really help the industry without blowing up this charter. I think we can help the industry by increasing the aperture on the security side. 18:34:42 Property Graphs are a superset of RDF graphs. It seems to me that exapnding the core Data Model to include property graphs solves the problem. Its the right amount of flexibility and if forward looking 18:35:00 ...: Some of these have come up during our WG charter process, for example dizzy/anoncreds/ACDC 18:35:33 ...: I recognize this a recommendation and is in contradiction to positions folks have taken on the cal. I think this is the safest path forward to protect the value of the existing standard 18:35:43 ...: and protect security formats and focus on improving them 18:35:46 s/the cal./the call./ 18:35:50 +1 to what orie is saying 18:36:32 ...: I think we should open up the lower box, without the top one, without endangering the primary mission. 18:36:59 +1 to Orie, leave alone / clean up data model (very small changes), focus elsewhere for larger changes 18:37:11 ...: if i can't secure it properly then the value of semantic VCs is destroyed. we can get to some of these mission objectives in another WG charter where we are building on top of a strong security foundation. 18:37:17 +1 orie 18:38:04 ...: I'm excited about VC-JWP and VC-SD-JWT, and don't agree with where kristina put them, I think if people are distracted fighting over the core data model, we will not be able to do these security well. 18:38:08 q 18:38:20 ...: these are open PRs for several repos i would like people to review. 18:38:41 brent: we have 30 mins and a concrete proposal. 18:39:09 kristina: I think the proposal is the data model is RDF JSONLD and minimal changes will occur there, with most of our focus to be on securing the model. 18:39:15 q+ to note that we want a constrained set of JSON-LD, not to open up to full blown RDF. 18:39:27 q+ 18:39:46 ack SamSmith_ 18:40:20 dwaite has joined #vcwg 18:40:20 Thats ok Sam, I did that based on Kristina's slides last night :) 18:40:25 sam: Im going to talk about ACDC, and I'm guilty of often changing my slides dynamically and will take the liberty of talking specifically about ACDC extensibility model. which should answer manu's challenge 18:40:33 q+ 18:41:00 ...: RDF is a subset of a property graph, if this proposal said this will do a property graph. 18:41:06 so no enabling additional "serializations" but that extensibility handled in the securing documents (not happy with the wording but one way to put it..) 18:41:26 +1 Ivan !!!! 18:41:31 +1 to Ivan 18:41:42 ack ivan 18:41:53 There are beginning of standardization on the graph query languages, such as Cypher though... 18:42:15 Ivan: on the property graph thing, bad news: AFAIK property graphs are still a moving target, but it is not a standard we can rely on. The good news: as of today, there was the first WG call for RDF star, which is doing extensions to RDF to include property graph concepts, it is work happening, that may cause race condition of references 18:42:20 +1 -- sounds like we can get support for what Sam wants in due time. 18:42:37 whilst still using standards today 18:42:38 but both LPGs and their query languages might be tough to cite as normative dependencies for us right now... at least in my current understanding of them. 18:42:47 ...: the work is ongoing, we will not need to leave the RDF model if we need to get property graph features, without leaving and using new serializations. 18:42:48 q+ 18:42:54 ack JoeAndrieu 18:42:54 JoeAndrieu, you wanted to challenge the presumed for a registry in a world where "anyone can say anything" 18:44:04 +1 to contextual vocabularies 18:44:05 ack mprorock 18:44:13 Joe: I like Orie's basic proposal, I like that it explicitly uses RDF. I want to talk about the separation between the envelope and the payload of the VC, we should lock down the envelope, but we should keep the payload open, and allow people to say anything that isn't tied to a registry. as long as we in a community can agree on a payload then we should use the vocabulary. 18:44:37 s/RDF star/RDF-star/ 18:44:39 q+ to separation of envelope and payload 18:45:38 mprorock: I cannot echo enough support for lets get the data model trimmed a tiny bit, but focus it on one concrete testable thing. We need this to be flexible to not need to know every keypair in the credential, the nature of VCs is that they are Verifiable, which implies the security model must be rock solid, by doing what Orie is suggesting here, with refinements to the language, it allows us to set us up for RDF-Star/CBOR-LD 18:45:53 ... without taking away the focus on security aspects that we must ensure are fully addressed. 18:45:53 ack manu 18:45:53 manu, you wanted to note that we want a constrained set of JSON-LD, not to open up to full blown RDF. 18:46:20 Aisp has joined #vcwg 18:46:42 Manu: would like to spend some time talking against going full blown RDF, i agree with the gist of what Orie is saying, we tried really hard to strike the right balance by not focusing entirely on RDF, I think it would be a mistake to take that away. 18:46:47 -> RDF-star WG charter https://www.w3.org/2022/08/rdf-star-wg-charter/ 18:47:13 +1 Manu - I think setting ourselves down a testable path, without requiring hard overheads for payloads 18:47:16 +1 to using a "profile" of JSON-LD to reduce optionality and make things simpler. 18:47:19 +1 to JSON compatible 18:47:36 +1 to json-compatible JSON-LD 18:47:36 +1 manu 18:47:45 ...: we focused on making sure you can use JSON compatible JSON-LD, which does not imply you can do any JSON, but you can make sure it can be translated easily to JSON-LD, i think going further than that by saying you need JSON-LD processor is too much. We want people to take JSON that is JSON-LD and put it in a doc database all without using a JSON-LD processor. 18:48:05 -1 because if we are claiming JSON-LD is the extensibility model then we can't pretend it's not JSON-LD 18:48:18 my favorite way to secure JSON-LD, is using JOSE / COSE.... specifically using JWS / CWS. 18:48:20 justin_r: we should not pretend it's not JSON-LD ... 18:48:24 ...: when you put RDF in there you end up attracting the wrong sorts of people into the group, and i think we have done a good job walking a fine line. I think the shape is right, but want to make sure we don't lose the balance isnt lost 18:48:33 we should say it's JSON-LD ... but a specific profile of that that is particularly JSON friendly. 18:48:33 q? 18:48:35 dlongley: I'm fine with that tbh, but then we shouldn't claim it's a "data model" 18:48:37 ack selfissued 18:48:53 justin_r: yes, it's an RDF data model with a constrained JSON-LD serialization 18:48:56 +1 manu 18:49:02 +1 manu 18:49:14 selfissued: I often agree with Orie, but i disagree here. In practice as Kristina pointed out, lots of people have built VC implementations that don't use context or LD correctly, many devs took a stab at it and got it wrong. 18:49:45 For the record, GitHub signs commits incorrect with respect to PGP.... that doesn't mean we say thats ok by changing the OpenPGP spec. 18:49:47 ...: in some ways i agree with what manu said, if we can make it easy for devs to just use JSON in a way that, with a defined serialization with clear properties, will do the dev world a world of good. 18:50:01 ...: trying to require RDF, while an attempt to unify things will end up dividing people 18:50:04 ack SamSmith_ 18:50:09 q? 18:50:10 q+ to "don't use @context correctly" means "we have a non-conformant implementation". 18:50:12 q+ to ask if we are clarifying to a minimum of one context for the root VC envelope 18:50:53 sam: I want to respond to Ivan's comment, property graphs are admittedly a later development that has been around since the 70s/80s, whether you call that a property graph or an ISO standard, that is not an abstract data model. 18:51:13 q+ 18:51:22 ...but you need a standard serialization for it that is popular and easy enough to use 18:51:52 q? 18:52:04 ...: the model has been around forever and theres tons of papers about how you build graphs with edges. I don't want to preclude anyone to use RDF or JSON-LD, i don't want to be precluded from directed weighted graphs, we should be allowed to be able to put weights on the edges to enable machine learning. 18:52:15 ack dwaite 18:52:15 dwaite, you wanted to separation of envelope and payload 18:52:16 ...: why are we constraining this, other than considerations to tooling? 18:52:31 q+ to talk about JSON-only approach, edge weighting etc 18:52:36 If people can't get RDF/JSON-LD correctly... whats the chance they do LPGs (a super set) correctly? 18:52:40 q- phila_ 18:53:32 I think David is agreeing with me that we need to fix VC-JWT : ) 18:53:45 dwaite: Many things defined in the data model, especially how to represent it as a JWT, you will see lots of overlap between the envelope and the payload. That is one of the things people get wrong. There are mappings of values to JWTs that are not part of the data model. where is the line drawn here? 18:53:46 @ORIE LPG are easier to get right than triples 18:53:49 ack manu 18:53:49 manu, you wanted to "don't use @context correctly" means "we have a non-conformant implementation". 18:54:12 SamSmith, show me a standard for them that better defined that RDF. 18:54:35 s/ that / that's / 18:54:37 I'm a huge fan of Neo4J / LPGs / Cypher btw, 18:54:40 +q 18:54:41 DavidC has joined #vcwg 18:54:43 Manu: wanted ot speak to the comment about devs today that are not using context correctly, those are non-conformant VCs, there is a danger if we open up the aperture to allow semantically ambiguous VCs to be defined that is a problem, we need to do a better test suite that will fail those VCs. 18:54:43 +1 dlongley 18:54:48 present+ 18:54:51 s/ ot / to / 18:54:54 q+ 18:55:06 ...: we need to stop saying those things are part of the spec, they will fail a linter, and will continue to fail a linter, we need a hard line on what is and isn't a VC. 18:55:06 +1 to stoping calling everything a VC. 18:55:08 ack mprorock 18:55:08 mprorock, you wanted to ask if we are clarifying to a minimum of one context for the root VC envelope 18:55:10 +1 to Orie 18:56:22 q+ to say the developer challenge with JSON-LD is more about DEFINING good data model. It's easy to model with a JSON mind-set and get the underlying RDF wrong. But that problem is inescapable. It is in fact, the right obstacle. 18:56:24 mprorock: I do want to comment on the ML side of things, i spent lots of time on ML, the thing that is important there, is that it is too early to say, why do we want to standardize edges? the biggest advancements have been about auto encoders and semantic encoding, these are cool cutting edge thing, that isn't anywhere near ready for standardization. 18:56:40 q+ nadalin 18:56:56 ack phila 18:56:56 phila, you wanted to talk about JSON-only approach, edge weighting etc 18:57:00 ...: we will close paths of if we do it now. We should look at adding weights into edges, it just doesn't necessarily belong here. We should stop making mistakes on it, stop developers making mistakes and focuisng on security side of it. 18:57:58 ack dwaite 18:57:59 phil: entirely happy to have something that is entirely in JSON. I am surprised to hear about sam talking about the importance of edge weighting in this context, isn't the whole point of credential that I am saying X is true? isn't that always a weight of 1? am i misunderstanding? 18:58:05 50% chance your GS1 license is not expired phil ; ) 18:58:24 Lol 18:58:39 again, this weighting sounds like a great 3.0 feature to consider 18:58:44 I'm still a fan of LPGs tho... 18:58:47 Dwaite: you can attach multiple weights to the different claims, because you can attach different weightings to different pieces of evidence. 18:58:48 ack DavidC 18:58:53 +1. "I believe this to a 70% certainty" is a valid thing to verifiably assert. 18:58:55 We can use vocab and schema to easily attach probability to values 18:59:42 davidC: want to make a comment about envelopes, we have info that has everything to do with crypto that is in the core model, should be in the proof section, like expirty time. we have a lack of clarity between what has to do with the proofing and what has to do with the crypto. 19:00:21 +1 David, cleaning up those blurry lines is our primary mission IMO... opening up the date model, puts that mission in jeopardy... new work items I am a part of at IETF, don't even offer JSON as an option, its just CBOR / COSE. 19:00:28 s/expirty/expiry/ 19:00:35 ack JoeAndrieu 19:00:35 JoeAndrieu, you wanted to say the developer challenge with JSON-LD is more about DEFINING good data model. It's easy to model with a JSON mind-set and get the underlying RDF wrong. 19:00:38 ... But that problem is inescapable. It is in fact, the right obstacle. 19:00:39 ...: the second point is what is a valid VC, we are encountering this in the Open ID connect, a valid context, with a valid IRI, but you can easily specify those types using their URIs, I bet you these will break if you replace user friendly names with URIs 19:01:13 SamSmith has joined #vcwg 19:01:17 q 19:01:24 q+ 19:01:49 btw, I am also in favor of using `@vocab` to private explicit support for. "private claims" in the VCDM 2.0. 19:01:57 Joe: I want to share some learnings I had: profiling a learner with two different wrappers, one for the learner, If i did not have access to excellent resources I would have struggled. Defining a good context is hard, most devs do not need to do that. what we want is a VC that i can use a context/vocab/schema that people understand. 19:02:11 s/private/create/ 19:02:39 +1 needing more effort for a shared understanding vs. private modeling of "whatever" :) 19:02:40 ...: most devs are not designing information context, the designing part is hard. Forging a shared understanding is where we get the benefits but it is an extra lift. 19:02:42 ack nadalin 19:03:14 nadalin: you should not force at what is a VC today, and look at why are people not conforming? you should look at why the mistakes are happening, look at why they are not conforming, find the reason. 19:03:22 ack SamSmith 19:03:31 q+ to ask next steps 19:03:37 mccown has joined #vcwg 19:04:04 FWIW, here's the LER Wrapper I mentioned: https://static1.squarespace.com/static/607dccff60f78d73c96a3473/t/61648f3243286409709d66a5/1633980210604/PublicSpecificationforLERWrapperandWalletRecord.pdf 19:04:05 nadlin How does knowing why GitHub fails to sign commits properly with PGP, help us decide if we should change the PGP spec to make what GitHub is doing legal? 19:04:14 Sam: one of the advantages of property graphs is not weight but that you can have properties on the edge. this lets you say that an edge matches an ACDC that is points ot a schema that is on the edge. This lets you extend by adding a new node to the graph without cooperation with what was specified in the past. 19:04:27 q+ 19:04:52 That is what vocabularies give you 19:04:53 s/ ot / to / 19:04:54 ...: one of the hard part of mapping with context, is that meaning of words drift between contexts. The mapping is never 1, there are lots of things we want to do with VCs that require making inferences across links that do not have 100% certainty 19:05:15 q+ 19:05:52 +1 to Sam's statement about RDF vs graphs 19:05:53 ...: the verifiable data structure is enabled by having those property graphs, you can build them all using JSON and JSON schema, this enables people who use JSON and JSON schema tooling to build more sophisticated systems, because it is much easier to build property graphs. 19:06:02 ack brent 19:06:02 brentz, you wanted to ask next steps 19:06:07 I get the desire to reinvent RDF... in JSON... its always easier to build on what you know, than to build on a standard that you don't know that is already adopted. 19:06:17 decentralgabe has joined #vcwg 19:06:24 strawpoll? 19:06:28 q+ to note that PRs might be next? 19:06:30 Brent: What are concrete next steps here? we have outlines of a proposal from Orie where we keep the data model as is, and focus on opening the aperture on the security side? Where do we go from here? 19:06:45 Lets poll to measure 19:07:08 JSON Compatible JSON-LD for the envelope / core data model - focus on the security model 19:07:28 Kristina: we do not have consensus but the issue is more clearly framed. There are three options: what we see on the screen, closer to what manu was proposing with JSON as JSON-Ld, third closer to how do we reflect people who cannot use JSON-LD correctly 19:07:41 s/JSON-Ld/JSON-LD/ 19:07:42 ...: do people agree with that framing? 19:07:51 q+ to call for "define abstract data model for VC 2.0"? To just put that behind us, maybe? 19:07:58 q- 19:08:08 +1 dlongley 19:08:19 +1 to mprorock's framing of one of the options (plus with a focus on helping JSON devs however we can) (unemoting this) 19:08:23 brent: some calls for polling, i'll frame the question and throw it in the chat. 19:08:24 +1 on mprorock's and kristina's formulation. 19:08:25 ack ivan 19:08:35 goto has joined #vcwg 19:08:57 Ivan: to avoid misunderstanding, i get the value of property graphs, we are in contact with the people in that community trying to get them to come to the W3C for further standardization and we were sent away. 19:09:46 I am also in favor of tackling this topic directly, in 3.0.... with property graphs... just not with the current fires we need to put out. 19:09:57 ...: I get the value and you don't have to convince me. The situation today is do we want to restart the work and reformulate the current VC spec by throwing out our current model, or as Dave put it just look at RDF-STAR which allows us the possiblity of 2.5,3 or whatever which will bring in the features later on. 19:09:59 +1 to Ivan 19:10:00 I do not see enough support for property graphs for v2.0 at least among current participants, and hear sentiment maybe v3.0 19:10:07 +1 ivan 19:10:15 plus -- we get some incubation period to get that right in between 19:10:19 +1 ivan 19:10:33 q+ 19:10:36 ...: I think throwing away everything would be an enormous waste, and an enormous amount of energy, and waiting for RDF-Star is much cheaper. 19:10:45 nadalin has joined #vcwg 19:10:49 Happy to make sure a draft gets incubated if folks want to work on it in CCG 19:10:51 +1 to ivan 19:10:57 present+ 19:11:04 Kristina: I do not hear lots of support for property graphs for 2.0. Please open an issue 19:11:19 Brent: +1/-1 poll 19:11:20 The core data model should be written in JSON-compatible JSON-LD 19:11:20 This is a false dilemma. The choice is not RDF vs RDF*. Its do we allow in JSON people to use data models that are essentially property graphs 19:11:22 +1 19:11:24 +1 19:11:25 +1 19:11:25 +1 19:11:25 +1 19:11:29 +1 19:11:29 +1 19:11:29 +1 19:11:29 +1 19:11:30 +1 19:11:30 -1 that statement is meaningless 19:11:30 +1 19:11:33 +1 (as observer, not representing any organization) 19:11:34 +1 19:11:37 -1 19:11:37 +1 19:11:37 +1 19:11:38 JSON-LD *is* JSON compatible. 19:11:39 -1 19:11:46 0 19:11:54 -1 19:11:56 0 19:11:58 @tallted only if you close your eyes .... 19:12:13 ack TallTed 19:12:17 to me... that means an RDF data model that will be serialized to a specific profile of JSON-LD 19:12:33 that is very JSON friendly (in a variety of ways) 19:12:52 -1 19:13:10 q+ 19:13:10 Ted: similar to what Ivan has been saying, I don't think we can cut it out of the conversation it has been shoehorned in different places. Property graphs are not standardized, there is no standard for them. This is not a path forward on stanrdards, W3C work is toward standards. This is not the path of property graphs to the degree i have experienced to this date. 19:13:20 More concretely, "JSON-LD compatible JSON" means "don't use expanded form, don't use crazy @values everywhere, don't use the full extent of JSON-LD" 19:13:38 +1 manu 19:13:38 goto_ has joined #vcwg 19:13:41 (a JSON-idiomatic profile of JSON-LD) 19:13:47 +1 to above 19:13:47 +1 ted 19:13:49 ack JoeAndrieu 19:13:51 ...: Maybe in a few years it will be but it currently is not, and at that point there may be RDF-Star, i think we are going to be wasting an hour if we focus on property graphs. 19:14:00 +1 to the "this is W3C" angle... there might be better places to do LPG standards that are not W3C... Same is true for DIDs. 19:14:10 s/stanrdards/standards/ 19:14:19 +1 to Ted 19:14:23 ack SamSmith 19:14:25 Joe: The question is backing away from Infra is not the issue, I heard a concern about starting from scratch. 19:15:03 sam: i was not proposing we do RDF-Star, or other property graph standards, i was saying we should allow people using JSON, to build property graph constructs, and not be forced to use something that requires them to use it. 19:15:18 I think... we agree we want to make it easier for the developers for whom JSON-LD is a heavy lift.. 19:15:21 me error. INFRA was the DID thing. My comment can be dismissed 19:15:28 Brent: thank you for a good session, we got pretty close to concensus on that strawpoll there, i think we have a path to censensus. 19:15:41 rrsagent, draft minutes 19:15:41 I have made the request to generate https://www.w3.org/2022/09/15-vcwg-minutes.html ivan 19:15:42 present- 19:15:50 SamSmith re LPGs and VCs and RDF... https://github.com/w3c/vc-data-model/issues/881#issuecomment-1160696916 19:15:50 thanks @cel for the huge number of typo fixes! 19:15:58 so you're looking for some explicit expressivity that you see as missing... OK, be clear about what that expressivity is, and we can write something about how to express that in the model we're using -- or make appropriate adjustements as may be necessary to satisfy that explicit use case / requirement 19:16:26 rrsagent, draft minutes 19:16:26 I have made the request to generate https://www.w3.org/2022/09/15-vcwg-minutes.html ivan 19:16:38 Good my presentation this evening will be showing the use case and how we express it 19:16:42 in ACDC 19:16:59 Which is just JSON and JSON Schema 19:20:34 present+ 19:45:08 ivan has joined #vcwg 19:45:26 Jay has joined #vcwg 19:47:15 MacTed has joined #vcwg 19:47:21 ivan_ has joined #vcwg 20:03:34 RRSAgent, generate minutes 20:03:34 I have made the request to generate https://www.w3.org/2022/09/15-vcwg-minutes.html MacTed 20:08:53 risako has joined #vcwg 20:14:08 Jay has joined #vcwg 20:15:07 phila has joined #vcwg 20:15:53 matatk has joined #vcwg 20:16:07 gkellogg has joined #vcwg 20:16:17 present+ 20:16:33 pchampin has joined #vcwg 20:16:35 scribe: phila 20:16:59 PaulG has joined #vcwg 20:17:07 present+ 20:17:18 Topic: Joint Session - APA WG 20:17:55 decentralgabe has joined #vcwg 20:18:05 Fazio has joined #vcwg 20:18:18 scott_h has joined #vcwg 20:18:26 present+ 20:18:33 present+ 20:18:37 present+ 20:18:39 Lionel_Wolberger has joined #vcwg 20:18:42 kristina: Calls the meeting to order 20:18:45 present+ 20:18:46 present+ 20:19:19 brentz: The VC WG dinner is tonight. Meeting at 18:30 at Joe Fortez restaurant 20:19:23 kristina has joined #vcwg 20:19:35 starting! 20:19:37 * Lionel asks, can someone put the zoom link in the IRC please? 20:19:48 ivan_: Suggests meeting in the hall at 18:10 20:20:00 https://us02web.zoom.us/j/4929080639?pwd=VXN3ODE0U2x4TFhRK1RhODVBeW9ndz09 20:20:15 Irfan_Ali has joined #vcwg 20:20:21 present+ 20:20:27 present+ 20:20:41 atai has joined #vcwg 20:20:46 kristina: Welcomes members from APA (Accessible Platform Applications WG) 20:20:57 ... looking forward to hearing use cases 20:21:22 JoeAndrieu has joined #vcwg 20:21:25 present+ 20:21:25 Matthew Atkinson 20:21:29 present+ 20:21:31 Paul Grenier (apa member and chair of spoken pronunciation) 20:21:31 David Fazio - Fazio 20:21:38 matatk: I'm a co-chair of the WG 20:21:48 ... we can lead you to the use cases doc we have 20:21:48 Representing APA: Janina Sajka, Matthew Atkinson, Lionel Wolberger, Scott Hollier 20:21:56 ... and we have a couple of specific things to talk about 20:22:18 APA's agenda: https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2022#APA_.26_Verifiable_Credentials_Joint_Meeting 20:22:22 Irfan Ali (apa member and co-chair of spoken pronunciation) 20:22:26 present+ Janina 20:22:29 janina: We have a specific question 20:22:31 present+ 20:22:36 sebastianelfors has joined #vcwg 20:22:49 mccown has joined #vcwg 20:22:50 ... long standing problem with captures. Were hoping your tech will help get rid of Captchas 20:22:57 present+ 20:22:59 ... then we have the more general topic to discuss 20:23:05 ... at least on a conceptual basis 20:23:11 dezell has joined #vcwg 20:23:19 present+ 20:23:22 Accessible Authentication - Web Content Accessibility Guidelines 2.2 Success Criteria 20:23:22 present+ 20:23:25 brentz has joined #vcwg 20:23:26 janina: Might be be able to associate user with preferences (font size etc) 20:23:32 kdeangs1 has joined #vcwg 20:23:33 present+ 20:23:36 ... that can operate across devices 20:23:58 takuya has joined #vcwg 20:23:59 ... resurrects idea from 1995 when we thought CSS would do it for us, but user overrides have not succeeded 20:24:08 ... and even if they had, it would not be cross-device 20:24:24 ... that's why we think VCs might help - think of them as config files 20:24:29 Uchi has joined #vcwg 20:24:39 janina: But I want to start with the captcha question 20:24:44 subtopic: CAPTCHA 20:24:57 present+ 20:24:58 Karen has joined #vcwg 20:25:00 janina: Everyone's looking forward to passwordless login 20:25:36 hsano has joined #vcwg 20:25:51 jasonjgw has joined #vcwg 20:25:53 Fazio: A11y guidelines talk about success criteria 20:25:54 q? 20:26:06 ... one of them is accessible authn - read "Captcha killer" 20:26:08 present+ 20:26:09 Sadly, I think the biggest blockers to letting users set their own display preferences are Web designers who believe their way of display is the One Twue Way, and browser vendors who don't add "override all CSS" checkbox to their preferences which *do* let the user select default font and size (for monospaced and proportional). 20:26:20 q+ on replacing captcha - "proof of personhood" is being done at some level for digital age verification. 20:26:20 The Captcha paper is here https://www.w3.org/TR/turingtest/ 20:26:24 Fazio: Problems of security that don't require cognitive tests 20:26:55 s/Twue/True/ 20:26:55 q+ on asking about general accessibility of VCs 20:26:57 Lionel_Wolberger: I'm sharing my screen 20:27:13 ... see Turingtest link 20:27:33 Lionel_Wolberger: Sets out the current problem 20:27:36 Jem has joined #vcwg 20:27:48 present+ JaeunJemmaKu 20:27:50 ... the alternatives, like audio, are no better 20:28:18 janina: Speech recognition is now too good. Solving audio Captchas is no longer an effective check 20:28:26 ... ASR systems can solve them 20:28:35 Karen has joined #vcwg 20:28:49 +1 phila 20:29:09 Lionel_Wolberger: Looking at alternatives for a persistent Turing test 20:29:17 SteveNoble has joined #vcwg 20:29:17 I think this was the URL shared https://w3c.github.io/apa/captcha/ 20:29:18 ... 'CAP' has a working prototype 20:29:30 present+ 20:29:41 Lionel_Wolberger: A recent sharp uptake of FIDO by Apple, we're excited about that also 20:29:52 gkellogg has joined #vcwg 20:30:02 ... Smartphones are ubiquitous. The biometric function is v helpful 20:30:09 q? 20:30:12 Lionel_Wolberger: So... VCWG... do you have any thoughts 20:30:12 ack manu 20:30:12 manu, you wanted to comment on replacing captcha - "proof of personhood" is being done at some level for digital age verification. 20:30:15 Accessibility Guidlines Github issues regarding accessible authentification: https://github.com/w3c/wcag/labels/3.3.7%20Accessible%20Authentication 20:30:17 present+ 20:30:20 manu: Welcome. Thanks for joining us 20:30:21 q? 20:30:25 Thank you kristina, sorry for not posting. This one is slightly more up to date: https://www.w3.org/TR/turingtest/ 20:30:35 ah ok, thank you! 20:30:49 is there a pointer to VC use-cases document you have worked on? 20:30:51 manu: I want to point out a number of things that you point out Lionel_Wolberger are representable as VCs, so the question is, can we creae a broader solution 20:30:53 or is it the same one? 20:30:58 ... cf. a single hardware device 20:31:15 manu: The concept of passing a Turing test and getting a bunch of tokens resonates 20:31:36 ... The digital age verification systsm in the US, you have to turn up physically somewhere like a convenience store 20:31:58 ... You have to show up in person to activate your token and the toeksn that come from that. That's actually a Turning test 20:32:11 s/toeksn/tokens/ 20:32:27 manu: The tech can suppport these use cases but what we are lacking is how does the individual a11y needs use that 20:32:44 manu: When it comes to presenting that at a website, we're lacking a11y interfaces that we're using 20:32:47 Geun-Hyung_Kim has joined #vcwg 20:32:57 ... so we need help from you in defining the interfaces 20:33:02 q+ 20:33:23 janina: We know we need to loo at interfaces. We're a horizontal review group and 'interface' is a trigger word 20:33:58 wonsuk has joined #vcwg 20:34:05 Lionel_Wolberger: That was a helpful manu, we face a broader challenge of wallets in general 20:34:19 ... in W3C, I hear you're involved in blockchains 20:34:30 ... this s a type of wallet 20:34:38 q? 20:35:01 s/loo /look / 20:35:06 q+ 20:35:10 ack gkellogg 20:35:10 gkellogg, you wanted to comment on asking about general accessibility of VCs 20:35:17 ack gkellogg 20:35:23 YanZhang has joined #vcwg 20:36:02 gkellogg: This is not specifically about captcha ... VCs are mainly a data model but they're intended for presentation 20:36:22 ... so I wonder whether the VCWG has thought about presentation and esp a11y 20:36:29 q+ To check on agenda timing 20:36:47 manu: We have an a11y consideration in the spec now but it's a massive cop out "it's a data model, of course it's accessible" 20:36:58 ... This is all going to come to the fore when we talk about presentation 20:37:30 q+ 20:37:44 ... Unfortunately, even in this iteration, we don't have that. People are building against our spec but presentation isn't in there and therefore nor is a11y 20:37:59 +1 to voluntary exploration of accessibility 20:38:03 manu: I don't know how structure that work other than requesting help from you when it comes up 20:38:31 Lionel_Wolberger: We do sometimes flag in a data model or low level API, we see future a11y issues. We've done that before and we could revisit your a11y section 20:38:37 ... and look at that issue 20:38:49 ack ivan_ 20:39:20 ivan_: Manu preempted me. It's not in our charter to work on presentation of our data model. It will come up eventally. At the moment, it's not part of the our work 20:39:38 ... What you just described as a kind of future looking comment... for later... that wojld be useful 20:39:50 ivan_: But to set expectation, we're not working on presentation 20:40:01 janina: We're not expecting something in 6 months 20:40:03 q+ 20:40:20 q+ to note that I don't think we should wait two years to get a11y review, we have an implementation guide. 20:40:21 janina: Are you looking at cross-federated environments 20:40:43 our charter: https://www.w3.org/2022/06/verifiable-credentials-wg-charter.html 20:40:50 https://www.w3.org/2022/06/verifiable-credentials-wg-charter.html 20:40:53 ... IS your current scope including - eg. - devices from multiple environments, say between an Android phone and a Mac laptop 20:41:06 Lionel_Wolberger: We also produce docs that are user requirements 20:41:24 we can non-normatively talk about APIs/protocols, but cannot write normative documents on that topic 20:41:28 yes, huge +1 for digital wallet accessibility requirements! 20:41:30 ... It could be that one take away today is that we need to look at digital wallet usaebility 20:41:34 +1 20:41:38 scott: I agree 20:41:41 +` 20:41:47 +1 20:41:49 s/IS /Is / 20:41:49 q+ to huge +1 for digital wallet accessibility requirements 20:42:04 s/+`// 20:42:24 scott: We try to look at each area and see what the potential user requirements are 20:42:37 Example Accessibility User Requirements doc - this one is about XR: https://www.w3.org/TR/xaur/ 20:42:42 Lionel_Wolberger: That might be how we engage 20:42:42 q? 20:42:58 janina: It would point in the direction of a next charter 20:43:14 ... we would look at the presentation layer and give you points to think about 20:43:25 scott: I agree, we could look at that 20:43:43 Lionel_Wolberger: We have thoroughly documnted used case 20:44:20 s/documnted/documented/ 20:44:35 ack Orie 20:44:36 Lionel_Wolberger: The task force will take up a11y usability requirements for digital wallets 20:44:38 q? 20:44:49 Orie: Thanks for coming and participating today. 2 points to raise 20:45:10 ... First, base don the VC data model, one thing I've been exploring, taking advantgae of the structure 20:45:38 ... an arbitrarily complex VC might be difficult to perceive. is there a preferred order of nodes in the graph 20:45:49 ... or maybe giving the user just what they need 20:45:56 ... it's a graph traversal issue 20:46:07 ... great opportunities to create experiences to traverse the graph 20:46:31 Orie: I've done a little exploration but a11y and UX for VCs are issues for us to explore. 20:46:42 s/base don/based on/ 20:46:47 ... audio-visual experiences from the graph would be exciting 20:47:24 Orie: Second - maybe a use case for extensions like ad blockers that change experiences on web pages 20:47:52 Orie: We could take these user pref credentials and apply them in presentation 20:48:10 ... I'd be excited to explore a prototype this, as a personal interest in this space 20:48:32 Lionel_Wolberger: Short response - we're always interested in alternative forms of data consumption. Graph traversal would be an interesting 20:48:38 ack matatk 20:48:38 matatk, you wanted to check on agenda timing 20:49:03 * Lionel asks the name of the person who just spoke? 20:49:50 q+ 20:49:53 RQTF use cases for VC (feedback welcome): https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Some_use_cases_for_verifiable_credentials 20:50:41 janina: 60 million people in the US have 'a disability' but there are 60 million different disabilities [scribe paraphrase] 20:50:47 q- 20:50:53 YanZhang has joined #vcwg 20:51:07 ack PaulG 20:51:09 kristina: I think a brief overview of hte use cases doc would be a good use of limited time 20:51:23 s/hte/the 20:51:34 selfissued has joined #vcwg 20:51:38 present+ 20:51:41 PaulG: Going back to the charter and implementations. It would be helpful for APA to have links to implementations you're aware of, even if just in passing 20:51:49 ... this will be useful to look at s 20:52:16 PaulG: Looking at the charter, section 2.4, there's a lot there that have a11y issues 20:52:23 q? 20:52:29 ... the data model itself we can handwave over 20:52:32 ack manu 20:52:32 manu, you wanted to note that I don't think we should wait two years to get a11y review, we have an implementation guide. and to huge +1 for digital wallet accessibility 20:52:36 ... requirements 20:52:49 manu: Huge +1 to accessible digital wallet. The time to do that is now 20:52:50 +1 Manu 20:53:14 ... I don't want to wait a yeard for that. There are platforms you could look at now, even though it's out of scope for this VCWG 20:53:23 Rendering verfiable Credential: https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/rendering-verifiable-credentials.md 20:53:25 manu: 'rendering VCs' work 20:53:41 ... there will be some work done at RWOT, including visual and audio rendering 20:53:51 ... are there ways of creating human prose about the VC 20:53:59 dwaite has joined #vcwg 20:54:01 ... and it is targeted at meeting a11y needs 20:54:11 ... so a VC can be rendered in different ways 20:54:23 manu: That's sometehing we'd like to get input on 20:54:56 I've also looked at GPT-3 processing of content, such as text summary or sentiment analysis... really exciting area, but with some serious privacy considerations. 20:55:02 manu: Finally, today there are wallet engagement mechanisms that are dependent at taking out your phone and poiting it at something 20:55:13 ... is that an a11y challenge - scanning a QR code? 20:55:21 s/poiting/pointing/ 20:55:33 s/sometehing/something/ 20:55:35 janina: I think they're successful more often than not, but you should explore the not 20:55:50 scott: Finding QR codes to start with can be a challenge 20:55:51 q+ 20:55:59 q+ to ask about NFC 20:56:22 scribe+ 20:56:28 Fazio: I know McDonalds were working on something like Monopoly that can be played without vision 20:56:35 q+ 20:56:56 scott: I also saw in Australia, guidance on how to get your phone in the right place 20:57:29 Fazio: My @@ app when I go to scan a cheque, it guides the user to move closer, further away etc. 20:57:45 s/@@/Bank of America/ 20:57:55 Related to "recognizing unreadable text identifiers", there is also https://github.com/mxgmn/WaveFunctionCollapse ... this is relevant to "issuer" / "holder" identifiers. 20:58:26 Lionel_Wolberger: It's successful more often than not. QR codes on menus seen as bad but actually no, because it's much more likely I can find the QR code and have the menu read to me 20:58:38 ack Lionel_Wolberger 20:58:55 q+ 20:58:58 Lionel_Wolberger: Orie said he had some insights into addrsssing CSS persistence through a browser extension. I'd love to hear more about that 20:59:28 Orie: It's not a thing I've got a working prototype, but I have explored extensions that inject script tags. You have a VC that represents your CSS prefs 20:59:53 ... and the extension would parse that and convert it into a style tag and inject it isnot a page. Privacy considerations. What other elements might detect that? 21:00:00 ... and discern a disability 21:00:41 ... If you look at the extension ecosystem there might be something to help build use cases 21:00:52 Janina: This also might be a way toward accessible wallets 21:01:17 janina: People do tend to have devices from multiple manufacturers 21:01:28 Orie: Password managers are typically sync'd across devices 21:01:39 ack phila 21:01:39 phila, you wanted to ask about NFC 21:02:01 phila: I have multiple interests here. The applicability of QR codes is important to me. 21:02:29 ... what about NFC? The capacity varies. There are alternatives to QR. And better barcodes 21:02:32 phila: Multiple interests here, interestd in use of QR Codes from GS1 perspective. What about NFC? When you talk about QR Code, there are alternatives, QR is not the most high capacity thing in the world, there are better things than QR. 21:02:46 ... that thing that goes beep at the border gate is not a QR code 21:03:02 Lionel_Wolberger: I'm not sure we know about NFCs 21:03:20 Fazio: I'd be concerned about privacy with NFC 21:03:23 s/interestd/interested/ 21:03:31 q? 21:03:34 ... I'm worried about credit cards being used outside the wallet 21:03:35 q+ 21:03:39 ack sebastianelfors 21:04:18 sebastianelfors: We had a discussion in the FIDO alliance about VCs. We concluded the Hyperledger approach was interesting 21:04:30 ... could be super-interesting for a11y 21:04:39 I can say that webNFC and web bluetooth are not well supported outside of chrome... https://github.com/w3c/web-nfc/issues/578 21:04:40 [scribe missed some of that, sorry] 21:04:41 q+ 21:04:59 q+ 21:05:08 kristina: You mentioned Web App Sec, W3C universal wallet... please add URLs to IRC 21:05:20 ack Orie 21:05:39 mprorock has joined #vcwg 21:05:46 s/Web App Sec/Wallet Security WG in DIF/ 21:05:57 tplooker has joined #vcwg 21:06:02 Orie: There are several wallet initiatives. ... a series of interaction protocols, openID Connect, DIDComm (popular on Hyperledge Aries) 21:06:04 KosukeKoiwai has joined #vcwg 21:06:06 present+ 21:06:44 q- 21:06:50 Orie: There have been conversations about Web NFC and wallets. What's the a11y angle. Outside native apps, those protocols can be less universally avalable 21:06:55 q? 21:07:15 ack Lionel_Wolberger 21:07:19 https://w3c-ccg.github.io/universal-wallet-interop-spec/ covers some wallet comms protocols 21:07:34 Lionel_Wolberger: We wanted to talk about the human care taker scenario ... very often a diabled person is in that situation 21:07:36 https://identity.foundation/wallet-rendering/v0.0.1/ 21:08:16 Janina: The standard example is the onset of Alzheimer's - one day someone else has to start making decisions and we need to cover those legal structures to do it 21:08:51 another link, to keep an eye on: https://www.linuxfoundation.org/press/linux-foundation-announces-an-intent-to-form-the-openwallet-foundation 21:09:01 Here are the mentioned iniatives for wallet backup/restore: 21:09:09 ack YanZhang 21:09:10 Janina: I can't do any of this 'power of attorney' work electronically (has to be on paper). I need to find someone I can trust, ahead of time, to take this on. An electronci version would be v good. 21:09:11 W3C Universal Wallet: https://w3c-ccg.github.io/universal-wallet-interop-spec/ 21:09:20 DIF Wallet Security: https://identity.foundation/working-groups/wallet-security.html 21:09:28 Hyperledger Indy Wallet: https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/design/003-wallet-storage/README.html 21:09:34 And here's Orie's issue for specifying backup/recovery for the W3C Universal Wallet: https://github.com/w3c-ccg/universal-wallet-interop-spec/issues/7 21:09:44 YanZhang: A11Y is v important. we talk about it internally a lot. The VC should be stored locally 21:09:56 q? 21:10:25 q+ 21:10:33 q+ to note caretaker/delegate VCs have been discussed, but we need more input from lawyers on what's needed. 21:10:55 ack Lionel_Wolberger 21:11:00 s/electronci/electronic/ 21:11:00 There are cases where you "sync" your credentials / messages to a new device from an existing one... migrating phones has gotten a lot easier recently... Android has done an amazing job of improving that experience. 21:11:35 Lionel_Wolberger: Something else we'd like to hear about. You say you don't do presentation. OK, but do want to speak for a minute about a person is who is associated with a procedure 21:11:47 s/procedure/association/ 21:11:58 s/association/advocacy association/ 21:12:08 Lionel_Wolberger: we'd love to see it working 21:12:18 q+ 21:12:23 We are also considering for a certain type of VC or VP, we can make them into non-fungible tokens, which is much easier to be recovered 21:12:29 ack matatk 21:12:33 ack manu 21:12:33 manu, you wanted to note caretaker/delegate VCs have been discussed, but we need more input from lawyers on what's needed. 21:12:44 manu: We're beyond PoC stage in many ways. There are companies here deploying this tech in real world (cites immigration services digital residency card) 21:13:03 ... in the next couple of years. That whole flow is applicable to that uze case you just outlines 21:13:10 If you are creating accessibility related credentials, you can consider: https://schema.org/accessibilityFeature 21:13:15 manu: What we're lacking is the organisation to issue the creds 21:13:38 ... You coud hope for a rapid turn around 21:13:44 s/coud/could/ 21:13:48 ack manu 21:14:27 manu: The caretaker/delegate use case. A child travelling with someone other than their parents, people who have any kind of caretaker needs 21:14:39 q- 21:14:45 mprorock_ has joined #vcwg 21:14:47 ... what we're misisng is someone to speak with authority in what those VCs should look like to have legal weight 21:14:56 ... we're missing subject matter experts tbh 21:15:11 Need *lots* of lawyers for that. At least one per jurisdiction. 21:15:20 Reminder of RQTF's use cases: https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Some_use_cases_for_verifiable_credentials 21:15:20 janina: I think we'll take to Wendy Seltzer 21:15:26 kristina: we're at time. 21:15:41 There is a project in Austin Texas, regarding "helper" / "care taker" use cases for persons experiencing homelessness - https://www.bythevalley.com/lifefiles 21:16:01 some of our team members worked on this. 21:16:09 kristina: Chair hat off. There are multiple UX issues we need to look at, but they are out of scope of the communication choice (HTTP, Bluetooth) 21:16:21 ... I think these are OOS for now. 21:16:50 Geun-Hyung_Kim has joined #vcwg 21:17:00 kristina: Maybe different people are implementing different presentations. Now we know a doc is coming up, that's going to help a lot 21:17:14 * Lionel asks anyone wishing to investigate the accessibility of an implementation, contact me at lionel@userway.org and I will pass it on to APA and RQTF 21:17:15 kristina: Chair hat on. Thanks very much for coming 21:17:21 Lionel_Wolberger: Thanks for having us. 21:20:12 jasonjgw has left #vcwg 21:20:23 I can scribe 21:20:35 Topic: Streamlining Data Integrity 21:21:18 sorry, remove me from the scribe list. 21:22:13 Link to slides: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_90 21:22:32 Slides from https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_90 21:23:24 manu: This is around potentially major changes that we need to make in data integrity to addrss some of the challenges we've hit in reent years 21:23:35 ... this is an attempt to be responsive to the community 21:23:44 ... aim to do so befre going to FPWD 21:24:08 ... Slides shows 3 topics to cover in the presentation 21:24:28 manu: The problem statement 21:24:40 ... crypto suite proliferation 21:25:30 manu: What we ended up saying way back was putting all the cyprto suites in the VC 21:25:38 .. we moved on quickly 21:25:48 ... people said what about my crypto context 21:26:04 ... Here we are many years later and people have had to take a differnt path. 21:26:36 ... Started putting all the cryptosuites in the one context. people complained, and put them in discrete contexts on top of the VC context 21:27:07 ... Whenever you need to use a specific type of crypto, you create your own context, include it at the top and you're fine 21:27:13 ... no dependencies on others 21:27:16 q? 21:27:41 s/differnt/different/ 21:27:51 manu: What tis created was a new concern. So many crypto suite contexts, lost "just use the basline context" 21:27:58 s/ tis / this / 21:28:00 q+ 21:28:06 s/basline/baseline/ 21:28:09 ack ivan_ 21:28:26 ivan_: This is not only a context file, it's a separate vocab, separate namespace and voc 21:28:35 manu: In practice they all share the same vocab 21:28:45 ... each context file just picks and chooses out of that vocab 21:29:02 q? 21:29:04 ... typically shares the same vocab but uses a differnet context. That's today 21:29:22 s/differnet/different/ 21:30:06 manu: Some people like lots of crypto suites. Not terrible but in reality they're almost the same. All that really changes is the type That's it. Lots of work just to generate a new crytopsuite 21:30:12 manu: Potential solution 21:30:22 s/crytopsuite/cryptosuite/ 21:30:33 Without a `@vocab` in v2: "@context": [ "https://www.w3.org/2018/credentials/v2", {"@vocab": "https://www.w3.org/2022/credentials/"} ], 21:30:37 manu: How can we use effectively the v1 context as is but use the crypto suites people want 21:30:57 with `@vocab` in v2 "@context": [ "https://www.w3.org/2020/credentials/v2" ], 21:31:32 manu: Proposed solution is to define a base Data Integrity Proof type. All we're doing is changing the type. Proposal is to add a new property of dataIntegrityProof 21:31:41 ... specifies crypto type as a string 21:31:47 manu: This is backwards compatible 21:31:51 ... nothing breaks 21:32:03 manu: But there may be a subset of us who are keen to move on 21:32:25 manu: [Shows solution example] 21:32:39 ... includes a v2 context. Defines the dataIntegrityProof type 21:32:46 ... then specifies crypto suite as a string 21:33:03 { 21:33:03 "@context": [ 21:33:03 "https://www.w3.org/2022/credentials/v2", 21:33:03 "https://www.w3.org/2022/credentials/examples/v2" 21:33:04 ], 21:33:04 "id": "http://example.edu/credentials/58473", 21:33:06 "type": ["VerifiableCredential", "AlumniCredential"], 21:33:08 ... 21:33:10 "proof": { 21:33:12 "type": "DataIntegrityProof", 21:33:14 "cryptosuite": "eddsa-2022", <-- this is now a string value 21:33:16 "created": "2022-02-25T14:58:42Z", 21:33:18 "verificationMethod": "https://example.edu/issuers/a#key-1", 21:33:20 "proofPurpose": "assertionMethod", 21:33:22 "proofValue": "z3FXQjecWufY46…UAUL5n2Brbx" 21:33:24 } 21:33:41 manu: The V2 context would then cover the majority of VCs. No more proliferation of contexts 21:33:54 ... if you need something more complex, the you can still do that. 21:34:23 manu: Bottom of the slide says: "Other potential crypto suites: nist-ecdsa-2022, koblitz-ecdsa-2022, rsa-2022, pgp-2022, bbs-2022, eascdsa-2022, ibsa-2022, jws-2022, recommended-2022, selective-disclosure-2022, postquantum-2022, etc. 21:34:23 " 21:34:43 q? 21:34:59 How about post-quantum cryptos? 21:35:00 q+ to ask about semantic disambiguation & centralization in the vocabulary 21:35:45 manu: Many devs have no knowledge of the differences between options. Should we just be specifying what's safe/recommended for 2022, 2023 etc 21:35:47 q+ to ask why DataIntegrityProof not its own context 21:35:54 q+ about post-quantum cryptos. 21:36:15 ... Maybe we recommend options to make it easier 21:36:17 q- about 21:36:23 q- post-quantum 21:36:30 manu: Those are just ideas, but show that this V2 context file can cover all these 21:36:36 q+ sebastianelfors 21:36:45 sebastianelfors q+ to talk about post-quantum cryptos. 21:36:46 gkellogg: Have you considered URIs instead of strings 21:36:54 q+ gkellog 21:37:01 q- cryptos. 21:37:04 q? 21:37:10 q+ to likely respond to pqc 21:37:16 ack JoeAndrieu 21:37:16 JoeAndrieu, you wanted to ask about semantic disambiguation & centralization in the vocabulary 21:37:43 JoeAndrieu: This in part doesn't seem to use the traditional JSON-LD disambiguation mechanism. Who controls the string for each cryptosuite? 21:37:53 A registry use case! 21:37:56 manu: Don't know. We will specify strings 21:38:07 phila: I had the same idea Orie 21:38:10 centrally managed registry... just like IANA :) 21:38:27 JoeAndrieu: We're allowing potentially ambiguous strings to be functional 21:38:35 manu: That stops proliferation 21:38:47 "The specification of new cryptographic primitives" is out of scope for v2. assume "a group defining cryptosuites is either implementers in this WG or CCG..? 21:38:52 JoeAndrieu: No it doesn't. There's no look up 21:38:54 q+ 21:39:07 ack brentz 21:39:07 brentz, you wanted to ask why DataIntegrityProof not its own context 21:39:18 brentz: Chair hat off. Sounds like a reason for a registry... 21:39:45 brentz: Why would data integrity proof be described in the V2 context rather than it's own data integrity context 21:39:58 q+ to say that a lot of the discussion here has to do with being practical for developers 21:40:06 manu: That would be an option, but it's about convenience. people say I really don't want to have to keep including lots of contexts 21:40:25 manu: This really is a bunch of engineering trade offs 21:40:28 q? 21:40:30 ack sebastianelfors 21:40:30 q+ 21:40:31 mkhraisha has joined #vcwg 21:41:17 sebastianelfors: Computer secrity resource centre, currently doing work on post-quantum. Should we take post-quantum into account? 21:41:27 s/secrity/security/ 21:41:30 manu: Yes, we have to consider post-quantum 21:41:30 q+ to explain JsonWebSignature2020 and COSE WG Post Quantum Signatures 21:41:37 q+ 21:41:42 manu: Whatever solution we have has to take account of post-q 21:41:50 ack gkellog 21:42:00 gkellogg: Why strings, not URIs? 21:42:12 gkellogg: They can be used the smae way but a URI has the potential to describe itself 21:42:28 ... and can be used to verify 21:42:31 Here's NIST CSRC program for post-quantum cryptos: https://csrc.nist.gov/projects/post-quantum-cryptography. 21:42:34 s/smae/same 21:42:57 manu: we could use a URI in here, but it might be fairly long which has consequences for things like Qr codes 21:43:06 ack mprorock_ 21:43:07 mprorock_, you wanted to likely respond to pqc 21:43:27 https://datatracker.ietf.org/doc/draft-prorock-cose-post-quantum-signatures/ 21:43:30 mprorock_: We know there has to be crypto agility. We had a call with some relevant experts. We shouldn't be defining cryptography here 21:44:04 +1 mprorock, I'm q'd to talk about overlap with VC-JWT / JsonWebSignature. 21:44:05 mprorock_: We know that stuff will come and as we talk later about multiple signatures, how are the big guys doing it etc that's when we get into practicalities 21:44:17 ack ivan_ 21:44:21 ... it would be greatto hear from people with experience 21:44:34 s/greatto/great to/ 21:44:57 ivan_: This sounds similar to the discussions we had this morning. For the lambda user, there is only one context user to add. But now they have add something else 21:45:11 To be clear, I am in favor of a "single context file" being enough... and for it to include a default vocabulary that covers private claims. 21:45:12 ... This change I think is a big improvement in usabulity 21:45:27 ivan_: But I think we won't avoid having some sort of registry for these things 21:45:28 +1 Ivan 21:45:39 ivan_: And to Brent - don't mix up the context and the vocabularies 21:45:50 +1 ivan 21:46:05 ack dlongley 21:46:05 dlongley, you wanted to say that a lot of the discussion here has to do with being practical for developers 21:46:22 dlongley: These solutions are responsive to developers 21:46:41 dlongley: We talked about that earlier (JSON-compatible JSON-LD etc) 21:47:00 q? 21:47:02 dlongley: The number of useful crytpo suites is much smaller than the number of VCs in the wild 21:47:09 q+ 21:47:11 ack tplooker 21:47:11 dlongley: So it scales 21:47:39 tplooker: Support in general for this. Makes it more manageable. Certainly experienced multiple context files being a problem for custimers 21:47:47 q+ to say the mere existence of emerging post-quantum cryptosuites highlights the need for decentralized disambiguation. 21:48:41 nadalin has joined #vcwg 21:48:44 mccown has joined #vcwg 21:48:44 ack Orie 21:48:45 Orie, you wanted to explain JsonWebSignature2020 and COSE WG Post Quantum Signatures 21:48:49 tplooker: On the intersect between what Dave was saying - technical purity, I agree. On stability designing extensibility for crypto suites... addressing a subset of problems for practicality 21:49:08 [ tplooker please check my scribing, I don't think I caught your words at all, sorry] 21:49:13 npd has joined #vcwg 21:49:27 s/custimers/customers 21:49:30 decentra_ has joined #vcwg 21:50:10 [orie talked about explain JsonWebSignature2020 and COSE WG Post Quantum Signatures] 21:50:21 q? 21:51:16 present+ 21:51:16 ack selfissued 21:51:21 Orie: We had the slide earlier where we were mapping between terms. Private claims - a crypto suite is a private claim - essential functionality with out of the box semantics - Generally I'm supportive of the idea for a simple contex file that covers what we need for V2 21:51:34 s/contex/context/ 21:51:46 selfissued: Why not just have a context for a cryptosuite that is extensible, logical, no registry to maintain 21:51:56 ... that seems the logicaloption to me 21:52:02 q? 21:52:06 ack pchampin 21:52:20 q+ to "why not just use different cryptosuite contexts"? 21:52:30 pchampin: String vs IRI discussion. If there is a registry which, from my POV seems a good idea, then every string can be made into an IRI 21:52:47 ... even without that, there are solutions in JSON-LD where those short strings can be made into IRIs 21:52:48 q+ to ask a simpler question 21:52:50 ack JoeAndrieu 21:52:50 JoeAndrieu, you wanted to say the mere existence of emerging post-quantum cryptosuites highlights the need for decentralized disambiguation. 21:53:14 JoeAndrieu: I apprecaite what selfissued just said. I think a single context file is not an extensibility model 21:53:28 s/apprecaite/appreciate/ 21:53:30 ack manu 21:53:30 manu, you wanted to "why not just use different cryptosuite contexts"? 21:53:31 ... we have to understand the context and we have to accept a potentially ambiguous string. Doesn't sound right to me 21:53:41 q+ 21:53:51 manu: In response to selfissued why not just use a different crytosuite? Bc people complained 21:54:12 q+ 21:54:22 manu: Devs seemed to be fine with creating a context for different use cases. But when you include the cyrpto suite, they start to complain 21:54:26 s/crytosuite/cryptosuite/ 21:54:39 it would be better to just add this to v2: "@vocab": "https://www.iana.org/assignments/jose#" 21:54:50 q- 21:55:03 s/cyrpto/crypto/ 21:55:08 manu: It's arguable that we're sing the model in this specific way. Are the trade offs worth it?? Fallback is to cary on doing what we're doing today but we know pepople complain about it 21:55:13 ack mprorock_ 21:55:13 mprorock_, you wanted to ask a simpler question 21:55:22 s/ sing / using / 21:55:26 mprorock_: I was going to ask - what would JOSE do? 21:55:29 s/pepople/people/ 21:55:32 or this: "@vocab": "https://w3id.org/w3c-registries/vc#" 21:55:40 q+ 21:55:53 mprorock_: Why don't we just define semantics for ??. What's the additional complexity we need above what JWTs etc 21:55:53 s/cary on/carry on/ 21:56:03 q+ to note we can't just point to IANA because they don't cover transformations. 21:56:10 s/??/JOSE kty, alg, etc./ 21:56:15 mprorock_: I want to attach signatures, but are we going too far and creating additional probs for ourselves 21:56:25 ack mccown 21:56:32 manu, vc-jwt doesn't DO tranformations ; ) 21:57:11 ??: I like this proposal. Whether the format is right I'm not sure. I chai the DIFComm WG (?) There are 3 acceptable crytpo options for post quantum (in hte US) 21:57:24 but the point is well taken, you could use the vocab to point to a w3c registry that disambiguated. 21:57:25 ... there's always going to be multiple signatures needed 21:57:33 s/DIFComm/DIDComm/ 21:57:56 s/crytpo/crypto/ 21:58:09 s/chai /chair / 21:58:10 ??: I can pick my favourite algorithm and then the client agent what it supports. If there;s an industry standard, that wold be super helpful 21:58:11 s/??:/mccown/ 21:58:16 ack dlongley 21:58:18 Karen has joined #vcwg 21:58:22 ack mikeprorock_ 21:58:33 q+ mprorock_ 21:58:38 dlongley: To respond to Mike. JOSE is great at expressing every option 21:58:38 s/??:/mccown:/ 21:58:52 s/mccown /mccown:/ 21:59:08 mprorock__ has joined #vcwg 21:59:17 dlongley: What it doesn't do is provide a layer that describes a set of layers that are afe to use 21:59:21 q+ 21:59:22 s/afe/safe/ 21:59:27 best mic of TPAC so far 21:59:40 dlongley: Might include things like c14 algorithms etc 21:59:45 q+ to ask for next steps 21:59:53 s/c14/c14n/ 22:00:00 sounds like a good use of a context for each of those well-formed cryptosuites 22:00:00 dlongley: being able to define these profiles is very useful. 22:00:19 ack manu 22:00:19 manu, you wanted to note we can't just point to IANA because they don't cover transformations. 22:00:51 Thats correct Manu, but specific to Data Integrity. 22:00:56 manu: Dave has said it best. To be specific - why can't just point to JOSE, We can't just point to the registry and say use that. 22:01:16 +1 to a new registry for "new parameters". 22:01:20 ack mprorock_ 22:01:22 manu: [gives example]. There are params that are needed that don't go into these crypto suites 22:01:26 -1 to new registries 22:01:45 mprorock_: Can we keep this simpler, maybe with registries, think about the dev process. 22:02:23 I can't wait to see "ProofOfWorkFreeRevocationList2022" 22:02:28 you don't want software to automatically allow any combination of parameters -- so you need a name (aka cryptosuite) underwhich to bind them all. 22:02:39 mprorock_: I want to keep more aligned with IANA. I trust W3C to talk about RDF canonicalisation, but not to pick "this is the set of crypto you should use" 22:02:39 ack selfissued 22:03:09 selfissued: Responding to dlongley - I don't agree that JOSE allows all the choices. It only allows things that we think make sense 22:03:31 selfissued: being able to use bad combinations is not good [paraphrase] 22:03:35 q+ to suggest next steps 22:03:51 kristina: I think the group agrees with the problem statement an the need to solve it. 22:04:08 ... Some divergence on registries 22:04:17 q+ 22:04:28 +1 manu 22:04:30 [Discussion about what the straw poll will be about] 22:04:38 Going to clarify: I want JSON-LD, I want an array of signatures, I also want those sigs described and pointed at iana 22:04:47 JoeAndrieu: I'm not sure what you mean by the problem statement? 22:04:54 kristina: The problem slide that Manu showed 22:05:00 *described using existing terms 22:05:41 JoeAndrieu: I don't know that we have consensus on that. I don't think a context that unambiguously references a crypto suite is a problem, I think it's a feature 22:05:42 q+ to ask what group would have the long-term responsibility of managing a registry? 22:05:46 kristina: OK, we'll start there 22:05:48 q+ 22:05:53 q- 22:05:57 q+ 22:06:15 Is the proliferation of cryptosuites a problem for data integrity 22:06:24 +1 22:06:25 +1 22:06:26 -1 22:06:26 +1 22:06:28 +1 (yes it is) 22:06:30 +1 22:06:30 +1 22:06:31 +1 22:06:32 +1 22:06:32 +1 22:06:33 +1 22:06:37 +1 22:06:37 what about the quantum!?! 22:06:37 -0.25 22:06:40 -1 22:06:44 -1 22:06:54 +1 (it does and will cause confusion in the user spheres) 22:06:57 -1 22:07:02 (the ergonomics of implementing them is more challenging than it needs to be, it's not necessarily that there are "too many") 22:07:11 ack JoeAndrieu 22:07:15 ack kristina 22:07:15 kristina, you wanted to ask for next steps 22:07:59 (...we're gonna need a crypto suite rubric...) 22:08:03 WG should define a base Data Integrity Proof type 22:08:03 q+ to say cryptosuite proliferation is a fact, not something we can specify away 22:08:09 +1 22:08:24 +1 22:08:32 +1 22:08:32 +1 22:08:32 +1 22:08:36 +1 22:08:36 +1 22:08:39 +1 22:08:41 +1 22:08:43 +0.9 (DRY principle - but appreciate extensibility) 22:08:50 +0 (plus to the definition, - to Manu's version) 22:09:06 _0 22:09:18 ack gkellogg 22:09:18 gkellogg, you wanted to ask what group would have the long-term responsibility of managing a registry? 22:09:22 -q 22:09:30 gkellogg: I'm guilty of writing specs that need registries 22:09:37 q+ 22:09:38 great question!!!!!! 22:09:54 ... Question is what group has hte long term resposnsibility for maintaining the registry 22:10:01 Excellent question 22:10:06 s/ hte / the / 22:10:14 gkellogg: Not saying whether it's a good or bad ide, just asking a question 22:10:26 ack pchampin 22:10:27 kristina: We have a session after the break about rgistries 22:10:31 ack kristina 22:10:47 +1 to the speaker. 22:11:10 pchampin: Joe talked about a context that identifies an uanmabiguous crypto suite That's not what a context does. I think you're talking about string vs IRI 22:11:13 crypto suites in a standards specification is another form of registry 22:11:15 +1 22:11:34 ack JoeAndrieu 22:11:34 JoeAndrieu, you wanted to say cryptosuite proliferation is a fact, not something we can specify away 22:11:42 JoeAndrieu: Whoever is creating this VC will identify the crypto. 22:11:59 s/rgistries/registries 22:12:05 q? 22:12:15 ... separating out the data integrity proof from the V2 context makes sense. But let's not add in ambiguity. We are going to have more crypto suites 22:12:28 q+ 22:12:37 q+ to say because that disambiguation is worth the squeeze in an open world, but not for a closed or "small" world 22:12:39 https://www.w3.org/TR/vc-data-model/#bib-vc-extension-registry points to https://w3c-ccg.github.io/vc-extension-registry/ 22:12:43 ... we can't lock down our crypto suites, we need to allow others and it can't be by reference to a registry that says A is OK, B is not [paraphrase] 22:12:45 ack Orie 22:12:46 q+ 22:12:56 registries that enforce a policy aren't registries, they are policy enforcement points 22:13:23 Orie: At the risk of blowing the regsitries conversation, it's worth just checking in what are we talking about puttin gin a registry. There's always the ability to build your own crypto suite 22:13:33 q+ 22:13:33 s/regsitries/registries/ 22:13:35 +1 orie 22:13:42 s/puttin gin/putting in/ 22:14:14 q+ 22:14:38 Orie: If you think this is going to kill decentralisation, it's not. You can still do crypto for you and your friends. It's a registry of known crypto suites 22:14:47 ack dlongley 22:14:47 dlongley, you wanted to say because that disambiguation is worth the squeeze in an open world, but not for a closed or "small" world 22:14:58 zakim, close the queue 22:14:58 ok, brentz, the speaker queue is closed 22:15:25 +1 22:15:27 dlongley: Big +1 to Orie. Disambiguation is worth the squeeze in the open world, but not the limited closed world. The number of crypto suites is use is actually small 22:16:07 dlongley: You just don't need massively decentralised extensibility. In the VC space it makes sense, but for crypto it's a much smaller set 22:16:20 ... Need to choose a fit for purpose solution 22:16:23 SamSmith has joined #vcwg 22:16:23 ack ivan_ 22:17:04 +1 to ivan's framing. 22:17:05 +1 to Ivan 22:17:06 +1 ivan 22:17:14 +1 to Ivan 22:17:19 ivan_: I just realised we may have missed a point If I understood Manu, the mechanism we have today would remain as an option. What we're looking at, I think, is making it easier for the 80%. The 20% can use the existing painful mechanism 22:17:19 ack tplooker 22:17:47 tplooker: I was going to make a similar point. Manu's proposal was about keeping the simple things simple, but allowing more complex decentralised approach if needed 22:18:17 +1 to tplooker 22:18:18 ack mprorock__ 22:18:21 tplooker: Crypto is a highly specialised industry. Should allow people to innovate - this proposal doesn't stop that. 22:18:36 +1 to getting "more secure by default" 22:18:47 mprorock__: Violent agreement. You won't be secure by default but we can work in that direction. Need to be careful of Not Invented Here 22:19:04 ... What put me off VCs at first is that some of this stuff had been solved before 22:19:28 ... we do have the ability to make breaking changes if we have to, but we don't want to close things off that we don't need to. 22:19:35 kristina: Thanks everyone for the conversation 22:19:35 +1 mike, safe defaults. 22:19:48 kristina: We have good agreement, but not full agreement 22:20:02 ... there will be different views on different contexts 22:20:23 kristina: Seems to be rough support for a registry - may change after the break 22:20:39 kristina: Proposal does not eliminate current approach. 22:20:47 ... so some support for proposed solution 22:20:58 note: I don't agree with the statement of support or consensus on this issue 22:21:02 RRSAgent, draft minutes 22:21:02 I have made the request to generate https://www.w3.org/2022/09/15-vcwg-minutes.html phila 22:21:10 rrsagent, draft minutes 22:21:10 I have made the request to generate https://www.w3.org/2022/09/15-vcwg-minutes.html ivan_ 22:21:12 zakim, open the queue 22:21:12 ok, brentz, the speaker queue is open 22:21:17 [Break for 15 minutes] 22:23:02 atai has left #vcwg 22:23:42 An earlier question asked why define a W3C managed registry for algorithm identifiers when IANA already defines one for COSE etc... This should be addressed independently from the question whether a registry is used/not 22:38:25 gkellogg has joined #vcwg 22:38:58 we are starting! 22:38:58 mkhraisha has joined #vcwg 22:39:23 scribe+ 22:39:38 Topic: VC registries 22:39:57 selfissued: Mike Jones from Microsoft. I've put things in registries over the years, and written a few of them. 22:40:21 mccown has joined #vcwg 22:40:32 ... Some review. What are registries? Many specifications define extention points. registries are authoritative listings of items utiltizing those ext points. 22:40:40 mprorock has joined #vcwg 22:40:46 present+ 22:41:06 ... Typically including an identifier, short human-readable description, reference to spec defining the thing (usually most important), and who is authorized to update it, may be necessary. May also include a status field, etc. 22:41:12 present+ 22:41:19 ... Each kind of registry may have fields that some other don't. 22:41:20 present+ 22:41:23 [Slide 75] 22:42:19 ... IANA JSON Web Signature and Encryption Algorithms registry. Two entries: ES256... ECDSA, ... alg, Recommended+ (meaning if you are building, probably should include it. "+" means may become required in the future) 22:42:28 ... RFC 7518 22:42:53 Geun-Hyung_Kim has joined #vcwg 22:42:55 ... The other entry, not made by an RFC, registered by the WebCrypto WG in W3C, was also put into the registry. 22:43:02 ... Change controller is that WG; reference to spec 22:43:16 ... [Slide 76] Why use registries? 22:43:26 ... Not just a list; enable interoperable implementations using them. 22:43:46 ... Registries contain references to authoritative definitions; that avoids name conflicts, among other things. 22:43:57 ... (So you can't just register ES256 privately) 22:44:03 ... Then we do interop testing, later... 22:44:28 ... This enables us to state that implementations of e.g. RSA-OAEP-384 to hopefully interoperate, in both WebCrypto and JOSE. 22:44:35 jeff_ has joined #vcwg 22:44:45 ... [Slide 77] We may soon make some process decisions; I want to make some suggestions. 22:44:53 present+ 22:44:56 ... Yesterday was my 30th anniversary at Microsoft 22:45:12 ... Pam Dingle posted a link on Twitter to a query of all the RFCs that I have; the most cited was JSON Web Token. 22:45:21 ... An awful lot of these use or establish registries. 22:45:28 -> https://twitter.com/pamelarosiedee/status/1570137774686375936 Mike's recognition 22:45:31 ... IETF has a separate org for regs: IANA 22:45:38 ... that administers numeric and textual assignments. 22:45:44 ... That's where the "4" for IPv4 is registered. 22:45:51 ... The 25 for SMTP 22:45:58 ... ES256 for that kind of signature. etc. 22:46:05 also where you can find your root servers: https://www.iana.org/domains/root/servers 22:46:12 ... Important because independent of WGs; also independent of the IESG. 22:46:30 ... To create a registry in IANA, you create an RFC. That's the one thing that's IETF-specific; you can't create one from e.g. this WG. 22:46:42 ... e.g. 7518 JWA 22:46:52 ... RFC defines criteria to register. 22:47:02 ... and populates the initial registry contents. 22:47:07 kdeangs1 has joined #vcwg 22:47:10 ... e.g. ES256 was in that RFC 22:47:23 ... IESG (area directors) select a few designated experts 22:47:35 ... who read incoming registration requests and decide whether they meet the critera or not. 22:47:43 ... Typically those are the initial RFC authors, but could be others. 22:47:45 dezell has joined #vcwg 22:47:54 ... Then the registry ready to take in requests. 22:47:57 present+ 22:48:04 ... So another spec (not necessarily an RFC) can register new stuff. 22:48:15 ... WebCrypto example - W3C has used IANA registries. 22:48:27 ... Finally, the designated experts review the requests, approve or reject and say why (rare) 22:48:38 ... IANA adds the entries to the database for approved requests, and then you can see them online. 22:49:02 ... RFC 8126 guidelines for writing an IANA considerations section in RFCs - describes this in pretty good detail - not just what to do, but why it's this way. an interesting read. 22:49:10 [Slide 78] 22:49:21 ... W3C has been working to establish registry practices. 22:49:28 ... A number of us in the room have been working on those. 22:49:35 ... I interviewed Ivan and Wendy about this 22:49:52 ... W3C can designate a specification as being a registry - document contains registration entries. 22:49:58 ... Registries administered by either a WG or a CG. 22:50:18 ... DID Spec Registries administered by DID WG 22:50:36 ... Unlike IANA... no designated experts; although a WG could appoint some as part of its process. 22:50:50 ... What bothers me most is that there is no provision for its maintenance beyong the lifetime of the CG/WG 22:50:50 q+ to comment on Community Group Registries 22:51:10 ... i.e. our registry could outlive the CG/WG, we want it to continue 22:51:14 ... Not there yet, but could get there 22:51:21 [Slide 79] 22:51:41 maintenance in making changes to the registry? or just the continued presence of the registry database? 22:51:43 ... I was in a WG with Tony and some others of you, WebAuthn WG, that decided explicitly to use IANA for its registries 22:52:00 ... In part for its independence, and the longevity factor 22:52:15 ... But need an RFC to establish the registry. So I and others did, with the blessing of the WG. 22:52:25 ... Two registries, one for attestations... 22:52:45 ... The initial registrations came from the WebAuthn Level 1 spec; cited them; WebAuthn Level 2 added new ones. 22:52:52 ... FIDO specs have also utilized these registries 22:52:58 s/attestations.../attestations, the other for extentions./ 22:53:06 ... Not to prejudice this, but we could choose to do the same thing 22:53:13 ... I think we want to have that discussion 22:53:17 [Slide 80] 22:53:36 ... One issue in our repository about the core of these discussions - feel free to read and comment. #909 (vc-data-model) 22:53:48 ... Turning the floor over to my colleague in Texas with the pretty office. 22:53:53 Orie: Thank you sir 22:54:06 ... To pick up with some examples, I'll point to some links here you may have seen. 22:54:29 ... There can be some confusion over the specification that defines terms, and the namespace or vocabulary that may contain definitions, and a registry that may point to that. 22:54:35 ... But you see versions of these in our work. 22:54:49 ... In the first link, see a landing page for verifiable credentials, the version from 2018. 22:54:52 [Slide 81] 22:54:59 ... VC in JWT format - you can understand how to interpret 22:55:03 ... the alg 22:55:08 ... and register additional terms 22:55:27 ... Private claims are not in the registry, but you may still seem them in a JWS/JWE header, or in a payload 22:55:34 q- 22:55:44 ... VC Data Integrity work has some contexts, those are pointing to IRIs 22:56:10 ... jws-20202, ed25519-2020... you'll see a description of those suites. Vocabularies... pointing to context files. 22:56:28 ... Namespaces (links on bottom of slide) 22:56:41 ... did, activity pub, web of things - all rooted under w3.org 22:57:06 ... These namespaces and registries have some similarity - have editors, maintaining term definitions, sometimes just pointing through to other locations 22:57:16 ... Some of these you might be using with verifiable credentials today. 22:57:20 ... Where do we register these? 22:57:24 [Slide 82] 22:57:38 ... w3id.org - permanent URL service maintained by w3.org - pretty popular 22:57:49 ... you can open a pull request and reserve a namespace under that 22:57:57 ... then can provide redirects to specifications. 22:58:07 s/by w3.org/by the community/ 22:58:12 ... So if e.g. Traceability were to move to a working group or other location, links could still work 22:58:42 ... Often folks working on VCs will set up something like this - since they are not sure if where they will host forever 22:58:55 ... So the vocabs can be changed but remain hosted 22:59:04 q+ 22:59:08 ... Examples not part of W3C community... 22:59:20 ... Rebase - social network account linking credentials 22:59:25 ... Schema directory (DIF) 22:59:29 ... KYC credentials 22:59:33 decentralgabe has joined #vcwg 22:59:45 ... That one is related to credential types - for registering decentralized semantics 22:59:59 ... for JSON-LD. But could be a collection of JSON schemas. 23:00:19 ... Potential confusion about JSON-LD and JSON schema; they are not direct substitutes 23:00:33 ... but both may need to be registered and hosted 23:00:38 ... for interoperability 23:00:43 {Slide 83] 23:00:59 ... Different kinds of content in the same registry: extentions to core data model, and DID methods. Different things! 23:01:31 ... DID method specs, need a contact. For checking names. "is foobar taken" 23:01:43 ... People can then click through to method specifications 23:01:56 ... In practice we see method specs being added frequently, but core terms to the data model not added very frequently 23:02:10 ... Maybe should split the registry based on what is more contentious / takes more frequent updates? 23:02:29 ... Another problem with did-spec-registries: considering requiring or not requiring value statements / impact statements 23:02:47 ... e.g. to acknowledge if it's based on a proof-of-work blockchain, to be forced to acknowledge that if the registry requires that. 23:03:02 ... This may be wanted to signal values about entries 23:03:21 ... Another value judgement: is it time to obsolete / not-recommend a particular suite. 23:03:29 ... Like md5 23:03:51 ... Community could form a registry with no values, and then later add values; or could form it with values and then later decide it's extraneous information. 23:04:11 ... If you are responsible for this, possibly you'll get things thrown at you if you don't make the right choice with regards to values. 23:04:37 ... Representations: In did-spec-registries need to think about how a term is represented 23:05:02 ... e.g. could use a different name for JSON, JSON-LD, YAML. Abstract name and concrete representations 23:05:11 ... But then new formats come in... CBOR, TOML... 23:05:14 ... So need some policy 23:05:28 ... Challenging to define registration critera so the maintainer can operate autonomously 23:05:37 ... without burdening them with an egregious policy for new entries 23:05:42 ... Since they are probably volunteering their time 23:05:51 ... despite maybe being a paid W3C member 23:06:03 ... If it takes too much effort, not good. But if registry is too lax, other risks. 23:06:28 ... What guidance to provide to registry maintainers - whether to include entries, or to ask the registrant to alter because of omissions or problems 23:06:30 JoeAndrieu has joined #vcwg 23:06:32 q? 23:06:34 [Slide 83] 23:06:35 q? 23:06:37 q+ 23:06:45 q+ to note W3C Registry Process. 23:06:46 ack ivan_ 23:06:57 q+ 23:07:01 ivan_: Some additional facts to complete the picture... 23:07:30 ... Slide 78 on W3C Registry Process - which is not very old... The reason the DID registry is not according to this process is because at the time we decided the DID registry, this process did not exist. 23:07:46 ... One element important in the registry process is that it requires the working group to describe/define the policy of how the registry is maintained. 23:07:59 ... That policy and maintenance has to be accepted by the AC, just as a recommendation has to be accepted. 23:08:09 ... So there is a pretty strict control over the policy, whether it is right or not. 23:08:33 q+ to talk about ref.gs1.org 23:08:33 ... That is a core of the matter... As Mike talked about how IANA does it with independent experts, etc... It's up to the WG to make a decision. 23:09:16 ... Slide 81 - Vocabularies and Namespaces - I don't consider that a registry, but that's a terminology issue... For about 10 years, the habit has been to put the namespaces under a /ns/ folder under the top-level of W3C. Only the Team has the right to control that. 23:09:26 pchampin has joined #vcwg 23:09:34 selfissued has joined #vcwg 23:09:34 ... So it is highly controlled... the W3C team acting as a gatekeeper... who that is depends on the team. 23:09:34 q- 23:09:38 present+ 23:09:39 q+ 23:09:56 +1 ivan :) 23:10:04 ... I was very surprised that the credentials vocabulary namespace is not that. I think that should have been done under the /ns namespace. Easy for me to say, I wasn't there... 23:10:14 ack JoeAndrieu 23:10:23 ... Probably too late to change, but highly unusual these days that it's where it is. 23:10:32 JoeAndrieu: I don't like registries. 23:10:39 +1 ivan 23:10:46 ... In a JSON-LD world, the way it's used is great... All the features Mike mentioned sound great. 23:11:02 ... But we don't need a centralized registry, because we already have an extensible model with JSON-LD 23:11:17 q+ to explain we do need a register for the "non private claims" our specification defines. 23:11:24 ... I don't believe W3C has the institutional capacity for registries. 23:11:30 +1 to Joe. cost to maintain registry is enomous 23:11:30 ... Most WGs don't know what makes a good registry. 23:11:35 +1 23:11:42 ... We had issues in the DID WG with changing the process, and schemas, without WG approval 23:11:52 q? 23:12:00 +1 to some of what joe is saying :) 23:12:04 s/enomous/enormous/ 23:12:12 ... w3.org was brought up as an example, I think that is a great example of a huge namespace under informal control, that far too many orgs are dependending on. 23:12:17 ... Self-appointed controllers 23:12:22 s/dependending/depending/ 23:12:29 ... It works, but it's a hack - not a good mechanism. 23:12:36 +1 to name squatting problem. 23:12:47 ... Registries create a first incentive - land grab 23:12:48 did:0: everyone wants it. 23:12:58 ... As long as have that incentive, we'll have hoarding, squatting, and trademark issues. 23:13:05 q+ 23:13:10 ack manu 23:13:10 manu, you wanted to note W3C Registry Process. 23:13:11 once there are too many things to register, registries don't work well 23:13:13 q+ 23:13:13 ... All of that is unnecessary with the JSON-LD extensibility model. 23:13:35 manu: I don't like registries, but they have grown on me. I think they are useful as a documentation tool. 23:14:04 ... I think it's telling that the verifiable credentials registries exists (but no one pays attention to it) and the community didn't implode as a result of it. 23:14:13 ... I think we'll have one eventually. People like it. 23:14:27 See https://w3c-ccg.github.io/vc-extension-registry/ also 23:14:30 ... Like Orie, I don't enjoy managing that registry, but it's been working, more-or-less. 23:14:59 ... I talked with David Singer and Florian who set up the registries process, saying people are complaining that a lot is left up to the WG. They said it's by design; it's up to the WG to decide things. 23:15:06 and https://github.com/w3c-ccg/ld-cryptosuite-registry 23:15:16 ... But people need help deciding... They said we discussed that; it's up to your WG to decide. 23:15:35 ... I agree we haven't quite figured out what the rules are for the DID Spec Registries. 23:15:51 ... Mike Orie and I are kindof flying by the seat of our pants... it's calmed down a little bit... 23:15:57 dwaite has joined #vcwg 23:16:01 ... I've seen the blowups with an expert denies an entry 23:16:17 q+ 23:16:17 ... Can't escape the controversy, whether it's at IANA or here, there's always a set of designated experts, whether here or there. 23:16:32 ... Not opposed to moving it to IANA eventually, but I think the group needs to figure out what will be in it, before moving it. 23:16:44 -1 to assuming we need a registry 23:16:49 ack phila 23:16:50 phila, you wanted to talk about ref.gs1.org 23:16:54 ... So I don't see a way out of defining rules, appointing designated experts, and having controversy as a result of that. 23:17:06 phila: Warning, I could talk about URL persistance for the rest of the year 23:17:10 kristina: Time check... 23:17:29 phila: There is a process, in fact as Mike said it's the RFC that sets up the process for the registry - the same as for the WG to define it 23:17:40 ... At some point, we'll do something else. I'll be retired in 10 years time. 23:17:49 ... Some of you will be. Some of you already are (Why are you here?) 23:18:02 -> https://ref.gs1.org/gs1/uri-policy/ 23:18:06 ... Persistence is important. Kevin and I spent cumulative hours setting up a new subdomain on our corporate domain name, about persistence ^ 23:18:27 ... The policy document for how to get URI there is extensive - designed, like w3.org/ns, like w3id, is because it has to be designed for persistence 23:18:32 ... otherwise your marketing department will change it 23:18:38 q? 23:18:43 ... Primary reason was to get it away from the marketing dept 23:18:49 ... w3.org has a persistence policy 23:18:49 https://ref.gs1.org/epcis/eventTime <3 23:18:52 https://www.w3.org/Consortium/Persistence 23:18:56 ... Problem is that it's out of date. 23:19:07 ... It names a host that hasn't been a host for 20 years 23:19:11 q? 23:19:16 ... Persistence is as important as process, both need to be a part of this. 23:19:16 ack mprorock 23:19:51 mprorock: I reiterate my hatred of registries, especially based on my experience in the did-spec-registries; too much for 1, 2 or 3 people to manaage - even with the lightening (but spiking) load 23:20:03 ... Do you have a spec? Does it look something like a spec? Cool, it goes in. 23:20:19 ... But then people in the WG get upset, there is pushback and flak; not helpful 23:20:33 ... So maybe with a process we can address this? But I'm skeptical. 23:20:42 ... Namespace is key; large orgs are thinking about it 23:20:47 (I don't see anything in the Persistence Policy that commits to a specific set of hosts, or mentions any host organizations by name) 23:20:55 ... Now is a really good time to get this over with - namespace, persistence - let's at least consider that. 23:21:17 ... Other thing: When you take something to a large corporate or government CIO, they will say, oh, it's an Internet registry, let me go to an Internet registry to look it up 23:21:37 ... We should think about that... Not a hard no on descriptions, registries of stuff we've looked at, maybe. 23:21:52 ... But to say, go do it at CCG... we're past that point. 23:22:01 ... People are using this stuff; not suitable for CG. 23:22:12 ... Other than having a test registry, to get working 23:22:22 +1 Mike, doing it in the ccg sends really bad signal to adopters sadly... speaking as a person who has done a lot of ccg registries 23:22:25 ack Orie 23:22:25 Orie, you wanted to explain we do need a register for the "non private claims" our specification defines. 23:22:25 ... Once it gets past that into the real world, it needs to go from CG to a WG, or to IETF, etc. 23:22:37 mccown has joined #vcwg 23:23:05 Orie: The concept of the terms we register in our spec that our spec defines; issuer, holder, credentialStatus, credentialSchema... those are terms that belong in a namespace/specification; we are defining them. 23:23:22 Values vs term names is different 23:23:28 ... Compared to JOSE, terms go in the registry. Other terms don't go into the IANA registry, but you still need to understand them. 23:23:46 ... Some properties are normatively defined in a spec; others are defined through an extensibility mechanism - part of a registry or not. 23:24:00 Allowed values of terms often belong in some kind of registry 23:24:07 +1 to two types of definitions: defined within the spec, defined through extensibility mechanism 23:24:07 ... Re: Joe's comment that we don't need any registries; I think we need something to point to the definitions of the terms we reserve. 23:24:09 q? 23:24:09 Assuming we want interoperability 23:24:21 ack kdeangs 23:24:23 gkellogg has joined #vcwg 23:24:42 kdeangs1: I'm with Joe, I don't like the idea of registries - in general; you get name squatting, trademark issues... 23:25:00 q+ to say yes, we do need to define the terms specified in the spec. that's what the v2 context is for. No registry needed. 23:25:02 ... Having a large centralized registry in my opinion goes against the philosophy of verifiable credentials that is decentralized. 23:25:16 +1 to kdeangs1 ... -1 to "large centralized registries" 23:25:17 ... The power of VCs is that it's decentralized. We should provide guidance how to build them... 23:25:26 ... But I don't think we should be hosting them 23:25:33 ... e.g. the vaccination credential 23:25:52 ... Incredible work by people in this group, but I don't think it belongs here; it should be hosted by that org, WHO. 23:26:03 ... Electronic passport, managed by International Civil Aviation Organization 23:26:09 ... If they are doing VCs for passports, they should host it 23:26:18 q? 23:26:22 ... Only relying us to host the core VC ... itself 23:26:27 s/us/on us/ 23:26:32 ack YanZhang 23:26:38 context: https://www.w3.org/2018/credentials/v1, vocabulary: https://www.w3.org/2018/credentials#VerifiableCredential 23:26:41 YanZhang: I agree, no one likes registries 23:26:52 ... VC-wise, we could work with a centralized system or an enterprise system 23:26:59 ... I don't think it's necessary to impose a centralized registry on the system. 23:27:15 ... 2. In fact, in different industries, same words may have different meanings. 23:27:26 ... So making a centralized registry ourself will have a lot of challenges 23:27:37 ... 3. Right now there are a lot of standards communities referencing our work. 23:27:43 ... e.g. ToIP foundation 23:27:53 ... 4. Decentralization by design / by default 23:27:54 It feels like "registry of what" is missing from the conversation.. 23:28:04 +1 kristina 23:28:05 +1 kristina 23:28:06 ... If we maintain centralized registry, it could jeopardize our collaboration with other organizations. 23:28:06 q+ 23:28:08 +1 kristina 23:28:15 +1 kristina 23:28:16 ... I agree we need some guidance on how to name things, what is a general process 23:28:27 +1 Kristina 23:28:32 ... So I get the essence of the work... maybe we need different names, to define the process, without registries 23:28:33 ack selfissued 23:28:38 +1 kristina ... registries only make sense for relatively small sets of information, IMO. 23:28:42 zakim, close the queue 23:28:42 ok, kristina, the speaker queue is closed 23:28:58 selfissued: Registries for what? To avoid name conflicts in a number of different places; pretty inevitable. Maybe not needed for JSON-LD, but needed for JSON and CBOR, etc. 23:29:08 ... So I think it's a foregone conclusion that we will have registries. 23:29:32 +1 selfissued 23:29:33 ... Re: mprorock's statement, the min bar we institute should not be subject to random interventions by the WG. It must be arms-length from the WG. 23:29:39 ... The way to do that is through IANA 23:30:08 ... It's still always on the WG to define the policies. Same at IETF, there are instructions to the experts. IANA does review that, just like the rest of the RFC, to make sure it's sane. 23:30:16 ... In our case maybe the AC has to review our instructions; that's all good. 23:30:30 ... If we have time, I would request that the chairs run a straw poll 23:30:38 q? 23:30:48 ... Whether, as a statement of intent, whether we want to run registries through IANA. 23:30:54 ack JoeAndrieu 23:30:54 JoeAndrieu, you wanted to say yes, we do need to define the terms specified in the spec. that's what the v2 context is for. No registry needed. 23:31:14 JoeAndrieu: Unfortunately, Manu and Mike, I think the assertion that it is inevitable is not collaborative, it shuts down 23:31:19 manu: Not my intent 23:31:24 JoeAndrieu: OK 23:31:24 dwaite has joined #vcwg 23:31:33 ... We may have some terms to define; not to think about as a registry... 23:31:49 ... In the world of VCs, we need to allow anyone to say anything, including if it's not okay by who is running the registry 23:31:49 ack nadalin 23:31:59 ... Since we have JSON-LD, I don't think we need it 23:32:06 nadalin: We already have it with JOSE claims 23:32:14 ... Nothing normative in the VC spec about having to be decentralized 23:32:18 +1 tony 23:32:27 kdeangs1: I never said we have to be... 23:32:38 +1 Orie 23:32:50 I like Orie proposal 23:32:54 centralized VCs don't need VCs 23:32:57 kristina: To close the conversation, let's run the straw proposal 23:33:45 wut... how does. adding a ns for v2 break anthing... v2 not exist yet. 23:33:48 mprorock: ... Should we consider that... 23:34:00 manu: ... would break the whole ecosystem ... 23:34:00 context is fine 23:34:03 ns is for vocabularies 23:34:09 kristina: If we ever need to have a registry, if the need comes up, 23:34:13 ... do we want to use IANA? 23:34:21 if we are talking ns, we are talking about changing the base URL for VC vocabulary -- that would be VERY BAD. 23:34:25 straw poll: we should run VCWG registries through IANA, if we have registries 23:34:26 ... since we heard some pain points by people who had to deal with did-spec-registries and whatnot 23:34:30 -1 23:34:31 osamu has joined #vcwg 23:34:33 +1 23:34:35 -1 23:34:36 +1 23:34:36 +1 23:34:39 +1 23:34:39 brentz: straw poll is non-binding 23:34:40 +1 23:34:41 +1 cost wise, and organizational stability wise. 23:34:41 +1 23:34:42 +1 23:34:42 +1 23:34:45 +1 23:34:46 -1, we need to understand the rules before handing it over. 23:34:47 -1 23:34:48 +0 23:34:53 crypto people will not use IANA 23:34:53 -1 23:34:53 -1 23:34:57 -0.5 23:35:01 will use ENS and etc 23:35:02 +0 23:35:02 -0 23:35:03 We would write the rules 23:35:08 The WG 23:35:10 -1 23:35:12 0 23:35:16 kristina: Thank you everyone. And there is another...? 23:35:39 straw poll: v2 will have an /ns for normative term defs? 23:35:44 -1 23:35:46 -1 23:35:55 +1 23:36:27 kristina: ... Never mind, second straw poll not valid 23:36:28 crypto domain is actually adopting W3C standards 23:36:55 ivan_: I think it was a mistake (not using /ns) but it's already out there, using the 2018 URL. RDF graphs are referring to them 23:36:56 luckily datestamped... so they will stay where they are. 23:37:01 VCs and DIDs are getting traction in the crypto world, but it's slow going 23:37:03 ... they have to stay where they are for eternity. It's too late. 23:37:06 a lot of debated between SBT and DID, 23:37:07 q+ to note "it's too late" 23:37:11 ... Physically there is a possibility for redirection 23:37:17 q+ to not it is about v2 not v1 23:37:17 ... But the vocabularies are there 23:37:41 2018 forever!!!! 23:37:47 ... If doing any inferencing... technically the only property is to use the owl sameAs statement... you don't even want to know. 23:37:48 it was a simpler time 23:37:51 before the merge 23:38:02 Lol 23:38:02 kristina: Let's take a deep breath, and move onto ACDC. 23:38:07 s/onto/on to/ 23:38:10 the year of the ICO. 23:38:31 LOL 23:38:42 [SamSmith presenting] 23:38:47 [Title Slide] 23:38:52 zakim, open the queue 23:38:52 ok, kristina, the speaker queue is open 23:39:03 SamSmith: ACDCs are verifiable data structures supporting attestations and credentials. 23:39:09 ... Slides will be posted tomorrow 23:39:16 [Resources slide] 23:39:27 ... ACDC for Muggles is a very good introduction to ACDCs at a high level 23:39:33 ... Presented at this WG meeting a few weeks ago. 23:39:41 ... This presentation today is more technical 23:39:45 ... ACDC is based on KERI 23:39:47 can we get these slides injected into the group deck for provenance? 23:39:54 ... [Important ACDC Features slide] 23:40:07 ... ACDCs leverage SEDs, and AIDs - namespace-agnostic identifiers 23:40:12 s/SED/SAID/ 23:40:21 note to the WG members (esp. editors) to open issues to record the conversations accordingly 23:40:29 q? 23:40:33 ... Based on "dumb" "white magic" crypto. Does not preclude using other crypto 23:40:42 ... Uses JSON Schema. Tied to schemas, immutable 23:41:00 ... Uses property graph model - but not tied to a particular version - just using JSON and JSON Schema. 23:41:17 ... Graduated disclosure; looks at disclosure in various forms: compact, private, partial, selective... 23:41:24 ... Contractually Protected Disclosure 23:41:37 ... Each of these may not be sufficient 23:41:49 ... (statistical correlation and cryptographic correlation) 23:41:57 ... Everything should be zero-trust and verifiable. 23:42:10 [Slide: Basic ACDCs] 23:42:13 ... Designed to be compact 23:42:51 ... Top level fields: version field, a SAID; salty nonce; id field, using a namespace or not; registry identifier, schema identifier; attribute, rules, edge identifiers - all SAIDs 23:43:07 ... making a cryptographic commitment to the full representation for serialization 23:43:13 ... but don't have to put the full representation over the wire 23:43:27 [Basic ACDC JSON Schema] 23:43:34 ... ACDCs use JSON Schema 23:43:44 ... Schema, required fields, property fields 23:43:52 ... That's the schema for the non-compact version 23:44:14 ... To uncompact it, take each section (attribute section...)... 23:44:21 ... A commitment to this (pointing) is a commitment to that (pointing) 23:44:29 ... So we can use JSON schema to make a commitment to both versions 23:44:38 ... to say I either have a SAID for this one, or the uncompacted one 23:44:46 ... to enable graduated disclosure 23:45:01 ... Issuer can require what they want 23:45:12 ... if they give enough flexibility, can use graduated disclosure 23:45:24 [Slide: Edge Section] 23:45:26 ... Edge has properties 23:45:42 ... Node/vertex (pointing to "d", "n", "s")... 23:46:04 ... Can define in schema the types of the edges 23:46:15 ... So verifier can verify by type, not just by reference 23:46:20 ... So don't have to expand... 23:46:30 [Slide: Nested Edge Section] 23:46:35 ... Schema not included, would take too long 23:46:44 [ACDC Normative slide... skipped] 23:46:51 [Slide: Big Picture] 23:46:58 ... Nodes with edges 23:47:10 ... Because using CIDs, it's a distributed graph 23:47:14 ... Verifiable data structure all the way down. 23:47:31 q+ to ask what format of content addressable identifiers, multiformats / ipfs ? 23:48:01 ... Important point is that it's decentralized verifiable data structure 23:48:42 jeff_ has joined #vcwg 23:49:07 Self-describing slides (or associated speaker notes) can be helpful for DEEP topics like this 23:49:21 cel: scribe interrupt, having trouble keeping up 23:49:24 [discussing] 23:49:35 SamSmith: ACDC is universally referenced by its SAID. 23:49:41 ... It's cryptographically self-describing 23:49:42 q? 23:49:56 ... Basically a hash; in a compact representation 23:50:01 ... Universally unique; no entity collissions 23:50:07 s/collissions/collisions/ 23:50:25 ... Because it's distributed, each graph fragment has an id; the schema is the same; so no collision possible 23:50:31 so far the closest to an existing standard I have seen so far is JSON Schema, is everything else new? 23:50:31 ... Same schema and SAID 23:50:34 pchampin has joined #vcwg 23:50:41 ... No collision of type for ACDCs as fragments 23:50:57 ... So I can sign and send over Internet; verify over wire they are verifiable and have integrity, 23:51:00 ... without having to do expansion. 23:51:15 ... This allows communicating to everyone in a distributed fashion 23:51:27 ... No need to coordinate on namespace, because everything is cryptographically verifiable and unique 23:51:35 ... It's verifiable all the way down. 23:51:46 ... This means provenanced chains of custody 23:51:51 ... Traceability in supply chains 23:52:08 ... Can chain together to represent chains of entitlement/authority 23:52:12 q? 23:52:15 ... like vLEI 23:52:20 q+ 23:52:33 ... Can add an adge, and the whole chain is verifiable 23:52:48 ... All the tooling verifies the same thing; just looks like a chained ACDC; no other representation 23:52:58 how is this related to https://github.com/ipld/ipld/blob/800570be4e91b9502911644fcf9f7f5098472ad0/specs/codecs/dag-jose/index.md 23:53:05 ack Orie 23:53:05 Orie, you wanted to ask what format of content addressable identifiers, multiformats / ipfs ? 23:53:22 Orie: Content IDs, JSON Schema... multiformats, IPFS? 23:53:34 ... JSON Schema is standard, sortof... Are others... building blocks? 23:53:39 SamSmith: CESAR 23:53:44 ... just a compact representation 23:53:52 s/CESAR/CSER/ 23:53:54 ... You would do a map of BLAKE3 digest to the COSE/JWT representation of that 23:54:09 SamSmith: ACDCs trying to benefit from compact representation to be easy to audit 23:54:10 +1 Orie this seems like a reinvented dag-jose/ipld 23:54:20 ... to not have verbose cryptographic primitives 23:54:26 ... but can map 1:1 typically 23:54:32 ... for other libraries 23:54:39 ... Compactness for usability 23:55:01 ... Nothing fancy for JSON Schema; just a string that is a compact representation of the schema itself, using the SAID protocol 23:55:08 copying this link from zoom here: https://weboftrust.github.io/ietf-said/draft-ssmith-said.html 23:55:12 ... to embed content-addressible data in a map 23:55:23 ... Using that protocol, everyone can verify the id as provided 23:55:28 ack mprorock 23:55:46 mprorock: Data traceability... have you tried looking into archive.org? 23:55:52 ... validating the crawl overhead? 23:55:58 SamSmith: No, have not done that 23:56:15 ... We have issued facts over IXVRL documents 23:56:32 ... so individual facts can be separately attested 23:56:42 ... Individual signers only liable for the facts they attested 23:56:51 [Slide: Append-to-Extend] 23:57:01 q+ 23:57:05 SamSmith: No namespace collisions; can piece them together because it's a CID 23:57:11 ... If you want custom fields, just chain them on. 23:57:20 ... Start with pre-existing fields in schema, then chain on the custom fields 23:57:27 ... The mantra is "append to extend" 23:57:43 ... So you don't need any centralized registries to avoid namespace collisions, because they are none 23:58:02 ... If you want to define new and meaningful labels... you can. 23:58:08 ack mprorock 23:58:09 mprorock: What are you asking us to do here? 23:58:17 [Slide: ... Ask] 23:58:33 SamSmith: ACDCs want to be interoperable; want a big-tent model with the W3C community 23:58:36 q+ 23:58:47 ... We use JSON Schema and CESR primitives... those could be mapped one-to-one with JWT primitives... 23:58:55 ... We don't want to be forced to use schema.org 23:59:03 ... Not asking to replace JSON-LD, but want to co-exist with just JSON 23:59:19 ... No normative field labels for our field labels, but could map to normative field labels for interoperability 23:59:23 ack mprorock 23:59:32 +1 mike 23:59:56 mprorock: A number of us have vocabularies that are bound to JSON schema, or JSON Schema in YAML format; to allow double-checking... seems to be working well. Why not just map vocab with some rules to the existing vocabularies you are after? 23:59:57 q+