Verifiable Credentials Working Group F2F, 2nd day — Minutes

Date: 2023-02-15

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, Kaliya Young, Ted Thibodeau Jr., Dave Longley, Dmitri Zagidulin, Manu Sporny, Geunhyung Kim, Shigeya Suzuki, Gabe Cohen, Michael Prorock, Phillip Long, Andres Uribe, Kristina Yasuda, Orie Steele, Brian Campbell, Paul Dietrich, Oliver Terbu, Przemek Praszczalek, Samuel Smith, Joe Andrieu, Michael Jones, David Waite, David Chadwick, Mahmoud Alkhraishi

Regrets:

Guests: Phil Fariller

Chair: Brent Zundel, Kristina Yasuda

Scribe(s): Paul Dietrich, Joe Andrieu, David Waite, Manu Sporny, Michael Jones

Content:


Brent Zundel: Welcome to day 2.
… Agenda with 2 topics plus issues.
… data integrity then VC-jwt.
… focus on decisions and concrete steps to move forward.
… jump right in. Manu?.

1. Data Integrity Specification.

Ivan Herman: Slides start at https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g1482ccb90af_0_105.

Manu Sporny: Not that many slides.
… basically a status update today for Data Integrity.
… Identify the remaining difficult decisions.
… then set where we go from here, actual timeline.
… Today. We have adopted the base specification.
… introduces base concepts, cryptosuites, privacy consideration.
… Data Integrity is not just a linked data thing.
… you can use it on pure JSON, pure CBOR, and linked data.
… biggest different with JWT is the canonicalization.
… That’s because we want to sign over the semantics, with signatures that are immune to changes in space.
… For example, schema.org will start consuming information off websites we want to enable that to be exposable with data integrity.
… So a major difference is that canonicalization aka transformation, then signing.
… We’ve adopted the base spec, and also a basic security vocabulary.
… FPWD of VC Data Integrity.
… Adopted JSONWebSignature2020 and EdDSA Cryptosuite.
… first FPWD of vc-jws-2020.
… That’s where we are today..
… We’ve also have a bunch of plugfest.
… work been going since 2012.
… interop testing and test suites.
… Things to do in next ~6 months.
… FPWD of EdDSA Cryptosuite.
… Big question is are we going to do ECDSA cryptosuite?.
… Must complete test suites.
… Issue processing (not much controversial there).
… Snapshottable CRs? We’re close. Should be doable within the next 6 months.
… but lets talk about that strategy.
… perhaps go earlier to first CR knowing we plan on a revised, 2nd PR.

Ivan Herman: on the to do list, we still have a lot of work on the security vocabulary cleanup..

Manu Sporny: yes. +1.
… Thank you. Ivan is the one who did almost all the vocabulary clean up into a new format..

Ivan Herman: i hope in a few weeks I’ll be able to work on it again.

Manu Sporny: we may need some focus time. not sure if that’s a special topic call for those interested in cleaning up that vocabulary.
… that’s it for roadmap status update.
… Here are the results of the Jobs for the Future (JFF) plugfest.
… I’m bringing this up because the EdDSA cryptosuite was the most used, both 2018 and 2020.
… that’s one thing to talk about. do we want to kill of the 2018 version? (I want to).
… There were 17 different issuers (although not 17 implementations).
… 6 different libraries.
… 8 different wallets generating DID Auth signatures.
… then the issuers were signing the VCs themselves with EdDSA.
… one of the challenges here is going to be getting to the newest data integrity proof thing.
… we’ve got enough people implementing this stuff. we just need to convince them to upgrade.
… that should be straightforward as there isn’t much change. should be simple.
… test suites! We have preliminary suites for VC Data Integrity, EdDSA Cryptosuite, JSONWebSignature2020.
… we have a mix in library that can test base layer VC data integrity then also specific profiles.
… currently powered by making calls against the VC-API and asking the issuer to issuer, then it checks those signatures.
… it calls verify locally.
… we could make it so it calls verify on other endpoitns (VC API), but we aren’t doing that yet.
… There is an NxN matrix that tests all issuers against all verifiers.
… Orie want to give background on JSONWebSignature2020.

Orie Steele: the test suite is at DIF..
… basically about implementation interoperbility.
… uses docker.
… so each implementation builds a CLI and generates outputs from the implementations.
… and then verifies the output with just one verifier.
… You produce a payload, we verified this payload..
… Not statement by statement. Kind of a file-based verification.
… Like the test vectors for COSE.
… The tests are dynamically generated from inputs.
… outputs shows which vendors passed which pieces.
… it has a bunch of suites, and each implementation gets tested against the ones it supports.

Manu Sporny: there is a question about how to test things for W3C.
… traditionally its about testing the normative requirements to verify interoperability to the spec.
… it hasn’t really been about making sure things actually work together.

Orie Steele: The VC Data Integrity test suite, covers the normative statements part, the crypto suites make sure the sign and verify are interoperable..

Manu Sporny: The Data Integrity chart. The test name on the left is the spectext that is being tested.
… “proof field MUST exist at top-level of data object”.
… Every crypto suite tests those data integrity tests.
… Then each cryptosuite has its own set of test vectors.
… This is showing we are actually testing the verification statements, not just the validity of the signature.
… At the bottom is the matrix (Section 2.5).
… we have everyone issue a credential, then test it against every verifier..
… we don’t have to do this for this working group, but it is a great demonstration of interop.
… That’s our proposal for how we do testing.
… Fairly easy to crank these tests out because its modular.
… Using that suite and the tests in current form. I assert we can get to CR within the next 6 months easily.

Ivan Herman: to get to CR we have to also go through horizontal review. That might take a long time.

Manu Sporny: that’s a good point. We should start horizontal review in the next few months.

Ivan Herman: The next FEW DAYS :-).

Manu Sporny: if I remember, we don’t need to be finished, but historically it has always been a rush.

Ivan Herman: yes, it’s always a pain.

Brent Zundel: one thing the reviwers HATE is to review a spec that can’t change because its going into CR.

Manu Sporny: open question on EcDSA.
… need to align with last language in the spec.
… For each feature, we are looking for at least two checkmarks.
… Not a very high bar. We could go higher: 3 or 4 or 5.
… Given that we have 17 implementers or half that for reusing code. So we have at least 6..
… We aren’t at risk.
… Next JFF plugfest is in the next few months. We can use that to get support for cryptosuites.
… Here’s the discussion: The big rocks.
… This is the thing with discussion to day.
… JCS instead of URDNA?.
… Need in put on these four.
… first thing, should all the cryptosuites support JSON canonicalization in addition to UDRNA? Issue #25.
… The reason for this is so that people that want to do JSON only can use JCS. That requires no RDF.
… The other argument is that URDNA is going through standardization at W3C, multiple implementations,.
… but not a machine verified proof..
… that proof doesn’t always happen, but its a good idea. it’s hard and will take 6-9 months.
… This is not a limiting factor anywhere else (IETF).
… Most crypto we use doesn’t have these proofs.
… If we find some flaw in URDNA, then the canonicalization group doesn’t feel it would be catastrophic, but it would be nice to have that backup.
… so JCS would be a good backup.
… so every suite has the option to use JCS.
… Should all of the suites have this kind of dual support?.
… Thoughts?.

Orie Steele: I want to talk about proof chains.
… I just really want them to exist.
… In data integrity proofs where we’ve seen interop, you can’t get that nested proof, which is easy with JWT. Let’s get that into DI.
… Either finish or cut.

1.1. Canonicalization schemes.

Michael Jones: I queued for the suggestion that maybe we support multiple canonicalization.
… “Standards is the process of making the choices that don’t matter”.
… Do you call things XYZ or PDQ? It often doesn’t matter EXCEPT that there is agreement.
… If there are choices, different developers will make different choices and that harms interop.

See github issue vc-di-eddsa#25.

Michael Jones: First and foremost, decide.

