Verifiable Credentials Working Group F2F, 1st day — Minutes

Date: 2022-09-15

See also the Agenda and the IRC Log


Present (VCWG): Michael Prorock, Dave Longley, Brent Zundel, Ivan Herman, Samuel Smith, Kristina Yasuda, Shigeya Suzuki, Manu Sporny, Orie Steele, Gabe Cohen, David Ezell, Phil Archer, Mahmoud Alkhraishi, Chris Abernethy, David Waite, David Lehn, David Chadwick, Justin Richer, Yan Zhang, Ted Thibodeau Jr., Sebastian Elfors, Antony Nadalin, Michael Jones, Steve McCown, Joe Andrieu, Charles Lehner, Oliver Terbu, Geunhyung Kim, Paul Dietrich, Steve Noble, Tobias Looker

Present (APA WG): David Fazio, Paul Grenier, Scott Hollier, Matthew Atkinson, Lionel Wolberger, Irfan Ali, Janina Sajka, Jason White,


Guests: Satoshi Sakamori, Paul Dietrich, Kosuke Koiwai, Jay Kishigami, Pierre-Antoine Champin, Osamu Nakamura, Hiroyuki Sano, Cole Davis, Reisako Hamano, John Bradley, Richard Worth, David Cohen, Wonsuk Lee, Karen Myers, Vittorio, Gregg Kellogg, Jaeun Jemma Ku, Ryosuke Abe, Jeff Jaffee

Chair: Kristina Yasuda, Brent Zundel

Scribe(s): Manu Sporny, Kristina Yasuda, Phil Archer, Mahmoud Alkhraishi, Brent Zundel, Charles Lehner


1. Introductions and Welcome.

Brent Zundel: Welcome everyone, we have a full agenda today and tomorrow. Let’s start off with some logistics.
… 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.
… We expect you to wear a mask, take your daily covid test, and practice good health practices throughout the day.

Kristina Yasuda: slides:

Brent Zundel: We are going to have 4 scribes throughout the day, we have a sign up list.
… Please jump into this slide if you’re willing to scribe, if you want to jump in, please add yourself to the scribe list.
… We are live in zoom and IRC, if you want to join the queue, we can add you to the queue.
… I think that’s mostly logistics.

Ivan Herman: please present+ if you are in IRC.

2. Agenda.

Brent Zundel: We are going to start out by talking about use cases. We will then break, then talk about transformations of core data model.
… We’ve already decided to split up securing VCs into separate specifications, JWT and Data Integrity.
… In the core data model, properties for credential and verifiable credential. We are going to talk about where serializations should go and where to specify them.
… Then break for lunch, then joint meeting with accessibility WG, they want to talk about use cases that they have.
… We’ll spend the rest of first block of afternoon about cryptosuites and Data Integrity streamlining.
… 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.

Kristina Yasuda: 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.

Orie Steele: Awesome context setting Kristina. Thank you..

Ivan Herman: 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.

Brent Zundel: If you are scribing, you have the power to stop the meeting.
… (to ask people to repeat what they said).

Ivan Herman: See The overall slide set on Google Doc.

3. Mission and Goals.

Brent Zundel: Our mission is to make expressing, exchanging, VCs easier and more secure on the Web. It’s what we’re here for.
… We have these deliverables in progress – VC 2.0, Data Integrity, JWT, JWS2020.
… This is what is in progress.

Kristina Yasuda: If people are familiar with Linked Data Proofs, that has been renamed to Data Integrity.

Brent Zundel: 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.
… 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.
… 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.
… 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.
… This is also the timeline for every other normative spec, we need to have things wrapped up in a year, we have a lot of process to go through to finish them, etc.
… This means that for primary spec, we are looking at march next year for feature freeze, that’s about 6-7 months out.
… 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.

Kevin Dean: We’ve stated in charter that we’re not committed to backwards compatibility.

Kristina Yasuda: Yes, but we do not want to do breaking changes without deep consideration.

Orie Steele: +1 to breaking changes to fix things!… when we need to..

Michael Prorock: +1 esp. on the when we need to.

Kevin Dean: Yes, we don’t have to go in with a sledge hammer.

4. Presentations.

Brent Zundel: When you introduce yourself, name, and something interesting about yourself.
… 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”.
… I don’t know why that was in my head.

Kristina Yasuda: Hi Kristina, I represent Microsoft, song stuck in my head “Man on the Moon”.

Cole Davis: Hi Cole, Switchboard, I have had Miles Davis in my head.

Dave Longley: Hi Dave Longley, Digital Bazaar, the most recent song stuck in my head was “What does the Fox say”, interesting trick, if you’re able to do short jingle in your head, you can stop remembering the song by doing tat.

David Chadwick: Hi David was on University of Kent, founded Verifiable Credentials LTD, bought by crossword cybersecurity director of identity.

David Lehn: David Lehn with Digital Bazaars, working w/ DIDs, VCs, etc for quite some time now.

Jay Kishigami: Jay from W3C, song in my head … is “Saturday in the Park by Chicago”.

Kosuke: Kosuke from KDDI, BTS in my head at times.

Michael Prorock: Mike Prorock, work w/ VCs/DIDs “big city” in my head right now.

Orie Steele: 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.

Osamu Nakamura: Osamu Nakamura from Keio, overseeing some of this work there.

Paul Dietrich: Paul from GS1US, work in innovation group on digital identity work – “I look just like Bob Dylan”.

Reisako Hamano: Risako, software engineer at Yahoo Japan.

Ryosuke Abe: Riosuke Abe from Keio, working on DID with Shigeya.

Samuel 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.
… was former interim chairman at Sovrin, Dwarf song from Misty Mountains.

Ted Thibodeau Jr.: Ted Thibodeau, OpenLink Software, working with everything Linked Data, VC, DIDs, x509, etc. I have no song in my head, rejoicing in my heart from a new fridge.

Chris Abernethy: I’m Chris with working with VCs for supply chain interop.

John Bradley: John from yubico, sex pistols god save the queen.

David Waite: David from Ping Identity, alternative have screaming trees I nearly lost you in my head.

Sebastian Elfors: Sebastian working, recently working on electronic signatures, work with ETSI, EUDI, FIDO Alliance, interested in work here could reach entire population for EU eople. .

Shigeya Suzuki: Shigeya Suzuki from Keo, marble machine.

Joe Andrieu: Joe from VC Editor of Use Case document, song in my head, C&C music machine everybody dance now.

David Ezell: David Ezell from Conexxus, song in my head steven sondheim from web side story, brilliant melody, dysptoian mood, onward christian soldiers.

Antony Nadalin: Tony Nadalin chair WebAuthn group, mr sandman.

Michael Jones: Mike Jones from Microsoft, 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.

Phil Archer: phila: selfissued is being modest. See this tweet from Pam Dingle

Karen Myers: Karen with W3C, member outreach, business development, new member Steve McCowen from Anonyme, I’m his buddy today. We have had many new members join fro VCs. Song, red solo cup.

VitorioB: I work for Okta, been in identity space for a couple of decades, beliver in t… chang of season by green theater.

Richard Worth: Richard from Capital One.

Yie: Yie working on blockchain, and working on VCs for payment, No music in my head.

Steve McCown: 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.

Sakamoto: Tkuya from … Working on trusted internet.

Mahmoud Alkhraishi: Mahmoud from Mavennet, I have rumors from Fleetwood Mac.

David Cohen: David from Block/TBD, song in my head, … scribe missed.

Gabe Cohen: Gabe, not David.

Hiroki: Hiroki from Sony, standardization; our member can’t join tpac, i’m here to learn more about VC work.

Kevin Dean: Kevin from GS1, co editor of VC use cases document, fun fact, from my university … rented classic hearse with coffin and went into prom.

Phil Archer: Phil work with Kevin at GS1 and Paul, as retired radio jock, trying to fogget songs, LBC news theme is song in my head.

Manu Sporny: Hi Manu.

SamGoto: Sam from Google Chrome, I have baby shark stuck in my head, my email is goto at google and chromium.

Pierre-Antoine Champin: 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.

Ivan Herman: Ivan Herman, from W3C team, staff contact for this working group, was at DID WG to Pierre, song in my head, flew into vancouver I listened to blues guitar of joe bonamassa, it kept me awake, if I need to stay awake, I need this in my head.

Manu Sporny: WonsukLee from ETRI, member of DID WG.

Ted Thibodeau Jr.: an earworm antidote for those who may need or want one, now or later:

Charles Lehner: Hi Charles Lehner, from Credentials CG.

Brent Zundel: Thanks for everyone that introduced themselves.

5. Real World Use Cases.

Brent Zundel: 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?.

Ivan Herman: See See slides.

Kristina Yasuda: I do have feelings about this topic, 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?.
… 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.

Manu Sporny: One of our biggest deployments is in retail age verification.
… we found the model adequate but big gaps in in-person presentation.
… getting the credential small enough to fit a small QR code was a big problem.

Kristina Yasuda: yeah, per conversation above, mission says “on the web”…

Manu Sporny: In-person presentation at PoS really hard with exiting software.
… Other thing we’ve heard from retail, gov etc want their credential to look a certain way.
… they have no control over that. Adding a PNG makes the credential huge.
… WoT looking at presentation layer.
… we’d be fine if none of that happens here as external model works, but those are the buggets challenges we see.

Kristina Yasuda: I think CSS group in W3C was working on standardizing “visuals” which could be expanded to VCs too.

Sebastian Elfors: 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.

Brent Zundel: DPP is Digital Product Passport.

Phil Archer: To pick up presentation issue, like manu I’d be ok with it not done here, support existence of presentation 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 where it can go.

Kristina Yasuda: 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.

Mahmoud Alkhraishi: 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”.

Brent Zundel: Can you speak more to that?.

Mahmoud Alkhraishi: I need a way to relate VCs/VPs together.

Joe Andrieu: I wanted to focus on presentation 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.

Brent Zundel: There is also wallet rendering work happening at DIF:

Manu Sporny: 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 service dog has its vax.
… preferences on websites, I#d like font to be > size X, contrast >= Y etc.
… we don’t have those in the UCR they’ll come in with.

Phil Archer: Adding an issue to data model to add hook for presentation (visual or otherwise).

