Verifiable Credentials Working Group Telco — Minutes

Date: 2022-10-05

See also the Agenda and the IRC Log

Attendees

Present: Michael Jones, Brent Zundel, Ivan Herman, Michael Prorock, David Chadwick, Ted Thibodeau Jr., Shigeya Suzuki, Chris Abernethy, Kristina Yasuda, Steve McCown, Sebastian Elfors, Dave Longley, Kevin Dean, Gabe Cohen, David Waite, Geunhyung Kim, Manu Sporny, Oliver Terbu, Joe Andrieu, Juan Caballero, Dmitri Zagidulin, Gregory Natran, Orie Steele, Jeremie Miller, Antony Nadalin, Shawn Butterfield

Regrets: Charles Lehner

Guests:

Chair: Brent Zundel

Scribe(s): David Waite, Manu Sporny

Content:

Brent Zundel: bulk of time talking about concrete proposals for the core data model, as time permits at the end we will do triage for known issues.

Manu Sporny: a quick report from rebooting might be useful, a few items which may be useful to the group.

Steve McCown: introductions; just recently joined, from anonymity labs, working for quite a while with sovrin, DIF.

1. Work Item status updates/PRs.

1.1. Data Integrity

Manu Sporny: https://github.com/w3c/vc-data-integrity/.

Manu Sporny: VC Data integrity - a number of pull requests which have been processed over the last 2-3 weeks, filling out parts of the specification, thanks to efforts so far, 2-3 more weeks of work before FPWD, ask for review of current PRs.
… PRs seem to be getting adequate review.

Manu Sporny: https://github.com/w3c/vc-data-integrity/pulls.

Michael Prorock: +1 manu - we are probably just inside a month for an FPWD, especially now that i am done with travel for a bit.

Manu Sporny: https://github.com/w3c/vc-data-integrity/pulls.

1.2. JWT

Michael Jones: clean up of various pieces of text, looking to discussions today of data model as that may affect how we map VC-JWT to the VCDM. Discussions with co-editors on FPWD timeline.

1.3. Data Model

Manu Sporny: https://github.com/w3c/vc-data-model/pulls.

See github pull request vc-data-model#924.

Manu Sporny: VCDM spec, scripts for vocabulary generation as PR, PR. #924 has a fair bit of discussion, quite a number of issues, encouraged to create PRs for issues.

1.4. JWS 2020

See github pull request vc-jws-2020#24.

Orie Steele: JWS2020 has one open PR, call to get reviews.
… Ready to kick off FPWG process with guidance.

Ivan Herman: synchronizing publication with other work items, including data integrity, may make things simpler.

Manu Sporny: +1, we don’t have to time all of them together, VC-JWT is separate, Data Integrity and JWS2020 can be done at the same time.

2. RWoT.

Juan Caballero: https://www.weboftrust.info/.

Brent Zundel: reasonably well attended meeting, rebooting web of trust is one of the early communities instrumental to decentralized identity and DID work.

Juan Caballero: https://github.com/WebOfTrustInfo/rwot11-the-hague/tree/master/draft-documents.

Brent Zundel: a decent of attendees had been there previously, not a lot of first-timers, a number of work items which could tie into this WG.

Manu Sporny: +1 to a NOTE on correlation best practices/advice..

Brent Zundel: personally involved in a paper about correlation which might be publishable by a note in this group, call to put ability to correlate in the hands of the subject vs isusers/verifiers.

Oliver Terbu: holder binding presentation at TPAC, at rebooting had a bit of discussion over the three days.

Juan Caballero: Stephen’s issue.

Oliver Terbu: came up with a proposal and tried to understand how the proposal would work against various holder binding use cases, including requirement catering to enterprise.

Manu Sporny: +1 to presenting the paper to the VCWG..

Oliver Terbu: after we finish paper, would like to present to group.

Manu Sporny: dmitri’s group, Charles, and others worked on the rendering efforts - took rendering paper and came up with a demo on using a templated SVG to render a verifiable credential.
… could end up adding a property to the VC data model.

Juan Caballero: https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/rendering-vcs-snapshot-9-27-22.md.

Juan Caballero: https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/title-tbd-issuer-verifier-list.md.

Manu Sporny: also discussion on how to link one VC to another VC using a link and a hash, a problem some have been trying to solve/standardize..
… We worked with Keio, Fraunhofer, TNO, Bloqzone, Spherity, and Digital Bazaar on the paper..
… Another group including trust over ip, and others on trusted issuer/verifier list, node authorities, trust registry - how do you know whether to trust a credential that has been issued, should you engage with a verifier,.
… another month or so on that paper to finish up.

