Verifiable Credentials Working Group F2F, 2nd day — Minutes

Date: 2022-09-16

See also the Agenda and the IRC Log

Attendees

Present (VCWG): Ivan Herman, Jeremie Miller, Brent Zundel, Joe Andrieu, Kristina Yasuda, Hiroyuki Sano, Orie Steele, David Ezell, Geunhyung Kim, Kevin Dean, Justin Richer, Ted Thibodeau Jr., Shigeya Suzuki, Manu Sporny, Phil Archer, Steve McCown, Gabe Cohen, Oliver Terbu, Ryan Grant, Chris Abernethy, Antony Nadalin, David Chadwick, Michael Jones, Dave Longley, David Waite, Samuel Smith, Shawn Butterfield, Wayne Chang, Mahmoud Alkhraishi

Present (RCH WG): Pierre-Antoine Champin, Ivan Herman, Gregg Kellogg, Ted Thibodeau Jr., Manu Sporny, Phil Archer, Markus Sabadello, Aidan Hogan, Dave Longley, Mahmoud Alkhraishi

Regrets: Charles Lehner

Guests: Jay Kishigami, goto, Reisako Hamano, Paul Dietrich, Tatsuya Igarashi, Wonsuk Lee, Michael McCool, Hiroyuki Sano, Osamu Nakamura

Chair: Kristina Yasuda, Brent Zundel

Scribe(s): Joe Andrieu, Kevin Dean, Manu Sporny, Dave Longley, Wayne Chang, Kristina Yasuda, Orie Steele

Content:

• 1. Holder Binding.
• 2. Joint Session with the RCH Working Group.
• 3. Delegated and Multi-Party Credentials.
• 4. Intro to SD-JWT.
• 5. VC Test Suites.
• 6. Internationalization.
• 7. JSON Schema and VC Data Model.
• 8. Editorial Work Mode.

Brent Zundel: Good morning. Still need some scribes.
… let’s get started.
… we are meeting under W3C IPR policy, so if you have something you want to patent, don’t tell us.
… We are also operating under the ethical code of conduct, so be nice. Just like you were yesterday.
… Today we are covering … staring with Holder binding, from Oliver.
… Then a joint session with the RCH working group.

Kristina Yasuda: more this afternoon, … finishing up with internationalization by Shigeya.
… If we need follow up or another session, let us know.
… maybe we can fit it in.

1. Holder Binding.

Ivan Herman: Slides:.

Oliver Terbu: Ok. Are we ready?.

Ryan Grant: slides: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_105.

Oliver Terbu: First few slides is a recap of current roles in VC data model.
… Everyone is likely familiar with this diagram. it describes the role in the model.
… Issuer creates a VC, issues to Holder, holder presents the VC to a Verifier (typically as a Verifiable Presentation).
… I’m not super happy with this diagram because it leaves out some things.
… For example, the intended holder and the subject.
… From the current specification, a holder.
… Subject: … (quotes from the spec).
… Credential subject is mandatory, but each credentialSubject may contain an identifier.
… I have no problem with that, it’s good to be able to skip that ID for privacy reasons.
… Just note you don’t always have that ID.
… What is a VP?.
… A VP is created by a holder. The holder property is optional. It’s not even that. Because there is no normative language for the holder.
… That’s something that we definitely need to address.
… Remember the VP may or may not include a holder property (which is also not normative).
… Let’s talk about holder binding.
… Many of us in our group understand this.
… A VC can be created by anyone…
… The VC can be presented by anyone.
… We don’t have semantics other than tamper-evidence and authorship.
… We do not guarantee that the holder is the intended recipient.
… Verifier needs to perform additional steps to apply business rules to figure out if holder == subject.
… This is a common use case for verifiers: to prove that the credential was presented by the intended holder.
… I create a VP, sign it, give it to my future employer.
… This is a common use, but may not work for everyone.
… If the subject ID is the same as the holder property.
… Holder property is non-normative. We should fix this.
… It is unclear who is the holder if the holder property is omitted.
… The Credential Subject ID is optional (which is good).
… So a verifier would typically verify, if holder id = subject id & DID document of holder contains the verification method from the VP proof, and that proof is valid, then the verifier can know is the actual holder presenting the credentials.
… This doesn’t work with anon-creds and BBS+, but it is the simplest model.

Ted Thibodeau Jr.: I’m concerned about a few pieces. We explicitly decided that the holder need not be the subject.
… the subject is whatever entity those statements are about.
… may be explicitly identified or not.
… We explicitly decided that holder was NOT a statement in the credential because several of the initial use cases were for scenarios where the holder was NOT the subject.

Orie Steele: In general +1 to this… we need to create explicit clarity regarding the cases where these id values match..

Oliver Terbu: Agreed. I’m just pointing out that this is a common pattern.

Antony Nadalin: if the holder is not the subject how is holder authentication done?.

Ted Thibodeau Jr.: but that’s part of the problem.

Orie Steele: +1 to what oliver is saying, this presentation is about the case where the holder is the subject… its not to say that HAS to be the case..

Ted Thibodeau Jr.: if folks are doing the wrong thing, we want to fix that.
… The presenter at the time they present it, is the holder.
… The presenter is never in a credential, nor in the VP either (as far as I recall).

Orie Steele: the presenter IS identified in a credential WHEN the holder matches the subject..

Kevin Dean: the way I see this, coming in relatively late.
… the absence of the holder means that anyone can hold it.
… In the use cases that we have identified, the subject is far more critical than the holder.
… Cases where the credential can be passed around.
… And it doesn’t really matter how has it at any point.
… It matters what it says about the subject.

Ted Thibodeau Jr.: +1 to speaker.

Kevin Dean: That’s important flexibility.

Orie Steele: yes, +1 thats how it works today, afaik..

Oliver Terbu: Agreed.
… This isn’t about mandating any approach. This is what I’ve seen.

Kevin Dean: Thanks, Orie..

Oliver Terbu: I agree that many use cases do not require it.

Orie Steele: +1 to what oliver is saying again..

Oliver Terbu: I didn’t mean to argue FOR this, but just to point out some gaps.

Dave Longley: sounds like a lot more agreement than disagreement here so far.

Manu Sporny: just for historical context.
… holder has no normative language because we added it later.

Orie Steele: +1 Manu.

Manu Sporny: we expected we would add something in 2.0 to clean that up.
… I think what we’re hearing is that we could do a better job describing how holders fit into presentations.
… Might help illustrate this use case if we need the holder defined specifically.

Kevin Dean: We should formalize it, though. Absence of holder: anyone can hold it, regardless of subject. Absence of subject: statement generic or anonymous, regardless of holder..

Manu Sporny: for example, a VC that specifies a parent and who should be holding it.
… there’s not guidance in the VC data model about what you are supposed to do it.
… Do you have a use case where we need holder defined normatively.

Oliver Terbu: one example would be: I have multiple DIDs. I get credentials for one of those IDs, and I need to present to a potential employer, but I want to use a different VC.
… current spec has language for explaining for claiming DIDs are “sameAs” something like that.
… There are many many more.
… It’s tricky when we don’t have values for subjects and holders.

Orie Steele: +1 to making id more required… making it optional doesn’t buy what people think it does..

Oliver Terbu: later in the slides, I’d like to talk about some specific things.

Manu Sporny: it would help if we had a clear set of use cases.

Orie Steele: I’m queued to provide a use case for holder/subject binding in a supply chain use case.
… you’ll often have VCs from supply chain about each other, as part of compliance process.

Antony Nadalin: in mDL Holder verification is intended to be at least equivalent to the attended mode, and example is using issuer provided portrait image.

Orie Steele: For example, I might have a cert about the quality of the farms I’m buying from.
… and a credential about my facility.
… and I might present those credentials, where I am the subject, other where I am not.
… This is where we would like to say… about the holder is SOMEBODY.

Joe Andrieu: I want to clarify what you said, there is already delegateable stuff?.

Kristina Yasuda: in the afternoon, a presentation on it.

Joe Andrieu: When you do a presentation, it’s a fact that you are the holder when you present. It’s functional, which is why it isn’t a property anywhere, when you make it a property, you lose that functionality.

Ted Thibodeau Jr.: +1 to Joe.

Joe Andrieu: That isn’t a good delegation use case, MANU.

David Chadwick: privacy aside, we can regard a VC a bit like a public key certificate: anyone can pick it up.
… the trick is proof of control.
… at the point of presentation, can the presenter prove they control the crypto.

Orie Steele: related issue regarding disambiguating holder, https://github.com/w3c/vc-data-model/issues/902.

David Chadwick: If I present something that says I’m the director, then I need to prove possession (not just as the subject, but that you are related).

Ted Thibodeau Jr.: “authorized to present” should not be by specifying “holder” within the VC; should be by specifying “valid if presented by” or similar.

Orie Steele: +1 TallTed.

Dave Longley: TallTed: yeah, something like that.

Pierre-Antoine Champin: seems to me when the holder matters, this should be somehow claimed, where the holder is a subject.

Dave Longley: “acceptablePresenter”.

Manu Sporny: Agree with PA that that’s an option..

Kevin Dean: I want to talk to the credential that someone is a member of the board.
… The usefulness of that credential is independent of who holds it.

Justin Richer: there are two different questions: “Is the presenter allowed to present this?” and “is the presenter the subject?”.

Orie Steele: +1 justin_r !.

Dave Longley: +1 to justin_r … but we may only need one more element to express the former since the latter may already be easily determined.

Yan Zhang: for a verifier to prove something, a particular good is related to IP on chain.
… This is hard to prove.

Ryan Grant: +1 justin_r.

Yan Zhang: It’s helpful to reserve a field where we can say something about whether or not the presenter must be the subject.
… I think we can leave this in a limbo mode if we reserve a field for future use.

Justin Richer: dlongley: it seems to me the second one is the harder one because it requires outside knowledge about the subject.

Justin Richer: dlongley: otherwise the security comes down to only handing VCs to the subjects and nobody else.

Dave Longley: justin_r: yeah, i guess it depends on whether you can do simple identifier equivalence or not.

Justin Richer: dlongley: good point, I was assuming a world with pairwise IDs everywhere, as a starting point.

Dave Longley: justin_r: yeah, depends on the use case / privacy requirements..

Justin Richer: dlongley: agreed.

Oliver Terbu: proof of possession is also hard to prove in a canonical way.
… the diversity of proving control and that I’m the intended holder.
… Consider VC issued to Alice, Alice gives it to Bob.
… Bob gives it to Verifier.

Yan Zhang: just mark whether this VC is supposed to be bond to a subject or not..

Oliver Terbu: Verifier doesn’t know if Bob is the intended holder.
… currently there is something about holder binding.
… We had a bunch of issues about this to make the binding more explicit.