Brent Zundel: That was what I was hoping from for that conversation.

Kristina Yasuda: Let’s discuss use cases with Joe.

6. Updating Use Cases.

Manu Sporny: See See slides.

Joe Andrieu: What we’ve done with use cases, what we’re doing in next phase, kevin has stepped forward to help with use case.
… 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.
… We have shifted some of the names here, these are the tasks that we have in the document, requirements, motivations, needs.

Kristina Yasuda:

Joe Andrieu: Then we have focal use cases, deeper dive on specific use cases, request us Citizenship, expert dive instructor to maintain certification, international travel with minor, expanded background, why this is interesting, who needs to trust whom and who is liable, and finally threat model.
… Understood threats, how system can respond, we have user sequences, creating VC, using VC.
… We have 5 example VCs, that are probably out of date. We should look at current use cases.
… Lessons learned, amend – we don’t really amend, so maybe we can take 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.

Gabe Cohen: @joeandrieu created an issue about a month ago re:evidence

Joe Andrieu: 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.
… how do you refer to a VC canonically? How do you link?.
… We refer to identifiers in VCs but not VC about another VC.
… another lessons learned, it’s hard to get contributions – easy to get at beginning and end, but not much inbetween.
… 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.
… 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 authorization or not.
… Not sure use cases are helping us there.
… I’ve already talked about presentation layer. Queue?.

Kristina Yasuda: 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 should be implementation guide. Might be requirements wishlist for data model.

Joe Andrieu: 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).
… Two different ways to look at same functionality.

Phil Archer: 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?.

Shigeya Suzuki: there are several use cases missing, I think we need to add several.

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 diffuse some of the criticism, you are talking about theoretical scenarios, vs. real world use cases. If you.

Manu Sporny: have numbers, that’s incredibly useful..

Joe Andrieu: Yes, I like that, thanks.

Kristina Yasuda: See List of 13 use-cases Japanese governments are funding on VC/DIDs:.

Kristina Yasuda: it’s in japanese, but I think browser translate feature should do a fairly good job.

Kristina Yasuda: the actual framing is “Trusted Web”, how a Japanese government expects to make Web more “trustworthy” without relying on the platforms..

Kristina Yasuda: but the technology expected is VC/DIDs.

Kristina Yasuda: 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).

Jay Kishigami: 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?.

Orie Steele: +1 to better language support in v2… we are very interested in that related to international supply chain documents..

Shigeya Suzuki: 1.42Mil USD (200mil JPY) on 13 projects. It’s announced last Tuesday..

Yan Zhang: From digital twin WG, there are some useful things there. Right now VC standard is useful, at least 6 different projects, two are 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 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.

Paul Dietrich: 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?.

Joe Andrieu: It was not intentional, would like more use cases for B2B, where work started, etc.

Orie Steele: See B2B Supply Chain uses cases.

Yan Zhang: 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.

Joe Andrieu: 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 talked a bit about evidence traceability. What about mobile/web integration, use cases that have that, and then accessibility – huge oversight.
… 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.

Orie Steele: +1 to accessibility overlap, there are some really awesome accessibility features you can build by cleverly interpreting machine readable semantics..

Ted Thibodeau Jr.: You said replace amend with reference… for documentation? amend is important.

Joe Andrieu: 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.

Kristina Yasuda: how do you amend a VC without breaking a signature? feels like update/reissue are more accurate.

Manu Sporny: i18n - we have a full i18n solution in VCs but I don’t think anyone’s used it.
… Shigeya has proposed an alternative solution that I think we’re talking about later.
… We have addressed i18n, but I don’t think it has resulted in internationalized creds.

Dave Longley: +1 to Orie’s VC status list example.

Orie Steele: 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, maybe revocation isn’t right way to think of that, you can have credentials with multiple statuses, entry point has to be updated frequently to associated/related reference has been updated. Just clarifying. The spec says we refer to things by id.

Joe Andrieu: that 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 the same thing – then we could talk about that sort of update.
… If we use a hash, can’t update.

Orie Steele: +1 to stable identifiers for several version of a credential..

Orie Steele: (the use case).

Joe Andrieu: +1 Orie.

Kristina Yasuda: there is a conversation on this topic in OpenID4VCI, raised by Tobias:

Kevin Dean: 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.

Kristina Yasuda: ie how does the wallet know two credentials are the same type, just “updated”.

Orie Steele: For the record we have this today related to “revocable” bills of lading / other supply chain oriented credentials..

Manu Sporny: 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.

Orie Steele: +1 to the separate immutable / content id use case..

Manu Sporny: 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.

Orie Steele: +1 to update being necessary for a number of privacy preserving extensions to VCs..

Yan Zhang: Regarding updating VCs, long conversation with ZK SNARKS, in cryptography domain, snarks are popular. 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.

Kevin Dean: 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, from point of manufacture to when its received.
… What is traceability, about provenance, traceability is about how it got here, what ingredient were used, when was it stored, who carried it, if it’s produce – was temperature maintained?.
… from carrier to distributor to retailer to store, traceability can tell you everything along the way. But 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.
… 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.
… 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?.
… For example, if they have serial number, sparse number, some condense is someone asking has seen this item.
… what about trading partner, trading partners might get this information. Retailer, what if I want to ensure chain was maintained?.
… Then there are regulators, they make the rules, they can see whatever they want.
… 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.
… Once it’s responded, whether it has data or not, how does it respond to query itself? Again, no response, filtered data, or no data – all the ways discovery service can respond depending on who you are and how sensitive the data is.

Samuel Smith: Another way of viewing traceablility is as a chain-of-custody of the data so one can provenance the data..

Samuel Smith: Supply chain manifests as they flow through customs are a common use case.

Samuel Smith: This is a prime reason ACDCs support chaining.

Kevin Dean: 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 let them have the data. Retailer, if I’m giving out data as distributor, I can give data out. Distributor has relationship with retailer, manufacturer might do end run around distributor and sell directly to retailer. One of many use cases where you might not to publish lots of data.

Kevin Dean: 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 ecosystem that identifies you as a trading partner.

Phil Archer: Our GS1 colleague Mark Harrison wrote a paper on End to End traceability using VCs:

Vittorio: This is an interesting scenario, in a number of relationships that you express, your token 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.

Kevin Dean: The answer is we don’t know that we do, maybe we submit the use case and maybe VCs are not a viable solution.

Dave Longley: VCs… distributing trust without having to distribute infrastructure.

Kevin Dean: We have been looking at these use cases and tech solutions 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, the nature 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 verification. The process for validating a trading partner, several different VC ecosystems, FDA certification, trading partner capabilities, four completely separate VC ecosystems each with rules, verification and validation rules defined by their respective ecosystems that can be used to prove things about a potential trading partner more rapidly than we could before..

Samuel Smith: Another way of described this “disconnected” 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 models.

Proposed resolution: We will update the Verifiable Credentials Use Cases, with Joe Andrieu and Kevin Dean as editors.. (Brent Zundel)

Brent Zundel: want to run a proposal.

Manu Sporny: +1.

Orie Steele: +1.

Shigeya Suzuki: +1.

Mahmoud Alkhraishi: +1.

Ted Thibodeau Jr.: +1.

Manu Sporny: +1.

Joe Andrieu: +1.

Dave Longley: +1.

Brent Zundel: +!.

Brent Zundel: +1.

Jay Kishigami: +1.

wonsuk: +1.

Kristina Yasuda: +1.

David Waite: +1.

Resolution #1: We will update the Verifiable Credentials Use Cases, with Joe Andrieu and Kevin Dean as editors..

Joe Andrieu: We welcome additional collaborators, if you have suggestions, lionel, reach out to us if you have use cases you want to have covered.

Shigeya Suzuki: 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).

Geunhyung Kim: Geun-Hyung_Kim has joined #vcwg.

7. Serializations and the Core Data Model.

Ivan Herman: See Slides on Google Doc.

Kristina Yasuda: trying to be careful and considerate as possible with my words, In VC data model v1 we have a data model, a serialization and proof sections, i.e. how do you sign those credentials.
… 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.
… either you have a valid @context or you do not, in which case you use out of band mechanisms to understand the claims.
… in 1.1 all these components were in 1 document. The serialization might not have been explicit but it is there.

Orie Steele: disagree with the framing of this… does not represent consensus on v2 (wrt the data model / serialization side)… the securing side seems accurate..

Kristina Yasuda: 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.
… what i really want to bring up is the SD-JWT use case, a json format that allows selective disclosure without advanced crypto, theres JWP, CBOR, ACDC, and others. Where do these sit?.

Orie Steele: This slide mixes security and serialization incorrectly imo..

Kristina Yasuda: 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 representations, or do we want to say ONLY JSON-LD is the appropriate serialization.
… 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?.

Ted Thibodeau Jr.: Did we not already decide that serialization was an open extensibility point? by means of the abstract data model?.

Kristina Yasuda: this is one of the framing that we have been discussing as chairs.

Ted Thibodeau Jr.: 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?.

Manu Sporny: 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.

Orie Steele: My slides also address this… but there are parts of the framing Kristina presented which I do agree with..

Manu Sporny: Question 1: Do we want to represent VCs in a variety of different syntaxes? I think yes.
… Possible second question: Do we want to create a new abstract data model for VCs? big -1 on that.
… 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.

Ted Thibodeau Jr.: so instead of forcing translation thru an abstract data model, we force translation thru a physical data model?.

Dave Longley: 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..

Manu Sporny: 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.
… I suggest we push it out to security layer.

Orie Steele: 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 flaws in how we defined proof types in 1.1, my primary mission is fixing those flaws while preserving the data model features in 1.1.
… 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].
… like manu mentioned for JSON-LD to CBOR-LD there is a path, but that may not be the only binary path people are interested in, i do not believe it is a wise choice to start tackling this serialization complexity now, its a question of prioritization. I am worried about adding too much scope.
… I think we can make improvements on the spec from 1.1 to 1.2 that are valuable before we tackle the harder bits.

Manu Sporny: 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.
… second most useless*.

Justin Richer: second most useless.

Kristina Yasuda:

Manu Sporny: I think we need to look at that section to see if it is buying us anything.

Justin Richer: The most useless is extensions may allow, prohibit etc, this is a close second.