Shigeya Suzuki: I was part of the issuer/verifier discussion too..

David Chadwick: proposal to introduce a new role, issuee, a kind of holder who can pass credentials to other people. Holder is variable while the issuee is a fixed participating entity.

Ivan Herman: See Issue referred to by DavidC.

Ted Thibodeau Jr.: recommends DavidC proposal to be in another issue.
… separately concerned about the value of this - that there is not a confusion of holder and subject broadly.

Manu Sporny: It also sounds like it overlaps w/ holder binding discussion..

Gabe Cohen: confusion of holder vs subject surfaced in delegated credential discussions.

Gabe Cohen: ref: delegated creds - https://github.com/w3c/vc-data-model/issues/930, multi subject - https://github.com/w3c/vc-data-model/issues/931, multi issuer - https://github.com/w3c/vc-data-model/issues/932.

Ted Thibodeau Jr.: TallTed: “Issuee” is not material to any of #930, #931, #932. “Issuee” should get its own issue..

3. Concrete Proposals for Core Data Model.

See github issue vc-data-model#929.

Manu Sporny: attempt at a number of proposals - some discussion over those proposals with a couple of +1’s, some back-and-forth with Orie, wondering if the best approach is to put proposals forward to see if there’s agreement.

Manu Sporny: See proposal.

Michael Jones: +1 to make VCs easier to use and develop.

Manu Sporny: there are a number of things which make JSON-LD processing mandatory, one idea here would be to not allow JSON-LD expanded form - only bald JSON-LD is one in compacted form.

Michael Prorock: +1 to easier to use and develop.

Ivan Herman: See JSON-LD compact form definition.

Manu Sporny: another, have @context use URLs and recommend against inline contexts.

Michael Prorock: -1 to guidance against inline context - see comments in issue re twitter and other discussions on schema.rg.

Manu Sporny: finally, a discussion about @vocab and make it easier for developers to pick up and use without the first thing to do being to define a JSON-LD document..
… a suggestion by Orie that its RDF, my proposal is it is JSON-LD which is a superset of RDF, others that it is JSON-only.

Michael Jones: My proposal titled “It’s time to let JSON be JSON” is at https://github.com/w3c/vc-data-model/issues/929#issuecomment-1267697526.

Michael Jones: after discussions with a lot of people including at TPAC, there is ample evidence that there are developers who get it wrong if they use @context, and who would be happy with a more typical JSON model. The current text is halfway between, requiring an @context without requiring JSON-LD. The simplest way to resolve this is to define two kinds of credentials - ones which include @context and are JSON-LD, and ones which don’t and are JSON.

Gabe Cohen: +1 Mike.

Michael Jones: it is a little unfortunate if we have two representations, but that is what we are seeing. We should restrict the usage of @context if the data is not JSON-LD, and require it if it is.

Jeremie Miller: +1 to two clearly different kinds, w/ @context and without.

Orie Steele: appreciate comment about developers, various skillsets mean that some struggle with certain technologies while others find it easier. We should strive to make it easier to implement for unskilled developers..

Michael Prorock: +1 orie - ietf vs w3c and a place for all things.

Joe Andrieu: +1 to point out that restricting context would be a violation of JWT’s extensibility framework.

Shawn Butterfield: +100 Orie.

Manu Sporny: -1 (splitting into two different formats) that will guarantee a non-interoperable VC ecosystem..

Dave Longley: +1 to Orie.

Michael Prorock: -1 to splitting into two different formats.

Dave Longley: -1 to splitting into two different formats, if don’t want data model constraints and open world decentralized semantics, use a JWT – that already exists..

Michael Prorock: +1 semantics are important to this work.

Manu Sporny: +1 on semantics being important and are a key differentiator here..

Orie Steele: COSE/JOSE work in IETF, have their place in signing unstructured data. To the original point on implementation complexity, should be trivial to implement but should have value in implementing. Combining things together means that they lose the value of their specificity. My value in Verifiable credentials is that they provide semantic data..

Michael Prorock: https://lists.w3.org/Archives/Public/public-credentials/2022Sep/0253.html.

Orie Steele: example of a mill test report signed by a steel company in Mexico - want them to choose between using VC-JWT or Data Integrity - but regulators consuming the document should have the same semantic data at the end.
… mission we are on is to create an open world model for structured semantic data, treating this work as an extension of COSE/JOSE with a few new terms doesn’t solve these objectives or help issuers and verifiers..