Ted Thibodeau Jr.: University Degree identifies the recipient as the Subject. Presenter/Holder doesn’t matter, except that if the Presenter is claiming the Degree as their own, they must be identified as the Subject..

Oliver Terbu: what is asked that the VP is presented by the intended holder.
… It can get more complicated than this.

Antony Nadalin: holder can be a device and device can have attestation.

Oliver Terbu: For example, when the VCs have multiple IDs.

Orie Steele: +1 nadalin.

Oliver Terbu: Or consider the alsoKnownAs property.

Orie Steele: people are not devices, both deserve the right to ids..

Dave Longley: +1 to device use case … there could also be “bindings to a type of device” (as opposed to a specific one).

Ted Thibodeau Jr.: “Holder Binding” is problematic from the start.

Oliver Terbu: let’s try to define what holder binding really means.
… A way to validate the intended holder is the presenter of a VP.

Dave Longley: “Presenter binding”.

Oliver Terbu: We need to bind: they might be the subject. They might be claims made by the issuer.

Ted Thibodeau Jr.: “Presenter binding” is better, but “binding” also isn’t right.

Oliver Terbu: The holder of the VC, even though there is no holder identifier, presents a proof.

Dave Longley: TallTed: agreed.

Oliver Terbu: I hope this meets the sense of the group.

Joe Andrieu: of what holder binding is.

Joe Andrieu: I don’t know how much of this is easily adjustable, or if there is profound disagreement. VCs are statements, if we are going to bind holder to this, feels like it might be censorship. There might be things in here interpreted as business rules, but VC itself is just a statement. I don’t know if we should be empowering idea of intended holder.

Dave Longley: “acceptable / intended presenter” seems better here.

Oliver Terbu: a lot of people deployed solutions based on the model, where they want to check if the VP is issued by.
… check if the VP is issued by the subject.

Antony Nadalin: mDL has the normative concept of holder of the mDoc.

Oliver Terbu: There is one proposal to …
… Holder binding should not be tied to the VC, but maybe rather at the VP point.
… We might be able to use NIST 800-63-3.
… But that doesn’t deal with the actual binging mechanism.
… Maybe we could use it in the VP proof.
… But then, even if you verify the VP, you don’t know that it was presented by the right party.

Ted Thibodeau Jr.: …“intended presenter”.

Jeremie Miller: A critical function for VPs is replay prevention, and that is typically an inherent feature of holder binding but IMO should be treated separately.

Oliver Terbu: Reusing the evidence property might work, but it isn’t defined at VP level.
… I would suggest, creating a new VP/holder binding mechanism.
… Potentially restrict how the credential can be used.
… binding the holder to the VP with maximum flexibility.
… a list of requirements.
… first, allow verifier to.
… [too fast, check slides].

Jeremie Miller: a VC including an ephemeral public key provided by the holder, such that that key has to be used to sign a VP, is only for replay prevention and does not have to “holder binding”.

Oliver Terbu: It should be able to create VCs and VPs without holder binding.

Kristina Yasuda: let’s look at the concrete proposal.

Oliver Terbu: based on discussion, I came up with a proposal.
… add holderBinding to VC.

Orie Steele: manu we have another issue that tracks the array case for “issuer”, “holder” and “subject”… I think array vs object vs string id should be handled consistently in the core data model.. https://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660.

Oliver Terbu: include the following that includes a type property about how the binding can be verified.
… The holder binding information may also include information about VPs, such as references to VCs.
… for example, it might define that a particular key is checked against a property in the VP.
… that’s the proposal.
… I want to guide the verifier to understand which holder binding method applies.
… There might be binding methods where there are agreements.
… That’s basically my proposal. That would address the concerns raised.

Brent Zundel: chair hat off, establishing a standard method for expressing private holder binding is valuable for Avast..

Kevin Dean: the more I think about this, the more uncomfortable about this.
… consider a passport. when we present that at a border crossing, we have to present our own.
… but there are other use cases that don’t require that holder = subject.
… It is use case specific.

Jeremie Miller: holder is different than subject, no?.

Kevin Dean: It is the use case that would decide who the holder should be when it is presented.
… I would be hard pressed to think of an example where it is appropriate where only one party can ever present that.

Oliver Terbu: yes, I wouldn’t want this to be required.
… but it would make it so much easier for the verifier.
… This isn’t about limiting, it is about enabling.

Pierre-Antoine Champin: if it’s use-case specific, shouldn’t this be decided by the verifier rather than the presenter?.

Ryan Grant: seems like we are identifying a few business rules based on how credentials are typically used.
… are there others? are we being comprehensive about this.
… it may be useful to be more comprehensive about it.

Ted Thibodeau Jr.: how do you prevent “unauthorized presenter” from representing themselves as “authorized presenter” if Issuer has not specified Credential Subject and Authorized Presenter within the VC?.

Kristina Yasuda: chair hat off, specifying a mechanism that can be used with certain business rules, if they are present, is different from defining those specific business rules.

Phil Archer: +1 to JoeAndrieu.

Brent Zundel: +1 to Joe, except in cases where a verifier needs to know.

Joe Andrieu: Back in the day, the VP was created to help with this problem because anyone could have the serialized credential, the act of presenting it w/ passport is legally binding, relevant. VPs were created for that, what I like about what Oliver is presenting, we have a loosey goosey mechanism right now. What we have right now is too loose. The use cases aren’t about who can use the VC, that’s an anti-pattern, VC should model statements attested to.

Manu Sporny: by anyone. It doesn’t matter who has the statement, the statement exists. Yes, to having more nuance about this, but don’t think the purpose can be about restricting use of the VC..

Manu Sporny: oliver’s provided some good food for thought.
… I remain skeptical about the restriction part of this proposal.
… if we don’t do it in this group, it’s just going to get done elsewhere.
… so let’s see if we can improve our language.

Brent Zundel: framing this as a limiting factor of the credential isn’t the right way to think about this.
… when I think about it, I see it as a concern that some verifiers have.
… This is a concern that verifiers have.

Yan Zhang: https://vitalik.ca/general/2022/01/26/soulbound.html.

Yan Zhang: Soul bounding tokens.

Brent Zundel: Sometimes they will need prove that the presenter is the “right” party.
… I want to point out that in my mental model, having a methodology for private holder binding.

Gregg Kellogg: Presumably, something like a Search Warrant is only valid when presented by an authorized authority..

Brent Zundel: that’s similar to biometric binding, where the passport is expected to be used by the person whose photo is on the document.

Yan Zhang: there are situations VP shall only be used by the holder. Like in the DAO governance process.

Gabe Cohen: +1 Brent.

Samuel Smith: In ACDC we separate the roles cleanly. There is an Issuer and MAY be an Issuee which if specified is a targeted identifier. In a presentations there is a Discloser and a Disclosee. The Issuer may or may not be the Discloser. The issuee if any may or may not be the Discloser. So binding to Discloser and Disclosee is separable from binding to Issuer and Issuee.

Samuel Smith: The term Holder unfortunately does not have such separation..

David Waite: the way I look at it, is, if the holder is presenting, that can be handles as the subject in a new VC.

Ted Thibodeau Jr.: gkellogg – Search Warrant doesn’t typically specify presenting officer, allows any relevant officer to present it.

Yan Zhang: passport is different, I often time to give my passport to the travel agency and ask them to apply Visa for me.

David Waite: if the person who is allowed to present a birth certificate is their parent.
… we may already have ways to do this.

Brent Zundel: +1 to DW, but relationships I think are orthogonal.

David Chadwick: For a use case where you can’t pass on. I got my cards out of my wallet. Some of them say “non-transferable”.

Jeremie Miller: holder binding where the key is ephemeral and just used for replay protection, is it really just for preventing reply attacks.

Brent Zundel: One use case is a verifier asking for my birth certificate. Holder binding is one way for a holder to express that they are the subject of the birth certificate credential in a verifiable way..

Samuel Smith: we looked at the roles of the holder and we saw this ambiguity, so we have issuers and issuees… disclosures and disclosee.
… and so on.

Jeremie Miller: JoeAndrieu: I agree, thanks, they just functionally look almost identical.

Samuel Smith: then this confusion went away for us.
… “We” is AC/DC.

Ryan Grant: +1 to SamSmith’s definitions.

Yan Zhang: or we distinguish issuees from holders.

Kristina Yasuda: that’s it for the queue! Thanks, Oliver.
… next steps: discussion in Github issue, eventually to a PR.

Orie Steele: oliver: I would start a normative definition for holder on an issue..