Kristina Yasuda: If no other comments moving forward to Orie’s Presentation.

Mahmoud Alkhraishi: See Orie’s slides.

Orie Steele: Hope my snarky attitude translates remotely.
… 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.
… they will take a while, i suggest we get the lay of the land then begin solutioning.
… On the right hand side, you will see some version of GPT-3 of a true scotsman on an envelope.
… this speaks to the core data model and the branding problem associated with it! I hope the directness doesn’t come in any way offensive.
… 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.
… one of them is semantics and graph theory, and the question ends up how many of this is related to browsers etc?.
… 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?.
… what is the relationship between w3c values and the communities we’re a part of? is semantic web dead?.
… Ive seen privacy and accessibility considerations as a big consideration that is unique to W3C.
… 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.
… one of the questions is: What are we defining? whats to define here? its a question of Decentralization.
… 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?.
… 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 and have JOSE, we have CBOR and COSE. Why are we here?.
… 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.

Ivan Herman: 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.
… 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.
… these days it is not fashionable to say that, but if you look at knowledge what graphs do, some people have to acknowledge that it was greatly influenced by the 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.
… I want to push back on using the word “semantic”, I do not think we are interested in that.

Samuel Smith: 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].
… 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.
… 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 I talk about ACDC.

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.
… that ability is far more valuable to get the data from multiple different sources.

Antony 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.
… they have their own data model, defined at IETF. We should not have to tie them to the VC model.

Samuel Smith: 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..

Samuel Smith: 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..

Orie Steele: JSON CBOR, JSON LD, there are many data models that have value and adoption.
… 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.
… 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.
… I am very much in favour of these graph structures, I love these things, in particular applying these technologies to supply chains, traceability etc.

Samuel Smith: +1 @mkraisha.

Ted Thibodeau Jr.: 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..

Orie Steele: You should hold me accountable to my bias.
… 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 extraneous information.

Kristina Yasuda: if we don’t we should probably have a placeholder issue to revisit non-normative sections in the data model document…

Orie Steele: 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).

Samuel Smith: RDF does not support weighted edges this is why I cannot use it..

Charles Lehner: SamSmith, maybe RDF-star could support weighted edges?.

Orie Steele: I understand there will be disagreements on the framing of previous slide. lets focus on that before we focus on securing it.
… there are parts that already start to create real trouble for us as a group: a few ideas are:.
… 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.

Joe Andrieu: +1 for clear layers.

Orie Steele: I think clean layers are what we need, the blurry edges create lots of risk the VC-JWT in particular I’m worried about that edge.

Samuel Smith: +1 for clear layers.

Kristina Yasuda: +1 I agree that in the slides these components are clearly separated, but in v1.1 they are not that clearly separately defined.

Orie Steele: Second blurred line area: Content Type pieces.
… 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.
… 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.
… 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.
… this is an area we can easily run into issues that snowball.

Ivan Herman: 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. Context is 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.

Orie Steele: 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.

Samuel Smith: 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..

Gabe Cohen: JSON-LD has been used out of necessity, and JSON Schema can be used instead, and wasn’t because it wasn’t defined properly.

Orie Steele: 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.

Manu Sporny: 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.
… I want to understand where the conversation is going.

Orie Steele: I’m not here to tell the WG what to do, im here to make everyone feel where we are.

Ted Thibodeau Jr.: 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.
… if we cannot understand the tools we are trying to work with we cannot clarify it for anyone else. For example there are 6 media types one of which is legal i believe.
… that makes it impossible to discuss.
… 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.

Orie Steele: 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.
… 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.
… we have to do this in the CORE DID model because of the translations we have to do.
… 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?.
… this was a core point of concern from the DID objectors.
… please read the private claim names in the associated IETF specs, and asking what is the relationship between them and our work.

Kristina Yasuda: private claim names:

Kristina Yasuda: (I think..).

Orie Steele: this is one interpretation of taking the did core route. which should align with kristina’s slide.
… 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.
… want to hear from folks who think infra went really well or not so well.

Justin Richer: 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.
… 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.
… 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 strictly, the http header spec gives us a very good example of a very good serialization and very good parsing language.
… 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.
… 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.
… 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.

Samuel Smith: +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.
… I think members of the industry have adopted tooling that is core to their business, if we cannot accommodate the major tooling sets, to get something that has interop across the industry we will run into the serialization wars.
… notably we do not have XML. We need to have enough flexibility to have serialization to reflect the major tooling stacks in the industry.
… 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.

Justin Richer: +1 the data model needs to go strictly in and out of these major stacks.

Justin Richer: new serializations have to follow the same path.

Justin Richer: manu: weren’t you the one who campaigned for us to use infra?.

Manu Sporny: 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].
@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.
… 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?.
… that is my concern because it backfired on us in did core and fairly certain it will backfire here.

Joe Andrieu: I want to endorfe everything manu just said, i don’t understand why the abstract data model was even considered.

Charles Lehner: e/endorse/endorse/.

Joe Andrieu: the abstract data model is innately untestable, all we can test is serializations.

Orie Steele: 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.
… 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.

Michael Prorock: +1 Orie.

Orie Steele: I echo the words to the group, but i think its very different from did core.

Manu Sporny: +1 orie.

Mahmoud Alkhraishi: +1 Orie.

Gabe Cohen: +1.

Dave Longley: +1 to Orie.

Michael Jones: 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.
… at least 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.
… if they are informed by a common prescription of what the normal fields are that should appear in the representations, but that is not testable.

Justin Richer: so a model … for the data … that is abstracted …. 🤔.

Gabe Cohen: +1 reduce optionality.

Manu Sporny: 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.

Michael Prorock: I am not opposed to going JSON-LD only.

Kristina Yasuda: 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..

Joe Andrieu: +1 to reduced optionality (especially at the “envelope” layer, that of the credential, without constraining the claims).

Gabe Cohen: +1 Kristina.

Manu Sporny: 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.
… 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.

Michael Jones: 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.
… likewise if you want global interop, you need to have it written down, thats just practical engineering.

Orie Steele: Where do we feel like we should open the aperture and where do we feel like we shouldn’t?.

Samuel Smith: q.

Orie Steele: 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.
… 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.

Samuel Smith: Property Graphs are a superset of RDF graphs. It seems to me that expanding the core Data Model to include property graphs solves the problem. Its the right amount of flexibility and if forward looking.

Orie Steele: Some of these have come up during our WG charter process, for example dizzy/anoncreds/ACDC.
… I recognize this a recommendation and is in contradiction to positions folks have taken on the call. I think this is the safest path forward to protect the value of the existing standard.
… and protect security formats and focus on improving them.

Mahmoud Alkhraishi: +1 to what orie is saying.

Orie Steele: I think we should open up the lower box, without the top one, without endangering the primary mission.

Dave Longley: +1 to Orie, leave alone / clean up data model (very small changes), focus elsewhere for larger changes.

Orie Steele: 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.

Michael Prorock: +1 orie.

Orie Steele: 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.

Orie Steele: these are open PRs for several repos i would like people to review.

Brent Zundel: we have 30 mins and a concrete proposal.

Kristina Yasuda: I think the proposal is the data model is RDF JSON-LD and minimal changes will occur there, with most of our focus to be on securing the model.

Samuel Smith: 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.
… RDF is a subset of a property graph, if this proposal said this will do a property graph.

Kristina Yasuda: so no enabling additional “serializations” but that extensibility handled in the securing documents (not happy with the wording but one way to put it..).

Ivan Herman: 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.
… 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.

Orie Steele: There are beginning of standardization on the graph query languages, such as Cypher though….

Orie Steele: 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..

Michael Prorock: +1 Ivan !!!!.

Dave Longley: +1 to Ivan.

Dave Longley: +1 – sounds like we can get support for what Sam wants in due time, whilst still using standards today.

Ivan Herman: See RDF-Star WG charter.

Ivan Herman: See “RDF-star and SPARQL-star” (Community Group Report, input to the WG).

Samuel Smith: +1 to contextual vocabularies.

Joe Andrieu: 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.

Michael Prorock: 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 key-pair 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.
… without taking away the focus on security aspects that we must ensure are fully addressed.

Manu Sporny: 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.

Michael Prorock: +1 Manu - I think setting ourselves down a testable path, without requiring hard overheads for payloads.

Dave Longley: +1 to using a “profile” of JSON-LD to reduce optionality and make things simpler..

Brent Zundel: +1 to JSON compatible.

Joe Andrieu: +1 to json-compatible JSON-LD.

Kristina Yasuda: +1 manu.

Manu Sporny: 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.

Justin Richer: -1 because if we are claiming JSON-LD is the extensibility model then we can’t pretend it’s not JSON-LD.

Orie Steele: my favorite way to secure JSON-LD, is using JOSE / COSE…. specifically using JWS / CWS..

Dave Longley: justin_r: we should not pretend it’s not JSON-LD ….

Manu Sporny: 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.

Dave Longley: we should say it’s JSON-LD … but a specific profile of that that is particularly JSON friendly..

Justin Richer: dlongley: I’m fine with that tbh, but then we shouldn’t claim it’s a “data model”.

Dave Longley: justin_r: yes, it’s an RDF data model with a constrained JSON-LD serialization.

Orie Steele: +1 manu.

Michael Prorock: +1 manu.

Michael Jones: 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.

Orie Steele: For the record, GitHub signs commits incorrect with respect to PGP… that doesn’t mean we say thats ok by changing the OpenPGP spec..

Michael Jones: 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.
… trying to require RDF, while an attempt to unify things will end up dividing people.

Samuel Smith: 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.

Dave Longley: …but you need a standard serialization for it that is popular and easy enough to use.

Samuel Smith: 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.
… why are we constraining this, other than considerations to tooling?.

Orie Steele: If people can’t get RDF/JSON-LD correctly… whats the chance they do LPGs (a super set) correctly?.

Orie Steele: I think David is agreeing with me that we need to fix VC-JWT : ).

David Waite: 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?.

Samuel Smith: @ORIE LPG are easier to get right than triples.

Orie Steele: SamSmith, show me a standard for them that’s better defined that’s RDF.

Orie Steele: I’m a huge fan of Neo4J / LPGs / Cypher btw,.

Manu Sporny: wanted to 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.

Michael Prorock: +1 dlongley.