Michael Prorock: There’s a thread about X.509 where choices were allowed and now there is chaos..
… I am an acknowledged horrible editor on this spec..
… Because the spec itself bothers me..
… I brough this up when we first looked at x.509 stuff coming in.
… There exist already defined stuff. I am concerned at the root level that perhaps we merge JCS2020 merged with the spec.
… with VC-JWT (make sure it works). That might be a different path..
… At this point, I don’t know how to make it something I would want to continue to work on and implement. That concerns me..
… Instead of working on product, go do this complicated thing. And I’m familiar with the work.
… yes we can go to CR, but maybe we should simplify first.
… Maybe that’s a later step, but it feels like we keep kicking the can down the road.
… Do I think there are practical things we can do? Yes. Pick one..
… Proofchains: nice to see..
… Others seem mostly simple..
… But this meta thing: we never resolved possibly being bound to the IANA jose, so let’s not use it in DI.

Brent Zundel: What’s the status of JCS.

Ivan Herman: the question is: how stable is JCS?.

Michael Jones: its conditional RFC. Personal submission because JSON working group didn’t like it.
… its informational.

Orie Steele: with DI Proofs, there is a set of things that when you create it, you must do, including defining canonicalization.
… I’ve created a lot of DI suites over the year..
… Every time you create one you HAVE to state the canonicalization.
… most have been URDNA, but some have been JCS.
… To say you MUST define the canonicalization, but only show URDNA, that’s a problem.
… We have 90% URDNA..
… to me the extensibility is better supported by actually supporting JCS as proof of choice.
… If we only give one example, it’s essentially not giving people a choice.
… We should either support extensibility with a second option, or get rid of the optionality.
… for DI proofs to be valuable, then need to have different features than existing systems (JOSE, COSE, X.509).
… JCS could help in that regard..
… We could separate different cryptosuites. Some with URDNA, some with JCS. Same crypto, but different canonicalization..
… This shows the different options. The best we could to demonstrate value with those examples..
… Whether or not those options take off isn’t the point..
… From a design perspective, it’s important for data integrity to have distinctive value.

Dave Longley: I agree with a lot of Orie. I also agree with Mike’s comments about making decisions..
… There are good arguments to be made that these algorithms don’t do the same things. They make important choices.
… I don’t think suites MUST be able to support both, but its a good idea.
… about making decisions and reusing tech. It’s important to understand the design features..

Orie Steele: For the record I don’t think a single suite should support both… I think a single suite MUST make a choice, so the implementation burden for the suite is minimized..

Dave Longley: we wouldn’t be here if we thought JWTs and VCs are the same.
… We spent a decade to get the VC work going forward because they do something different.

Michael Prorock: See RFC8785.

Gabe Cohen: I’m not against supporting JCS, but I’m curious about the arguments.

Michael Prorock: To Gabe’s question. Some of this goes to optionality. If we have extensibility, we should demonstrate choice.
… But let’s look at DI, it’s about signing “the meaning”.
… The practical value I see is that signing with URDNA, that I’m signing the transformed NQuads..
… If that meaning changes over time, that signature should break.
… JCS doesn’t get at that meaning..
… To my mind, unless we can come up with the value of JCS, we should just get rid of the optionality.
… But if we are going to keep optionality, JCS looks like the best candidate.
… There have been so many times this has been attempted..
… If you look at the XML stuff….
… It’s concerning to me to have the optionality unless we can state the value of it.

Manu Sporny: I’m concerned we aren’t going to get to the “easier” items. Can we put a pin in this and talk about proof chains..
… also different about JWS2020 uniqueness would be good to discuss.
… dequeing myself. Can we wrap this topic up?.

Michael Prorock: https://www.ietf.org/standards/process/informational-vs-experimental/ diffs on standard track vs informational.

Michael Jones: problems with JCS. If you’re not canonicalizing floating point numbers, it’s easy..
… Unicode might also be a challenge.

Dave Longley: JSON is UTF-8.

Michael Jones: From my point of view Unicode canonicalization is not something you’d do in a JSON scheme, you’d do it at application layer.
… my preference if we had to choose would be JCS over URDNA.

David Waite: building on Mike’s comment. When you canonicalize, you’re trying to deal with syntax. With XML, the rules were smarter than the developers.
… these different systems need to give them their sense of the data and not just integrity.
… one is outputing NQUADs, one is outputing JSON.

Michael Prorock: +1 dwaite.

David Waite: At the end of the process, they get different data.

Orie Steele: in URDNA, when data type is JSON, JSON is used internally.
… The other comment: what’s the value of JCS?.
… Why transform JSON into a hashable format?.
… It’s because the structure and syntax of JSON. If you want to sign something, if you’re dealing with ordering, you get different hashes, so it matters where that happens..
… The sidetree protocol (which did:ion uses) uses JCS because it uses hashes and we didn’t want the storage layer to be hackable at the storage layer.

Dave Longley: +1 to Orie.

Orie Steele: Microsoft’s ion implementation seems to be doing well (that’s to godiddy.com lists).
… JCS has a use when used for that purpose.
… It’s basically about that hashes..

Dave Longley: +1 to not letting overreaction culture in the security community dismiss valid and useful use cases and features.

Orie Steele: Saying that I like data structures that always hash to a different value… that doesn’t make me super happy about JSON.
… It shows up in these places where we have different signatures and you have do design around this possibility..
… you BETTER think about that, because it is fundamental to JSON.
… There are places you don’t care because you’re just signing over bytes. Or you might, because you’re reconstructing options over time..

1.2. JWS-2020 and Other Cryptosuites.

Orie Steele: JSONWebSignature, what’s different?.
… Not a lot..
… It uses URDNA. It’s signs not the raw canonicalization, but a detached JSON signature that has a header, concatenated with createVerify bytes.
… that’s different than using just the createVerify bytes..
… That adds bytes, but also flexibilty.
… I floated on the list a while ago that JSONWebSignature2020 could be different.
… we like IANA, we like detached, but perhaps we want a different canonicalization..
… since its’ about “JSON” we can use a JSON native canonicalization.
… I would like to focus on just the JSON, and NOT do URDNA.
… This would make JSONWebSignature obviously different.
… folks don’t agree. and obviously we’d need consensus to change it.

Manu Sporny: I just put myself to suggest we move on..
… Thoughts: I think its important to use JCS..
… Do we want alternatives?.
… As a customer, there is a desire to have a backup in the Edwards suite (EdDSA).
… our company is probably going to do it with or without the WG..
… It’ll be up to the WG to decide if that’s worth while.
… I don’t think it’s a difficult change (adding JCS).
… Could do it with several of the suites.
… That would mean EdDSA would have two variations of the data integrity proof.
… not sure what that means to support the IANA variations for JSON WebSignature.

Mahmoud Alkhraishi: something about does the current situation break ?.

Manu Sporny: it still verifies, but the underlying information model can change without you.

Mahmoud Alkhraishi: if somebody changes the context to exclude a word, it doesn’t break in JCS.

Orie Steele: there was comment about one of the first DI proofs was mastodon and fediverse.
… there was a recent proposal to rekindle that with JCS.
… There are folks thinking about this, other than just us..
… What’s interesting: They aren’t signing VCs.
… So, for data integrity proofs, they aren’t using VCs, but its a similar approach.
… The comment about… if DB is going to create raw signature for everything, then a different canonicalization….
… Is that an industry intention?.
… Is that correct, than we can withdraw JCS and handle that differently..
… If the only difference is the header saying us IANA, that isn’t worth the effort to standardize.

Brent Zundel: moving to break.
… keep talking over break. come back with solutions.

Manu Sporny: asked Mike Prorock to prose.