Ted Thibodeau Jr.: Paul_Dietrich_GS1 – Note that present is not temporally tracked (except per meeting log/minutes). You either were present or not. By executing present-, you’re negating your previous present+, so you’re no longer logged as present for this meeting. (See https://www.w3.org/2022/09/16-vcwg-minutes.html to confirm.).

2. Joint Session with the RCH Working Group.

Markus Sabadello: Thanks to the VC working group for their hospitality. Joint session to discuss how working groups relate.
… Not in Vancouver.
… Quite involved in DID, a little involved in VC.
… Chair of RDF Canonicalization and Hashing working group, AKA RCH.

Phil Archer: I’m a co-chair of the working group.
… Markus has much more knowledge of DID and cryptographic. My background is in linked data. Between us we have the skills to move the group forward.

Markus Sabadello: Output of RCH working group is meant to be generic. Important though that this be applied to VCs.

Phil Archer: See slides.

Markus Sabadello: Quick introduction. Something gets hashed on the slide. VC contains proof and proof value, which is a signature of the VC.
… Proof will be partially standardized in VC working group but will also include work from RCH working group.
… Deliverables of RCH WG are RDF dataset hash and RDF dataset canonicalization.
… RDF dataset hash will be derived from canonicalization, which is about creating a canonicalized form of the RDF dataset.
… VC WG is working on VC data model and includes securing of VC, going forward with two prominent ways: VC JWT and VC Data Integrity,.
… VC Data Integrity has dependency on RCHWG deliverables.
… VC Data Integrity is still evolving. New cryptography suites are being proposed. Some are not signatures e.g., MerleDisclosureProof2021.

Orie Steele: Yes, there are details related to BBS+ … also there is an alternative to it that goes even deeper… https://github.com/zkp-ld/jsonld-signatures-bbs.

Markus Sabadello: RCHWG has to ensure that its deliverables meet the requirements of the VCWG.
… What does VCWG want, that does not restrict output of RCHWG to working only for VCs?.

Orie Steele: There is a version of BBS+ signatures that supports term-wise security.
… New RDF-star, is it possible that changes to that would result in another version of RDF normalization, which would change RCHWG deliverables?.

Phil Archer: phila: https://github.com/w3c/rch-rdc/issues/2.

Phil Archer: I’ve put a few high-level issues in GitHub, including, “What are we going to do about RDF*?”.

Kristina Yasuda: does RDF-star introduce a lot of breaking changes from RDF?.

Phil Archer: No kristina.

Pierre-Antoine Champin: kristina, no breaking change, but it extends the data model.

Orie Steele: kristina: afaik, it adds the ability to annotate edges, which would impact nquads… somehow….

Kristina Yasuda: thanks!.

Manu Sporny: Markus, you asked what does this group need from RCHWG?.

Pierre-Antoine Champin: Orie +1.

Dave Longley: Orie: i’ll mention something relevant to RDF-star + RDF canonicalization just briefly in my presentation at the end.

Manu Sporny: Concerned that we would have data integrity CR-ready five to six months ahead of RCH WG deliverable.
… May receive canonicalization from RCH WG and web of things WG.
… Current canonicalization scheme will continue to work.
… Doesn’t stop us from standardizing the thing that’s been out there for a decade now. 2015 is the current version.
… Focus hopefully will be on standardizing 2015 version.

Phil Archer: Timing is an issue. VCWG having that dependency puts pressure on RCHWG. One way to get on with it is to rubber-stamp what is there already, which is not what we’re going to do.
… That would be an abuse of the system.
… Going to hear from Dave and Aiden who have been working on this.
… I don’t think there’s a different approach.
… Feel free to raise an issue in the RCHWG GitHub.

Pierre-Antoine Champin: https://github.com/w3c/rch-rdc.

Orie Steele: pchampin: can you provide a link to the rendered spec ?.

Pierre-Antoine Champin: Orie: there’s none yet, we have only just started.

Pierre-Antoine Champin: but that will likely be https://w3c.github.io/rch-rdc/, eventually.

Ivan Herman: For the timing, I don’t think it would be a major problem. It can be formalized as Rec at the end of the WG’s life. We should not go out with a recommendation that does not rely on standard methods.
… If we find a new canonicalization algorithm that meets the requirements, I would be surprised.
… I don’t expect something new popping up.
… Can we explore the possibility of exploring certain RDF graphs with given characteristics that would lead to faster c14n?.
… Reluctant to categorize RDF graphs as they are difficult to categorize.
… Well-ordered RDF graphs can be put down in Turtle.

Manu Sporny: Ivan, we could proceed to CR. I don’t think we can proceed to CR unless 2015 is in there.

Ivan Herman: No, we can stay in CR if we have a working draft. We can be “one step ahead”.

Michael Jones: Who is it that wants to use the JCS c14n?.

Orie Steele: For the notes, this is the related JCS spec: https://datatracker.ietf.org/doc/html/rfc8785.

Manu Sporny: Because they don’t like RDF and want to use a different data stream.
… They have JSON-E templates that they want to inject data into.
… Very specific to their (Web of Things) use case.

Michael McCool: Want to avoid having to run RDF systems on IoT hubs due to size requirements.
… Might have to support multiple styles of signing.
… Need some standard way to JSON serialized assignment.

Shawn Butterfield: to answer why jcs?.

Markus Sabadello: I like the comments so far. I think it’s looking better.
… OK to move at different speeds.
… If anyone feels that RCH WG should work with JCS c14n, say so.

Manu Sporny: Also note that when you use JCS, you open up the possibility of signing invalid data.

Manu Sporny: (when you’re using JSON-LD + JCS – more security attack surface for an easier canonicalization).

Orie Steele: Regarding the web of things interest in JSON / JSON-LD stuff, we do use some JCS here: https://w3id.org/traceability as part of our JSON-LD context generation process from JSON Schema..

Orie Steele: AFAIK, JCS is used under the hood by URDNA2015 for @type: @json.

Shawn Butterfield: An opinionated implementer’s answer. One of the reasons why I might choose JCS c14n is that oftentimes I am in a situation that require approval and must be implemented using what has been approved.

Orie Steele: +1 Shawn.

Shawn Butterfield: I can’t do anything to make Jackson libraries better.
… Easy for implementers to understand. Output is consistent and reliable.

Michael McCool: JCS doesn’t deal with the values of things in strings (e.g., data/time in local format). Certain values have to be expressed in the right way to be canonical.
… Some elements have default values. Do we insert them or ignore them if not present?.

Manu Sporny: I don’t want people to come away thinking that JWS is equivalent to RDF c14n. JWS risks developers signing anything.

Orie Steele: When you use URDNA2015 on @json… you are using JCS..

Manu Sporny: If your developers know what they’re doing, they will hopefully write extensions that are usable.

Michael Jones: Manu, in what way is the security threat surface opened up?.

Shawn Butterfield: I’m also not sure what @manu means either..

Phil Archer: Existing spec does use JCS, per Orie.

Manu Sporny: You can JCS {“foo”: “bar”} (literally) and the canonicalizer won’t complain… if you have that in a VC, you just signed something that is invalid..

Markus Sabadello: Back to relationship between two groups.

Manu Sporny: (if you have no context).

Markus Sabadello: How do you get to the hash value given the data set displayed?.
… The VC data model defines pretty much everything except what’s in the proof.
… What’s in the proof object define what gets canonicalized and hashed to create the proof value.
… I imagine that VC data integrity specification plus crypto suite will drive how to do it.
… Need to define boundary between and VC data integrity and crypto suites.
… I would like to get some input from the VCWG.

Orie Steele: related to existing VC WG things at JCS… https://github.com/w3c/vc-jws-2020/blob/main/contexts/v1/index.json#L15.

Phil Archer: I think we will be getting a lot of input as there is a lot of overlap between the two groups.
… Need to be aware of the timing.

Markus Sabadello: No more questions to ask of VCWG.
… My understanding is that what gets hashed is not only a hash of the RDF dataset but also of some of the proof attributes.

Manu Sporny: I wish I had an answer. This is something that belongs in data integrity.

Dave Longley: +1 to it being in data integrity, data integrity combines the primitives output from the RCH WG as needed.

Orie Steele: For those that prefer to read code, this is a version of the “create verify data” algorithm: https://github.com/transmute-industries/RsaSignature2017/blob/master/src/common.js#L14.

Manu Sporny: Proof options (algorithm, date/time, verification method) are a separate RDF data set from the main VC.
… If we draw the line where the RCHWG.. I don’t know.
… Other detail is that there are interesting aspects of BBS+. One of them is to ensure that selective disclosure works.

Dave Longley: hash-based message authentication code = HMAC.

Manu Sporny: May require using HMAC as part of the canonicalization.

Orie Steele: Regarding some of the existing BBS+ statement approach manu is talking about: https://github.com/transmute-industries/verifiable-data/blob/main/packages/bbs-bls12381-signature-2020/src/BbsBlsSignature2020.ts#L106.

Orie Steele: its also related to the termise use case mention previously..

Manu Sporny: May want to canonicalize statement by statement.
… I’m just highlighting things that need to be formalized in the specification.

Markus Sabadello: My understanding is that individual statements need to be canonicalized for BBS+.
… This could be a very short specification.

Orie Steele: Yes Markus, there is a version of this same thing that works with merkle proofs and vanilla JWS - https://w3c-ccg.github.io/Merkle-Disclosure-2021/.

Orie Steele: There is also some work done by gov of singapore I believe related to merkle proofs and nquads..

Ivan Herman: Historically, when we wrote the charter, the focus was always on the c14n.
… The fact that we separated the hash makes it trivial.
… WG may decide that it’s not a separate deliverable.
… Creating the charter was a very long process. Hash has been separated from the c14n to make it easier.

Phil Archer: See Explainer.

Dave Longley: Comment on where is the line between VCWG and RCHWG. RCHWG is responsible for creating primitives that can be incorporated into VCWG.

Phil Archer: Although not listed, a good use case, including those not feeding VCS, is going to drive this forward.

Markus Sabadello: RDF dataset c14n, understanding is that input is an RDF dataset and output is also an RDF dataset.

Orie Steele: For the notes, the current draft for bbs+ data integrity - https://w3c-ccg.github.io/ldp-bbs2020/ and Mattr’s implementation https://github.com/mattrglobal/jsonld-signatures-bbs.

Dave Longley: good questions for the RCH WG to answer later, i think :).

Gregg Kellogg: What is the output of the canonicalization serialized or abstract? Is there a notion of a abstract dataset that can deliver an abstract c14n?.
… I’m feeling right now that the requirements of what the hashing spec needs to do is vague.

Pierre-Antoine Champin: I believe that the output of c14n is a mapping from blank nodes to labels.

Ivan Herman: What you said from an RDF point of view. C14n doesn’t change the dataset. It creates a specific canonical serialization of that dataset.
… Both create proofs in a canonical way. Dataset doesn’t change.

Phil Archer: That is my understanding as well.
… In my head, you can chuck in any serialization of RDF and the output is the same.
… Two people on the phone who have done this.

Phil Archer: Dave’s slides start here: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g15613afc368_10_35 here.

Dave Longley: First thing I want to talk about is relationship RDF and VCWG.
… What is an RDF dataset? It’s a way to model graphs of information.
… VC data model aligns with RDF.
… “Verify” means that we’re verifying that the information hasn’t changed and that the issuer is indeed the one who created it.
… Anonymity is preserved if we don’t need the verifiers to call home.
… Cryptographic primitive called a digital signature provides this.
… Different implementations might produce different bytes for signing for the same VC.
… Why not just have the issuer define the sequence of bytles?.
… This makes it harder on application developers.
… Not a problem on simple use cases, but more complex use cases cause problems.
… C14n ensures that the same set of data produces the same signature.
… Bytes that are protected are the output of the hash algorithm.
… Once we produce and sign the hash, we can discard the hash.
… Whenever we see the same data, we should get the same signature.
… Trade offs favour c14n.
… You can transform a VC into another format (e.g., CBOR-LD) and get the same results.
… URDNA2015 is a c14n algorithm that is input into the RCHWG.
… Based on 2012 algorithm, upgraded to handle multiple graphs instead of a single graph.
… Fit-for-purpose for RDF.
… Combines every RDF element, reuses existing primitives, and hashes with SHA-256.

Orie Steele: One of the biggest deployments of it I am aware of is related to Activity Pub / Mastodon …https://github.com/tootsuite/mastodon/blob/cabdbb7f9c1df8007749d07a2e186bb3ad35f62b/app/lib/activitypub/linked_data_signature.rb#L30.

Kristina Yasuda: the Mirabolic consulting paper on URDNA2015: https://lists.w3.org/Archives/Public/public-credentials/2021Apr/att-0032/Mirabolic_Graph_Iso_Report_2020_10_19.pdf.

Kristina Yasuda: because I was looking at it…

Dave Longley: With RDF-star, same upgrade process as from 2012-2015 should be followed.

Gregg Kellogg: With regards to CCG spec, there is an open pull request to fix things up. CCG will make a final report out of that for the WG to reference.

Phil Archer: Do you have an idea of timing?.