Manu Sporny: 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.

Orie Steele: +1 to stoping calling everything a VC.

Dave Longley: +1 to Orie.

Michael Prorock: 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.
… 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.

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?.

Orie Steele: 50% chance your GS1 license is not expired phil ; )

Michael Prorock: Lol.

Dave Longley: again, this weighting sounds like a great 3.0 feature to consider.

Orie Steele: I’m still a fan of LPGs tho…

David Waite: you can attach multiple weights to the different claims, because you can attach different weightings to different pieces of evidence.

Ted Thibodeau Jr.: +1. “I believe this to a 70% certainty” is a valid thing to verifiably assert.

Michael Prorock: We can use vocab and schema to easily attach probability to values.

David Chadwick: 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 expiry time. we have a lack of clarity between what has to do with the proofing and what has to do with the crypto.

Orie Steele: +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..

David Chadwick: 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.

Samuel Smith: q.

Orie Steele: btw, I am also in favor of using @vocab to create explicit support for. “create claims” in the VCDM 2.0..

Joe Andrieu: 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.

Dave Longley: +1 needing more effort for a shared understanding vs. private modeling of “whatever” :).

Joe Andrieu: 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.

Antony 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.

Joe Andrieu: FWIW, here’s the LER Wrapper I mentioned:

Orie Steele: nadalin 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?.

Samuel Smith: 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 to 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.

Michael Prorock: That is what vocabularies give you.

Samuel Smith: 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.

Kevin Dean: +1 to Sam’s statement about RDF vs graphs.

Samuel Smith: 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.

Orie Steele: 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..

Gabe Cohen: strawpoll?.

Brent Zundel: 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?.

Orie Steele: Lets poll to measure.

Michael Prorock: JSON Compatible JSON-LD for the envelope / core data model - focus on the security model.

Kristina Yasuda: 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.
… do people agree with that framing?.

Michael Prorock: +1 dlongley.

Dave Longley: +1 to mprorock’s framing of one of the options (plus with a focus on helping JSON devs however we can) (unemoting this).

Brent Zundel: some calls for polling, i’ll frame the question and throw it in the chat.

Manu Sporny: +1 on mprorock’s and kristina’s formulation.

Ivan Herman: 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.
… 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 possibility of 2.5, 3 or whatever version which will bring in the features later on.
… I think throwing away everything would be an enormous waste, and an enormous amount of energy, and waiting for RDF-Star is much cheaper.

Dave Longley: +1 to Ivan.

Orie Steele: 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..

Kristina Yasuda: I do not see enough support for property graphs for v2.0 at least among current participants, and hear sentiment maybe v3.0.

Orie Steele: +1 ivan.

Dave Longley: plus – we get some incubation period to get that right in between.

Michael Prorock: +1 ivan.

Michael Prorock: Happy to make sure a draft gets incubated if folks want to work on it in CCG.

Phil Archer: +1 to ivan.

Kristina Yasuda: I do not hear lots of support for property graphs for 2.0. Please open an issue.

Brent Zundel: +1/-1 poll.

Brent Zundel: Strawpoll: The core data model should be written in JSON-compatible JSON-LD.

Samuel Smith: 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.

Kevin Dean: +1.

Orie Steele: +1.

David Chadwick: +1.

Manu Sporny: +1.

Joe Andrieu: +1.

Michael Prorock: +1.

Sebastian Elfors: +1.

Ivan Herman: +1.

Steve McCown: +1.

Shigeya Suzuki: +1.

Justin Richer: -1 that statement is meaningless.

Mahmoud Alkhraishi: +1.

Charles Lehner: +1 (as observer, not representing any organization).

Phil Archer: +1.

David Waite: -1.

David Ezell: +1.

Dave Longley: +1.

Ted Thibodeau Jr.: JSON-LD is JSON compatible..

Gabe Cohen: -1.

Oliver Terbu: 0.

Samuel Smith: -1.

Hiroyuki Sano: 0.

Justin Richer: @tallted only if you close your eyes …..

Dave Longley: to me… that means an RDF data model that will be serialized to a specific profile of JSON-LD.

Dave Longley: that is very JSON friendly (in a variety of ways).

Michael Jones: -1.

Ted Thibodeau Jr.: 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 standards, W3C work is toward standards. This is not the path of property graphs to the degree i have experienced to this date.

Manu Sporny: 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”.

Michael Prorock: +1 manu.

Dave Longley: (a JSON-idiomatic profile of JSON-LD).

Manu Sporny: +1 to above.

Michael Prorock: +1 ted.

Ted Thibodeau Jr.: 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.

Orie Steele: +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..

Ivan Herman: +1 to Ted.

Joe Andrieu: The question is backing away from Infra is not the issue, I heard a concern about starting from scratch.

Samuel Smith: 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.

Kristina Yasuda: I think… we agree we want to make it easier for the developers for whom JSON-LD is a heavy lift…

Joe Andrieu: me error. INFRA was the DID thing. My comment can be dismissed.

Brent Zundel: thank you for a good session, we got pretty close to concensus on that strawpoll there, i think we have a path to censensus.

Orie Steele: SamSmith re LPGs and VCs and RDF…

Ted Thibodeau Jr.: 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.

Samuel Smith: in ACDC.

Samuel Smith: Which is just JSON and JSON Schema.

8. Joint Session With the APA WG.

Kristina Yasuda: Calls the meeting to order.

Kristina Yasuda:

Kristina Yasuda: Welcomes members from APA (Accessible Platform Applications WG).
… looking forward to hearing use cases.

Matthew Atkinson: Matthew Atkinson.

Paul Grenier: Paul Grenier (apa member and chair of spoken pronunciation).

David Fazio: David Fazio - Fazio.

Matthew Atkinson: I’m a co-chair of the WG.
… we can lead you to the use cases doc we have.

Lionel Wolberger: Representing APA: Janina Sajka, Matthew Atkinson, Lionel Wolberger, Scott Hollier.

Matthew Atkinson: and we have a couple of specific things to talk about.

Matthew Atkinson: APA’s agenda: [](

Janina Sajka: We have a specific question.
… long standing problem with captures. Were hoping your tech will help get rid of Captchas.
… then we have the more general topic to discuss.
… at least on a conceptual basis.

David Fazio: Accessible Authentication - Web Content Accessibility Guidelines 2.2 Success Criteria.

Janina Sajka: Might be be able to associate user with preferences (font size etc).
… that can operate across devices.
… resurrects idea from 1995 when we thought CSS would do it for us, but user overrides have not succeeded.
… and even if they had, it would not be cross-device.
… that’s why we think VCs might help - think of them as config files.
… But I want to start with the captcha question.
… Everyone’s looking forward to passwordless login.

David Fazio: A11y guidelines talk about success criteria.
… one of them is accessible authn - read “Captcha killer”.

Ted Thibodeau Jr.: 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 True 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)..

Lionel Wolberger: See The Captcha paper.

David Fazio: Problems of security that don’t require cognitive tests.

Lionel Wolberger: I’m sharing my screen.
… see Turingtest link.
… Sets out the current problem.
… the alternatives, like audio, are no better.

Janina Sajka: Speech recognition is now too good. Solving audio Captchas is no longer an effective check.
… ASR systems can solve them.

nms01: +1 phila.

Lionel Wolberger: Looking at alternatives for a persistent Turing test.
… ‘CAP’ has a working prototype.
… A recent sharp uptake of FIDO by Apple, we’re excited about that also.
… Smartphones are ubiquitous. The biometric function is v helpful.
… So… VCWG… do you have any thoughts.

Jem: Accessibility Guidlines Github issues regarding accessible authentification:

Manu Sporny: Welcome. Thanks for joining us.

Kristina Yasuda: ah ok, thank you!.

Kristina Yasuda: is there a pointer to VC use-cases document you have worked on?.

Kristina Yasuda: or is it the same one?.

Manu Sporny: 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.
… cf. a single hardware device.
… The concept of passing a Turing test and getting a bunch of tokens resonates.
… The digital age verification systsm in the US, you have to turn up physically somewhere like a convenience store.
… You have to show up in person to activate your token and the tokens that come from that. That’s actually a Turning test.
… The tech can suppport these use cases but what we are lacking is how does the individual a11y needs use that.
… When it comes to presenting that at a website, we’re lacking a11y interfaces that we’re using.

Manu Sporny: so we need help from you in defining the interfaces.

Janina Sajka: We know we need to look at interfaces. We’re a horizontal review group and ‘interface’ is a trigger word.

Lionel Wolberger: That was a helpful manu, we face a broader challenge of wallets in general.
… in W3C, I hear you’re involved in blockchains.
… this s a type of wallet.

Gregg Kellogg: This is not specifically about captcha … VCs are mainly a data model but they’re intended for presentation.
… so I wonder whether the VCWG has thought about presentation and esp a11y.

Manu Sporny: 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”.
… This is all going to come to the fore when we talk about presentation.
… 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.

Orie Steele: +1 to voluntary exploration of accessibility.

Manu Sporny: I don’t know how structure that work other than requesting help from you when it comes up.

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.
… and look at that issue.

Ivan Herman: 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.
… What you just described as a kind of future looking comment… for later… that would be useful.
… But to set expectation, we’re not working on presentation.

Janina Sajka: We’re not expecting something in 6 months.
… Are you looking at cross-federated environments?.
… Is your current scope including - eg. - devices from multiple environments, say between an Android phone and a Mac laptop.
… It could be that one take away today is that we need to look at digital wallet usability.

Lionel Wolberger: We also produce docs that are user requirements.

Kristina Yasuda: our charter:

Kristina Yasuda: we can non-normatively talk about APIs/protocols, but cannot write normative documents on that topic.

Manu Sporny: yes, huge +1 for digital wallet accessibility requirements!.

Orie Steele: +1.

Scott Hollier: I agree.

Shigeya Suzuki: +1.

Scott Hollier: We try to look at each area and see what the potential user requirements are.

Matthew Atkinson: Example Accessibility User Requirements doc - this one is about XR:

Lionel Wolberger: That might be how we engage.

Janina Sajka: It would point in the direction of a next charter.
… we would look at the presentation layer and give you points to think about.

Scott Hollier: I agree, we could look at that.