Manu Sporny: +1 to what Orie is saying..

Dave Longley: +1 to Orie.

Michael Prorock: +1 Orie.

David Chadwick: +1 to Orie (or plus infinity).

Joe Andrieu: comment on selfissued’s comment - if the extensibility model is to just add whatever terms to the JSON to extend it, why not allow @context..

Orie Steele: Example of awesome work at IETF, on signing arbitrary data… https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign.

Michael Jones: My comment on the JSON-only extensibility model is at https://github.com/w3c/vc-data-model/issues/929#issuecomment-1268585146.

Orie Steele: +1 to adding @vocab to the core data models v2 context..

Michael Prorock: applause to Orie on comments, a reasonable proposal is that @context is required given the semantic nature of work - however, it is important to recognize that there are a large body of use cases existing in the wild that also utilize some of the properties of JSON-LD like @vocab.

Manu Sporny: -1 to adding @vocab in core context, but +1 to add it in a “poc/developer” context..

Dave Longley: +1 to adding @vocab in some way that makes it easy for less skilled developers to use, not necessarily in the core context, but perhaps in another context that can be used and will signal its usage to simple processors (that just read the @context strings).

Michael Prorock: I should also note that @vocab prevents developer errors in terms of what is getting signed or not.

Manu Sporny: It creates errors as well – :).

Manu Sporny: However, there is a way to address this concern and we shouldn’t conflate that discussion w/ the core data model discussion..

Michael Jones: not trying to change JSON extensibility model, as it is a claim with specific meaning that could conflict. We should register it as a claim in the IANA JWT claim registry. You need to use claims in the way they are registered. If you use @context, use it as it is defined..

Orie Steele: +1 to registering JWT claims, -1 to thinking that IANA registries are the only way to understand claims… we are literally here to break that cycle..

Michael Prorock: +1 orie.

Manu Sporny: +1 orie.

Joe Andrieu: +1 to letting @context be used as intended, and allowed anywhere in the JSON serialization.

Dave Longley: +1 to Orie.

Orie Steele: luckily we don’t need a new standard to “just sign JSON or CBOR” :).

Manu Sporny: nor do we need a new JWT spec, it’s there, if people don’t want semantics – use that. :).

Orie Steele: don’t forget about signing with “sd-jwt” :).

Manu Sporny: or jwp! :).

Orie Steele: or acdcs.

Manu Sporny: or AnonCreds.

Michael Jones: Orie made a point that signing things should be a distinct activity from the type of data which is signed - we are defining what is signed, whether with JOSE, COSE, Data Integrity. The value we are adding is in defining the additional claims which are in a typical VC, and what they mean.

Dave Longley: my comments here: https://github.com/w3c/vc-data-model/issues/929#issuecomment-1268527033 <– use the right tool for your use case … if that’s a JWT, use one, if it’s a VC, use a VC … but these aren’t the same things and shouldn’t be made to be the same..

Orie Steele: this is why we shouldn’t let the core data model be “wagged” by a security format..

Kristina Yasuda: JWT spec cannot be used as-is to do a JSON-encoded VC.

Orie Steele: ? we use it in 1.1… not sure what you mean kristina..

Michael Prorock: there is a 3rd proposal on the table: @context + @vocab in core data model.

Manu Sporny: https://w3c-ccg.github.io/traceability-vocab/#credentials.

Manu Sporny: the problem here is that we are discussing splitting the ecosystem into two communities with different extensibility models. JSON-LD uses identifiers which do not require a central registry, while JSON would defines claims in a centralized registry..

Orie Steele: Don’t look at us… look at schema.org, GS1, UN CEFACT, CHEBI, QUDT, FIBO, etc….

Manu Sporny: if you just look at the traceability work, the amount of claims necessary would be massive. Argument is to go register claims in a centralized registry at IANA, use reverse domain names, etc..

Joe Andrieu: +1 to domain-specific terms, managed by each domain, as they wish. No need to centralize everything into a single registry. That’s an anti-pattern we’re trying to fix here..

Manu Sporny: that approach has been discussed time and time again and that approach just does not scale.

Orie Steele: Look at how people are already using the open world capabilities of JSON-LD in industry today… look at knowledge graphs… look at OntoText and Neo4j..

Manu Sporny: the ramifications of splitting the data model into two things with different extensibility will split the ecosystem, and is one of the greatest things we could do to damage the ecosystem today. Today, some people are doing it wrong but things like @vocab could be used to help.