Gregg Kellogg: Pull request is ready, it has one approval.
… Chairs need to publish.
… Something that can be done in a day.
… Another thing that occurred to me, N-Quads doesn’t have a canonical form but triples do.

Orie Steele: +1 gkellogg.

Gregg Kellogg: No normalized form in N-Quad spec.

Pierre-Antoine Champin: https://www.w3.org/TR/n-triples/#canonical-ntriples.

Pierre-Antoine Champin: confirm that the N-quads spec does not have a similar section.

Manu Sporny: CCG will take more than a day. Need to convene group and get them to approve.
… Will push that along.

Markus Sabadello: It’s on the agenda for CCG next week. From a process perspective we need to motion this to recognize it.
… What is the output? A serialized stream?.

Dave Longley: Output is abstract data model with labels applied to get sorted N-Quads.
… “blank node labels” aren’t really “abstract”. … a detail for the RCH WG to figure out how to describe appropriately..

Markus Sabadello: Output of algorithm is not a serialized N-Quad stream but rather an abstract data model.
… Which can then be used to create a serialized form.

Dave Longley: +1 to being precise.

Pierre-Antoine Champin: yes, bnode labels are not part of the abstract syntax of RDF, so this “abstract canonicalized dataset” is somewhat hypbrid.

Phil Archer: Aidan’s slides: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1553dcd7b23_239_0 Aidan’s slides.

Aidan Hogan: Blank nodes are common in real-world data.
… Things would be easier if blank nodes didn’t exist.
… Creates relationships that are more difficult to determine if they’re isomorphic.
… Drawing a different way makes it difficult to determine isomorphism.
… GI complete means graph isomorphic complete.

Orie Steele: Skolemise is also used in the Termwise work, mentioned previously..

Orie Steele: For those who want to learn more about the word: https://en.wikipedia.org/wiki/Skolem_normal_form.

Aidan Hogan: Canonical labelling makes it faster to detect duplicate documents.
… Naive canonicalization will solve most problems.
… What happens with more complex graphs?.

Orie Steele: I cannot communicate how much I love this presentation..

Gabe Cohen: make a graph to demonstrate your love.

Kristina Yasuda: without blank nodes.

Pierre-Antoine Champin: Orie +1.

Aidan Hogan: (see presentation for answer).

Orie Steele: No Agda, TLA+ proof? : ) … That there is a coq proof is pretty awesome..

Dave Longley: that was an excellent presentation!.

Gabe Cohen: +1.

Gregg Kellogg: Do your insights on ease of extending extend to RDF-star?.

Aidan Hogan: Yes, don’t see any difficulty.
… Add some bytes to indicate that it originated as RDF-star.
… Also use this to canonicalize SPARQL.

Orie Steele: Cannonized sparql could reduce compute times I imagine..

Pierre-Antoine Champin: Do you have some reference data that can be used?.

Aidan Hogan: Yes, they’re all public datasets.
… Some datasets are used to prove correctness.

Markus Sabadello: Conceptually, the two pieces of work appear aligned. Want to get some understanding of overlaps and similarities.

Phil Archer: q=.

Dave Longley: they are very very similar … but not the same, unfortunately..

Aidan Hogan: Certain elements are aligned. There are technical differences that may affect performance and ease of implementation.
… There will have to be a comparison.

Phil Archer: The process of leaning, which tries to get rid of duplicates, have you considered using a SHACL shape to get rid of what you don’t want?.

Dave Longley: i’d recommend not taking on the extra work :).

Aidan Hogan: One example uses SPARQL to lean graph. Can use SHACL as well.

Phil Archer: https://github.com/w3c/rch-rdc.

Phil Archer: https://github.com/w3c/rch-rdh.

Pierre-Antoine Champin: RCH WG homepage: https://www.w3.org/groups/wg/rch.

Markus Sabadello: We have our mailing list. Encourage group to subscribe.

Phil Archer: Very conscious of the fact that the conversation has been very rapid and that this has impacted members for whom English is not the first language.

Orie Steele: Thank you!.

Shawn Butterfield: qwert.

Brent Zundel: Our first presentation is from Gabe.

3. Delegated and Multi-Party Credentials.

slides: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_120.

Gabe Cohen: We’re talking about multiparty and delegated credentials today. There are 3 formations and only one has been covered in the spec.
… Will be discussing these and what should be included.
… I tried to illustrate what credentials are today. There’s an assumption of a single issuer and single subject. Here is Mr. Owl and Tootsie man.
… That’s the simple case, the first case that’s different involves a delegated credential. Mr. Owl has a child and he knows the answer to the challenge and a parent should be able to hold a VC on behalf of the subject.
… Where the child is the primary subject.
… Another possibility is that there are multiple parties. Imagine that Mr. Owl is a conjoined twin. He has two identities and solves the same challenge. Now there are two subjects for the same VC – how do we express that? The spec shows this case where the credentialSubject block uses an array with two entries.

Orie Steele: None of these are VCs – in the understanding of the word we have today. But they may be technologies that you’ve heard before.
… The prompt here is “A 3d rendering of a confused deputy”.

Kristina Yasuda: btw there is a multi-subject JWT individual draft in IETF OAuth WG: https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/.

Orie Steele: There’s been discussion the mailing list about “what’s the problem with using VCs as capabilities?” I’m not here to describe that whole thread to you, please read it.
… There are ZCAPs which could be used and the work we’re using could be applied under that model using JSON-LD and Data Integrity. There’s ucan with JWT and dpop with JWT. There are NFTs that are controlled by a party and where that party could transfer that thing to another entity.
… Having that token could give you rights, like the ability to post a message to a group and not having it could remove those rights. We see these things happening outside of our WG.

Kristina Yasuda: present?.

Orie Steele: It’s a good idea to keep this in mind and see what others are doing with these NFTs and what the model is we have today.
… Non-transferable NFTs have been called “soul-bound tokens”. People can’t transfer these. There are some dark cases for these – like sex-offender lists. There are some uncomfortable use cases there. I don’t think we should shy away from those use cases though because we don’t control what people do and at the very least we should be aware and aware of how people may confuse our work with that other stuff.

Gabe Cohen: I don’t mean to mean these examples as a proposal, just showing one way to express things.

Orie Steele: Some of the examples we’ve already discussed as a WG. There’s an issue for this I’ll dig up for the notes. It’s about multiple subjects.
… The question is, can you use a VC with multiple subjects today? It’s awkward right now. There’s an example in the spec with multiple subjects … but consistently transforming that to the different securing formats is tough.
… Particularly with multiple subjects because many of the securing formats don’t have a way to handle more than one subject. So it’s awkward to actually secure multiple subjects in a JWT or another format that may have been traditionally bound to a single identifier.
… Marriage certificates are one example where you could have a legal office and the certificate could have two parties that are getting married and they are both listed in the VC.
… Another example would be a person traveling with a service dog and they have a vaccination VCs – there are multiple ways to express that.
… These examples help show the problems with a multiple subject model. That’s hard – because now we’re having the same holder binding conversation but with multiple subjects.
… Other examples like power of attorney, sort of delegated use case … there are multiple subjects, holder bindings, and delegated use cases – each of these is a problem and they are all mixed together.
… We’ve seen examples of each of them. The spec text around them isn’t helping enough.
… There are challenges around multiple subjects today and we’ve seen the challenges with holder binding. There are questions around delegation today. Generally, we will need some text to help clean this up.
… Regarding delegation use cases / scenarios, there are folks experiencing homelessness. They may not have a safe place to store critical documentation to apply for a job or get medical care. They may rely on social workers or others to manage their identity.
… They don’t have a phone / safe place to store docs, things could be stolen. These use cases are real. We should think about how multiple subjects, holder binding, delegation will affect vulnerable populations.

Gabe Cohen: So this slide is straight from the spec – an informative example about how one could express two credential subjects. This is a relationship / married certificate. In addition to an identifier name, there’s a relationship in each block.
… I’d like to see this move past an informative example and get to strong implementation suggestions and there may be multiple interpretations.

Orie Steele: Multiple issuers. Manu mentioned concerns about this use case – I’d love for him to queue.
… Some of the examples of credentials with multiple issuers – some scenarios in blockchain architectures, where you have a contract (a piece of software that operates autonomously). When things interact you have a contract address and the person creating the artifact (they could have funded the address for this purpose or a long term address).
… That person could transfer the artifact to a party and that could go further … and the point is, do we identify the party that issued the contract or that called the contract or both.
… I’m not saying what it should be – I’m just saying there are use cases out there today where multiple identifiers participating in the issuance process. If you choose to recognize that or not in the final VC, that’s a choice but you could imagine people making different choices.
… In a few feature of twitter you can collaborate with a tweet together. If those were signed – would you both be signing, would you have two proofs with different issuers? Is it in order – is it a proof chain or set?.
… There’s language that’s been discussed around proof chains and proof sets that’s relevant to that. There are scenarios around child/parent, there are scenarios around credentials from multiple parties, you need sign off from a large set of people so you don’t have just one person being compelled under duress,e tc.
… Should credentials with multiple issuers even be allowed?.

Kevin Dean: I’m having a bit of difficulty with the examples to be honest. We need to look for use cases where the subject, or multiple subjects/multiple issuers and they are in some way equivalent.
… In the marriage example it’s clear both parties are equivalent. They are both parties to the marriage contract and equal on the certificate.
… Power of attorney isn’t such a case. That’s a statement of my authority over another granted by them or a judge.

Kristina Yasuda: how are multi signature use-cases being dealt right now?.

Kevin Dean: So someone is issuing the power of attorney … so we could easily structure it so that the person over whom I have power of attorney is just another attribute, etc.

Kristina Yasuda: several iss claims?.

Kevin Dean: The same would be true for issuers. If there are multiple issuers, a board of directors who have to approve a course of action. They would be considered equivalent – co-signers for a loan.

Ivan Herman: q.

Kevin Dean: I can think of a lot of examples for multiple issuers, I have some difficulty thinking of examples of multiple subjects.

Samuel Smith: One of the ways we’ve addressed both delegation and multiple party problem is that we use a practical approach. Everything is rooted in crypto IDs and you can have multiple controllers – and everything can be multisignature using thresholds. Those thresholds can be sophisticated.

Orie Steele: +1 sam, I think merging identifiers into a multi party systems is an excellent way to get rid of the “multiple issuers” case..

Samuel Smith: For the GLEIF you can have multiple signers, escrow signers, escrow redundancy, different weights for signing, etc. but they all control a single identifier.
… There are multiple controllers for one issuer identifier.
… You can also have delegated authorities … [missed] … there can be terms and conditions in the credential that can be used to identify what authority the issuee of that credential has in terms of actions that someone would recognize. We have good examples of that.
… This was important for our setup where people can represent organizations and their authority and representation however they want along the lines of how their corps and orgs are run.