Lionel Wolberger: We have thoroughly documented used case.
… The task force will take up a11y usability requirements for digital wallets.

Orie Steele: Thanks for coming and participating today. 2 points to raise.
… First, based on the VC data model, one thing I’ve been exploring, taking advantgae of the structure.
… an arbitrarily complex VC might be difficult to perceive. is there a preferred order of nodes in the graph.
… or maybe giving the user just what they need.
… it’s a graph traversal issue.
… great opportunities to create experiences to traverse the graph.
… I’ve done a little exploration but a11y and UX for VCs are issues for us to explore.
… audio-visual experiences from the graph would be exciting.
… Second - maybe a use case for extensions like ad blockers that change experiences on web pages.
… We could take these user pref credentials and apply them in presentation.
… I’d be excited to explore a prototype this, as a personal interest in this space.

Lionel Wolberger: Short response - we’re always interested in alternative forms of data consumption. Graph traversal would be an interesting.

Matthew Atkinson: RQTF use cases for VC (feedback welcome):

Janina Sajka: 60 million people in the US have ‘a disability’ but there are 60 million different disabilities [scribe paraphrase].

Kristina Yasuda: I think a brief overview of the use cases doc would be a good use of limited time.

Paul Grenier: 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.
… this will be useful to look at s.
… Looking at the charter, section 2.4, there’s a lot there that have a11y issues.
… the data model itself we can handwave over.

Manu Sporny: Huge +1 to accessible digital wallet. The time to do that is now.

Orie Steele: +1 Manu.

Manu Sporny: 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.

Manu Sporny: Rendering verfiable Credential:

Manu Sporny: ‘rendering VCs’ work.
… there will be some work done at RWOT, including visual and audio rendering.
… are there ways of creating human prose about the VC.
… and it is targeted at meeting a11y needs.
… so a VC can be rendered in different ways.
… That’s something we’d like to get input on.

Orie Steele: 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..

Manu Sporny: Finally, today there are wallet engagement mechanisms that are dependent at taking out your phone and pointing it at something.
… is that an a11y challenge - scanning a QR code?.

Janina Sajka: I think they’re successful more often than not, but you should explore the not.

scott: Finding QR codes to start with can be a challenge.

David Fazio: I know McDonalds were working on something like Monopoly that can be played without vision.

Scott Hollier: I also saw in Australia, guidance on how to get your phone in the right place.

David Fazio: My Bank of America app when I go to scan a cheque, it guides the user to move closer, further away etc.

Orie Steele: Related to “recognizing unreadable text identifiers”, there is also … this is relevant to “issuer” / “holder” identifiers..

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.
… Orie said he had some insights into addrsssing CSS persistence through a browser extension. I’d love to hear more about that.

Orie Steele: 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.
… 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?.
… and discern a disability.
… If you look at the extension ecosystem there might be something to help build use cases.

Janina Sajka: This also might be a way toward accessible wallets.
… People do tend to have devices from multiple manufacturers.

Orie Steele: Password managers are typically sync’d across devices.

Phil Archer: I have multiple interests here. The applicability of QR codes is important to me.
… what about NFC? The capacity varies. There are alternatives to QR. And better barcodes.
… Multiple interests here, interested 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.
… that thing that goes beep at the border gate is not a QR code.

Lionel Wolberger: I’m not sure we know about NFCs.

David Fazio: I’d be concerned about privacy with NFC.
… I’m worried about credit cards being used outside the wallet.

Sebastian Elfors: We had a discussion in the FIDO alliance about VCs. We concluded the Hyperledger approach was interesting.
… could be super-interesting for a11y.

Orie Steele: I can say that webNFC and web bluetooth are not well supported outside of chrome…

Phil Archer: [scribe missed some of that, sorry].

Kristina Yasuda: You mentioned Wallet Security WG in DIF, W3C universal wallet… please add URLs to IRC.

Orie Steele: There are several wallet initiatives. … a series of interaction protocols, openID Connect, DIDComm (popular on Hyperledge Aries).
… There have been conversations about Web NFC and wallets. What’s the a11y angle. Outside native apps, those protocols can be less universally available.

Orie Steele: covers some wallet comms protocols.

Lionel Wolberger: We wanted to talk about the human care taker scenario … very often a diabled person is in that situation.

Orie Steele:

Janina Sajka: 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.

Orie Steele: another link, to keep an eye on:

Sebastian Elfors: Here are the mentioned iniatives for wallet backup/restore:.

Janina Sajka: 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 electronic version would be v good.

Sebastian Elfors: W3C Universal Wallet:

Sebastian Elfors: DIF Wallet Security:

Sebastian Elfors: Hyperledger Indy Wallet:

Sebastian Elfors: And here’s Orie’s issue for specifying backup/recovery for the W3C Universal Wallet:

Yan Zhang: A11Y is v important. we talk about it internally a lot. The VC should be stored locally.

Orie Steele: 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..

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 association.
… we’d love to see it working.

Yan Zhang: 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.

Manu Sporny: We’re beyond PoC stage in many ways. There are companies here deploying this tech in real world (cites immigration services digital residency card).
… in the next couple of years. That whole flow is applicable to that uze case you just outlines.

Orie Steele: If you are creating accessibility related credentials, you can consider:

Manu Sporny: What we’re lacking is the organisation to issue the creds.
… You could hope for a rapid turn around.
… The caretaker/delegate use case. A child travelling with someone other than their parents, people who have any kind of caretaker needs.
… what we’re misisng is someone to speak with authority in what those VCs should look like to have legal weight.
… we’re missing subject matter experts tbh.

Ted Thibodeau Jr.: Need lots of lawyers for that. At least one per jurisdiction..

Matthew Atkinson: Reminder of RQTF’s use cases:

Janina Sajka: I think we’ll take to Wendy Seltzer.

Kristina Yasuda: we’re at time.

Orie Steele: There is a project in Austin Texas, regarding “helper” / “care taker” use cases for persons experiencing homelessness -

Orie Steele: some of our team members worked on this..

Kristina Yasuda: 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).
… I think these are OOS for now.

Geunhyung Kim: Geun-Hyung_Kim has joined #vcwg.

Kristina Yasuda: Maybe different people are implementing different presentations. Now we know a doc is coming up, that’s going to help a lot.
… Chair hat on. Thanks very much for coming.

Lionel Wolberger: Thanks for having us.

9. Streamlining Data Integrity.

Manu Sporny: Slides of talk:

Manu Sporny: This is around potentially major changes that we need to make in data integrity to address some of the challenges we’ve hit in recent years.
… this is an attempt to be responsive to the community.
… aim to do so befre going to FPWD.
… Slides shows 3 topics to cover in the presentation.
… The problem statement.
… crypto suite proliferation.
… What we ended up saying way back was putting all the cyprto suites in the VC, we moved on quickly.

Manu Sporny: people said what about my crypto context.
… Here we are many years later and people have had to take a different path.
… Started putting all the cryptosuites in the one context. people complained, and put them in discrete contexts on top of the VC context.
… Whenever you need to use a specific type of crypto, you create your own context, include it at the top and you’re fine.
… no dependencies on others.
… What this created was a new concern. So many crypto suite contexts, lost “just use the baseline context”.

Ivan Herman: This is not only a context file, it’s a separate vocab, separate namespace and voc.

Manu Sporny: In practice they all share the same vocab.
… each context file just picks and chooses out of that vocab.
… typically shares the same vocab but uses a different context. That’s today.
… 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 crypto-suite.
… Potential solution.

Orie Steele: Without a @vocab in v2: "@context": [ "", {"@vocab": ""}],.

Manu Sporny: How can we use effectively the v1 context as is but use the crypto suites people want.

Orie Steele: with @vocab in v2 "@context": [""],.

Manu Sporny: 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.
… specifies crypto type as a string.
… This is backwards compatible.
… nothing breaks.
… But there may be a subset of us who are keen to move on.
… [Shows solution example].
… includes a v2 context. Defines the dataIntegrityProof type.
… then specifies crypto suite as a string.

  "@context": [.
  "id": "",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "proof": {.
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-2022", <-- this is now a string value
    "created": "2022-02-25T14:58:42Z",
    "verificationMethod": "",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3FXQjecWufY46…UAUL5n2Brbx"

Manu Sporny: The V2 context would then cover the majority of VCs. No more proliferation of contexts.
… if you need something more complex, the you can still do that.
… 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.”.

Sebastian Elfors: How about post-quantum cryptos?.

Manu Sporny: Many devs have no knowledge of the differences between options. Should we just be specifying what’s safe/recommended for 2022, 2023 etc.
… Maybe we recommend options to make it easier.
… Those are just ideas, but show that this V2 context file can cover all these.

Kristina Yasuda: sebastianelfors q+ to talk about post-quantum cryptos..

Gregg Kellogg: Have you considered URIs instead of strings.

Joe Andrieu: This in part doesn’t seem to use the traditional JSON-LD disambiguation mechanism. Who controls the string for each cryptosuite?

Orie Steele: A registry use case!.

Manu Sporny: Don’t know. We will specify strings.

Phil Archer: I had the same idea Orie.

Orie Steele: centrally managed registry… just like IANA :).

Joe Andrieu: We’re allowing potentially ambiguous strings to be functional.

Manu Sporny: That stops proliferation.

Kristina Yasuda: “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..?

Joe Andrieu: No it doesn’t. There’s no look up.

Brent Zundel: Chair hat off. Sounds like a reason for a registry…
… Why would data integrity proof be described in the V2 context rather than it’s own data integrity context.

Manu Sporny: 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.
… This really is a bunch of engineering trade offs.

Sebastian Elfors: Computer security resource centre, currently doing work on post-quantum. Should we take post-quantum into account?.

Manu Sporny: Yes, we have to consider post-quantum.
… Whatever solution we have has to take account of post-q.

Gregg Kellogg: Why strings, not URIs?.
… They can be used the same way but a URI has the potential to describe itself.
… and can be used to verify.

Sebastian Elfors: Here’s NIST CSRC program for post-quantum cryptos:

Manu Sporny: we could use a URI in here, but it might be fairly long which has consequences for things like Qr codes.

Orie Steele:

Michael Prorock: We know there has to be crypto agility. We had a call with some relevant experts. We shouldn’t be defining cryptography here.

Orie Steele: +1 mprorock, I’m q’d to talk about overlap with VC-JWT / JsonWebSignature..

Michael Prorock: 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.
… it would be great to hear from people with experience.

Ivan Herman: 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.
… This change I think is a big improvement in usability.
… But I think we won’t avoid having some sort of registry for these things.

Orie Steele: 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..

Orie Steele: +1 Ivan.

Ivan Herman: And to Brent - don’t mix up the context and the vocabularies.

Michael Prorock: +1 ivan.

Dave Longley: These solutions are responsive to developers.
… We talked about that earlier (JSON-compatible JSON-LD etc).
… The number of useful crytpo suites is much smaller than the number of VCs in the wild.
… So it scales.

Tobias Looker: Support in general for this. Makes it more manageable. Certainly experienced multiple context files being a problem for customers.
… 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.

Phil Archer: [orie talked about explain JsonWebSignature2020 and COSE WG Post Quantum Signatures].

Orie Steele: 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 context file that covers what we need for V2.

Michael Jones: Why not just have a context for a cryptosuite that is extensible, logical, no registry to maintain.
… that seems the logical option to me.

Pierre-Antoine Champin: 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.
… even without that, there are solutions in JSON-LD where those short strings can be made into IRIs.

Joe Andrieu: I appreciate what selfissued just said. I think a single context file is not an extensibility model.
… we have to understand the context and we have to accept a potentially ambiguous string. Doesn’t sound right to me.

Manu Sporny: In response to selfissued why not just use a different cryptosuite? Bc people complained.
… Devs seemed to be fine with creating a context for different use cases. But when you include the crypto suite, they start to complain.

Orie Steele: it would be better to just add this to v2: "@vocab": "".

Orie Steele: or this: "@vocab": "".

Orie Steele: but the point is well taken, you could use the vocab to point to a w3c registry that disambiguated..

Manu Sporny: It’s arguable that we’re using the model in this specific way. Are the trade offs worth it?? Fallback is to carry on doing what we’re doing today but we know people complain about it.

Michael Prorock: I was going to ask - what would JOSE do?.
… Why don’t we just define semantics for JOSE kty, alg, etc.. What’s the additional complexity we need above what JWTs etc.
… I want to attach signatures, but are we going too far and creating additional probs for ourselves.

Orie Steele: manu, vc-jwt doesn’t DO tranformations ; ).