Kristina Yasuda: @orie: JWT spec defines the claims, but there is a need for a profile like vc-data-model or an ID Token section in oidc to make those claims meaningful - iss/iat/etc are all optional in the JWT spec itself.

Dave Longley: i don’t understand how a “vanilla JSON ‘VC’ that doesn’t have data model constraints and uses a centralized claims registry” would be different from a JWT – what would we be doing here?.

Shawn Butterfield: If I am forced to include @context, but I do nothing to actually use it and none of the relying parties for my use-case rely upon it then what purpose does it serve? Requiring it isn’t something I can fully support, but I can absolutely see the value in it for some use-cases, so I’m more than happy to optionally use it..

Orie Steele: kristina: ahh yes, we have the “securing specs” to handle those profiles / mappings..

Kristina Yasuda: +1 shawnb…

Manu Sporny: shawnb if you don’t use use @context, what’s your extensibility story?.

Dave Longley: shawnb, when you read a spec that says what the context is (what the mappings are) and you hard code your software to look for its URL identifier and its mappings, you don’t have to programmatically process it..

Orie Steele: Guys… you can sign JSON today… with JOSE… why are you here if you just want to process JSON and JWTs / JWS ?.

Kristina Yasuda: Orie, umm securing is how to secure/sign; JWT body of what is signed is separate - why JWT and JWS are separate…

Manu Sporny: +1 to Orie.

Dave Longley: +1 to Orie.

Joe Andrieu: +1 to Orie.

Jeremie Miller: +1 shawnb.

Antony Nadalin: not proposing to get rid of @context, it should be optional whether you use it or not. You have troubles today because people find they are not needing it - but you are forcing the parser and logic to understand it. Mandating @context has made the world more complex - you don’t need it while processing just JSON and JWTs. As far as interoperability is concerned - you hurt interoperability by forcing people to go down this route..

Kristina Yasuda: Orie, it’s not how to sign, but the body of what’s being signed…

Orie Steele: -1 to “hurting interop”… its like saying OIDC hurts interop…. profiling does not hurt interop, in enables it..

Michael Prorock: +1 orie (to his -1).

Dave Longley: +1 to Orie.

Kevin Dean: if we have an envelope model, where we use @context as a wrapper for the verifiable credential model where inside the envelope the issuer can do what they please..

Shawn Butterfield: @manu I don’t need semantic meaning to have extensibility in the datamodel..

Shawn Butterfield: dlongley - if I do that then what purpose does @context serve for my software in processing the payload?.

Orie Steele: shawnb, not sure what your use case is, but maybe JOSE / COSE is a better fit for it ?.

David Waite: One of the issues I have with @context environmens where people are not ready to handle it, @vocab are not ignorable, especially within data integrity and cnaonicalization of RDF, as well as without it, you wind up having two different data models for the same piece of data and that matters in a security context..

Michael Prorock: semantic meaning on what a VC itself means is important.

Shawn Butterfield: Orie - yes, generally speaking it is..

Dave Longley: shawnb: it’s like adding a type definitions file to make JS into TypeScript.

Orie Steele: You should use JOSE / COSE… if they are better fit for your use case… You should not try and make everyone use them, if you don’t understand their usecases..

Dave Longley: shawnb: the @context URL says “these are the types used in here” – and if your software knows that context, it doesnt’ have to do any transforms, it only accepts JSON marked with that @context value..

David Waite: If you have multiple ways of expressing things and people understand that in different ways, someone might thing an object property means something specific vs. someone processing @context thinks theres an extra value there, downloading things dynamically, changes semantics as they are processing it and that’s a serious security issue where you can craft messages are meant to be secure but can be interpreted in different ways by different people,.

Manu Sporny: where we’re not encouraging processing as data, you haven’t committed to valid semantic model for extensions where JSON developers are using static things - explosion of complexity. We are not giving people the flexibility to do both sets of tools, we are requiring them to understand security ramifications looking at data in different ways..

Shawn Butterfield: Orie: Agree, I’m not trying to make everyone use them..

Orie Steele: Imagine telling everyone that category theory and type safe languages are bad, because you can use python and javascript..

Michael Jones: We already have a split ecosystem, there are two camps, we should support both well than to be halfway inbetween that serves no one..
… responding to manu’s comment - the community is already divided. We have those who speak JSON-LD correctly and those who are not. We are better off recognizing that vs leaving things halfway between.

Orie Steele: -1 to “there are 2 camps”… there are people who use JOSE / COSE and there are people who use them and the VC Data Model..