Michael Prorock: proposes abandoning JWS 2020 and redirect folks to VC-JWT to use JOSE signing approaches (PR #51).

Orie Steele: The proposal, is to not use jws-2020 anymore, and just use https://github.com/w3c/vc-jwt/pull/51 for securing credential+ld+json..

Michael Prorock: test prop: Abandon JWS2020 in favor of pointing to VC-JWT.

Michael Prorock: It would allow us to make the existing specs better..

Manu Sporny: I think it makes it cleaner and reduced optionality.

Orie Steele: Happy to be an editor of just one of these.
… looking forward to working on only one work item.

Brent Zundel: ask about what “pointing” to vc-JWT. what is the methodology?.

Michael Prorock: We can add a header to the JWS document to point to vc-jwt..

Orie Steele: Agree with proposal to update the readme. Is there a formal document change to link them together? Would be weird to advance vc-jwt with a pointer to a FPWD.

Manu Sporny: we might not need a formal proposal. Can we move forward without a proposal and vote?.

Ivan Herman: In the old days a working draft was converted into a note. Now we should make a clear resolution that this document does not go to rec because it will stay on record as a draft..

Proposed resolution: Abandon JWS2020 in favor of pointing to VC-JWT using the JWS 2020 Readme and text in VC-JWT. (Brent Zundel)

Orie Steele: +1.

Mahmoud Alkhraishi: +1.

Manu Sporny: +1.

Dave Longley: +1.

Will Abramson: +1.

Ivan Herman: +1.

Michael Prorock: +1.

Michael Jones: +1.

Brent Zundel: +1.

Shigeya Suzuki: +1.

Joe Andrieu: +1.

Andres Uribe: +1.

Ted Thibodeau Jr.: +1.

Phillip Long: _1.

Phillip Long: +1.

Phillip Long: LOL - it’s a special ++.

Resolution #1: Abandon JWS2020 in favor of pointing to VC-JWT using the JWS 2020 Readme and text in VC-JWT.

1.3. Data Integrity Roadmap.

Manu Sporny: lets go down the remaining bulleted items..
… no FPWD yet, but its ready so I am suggesting we cut an FPWD as soon as we can..
… Now that JWS 2020 is removed, it strengthens the argument for a EcDSA suite..
… reviewing timeline from the slide 87.
… Try to get chained proofs in there before CR.
… Because we have CR snapshots, we can try to get into CR by June and then snapshot or two by the end of the year to get to PR by the end of the year. Any Issues with this>.

JoeAdrieu: Questiona about feature freeze in May..

Manu Sporny: Aligns with test suites.

Michael Prorock: I would like call out of a horizontal review on this schedule. Could run a proposal to lock additional features today..
… this makes CR3 in December reasonable..

Ivan Herman: don’t understand the comment on CR snapshot?.

Michael Prorock: test proposal: only additional features for data integrity add chained proofs add language for MUST specify canon method as MAY be JCS or URDNA.

Manu Sporny: Correction CR draft snapshots..

Michael Prorock: note of this timeline needs horiz review, and is probably 30 days too aggressive at minimum.

Brent Zundel: Use to be you go into CR and start over if you make changes. Now the process allows for more fluidity. You create a snapshot as you go into CR and you can make changes (non normative). i.

Ivan Herman: big practical difference: you can use echidna for a cr draft and you cannot use it for cr snapshot :-).

Brent Zundel: Sounds to me like Mike (p) is proposing feature freeze..
… Not that they are finished but that they are a locke set.

Joe Andrieu: Don’t think we are ready for a feature freeze today: For example when you send a proto VC to a signer..
… Wants to have a conversation on this before a feature freeze..

Michael Prorock: Strongly objects to any additional other than a path to feature freeze with the two things discussed above. Cool things could come from these items, but we can’t add anything complex..

Manu Sporny: Don’t want to make this decision today. Pretty sure major things are in the spec (except what Joe said). No issue will calling freeze soon..
… Totally forgot about BBS.
… people are actively working on this and and putting it out there..

Orie Steele: crypto layer is still going through IETF and that could take a long time. Data integrity CCG draft is not likely to change. Could adopt a CCG draft in its current format and hold until IETF finishes..

Joe Andrieu: @orie yep, an “unprotected” property will do the job. The goal is to have that property as a standard, so that issuer services ignore it (or never receive it) and holders know that it doesn’t travel with the VC, but is somewhere in the proof..

Manu Sporny: +1 to mprorock and orie.

Michael Prorock: Note that with BBS draft, it was beat up and led to the current work at IETF. Fine with bringing this into the features as long as its held until IETF completes.

Brent Zundel: Moving on to the topic of VC-JWT.

2. VC-JWT.

Ivan Herman: Slides start at https://docs.google.com/presentation/d/128DHWSzVxPgAhB0mq-h23_iATnbVeA4Y-JhNLjpcXJE/edit#slide=id.g1f071ce6e7e_3_18.

Orie Steele: presentation about VC JWT, PRs, and take temperature of SD-JWT.
… review of registered claim names. Make better use of registered claim names. Examples shown on slide..
… public claim names. Collision resistant names are important..
… private Claim names. Not registered. Imaging all kinds of other names to include in token that you dont care to go to a registry..
… We can agree to interpret these claim names consistently. They are subject to collusion and used with caution.
… organization_id may be an example of both good and bad.

Michael Prorock: Note these important things. Tend to see this between parties trying something out. Also see in developer docs that publish private claims with rules..
… Expect that we see similar things with VC-JWT. Developer docs with private claims..
… The other callout from previous slide. This isn’t unique to private claims, JSON-LD addresses with vocabs, but there are other mechanisms.

Orie Steele: Example from slide 91 PR #44.
… Walking through example with differences between ld+json and +jwt.

See github pull request vc-jwt#50.

See github issue vc-jwt#53.

Orie Steele: You can have properties in JSON. Everyone expects that they can be ignored if you don’t understand them..
… the JSON @context member is allowed and not required.

Manu Sporny: I missed this when reviewing PR 33. All of a sudden we made @context optional. Secondly, its not a verifiable credential or credential. Its arbitrary JSON (a JWT claim set)..
… I think its highly problematic. Missed during a review..

Ted Thibodeau Jr.: +1 manu.

Dave Longley: +1 manu.

Manu Sporny: massive -1. Believes this is the wrong thing to do..

Orie Steele: Would you prefer we call them credentials.

Paul Dietrich: manu-: I prefer we call them JWTs.

Joe Andrieu: We don’t have an unsecured media type for a credential claim set..

Orie Steele: the cty property that has been adopted has a -1.1. The one shown here doesn’t have this..

Joe Andrieu: I don’t understand why we are talking about a credential claim set that are not a VC.
… This feels out of scope. It feels like a different thing being secured..

Orie Steele: are you talking bout credential-claim-set versus credential+ld+json?.

Joe Andrieu: definition of what a VC is is not what is at point. VC data model defines a VC but that is not this (slide)..

Orie Steele: There is two parts of the spec to review together. First is the definition. Second is every normative statement that is a requirement. Those are what a VC is..

Joe Andrieu: Do you believe the stuff on the right meet those requirements?.

Orie Steele: Lets start with the definition.

Ivan Herman: say the say thing as Joe. The right hand side is not what we defined in the VC data model, except for the context which is optional..
… This is ok, but not what this working group is working on. I don’t see how this comes into the picture..

Dave Longley: Agree with manu, Joe and ivan on this. Getty very confused on the processing rules to understand this. Would have to go back to some mapping rules which I though we were moving away from.

Phillip Long: +1 with Ivan, Joe and Manu - this is out of scope..

Dave Longley: looks complicated and out of scope for the group.

Michael Jones: this came out of a desire to have VC-JWT to be simpler than in 1.1.
… There have been mappings that keep the VC identifier and the JWT identifier. This can been a complexity nightmare for implementors..

Michael Prorock: https://w3c.github.io/vc-jwt/#relation-to-the-verifiable-credentials-data-model.

Michael Jones: It was the view of the editors to have no mapping rules. So we created for v2 a native JWT representation of VC. No question that they are credentials and verifiable. They don’t use all the claims from the VC data mode..

Dave Longley: i’m +1 for recommending against using the “instead of” mapping and using encapsulation or just having the content be a credential directly, those are both reasonably clean, IMO.

