Meeting minutes
<cel> SamSmith: ACDC is based on immutable schemas using CIDs/SAIDs
<Orie> possibly also related: https://
<cel> ... We would'nt use your schema, because it's not locked down enough. But could map to them.
<cel> ... After sending over the wire, can convert...
<cel> ... With JSON-LD, you sign the RDF graph after expansion
<Orie> actually, vc-jwt does sign JSON-LD.
<cel> ... We believe you should just sign what's sent over the wire, that's a more secure posture.
<Orie> it signs JSON.
<mprorock> Right orie
<cel> ... ToIP has OCA, a new schema representation... Or schema.org... could do those mappings
<cel> ... but we want to not be precluded from sending over the wire in our locked-down form
<cel> ... We can certainly define an interop profile from our schema to yours
<dlongley> all of these things sign hashes, actually :) ... if we're splitting hairs.
<decentralgabe> https://
<cel> decentralgabe: There is a draft schema that does this ^
<cel> kristina: Thanks, thank you to the scribes!
<Orie> Thanks for presenting SamSmith!
<cel> kristina: I highly encourage people, especially WG chairs, to document issues that may help us move forward
<cel> ... We're starting to tomorrow at...
<cel> ... 9am.
<cel> 6:10 in lobby to walk to dinner
<cel> manu: thanks to chairs for keeping us on schedule
<ivan> Date: 2022-09-16
<JoeAndrieu> Good morning, folks
brent: Good morning. Still need some scribes.
brent: 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 .... starting with Holder binding, from Oliver
… Then a joint session with the RCH working group
kristina: 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.
oliver: Ok. Are we ready?
… 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 ommitted
… 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.
oliver: This doesn't work with anon-creds and BBS+, but it is the simplest model
tallted: 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
<Orie> In general +1 to this... we need to create explict clarity regarding the cases where these `id` values match.
tallted: 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
oliver: Agreed. I'm just pointing out that this is a common pattern.
<nadalin> if the holder is not the subject how is holder authentication done?
tallted: but that's part of the problem.
<Orie> +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.
tallted: 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> the presenter IS identified in a credential WHEN the holder matches the subject.
kristina: queue please
kdeangs1: 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.
<TallTed> +1 to speaker
kdeangs1: That's important flexibility.
<Orie> yes, +1 thats how it works today, afaik.
oliver: Agreed.
… This isn't about mandating any approach. This is what I've seen.
Thanks, Orie.
oliver: I agree that many use cases do not require it.
<Orie> +1 to what oliver is saying again.
oliver: I didn't mean to argue FOR this, but just to point out some gaps
<dlongley> sounds like a lot more agreement than disagreement here so far
<Zakim> manu, you wanted to note why holder isn't normative right now, and ask about use cases that we're focusing on and why it matters?
manu: just for historical context
… holder has no normative language because we added it later
<Orie> +1 Manu
manu: 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
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: Might help illustrate this use case if we need the holder defined specifically
manu: 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: one example would be: I have multipled DIDs. I get credentials for on 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> +1 to making `id` more required... making it optional doesn't buy what people think it does.
oliver: later in the slides, I'd like to talk about some specific things
manu: it would help if we had a clear set of use cases
kristina: growing queue. Let's process that a bit.
<Zakim> Orie, you wanted to give use cases for holder / subject binding in B2B supply chain credential use cases.
orie: 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.
<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: 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
<Zakim> JoeAndrieu, you wanted to say Please do not think you can delegate credentials
JoeAndrieu: I want to clarify what you said, there is already delegatable stuff?
kristina: in the afternoon, a presentaton on it
JoeAndrieu: 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.
<TallTed> +1 to Joe
JoeAndrieu: That isn't a good delegation use case, MANU.
davidc: 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> related issue regarding disambiguating holder, https://
<TallTed> "authorized to present" should not be by specifying "holder" within the VC; should be by specifying "valid if presented by" or similar
davidc: 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)
<Zakim> pchampin, you wanted to suggest that, when the holder matters, maybe they should also be a subject
<Orie> +1 TallTed
<dlongley> TallTed: yeah, something like that
pchampin: seems to me when the holder matters, this should be somehow claimed, where the holder is a subject
<dlongley> "acceptablePresenter"
Agree with PA that that's an option.
kdeangs1: I want to talk to the credential that someone is a member of the board
<justin_r> there are two different questions: "Is the presenter allowed to present this?" and "is the presenter the subject?"
kdeangs1: The usefulness of that credential is independent of who holds it.
<Orie> +1 justin_r !
YanZhang: for a verifier to prove something, a particular good is related to IP on chain.
… This is hard to prove.
<rgrant> +1 justin_r
<dlongley> +1 to justin_r ... but we may only need one more element to express the former since the latter may already be easily determined
YanZhang: 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_r> dlongley: it seems to me the second one is the harder one because it requires outside knowledge about the subject
oliver: proof of possession is also hard to prove in a canonical way
<justin_r> dlongley: otherwise the security comes down to only handing VCs to the subjects and nobody else
oliver: the diversity of proving control and that I'm the intended holder
<dlongley> justin_r: yeah, i guess it depends on whether you can do simple identifier equivalence or not
oliver: Consider VC issued to Alice, Alice gives it to Bob
… Bob gives it to Verifier.
<justin_r> dlongley: good point, I was assuming a world with pairwise IDs everywhere, as a starting point
<YanZhang> just mark whether this VC is supposed to be bond to a subject or not.
oliver: Verifier doesn't know if Bob is the intended holder
<dlongley> justin_r: yeah, depends on the use case / privacy requirements.
oliver: currently there is something about holder binding
<justin_r> dlongley: agreed
oliver: We had a bunch of issues about this to make the binding more explicit
<TallTed> 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: what is asked that the VP is presented by the intended holder
… It can get more complicated than this.
<nadalin> holder can be a device and device can have attestation
oliver: For example, when the VCs have multiple IDs
<Orie> +1 nadalin
oliver: Or consider the alsoknownas property
<Orie> people are not devices, both deserve the right to `id`s.
oliver: q+ to talk about the intended holder as an anti-pattern
whoops
<dlongley> +1 to device use case ... there could also be "bindings to a type of device" (as opposed to a specific one)
.
<TallTed> "Holder Binding" is problematic from the start
oliver: let's try to define what holder binding really means
… A way to validate the intended holder is the presenter of a VP
<dlongley> "Presenter binding"
oliver: We need to bind: they might be the subject. They might be claims made by the issuer.
<TallTed> "Presenter binding" is better, but "binding" also isn't right
oliver: The holder of the VC, even though there is no holder identifier, presents a proof
<dlongley> TallTed: agreed
oliver: I hope this meets the sense of the group
of what holder binding is
<Zakim> JoeAndrieu, you wanted to talk about the intended holder as an anti-pattern
JoeAndrieu: I don't know how much of this is easiy 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..
<dlongley> "acceptable / intended presenter" seems better here
oliver: 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
<nadalin> mDL has the normative concept of holder of the mDoc
oliver: 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
<TallTed> ..."intended presenter"
<Jeremie> 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: 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
oliver: binding the holder to the VP with maximum flexibility
… a list of requirements
… first, allow verifier to
… [too fast, check slides]
<Jeremie> 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: It should be able to create VCs and VPs without holder binding
kristina: let's look at the concrete proposal
oliver: based on discussion, I came up with a proposal.
… add holderBinding to VC
<Orie> 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://
oliver: 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> chair hat off, establishing a standard method for expressing private holder binding is valuable for Avast.
kdeangs1: 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> holder is different than subject, no?
kdeangs1: 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: 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
<Zakim> rgrant, you wanted to mention that those asks are asking for business rules. are business rules in scope?
<pchampin> if it's use-case specific, shouldn't this be decided by the verifier rather than the presenter?
rgrant: 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 comprehenshive about it
<Zakim> JoeAndrieu, you wanted to say any restrictions on how a credential can be used is censorship
<TallTed> 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> 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
<phila> +1 to JoeAndrieu
<brent> +1 to Joe, except in cases where a verifier needs to know
JoeAndrieu: 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
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.
<Zakim> manu, you wanted to be generally supportive of the need to find a solution to this problem and to refine the initial proposal.
manu: 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
<Zakim> brent, you wanted to say that whether to check holder binding is up to the verifier and to say biometrics are a method of holder binding and to say that framing this as a limiting factor decided by the issuer isn't really correct
brent: 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.
<YanZhang> https://
brent: Sometimes they will need prove that the presenter is the "right" party
<YanZhang> Soul bounding tokens
brent: I want to point out that in my mental model, having a methodology for private holder binding
<gkellogg> Presumably, something like a Search Warrant is only valid when presented by an authorized authority.
brent: that's similar to biometric binding, where the passport is expected to be used by the person whose photo is on the document
<YanZhang> there are situations VP shall only be used by the holder. Like in the DAO governance process
<decentralgabe> +1 Brent
<Zakim> dwaite, you wanted to relationship of subject to holder
<SamSmith> 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 issee if any may or may not be the Discloser. So binding to Discloer and Discloee is separable from binding to Issuer and Issuee
<SamSmith> The term Holder unfortunately does not have such separation.
dwaite: the way I look at it, is, if the holder *is* presenting, that can be handles as the subject in a new VC.
<TallTed> gkellogg -- Search Warrant doesn't typically specify presenting officer, allows any relevant officer to present it
<YanZhang> passport is different, I often time to give my passport to the travel agency and ask them to apply Visa for me
dwaite: if the person who is allowed to present a birth certificate is their parent.
… we may already have ways to do this
<brent> +1 to DW, but relationships I think are orthogonal
davidc: For a use case where you can't pass on. I got my cards out of my wallet. Some of them say "non-transferable".
<Zakim> Jeremie, you wanted to say using an ephemeral key for replay prevention also considered holder binding and to ask is using an ephemeral key for replay prevention, also considered holder binding?
jeremie: holder binding where the key is ephemeral and just used for replay protection, is it really just for preventing reply attacks
<brent> 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.
samsmith: 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> JoeAndrieu: I agree, thanks, they just functionally look almost identical
samsmith: then this confusion went away for us.
… "We" is AC/DC
<rgrant> +1 to SamSmith's definitions
<YanZhang> or we distinguish issuees from holders
kristina: that's it for the queue! Thanks, Oliver
… next steps: discussion in Github issue, eventually to a PR
<Orie> oliver: I would start a normative definition for holder on an issue.
<TallTed> 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://
markus_sabadello: Thanks to the VC working group for their hospitality. Joint session to discuss how working groups relate.
markus_sabadello: Not in Vancouver.
… Quite involved in DID, a little involved in VC.
… Chair of RDF Canonicalization and Hashing working group, AKA RCH.
phila: 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.
<phila> 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> Yes, there are details related to BBS+ ... also there is an alternative to it that goes even deeper... https://
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?
<Zakim> Orie, you wanted to ask about RDF-star and RCH
orie: There is a version of BBS+ signatures that supports term-wise security.
<phila> phila: https://
orie: New RDF-star, is it possible that changes to that would result in another version of RDF normalization, which would change RCHWG deliverables?
phila: I've put a few high-level issues in GitHub, including, "What are we going to do about RDF-star?"
<Zakim> manu, you wanted to note timeline and staging will be a concern. and to note other canonicalization schemes for WoT
<kristina> does RDF-star introduce a lot of breaking changes from RDF?
<phila> No kristina
manu: Markus, you asked what does this group need from RCHWG?
<pchampin> kristina, no branking change, but it extends the data model
<Orie> kristina: afaik, it adds the ability to annotate edges, which would impact nquads... somehow...
<kristina> thanks!
<pchampin> Orie +1
<dlongley> Orie: i'll mention something relevant to RDF-star + RDF canonicalization just briefly in my presentation at the end
manu: Concerned that we would have data integrity CR-ready five to six months ahead of RCH WG deliverable.
<TallTed> ("RDF*" and "RDF-star" are pronounced the same, but mean very different things. "RDF*" was an early draft of the idea; "RDF-star" represents the current evolution.)
manu: May receive canonicalization from RCH WG and web of things WG.
… Current canonicalization scheme will continue to work.
<yamdan> thanks Orie for mentioning Term-wise BBS+, which actually I'm in charge of
manu: 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.
<Orie> yamdan: feel free to q in case you have opinions on how canonization impacts termise disclosure.
phila: Timiing 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.
<pchampin> https://
ivan: For the timing, I don't think it would be a major problem. It can be formalized at the end of the WG's life. We should not go out with a recommendation that does not rely on standard methods.
<Orie> pchampin: can you provide a link to the rendered spec ?
<pchampin> Orie: there's none yet, we have only just started
ivan: If we find a canonicalization algorithm that meets the requirements, I would be surprised.
<pchampin> but that will likely be https://
ivan: 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.
<Zakim> manu, you wanted to ask if we can go to CR w/o URDNA2015 being in CR as well?
manu: Ivan, we could proceed to CR. I don't think we can proceed to CR unless 2015 is in there.
ivan: No, we can stay in CR if we have a working draft.
selfissued: Who is it that wants to use the JCS c14n?
<Zakim> manu, you wanted to answer selfissued
<Orie> For the notes, this is the related JCS spec: https://
manu: 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.
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.
<sb> to answer why jcs?
markus_sabadello: I like the comments so far. I think it's looking better.
… OK to move at different speeds.
<manu> Also note that when you use JCS, you open up the possibility of signing invalid data
<manu> (when you're using JSON-LD + JCS -- more security attack surface for an easier canonicalization)
markus_sabadello: If anyone feels that RCH WG should work with JCS c14n, say so.
<Orie> Regarding the web of things interest in JSON / JSON-LD stuff, we do use some JCS here: https://
<Orie> AFAIK, JCS is used under the hood by URDNA2015 for `@type: @json`
sb: 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> +1 Shawn
sb: I can't do anything to make Jackson libraries better.
… Easy for implementers to understand. Output is consistent and reliable.
<Zakim> McCool, you wanted to react to sb
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?
<Zakim> manu, you wanted to note dangers w/ JCS c14n.
manu: I don't want people to come away thinking that JWS is equivalent to RDF c14n. JWS risks developers signing anything.
<Orie> When you use URDNA2015 on `@json`... you are using JCS.
<selfissued> Manu, in what way is the security threat surface opened up?
manu: If your developers know what they're doing, they will hopefully write extensions that are usable.
<sb> I'm also not sure what @manu means either.
phila: Existing spec does use JCS, per Orie.
<manu> 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> (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> related to existing VC WG things at JCS... https://
phila: 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.
<Zakim> manu, you wanted to note hash of credential and hash of proof are combined and hashed, and complexities with BBS+
manu: I wish I had an answer. This is something that belongs in data integrity.
<dlongley> +1 to it being in data integrity, data integrity combines the primitives output from the RCH WG as needed
<Orie> For those that prefer to read code, this is a version of the "create verify data" algorithm: https://
manu: 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.
<dlongley> hash-based message authentication code = HMAC
manu: May require using HMAC as part of the canonicalization.
<Orie> Regarding some of the existing BBS+ statement approach manu is talking about: https://
manu: May want to canonicalize statement by statement.
<Orie> its also related to the termise use case mention previously.
manu: 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+.
<Orie> Yes Markus, there is a version of this same thing that works with merkle proofs and vanilla JWS - https://
markus_sabadello: This could be a very short specification.
ivan: Historically, when we wrote the charter, the focus was always on the c14n.
… The fact that we separated the hash makes it trivial.
<Orie> There is also some work done by gov of singapore I believe related to merkle proofs and nquads.
ivan: 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.
<phila> Explainer
dlongley: Comment on where is the line between VCWG and RCHWG. RCHWG is responsible for creating primitives that can be incorporated into VCWG.
phila: 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.
<Zakim> gkellogg, you wanted to request specific requirements from VCWG on the Hash spec, and question the division of responsibility between RDFC14N and Hash.
<Orie> For the notes, the current draft for bbs+ data integrity - https://
<dlongley> good questions for the RCH WG to answer later, i think :)
gkellogg: 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.
<pchampin> I believe that the output of c14n is a mapping from blank nodes to labels
ivan: 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.
phila: 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.
<phila> Dave's slides start here
dlongley: 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.
<TallTed> what about canonization vs canonicalization?
dlongley: Based on 2012 algorithm, upgraded to handle multiple graphs instead of a single graph.
<TallTed> and canonize vs canonicalize?
dlongley: Fit-for-purpose for RDF.
… Combines every RDF element, reuses existing primitives, and hashes with SHA-256.
<Orie> One of the biggest deployments of it I am aware of is related to Activity Pub / Mastodon ... https://
<kristina> the Mirabolic consulting paper on URDNA2015: https://
<kristina> because I was looking at it..
dlongley: With RDF*, same upgrade process as from 2012-2015 should be followed.
<Zakim> gkellogg, you wanted to note that N-Quads doesn't have a specified C14N form, although it can be derived from that of N-Triples.
gkellogg: 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.
phila: Do you have an idea of timing?
gkellogg: 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> +1 gkellogg
gkellogg: No normalized form in N-Quad spec.
<Zakim> manu, you wanted to speak to CCG steps
<pchampin> https://
<pchampin> confirm that the N-quads spec does not have a similar section
manu: CCG will take more than a day. Need to convene group and get them to approve.
… Will push that along.
<dlongley> TallTed: canonize/canonicalization are synonyms
<dlongley> (all the various forms of those words)
<pchampin> dlongley you mean c14n = c10n ? :-P
<dlongley> heh :)
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?
dlongley: Output is abstract data model with labels applied to get sorted N-Quads.
<dlongley> "blank node labels" aren't really "abstract"
<dlongley> 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.
<dlongley> +1 to being precise
<pchampin> yes, bnode labels are not part of the abstract syntax of RDF, so this "abstract canonicalized dataset" is somewhat hypbrid
<gkellogg> s/hyprid/hybrid/
<phila> Aidan's slides
aidan: 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.
<Orie> These slides are amazing.
aidan: GI complete means graph isomorphic complete.
<Orie> Skolemise is also used in the Termwise work, mentioned previously.
<Orie> For those who want to learn more about the word: https://
aidan: Canonical labelling makes it faster to detect duplicate documents.
… Naive canonicalization will solve most problems.
… What happens with more complex graphs?
<Orie> I cannot communicate how much I love this presentation.
<decentralgabe> make a graph to demonstrate your love
<kristina> without blank nodes
<pchampin> Orie +1
aidan: (see presentation for answer)
<Orie> No Agda, TLA+ proof? : ) ... That there is a coq proof is pretty awesome.
<dlongley> that was an excellent presentation!
<decentralgabe> +1
<Zakim> gkellogg, you wanted to ask about thoughts on extending to RDF-star.
gkellogg: Do your insights on ease of extending extend to RDF-star?
aidan: Yes, don't see any difficulty.
… Add some bytes to indicate that it originated as RDF-star.
… Also use this to canonicalize SPARQL.
<Orie> Cannonized sparql could reduce compute times I imagine.
<Zakim> pchampin, you wanted to ask if a test-suite is available
pchampin: Do you have some reference data that can be used?
aidan: 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.
<dlongley> they are *very very* similar ... but not the same, unfortunately.
aidan: Certain elements are aligned. There are technical differences that may affect performance and ease of implementation.
… There will have to be a comparison.
phila: 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?
<dlongley> i'd recommend not taking on the extra work :)
aidan: One example uses SPARQL to lean graph. Can use SHACL as well.
<phila> https://
<phila> https://
<pchampin> RCH WG homepage: https://
markus_sabadello: We have our mailing list. Encourage group to subscribe.
phila: 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> Thank you!
<shawnb> qwert
<justin_r> no, sorry -- under a deadline
brent: Our first presentation is from Gabe.
<decentralgabe> & Orie
brent: Gabe and Orie.
decentralgabe: We're talking about multiparty and delegated credentials today. There are 3 formations and only one has been covered in the spec.
decentralgabe: Will be discussing these and what should be included.
decentralgabe: 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.
decentralgabe: 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.
decentralgabe: Where the child is the primary subject.
decentralgabe: 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: None of these are VCs -- in the understanding of the word we have today. But they may be technologies that you've heard before.
Orie: The prompt here is "A 3d rendering of a confused deputy".
<kristina> btw there is a multi-subject JWT individual draft in IETF OAuth WG: https://
Orie: 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.
Orie: 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.
Orie: 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> present?
Orie: 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.
Orie: 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.
decentralgabe: I don't mean to mean these examples as a proposal, just showing one way to express things.
Orie: 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.
Orie: 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.
Orie: 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.
Orie: 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.
Orie: Another example would be a person traveling with a service dog and they have a vaccination VCs -- there are multiple ways to express that.
Orie: 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.
Orie: 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.
Orie: We've seen examples of each of them. The spec text around them isn't helping enough.
Orie: 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.
Orie: 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.
Orie: 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.
decentralgabe: 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.
decentralgabe: I'd like to see this move past an informative example and get to strong implementation suggestions and there may be multiple interpretations.
Orie: Multiple issuers. Manu mentioned concerns about this use case -- I'd love for him to queue.
Orie: 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).
Orie: 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.
Orie: 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.
Orie: 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?
Orie: 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.
Orie: Should credentials with multiple issuers even be allowed?
kdeangs1: 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.
kdeangs1: In the marriage example it's clear both parties are equivalent. They are both parties to the marriage contract and equal on the certificate.
kdeangs1: Power of attorney isn't such a case. That's a statement of my authority over another granted by them or a judge.
<kristina> how are multi signature use-cases being dealt right now?
kdeangs1: 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> several iss claims?
kdeangs1: 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.
kdeangs1: I can think of a lot of examples for multiple issuers, I have some difficulty thinking of examples of multiple subjects.
SamSmith: 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> +1 sam, I think merging identifiers into a multi party systems is an excellent way to get rid of the "multiple issuers" case.
SamSmith: For the GLEIF you can have multiple signers, escrow signers, escrow redundancy, different weights for signing, etc. but they all control a single identifier.
SamSmith: There are multiple controllers for one issuer identifier.
SamSmith: 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.
SamSmith: 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.
decentralgabe: 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: 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: We have 2 minutes left, so the topic is multisubject credentials and based on the morning conversations, Manu and Joe may have opinions.
manu: 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.
manu: I've seen that happen over the years, different definitions resulting in people talking past each other for a long period of itme.
<Orie> Here is a link to an issue that is related: https://
manu: 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> the chairs agreed to spend 10 more minutes on this topic
<Orie> +1 to we need to cleanly separate these topics... but they are merged in the minds of many folks.
<Zakim> JoeAndrieu, you wanted to talk about delegating statements, verses statements that delegate
manu: 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 authz and others are not and we need to categorize.
JoeAndrieu: +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.
<YanZhang> +1
JoeAndrieu: 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.
JoeAndrieu: 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> there seems to be 2 more slides?
<decentralgabe> next one please
<Orie> +1 protocols for building authorization on VCs seems out of scope.
<decentralgabe> sorry, one after this
JoeAndrieu: 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.
<rgrant_> +1 to stopping at the envelope
<Orie> but I am not sure we are "forbidding " those use cases or "allowing them" based on the spec today.
decentralgabe: 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.
decentralgabe: 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.
<Zakim> manu, you wanted to note questions confuse the use cases. and to note issues.
manu: 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> Should the data model now support multiple subject credentials? even thought we can't test them concretely in VC-JWT?
manu: 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> I will note that this leads to a "My security format is better because X..." which I am frustrated by.
<kristina> manu: so when you do multisig, you include only one issuer and/or subject?
<Zakim> JoeAndrieu, you wanted to ask about use cases
manu: 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> Orie, it leads to a: You can do X with Y technology but not Z technology -- it's just a factual statement.
JoeAndrieu: 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> manu, thats the same thing I am saying, in different words.
JoeAndrieu: 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.
JoeAndrieu: 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.
JoeAndrieu: Did you add those use cases to the core spec or use cases?
decentralgabe: Neither they are in issues in the core spec repo.
<Orie> -1 to moving those issues to use cases.
JoeAndrieu: Ok, let's try to get those moved over to the use cases doc.
<decentralgabe> issues: https://
Orie: 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.
Orie: Each of those systems will have their own constraints.
Orie: 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.
<decentralgabe> @JoeAndrieu - use cases to prove out the need for a change to the data model
Orie: 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.
Orie: That seems unlikely that it would pan out but you could perhaps do things like that with Data Integrity.
Orie: 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: Next topic is SD-JWT.
kristina: Chair hat off for the full 40 minutes from me.
Intro to SD-JWT
kristina: The purpose of the presentation is to introduce the concept. There are several questions / cry for help in defining certain aspects.
kristina: This is a draft adopted in the IETF and the work is happening at IETF.
kristina: The problem in the VC space is that the VC-JWTs are not selectively disclosable.
kristina: You get one signature and you can't take out one of the claims without breaking it.
kristina: So the main problem was finding a way to do selective disclosure.
sebastianelfors: As I mentioned earlier, I am part of the EUDI wallet group.
sebastianelfors: 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.
sebastianelfors: Another problem is with BBS which is new crypto.
sebastianelfors: So we're really interested in is SD-JWT for personal identification data for the EUDI wallet.
kristina: 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.
kristina: The concept is not new, it's just never been documented as a standard.
kristina: The idea is that the issuer hashes each claim, only digests are included, no claim values.
kristina: So a mapping is sent with actual claim mappings and salts and key-value pairs.
kristina: In presenting -- the whole digests are sent and only the salt and mappings/key-value pairs that the holder agrees to release.
kristina: There's an illustration for this in the slide.
<SamSmith> 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: 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.
kristina: Including the information for all the digests.
<sebastianelfors> One more question to be discussed: Should the proposed "sd_digests" VC claim be registered as a top claim by IANA?
kristina: In selective disclosure happens with the mapping -- the holder only sends the salt and claims values for those claims that are being released.
kristina: 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.
kristina: So some examples. These examples are from the SD-JWT doc.
<SamSmith> The unique feature of ACDCs is a graduated disclosure mechanism using composed schema that supports contractually protected selective disclosure
kristina: The question is -- how can these concepts in the SD-JWT document be mapped to the VC model.
kristina: SD-JWT defines `sd-digests` as a top-level JWT claim.
kristina: It contains mappings and arrays with salts and values, it's opinionated but it's a draft and we expect discussion.
kristina: During presentation is the `SD-JWT-Release` container.
kristina: 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.
kristina: 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.
kristina: There was a long discussion around that -- so far sending the plain text without encryption ... missed ... the verifier needs to do the computation.
kristina: The current document does allow generating one digest for the whole object or each separate object. This could end up with lots of complexity.
kristina: We have implementations, one in python, kotlin, rust.
kristina: I want to bring this up with the VCWG, there's discussion in an issue between mostly me and sebastianelfors.
kristina: 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].
<sebastianelfors> Here's the issue on SD-JWT-VC: https://
kristina: Conceptually, the claims included in the credential subject and non-SD claims.
kristina: Because there is a whole signature on the whole JWT -- the first name / last name, you won't be able to do SD.
kristina: The digest of the claims ... and claims included by value in the credential subject.
kristina: 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.
kristina: In the VP the object would be included.
kristina: 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.
kristina: Nesting / processing is not straightforward in some options.
<Orie> 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: Can credential subject be empty? Where do we describe SD-JWT?
<brent> would it work to map credentialSubject and sd_digests so they are equivalent?
<decentralgabe> ref: https://
decentralgabe: 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.
<shawnb> +1, I like what you're attempting to accomplish
<Orie> I also like the idea of it, just not the serialization backflips needed :)
SamSmith: 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.
SamSmith: You can generate on the fly credentials that are unlinkable as well.
sebastianelfors: I have a comment on how to document this. Section 5.8 -- could we rename that to Selective Disclosure, ZKP is just another methoed.
sebastianelfors: We have atomic VCs, SD-JWT and other options to add there.
<Jeremie> +present
wayne: 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.
wayne: 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.
wayne: 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.
wayne: 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...
wayne: The term pepper might be better than salt because it's meant to be kept secret.
<Zakim> manu, you wanted to note complexity explosion w/ VC-JWT, SD-JWT, JWP. To be clear, these are tracking identifiers but that's not what SD-JWT is trying to address?
<Orie> I'll take string encoded json over base64url encoded JSON : )
manu: I'm concerned with the complexity that we're adding here. It sounds like ...
manu: It sounds like several different securing schemes.
manu: 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> Agree, sd-jwt feels like a stop gap, aimed at tackling ISO / mDL use cases... meaning it might be a useful stop gap.
<kristina> claim blinding is definitely the topic, wayne. and there is high potential it will be mandated
manu: It feels like a narrow solution -- and it's useful, but it's a lot of complexity.
manu: 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.
manu: The concern here is that we're adding a lot of complexity for a narrow use case and it will confuse people.
<Zakim> kristina, you wanted to respond to wayne
kristina: 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> is that horse trade on the table!?!?! thats exciting.
kristina: Those don't have the features we want -- I would argue SD is a requirement.
kristina: I would want to avoid VC-JWT because SD-JWT does SD.
kristina: The concern about keeping both is complexity and having more complexity ... and that we want the tech to be more mature.
kristina: Having SD-JWT instead of VC-JWT might be an option.
<Zakim> phila, you wanted to talk about the tyranny of choice
<Orie> I think an objective is to minimize the number of "alternative" but "nearly equivalent" security formats.
phila: 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.
phila: 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: If the explanation was not clear enough -- this is not a reinvention of VC-JWTs, we're adding a feature.
manu: 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.
manu: 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.
manu: 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.
sebastianelfors: I wanted to clarify SD-JWT, it reduces complexity because BBS and anoncreds are extremely complex because they haven't been analyzed properly.
<Orie> I would offer that if v2 includes `@vocab` no changes necessary and context will work fine using the v2 version : )
sebastianelfors: I think this approach reduces complexity than anything else.
kristina: If JWP proceeds faster than SD-JWT, I would be happy to just have it.
<Orie> I would love for JWP to move faster... add your voice to the IETF list on the subject.
kristina: JWP started a year and a half before before SD-JWT but SD-JWT is moving faster it seems.
kristina: There are multiple implementations that are moving SD-JWT and no JWP ones.
kristina: 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> the JWP BoF is getting scheduled, ideally in the next few weeks
<Zakim> brent, you wanted to respond to sebastianelfors
kristina: I understand all the comments raised ... I raised this now to get stable examples, etc.
brent: 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.
<Zakim> manu, you wanted to ask about "Must disclose" DSs, talk about "complexity" in crypto.
manu: 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.
manu: It has been analyzed by different cryptographers.
manu: 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.
manu: 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.
manu: 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.
manu: So, when you SD something, you really have to disclose "these three fields". I know the BBS work has this feature.
<Orie> agree, that it would, but disagree that it would have a material impact for sd-jwt.
manu: There may be times to selective disclose `@context` ... maybe you need to always do that so the type of context is understood.
manu: Things there to look into.
kristina: 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.
kristina: So what happens when you apply to the VC data model and so on -- that's all in scope for the VCWG.
<manu> I don't think it would have a material impact, Orie, just important to consider.
selfissued: I wanted to reinforced a point from my own experience that Kristina briefly made about stability in spec development.
selfissued: 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.
selfissued: 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.
selfissued: 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.
selfissued: Yeah, there's still some decisions to be made, but we're very close to having a core the WG could agree to.
selfissued: It took a while after that but mostly for JWS, JWE.
selfissued: 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.
selfissued: Not everything is the same, but I do have confidence we can keep things stable through the IETF process.
sebastianelfors: 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.
<Zakim> kristina, you wanted to add color on mDL and potentially next steps
kristina: 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> 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: In mDL world, SD is an absolute requirement, JWTs obviously do not do SD without SD-JWT.
kristina: Doing JSON-LD and BBS ... BBS did not exist.
kristina: There was no JSON option ... so the SD-JWT work was forced to be accelerated.
kristina: SD-JWT seems like the best bet in the middle term.
kristina: 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.
kristina: I feel, honestly, a bit insecure in doing the definitions here and I would like the experts from this group to chime in.
kristina: I'd like to see if there's at least some value in doing this.
VC Test Suites
manu: I found this hideous slide deck, so I really wanted to use it.
manu: 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.
manu: 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.
manu: 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.
manu: no one knew how to maintain the test suite because it was in lisp. this is an example of the test.
manu: 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.
manu: 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: when you say the driver tells the issuer to issue, then driver tells verifier to verify, does this mean one impl?
manu: 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: could two implementations interop their verifiable credentials?
manu: yes
<Orie> I'm a big fan of "docker + cli" setups.
manu: 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.
manu: therefore we used a command line approach.
manu: 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> +1 to continuous nightly test reports!
gkellogg: 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: great point, agreed
<Orie> +1 to gkellogg
<brent> +1
manu: what happened in 1.1?
topic 1.1
manu: 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.
topic 2.0
manu: what are some requirements that we might want to apply here? test all the must normative statements in specs.
<Orie> +100 to this.
manu: 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.
manu: 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: 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> Link to W3C Process that describes the requirements for implementation experience: https://
<Orie> 2 options to consider, for the record, (docker + cli) : https://
ivan: for the publishing 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: that sounds very useful
<pchampin> https://
ivan: we realized this around a year ago, and we could use a tool where we could take the statements and link to tests
manu: sounds very useful, thanks!
+1 to testing shoulds
TallTed: 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.
TallTed: 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.
phila: 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> +1 to daily / weekly / monthly recurring tests.
<ivan> An example for what respec can give you (from an EPUB WG document)
<mkhraisha> huge +1 to recurring scheduled tests
manu: there is at least a subset of companies that want constant testing to show their customers.
phila: thanks
DavidC: 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: 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
DavidC: what about issuers
manu: 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.
decentralgabe: 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> A nice way to remove the infra requirement is to use docker + cli, and not use http.
YanZhang: 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: interactions?
YanZhang: so right now, with all the test suites, you're testing automatically. but is there any technical features to test for protocols?
manu: no, not authorized to work on protocol. there will be in time. there are things testing protocols outside, such as in CCG, OIDC, etc.
selfissued: 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.
selfissued: for example, in the JWT spec there were statements without the normative keyword terms, but they were required nonetheless.
selfissued: 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.
selfissued: 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.
<Zakim> brent, you wanted to talk about difference between what is required for Rec vs conformance testing
selfissued: when do you test SHOULDs? you often improve interoperability by testing SHOULDs. in normal implementations, you usually implement them anyway.
<kristina> +1 to brent we should differentiate the minimum from what is ideal
<Orie> +1
brent: 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.
<Zakim> gkellogg, you wanted to note that some specs add parameters to the manifest to group tests by type or attributes. and to note that some specs add parameters to the manifest to group tests by type or attributes. Also, to note GH Actions infrastructure
brent: some of the questions that the director/AC is asking for is if we have shown independent interoperable impls.
gkellogg: as an implementation technique, i've seen test suites add parameterization to the tests, so you can group tests by features to pass.
<Orie> +1 to github actions
gkellogg: 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.
<Zakim> phila, you wanted to respond to Mike
phila: 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.
+1 to sharing the test suite
phila: yes, it does fulfill, but there are more things to do too.
ivan: 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> I think github actions would be great, so implementers can use it in CI/CD
wayne: 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.
<Zakim> gkellogg, you wanted to discuss mutability of test suite after REC
gkellogg: 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.
topic 2.0 options
<Orie> This slide covers a few of the links I shared earlier... each of these suites has pro's and con's.
<Orie> Great slide Manu.
manu: we could keep test suites as-is, static and from command line.
manu: 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.
manu: we could use some other interface
manu: [showing screen for test suite] normative statements on left, tests on right. this is what we have today.
manu: 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: just a comment as an author. this covers both JsonWebSignature2020 and also VC-JWT because they both build on JOSE
Orie: keep them separate test suites, even if they're on the same docker-based deployment
Orie: 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.
<ivan> another example may be
manu: 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: that's right, it covers issuance of revocable + unrevocable credentials. e.g., if you issue things will the verifier accept it?
Orie: folks may not want to stand up an HTTP server to demonstrate the full conformance to the data model.
manu: 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> Credit to Mesur and Mavennet (and Transmute) for the work on the Traceability Test Suite... it also runs nightly.
manu: 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: there's another example here
manu: 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: [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.
ivan: 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.
ivan: it's a little bit different because each test is different, and we'd need to configure this.
manu: 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.
<phila> An alternative approach to test suites, aimed at devs
<Orie> phila thanks for the link to the digital link test suite... I love how interactive it is.
Internationization
Internationalization
<SamSmith> so is there not going to be a discussion about JSON Schema?
shigeya: 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: 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
<inaudible>
gregkellog: in JSON-LD 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 langauge identifer 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 requiremetns for top to bottom direction, we would need a modification.
shigeya: in the japanese language, we can manage without the veritical 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 langauges, 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 langauge map?
having a "multilingualDictionary" property in the VC that points to a minidictionary is interesting
shigeya: next steps, we need to consult internationalization experts
<Zakim> manu, you wanted to note preference for external mappings, not using current mechanisms.
shigeya: and draft PRs to address the mapping and externalization considerations
manu: great summary of the options
ivan: slide 342 i don't think this is JSON-LD
yeah, the existing examples don't work well for "simple JSON" users
manu: these are options available, but not sure this is being used in practice
… the externalization use case is the most compeling
… 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 benfits 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
… at this point I am feeling pretty -1 on slide 3342 and using the existing JSON-LD language features
… the experts told us to use the language features, but they didn't comment on externalization
<mccown> +1 for externalization.
manu: +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
<Zakim> gkellogg, you wanted to question manu's assertion that they're not working out.
<Zakim> Jay, you wanted to ask translation extension at FHIR
Jay: Is translation extension in HL7FHIR the same approach?
manu: i don't know FHIR enough to know
TallTed: I am concerned that externalizing it will limit its untility, and online offline acccess
… I don't know that we have really even tried the existing mechanisms
presumably the dictionary could also be embedded
<Zakim> phila, you wanted to talk about getting FHIR expertise
TallTed: I don't think the deployment of VCs todate has tested this
phila: there is an expert name Eric Prud'hommeaux (ericP in W3C circles)
<brent> External mechanisms make me mildly concerned about security risks.
yup, may be harder to do selective disclosure as well
shigeya: I think its good to externalize but then embed, and we can handle remote access as a seperate issue
Orie: 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> from Jay: FHIR 5.0 traslation extension in https://
Orie: 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
giving it more effort in v2.0.
brentz: 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.
<Zakim> phila, you wanted to talk about hashlinks for this
phila: I agree with Brent, and Orie... but this will effect the threat model
TallTed: the other thing about externalization is that they impact interfaces to the user as well, form elements, not form inputs
kristina: there seems to be a lot of support for this work
… we should create issues for this
JSON Schema and VC Data Model
the resulting language map could also include a reference back to the VC and be signed by the issuer
kristina: last official topic for the agenda
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: 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> (+1 to ivan...)
ivan: 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
dezell: 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
SamSmith: +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
wayne: 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
<Zakim> manu, you wanted to support further definition of this.
manu: +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: we can do both as long as we know they are different
decentragabe: yep, primary mission regarding the credential subject
pchampin: +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: 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.
Orie: When you have an API, you target a specific OpenAPI version.
dezell: 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.
phila: OAS is a standard?
<phila> https://
https://
ivan: the question is can we refer to it?
phila: that thing isn't a formal standard, but it seems used often... can we use it?
ivan: we do refer to schema.org normatively
kristina: great conversation
… see you on the issues
… this is the end of the official agenda
Editorial Work Mode
Editorial Work Mode
brent: we had a request to reiteerate 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 cchanges, only require 1 editor to sign off
… if concerns are raised, you may need to revert.
… thats it
<Zakim> manu, you wanted to note "FPWDs" and timeline for that.
manu: 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: 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: 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 publish
I am a little concerned with a 5th working document.. seeing the progress on other ones
ivan: it triggers patent disclosure, and gives us stable URLs
<Zakim> manu, you wanted to note we might want mandatory reviews on documents
manu: what we could do is mandatory reviews
… usually you just tell people, to read.
<brent> +1 to Ivan, FPWD sooner rather than later
manu: 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 consenus on the data integrity proof stuff
agreed on FPWD for data integrity now, would like more discussion before additional cryptosuite document
manu: +1 to what orie said, about publishing a crypto suite along side it
… if they are both ready, sooner the better'
sorry just got back getting a drink.
kristina: 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: I will do my best to clean up the minutes
… it will be hard, because I don't know all names
kristina: thanks to scribes
… joe, kevin, dave orie
brent: we will be off next week
sry...
brent: we decided not to cancel next week
kristina: thanks everyone!