Steve McCown: I like this proposal. Whether the format is right I’m not sure. I chair the DIDComm WG (?) There are 3 acceptable crypto options for post quantum (in hte US).
… there’s always going to be multiple signatures needed.
… 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.

Dave Longley: To respond to Mike. JOSE is great at expressing every option.
… What it doesn’t do is provide a layer that describes a set of layers that are safe to use.

David Waite: best mic of TPAC so far.

Dave Longley: Might include things like c14n algorithms etc.

Joe Andrieu: sounds like a good use of a context for each of those well-formed cryptosuites.

Dave Longley: being able to define these profiles is very useful.

Manu Sporny: 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.

Orie Steele: Thats correct Manu, but specific to Data Integrity..

Orie Steele: +1 to a new registry for “new parameters”..

Manu Sporny: [gives example]. There are params that are needed that don’t go into these crypto suites.

Joe Andrieu: -1 to new registries.

Michael Prorock: Can we keep this simpler, maybe with registries, think about the dev process.

Orie Steele: I can’t wait to see “ProofOfWorkFreeRevocationList2022”.

Dave Longley: you don’t want software to automatically allow any combination of parameters – so you need a name (aka cryptosuite) underwhich to bind them all..

Michael Prorock: 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”.

Michael Jones: Responding to dlongley - I don’t agree that JOSE allows all the choices. It only allows things that we think make sense.
… being able to use bad combinations is not good [paraphrase].

Kristina Yasuda: I think the group agrees with the problem statement an the need to solve it.
… Some divergence on registries.

Orie Steele: +1 manu.

Phil Archer: [Discussion about what the straw poll will be about].

Michael Prorock: Going to clarify: I want JSON-LD, I want an array of signatures, I also want those sigs described and pointed at iana.

Joe Andrieu: I’m not sure what you mean by the problem statement?.

Kristina Yasuda: The problem slide that Manu showed.

Joe Andrieu: 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.

Kristina Yasuda: OK, we’ll start there.

strawpoll: Is the proliferation of cryptosuites a problem for data integrity.

Manu Sporny: +1.

Mahmoud Alkhraishi: +1.

Joe Andrieu: -1.

Michael Prorock: +1.

Orie Steele: +1 (yes it is).

Dave Longley: +1.

Tobias Looker: +1.

Ivan Herman: +1.

Gabe Cohen: +1.

Steve McCown: +1.

Shigeya Suzuki: +1.

Phil Archer: +1.

Joe Andrieu: what about the quantum!?!.

Charles Lehner: -0.25.

Michael Jones: -1.

Antony Nadalin: -1.

Ted Thibodeau Jr.: +1 (it does and will cause confusion in the user spheres).

David Waite: -1.

Dave Longley: (the ergonomics of implementing them is more challenging than it needs to be, it’s not necessarily that there are “too many”).

Ted Thibodeau Jr.: (…we’re gonna need a crypto suite rubric…).

Kristina Yasuda: WG should define a base Data Integrity Proof type.

Manu Sporny: +1.

Ivan Herman: +1.

Tobias Looker: +1.

Michael Prorock: +1.

Dave Longley: +1.

Orie Steele: +1.

Mahmoud Alkhraishi: +1.

Steve McCown: +1.

Shigeya Suzuki: +1.

Charles Lehner: +0.9 (DRY principle - but appreciate extensibility).

Joe Andrieu: +0 (plus to the definition, - to Manu’s version).

Ted Thibodeau Jr.: _0.

David Waite: -q.

Gregg Kellogg: I’m guilty of writing specs that need registries.

Gregg Kellogg: Question is what group has the long term responsibility for maintaining the registry.

Orie Steele: great question!!!!!!.

Michael Prorock: Excellent question.

Gregg Kellogg: Not saying whether it’s a good or bad ide, just asking a question.

Kristina Yasuda: We have a session after the break about registries.

Orie Steele: +1 to the speaker..

Pierre-Antoine Champin: 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.

nms01: crypto suites in a standards specification is another form of registry.

Michael Prorock: +1.

Joe Andrieu: Whoever is creating this VC will identify the crypto.
… 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.

Charles Lehner: points to

Joe Andrieu: 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].

nms01: registries that enforce a policy aren’t registries, they are policy enforcement points.

Orie Steele: At the risk of blowing the registries conversation, it’s worth just checking in what are we talking about putting in a registry. There’s always the ability to build your own crypto suite.

Michael Prorock: +1 orie.

Orie Steele: 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.

Mahmoud Alkhraishi: +1.

Dave Longley: 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.
… You just don’t need massively decentralised extensibility. In the VC space it makes sense, but for crypto it’s a much smaller set.
… Need to choose a fit for purpose solution.

Ivan Herman: 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.

Orie Steele: +1 to ivan’s framing..

Dave Longley: +1 to Ivan.

Michael Prorock: +1 ivan.

Manu Sporny: +1 to Ivan.

Tobias Looker: 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.

Dave Longley: +1 to tplooker.

Tobias Looker: Crypto is a highly specialised industry. Should allow people to innovate - this proposal doesn’t stop that.

Dave Longley: +1 to getting “more secure by default”.

Michael Prorock: Violent agreement. You won’t be secure by default but we can work in that direction. Need to be careful of Not Invented Here.
… What put me off VCs at first is that some of this stuff had been solved before.
… 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.

Kristina Yasuda: Thanks everyone for the conversation.

Orie Steele: +1 mike, safe defaults..

Kristina Yasuda: We have good agreement, but not full agreement.
… there will be different views on different contexts.
… Seems to be rough support for a registry - may change after the break.
… Proposal does not eliminate current approach.
… so some support for proposed solution.

Joe Andrieu: note: I don’t agree with the statement of support or consensus on this issue.

nms01: 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.

10. VC registries.


Michael Jones: Mike Jones from Microsoft. I’ve put things in registries over the years, and written a few of them.
… Some review. What are registries? Many specifications define extention points. registries are authoritative listings of items utiltizing those ext points.
… 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.
… Each kind of registry may have fields that some other don’t.
… 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).
… RFC 7518.

Michael Jones: The other entry, not made by an RFC, registered by the WebCrypto WG in W3C, was also put into the registry.
… Change controller is that WG; reference to spec

Michael Jones: Not just a list; enable interoperable implementations using them.
… Registries contain references to authoritative definitions; that avoids name conflicts, among other things.
… (So you can’t just register ES256 privately).
… Then we do interop testing, later…
… This enables us to state that implementations of e.g. RSA-OAEP-384 to hopefully interoperate, in both WebCrypto and JOSE.

Michael Jones: Yesterday was my 30th anniversary at Microsoft.
… Pam Dingle posted a link on Twitter to a query of all the RFCs that I have; the most cited was JSON Web Token.
… An awful lot of these use or establish registries.

Phil Archer: See Mike’s recognition.

Michael Jones: IETF has a separate org for regs: IANA.
… that administers numeric and textual assignments.
… That’s where the “4” for IPv4 is registered.
… The 25 for SMTP.
… ES256 for that kind of signature. etc.

Orie Steele: also where you can find your root servers:

Michael Jones: Important because independent of WGs; also independent of the IESG.
… 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 … RFC defines criteria to register.
… and populates the initial registry contents.
… e.g. ES256 was in that RFC.
… IESG (area directors) select a few designated experts.
… who read incoming registration requests and decide whether they meet the critera or not.
… Typically those are the initial RFC authors, but could be others.
… Then the registry ready to take in requests.
… So another spec (not necessarily an RFC) can register new stuff.
… WebCrypto example - W3C has used IANA registries.
… Finally, the designated experts review the requests, approve or reject and say why (rare).
… IANA adds the entries to the database for approved requests, and then you can see them online.
… 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.
… W3C has been working to establish registry practices.
… A number of us in the room have been working on those.
… I interviewed Ivan and Wendy about this.
… W3C can designate a specification as being a registry - document contains registration entries.
… Registries administered by either a WG or a CG.
… DID Spec Registries administered by DID WG.
… Unlike IANA… no designated experts; although a WG could appoint some as part of its process.
… What bothers me most is that there is no provision for its maintenance beyong the lifetime of the CG/WG.
… i.e. our registry could outlive the CG/WG, we want it to continue.
… Not there yet, but could get there.