Michael Jones: this makes it simpler than 1.1. It admits the mapping was a mistake and that we should use native claims directly.

Michael Prorock: a couple ways this discussion can go. Initially read the definition. Pasted into the minutes..

Michael Prorock: https://w3c.github.io/vc-data-model/#terminology:.

: credential: credential A set of one or more claims made by an issuer. A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. The claims in a credential can be about different subjects..

Michael Prorock: Read from section 1.1 in VC-JWT. Relation to the VC data model. Defines encoding rules to covert. Defines how to make use of VC-JWT specific claim names..
… I think that if we already have registered claims in JWT (mapping) lets use them..
… however, suspect that there are things in the VC data model, where it says it MUST have something that do not have registered claim names..

Dave Longley: a simplistic summary of what a verifiable credential is not a normative definition of the actual, interoperable data model.

Michael Prorock: There are stuff not covered by registered claim names. These are the things that make VCs VCs..
… question for group. What example would make this a VC? Duplicate values? Context? Can we get this info..

Manu Sporny: Normative language in the spec and these are not in the VC-JWT example..

Phillip Long: very persuasive.

Michael Prorock: https://w3c.github.io/vc-data-model/#conformance.

Manu Sporny: We have a conformance specification and states clearly what forms a conformant document..

Joe Andrieu: from the spec: A conforming document is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections 4. Basic Concepts, 5. Advanced Concepts, and 6. Syntaxes of this document MUST be enforced..

Manu Sporny: The thing on the right is not any of these things..
… The thing on the right is a JWT claim set and not what this group does. Feels like describing a JWT and trying to call it a VC..
… What is the use case here? Totally agree that mapping was a bad idea..

Dave Longley: +1 mapping was bad :).

Manu Sporny: not in our charter to do this. unless we want to come up with mappings again..

Michael Jones: From the 1.1 spec: “Verifiable credentials represent statements made by an issuer in a tamper-evident and privacy-respecting manner.”.

Michael Jones: And “Credentials represent statements made by an issuer.”.

Gabe Cohen: What will it take to make more sections normative to prevent lawyering..
… Agrees this is not a VC as described today..
… necessary to have a native JWT implementation of VC..
… There is a conception of a VC that encapsulates a JWT that is not just a JWT.

Andres Uribe: My interpretation. Normative pieces are: must be a context. must have a credential subject. When manu referred to mappings is this what you mean?.

Manu Sporny: yes.

Andres Uribe: If we step away from JSON and support protos. What does that mean for names? (protobufs).

Dave Longley: choosing a number of statements that are intended to help the reader understand at a less-technical level what something is in a specification (any spec) … does not change the rest of the spec or what normative parts are needed for interop and conformance.

Orie Steele: VC-JWT today describes the mapping from vc-credential+ld+json to a JWT. These rules say that properties can be omitted that are required in the core data model.

Michael Prorock: big +1 to what orie is saying here.

Orie Steele: implemented 1.1 VC-JWT and 1.1 data integrity. mapping problem in 1.1 was a real problem..

Dave Longley: +1 … the VC-JWT 1.1 mapping “optionality” was a good example of not “just making a choice in a standards group” when two things do the same thing… and clearly “in addition to” was better and should have been chosen..

Orie Steele: in 2.0 we described 1.1 better. We also gave unique names to the content. We should make arguments clear as this is the beginning of a rational debate..
… Is this a zero sum game for branding of what a VC is. If core data model says it must be JSON, then it prevents alot of futures people want to get to..

Dave Longley: -1 to shutting the door vs. saying v2 only does X..

Michael Prorock: even bigger +1 to what orie is saying here.

Orie Steele: Concerned that it may be pigeonholed into a dead end if we can talk about binary ….
… concurred there are numerous problems in the 1.1 vc-jwt. they cannot implement it. additional information needs to be contained to have interoperability that is not in the specific..

Michael Prorock: e.g. of what orie is saying - that difficulty in implementation is part of what lead to jws2020.

Orie Steele: intention is to clearly communicate what working group members want..
… better to describe what people are doing rather than tell them to use long names when its their best practice to use short names..

Dave Longley: sometimes there will be conflicts with technologies and choices have to be made..

Michael Jones: agree with co-editor (Orie)..
… VC 1.1 spec has a representation as a JWT..
… Have an opportunity to embrace other representation of credentials that will come out whether or not we do it here..
… Already have experience that mapping creates more problems than it solves..
… much like we worked on a native JWT implementation of a credential, we might need to develop a CBOR representation..
… Hope this parallels the JWT representation..
… reading from 1.1 spec ….
… reading definitions of credentials and verifiable credentials.
… takes objection to the statement that they are not verifiable credentials. Take objection to the statement that this is not what the group does. Please accept that these are VCs made by this work group..

Michael Prorock: Note that this is still a draft. Merging 44 doesn’t mean the workgroup has done this..
… this is not a VC because its not encoded as a JWT with a signature. we would need to see that..
… What is the bare minimum of a VC and compare with this. There are gaps with what are presented on the right hand side between it and a VC..
… But if there is a registered claim mapped to the same meaning, why would we duplicate that..
… I want to be able to use this with bigger data and consistently and right now that is difficult..
… side with Manu that we should mandate the inclusion of a context..
… semantics are important when processing this data as an interconnected graph.

Manu Sporny: We have mentioned binary expression of VC multiple times. This exists today as CBOR-LD and it is deployed and working. These arguments about binary are not convincing at all. That mechanism does do mapping leveraging the context..
… we took this approach because of the open world model and can’t expect that every term is managed by a working group..
… they do automated mapping from the data model to an arbitrary middle format. When you verify you back into JSON just like the data model..
… much less problem if that was the approach we are taking here, but we are not..
… We are saying that manual mapping was a bad idea and we should never do it again. Automated mapping has worked well..

Andres Uribe: whats the difference between manual mapping and automated mapping?.

Dmitri Zagidulin: I think the distinction between ‘manual mapping’ and ‘automated mapping’ is kind of murky…

Manu Sporny: if we have a different context for a JWT you could keep the JWT names and there would be an automated mapping because of the context the JWT people can ignore that would reconcile this method..
… There would have to be some automated mapping of some kind. But this proposal feels dead in the water to me..
… demonstrated that we can get to binary already.

Ted Thibodeau Jr.: +1 manu, throughout.

Manu Sporny: normative statements in the document are not satisfied. Just because we merged doesn’t mean we agreed..

Michael Prorock: so is it the LD part that is the issue (or lack of it in the example)?.

Joe Andrieu: I don’t think this was merged with consensus..
… as Manu said we do have CBOR LD. Pure FUD if we say we can’t get to CBOR. We can get there..
… This is not a W3C VC. In the W3C VC working group, they mean W3C VCs, which it is not. Does not meet the normative requirements in the VCDM..
… as we have said before, our job is to make choices. Having two fundamentally different data models is not effective..
… We must agree on the single model of the thing that we are securing with our different data integrity methods..

Ivan Herman: +1 to JoeAndrieu.

Dave Longley: Agree with Joe. I dont think that this limits us to add more in version 3..
… we could pick any spec and ignore normative statements and say it meets the spec..
… For example we could grab the opening statement from the JWT spec interpret this.
… The VC-JWT 1.1 rules met the requirements of the VCDM..
… Sometime when you coming two technologies to get their benefits, there will be conflicts and you have to chose between them. That’s oK and part of the standards process.

Dmitri Zagidulin: can you hear me ok?.

Dmitri Zagidulin: one second.

Manu Sporny: /me no audio.

Dmitri Zagidulin: discuss mprorocks early question. What would the right side have to look like.
… It would have to have the required VC fields. issuer and credential subject.
… the claims about the subject and VC must be separated on different nesting levels. Right side would have to maintain this..
… name in this example is the name of the VC not the name of the subject.
… given that our goal is compactness, there are ways of making context required and keeping it compact, like CBOR-LD..
… summary: Not all the required fields, and makes context optional..
… iss is a string only. but VCDM is an object..