Gabe Cohen: I like that approach, I don’t think that should be the only one. I think there’s value in communicating all parties that are enumerated in these scenarios. Perhaps that could be handled in another portion of the credential subject. I think the information could just be in the VC.

Ivan Herman: A minor warning. The JSON-LD semantics is such that the array is default unordered. If I take the second example – with multiple issuers. From a JSON-LD standpoint it says that the issuers are the same, there’s no order. You can add an order but you have to do that explicitly.

Kristina Yasuda: We have 2 minutes left, so the topic is multisubject credentials and based on the morning conversations, Manu and Joe may have opinions.

Manu Sporny: Yes, many opinions, there’s a very long thread about delegation and credentials on the CCG mailing list, lots of good things said there. We may not be using the same definition of delegation or the use cases may be a bit confused.
… I’ve seen that happen over the years, different definitions resulting in people talking past each other for a long period of time.

Orie Steele: Here is a link to an issue that is related: https://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660.

Manu Sporny: There are specific technologies for delegated authorizations – one of the first questions we should ask is if it’s a delegated authorization use case or is it something else. If it’s delegated authorizations there are other technologies that are a better fit for this.

Kristina Yasuda: the chairs agreed to spend 10 more minutes on this topic.

Orie Steele: +1 to we need to cleanly separate these topics… but they are merged in the minds of many folks..

Manu Sporny: That’s the concern I have with this in general – I don’t think we’ve really honed in on the use cases. People throw them out there – and some are delegated authorization and others are not and we need to categorize.

Joe Andrieu: +1 to clearer use cases if we don’t have enough to distinguish. I think there’s a miscommunication around delegating statements and statements that delegate.

Yan Zhang: +1.

Joe Andrieu: Manu mentioned a birth certificate before as a delegateable certificate – and no, you can’t do that. Statements don’t get delegated – they just get verified.
… Anything you can put in the letter is a statement – the letter can have a statement of authorization. It doesn’t make letters a point of delegation, it’s just something you can do with it. You can use VCs to comment on code. Should we change the model to make it easier to comment on code. No.

Kristina Yasuda: there seems to be 2 more slides?.

Gabe Cohen: next one please.

Orie Steele: +1 protocols for building authorization on VCs seems out of scope..

Gabe Cohen: sorry, one after this.

Joe Andrieu: There’s a differentiation that is subtle and we should understand it. We’re here to standardize the envelope and data model – and there is a rich and open world where people are making authorizations and delegations and we need to be careful.

Ryan Grant: +1 to stopping at the envelope.

Orie Steele: but I am not sure we are “forbidding “ those use cases or “allowing them” based on the spec today..

Gabe Cohen: I agree with Manu and Joe on getting clear use cases. I know there have been a lot of prior discussions. I opened 3 issues to talk about them where we could add those good use cases.
… I didn’t intend to address all these – just raising the discussion and I’d like to see proposals on these issues on what we should do next.

Manu Sporny: Just to note – on these issues. The first one “delegate credentials” there be dragons. That’s the one that’s mixing a bunch of stuff up and that’s what the CCG discussion is about. Multisubject credentials the data model supports today and I don’t know if it’s a good idea to prevent it from doing that today but let’s let that play out why cut it off?.

Orie Steele: Should the data model now support multiple subject credentials? even thought we can’t test them concretely in VC-JWT?.

Manu Sporny: Multi issuers is interesting – if you are using data integrity you can have multiple different proofs using Data Integrity (you can’t do this with JWTs) but the issuer field only allows a single value.

Orie Steele: I will note that this leads to a “My security format is better because X…” which I am frustrated by..

Kristina Yasuda: manu: so when you do multisig, you include only one issuer and/or subject?.

Manu Sporny: The bottom two issues … are worth discussing now perhaps but the delegated one may need months of discussion and getting definitions right so we’re on the same page.

Manu Sporny: Orie, it leads to a: You can do X with Y technology but not Z technology – it’s just a factual statement..

Joe Andrieu: Multiple subject is a necessary and I think we have use cases that clarify that. On a birth certificate there’s a mother and a child. A marriage certificate has two spouses, some witnesses, etc.

Orie Steele: manu, thats the same thing I am saying, in different words..

Joe Andrieu: We had that debate quite a few years ago – about whether the language should state there’s a single subject and it can’t because we know of VCs that need it.
… It’s really about the semantics not the crypto here. There are so many different ways that multiple signatures could be interpreted so we’d have to talk about that.
… Did you add those use cases to the core spec or use cases?.

Gabe Cohen: Neither they are in issues in the core spec repo.

Orie Steele: -1 to moving those issues to use cases..

Joe Andrieu: Ok, let’s try to get those moved over to the use cases doc.

Gabe Cohen: issues: https://github.com/w3c/vc-data-model/issues/930, https://github.com/w3c/vc-data-model/issues/931, https://github.com/w3c/vc-data-model/issues/932.

Orie Steele: I’d like to respond to some of what Manu said. I think we’re having a bit of conversation in the chat about … what’s the core data model and what it allows. Then there will be representations of the core data model that are secured in a given system, VC-JWT, Data Integrity, potentially SD-JWT, potentially AC/DCs.
… Each of those systems will have their own constraints.
… That’s a fact. But the core data model – when you divide it out … some of those security mechanisms will take all the features and some will only take a smaller set.

Gabe Cohen: @JoeAndrieu - use cases to prove out the need for a change to the data model.

Orie Steele: We have the ability to alter that. If we say that the core data model lets you have multiple subjects … and we update IETF specs that allow JWTs to have multiple subjects / issuers.
… That seems unlikely that it would pan out but you could perhaps do things like that with Data Integrity.
… It’s our job to say if issuer is a string / array / object with an id property. Those questions impact those scenarios we’re discussing and we need to be clear.

Brent Zundel: Next topic is SD-JWT.

Kristina Yasuda: Chair hat off for the full 40 minutes from me.

4. Intro to SD-JWT.

Brent Zundel: slides at: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1553dcd7b23_217_4.

Kristina Yasuda: The purpose of the presentation is to introduce the concept. There are several questions / cry for help in defining certain aspects.
… This is a draft adopted in the IETF and the work is happening at IETF.
… The problem in the VC space is that the VC-JWTs are not selectively disclosable.
… You get one signature and you can’t take out one of the claims without breaking it.
… So the main problem was finding a way to do selective disclosure.

Sebastian Elfors: As I mentioned earlier, I am part of the EUDI wallet group.
… We got feedback from cryptographers on different ways to do selective disclosure – there are problems with the mDoc presentation is the connection to the issuer which is revealing that the holder is taking action.
… Another problem is with BBS which is new crypto.
… So we’re really interested in is SD-JWT for personal identification data for the EUDI wallet.

Kristina Yasuda: This slide just says that the principle we want is to keep SD-JWT as simple as possible. We have several implementations in a couple months which is a testament to that.
… The concept is not new, it’s just never been documented as a standard.
… The idea is that the issuer hashes each claim, only digests are included, no claim values.
… So a mapping is sent with actual claim mappings and salts and key-value pairs.
… In presenting – the whole digests are sent and only the salt and mappings/key-value pairs that the holder agrees to release.
… There’s an illustration for this in the slide.

Samuel Smith: With some minoradaptations to the ACDC structure, the salted hash or blinded digest approach is the mechanism in the ACDC spec for selective disclosure and bulk issuance.

Kristina Yasuda: I’m using the concept defined in the IETF draft and later we’ll try to map it to the VC. So just think of the SD-JWT as a VC signed as a credential and you send a container with the mappings you need.
… Including the information for all the digests.

Sebastian Elfors: One more question to be discussed: Should the proposed “sd_digests” VC claim be registered as a top claim by IANA?.

Kristina Yasuda: In selective disclosure happens with the mapping – the holder only sends the salt and claims values for those claims that are being released.
… We say optionally signed by the holder in the IETF … if it’s a VP, it’s most likely going to be signed by the holder.
… So some examples. These examples are from the SD-JWT doc.

Samuel Smith: The unique feature of ACDCs is a graduated disclosure mechanism using composed schema that supports contractually protected selective disclosure.

Kristina Yasuda: The question is – how can these concepts in the SD-JWT document be mapped to the VC model.
… SD-JWT defines sd-digests as a top-level JWT claim.
… It contains mappings and arrays with salts and values, it’s opinionated but it’s a draft and we expect discussion.
… During presentation is the SD-JWT-Release container.
… It’s worth noting that the concept of reusing VC-JWT … the security changes a bit, as a verifier, you do need to compute the additional computation to do the complete verification.
… The verifier must not accept the claim values in the release without computing the digests because a malicious holder could inject those values. That’s a huge caveat.
… There was a long discussion around that – so far sending the plain text without encryption … missed … the verifier needs to do the computation.
… The current document does allow generating one digest for the whole object or each separate object. This could end up with lots of complexity.
… We have implementations, one in python, kotlin, rust.
… I want to bring this up with the VCWG, there’s discussion in an issue between mostly me and sebastianelfors.
… There are options in the issue where there is a top-level sd_digest claim but instead of defining the claims directly we do something else [missed].

Sebastian Elfors: Here’s the issue on SD-JWT-VC: https://github.com/w3c/vc-data-model/issues/908.

Kristina Yasuda: Conceptually, the claims included in the credential subject and non-SD claims.
… Because there is a whole signature on the whole JWT – the first name / last name, you won’t be able to do SD.
… The digest of the claims … and claims included by value in the credential subject.
… In the next slide I have questions – potentially – there might be cases if we go this path the credential subject becomes empty and it’s a required property and is that allowed is one question.
… In the VP the object would be included.
… Not to confuse people – just to note where discussion has been. The other option is to put the whole subject in the SD claim … but that violates the draft spec.
… Nesting / processing is not straightforward in some options.

Orie Steele: I appreciate the intention behind this, but it just makes you wish for a better alternative… like JWP… for sure, there will need to be a very different mapping for vc-sd-jwt vs vc-jwt..

Kristina Yasuda: Can credential subject be empty? Where do we describe SD-JWT?.

Brent Zundel: would it work to map credentialSubject and sd_digests so they are equivalent?.

Gabe Cohen: ref: https://github.com/workdaycredentials/specifications/blob/master/specifications/claim-proof.md.

Gabe Cohen: I’m really happy to see this, when I was at work in 2019, we did a similar scheme not using JWTs. We used a claim next to each field that was the digest and a digest overall at the end so you could disclose pairs or the whole thing.

Shawn Butterfield: +1, I like what you’re attempting to accomplish.

Orie Steele: I also like the idea of it, just not the serialization backflips needed :).

Samuel Smith: I’m really interested in this, I don’t know if you’re familiar but we should discuss – the solution for both SD and issued credentials in AC/DC show lots of similarities. Using salty nonces to blind values and so on … and using schemas to allow verifiers to confirm the disclosure is acceptable.
… You can generate on the fly credentials that are unlinkable as well.