npd: maintenance in making changes to the registry? or just the continued presence of the registry database?.

Michael Jones: I was in a WG with Tony and some others of you, WebAuthn WG, that decided explicitly to use IANA for its registries.
… In part for its independence, and the longevity factor.
… But need an RFC to establish the registry. So I and others did, with the blessing of the WG.
… Two registries, one for attestations, the other for extentions.
… The initial registrations came from the WebAuthn Level 1 spec; cited them; WebAuthn Level 2 added new ones.
… FIDO specs have also utilized these registries.
… Not to prejudice this, but we could choose to do the same thing.
… I think we want to have that discussion.
… One issue in our repository about the core of these discussions - feel free to read and comment. #909 (vc-data-model).
… Turning the floor over to my colleague in Texas with the pretty office.

Orie Steele: Thank you sir.
… To pick up with some examples, I’ll point to some links here you may have seen.
… 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.
… But you see versions of these in our work.
… In the first link, see a landing page for verifiable credentials, the version from 2018.
… VC in JWT format - you can understand how to interpret.
… the alg.
… and register additional terms.
… Private claims are not in the registry, but you may still seem them in a JWS/JWE header, or in a payload.
… VC Data Integrity work has some contexts, those are pointing to IRIs.
… jws-20202, ed25519-2020… you’ll see a description of those suites. Vocabularies… pointing to context files.
… Namespaces (links on bottom of slide).
… did, activity pub, web of things - all rooted under
… These namespaces and registries have some similarity - have editors, maintaining term definitions, sometimes just pointing through to other locations.
… Some of these you might be using with verifiable credentials today.
… Where do we register these?.
… - permanent URL service maintained by the community - pretty popular.
… you can open a pull request and reserve a namespace under that.
… then can provide redirects to specifications.
… So if e.g. Traceability were to move to a working group or other location, links could still work.
… Often folks working on VCs will set up something like this - since they are not sure if where they will host forever.
… So the vocabs can be changed but remain hosted.
… Examples not part of W3C community…
… Rebase - social network account linking credentials.
… Schema directory (DIF).
… KYC credentials.
… That one is related to credential types - for registering decentralized semantics.
… for JSON-LD. But could be a collection of JSON schemas.
… Potential confusion about JSON-LD and JSON schema; they are not direct substitutes.
… but both may need to be registered and hosted.
… for interoperability.
… Different kinds of content in the same registry: extentions to core data model, and DID methods. Different things!.
… DID method specs, need a contact. For checking names. “is foobar taken”.
… People can then click through to method specifications.
… In practice we see method specs being added frequently, but core terms to the data model not added very frequently.
… Maybe should split the registry based on what is more contentious / takes more frequent updates?.
… Another problem with did-spec-registries: considering requiring or not requiring value statements / impact statements.
… 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.
… This may be wanted to signal values about entries.
… Another value judgement: is it time to obsolete / not-recommend a particular suite.
… Like md5.
… 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.
… 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.
… Representations: In did-spec-registries need to think about how a term is represented.
… e.g. could use a different name for JSON, JSON-LD, YAML. Abstract name and concrete representations.
… But then new formats come in… CBOR, TOML…
… So need some policy.
… Challenging to define registration critera so the maintainer can operate autonomously.
… without burdening them with an egregious policy for new entries.
… Since they are probably volunteering their time.
… despite maybe being a paid W3C member.
… If it takes too much effort, not good. But if registry is too lax, other risks.
… What guidance to provide to registry maintainers - whether to include entries, or to ask the registrant to alter because of omissions or problems.

Ivan Herman: Some additional facts to complete the picture…
… 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.
… 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.
… That policy and maintenance has to be accepted by the AC, just as a recommendation has to be accepted.
… So there is a pretty strict control over the policy, whether it is right or not.
… 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.
… 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.
… So it is highly controlled… the W3C team acting as a gatekeeper… who that is depends on the team.

Orie Steele: +1 ivan :).

Ivan Herman: 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…
… Probably too late to change, but highly unusual these days that it’s where it is.

Joe Andrieu: I don’t like registries.

Michael Prorock: +1 ivan.

Joe Andrieu: In a JSON-LD world, the way it’s used is great… All the features Mike mentioned sound great.
… But we don’t need a centralized registry, because we already have an extensible model with JSON-LD.
… I don’t believe W3C has the institutional capacity for registries.

Shigeya Suzuki: +1 to Joe. cost to maintain registry is enormous.

Joe Andrieu: Most WGs don’t know what makes a good registry.

Yan Zhang: +1.

Joe Andrieu: We had issues in the DID WG with changing the process, and schemas, without WG approval.

Orie Steele: +1 to some of what joe is saying :).

Joe Andrieu: 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 depending on.
… Self-appointed controllers.
… It works, but it’s a hack - not a good mechanism.

Orie Steele: +1 to name squatting problem..

Joe Andrieu: Registries create a first incentive - land grab.

Orie Steele: did:0: everyone wants it..

Joe Andrieu: As long as have that incentive, we’ll have hoarding, squatting, and trademark issues.

Dave Longley: once there are too many things to register, registries don’t work well.

Joe Andrieu: All of that is unnecessary with the JSON-LD extensibility model.

Manu Sporny: I don’t like registries, but they have grown on me. I think they are useful as a documentation tool.
… 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.
… I think we’ll have one eventually. People like it.

Orie Steele: See also.

Manu Sporny: Like Orie, I don’t enjoy managing that registry, but it’s been working, more-or-less.
… 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.

Orie Steele: and

Manu Sporny: But people need help deciding… They said we discussed that; it’s up to your WG to decide.
… I agree we haven’t quite figured out what the rules are for the DID Spec Registries.
… Mike Orie and I are kindof flying by the seat of our pants… it’s calmed down a little bit…
… I’ve seen the blowups with an expert denies an entry.
… Can’t escape the controversy, whether it’s at IANA or here, there’s always a set of designated experts, whether here or there.
… 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.

Joe Andrieu: -1 to assuming we need a registry.

Manu Sporny: So I don’t see a way out of defining rules, appointing designated experts, and having controversy as a result of that.

Phil Archer: Warning, I could talk about URL persistance for the rest of the year.

Kristina Yasuda: Time check…

Phil Archer: 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.
… At some point, we’ll do something else. I’ll be retired in 10 years time.
… Some of you will be. Some of you already are (Why are you here?).

Phil Archer: See GS1 persistence policy.

Phil Archer: Persistence is important. Kevin and I spent cumulative hours setting up a new subdomain on our corporate domain name, about persistence ^.
… The policy document for how to get URI there is extensive - designed, like, like w3id, is because it has to be designed for persistence.
… otherwise your marketing department will change it.
… Primary reason was to get it away from the marketing dept.
… has a persistence policy.

Orie Steele: <3.

Phil Archer: See W3C’s persistence.

Phil Archer: Problem is that it’s out of date.
… It names a host that hasn’t been a host for 20 years.
… Persistence is as important as process, both need to be a part of this.

Michael Prorock: 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.
… Do you have a spec? Does it look something like a spec? Cool, it goes in.
… But then people in the WG get upset, there is pushback and flak; not helpful.
… So maybe with a process we can address this? But I’m skeptical.
… Namespace is key; large orgs are thinking about it.

npd: (I don’t see anything in the W3C Persistence Policy that commits to a specific set of hosts, or mentions any host organizations by name).

Michael Prorock: Now is a really good time to get this over with - namespace, persistence - let’s at least consider that.
… 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.
… We should think about that… Not a hard no on descriptions, registries of stuff we’ve looked at, maybe.
… But to say, go do it at CCG… we’re past that point.
… People are using this stuff; not suitable for CG.
… Other than having a test registry, to get working.

Orie Steele: +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.

Michael Prorock: Once it gets past that into the real world, it needs to go from CG to a WG, or to IETF, etc.

Orie Steele: 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.

Michael Prorock: Values vs term names is different.

Orie Steele: Compared to JOSE, terms go in the registry. Other terms don’t go into the IANA registry, but you still need to understand them.
… Some properties are normatively defined in a spec; others are defined through an extensibility mechanism - part of a registry or not.

Michael Prorock: Allowed values of terms often belong in some kind of registry.

Joe Andrieu: +1 to two types of definitions: defined within the spec, defined through extensibility mechanism.

Orie Steele: 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.

Michael Prorock: Assuming we want interoperability.

Kevin Dean: I’m with Joe, I don’t like the idea of registries - in general; you get name squatting, trademark issues…
… Having a large centralized registry in my opinion goes against the philosophy of verifiable credentials that is decentralized.

Dave Longley: +1 to kdeangs1 … -1 to “large centralized registries”.

Kevin Dean: The power of VCs is that it’s decentralized. We should provide guidance how to build them…
… But I don’t think we should be hosting them.
… e.g. the vaccination credential.
… Incredible work by people in this group, but I don’t think it belongs here; it should be hosted by that org, WHO.
… Electronic passport, managed by International Civil Aviation Organization.
… If they are doing VCs for passports, they should host it.
… Only relying on us to host the core VC … itself.

Orie Steele: context:, vocabulary:

Yan Zhang: I agree, no one likes registries.
… VC-wise, we could work with a centralized system or an enterprise system.
… I don’t think it’s necessary to impose a centralized registry on the system.
… 2. In fact, in different industries, same words may have different meanings.
… So making a centralized registry ourself will have a lot of challenges.
… 3. Right now there are a lot of standards communities referencing our work.
… e.g. ToIP foundation.
… 4. Decentralization by design / by default.

Kristina Yasuda: It feels like “registry of what” is missing from the conversation…

Michael Prorock: +1 kristina.

Mahmoud Alkhraishi: +1 kristina.

Yan Zhang: If we maintain centralized registry, it could jeopardize our collaboration with other organizations.

Orie Steele: +1 kristina.

Shigeya Suzuki: +1 kristina.

Yan Zhang: I agree we need some guidance on how to name things, what is a general process.