Dave Longley: another important requirement: “Libraries or processors that support JSON-LD can process the @context property using full JSON-LD processing as expected.”.

Ted Thibodeau Jr.: resuming ~1pm ET.

Ted Thibodeau Jr.: +1 dmitriz, dlongley.

Orie Steele: we’ve been talking about data integrity and JWT as the only ways to secure the core data model - in 1.1 there was this other thing we talked about - CL signatures and other things. That existed back then, there was similar questions about whether it was or not a Verifiable Credential. Historical context, not new that we’ve had trouble determining whether something is a verifiable credential..
… CBOR-LD is not a verifiable credential but a transformation on verifiable credentials, similar to GZIP. Talked a bit over lunch, hidden in that is some important next-step types of things. A mapping to and from a VC is different from a native format..
… the other thing we discussed over lunch, there seems to be some amount of consensus that mappings were important for understanding whether you are talking about a verifiable credential. There is trivial mapping, such as credential+ld+json - these bytes are a credential. That trivial mapping seems to have some type of agreement..
… if mapping is fundamental to what a credential is, how can we constrain that (mapping) to get further agreement. If I have opaque blocks that I feed into a black box, if I get out something that looks like credential+ld+json, that may be acceptable. How much of that black box needs to be exposed, and what does this opaque format look like -w hat sort of constraints do you have..
… sidesteps the native conversation somewhat.

Dave Longley: +1 to the fuzzy idea of something that goes into / comes out of a black box as a credential+ld+json (and securing that content) being a verifiable credential.

David Waite: Just wanted to clarify something… MikeP said @context is one of the required fields, mapping layer from JSON to RDF, if issuer isn’t there, it will just map to something that isn’t an issuer. It’s the specification that creates those additional requirements..

Dmitri Zagidulin: (also has to be an object, in addition to url).

David Waite: one of the requirments we could have is it has to be a URL with same semantics… difference between binary and native formats… when you talk about CBOR as a compression algorithm in a QR Code, if you talk about IOT devices as json or RDF processing model, but they need to include URDNA, it becomes a bit untenable, wont work for some deployments, not enough physical size..

Michael Prorock: lead to possible proposal - if we can reliable go from one format into a VC-compliant document, thats ok then to say “this is a VC”. Some of this has been presented before - but we could define a vocabulary that takes in VC data model and then defines the terms that have a direct correspondence in a JWT, and uses them as defined by the context in verifiable credentials - must downselect certain capabilities.
… if that is a viable path, the other implied option is to say since we are already down selecting and since this is version 2, we could state that it must not contain a context in the vc-jwt itself - but if you are going to call it a vc-jwt, this is the context that is to be used in that conversion such that you get a compliant vc data model document.

Brian Campbell: like an implied context….

Michael Prorock: the advantage is that we can have things which just look like a normal JWT - possibly with additional required properties, that can always go back to VC data model. It also sets up from a CBOR standpoint to use those existing mappings for already defined claims, and use those existing encodings.

Dave Longley: would have to see the details of what Mike Prorock is saying, but the general theory seems like there may be a way to have that work, at least for some use cases.

Michael Prorock: implicit XSLT, but dislike it compared to other options such as not having semantics about things in core VC..

Dave Longley: +1 to … any credential+ld+json => magic transformation => JWT => magic untransformation => same credential+ld+json.

Michael Jones: I apreciate efforst to engineer a path forward, helpful to have face-to-face meetings to incubate such ideas. Could live with that mapping - that cynical Mike could then say you could define a mapping that concrete implementations choose not to use (to VC data model)..

David Chadwick: party A has a document in the VC Data Model, has the subject and optional attributes - they put a proof on it - JSON-LD, JWT proof. Pass it to party B, strips off that proof, passes it back to A. They will end up with the same document they started with nods.
… the issuance time, are not in the data model. The crypto can a different lifetime (in JWT) than the credential claims themselves - a driving privilege may be good for decades, while several licenses may need to be renewed over the years. The id of the credential becomes the issuer, then the VC property contains the VCDM..

Dmitri Zagidulin: (the only thing that gets lost in most automated mappings, is the timezone on the 3 timestamps).

Michael Prorock: that is 1.1 approach.

Dmitri Zagidulin: since JWT expresses timestamps as epoch seconds. and timezone is lost.

Michael Prorock: +1 dimitriz - the spec needs text around these items, e.g. zulu time.

Kaliya Young: he said NGI-Atlantic before mentioning JFF.

David Chadwick: We have shown this between issuers and verifiers JFF plugfest - ran through schema rules and conformed to VCDM. Put the entire VCDM and put it into the VC claim.

Dave Longley: DavidC’s approach sounds viable.

Dmitri Zagidulin: @dlongley - wait, DavidC’s approach is the 1.1 approach, no?.

Dave Longley: dmitriz: it’s a tweak on it.

Dmitri Zagidulin: what’s the tweak?.

Dave Longley: dmitriz: get rid of “instead of” is the biggest most important tweak.

Manu Sporny: +1 , value in certain kinds of mapping. Previous mapping did not work out well. Two proposals - David Chadwick’s approach is to copy without omitting, Mike Prorock’s suggestion is to define a mapping for fields to and from claims set. Concerned that translations have problems, such as dates and issuer strings. You would end up with something that looks more like a JWT. Feel David Chadwick’s approach is cleaner due to separations.

Samuel Smith: make a modified proposal - like the idea of implied @context, it allows for a broader adoptability of VCs - if for not other reason that if you made a graph; one axis people who benefit from primary intent of linked data, with end-to-end semantic interoperability.
… secured with data integrity or other proof. But for many implementations that provides little benefit with a lot of cost.
… on other axis, we have security - applications that find linked data proofs sufficient and appropriate for their needs, other find they do not benefit from a linked data representation (and need another form of security) or the data integrity proof is insufficient for their needs.
… so you now have four quadrants, but only one is satisfied when RDF is a representation. We can argue whether they are important, and if so that is the will of the working group. If we agree those others need to exist, then the implied @context helps us get there..

Dave Longley: sound like a given “intermediate securing format” can do whatever it wants … as long as when credential+ld+json (which always has @context) gets transformed … it’s lossless; you always get it back again as the same credential+ld+json..

Dmitri Zagidulin: +1 to Joe’s point, I think Sam’s current point is off topic.

Samuel Smith: you would not get the benefit of the intermediate representation. Been arguing we should have a layered approach, the cryptographic operations are distinct from the usability of the claim set. NIST does a good job where they separate IAL and AAL (assurance levels). When we talked yesterday about the issuer binding etc assurances, we are using that NIST model where you have assurance levels. What we didn’t say is what authenticator assurance[CUT].
… but those don’t belong in a claim set, they have to do with the authenticator. They may have something to do with the subject - and can be linked by the same identifier. By conflating the two, we create confusion. By making that distinction, we make it clearer for others to consume what we are defining..
… that means authenticators are metadata, and are not in the claim set or intermediate representation.

David Chadwick: point out that mike’s proposal is flawed from a security perspective - the issuance and expiry of the credential are not the same of the credential are the same as the JWT. The previous example of the driving license. If you do mappings between them, you will get in trouble..

Michael Prorock: provide a vocabulary and set of rules (e.g. around epoch time) that describes registered claims in JWTs in json-ld, and add other definitions as required that must be present in the JWT - this context must be used to translate from a JWT to a valid VC.

Michael Prorock: doesn’t disagree with David - there are mappings between some of the registered claims, and how you can do those with a JWT - it is not 1:1. There is this notion that certain other data fields would be necessary there. This gives us the opportunity to identify those, possibly add new claims if needed. Provides us a way to reconcile these two things..

Kristina Yasuda: > this context must be used to translate from a JWT to a valid VC.

Kristina Yasuda: mprorock, so now everyone who uses vc-jwt needs to do the transformation using context..?.