Sebastian Elfors: I have a comment on how to document this. Section 5.8 – could we rename that to Selective Disclosure, ZKP is just another methoed.
… We have atomic VCs, SD-JWT and other options to add there.

Jeremie Miller: +present.

Wayne Chang: Basically just wanted to say that we’re working on a VC model of a driving license and we like to see this so we’re supportive. There’s a SD mechanism in a CBOR model that does the same thing.
… It’s interesting to have a common representation on how to do this. Also, we’d like to be able to blind field names to produce better values.
… We’d like to see holder binding and understanding how it could work with the VP. The alternative representation would be to create the claim itself in the VP.
… We don’t like to see serialized JSON in strings, that throws a flag. On the plus side, the potential to issue the same data many times…
… The term pepper might be better than salt because it’s meant to be kept secret.

Orie Steele: I’ll take string encoded json over base64url encoded JSON : ).

Manu Sporny: I’m concerned with the complexity that we’re adding here. It sounds like several different securing schemes.
… SD-JWT feels like a stop gap, if you were to reveal none of the fields you’ve still got a tracking cookie. This is true for VC-JWTs and it’s true for a lot of data integrity things. I want us to be clear about what problem we’re actually solving.

Orie Steele: Agree, sd-jwt feels like a stop gap, aimed at tackling ISO / mDL use cases… meaning it might be a useful stop gap..

Kristina Yasuda: claim blinding is definitely the topic, wayne. and there is high potential it will be mandated.

Manu Sporny: It feels like a narrow solution – and it’s useful, but it’s a lot of complexity.
… People will look at VCs and be like “There are 4-5 different ways” to secure a VC and I have to figure out which one of those things I want to give the user. They will have to make an A or B person.

Brent Zundel: q.

Manu Sporny: The concern here is that we’re adding a lot of complexity for a narrow use case and it will confuse people.

Kristina Yasuda: The concern noted. But I would disagree in the sense that it’s added complexity for a narrow use case… in the sense that, and I expect -1 from some people for saying this. There is a potential for replacing VC-JWT with SD-JWT.

Orie Steele: is that horse trade on the table!?!?! thats exciting..

Kristina Yasuda: Those don’t have the features we want – I would argue SD is a requirement.
… I would want to avoid VC-JWT because SD-JWT does SD.
… The concern about keeping both is complexity and having more complexity … and that we want the tech to be more mature.
… Having SD-JWT instead of VC-JWT might be an option.

Orie Steele: I think an objective is to minimize the number of “alternative” but “nearly equivalent” security formats..

Phil Archer: A lot of this is above my head, I’m sorry, but I do understand that the more choice there is the harder to get implementations. If what you’re proposing is better than someone else, if it’s another way of doing the same thing please don’t.
… From a GS1 point of view – the fact that there’s more than one way is a barrier to adoption and we want to adopt. By all means if something is missing and needs doing, please do it, but don’t give me another choice to have to make.

Kristina Yasuda: If the explanation was not clear enough – this is not a reinvention of VC-JWTs, we’re adding a feature.

Manu Sporny: Thanks for that clarification, that is helpful. If we’re going to move from VC-JWTs to SD-JWTs, great. It keeps the same number of options on the table.
… I have a feeling that then the argument might become well JWPs do everything VC-JWTs and SD-JWTs do … and then we have 3 things and by the end of the group 2-3 go into the world, it gets into the tyranny of choice problem that Phil mentioned.
… Understanding that this is new and who knows how this will mature / play out at IETF… do we have a handle on when SD-JWTs will be done. We don’t know if it will be in the next year or two or what? What’s the timeline, would be good to know. The other question – how does it affect @context – I don’t know yet there are multiple ways to pair things together.

Sebastian Elfors: I wanted to clarify SD-JWT, it reduces complexity because BBS and anoncreds are extremely complex because they haven’t been analyzed properly.

Orie Steele: I would offer that if v2 includes @vocab no changes necessary and context will work fine using the v2 version : ).

Sebastian Elfors: I think this approach reduces complexity than anything else.

Kristina Yasuda: If JWP proceeds faster than SD-JWT, I would be happy to just have it.

Orie Steele: I would love for JWP to move faster… add your voice to the IETF list on the subject..

Kristina Yasuda: JWP started a year and a half before before SD-JWT but SD-JWT is moving faster it seems.
… There are multiple implementations that are moving SD-JWT and no JWP ones.
… I can’t guarantee there will be a stable draft in a year and a half, but just with JWT drafts … there would be stable examples early on.

Jeremie Miller: the JWP BoF is getting scheduled, ideally in the next few weeks.

Kristina Yasuda: I understand all the comments raised … I raised this now to get stable examples, etc.

Brent Zundel: You asserted that BBS and anoncreds were rejected by the EU because they hadn’t been fully analyzed. There are reasons they haven’t been accepted because they haven’t been standardized – it’s not because they are brand new crypto or not secure or too complicated.

Manu Sporny: I wanted to respond to that comment as well. That is not cool. I’m not a huge fan of BBS, it is fantastically complex is to say that it has been rejected by the EU is a gross misstatement. It is being moved through CFRG right now. It’s got call for adoption.
… It has been analyzed by different cryptographers.
… It would be great to bring other cryptographers to the fore and say what it’s not good to use. I think we should be careful with statements like that so it isn’t misleading.
… It would also be good to have the BBS cryptographers to respond to those statements. All crypto is complex, many of us have no idea what’s going on behind the scenes. The vast the majority of people just pick up a library shove data at it and believe it works.
… I take it as fact that salted hashes are a well known thing and paired with NIST crypto and is simpler than some other crypto, but it lacks some of the properties the other crypto brings.
… So, when you SD something, you really have to disclose “these three fields”. I know the BBS work has this feature.

Orie Steele: agree, that it would, but disagree that it would have a material impact for sd-jwt..

Manu Sporny: There may be times to selective disclose @context … maybe you need to always do that so the type of context is understood.
… Things there to look into.

Kristina Yasuda: I actually think that would be in scope for VC data model to decide. The scope of SD-JWT is to create a general mechanism an sd_digest container and how you communicate salts and plain values, etc.
… So what happens when you apply to the VC data model and so on – that’s all in scope for the VCWG.

Manu Sporny: I don’t think it would have a material impact, Orie, just important to consider..

Michael Jones: I wanted to reinforced a point from my own experience that Kristina briefly made about stability in spec development.
… When we were developing the JWT spec, I put together a consensus at the end of 2010 among people that were proposing similar things, Google, Facebook, MS, a few vendors.
… We came up with some example JWTs and the crypto behind them that we believed would be solid. We managed from 2010 to mid-2015 to keep those examples working.
… It’s not that additional stuff wasn’t added, it was, but the SD-JWT work at a similar level of maturity to when we created the JWT examples that we kept live.
… Yeah, there’s still some decisions to be made, but we’re very close to having a core the WG could agree to.
… It took a while after that but mostly for JWS, JWE.
… The JWT specs and their underpinnings weren’t done when OIDC went to final knowing that they could change but in practice they didn’t.
… Not everything is the same, but I do have confidence we can keep things stable through the IETF process.

Sebastian Elfors: I just wanted to elaborate on my previous statement. I apologize if it was taken badly. The architecture framework will be released in October – so they will select crypto that has been approved and only SD-JWT is the option to consider there.

Kristina Yasuda: To add a bit of color on the mDL side, the reason SD-JWT exists is because of that. The first idea to solve SD … was to do CBOR data over the Web but developers are more used to JSON.

Orie Steele: And to add “why” are they considering “sd-jwt” for selective disclosure… its because its achievable with popular tooling.. a design principle that we should not ignore the significance of…

Kristina Yasuda: In mDL world, SD is an absolute requirement, JWTs obviously do not do SD without SD-JWT.
… Doing JSON-LD and BBS … BBS did not exist.
… There was no JSON option … so the SD-JWT work was forced to be accelerated.
… SD-JWT seems like the best bet in the middle term.
… Next steps – majority of people in the room are working on JSON-LD and advanced crypto and this work is important for certain implementers and use cases. If there’s interest in helping … that would be great because there’s just a handful of us so far.
… I feel, honestly, a bit insecure in doing the definitions here and I would like the experts from this group to chime in.
… I’d like to see if there’s at least some value in doing this.

5. VC Test Suites.

Manu Sporny: I found this hideous slide deck, so I really wanted to use it :-).

Ivan Herman: Slide set: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_125.

Manu Sporny: maybe what we should do is review all the ways we’ve made mistakes in our test suites over the years. let’s do that.
… we’re gonna look at what went wrong with 1.0 test suite, 1.1 test suite, go over what we might do for 2.0. we’re not going to make any decisions, just survey what’s out there and slowly pick something over the next couple of months for next-generation testing.
… christine webber is the person who put together our first test suite in lisp. the pre-1.0 test suite was a command line driven python script, christine imported to racket. you needed to install racket and the vm to run the test suite. it was as bad as it sounds.
… no one knew how to maintain the test suite because it was in lisp. this is an example of the test.
… for the 1.0 rec test suite, we had a structure [diagram]. driver would call the issuer to issue, verifier to verify, then write results to a results file.
… this is what we did in the 1.0 rec test suite, but we did rewrite it from lisp into javascript. more contributions, more maintainable, 11 implementations. this was enough to survive the version 1.0 stuff that we did.

Ivan Herman: when you say the driver tells the issuer to issue, then driver tells verifier to verify, does this mean one impl?.

Manu Sporny: what would happen is all the implementers would download the test suite themselves, configure their system to run against a very specific issuer, and a very specific verifier.

Ivan Herman: could two implementations interop their verifiable credentials?.

Manu Sporny: yes.

Orie Steele: I’m a big fan of “docker + cli” setups..

Manu Sporny: what did we learn from 1.0? first lesson was don’t produce a test suite environment that reduces the amount of people who can contribute. lisp wasn’t a good choice, but it worked for long enough. we explored docker, one of the downsides was that everyone had to run the test suites themselves, but a number of implementers didn’t know how to put together a docker image.
… therefore we used a command line approach.
… when implementers completed their tests, they never looked back. it’s very doubtful that conformance tests are ongoing, and that the implementation report is likely out of date for years for some of these impls.

Orie Steele: +1 to continuous nightly test reports!.

Gregg Kellogg: we might be conflating two things here, one purpose for the impl report is to be able to show purposes of broad compatibility for transition. for that, it’s important to show a result at that point in time. the other purpose is for the community to show the current state of the market regarding these things. but they’re two different things.

Manu Sporny: great point, agreed.

Orie Steele: +1 to gkellogg.

Brent Zundel: +1.