nms01: +1 Kristina.

Yan Zhang: So I get the essence of the work… maybe we need different names, to define the process, without registries.

Dave Longley: +1 kristina … registries only make sense for relatively small sets of information, IMO..

Michael Jones: 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.
… So I think it’s a foregone conclusion that we will have registries.

Michael Prorock: +1 selfissued.

Michael Jones: 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.
… The way to do that is through IANA.
… 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.
… In our case maybe the AC has to review our instructions; that’s all good.
… If we have time, I would request that the chairs run a straw poll.
… Whether, as a statement of intent, whether we want to run registries through IANA.

Joe Andrieu: Unfortunately, Manu and Mike, I think the assertion that it is inevitable is not collaborative, it shuts down.

Manu Sporny: Not my intent.

Joe Andrieu: OK.
… We may have some terms to define; not to think about as a registry…
… 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.
… Since we have JSON-LD, I don’t think we need it.

Antony Nadalin: We already have it with JOSE claims.
… Nothing normative in the VC spec about having to be decentralized.

Michael Prorock: +1 tony.

Kevin Dean: I never said we have to be…

Michael Prorock: +1 Orie.

Michael Prorock: I like Orie proposal.

Joe Andrieu: centralized VCs don’t need VCs.

Kristina Yasuda: To close the conversation, let’s run the straw proposal.

Orie Steele: wut… how does. adding a ns for v2 break anthing… v2 not exist yet.

Michael Prorock: … Should we consider that…

Manu Sporny: … would break the whole ecosystem …

Manu Sporny: context is fine.

Manu Sporny: ns is for vocabularies.

Kristina Yasuda: If we ever need to have a registry, if the need comes up,.
… do we want to use IANA?.

Manu Sporny: if we are talking ns, we are talking about changing the base URL for VC vocabulary – that would be VERY BAD..

Kristina Yasuda: since we heard some pain points by people who had to deal with did-spec-registries and whatnot.

strawpoll: we should run VCWG registries through IANA, if we have registries.

Manu Sporny: -1.

Joe Andrieu: +1.

Ivan Herman: -1.

Michael Jones: +1.

Mahmoud Alkhraishi: +1.

Antony Nadalin: +1.

Brent Zundel: straw poll is non-binding.

nms01: +1.

Shigeya Suzuki: +1 cost wise, and organizational stability wise..

Gabe Cohen: +1.

Orie Steele: +1.

Michael Prorock: +1.

David Waite: +1.

Manu Sporny: -1, we need to understand the rules before handing it over..

Phil Archer: -1.

Dave Longley: +0.

Yan Zhang: crypto people will not use IANA.

Steve McCown: -1.

Osamu Nakamura: -1.

Ted Thibodeau Jr.: -0.5.

Yan Zhang: will use ENS and etc.

Charles Lehner: +0.

David Ezell: -0.

Michael Prorock: We would write the rules.

Michael Prorock: The WG.

Yan Zhang: -1.

Jay Kishigami: 0.

Kristina Yasuda: Thank you everyone. And there is another…?.

Brent Zundel: straw poll: v2 will have an /ns for normative term defs?.

Hiroyuki Sano: -1.

Manu Sporny: -1.

Michael Prorock: +1.

Kristina Yasuda: … Never mind, second straw poll not valid.

Yan Zhang: crypto domain is actually adopting W3C standards.

Ivan Herman: 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.
… they have to stay where they are for eternity. It’s too late.
… Physically there is a possibility for redirection.
… But the vocabularies are there.
… If doing any inferencing… technically the only property is to use the owl sameAs statement… you don’t even want to know.

Orie Steele: luckily datestamped… so they will stay where they are..

Joe Andrieu: VCs and DIDs are getting traction in the crypto world, but it’s slow going.

Yan Zhang: a lot of debated between SBT and DID,.

Orie Steele: 2018 forever!!!!.

Dave Longley: it was a simpler time.

Gabe Cohen: before the merge.

Michael Prorock: Lol.

Kristina Yasuda: Let’s take a deep breath, and move on to ACDC.

Orie Steele: the year of the ICO..

Yan Zhang: LOL.

11. ACDC.


Charles Lehner: [SamSmith presenting].

Samuel Smith: ACDCs are verifiable data structures supporting attestations and credentials.
… Slides will be posted tomorrow.

Samuel Smith: ACDC for Muggles is a very good introduction to ACDCs at a high level.
… Presented at this WG meeting a few weeks ago.
… This presentation today is more technical.
… ACDC is based on KERI.

Samuel Smith: [Important ACDC Features slide].
… ACDCs leverage SAIDs, and AIDs - namespace-agnostic identifiers.

Kristina Yasuda: note to the WG members (esp. editors) to open issues to record the conversations accordingly.

Samuel Smith: Based on “dumb” “white magic” crypto. Does not preclude using other crypto.
… Uses JSON Schema. Tied to schemas, immutable.
… Uses property graph model - but not tied to a particular version - just using JSON and JSON Schema.
… Graduated disclosure; looks at disclosure in various forms: compact, private, partial, selective…
… Contractually Protected Disclosure.
… Each of these may not be sufficient.
… (statistical correlation and cryptographic correlation).
… Everything should be zero-trust and verifiable.

Charles Lehner: [Slide: Basic ACDCs].

Samuel Smith: Designed to be compact.
… 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.
… making a cryptographic commitment to the full representation for serialization.
… but don’t have to put the full representation over the wire.

Samuel Smith: ACDCs use JSON Schema.
… Schema, required fields, property fields.
… That’s the schema for the non-compact version.
… To uncompact it, take each section (attribute section…)…
… A commitment to this (pointing) is a commitment to that (pointing).
… So we can use JSON schema to make a commitment to both versions.
… to say I either have a SAID for this one, or the uncompacted one.
… to enable graduated disclosure.
… Issuer can require what they want.
… if they give enough flexibility, can use graduated disclosure.

Samuel Smith: Edge has properties.
… Node/vertex (pointing to “d”, “n”, “s”)…
… Can define in schema the types of the edges.
… So verifier can verify by type, not just by reference.
… So don’t have to expand…

Samuel Smith: Schema not included, would take too long.

Samuel Smith: Nodes with edges.
… Because using CIDs, it’s a distributed graph.
… Verifiable data structure all the way down.
… Important point is that it’s decentralized verifiable data structure.

Ted Thibodeau Jr.: Self-describing slides (or associated speaker notes) can be helpful for DEEP topics like this.

Samuel Smith: ACDC is universally referenced by its SAID.
… It’s cryptographically self-describing.
… Basically a hash; in a compact representation.
… Universally unique; no entity collisions.
… Because it’s distributed, each graph fragment has an id; the schema is the same; so no collision possible.

Orie Steele: so far the closest to an existing standard I have seen so far is JSON Schema, is everything else new?.

Samuel Smith: Same schema and SAID.
… No collision of type for ACDCs as fragments.
… So I can sign and send over Internet; verify over wire they are verifiable and have integrity,.
… without having to do expansion.
… This allows communicating to everyone in a distributed fashion.
… No need to coordinate on namespace, because everything is cryptographically verifiable and unique.
… It’s verifiable all the way down.
… This means provenanced chains of custody.
… Traceability in supply chains.
… Can chain together to represent chains of entitlement/authority.
… like vLEI.
… Can add an adge, and the whole chain is verifiable.
… All the tooling verifies the same thing; just looks like a chained ACDC; no other representation.

Orie Steele: how is this related to

Orie Steele: Content IDs, JSON Schema… multiformats, IPFS?.
… JSON Schema is standard, sortof… Are others… building blocks?.

Samuel Smith: CSER.
… just a compact representation.
… You would do a map of BLAKE3 digest to the COSE/JWT representation of that.
… ACDCs trying to benefit from compact representation to be easy to audit.

Gabe Cohen: +1 Orie this seems like a reinvented dag-jose/ipld.

Samuel Smith: to not have verbose cryptographic primitives.
… but can map 1:1 typically.
… for other libraries.
… Compactness for usability.
… Nothing fancy for JSON Schema; just a string that is a compact representation of the schema itself, using the SAID protocol.

Orie Steele: copying this link from zoom here:

Samuel Smith: to embed content-addressible data in a map.
… Using that protocol, everyone can verify the id as provided.

Michael Prorock: Data traceability… have you tried looking into
… validating the crawl overhead?.

Samuel Smith: No, have not done that.
… We have issued facts over IXVRL documents.
… so individual facts can be separately attested.
… Individual signers only liable for the facts they attested.

Charles Lehner: [Slide: Append-to-Extend].

Samuel Smith: No namespace collisions; can piece them together because it’s a CID.
… If you want custom fields, just chain them on.
… Start with pre-existing fields in schema, then chain on the custom fields.
… The mantra is “append to extend”.
… So you don’t need any centralized registries to avoid namespace collisions, because they are none.
… If you want to define new and meaningful labels… you can.

Michael Prorock: What are you asking us to do here?.

Charles Lehner: [Slide: … Ask].

Samuel Smith: ACDCs want to be interoperable; want a big-tent model with the W3C community.
… We use JSON Schema and CESR primitives… those could be mapped one-to-one with JWT primitives…
… We don’t want to be forced to use
… Not asking to replace JSON-LD, but want to co-exist with just JSON.
… No normative field labels for our field labels, but could map to normative field labels for interoperability.

Mahmoud Alkhraishi: +1 mike.

Michael Prorock: 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?.

Samuel Smith: ACDC is based on immutable schemas using CIDs/SAIDs.
… We would’nt use your schema, because it’s not locked down enough. But could map to them.
… After sending over the wire, can convert…
… With JSON-LD, you sign the RDF graph after expansion.
… We believe you should just sign what’s sent over the wire, that’s a more secure posture.

Orie Steele: possibly also related:

Orie Steele: actually, vc-jwt does sign JSON-LD..

Orie Steele: it signs JSON..

Michael Prorock: Right orie.

Samuel Smith: ToIP has OCA, a new schema representation… Or… could do those mappings.
… but we want to not be precluded from sending over the wire in our locked-down form.
… We can certainly define an interop profile from our schema to yours.

Dave Longley: all of these things sign hashes, actually :) … if we’re splitting hairs..

12. Resolutions