Orie Steele: I filed https://github.com/w3c/vc-jwt/issues/53 to cover the 3 kinds of mapping I heard..

Joe Andrieu: defer some comments on optional @context. Highlight something DavidC touched on - which is the conflation of real world credential lifetime and the VC lifetime. In my case I would argue that his example is incorrect - the lifetime on my physical driving license is that of the physical credential and not the driving privilege on at a DMV. A bunch of the JFF folks.
… used the ID of the diploma, we need to resolve that.

David Chadwick: @JoeAndrieu. I know how. The metadata of the proof is separate from the metadata of the credential.

Joe Andrieu: if @context is not required in that VC property, how do you round-trip on a credential with a custom @context..

Michael Prorock: if you go from a VC in JSON-LD to a VC-JWT,….

Joe Andrieu: so I think it may fail that black box.

David Chadwick: think I know how to solve this issue - the claims about the subject and in the VCDM are distinct from the claims used for the proof.

Mahmoud Alkhraishi: to clarify you mean metadata about credential subject vs metadata about vc?.

David Chadwick: a number of incidents where we talk about claims of the VC that are actually metadata of the credential, has its own metadata such as its serial number or issuance data.

Orie Steele: See this issue filed by ivan…. seems relevant: https://github.com/w3c/vc-data-model/issues/1044.

David Chadwick: think JFF got it right when they put the certificate identifier as the credential identifier, each proof would have a different identifier but the credential data would have the same number.

Kristina Yasuda: see https://github.com/w3c/vc-jwt/issues/53.

3. SD-JWT VC.

Orie Steele: (slides) SD-JWT VC? Relevant slides to feature freeze and mapping conversations, as well as to the governance framework and ‘what the world things’ about verifiable credentials.

Kristina Yasuda: wrt signing json-ld payload using sd-jwt: https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/212.

Kristina Yasuda: feedback welcome.

Orie Steele: temperature gauge emoji indicates that we are trying to gauge enthusiasm. Potential debate over typ/cty.
… how can these parameters help us here. content type (cty) vc+sd+jwt - draw attention to the payload side of this window, ‘cnf’ claim may be related to holder binding.
… Feature Freeze is Coming.

Kristina Yasuda: don’t think sd-jwt vp makes sense…..

Ted Thibodeau Jr.: slide should be advanced.

Orie Steele: VP question - you haven’t seen a VP-JWT yet, we have statements in VC-JWT which refine those rules, restating them..
… want to ask - for SD-JWT, does the VP format look different or similar to VC-JWT, is there a way to indicate the entire token is a presentation rather than a kind of payload..
… JOSE-WG is back, asked IETF to work on standardizing JSON Web Proofs, CFRG is working on BLS 12-381 some intention for JWP to use that.
… pointing this out to be clear that this is all separate from the item on whether BBS should be brought in before feature freeze.
… May decide to bring it in if JOSE WG finishes, or if it is deferred after rechartering independent of IETF..

Michael Jones: JOSE is chartered to work more broadly than just JWP, working on algorithm review.

David Chadwick: quite like the SD-JWT work now, it has significantly improved, IMHO better than the ISO way of doing this. I think we should regard a SD-JWT as a different proofing mechanism of a verifiable credential data model document . We should define how you convert a VCDM to and from SD-JWT. That should be done within our working group rather than the IETF. The current IETF example is not a good example - doesn’t even have an @context.
… I think that is what we should do, think it would be valuable work..

Kristina Yasuda: ietf sd-jwt-vc example is for credential-claims-set+json in v2 :P.

Joe Andrieu: echoing what David said. I think it is important that we minimize the root data objects that we are securing using properties/proof types in credential+ld+json. That is what is coming out of Merkle world at reboot. Can we do the selective disclosure on the current VCDM with minimal changes. Concerned if the right side of the slide (SD-JWT) has the black box model. Once they disclose, they can’t convert back to the VC.
… selectively disclosed terms on the recipient can’t jam it into the original VC because it is not there.

David Chadwick: when it converted back you get a VCDM of the revealed bits only, the signature is over the whole lot..

Kristina Yasuda: my suggestion would be let’s not talk about VPs with sd-jwts.

David Chadwick: +1.

Kristina Yasuda: i mean VP that uses sd-jwt mechanism to selectively release claims in a VP.

Kristina Yasuda: jwt-vp can contain sd-jwt-vc, no worries.

David Chadwick: The VP should be the way of selectively disclosing bits of the SD-JWT.

Michael Prorock: the closer we keep or provide for translation for normal JWTS, CWTs, and stuff like that - the easier it is to leverage this stuff immediately when it comes out without a lot of work. When I think of cross-ecosystem work between IETF and W3C, that is one of the advantages and one of the reasons I’ve been pushing for something which is both a JWT and a VC..

David Waite: Talking about a black box model, we don’t have to have more permutations / combiations. Black box would be a part of the proofing mechanism, that’s how selective disclosure works..
… For anything that’s not an RDF canonicalization model..

Kristina Yasuda: where are we with content types for presentations..?.

Orie Steele: JWP - has somewhat the same model as SD-JWT, where the holder derives a presentation and presents that forward. BBS Data integrity proofs have that property as well. Similar in that they have a 1st credential representation which is the full credential as given by the issuer, and a second form which is presented to the verifier.
… claims piece - not sure this is still part of JWP, idea that I can tell you the kinds of fields which are in my progressive disclosure payload, may know information about what a credential is without selective disclosure.
… gets into how much you are required to reveal, which is a similar concept on all formats. The type of data integrity proof protected credential is revealed, that type communicates some of the properties you would expect. There’s field names in SD-JWT and JWP.
… there seems to be a bit of a key/value pair concept repeating here, they don’t always play super-nice together. You might need to transform an object to get key-value pairs. You have to be careful when you do that mapping and with that guidance..
… the more the DM constrains the mapping, the more the other side has to constrain things, which was the sort of thing that made people really unhappy with 1.1.

David Waite: JWP is early, its in flux, the claims part is a part of JPT JSON Proof Tokens, that would have the most bikeshedding..
… We have the flexibility to say that this claims isn’t needed, a different mechanism could be used, even down the point where you say the payload is NQuads. The claims on this slide are an effort to get what you get from JWTs today. This is in flux and possibly at a lower level than we’d want, similar to conversations about the body being a JWT claim set or JSON-LD..

Kristina Yasuda: update on SD-JWT side: the approach has changed quite a bit since TPAC; there have been a lot of improvements to the format. The current approach has implementations - contrary to previous approach, the current approach might not need explicit guidance to use with verifiable credentials as long as you understand the sd-jwt claims. Feedback welcome on whether this hypothesis is true or not.
… there is a market need to answer what is a SD-JWT VC. Either we say look at both specs together because it is clear, or if not we need to decide which working group that work happens in.

David Waite: From what I’ve seen of SD-JWT, it would be more of handling claim set and JSON-LD without defining rules beyond how to take SD-JWT how pieces have been redacted/filled in as a JSON document and interpret that as JSON. Given that we have content types that are JSON, where pieces can be adjusted, there might not be guidance there. There could be guidance around selective disclosure requirements and how things are mandatory to disclose..
… That’s probably where people would still need guidance..

David Chadwick: +1.

Brian Campbell: generally +1 to dwaite.

Kristina Yasuda: for those interested: https://docs.google.com/presentation/d/1h4za0rEf2FFd3ZvpN8kIfTR15jF9GPQMXAZ7miIwJpg/edit#slide=id.g18679a2d900_0_0.

Manu Sporny: the differences between SD-JWT, BBS into the group, what is the overlap, how do they differentiate from one another. BBS is designed so that you can do selective disclosure but not do repeatable signatures.

Samuel Smith: q.