Manu Sporny: what happened in 1.1?.
… we weren’t allowed to make normative changes, so the test suite didn’t change very much. we therefore got through the 1.1 process unphased, but not much more improvement.
… what about 2.0?.
… what are some requirements that we might want to apply here? test all the must normative statements in specs.

Orie Steele: +100 to this..

Manu Sporny: we ran the positive and negative tests per normative statement. we want to test the data model, but that usually means to testing the serialization. we want to test data integrity, jwt, sd-jwt, etc.
… we probably want to keep a loose coupling between impls and the test suite. i’m strongly recommending that we are running tests against implementations on a weekly/nightly basis towards gkellogg’s points.

Ivan Herman: i wasn’t around near 1.1 end, but at the end of the day, the MUST normative statements, if you do not give them something–the director either spend days and days to check the MUST statements against the tests, or just to believe us or not. we should list the tests against the MUST statements.

Brent Zundel: Link to W3C Process that describes the requirements for implementation experience: https://www.w3.org/2021/Process-20211102/#implementation-experience.

Orie Steele: 2 options to consider, for the record, (docker + cli) : https://identity.foundation/JWS-Test-Suite/#implementations, (postman + http): https://w3c-ccg.github.io/traceability-interop/reports/interoperability/.

Ivan Herman: for the EPUB WG, we are practicing this to show that each MUST statement has a pointer to its test, allowing us to check each requirement and go into the source. something like that is very useful.

Manu Sporny: that sounds very useful.

Pierre-Antoine Champin: https://respec.org/docs/#data-tests.

Ivan Herman: we realized this around a year ago, and we could use a tool where we could take the statements and link to tests.

Manu Sporny: sounds very useful, thanks!.

Ivan Herman: See An example for what respec can give you (from an EPUB WG document).

Kevin Dean: +1 to testing shoulds.

Ted Thibodeau Jr.: i hope we can test all SHOULD normative statements, there’s a reason why that exists. i disagree with MUST and MAY only. i disagree with forcing SHOULDs into MUSTs.
… i’d like to see these tests runnable after we’re done, specifically after transitions are done. there should be a way to run against a later implementation to get similar results out.

Phil Archer: to put in the side, manu, you say the results are assumed to be out of date….does anyone go back and check again and again? the other alternative, is that you can set a cron job to test each implementation. so what are you expecting for long term proof of conformance?.

Orie Steele: +1 to daily / weekly / monthly recurring tests..

Mahmoud Alkhraishi: huge +1 to recurring scheduled tests.

Manu Sporny: there is at least a subset of companies that want constant testing to show their customers.

Phil Archer: thanks.

David Chadwick: this is a question about optional MUSTs. we have a number of features in the standard, they are optional, you don’t have to provide them. but if you do provide them, they MUST conform. so how do people provide this and test?.

Manu Sporny: great question, we handle this on a case-by-case basis. for all the optional MUSTs, we found ways to test them. this is case-by-case. for example, you can create a VC with an optional MUST feature (such as evidence property), but if you do it perhaps you MUST have a type. so you create this VC and give it to a verifier, and see if there’s an error or not. in theory it shouldn’t. that’s example.

David Chadwick: what about issuers.

Manu Sporny: issuers are more difficult, it’s case-by-case. we have to see if it’s testable. if it’s not testable, we usually take the optional MUST out.

Gabe Cohen: i’d like to advocate for a requirement for implementers not to run their own infrastructure. i think orie’s pattern of docker containers is pretty straightforward, would be a good option to pursue.

Orie Steele: A nice way to remove the infra requirement is to use docker + cli, and not use http..

Yan Zhang: do we already have testing procedure in place? we’d like a test suite where we can test out the existing implementations to make sure they’re correct.

Manu Sporny: interactions?.

Yan Zhang: so right now, with all the test suites, you’re testing automatically. but is there any technical features to test for protocols?.

Manu Sporny: no, not authorized to work on protocol. there will be in time. there are things testing protocols outside, such as in CCG, OIDC, etc.

Michael Jones: we talked about this once upon a time in the DID WG, but i’ll repeat it here. it’s definitely in the case in the IETF and the W3C that plain english statements are normative unless marked non-normative via RFC2119 language.
… for example, in the JWT spec there were statements without the normative keyword terms, but they were required nonetheless.
… i’m involved with the OIDC certifications, and it’s the case that for OpenID, the WGs do have power on purpose to be able to add things to the conformance suite that are not in the spec. that may seem a strange thing to say or do, but here’s an example.

Kristina Yasuda: q.

Michael Jones: the definition of an ID token says that (in the spec) there must be a key ID if multiple keys are available to sign. the WG ultimately decided that interop would be improved if we just failed the case where a key ID was not included. i’m not saying we should do that or not, but if our goals are interop and not just conformance, we do have tools available to us to improve interop that go beyond what’s in the spec.
… when do you test SHOULDs? you often improve interoperability by testing SHOULDs. in normal implementations, you usually implement them anyway.

Kristina Yasuda: +1 to brent we should differentiate the minimum from what is ideal.

Orie Steele: +1.

Brent Zundel: i wanted to mention the reason we have a test suite is to show the W3C that we have implementation experience. the purpose is to demonstrate that, whether it shows conformance or just shows that, is additional. the minimum we need to do is to demonstrate implementations using the data model in existence.
… some of the questions that the director/AC is asking for is if we have shown independent interoperable impls.

Gregg Kellogg: as an implementation technique, i’ve seen test suites add parameterization to the tests, so you can group tests by features to pass.

Orie Steele: +1 to github actions.

Gregg Kellogg: a number of groups have been using GitHub actions that check on PRs. there are many things you can run on them, including periodicity (cron jobs). additionally, you could provision all the latest up to date implementations. GitHub and solve this.

Phil Archer: yes, you don’t have to use RFC2119 to make normative statements, but when i’m writing specs, i do choose those keywords to make it very implicit as a matter of choice. i take slight issue that the purpose is to get through the process. it is, but it’s also so that implementers can check their impls and build better software.

Kevin Dean: +1 to sharing the test suite.

Phil Archer: yes, it does fulfill, but there are more things to do too.

Ivan Herman: the test suite is an excellent way to test your own spec, to ensure that your statements are precise and testable. we have found errors in the process of modeling everything as tests, so it’s very important.

Brent Zundel: I think github actions would be great, so implementers can use it in CI/CD.

Wayne Chang: One more use case, we use continuous integration on our source code, we run the VC test suite when a branch is pushed, if it doen’t pass a test, we don’t merge. That would help implementers if we enabled that.

Gregg Kellogg: the test suites may show most valuable for other implementations after the spec is done. but what happens after problems are found in the test suites? what are the policies about immutability of test suite after publishing? we should have a policy on what to do with the test suite iterations after the rec is out.

Wayne Chang: See topic 2.0 options.

Orie Steele: This slide covers a few of the links I shared earlier… each of these suites has pro’s and con’s..

Orie Steele: Great slide Manu..

Manu Sporny: we could keep test suites as-is, static and from command line.
… we could dockerize the command line impls, or we could use an HTTP interface for implementations. this seems to be where most of the test suites have been going.
… we could use some other interface.
… [showing screen for test suite] normative statements on left, tests on right. this is what we have today.
… if you go back and go to the JWS test suite [screen sharing], a more macro test suite that tests in a macro sense.

Orie Steele: just a comment as an author. this covers both JsonWebSignature2020 and also VC-JWT because they both build on JOSE.
… keep them separate test suites, even if they’re on the same docker-based deployment.
… what’s cool about this test suite is that you can have a rust impl run against a javascript impl, and the CLI generates the different vectors for testing.

Manu Sporny: net one is the traceability test suite [screen sharing], it’s postman based, flow of credentials, breakdown of the tests, etc. it’s more of a higher level kind of workflow type testing to do an end-by-end impl testing, but we could probably figure out a way to do some of the testing in this group as well.

Orie Steele: that’s right, it covers issuance of revocable + unrevocable credentials. e.g., if you issue things will the verifier accept it?.
… folks may not want to stand up an HTTP server to demonstrate the full conformance to the data model.

Manu Sporny: in the last example is the verifier VC-API test suite [screen share], this one has asked the organizations to set up infrastructure. every vertical is a differnt company. test suite runs on a weekly basis to check conformance.

Orie Steele: Credit to Mesur and Mavennet (and Transmute) for the work on the Traceability Test Suite… it also runs nightly..

Manu Sporny: it’s possible to dockerize this. some implementers are totally fine running this infrastructure. there are a variety of options for us to pick from.

Ivan Herman: there’s another example here.

Manu Sporny: if you’re interested in testing, please get in touch with me or send an email out to the mailing list to say you’re interested in helping out.

Ivan Herman: [screen shared], what’s interesting is that this is a description of the tests themselves, tied to a MUST, SHOULD, or MAY test. on the right hand side, there are links. one link is going back to the spec with the statement, the last column links to a test result in a separate file.
… so there’s more information here than usually revealed. this is what you usually see [screen share], identifiers, implementations, and green/red accept. but the previous one gathers metadata and manifests it. this kind of information may be useful for our testers.
… it’s a little bit different because each test is different, and we’d need to configure this.

Manu Sporny: that’s it for testing, we don’t have to make a decision on which approach, we can make those decisions the next couple of meetings across the next few months.

Phil Archer: See An alternative approach to test suites, aimed at devs.

Samuel Smith: q.

Orie Steele: phila thanks for the link to the digital link test suite… I love how interactive it is…

6. Internationalization.

Slideset: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1553dcd7b23_211_0

Shigeya Suzuki: lets talk about internationalization.
… I want to talk about requirements, not so much how.
… lets talk about language strings among other things.
… there are credentials that need to work cross-border.
… for example, foreign students attending universities.
… typically the certifcates differ regarding education depending on the country of origin.
… currently the japanese government is issuing 2 types of certificates related to vaccination, based on HL7FHIR.
… HL7FHIR is multilingual.
… some fields are translated, other are not, such as name.
… the japanese government handles name encoding is special fields related to the patient data.
… the first example of the VCDM includes a multilingual example, but there is no explanation for how it is produced.
… we probably want to remove this example.
… we need normative rules for handling multilingual strings.
… do we need to use a language tag? related to BCP47?.

Ivan Herman: clarifying question, does this account also for left to right and right to left, but also vertical encoding?.
… JSON-LD 1.1 has a directionality encoding that is problematic.

gregkellog: in JSON-LD 1.1 1.1 we added 2 mechanisms for encoding text direction not otherwise supported by RDF.
… the one that is most favored in a name space with an encoding scheme, which includes the language identifier and the text direction…
… its in the JSON-LD REC, the idea would be that it would become a wider RDF standard… if there are requirements for top to bottom direction, we would need a modification.

Shigeya Suzuki: in the japanese language, we can manage without the vertical direction, its handled by display programs.
… not sure about other languages.
… how do we handle the construct.
… if we need to present 2 or 3 languages, for readable text entries… this creates complex and difficult structures.
… which might harm program readers ability to process… different to single language credentials.
… program interpretation of data structures remains a challenge.
… do we want to standardize such mappings?.
… do we have a use case for, supporting a large number of languages?.
… also translating property names would be useful.
… here are some examples of several constructs we could use.
… left hand side is the current approach.
… right hand side top, and bottom right … bottom right might be easier to refer to the inner property names from a programs point of view.
… We should use BCP47 for language tags.
… key mappings depend on construct used.
… maybe we should externalize things.
… we can use exact string mappings to translate between languages, but we have to consider integrity issues.
… this might be useful for handling text in each credential.
… we have talked about JSON-LD compatibility.
… should we implement a JSON-LD language map?.

Dave Longley: having a “multilingualDictionary” property in the VC that points to a minidictionary is interesting.

Shigeya Suzuki: next steps, we need to consult internationalization experts.
… and draft PRs to address the mapping and externalization considerations.

Manu Sporny: great summary of the options.

Ivan Herman: slide 342 i don’t think this is JSON-LD.

Dave Longley: yeah, the existing examples don’t work well for “simple JSON” users.

Manu Sporny: these are options available, but not sure this is being used in practice.
… the externalization use case is the most compelling.
… because thats how other solutions have worked, such as language mapping files in OS.
… it aligns with developer use.
… one file can be translated in parallel.
… there are a lot of benefits for handling an external representation, is you can improve over time.
… maybe we want to do hashlinks, but maybe we don’t so we can improve internationalization.

Manu Sporny: the experts told us to use the language features, but they didn’t comment on externalization.

Steve McCown: +1 for externalization..

Manu Sporny: +1 to adding a comment on externalization.

gkellog: in some communities language maps are working well, maybe they are not working well here… I like external maps idea.
… I think there are a lot of benefits to externalization.

Jay Kishigami: Is translation extension in HL7FHIR the same approach?.

Manu Sporny: i don’t know FHIR enough to know.

Ted Thibodeau Jr.: I am concerned that externalizing it will limit its utility, and online offline acccess.
… I don’t know that we have really even tried the existing mechanisms.

Dave Longley: presumably the dictionary could also be embedded.

Ted Thibodeau Jr.: I don’t think the deployment of VCs todate has tested this.

Phil Archer: there is an expert name <unknown>.

Brent Zundel: External mechanisms make me mildly concerned about security risks..

Dave Longley: yup, may be harder to do selective disclosure as well.

Shigeya Suzuki: I think its good to externalize but then embed, and we can handle remote access as a seperate issue.

Orie Steele: I like the idea of externalizing this and there being one binding point between VC data model and externalized language support. I agree with parallelizing language stuff as manu suggested. You send string file out to multiple language experts and get stuff back in parallel. We could provide guidance on caching.

Brent Zundel: from Jay: FHIR 5.0 traslation extension in https://build.fhir.org/languages.html.

Orie Steele: Also agree about not necessarily wanting to address immutability, it could be useful to make language corrections without breaking signatures. I know that’s a bit heresy, but I could see value in having an integrity protected terms w/ translated mappings/versions could be added over time without going through a reissuance process. This is an super important thing for us to address, could be one of the most things we do here. Very supportive of.

Manu Sporny: giving it more effort in v2.0..

Brent Zundel: unless we have a way to get the external thing, it changes the threat model.
… if you start addressing the meanings / translations… thats a potential attack.

Phil Archer: I agree with Brent, and Orie… but this will effect the threat model.

Ted Thibodeau Jr.: the other thing about externalization is that they impact interfaces to the user as well, form elements, not form inputs.

Kristina Yasuda: there seems to be a lot of support for this work.
… we should create issues for this.

Dave Longley: the resulting language map could also include a reference back to the VC and be signed by the issuer.

7. JSON Schema and VC Data Model.

Kristina Yasuda: last official topic for the agenda.

Ivan Herman: slides: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_140.

decentragabe: most people here are familar with JSON Schema.
… it supports field level validation, regexp, etc.
… it can help with credential field validation.
… it can help with defining document types.
… as a holder, I want confidence that my credential will be accepted.
… as a verifier, I want to define data shapes that I will accept, and I only trust certain issues to produce those data shape constraints.
… JSON schema can be cached.
… in the spec today, the example mentioned JSONSchemaValidator2018.
… which does not exist.
… in 2019 at Workday, we built a draft at the CCG to address the credentialSchema property.
… the draft defines metadata about the schema.
… covering authors and versioning, relative URIs and DIDS.
… there are a few companies that used it in a few languages.
… since then its gained some adoption but there are issues.
… in late 2021, we wanted to improve it, but it got stale.
… we need to make some updates to it.
… we need a way to authenticate schemas somehow.
… we need to continue to cover the metadata.
… i know at least of 2 imps that use this today.
… folks are independently using JSON Schema, regardless of the CCG draft.
… I asked in the DIF slack who uses JSON Schema, and several companies responded.
… at DIF, we use JSON Schema in a lot of our specs for object models.
… JSON Schema has a number of IETF drafts and excellent language support.
… this doesn’t cover code gen, editors, etc.
… I think it plays well with JSON-LD, and they pair well together.
… I think we should allow for both.
… I asked GPT-3 why we should include it in our spec.
… and the ai gave some good answers.

Ivan Herman: personally I am a fan of JSON Schema… we did use it in the DID WG, and the JSON Schema agrees and does not conflict with JSON-LD.
… one minor caveat, last i checked, JSON Schema is still a bit of a moving target.
… this makes it hard to target for standardization.
… W3C has had discussions with them, they politely said no, and would like to go their own way.

Kristina Yasuda: (+1 to ivan…).

Ivan Herman: the impact to us is, if we provide a JSON Schema, it can’t be normative.
… the spec can’t normatively rely on JSON Schema or features.
… if they do find a home for it in time, we might be lucky.
… apart from that, I am in favor of what you said.

David Ezell: I am a fan of creating a schema any time you have people creating documents, even with a non normative schema.
… I will reach out and see if we can’t find a way to find it a home.
… everyweek i write a ccouple hundred lines of JSON Schema.
… I have handled awkward features of composition.
… consider me available for review.

Samuel Smith: +1 to all the reasons to use JSON Schema mentioned.
… we like to use the composition operators, to handle single issuance and presentation with graduated disclosure.

Kristina Yasuda: q.

Wayne Chang: I am supportive of this work, I think JSON Schema is a great tool to help define shapes.
… I want to warn that it can be messy.
… type checks, semantic vocab, etc…
… JSON Schema can start to touch field constraints such as regex.

Manu Sporny: +1 to the work item in general.
… wanted to ask.
… should we define a JSON Schema 2018 type, is that right?.
… are you also saying we should have a schema for the core data model.

decentragabe: this is more about securing the credentialSubject, but I am ok to do both.

Manu Sporny: we can do both as long as we know they are different.

decentragabe: yep, primary mission regarding the credential subject.

Pierre-Antoine Champin: +1 as well, I want to point out there is a lot of conversations about this in JSON-LD CG related to YAML-LD.
… some people are really interested in linking a JSON-LD context with a JSON Schema.
… I also wanted to point out that those people use Open API.
… maybe its a solution to the problem Ivan raised.
… if its more stable maybe we can refer to OAS3.0 instead?.
… thats why its being raised in YAML-LD context.

Orie Steele: I’ve been involved in some of those conversations in JSON-LD CG, conversations about YAML-LD. We use OpenAPI specification files today and have extended YAML/JSON Schema representation to contain just enough properties to contain JSON-LD context from open api specification. Traceability vocab uses those things, work item has been contributed to by several companies. I don’t know answer to question on stable versioning and openapi has versioning and how they treat JSON Schema and I like that section because it gives you a better handle on exact features you can rely on in openapi 3. I’ve had a wonderful experience with open api and JSON Schema and have experienced the pain of JSON Schema, and language support, but if you look at specific features, that feature might not support the feature across implementations.
… When you have an API, you target a specific OpenAPI version.

David Ezell: great minds think alike.
… every JSON Schema we write, we use OAS to do it… with components.
… we already use OAS, and its a great point.

Phil Archer: OAS is a standard?.

Orie Steele: https://swagger.io/specification/.

Ivan Herman: the question is can we refer to it?.

Phil Archer: that thing isn’t a formal standard, but it seems used often… can we use it?.

Ivan Herman: we do refer to schema.org normatively…

Kristina Yasuda: great conversation.
… see you on the issues.
… this is the end of the official agenda.

8. Editorial Work Mode.

Brent Zundel: we had a request to reiterate the editorial work mode.
… for issues, we want the editorial team to triage and comment on issues.
… for PR if its substantive, it needs WG review.
… editorial changes, only require 1 editor to sign off.
… if concerns are raised, you may need to revert.
… thats it.

Manu Sporny: I think we had specified times before.
… 7 day window for review, to avoid backing out PRs.
… are we ready for FPWD on data integrity?.
… in the next month?.
… do we want to pull another crypto suite spec.

Orie Steele: in general in favor of doing FPWD for data integrity.
… the main comment is, to have confidence in the doc that represent WG consensus,.
… not sure there is a wg consensus on another crypto suite.
… want to have more conversation on crypto suite before doing another FPWD on it.
… not sure WG fully understands the implications of another cryptsuite.

Ivan Herman: general attitude is FPWD as soon as possible.
… it does not have to reflect wg consensus.
… i’ve seen FPWD with just section headings… not that we need to do that.
… its a stake in the ground.
… unless there is something very shameful in it, no reason not to publish.

Kristina Yasuda: I am a little concerned with a 5th working document. seeing the progress on other ones.

Ivan Herman: it triggers patent disclosure, and gives us stable URLs.

Manu Sporny: what we could do is mandatory reviews.
… usually you just tell people, to read.

Brent Zundel: +1 to Ivan, FPWD sooner rather than later.

Manu Sporny: I am suggesting an FPWD for data integrity, there has been a lot of ground work for the design goals and characteristics of the spec.
… there are a lot of issues that don’t need to be resolved.
… I think we do need to update it to reflect the rough consensus on the data integrity proof stuff.

Kristina Yasuda: agreed on FPWD for data integrity now, would like more discussion before additional cryptosuite document.

Manu Sporny: +1 to what orie said, about publishing a crypto suite along side it.
… if they are both ready, sooner the better’.

Phil Archer: .

Orie Steele: sorry just got back getting a drink..

Kristina Yasuda: if there is anything that is “ready for PR”… lets try to get to a PR.
… we got a lot done over the past few days, a huge thanks for everyone.

Ivan Herman: I will do my best to clean up the minutes.
… it will be hard, because I don’t know all names.

Kristina Yasuda: thanks to scribes.