Manu Sporny: one of them seems to have better properties than the other, with the problem with BBS being on a different path, not NIST crypto. Highlighting that this question on differentiation is going to come up. Imagine SD-JWT’s reason would be NIST crypto. If we pull BBS+ in, people will understand that it is not NIST approved, signals that some parties may issue it even if they can’t accept it, JWP is hardest to answer.
… feels like we need to have all these conversations in the next 1.5-2 months, doesn’t feel like we will have stable enough representations to go into CR in the next four months. Which may be ok, but then we are already thinking about re-chartering to including that work.

Brent Zundel: Likes to do everything - mdoc, SD-JWT, BBS, etc. Having said that, company roadmap includes a VC-spec compliant, BBS-protected selective disclosure JWP. May need to see about resourcing to get those specified.

Kristina Yasuda: IETF is march 25th.

Michael Prorock: fortunately, IETF meeting coming up - we can talk about things in a note if it feels that something will not make it. Things like SD-JWT are very interesting to me. I think we can be very practical, the week after IETF if they have not gotten a signal from IETF, we table it. I think we have enough to go in and get a usable 2.0 spec..
… maybe we recharter or go into maintenance mode, until we have input documents ready.

Orie Steele: for SD-JWT, the ability to do selective disclosure with the existing toolchain and support for the object data model are all really important. A major distinguishing factor with SD-JWT, JWP with BBS, Data Integrity for BBS. JWP: waiting for IETF, DI you are waiting for IETF and doing canonicalization..
… Totally fine to decide we are not going to get to JWP in this charter, may not get to BBS+DI in this charter, it would be a massive mistake to not get SD-JWT into the current structure some way due to the positioning of it within the ecosystem and path to deployment on existing technologies.

Brian Campbell: following a bit - intent on SD-JWT is to operate on a claim set with the ability to redact claims within that set. It shouldn’t be disallowed,.

David Waite: lost you brian, be prepared to repeat.

Brian Campbell: the goal of SD-JWT is to be almost drop-in usage for existing JWT, really just a redaction technique for content in claims themselves. Almost as though VC-JWT could just leverage SD-JWT without any particular guidance in place.

Samuel Smith: q.

Kristina Yasuda: We talked about data integrity, we talked about VC-JWT.
… There may be confusion about how ACDC relates to the other things.

4. ACDC.

Phil Fariller: A question came up about the proposal to have an assumed @context.
… For ACDCs we could create a proposal on how to secure VCs with ACDCs.
… We wondered if the assumed @context will go into the VCDM spec.
… ACDCs would be peers to JWTs and data integrity.

Samuel Smith: ACDCs are proof containers.
… If you want to include a full-blown VCDM object into an ACDC proof, you could do that.
… The ACDC itself doesn’t care what’s in its payload.
… They’re used to secure ISDL documents, for instance, which will never be JSON.

Samuel Smith: iXBRL documents.

Samuel Smith: Xml Business Reporting Language.

Kristina Yasuda: Thanks for bringing clarity on that topic.

Manu Sporny: We haven’t had the discussion about an assumed @context yet.
… The problem about an assumed @context is then you’re locked into that version forever.
… It can solve some problems and it can create some problems.

Brent Zundel: Are we talking about specifically securing VCDM objects or also other types.

Phil Fariller: We also want to secure other content types.

5. Ready for PR Issues.

Kristina Yasuda: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3A%22ready+for+PR%22.

5.1. ‘issued’ vs. ‘validFrom’ (formerly ‘issuanceDate’) (issue vc-data-model#965)

See github issue vc-data-model#965.

Manu Sporny: As David Chadwick pointed out earlier, there are different kinds of issuance dates.
… There is the credential issuance date and the signing date.

David Chadwick: The proof should have its own issuance date and expiration date.
… That’s different from what’s in the credential.

Kristina Yasuda: There is agreement that these are separate.
… That’s true both about the credential and how it’s secured.
… This issue isn’t clear enough on this point. I’d like to close it..
… We need guidance in the spec on the differences.

David Chadwick: If we do that, that would solve everything.

Kristina Yasuda: Would you like to do a PR, David?.

David Chadwick: Yes, I’d be glad to do a PR.

Joe Andrieu: There’s a real-world thing I have called a bachellors of science.
… That’s different than the credential representing the bachellors.
… There is naming confusion between the three things.

Kristina Yasuda: Is there an issue for that?.

Ted Thibodeau Jr.: TallTed: the diploma is distinct from the degree.

Joe Andrieu: We need to find a way to talk about this.

5.2. Protecting integrity of @context (issue vc-data-model#956)

See github issue vc-data-model#956.

David Chadwick: When I do the PR, Joe, you can suggest edits to the wording.

Manu Sporny: I need to get to this.

5.3. Proposal: Chaining VCs via links and digests (issue vc-data-model#952)

See github issue vc-data-model#952.

Kristina Yasuda: We want to see concrete text to make progress.

Dmitri Zagidulin: This is the concrete text.
… It’s ready for discussion.
… The proposal is there under straw proposal.

Kristina Yasuda: I’m assigning this to Dmitri.

Joe Andrieu: the “credential” related issues: https://github.com/w3c/vc-data-model/issues/1009 and https://github.com/w3c/vc-data-model/issues/991 and https://github.com/w3c/vc-data-model/issues/1012.

Brent Zundel: Once it’s ready for concrete changes to the spec, raise the PR.

Kristina Yasuda: We’re getting into feature freeze. If you want this in V2 it needs to happen soon..

5.4. Verification of multiple credential schemas (issue vc-data-model#950)

See github issue vc-data-model#950.

Gabe Cohen: There is a PR.

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

5.5. what is attribute ID in the verifiable credential? (issue vc-data-model#946)

See github issue vc-data-model#946.

Kristina Yasuda: This needs clarification in the spec.
… Is anyone willing to write the clarifying text.

Manu Sporny: I can try.

Orie Steele: He’s asking about what you should expect it to be and how should you handle it.
… This is related to the URL vs. URI confusion.

David Chadwick: I have an issue with the “parts of” wording.

Dmitri Zagidulin: (the question that almost all devs new to VCs ask is - 1) is ‘id’ required? 2) is it /supposed/ to be globally unique? Or can I use like a database row # for the id?.

David Chadwick: The credential schema should be one thing.
… There’s a disagreement there.
… I don’t think there’s agreement that Gabe’s proposal should be accepted.

Dmitri Zagidulin: Maybe this text belongs more in the Implementation Guide.
… I think we want to add it in the spec.
… Is it required and must it be globally unique?.
… We need guidance to say that it’s not required and that it should be globally unique.
… If absent, use the signature string as an ID.

Joe Andrieu: We call them URIs. We refer to RFC 3986..

David Waite: There’s a normative reference to the WhatWG specification.

Kristina Yasuda: If you’d like to revisit, please file an issue.

Brent Zundel: Yesterday we had a discussion about IDs.

5.6. Add “credential boilerplates” as examples (issue vc-data-model#935)

See github issue vc-data-model#935.

Orie Steele: Developers copy the examples and change them.
… There are several problems in our examples that make them not valid JSON-LD.
… I want them to have no @vocab-extended terms.
… This issue is an attempt lead developers gently into this reality.

Manu Sporny: We need to give people a nice gentle introduction.
… Maybe this belongs in the Implementer’s Guide.
… The base verifiable credential is pretty much useless.
… I’m concerned that people won’t be patient and read through all three examples.
… I’m concerned about adding examples that are not where we want people to end up.

Brent Zundel: I think that starting with basic boilerplate and gradually getting more complex is something I find useful when reading specs..

Orie Steele: I agree with that statement.

Manu Sporny: Our present examples try to exercise too many spec features.

Orie Steele: The first example cannot have two contexts.

Paul Dietrich: As a developer, I will search the examples for the features I want.

Dmitri Zagidulin: +1000 specs can /never/ have too many examples.

Paul Dietrich: I’m a fan of having numerous examples.

Ted Thibodeau Jr.: We can include links to spec text that we want people to read in the examples.

Manu Sporny: Let’s use some real-world examples.
… For instance, a simple open badge example.
… If they copy/paste them, they’re going to work.
… It’s a lot of work to go through the spec and revise the examples.
… We can have a “start here” section.
… It would be good to have a section in the spec saying how to move through the developer cycle.

Kristina Yasuda: I disagree with real-world examples in the core spec. But it’s fine to have them in an annex..

Orie Steele: +1 kristina.

Kristina Yasuda: We don’t want to distract readers.

Michael Jones: That’s the approach we use in the SD-JWT spec.

David Chadwick: I think I’ve now received conflicting instructions.
… I was asked to describe the terms of use used by Train.

Kristina Yasuda: I see them as being different.
… Adding properties one by one demonstrates that they’re useful.

Orie Steele: I think its a judgement call, and its possibly a good idea to start with a real world example for scenarios we have never seen….

Kristina Yasuda: if that is possible….

Manu Sporny: If we have a section on “how to get started” that builds things up bit by bit it can be early.

Orie Steele: I will do individual PRs for the examples.

5.7. (issue vc-data-model#919)

See github issue vc-data-model#919.

Kristina Yasuda: What’s the status of this, Gabe?.

Gabe Cohen: I don’t think there’s consensus. I can close it..

Joe Andrieu: I think this has been taken over by the assurance conversation..

5.8. Define policies for directory of a related work (issue vc-data-model#909)

See github issue vc-data-model#909.

Manu Sporny: We had consensus to define a directory of related work.

5.9. credentialSchema and Selective Disclosure (issue vc-data-model#890)

See github issue vc-data-model#890.

Orie Steele: A problem occurs if, as an issuer, I commit to a credential schema then present to you a selectively disclosed credential that doesn’t match the schema that I committed to.
… This is best addressed by explaining the situation to people.
… And you can design your schema so nothing bad happens.
… That’s the best we can do.

David Chadwick: This can be solved by making every property optional because then everything conforms to the schema.
… But that’s not right for mandatory fields.

Brent Zundel: This sounds like potentially a better fit for the Implementer’s Guide.
… It can say that the schema you’re issuing to needs to allow selective disclosure on the other end.

Oliver Terbu: There’s another possible solution using JSON schemas.
… For instance, it can express “one of”, “many of”, etc..

David Waite: There may be different requirements for the full-blown credential and the credential you present to people.
… You either need a schema that can represent both or two schemas or to decide that one of them is out of scope.

Joe Andrieu: What you just said hurt my brain in a good way.
… The issuer has to decide what is selectively disclosable.
… The issuer has to put it into the math to enable it.

Orie Steele: The issuer can express its intention for mandatory-to-disclose fields and protect them.
… We can write a description of how it works.
… The credential schema may be useful for this.

Samuel Smith: In ACDC we use the combination operations of JSON schema, including nesting.
… This gives the presenter a high degree of flexibility.

David Chadwick: in the evidence work we’ve done, the evidence contains the name & address of the subject.
… Sometimes unintended disclosure can occur.

Orie Steele: what david is saying is correct, but probably an example is needed to communicate it best..

Brent Zundel: This is happening with a different mental model of what the issuer needs to do.
… In my mental model, the verifier knows the schema because it’s public information.
… As a verifier, I can request the subset of the information that I want.
… described as a JSON schema.
… It’s a different mental model.

Phillip Long: And the holder can choose to disclose what they wish in that response to the verifier?.

Samuel Smith: You can do both together. That’s how we do it..

Brent Zundel: What’s actually happening is the intersection.

Orie Steele: For the notes, https://identity.foundation/presentation-exchange/#presentation-definition.

Kristina Yasuda: I think both are needed.

Brent Zundel: +1, both are needed.

Kristina Yasuda: What is in scope for the data model document is the schema for the issuer.
… How the verifier asked the wallet for what it wants is more at the protocol layer.
… This is a really complicated topic.
… We’re now implementing systems with selective disclosure.
… We’re realizing how many things it touches.

Orie Steele: +1 kristina.

Kristina Yasuda: We should try to describe the aspects that people need to consider when using selective disclosure.

Steve McCown: They may need to see that I live in the state. They don’t need to know my organ donor status..
… Without selective disclosure, we’ll give them everything in hopes they don’t use everything.
… I want selective disclosure to be the norm.

Brent Zundel: Sometimes the verifier won’t use the schema because it doesn’t care.

Joe Andrieu: I think we’re talking about four different schemas at least.
… 1. The credential schema.
… 2. A schema describing derivable claims.
… 3. The verifier’s desired schema as a result of a presentation request.
… 4: The intersection of 2 and 3.

Manu Sporny: I’m concerned that we’re waving our hands around this.
… A number of us are working on these things.
… They’re not in protocols. They’re not in implementations..

Orie Steele: i disagree, we have this functionality in 1.1, and people are already using this property without good guidance..

Manu Sporny: Just like we added things to VC 1.0 that we’re now taking out because we haven’t figured out how to use them.
… It’s OK to see “We’re working on these things”.

Phillip Long: +1 to Manu’s concern that we need to understand the four perspectives on use cases in the real world..

Brent Zundel: I disagree that this isn’t in protocols and implementations.
… Anyone who has implemented Presentation Change has done this.
… We’ve implemented this. It’s what we’re using..
… Maybe the VC spec could talk about this..

Steve McCown: How about a selective disclosure use case for the Holder’s local address? The local library doesn’t care about age, but they do care about residence. This is because local residents can usually use the library for free while non-residents often need to pay a fee..

Orie Steele: I disagree that we shouldn’t provide guidance.
… There are interoperable implementations using these properties.
… I’ve worked on Joe’s cases #1, #2, and #3.

Brent Zundel: #4 is presentation submission from the Presentation Exchange spec.

Orie Steele: Even if the guidance is just a heads-up that these things are happening in the wild, it’s useful to say that to people.

Michael Jones: brent, you talked about people using presentation exchange in protocols, that’s certainly true. I will put on my charter hat and said we intentionally put specification of protocols out of scope. I’m fine saying “this is how things are done in some protocols” without picking winners..

Brent Zundel: Yes, I was speaking to more of the how in the data model not in protocol perspective..
… I’m talking about saying what objects are passed back and forth - not how they are passed back and forth.

Phillip Long: Are we saying that the holder’s response to the verifier can choose to add or omit claims?.

Orie Steele: yes.

Orie Steele: It depends, but generally case 2 and case 4 address those concerns.

Manu Sporny: I wanted to underscore the points Mike Jones made.

Kristina Yasuda: i am uncomfortable saying deny/accept, i am ok saying this is when the schema can be used.

Kristina Yasuda: deny/accept is policy….

Manu Sporny: It’s fine to talk about data elements used in protocols.
… But we should not slide down the slope to defining protocols.

David Chadwick: The current credential schema addresses Joe’s #1.
… We add a new property, which is the disclosable schema. That’s #2..
… That’s where the VCDM ends.
… That’s my concrete proposal.

Orie Steele: The concrete proposal is good, even if i don’t agree with it..

Manu Sporny: Is the “disclosable” property being used today?.

David Chadwick: No - it doesn’t exist today.

Orie Steele: This would make it unambiguous.

Joe Andrieu: If we don’t have implementations, we’ll have to cut the work anyway.

David Chadwick: We have to specify things for people to implement them.
… I have implemented #1.
… There’s the problem that the verifier receives a credential that doesn’t conform to the schema.
… We’d say what the schema is that the holder would get and what the schema is that the verifier would get.

Phillip Long: How is the issuer going to be in a position to know what any given verifier needs?.

Brent Zundel: Assigned to Orie.

5.10. What is the action associated with issuing/creating a Verifiable Presentation? (issue vc-data-model#887)

See github issue vc-data-model#887.

Manu Sporny: If someone else wants to take #887, that’s fine.

Brent Zundel: kristina: all of the other ready-for-PR issues have assigned people.

Kristina Yasuda: If anyone else wants to jump in, that would help offload work from the editors.

Orie Steele: We need easier issues!.


6. Resolutions