00:00:07 <cel> SamSmith: ACDC is based on immutable schemas using CIDs/SAIDs
00:00:16 <Orie> possibly also related: https://datatracker.ietf.org/doc/html/draft-ietf-core-coral
00:00:19 <kristina> zakim, close the queue
00:00:19 <Zakim> ok, kristina, the speaker queue is closed
00:00:25 <kristina> q?
00:00:26 <cel> ... We would'nt use your schema, because it's not locked down enough. But could map to them.
00:00:33 <cel> ... After sending over the wire, can convert...
00:00:43 <cel> ... With JSON-LD, you sign the RDF graph after expansion
00:00:44 <Orie> actually, vc-jwt does sign JSON-LD.
00:00:54 <cel> ... We believe you should just sign what's sent over the wire, that's a more secure posture.
00:00:56 <Orie> it signs JSON.
00:00:58 <mprorock> Right orie
00:01:08 <cel> ... ToIP has OCA, a new schema representation... Or schema.org... could do those mappings
00:01:18 <cel> ... but we want to not be precluded from sending over the wire in our locked-down form
00:01:28 <cel> ... We can certainly define an interop profile from our schema to yours
00:01:30 <dlongley> all of these things sign hashes, actually :) ... if we're splitting hairs.
00:01:38 <kristina> ack decentralgabe
00:01:43 <decentralgabe> https://w3c-ccg.github.io/vc-json-schemas/v2/index.html
00:01:48 <cel> decentralgabe: There is a draft schema that does this ^
00:02:01 <cel> kristina: Thanks, thank you to the scribes!
00:02:23 <Orie> Thanks for presenting SamSmith!
00:02:32 <cel> kristina: I highly encourage people, especially WG chairs, to document issues that may help us move forward
00:02:46 <cel> ... We're starting to tomorrow at...
00:02:48 <pchampin> pchampin has joined #vcwg
00:02:57 <ivan_> rrsagent, draft minutes
00:02:57 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-vcwg-minutes.html ivan_
00:02:58 <cel> ... 9am.
00:03:44 <cel> 6:10 in lobby to talk to dinner
00:03:50 <cel> s/talk/walk/
00:04:51 <gkellogg> gkellogg has joined #vcwg
00:04:55 <Aisp> Aisp has joined #vcwg
00:05:36 <cel> manu: thanks to chairs for keeping us on schedule
00:39:35 <Jay> Jay has joined #vcwg
15:48:05 <RRSAgent> RRSAgent has joined #vcwg
15:48:05 <RRSAgent> logging to https://www.w3.org/2022/09/16-vcwg-irc
15:48:08 <Zakim> RRSAgent, make logs Public
15:48:09 <Zakim> please title this meeting ("meeting: ..."), ivan
15:48:37 <ivan> Meeting: Verifiable Credentials Working Group F2F, 2nd day
15:48:37 <ivan> Date: 2022-09-16
15:48:37 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2022Aug/0034.html
15:48:37 <ivan> chair: kristina, brent
15:49:00 <ivan> present+
15:52:35 <brent> brent has joined #vcwg
15:52:49 <risako> risako has joined #vcwg
15:52:55 <brent> present+
15:55:19 <takuya> takuya has joined #vcwg
15:55:38 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:56:30 <Aisp> Aisp has joined #vcwg
15:58:26 <phila> phila has joined #vcwg
16:00:06 <JoeAndrieu> Good morning, folks
16:00:11 <JoeAndrieu> q?
16:00:15 <JoeAndrieu> present+
16:00:22 <chike> chike has joined #vcwg
16:00:26 <kristina> kristina has joined #vcwg
16:00:29 <gkellogg> gkellogg has joined #vcwg
16:00:30 <kristina> present+
16:00:43 <JoeAndrieu> scribe+
16:00:55 <JoeAndrieu> brentz: Good morning. Still need some scribes.
16:01:17 <hsnao> hsnao has joined #vcwg
16:01:17 <JoeAndrieu> s/brentz/brent/
16:01:29 <hsnao> present+ Hiroyuki_Sano
16:01:31 <pchampin> pchampin has joined #vcwg
16:01:35 <gkellogg> gkellogg has joined #vcwg
16:01:37 <goto> goto has joined #vcwg
16:01:53 <gkellogg> present+
16:02:06 <osamu> osamu has joined #vcwg
16:02:16 <Orie> Orie has joined #vcwg
16:02:22 <Orie> present+
16:02:26 <Jem> Jem has joined #vcwg
16:02:38 <pchampin> present+ Pierre-Antoine_Champin
16:02:59 <Jay> Jay has joined #vcwg
16:03:24 <dezell> dezell has joined #vcwg
16:03:31 <dezell> present+
16:03:39 <osamu> present+
16:03:47 <Geun-Hyung_Kim> Geun-Hyung_Kim has joined #vcwg
16:04:09 <Geun-Hyung_Kim> present+
16:04:15 <Jay> present+
16:04:18 <kdeangs1> kdeangs1 has joined #vcwg
16:04:23 <kdeangs1> scribe+
16:04:24 <JoeAndrieu> brent: let's get started
16:04:36 <justin_r> justin_r has joined #vcwg
16:04:43 <JoeAndrieu> ... we are meeting under W3C IPR policy, so if you have something you want to patent, don't tell us.
16:04:56 <JoeAndrieu> ... We are also operating under the ethical code of conduct, so be nice. Just like you were yesterday.
16:05:03 <TallTed> present+
16:05:16 <JoeAndrieu> ... Today we are covering .... staring with Holder binded, from Oliver
16:05:24 <JoeAndrieu> ... Then a joint session with the RCH working group
16:05:28 <shigeya> present+
16:06:00 <JoeAndrieu> kristina: more this afternoon, ... finishing up with internationalization by Shigeya
16:06:16 <JoeAndrieu> ... If we need follow up or another session, let us know.
16:06:20 <JoeAndrieu> ... maybe we can fit it in.
16:06:24 <rgrant> rgrant has joined #vcwg
16:06:34 <manu> present+
16:06:51 <rgrant> rgrant has left #vcwg
16:07:00 <mccown> mccown has joined #vcwg
16:07:02 <phila> present+
16:07:13 <mccown> present+
16:07:22 <decentralgabe> decentralgabe has joined #vcwg
16:07:23 <goto> present+
16:07:28 <oliver> oliver has joined #vcwg
16:07:30 <decentralgabe> present+
16:07:30 <oliver> present+ oliver_terbu
16:07:38 <Mary> Mary has joined #vcwg
16:07:42 <wonsuk> wonsuk has joined #vcwg
16:07:47 <JoeAndrieu> oliver: Ok. Are we ready?
16:07:47 <rgrant> rgrant has joined #vcwg
16:07:57 <JoeAndrieu> ... First few slides is a recap of current roles in VC data model
16:08:04 <rgrant> present+
16:08:07 <JoeAndrieu> ... Everyone is likely familiar with this diagram. it describes the role in the model
16:08:25 <JoeAndrieu> ... Issuer creates a VC, issues to Holder, holder presents the VC to a Verifier (typically as a Verifiable Presentation)
16:08:36 <JoeAndrieu> ... I'm not super happy with this diagram because it leaves out some things
16:08:45 <JoeAndrieu> ... For example, the intended holder and the subject
16:08:53 <risako> present+ Risako_Hamano
16:09:08 <Paul_Dietrich_GS1> Paul_Dietrich_GS1 has joined #vcwg
16:09:09 <JoeAndrieu> ... From the current specification, a holder
16:09:19 <JoeAndrieu> ... Subject: ... (quotes from the spec)
16:09:52 <JoeAndrieu> ... Credential subject is mandatory, but each credentialSubject may contain an identifier
16:10:09 <JoeAndrieu> ... I have no problem with that, it's good to be able to skip that ID for privacy reasons
16:10:14 <JoeAndrieu> ... Just note you don't always have that ID
16:10:20 <JoeAndrieu> ... What is a VP?
16:10:50 <JoeAndrieu> ... 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.
16:11:01 <JoeAndrieu> ... That's something that we definitely need to address
16:11:14 <JoeAndrieu> ... Remember the VP may or may not include a holder property (which is also not normative)
16:11:19 <JoeAndrieu> ... Let's talk about holder binding
16:11:29 <JoeAndrieu> ... Many of us in our group understand this
16:11:45 <JoeAndrieu> ... A VC can be created by anyone...
16:11:58 <JoeAndrieu> ... The VC can be presented by anyone
16:12:09 <TallTed> s/staring with Holder binded/starting with Holder binding/
16:12:10 <ivan> ivan has joined #vcwg
16:12:12 <JoeAndrieu> ... We don't have semantics other than tamper-evidence and authorship
16:12:38 <JoeAndrieu> ... We do not guarantee that the holder is the intended recipient
16:12:51 <cabernet> cabernet has joined #vcwg
16:12:56 <JoeAndrieu> ... Verifier needs to perform additional steps to apply business rules to figure out if holder == subject
16:13:00 <cabernet> present+
16:13:24 <JoeAndrieu> ... This is a common use case for verifiers: to prove that the credential was presented by the intended holder
16:13:37 <JoeAndrieu> ... I create a VP, sign it, give it to my future employer.
16:13:48 <JoeAndrieu> ... This is a common use, but may not work for everyone.
16:14:20 <JoeAndrieu> ... If the subject ID is the same as the holder property.
16:14:26 <kristina> q?
16:14:47 <JoeAndrieu> ... Holder property is non-normative. We should fix this.
16:15:00 <JoeAndrieu> ... It is unclear who is the holder if the holder property is ommitted
16:15:09 <JoeAndrieu> ... The Credential Subject ID is optional (which is good)
16:15:55 <JoeAndrieu> ... 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.
16:16:07 <kristina> q?
16:16:09 <TallTed> q+
16:16:14 <kdeangs1> q+
16:16:17 <ivan> slideset: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_105
16:16:18 <JoeAndrieu> ... This doesn't work with anon-creds and BBS+, but it is the simplest model
16:16:18 <kristina> ack TallTed
16:16:41 <JoeAndrieu> tallted: I'm concerned about a few pieces. We explicitly decided that the holder need not be the subject.
16:16:49 <nadalin> nadalin has joined #vcwg
16:16:53 <JoeAndrieu> ... the subject is whatever entity those statements are about
16:17:00 <nadalin> present+
16:17:02 <JoeAndrieu> ... may be explicitly identified or not
16:17:07 <Orie> In general +1 to this... we need to create explict clarity regarding the cases where these `id` values match.
16:17:32 <JoeAndrieu> ... 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
16:17:51 <JoeAndrieu> oliver: Agreed. I'm just pointing out that this is a common pattern.
16:17:54 <nadalin> if the holder is not the subject how is holder authentication done?
16:18:02 <JoeAndrieu> tallted: but that's part of the problem.
16:18:05 <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.
16:18:08 <JoeAndrieu> ... if folks are doing the wrong thing, we want to fix that.
16:18:17 <JoeAndrieu> ... The presenter at the time they present it, *is* the holder
16:18:35 <JoeAndrieu> ... The presenter is never in a credential, nor in the VP either (as far as I recall)
16:18:36 <Orie> the presenter IS identified in a credential WHEN the holder matches the subject.
16:18:45 <kristina> ack kdeangs
16:18:49 <JoeAndrieu> kristina: queue please
16:18:55 <manu> q+ to note why holder isn't normative right now, and ask about use cases that we're focusing on and why it matters?
16:19:09 <JoeAndrieu> kevin: the way I see this, coming in relatively late.
16:19:14 <gkellogg> vq?
16:19:17 <JoeAndrieu> ... the absence of the holder means that anyone can hold it.
16:19:29 <JoeAndrieu> ... In the use cases that we have identified, the subject is far more critical than the holder.
16:19:29 <Orie> q+ to give use cases for holder / subject binding in B2B supply chain credential use cases.
16:19:38 <JoeAndrieu> ... Cases where the credential can be passed around
16:19:48 <JoeAndrieu> ... And it doesn't really matter how has it at any point.
16:19:55 <JoeAndrieu> ... It matters what it says about the subject.
16:20:00 <TallTed> +1 to speaker
16:20:02 <JoeAndrieu> ... That's important flexibility.
16:20:11 <kristina> q?
16:20:14 <Orie> yes, +1 thats how it works today, afaik.
16:20:17 <JoeAndrieu> oliver: Agreed.
16:20:30 <JoeAndrieu> ... This isn't about mandating any approach. This is what I've seen.
16:20:34 <kdeangs1> Thanks, Orie.
16:20:40 <JoeAndrieu> ... I agree that many use cases do not require it.
16:20:43 <Orie> +1 to what oliver is saying again.
16:20:51 <JoeAndrieu> ... I didn't mean to argue FOR this, but just to point out some gaps
16:20:52 <phila> s/kevin/kdeangs1/
16:21:10 <dlongley> sounds like a lot more agreement than disagreement here so far
16:21:21 <kristina> ack manu
16:21:21 <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?
16:21:23 <DavidC> DavidC has joined #vcwg
16:21:31 <DavidC> present+
16:21:33 <JoeAndrieu> manu: just for historical context
16:21:45 <JoeAndrieu> ... holder has no normative language because we added it later
16:21:46 <kristina> q?
16:21:49 <Orie> +1 Manu
16:21:56 <JoeAndrieu> ... we expected we would add something in 2.0 to clean that up
16:22:19 <Aisp_> Aisp_ has joined #vcwg
16:22:19 <JoeAndrieu> ... I think what we're hearing is that we could do a better job describing how holders fit into presentations
16:22:35 <kdeangs1> 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.
16:22:36 <JoeAndrieu> ... Might help illustrate this use case if we need the holder defined specifically
16:22:48 <JoeAndrieu> q+ to say Please do not think you can delegate credentials
16:23:09 <JoeAndrieu> manu: for example, a VC that specifies a parent and who should be holding it
16:23:16 <sb> sb has joined #vcwg
16:23:21 <JoeAndrieu> ... there's not guidance in the VC data model about what you are supposed to do it.
16:23:24 <DavidC> q+
16:23:29 <nadalin> q+
16:23:34 <JoeAndrieu> ... Do you have a use case where we need holder defined normatively
16:24:02 <pchampin> q+ to suggest that, when the holder matters, maybe they should also be a subject
16:24:11 <JoeAndrieu> 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
16:24:21 <kristina> q?
16:24:35 <JoeAndrieu> ... current spec has language for explaining for claiming DIDs are "sameAs" something like that
16:24:42 <JoeAndrieu> ... There are many many more.
16:24:57 <JoeAndrieu> ... It's tricky when we don't have values for subjects and holders.
16:25:11 <Orie> +1 to making `id` more required... making it optional doesn't buy what people think it does.
16:25:16 <JoeAndrieu> ... later in the slides, I'd like to talk about some specific things
16:25:36 <JoeAndrieu> manu: it would help if we had a clear set of use cases
16:25:49 <JoeAndrieu> kristina: growing queue. Let's process that a bit.
16:25:55 <kristina> ack Orie
16:25:55 <Zakim> Orie, you wanted to give use cases for holder / subject binding in B2B supply chain credential use cases.
16:26:13 <JoeAndrieu> orie: I'm queued to provide a use case for holder/subject binding in a supply chain use case
16:26:22 <YanZhang> YanZhang has joined #vcwg
16:26:29 <JoeAndrieu> ... you'll often have VCs from supply chain about each other, as part of compliance process.
16:26:40 <nadalin> in mDL Holder verification is intended to be at least equivalent to the attended mode, and example is using issuer provided portrait image
16:26:45 <JoeAndrieu> ... For example, I might have a cert about the quality of the farms I'm buying from
16:26:53 <JoeAndrieu> ... and a credential about my facility
16:26:56 <nadalin> q-
16:27:10 <JoeAndrieu> ... and I might present those credentials, where I am the subject, other where I am not.
16:27:41 <JoeAndrieu> ... This is where we would like to say... about the holder is SOMEBODY
16:27:45 <kristina> ack JoeAndrieu
16:27:45 <Zakim> JoeAndrieu, you wanted to say Please do not think you can delegate credentials
16:27:47 <manu> scribe+
16:28:00 <manu> JoeAndrieu: I want to clarify what you said, there is already delegatable stuff?
16:28:06 <manu> kristina: in the afternoon, a presentaton on it
16:28:49 <manu> 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.
16:28:56 <TallTed> +1 to Joe
16:29:02 <kristina> ack DavidC
16:29:03 <manu> JoeAndrieu: That isn't a good delegation use case, MANU.
16:29:28 <JoeAndrieu> davidc: privacy aside, we can regard a VC a bit like a public key certificate: anyone can pick it up
16:29:36 <JoeAndrieu> ... the trick is proof of control.
16:30:01 <JoeAndrieu> ... at the point of presentation, can the presenter prove they control the crypto
16:30:01 <kristina> q?
16:30:17 <Orie> related issue regarding disambiguating holder, https://github.com/w3c/vc-data-model/issues/902
16:30:25 <TallTed> "authorized to present" should not be by specifying "holder" within the VC; should be by specifying "valid if presented by" or similar
16:30:32 <JoeAndrieu> ... 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)
16:30:37 <kdeangs1> q+
16:30:40 <kristina> ack pchampin
16:30:40 <Zakim> pchampin, you wanted to suggest that, when the holder matters, maybe they should also be a subject
16:30:42 <Orie> +1 TallTed
16:30:44 <dlongley> TallTed: yeah, something like that
16:31:01 <JoeAndrieu> pchampin: seems to me when the holder matters, this should be somehow claimed, where the holder is the subject
16:31:10 <dlongley> "acceptablePresenter"
16:31:10 <manu> Agree with PA that that's an option.
16:31:11 <kristina> ack kdeangs
16:31:12 <YanZhang> q+
16:31:24 <JoeAndrieu> kdeangs1: I want to talk to the credential that someone is a member of the board
16:31:41 <justin_r> there are two different questions: "Is the presenter allowed to present this?" and "is the presenter the subject?"
16:31:44 <JoeAndrieu> ... The usefulness of that credential is independent of who holds it.
16:31:48 <kristina> ack YanZhang
16:32:02 <Orie> +1 justin_r !
16:32:10 <JoeAndrieu> YanZhang: for a verifier to prove something, a particular good is related to IP on chain.
16:32:10 <pchampin> s/ where the holder is the subject/ where the holder is a subject/
16:32:18 <JoeAndrieu> ... This is hard to prove.
16:32:26 <rgrant> +1 justin_r
16:32:37 <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
16:32:46 <JoeAndrieu> ... It's helpful to reserve a field where we can say something about whether or not the presenter must be the subject
16:33:01 <JoeAndrieu> ... I think we can leave this in a limbo mode if we reserve a field for future use
16:33:13 <justin_r> dlongley: it seems to me the second one is the harder one because it requires outside knowledge about the subject
16:33:33 <JoeAndrieu> oliver: proof of possession is also hard to prove in a canonical way
16:33:33 <justin_r> dlongley: otherwise the security comes down to only handing VCs to the subjects and nobody else
16:33:43 <JoeAndrieu> ... the diversity of proving control and that I'm the intended holder
16:33:46 <dlongley> justin_r: yeah, i guess it depends on whether you can do simple identifier equivalence or not
16:34:08 <JoeAndrieu> ... Consider VC issued to Alice, Alice gives it to Bob
16:34:15 <JoeAndrieu> ... Bob gives it to Verifier.
16:34:19 <justin_r> dlongley: good point, I was assuming a world with pairwise IDs everywhere, as a starting point
16:34:20 <YanZhang> just mark whether this VC is supposed to be bond to a subject or not.
16:34:25 <JoeAndrieu> ... Verifier doesn't know if Bob is the intended holder
16:34:35 <dlongley> justin_r: yeah, depends on the use case / privacy requirements.
16:34:38 <JoeAndrieu> ... currently there is something about holder binding
16:34:47 <justin_r> dlongley: agreed
16:34:52 <JoeAndrieu> ... We had a bunch of issues about this to make the binding more explicit
16:35:11 <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.
16:35:13 <JoeAndrieu> ... what is asked that the VP is presented by the intended holder
16:35:35 <kristina> q?
16:35:39 <JoeAndrieu> ... It can get more complicated than this.
16:35:46 <nadalin> holder can be a device and device can have attestation
16:35:53 <JoeAndrieu> ... For example, when the VCs have multiple IDs
16:36:01 <Orie> +1 nadalin
16:36:08 <JoeAndrieu> ... Or consider the alsoknownas property
16:36:24 <Orie> people are not devices, both deserve the right to `id`s.
16:36:26 <JoeAndrieu> ... q+ to talk about the intended holder as an anti-pattern
16:36:30 <JoeAndrieu> whoops
16:36:39 <sebastianelfors> sebastianelfors has joined #vcwg
16:36:39 <dlongley> +1 to device use case ... there could also be "bindings to a type of device" (as opposed to a specific one)
16:36:41 <JoeAndrieu> q+ to talk about the intended holder as an anti-pattern
16:36:50 <TallTed> "Holder Binding" is problematic from the start
16:36:56 <kristina> s/q+ to talk about the intended holder as an anti-pattern/.
16:37:00 <JoeAndrieu> oliver: let's try to define what holder binding really means
16:37:17 <JoeAndrieu> ... A way to validate the intended holder is the presenter of a VP
16:37:25 <dlongley> "Presenter binding"
16:37:34 <JoeAndrieu> ... We need to bind: they might be the subject. They might be claims made by the issuer.
16:37:52 <rgrant> q?
16:37:54 <TallTed> "Presenter binding" is better, but "binding" also isn't right
16:37:57 <JoeAndrieu> ... The holder of the VC, even though there is no holder identifier, presents a proof
16:38:02 <dlongley> TallTed: agreed
16:38:06 <JoeAndrieu> ... I hope this meets the sense of the group
16:38:12 <JoeAndrieu> of what holder binding is
16:38:34 <kristina> ack JoeAndrieu
16:38:35 <Zakim> JoeAndrieu, you wanted to talk about the intended holder as an anti-pattern
16:39:09 <phila> q+
16:39:19 <kdeangs1> q+
16:39:20 <manu> 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..
16:39:40 <dlongley> "acceptable / intended presenter" seems better here
16:39:55 <JoeAndrieu> oliver: a lot of people deployed solutions based on the model, where they want to check if the VP is issued by.
16:40:08 <manu> q+ to follow on w/ dlongley's suggestion "acceptablePresenter" with array of presenters?
16:40:10 <JoeAndrieu> ... check if the VP is issued by the subject
16:40:16 <rgrant> q+ to mention that those asks are asking for business rules.  are business rules in scope?
16:40:29 <nadalin> mDL has the normative concept of holder of the mDoc
16:40:31 <JoeAndrieu> ... There is one proposal to ...
16:40:50 <JoeAndrieu> ... Holder binding should not be tied to the VC, but maybe rather at the VP point
16:41:12 <Jeremie> Jeremie has joined #vcwg
16:41:19 <JoeAndrieu> ... We might be able to use NIST 800-63-3
16:41:30 <JoeAndrieu> ... But that doesn't deal with the actual binging mechanism.
16:41:37 <JoeAndrieu> ... Maybe we could use it in the VP proof.
16:41:59 <ivan> ivan has joined #vcwg
16:42:00 <JoeAndrieu> ... But then, even if you verify the VP, you don't know that it was presented by the right party
16:42:00 <TallTed> ..."intended presenter"
16:42:15 <phila> q-
16:42:24 <manu> q-
16:42:25 <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
16:42:35 <JoeAndrieu> ... Reusing the evidence property might work, but it isn't defined at VP level
16:42:50 <kristina> q?
16:43:03 <JoeAndrieu> ... I would suggest, creating a new VP/holder binding mechanism
16:43:20 <JoeAndrieu> ... Potentially restrict how the credential can be used
16:43:39 <JoeAndrieu> q+ to say any restrictions on how a credential can be used is censorship
16:43:58 <JoeAndrieu> oliver: binding the holder to the VP with maximum flexibility
16:44:12 <JoeAndrieu> ... a list of requirements
16:44:27 <JoeAndrieu> ... first, allow verifier to
16:44:34 <manu> q+ to note we might want this thing to be an array
16:44:38 <JoeAndrieu> ... [too fast, check slides]
16:45:02 <manu> q-
16:45:03 <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"
16:45:06 <JoeAndrieu> ... It should be able to create VCs and VPs without holder binding
16:45:28 <selfissued> selfissued has joined #vcwg
16:45:39 <JoeAndrieu> kristina: let's look at the concrete proposal
16:45:40 <selfissued> present+
16:45:51 <dlongley> present+
16:45:57 <JoeAndrieu> oliver: based on discussion, I came up with a proposal.
16:46:21 <JoeAndrieu> ... add holderBinding to VC
16:46:22 <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://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660
16:46:26 <manu> q+ to be generally supportive of the need to find a solution to this problem and to refine the initial proposal.
16:46:39 <JoeAndrieu> ... include the following that includes a type property about how the binding can be verified.
16:47:01 <JoeAndrieu> ... The holder binding information may also include information about VPs, such as references to VCs
16:47:27 <JoeAndrieu> ... for example, it might define that a particular key is checked against a property in the VP
16:47:38 <JoeAndrieu> ... that's the proposal
16:48:15 <JoeAndrieu> ... I want to guide the verifier to understand which holder binding method applies.
16:48:34 <JoeAndrieu> ... There might be binding methods where there are agreements.
16:48:50 <JoeAndrieu> ... That's basically my proposal. That would address the concerns raised.
16:48:56 <kristina> q?
16:49:10 <neds> neds has joined #vcwg
16:49:13 <kristina> ack kdeangs
16:49:23 <brent> chair hat off, establishing a standard method for expressing private holder binding is valuable for Avast.
16:49:33 <dwaite> dwaite has joined #vcwg
16:49:34 <JoeAndrieu> kdeangs1: the more I think about this, the more uncomfortable about this.
16:49:36 <wonsuk_> wonsuk_ has joined #vcwg
16:49:37 <dwaite> present+
16:49:45 <Jeremie> present+
16:49:54 <JoeAndrieu> ... consider a passport. when we present that at a border crossing, we have to present our own
16:50:12 <brent> q+ to say that whether to check holder binding is up to the verifier
16:50:15 <JoeAndrieu> ... but there are other use cases that don't require that holder = subject
16:50:22 <JoeAndrieu> ... It is use case specific.
16:50:33 <Jeremie> holder is different than subject, no?
16:50:34 <dwaite> q+ to relationship of subject to holder
16:50:37 <brent> q+ to say biometrics are a method of holder binding
16:50:38 <JoeAndrieu> ... It is the use case that would decide who the holder should be when it is presented
16:50:59 <JoeAndrieu> ... I would be hard pressed to think of an example where it is appropriate where only one party can ever present that
16:51:11 <brent> q+ to say that framing this as a limiting factor decided by the issuer isn't really correct
16:51:14 <DavidC> q+
16:51:25 <JoeAndrieu> oliver: yes, I wouldn't want this to be required
16:51:36 <JoeAndrieu> ... but it would make it so much easier for the verifier
16:51:51 <JoeAndrieu> ... This isn't about limiting, it is about enabling
16:51:58 <kristina> ack rgrant
16:51:58 <Zakim> rgrant, you wanted to mention that those asks are asking for business rules.  are business rules in scope?
16:52:04 <pchampin> if it's use-case specific, shouldn't this be decided by the verifier rather than the presenter?
16:52:27 <JoeAndrieu> rgrant: seems like we are identifying a few business rules based on how credentials are typically used
16:52:38 <JoeAndrieu> ... are there others? are we being comprehensive about this.
16:52:50 <JoeAndrieu> ... it may be useful to be more comprehenshive about it
16:52:55 <kristina> ack JoeAndrieu
16:52:55 <Zakim> JoeAndrieu, you wanted to say any restrictions on how a credential can be used is censorship
16:53:09 <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?
16:53:28 <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
16:54:14 <phila> +1 to JoeAndrieu
16:54:16 <brent> +1 to Joe, except in cases where a verifier needs to know
16:54:24 <manu> 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
16:54:25 <manu> 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.
16:54:28 <SamSmith> q+
16:54:29 <kristina> ack manu
16:54:30 <Zakim> manu, you wanted to be generally supportive of the need to find a solution to this problem and to refine the initial proposal.
16:54:44 <JoeAndrieu> manu: oliver's provided some good food for thought.
16:54:56 <JoeAndrieu> ... I remain skeptical about the restriction part of this proposal
16:55:05 <SamSmith> q-
16:55:07 <JoeAndrieu> ... if we don't do it in this group, it's just going to get done elsewhere
16:55:16 <JoeAndrieu> ... so let's see if we can improve our language
16:55:17 <kristina> ack brent
16:55:17 <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
16:55:20 <Zakim> ... factor decided by the issuer isn't really correct
16:55:29 <Yi> Yi has joined #vcwg
16:55:49 <JoeAndrieu> brent: framing this as a limiting factor of the credential isn't the right way to think about this
16:55:59 <JoeAndrieu> ... when I think about it, I see it as a concern that some verifiers have.
16:56:09 <JoeAndrieu> ... This *is* a concern that verifiers have.
16:56:27 <YanZhang> https://vitalik.ca/general/2022/01/26/soulbound.html
16:56:31 <JoeAndrieu> ... Sometimes they will need prove that the presenter is the "right" party
16:56:37 <YanZhang> Soul bounding tokens
16:56:47 <JoeAndrieu> ... I want to point out that in my mental model, having a methodology for private holder binding
16:57:10 <Jeremie> q+ is using an ephemeral key for replay prevention also considered holder binding
16:57:11 <gkellogg> Presumably, something like a Search Warrant is only valid when presented by an authorized authority.
16:57:14 <JoeAndrieu> ... that's similar to biometric binding, where the passport is expected to be used by the person whose photo is on the document
16:57:17 <YanZhang> there are situations VP shall only be used by the holder. Like in the DAO governance process
16:57:18 <decentralgabe> +1 Brent
16:57:21 <kristina> ack dwaite
16:57:22 <Zakim> dwaite, you wanted to relationship of subject to holder
16:57:24 <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
16:57:45 <kristina> q+ Jeremie to say using an ephemeral key for replay prevention also considered holder binding
16:57:46 <SamSmith> The term Holder unfortunately does not have such separation.
16:57:50 <Jeremie> q+ is using an ephemeral key for replay prevention, also considered holder binding?
16:57:55 <JoeAndrieu> dwaite: the way I look at it, is, if the holder *is* presenting, that can be handles as the subject in a new VC.
16:58:08 <TallTed> gkellogg -- Search Warrant doesn't typically specify presenting officer, allows any relevant officer to present it
16:58:08 <YanZhang> passport is different, I often time to give my passport to the travel agency and ask them to apply Visa for me
16:58:09 <Jeremie> q+ to ask is using an ephemeral key for replay prevention, also considered holder binding?
16:58:11 <JoeAndrieu> ... if the person who is allowed to present a birth certificate is their parent.
16:58:18 <JoeAndrieu> ... we may already have ways to do this
16:58:23 <SamSmith> q+
16:58:27 <brent> +1 to DW, but relationships I think are orthogonal
16:59:01 <kristina> q?
16:59:03 <JoeAndrieu> 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".
16:59:06 <kristina> ack DavidC
16:59:13 <kristina> ack Jeremie
16:59:13 <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
16:59:16 <Zakim> ... holder binding?
16:59:44 <JoeAndrieu> jeremie: holder binding where the key is ephemeral and just used for replay protection, is it really just for preventing reply attacks
16:59:46 <kristina> ack SamSmith
17:00:15 <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.
17:00:22 <JoeAndrieu> samsmith: we looked at the roles of the holder and we saw this ambiguity, so we have issuers and issuees... disclosures and disclosee
17:00:24 <JoeAndrieu> ... and so on
17:00:24 <Jeremie> JoeAndrieu: I agree, thanks, they just functionally look almost identical
17:00:32 <JoeAndrieu> ... then this confusion went away for us.
17:00:37 <JoeAndrieu> ... "We" is AC/DC
17:00:41 <rgrant> +1 to SamSmith's definitions
17:00:50 <igarashi> igarashi has joined #vcwg
17:00:52 <YanZhang> or we distinguish issuees from holders
17:00:55 <kristina> q?
17:00:58 <igarashi> present+ Tatsuya_Igarashi
17:01:13 <JoeAndrieu> kristina: that's it for the queue! Thanks, Oliver
17:01:52 <JoeAndrieu> ... next steps: discussion in Github issue, eventually to a PR
17:01:53 <Orie> q?
17:02:17 <Orie> oliver: I would start a normative definition for holder on an issue.
17:02:40 <Paul_Dietrich_GS1> present-
17:02:44 <ivan> rrsagent, draft minutes
17:02:44 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-vcwg-minutes.html ivan
17:05:26 <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://www.w3.org/2022/09/16-vcwg-minutes.html to confirm.)
17:08:07 <wonsuk> wonsuk has joined #vcwg
17:10:59 <wonsuk> present+ Wonsuk_Lee
17:15:46 <gkellogg> gkellogg has joined #vcwg
17:16:57 <phila> phila has joined #vcwg
17:17:43 <kdeangs1> scribe: kdeangs1
17:17:48 <rgrant> present+
17:17:49 <cabernet_> cabernet_ has joined #vcwg
17:17:50 <markus_sabadello> markus_sabadello has joined #vcwg
17:17:57 <cabernet_> present+
17:18:06 <gkellogg> present+
17:18:13 <Orie> present+
17:18:53 <kdeangs1> markus: Thanks to the VC working group for their hospitality. Joint session to discuss how working groups relate.
17:18:54 <yamdan> yamdan has joined #vcwg
17:19:11 <kdeangs1> s/markus/markus_sabadello/
17:19:16 <seth> seth has joined #vcwg
17:19:29 <kdeangs1> markus_sabadello: Not in Vancouver.
17:19:42 <ivan> ivan has joined #vcwg
17:19:45 <kdeangs1> ... Quite involved in DID, a little involved in VC.
17:19:57 <ivan> ivan has joined #vcwg
17:20:08 <kdeangs1> ... Chair of RDF Canonicalization and Hashing working group, AKA RCH.
17:20:21 <kdeangs1> phila: I'm a co-chair of the working group.
17:20:50 <kdeangs1> ... 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.
17:22:26 <kdeangs1> markus_sabadello: Output of RCH working group is meant to be generic. Important though that this be applied to VCs.
17:22:44 <phila> -> https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_115 slides
17:23:11 <kdeangs1> ... Quick introduction. Something gets hashed on the slide. VC contains proof and proof value, which is a signature of the VC.
17:23:53 <kdeangs1> ... Proof will be partially standardized in VC working group but will also include work from RCH working group.
17:24:14 <lgombos> lgombos has joined #vcwg
17:24:32 <kdeangs1> ... Deliverables of RCH WG are RDF dataset hash and RDF dataset canonicalization.
17:24:53 <selfissued> selfissued has joined #vcwg
17:24:55 <dwaite> dwaite has joined #vcwg
17:25:03 <selfissued> present+
17:25:10 <kdeangs1> ... RDF dataset hash will be derived from canonicalization, which is about creating a canonicalized form of the RDF dataset
17:25:24 <kristina> q?
17:26:55 <kdeangs1> ... 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,
17:27:15 <kdeangs1> ... VC Data Integrity has dependency on RCHWG deliverables.
17:28:25 <kdeangs1> ... VC Data Integrity is still evolving. New cryptography suites are being proposed. Some are not signatures e.g., MerleDisclosureProof2021.
17:29:16 <Orie> Yes, there are details related to BBS+ ... also there is an alternative to it that goes even deeper... https://github.com/zkp-ld/jsonld-signatures-bbs
17:29:40 <kdeangs1> ... RCHWG has to ensure that its deliverables meet the requirements of the VCWG.
17:29:43 <Orie> q+ to ask about rdf* and RCH
17:30:08 <manu> q+
17:30:09 <kdeangs1> ... What does VCWG want, that does not restrict output of RCHWG to working only for VCs?
17:30:18 <phila> ack Orie
17:30:18 <Zakim> Orie, you wanted to ask about rdf* and RCH
17:30:32 <manu> q+ to note timeline and staging will be a concern.
17:30:49 <kdeangs1> orie: There is a version of BBS+ signatures that supports term-wise security.
17:31:28 <manu> q+ to note other canonicalization schemes for WoT
17:31:30 <phila> phila: https://github.com/w3c/rch-rdc/issues/2
17:31:30 <kdeangs1> ... New RDF*, is it possible that changes to that would result in another version of RDF normalization, which would change RCHWG deliverables?
17:31:46 <gkellogg> s/RDF*/RDF-star/
17:31:49 <kdeangs1> phila: I've put a few high-level issues in GitHub, including, "What are we going to do about RDF*?"
17:31:53 <dlongley> q+
17:31:59 <phila> q?
17:32:13 <dlongley> q-
17:32:22 <phila> ack manu
17:32:22 <Zakim> manu, you wanted to note timeline and staging will be a concern. and to note other canonicalization schemes for WoT
17:32:25 <kristina> does RDF* introduce a lot of breaking changes from RDF?
17:32:33 <phila> No kristina
17:32:34 <gkellogg> s/RDF*/RDF-star/
17:32:38 <takashi> takashi has joined #vcwg
17:32:43 <kdeangs1> manu: Markus, you asked what does this group need from RCHWG?
17:32:45 <pchampin> kristina, no branking change, but it extends the data model
17:32:52 <Orie> kristina: afaik, it adds the ability to annotate edges, which would impact nquads... somehow...
17:33:00 <kristina> thanks!
17:33:01 <TallTed> s/RDF*/RDF-star/
17:33:02 <pchampin> Orie +1
17:33:16 <ivan> q+
17:33:19 <dlongley> Orie: i'll mention something relevant to RDF-star + RDF canonicalization just briefly in my presentation at the end
17:33:25 <TallTed> s/rdf* and RCH/RDF-star and RCH/
17:33:44 <kdeangs1_> kdeangs1_ has joined #vcwg
17:34:01 <selfissued> q+
17:34:28 <kdeangs1_> manu: Concerned that we would have data integrity CR-ready five to six months ahead of RCH WG deliverable.
17:34:41 <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.)
17:34:43 <kdeangs1_> ... May receive canonicalization from RCH WG and web of things WG.
17:35:05 <kdeangs1_> ... Current canonicalization scheme will continue to work.
17:35:13 <yamdan> thanks Orie for mentioning Term-wise BBS+, which actually I'm in charge of
17:35:26 <kdeangs1_> ... Doesn't stop us from standardizing the thing that's been out there for a decade now. 2015 is the current version.
17:35:49 <kdeangs1_> ... Focus hopefully will be on standardizing 2015 version.
17:36:08 <markus_sabadello> q+
17:36:10 <Orie> yamdan: feel free to q in case you have opinions on how canonization impacts termise disclosure.
17:36:34 <kdeangs1_> 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.
17:36:44 <kdeangs1_> ... That would be an abuse of the system.
17:36:57 <kdeangs1_> ... Going to hear from Dave and Aiden who have been working on this.
17:37:08 <kdeangs1_> ... I don't think there's a different approach.
17:37:26 <kdeangs1_> ... Feel free to raise an issue in the RCHWG GitHub.
17:37:30 <phila> q?
17:37:34 <phila> ack ivan
17:37:51 <pchampin> https://github.com/w3c/rch-rdc
17:38:00 <wonsuk> wonsuk has joined #vcwg
17:38:29 <kdeangs1_> 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.
17:38:29 <manu> q+ to ask if we can go to CR w/o URDNA2015 being in CR as well?
17:38:51 <Orie> pchampin: can you provide a link to the rendered spec ?
17:39:30 <pchampin> Orie: there's none yet, we have only just started
17:39:49 <kdeangs1_> ... If we find a canonicalization algorithm that meets the requirements, I would be surprised.
17:40:03 <pchampin> but that will likely be https://w3c.github.io/rch-rdc/, eventually
17:40:08 <phila> vq?
17:40:10 <kdeangs1_> ... I don't expect something new popping up.
17:40:47 <kdeangs1_> ... Can we explore the possibility of exploring certain RDF graphs with given characteristics that would lead to faster c14n?\
17:41:00 <kdeangs1_> ... Reluctant to categorize RDF graphs as they are difficult to categorize.
17:41:39 <kdeangs1_> ... Well-ordered RDF graphs can be put down in Turtle.
17:41:49 <phila> ack manu
17:41:49 <Zakim> manu, you wanted to ask if we can go to CR w/o URDNA2015 being in CR as well?
17:41:59 <dezell> dezell has joined #vcwg
17:42:07 <dezell> present+
17:42:10 <kdeangs1_> manu: Ivan, we could proceed to CR. I don't think we can proceed to CR unless 2015 is in there.
17:42:15 <phila> ack selfissued
17:42:21 <kdeangs1_> ivan: No, we can stay in CR if we have a working draft.
17:42:40 <kdeangs1_> selfissued: Who is it that wants to use the JCS c14n?
17:42:43 <manu> q+ to answer selfissued
17:42:54 <phila> ack manu
17:42:54 <Zakim> manu, you wanted to answer selfissued
17:43:02 <Orie> For the notes, this is the related JCS spec: https://datatracker.ietf.org/doc/html/rfc8785
17:43:08 <kdeangs1_> manu: Because they don't like RDF and want to use a different data stream.
17:43:29 <kdeangs1_> ... They have JSON-E templates that they want to inject data into.
17:43:48 <kdeangs1_> ... Very specific to their (Web of Things) use case.
17:44:04 <phila> q+ to talk about algo IDs as part of the c14n
17:44:27 <kdeangs1_> McCool: Want to avoid having to run RDF systems on IoT hubs due to size requirements.
17:44:31 <dwaite> dwaite has joined #vcwg
17:44:44 <kdeangs1_> ... Might have to support multiple styles of signing.
17:45:03 <sb> q+
17:45:15 <kdeangs1_> ... Need some standard way to JSON serialized assignment.
17:45:19 <sb> to answer why jcs?
17:45:22 <phila> ack markus_sabadello
17:45:32 <phila> q-
17:45:40 <kdeangs1_> markus_sabadello: I like the comments so far. I think it's looking better.
17:46:07 <kdeangs1_> ... OK to move at different speeds.
17:46:11 <manu> Also note that when you use JCS, you open up the possibility of signing invalid data
17:46:33 <phila> ack sb
17:46:34 <manu> (when you're using JSON-LD + JCS -- more security attack surface for an easier canonicalization)
17:46:36 <kdeangs1_> ... If anyone feels that RCH WG should work with JCS c14n, say so.
17:46:47 <manu> q+ to note dangers w/ JCS c14n.
17:46:47 <Orie> Regarding the web of things interest in JSON / JSON-LD stuff, we do use some JCS here: https://w3id.org/traceability as part of our JSON-LD context generation process from JSON Schema.
17:46:59 <markus_sabadello> q+
17:47:36 <Orie> AFAIK, JCS is used under the hood by URDNA2015 for `@type: @json`
17:47:49 <kdeangs1_> 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.
17:48:07 <McCool> q?
17:48:13 <Orie> +1 Shawn
17:48:19 <kdeangs1_> ... I can't do anything to make Jackson libraries better.
17:48:33 <McCool> q++
17:48:37 <McCool> qq+
17:48:52 <kdeangs1_> ... Easy for implementers to understand. Output is consistent and reliable.
17:49:00 <phila> ack McCool
17:49:00 <Zakim> McCool, you wanted to react to sb
17:49:11 <phila> q- +
17:49:33 <kdeangs1_> 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.
17:49:57 <ivan_> ivan_ has joined #vcwg
17:49:59 <kdeangs1_> ... Some elements have default values. Do we insert them or ignore them if not present?
17:50:10 <phila> ack markus_sabadello
17:50:15 <phila> q+ markus_sabadello
17:50:18 <phila> ack manu
17:50:18 <Zakim> manu, you wanted to note dangers w/ JCS c14n.
17:50:46 <kdeangs1_> manu: I don't want people to come away thinking that JWS is equivalent to RDF c14n. JWS risks developers signing anything.
17:50:49 <Orie> When you use URDNA2015 on `@json`... you are using JCS.
17:51:01 <selfissued> Manu, in what way is the security threat surface opened up?
17:51:28 <kdeangs1_> ... If your developers know what they're doing, they will hopefully write extensions that are  usable.
17:51:29 <sb> I'm also not sure what @manu means either.
17:51:39 <kristina> kristina has joined #vcwg
17:51:42 <phila> ack markus_sabadello
17:51:44 <kristina> present+
17:51:47 <kdeangs1_> phila: Existing spec does use JCS, per Orie.
17:52:19 <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.
17:52:20 <kdeangs1_> markus_sabadello: Back to relationship between two groups.
17:52:23 <manu> (if you have no context)
17:52:26 <McCool> present+ Michael_McCool
17:52:58 <kdeangs1_> ... How do you get to the hash value given the data set displayed?
17:53:22 <kdeangs1_> ... The VC data model defines pretty much everything except what's in the proof.
17:53:34 <phila> q?
17:54:02 <kdeangs1_> ... What's in the proof object define what gets canonicalized and hashed to create the proof value.
17:54:39 <kdeangs1_> ... I imagine that VC data integrity specification plus crypto suite will drive how to do it.
17:55:07 <kdeangs1_> ... Need to define boundary between and VC data integrity and crypto suites.
17:55:28 <kdeangs1_> ... I would like to get some input from the VCWG.
17:56:00 <Orie> related to existing VC WG things at JCS... https://github.com/w3c/vc-jws-2020/blob/main/contexts/v1/index.json#L15
17:56:08 <kdeangs1_> phila: I think we will be getting a lot of input as there is a lot of overlap between the two groups.
17:56:22 <kdeangs1_> ... Need to be aware of the timing.
17:56:35 <kdeangs1_> markus_sabadello: No more questions to ask of VCWG.
17:57:01 <mkhraisha> mkhraisha has joined #vcwg
17:57:22 <kdeangs1_> ... My understanding is that what gets hashed is not only a hash of the RDF dataset but also of some of the proof attributes.
17:57:31 <manu> q+ to note hash of credential and hash of proof are combined and hashed, and complexities with BBS+
17:57:46 <phila> ack manu
17:57:46 <Zakim> manu, you wanted to note hash of credential and hash of proof are combined and hashed, and complexities with BBS+
17:58:07 <kdeangs1_> manu: I wish I had an answer. This is something that belongs in data integrity.
17:58:10 <dlongley> +1 to it being in data integrity, data integrity combines the primitives output from the RCH WG as needed
17:58:34 <Orie> For those that prefer to read code, this is a version of the "create verify data" algorithm: https://github.com/transmute-industries/RsaSignature2017/blob/master/src/common.js#L14
17:58:37 <kdeangs1_> ... Proof options (algorithm, date/time, verification method) are a separate RDF data set from the main VC.
17:58:59 <kdeangs1_> ... If we draw the line where the RCHWG... I don't know.
17:59:23 <dlongley> q+
17:59:51 <kdeangs1_> ... Other detail is that there are interesting aspects of BBS+. One of them is to ensure that selective disclosure works.
18:00:15 <dlongley> hash-based message authentication code = HMAC
18:00:21 <kdeangs1_> ... May require using HMAC as part of the canonicalization.
18:00:33 <Orie> Regarding some of the existing BBS+ statement approach manu is talking about: https://github.com/transmute-industries/verifiable-data/blob/main/packages/bbs-bls12381-signature-2020/src/BbsBlsSignature2020.ts#L106
18:00:39 <kdeangs1_> ... May want to canonicalize statement by statement.
18:00:53 <Orie> its also related to the termise use case mention previously.
18:01:11 <kdeangs1_> ... I'm just highlighting things that need to be formalized in the specification.
18:01:43 <kdeangs1_> markus_sabadello: My understanding is that individual statements need to be canonicalized for BBS+.
18:01:59 <Karen> Karen has joined #vcwg
18:02:05 <Orie> Yes Markus, there is a version of this same thing that works with merkle proofs and vanilla JWS -  https://w3c-ccg.github.io/Merkle-Disclosure-2021/
18:02:05 <kdeangs1_> ... This could be a very short specification.
18:02:20 <brent> q?
18:02:41 <kdeangs1_> ivan: Historically, when we wrote the charter, the focus was always on the c14n.
18:03:08 <kdeangs1_> ... The fact that we separated the hash makes it trivial.
18:03:25 <Orie> There is also some work done by gov of singapore I believe related to merkle proofs and nquads.
18:03:30 <kdeangs1_> ... WG may decide that it's not a separate deliverable.
18:04:05 <phila> ack dlongley
18:04:08 <kdeangs1_> ... Creating the charter was a very long process. Hash has been separated from the c14n to make it easier.
18:04:42 <phila> -> https://www.w3.org/2022/07/rch-wg-charter/explainer.html Explainer
18:04:50 <kdeangs1_> dlongley: Comment on where is the line between VCWG and RCHWG. RCHWG is responsible for creating primitives that can be incorporated into VCWG.
18:05:32 <markus_sabadello> q+
18:05:34 <gkellogg> q+
18:05:43 <phila> ack markus_sabadello
18:05:43 <kdeangs1_> phila: Although not listed, a good use case, including those not feeding VCS, is going to drive this forward.
18:06:30 <gkellogg> q+ to request specific requirements from VCWG on the Hash spec, and question the division of responsibility between RDFC14N and Hash.
18:06:52 <kdeangs1_> markus_sabadello: RDF dataset c14n, understanding is that input is an RDF dataset and output is also an RDF dataset.
18:06:56 <phila> ack gkellogg
18:06:57 <Zakim> gkellogg, you wanted to request specific requirements from VCWG on the Hash spec, and question the division of responsibility between RDFC14N and Hash.
18:07:09 <Orie> For the notes, the current draft for bbs+ data integrity - https://w3c-ccg.github.io/ldp-bbs2020/ and Mattr's implementation https://github.com/mattrglobal/jsonld-signatures-bbs
18:07:35 <ivan_> q+
18:07:44 <dlongley> good questions for the RCH WG to answer later, i think :)
18:07:45 <kdeangs1_> 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?
18:08:15 <kdeangs1_> ... I'm feeling right now that the requirements of what the hashing spec needs to do is vague.
18:08:21 <phila> ack next
18:08:33 <pchampin> I believe that the output of c14n is a mapping from blank nodes to labels
18:08:58 <kdeangs1_> 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.
18:09:15 <kdeangs1_> ... Both create proofs in a canonical way. Dataset doesn't change.
18:09:16 <shawnb> shawnb has joined #vcwg
18:09:32 <kdeangs1_> phila: That is my understanding as well.
18:10:19 <kdeangs1_> ... In my head, you can chuck in any serialization of RDF and the output is the same.
18:10:31 <kdeangs1_> ... Two people on the phone who have done this.
18:11:06 <phila> -> https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g15613afc368_10_35 Dave's slids start here
18:11:12 <kdeangs1_> dlongley: First thing I want to talk about is relationship RDF and VCWG.
18:11:12 <phila> s/slids/slides/
18:11:57 <kdeangs1_> ... What is an RDF dataset? It's a way to model graphs of information.
18:12:22 <kdeangs1_> ... VC data model aligns with RDF.
18:13:09 <kdeangs1_> ... "Verify" means that we're verifying that the information hasn't changed and that the issuer is indeed the one who created it.
18:13:37 <kdeangs1_> ... Anonymity is preserved if we don't need the verifiers to call home.
18:14:01 <kdeangs1_> ... Cryptographic primitive called a digital signature provides this.
18:14:21 <kdeangs1_> ... Different implementations might produce different bytes for signing for the same VC.
18:14:42 <kdeangs1_> ... Why not just have the issuer define the sequence of bytles?
18:14:58 <kdeangs1_> ... This makes it harder on application developers.
18:15:28 <kdeangs1_> ... Not a problem on simple use cases, but more complex use cases cause problems.
18:16:05 <kdeangs1_> ... C14n ensures that the same set of data produces the same signature.
18:16:26 <kdeangs1_> ... Bytes that are protected are the output of the hash algorithm.
18:16:52 <kdeangs1_> ... Once we produce and sign the hash, we can discard the hash.
18:17:21 <kdeangs1_> ... Whenever we see the same data, we should get the same signature.
18:18:03 <kdeangs1_> ... Trade offs favour c14n.
18:18:42 <kdeangs1_> ... You can transform a VC into another format (e.g., CBOR-LD) and get the same results.
18:20:02 <kdeangs1_> ... URDNA2015 is a c14n algorithm that is input into the RCHWG.
18:20:14 <TallTed> what about canonization vs canonicalization?
18:20:17 <ivan> ivan has joined #vcwg
18:20:32 <kdeangs1_> ... Based on 2012 algorithm, upgraded to handle multiple graphs instead of a single graph.
18:20:36 <TallTed> and canonize vs canonicalize?
18:20:55 <kdeangs1_> ... Fit-for-purpose for RDF.
18:21:40 <kdeangs1_> ... Combines every RDF element, reuses existing primitives, and hashes with SHA-256.
18:21:43 <Orie> One of the biggest deployments of it I am aware of is related to Activity Pub / Mastodon ... https://github.com/tootsuite/mastodon/blob/cabdbb7f9c1df8007749d07a2e186bb3ad35f62b/app/lib/activitypub/linked_data_signature.rb#L30
18:21:57 <gkellogg> q+ to note that N-Quads doesn't have a specified C14N form, although it can be derived from that of N-Triples.
18:22:05 <kristina> the Mirabolic consulting paper on URDNA2015: https://lists.w3.org/Archives/Public/public-credentials/2021Apr/att-0032/Mirabolic_Graph_Iso_Report_2020_10_19.pdf
18:22:13 <kristina> because I was looking at it..
18:22:27 <phila> q?
18:22:32 <kdeangs1_> ... With RDF*, same upgrade process as from 2012-2015 should be followed.
18:22:36 <phila> ack next
18:22:38 <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.
18:23:01 <markus_sabadello> q+
18:23:08 <kdeangs1_> 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.
18:23:10 <manu> q+ to speak to CCG steps
18:23:22 <wayne> wayne has joined #vcwg
18:23:27 <kdeangs1_> phila: Do you have an idea of timing?
18:23:39 <kdeangs1_> gkellogg: Pull request is ready, it has one approval.
18:23:53 <kdeangs1_> ... Chairs need to publish.
18:24:03 <kdeangs1_> ... Something that can be done in a day.
18:24:28 <kdeangs1_> ... Another thing that occurred to me, N-Quads doesn't have a canonical form but triples do.
18:24:54 <Orie> +1 gkellogg
18:24:54 <kdeangs1_> ... No normalized form in N-Quad spec.
18:24:58 <phila> ack manu
18:24:58 <Zakim> manu, you wanted to speak to CCG steps
18:24:58 <pchampin> https://www.w3.org/TR/n-triples/#canonical-ntriples
18:25:17 <pchampin> confirm that the N-quads spec does not have a similar section
18:25:18 <kdeangs1_> manu: CCG will take more than a day. Need to convene group and get them to approve.
18:25:22 <phila> ack markus_sabadello
18:25:28 <kdeangs1_> ... Will push that along.
18:25:32 <dlongley> TallTed: canonize/canonicalization are synonyms
18:25:45 <dlongley> (all the various forms of those words)
18:26:16 <pchampin> dlongley you mean c14n = c10n ? :-P
18:26:21 <dlongley> heh :)
18:26:29 <kdeangs1_> markus_sabadello: It's on the agenda for CCG next week. From a process perspective we need to motion this to recognize it.
18:26:40 <kdeangs1_> ... What is the output? A serialized stream?
18:27:17 <markus_sabadello> q+
18:27:18 <kdeangs1_> dlongley: Output is abstract data model with labels applied to get sorted N-Quads.
18:27:40 <dlongley> "blank node labels" aren't really "abstract"
18:27:53 <dlongley> a detail for the RCH WG to figure out how to describe appropriately.
18:27:54 <kdeangs1_> markus_sabadello: Output of algorithm is not a serialized N-Quad stream but rather an abstract data model.
18:28:10 <phila> q?
18:28:12 <kdeangs1_> ... Which can then be used to create a serialized form.
18:28:15 <dlongley> +1 to being precise
18:28:16 <phila> q- markus_sabadello
18:28:20 <pchampin> yes, bnode labels are not part of the abstract syntax of RDF, so this "abstract canonicalized dataset" is somewhat hypbrid
18:28:37 <gkellogg> s/hyprid/hybrid/
18:29:03 <phila> -> https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1553dcd7b23_239_0 Aidan's slides
18:29:16 <kdeangs1_> aidan: Blank nodes are common in real-world data.
18:29:31 <kdeangs1_> ... Things would be easier if blank nodes didn't exist.
18:30:29 <kdeangs1_> ... Creates relationships that are more difficult to determine if they're isomorphic.
18:31:20 <kdeangs1_> ... Drawing a different way makes it difficult to determine isomorphism.
18:31:28 <Orie> These slides are amazing.
18:31:36 <kdeangs1_> ... GI complete means graph isomorphic complete.
18:32:15 <Orie> Skolemise is also used in the Termwise work, mentioned previously.
18:32:43 <Orie> For those who want to learn more about the word: https://en.wikipedia.org/wiki/Skolem_normal_form
18:33:10 <mccown> mccown has joined #vcwg
18:33:21 <kdeangs1_> ... Canonical labelling makes it faster to detect duplicate documents.
18:35:47 <dezell> dezell has joined #vcwg
18:35:53 <dezell> present+
18:36:09 <kdeangs1_> ... Naive canonicalization will solve most problems.
18:36:16 <kdeangs1_> .. What happens with more complex graphs?
18:37:31 <Orie> I cannot communicate how much I love this presentation.
18:37:50 <decentralgabe> make a graph to demonstrate your love
18:38:05 <kristina> without blank nodes
18:39:40 <pchampin> Orie +1
18:42:57 <phila> q?
18:48:18 <kdeangs1_> ... (see presentation for answer)
18:48:20 <wayne> wayne has joined #vcwg
18:48:37 <gkellogg> q+ to ask about thoughts on extending to RDF-star.
18:49:08 <Orie> No Agda, TLA+ proof? : ) ... That there is a coq proof is pretty awesome.
18:49:59 <pchampin> q+ to ask if a test-suite is available
18:50:38 <dlongley> that was an excellent presentation!
18:50:48 <decentralgabe> +1
18:50:55 <phila> ack gkellogg
18:50:55 <Zakim> gkellogg, you wanted to ask about thoughts on extending to RDF-star.
18:50:55 <markus_sabadello> q+
18:51:26 <kdeangs1_> gkellogg: Do your insights on ease of extending extend to RDF*?
18:51:36 <kdeangs1_> aidan: Yes, don't see any difficulty.
18:51:42 <gkellogg> s/RDF*/RDF-star/
18:51:50 <kdeangs1_> ... Add some bytes to indicate that it originated as RDF-star.
18:52:06 <kdeangs1_> ... Also use this to canonicalize SPARQL.
18:52:12 <Orie> Cannonized sparql could reduce compute times I imagine.
18:52:14 <phila> ack next
18:52:15 <Zakim> pchampin, you wanted to ask if a test-suite is available
18:52:37 <phila> q+
18:52:38 <kdeangs1_> pchampin: Do you have some reference data that can be used?
18:52:46 <kdeangs1_> aidan: Yes, they're all public datasets.
18:52:58 <phila> ack next
18:53:01 <kdeangs1_> ... Some datasets are used to prove correctness.
18:53:11 <rgrant> rgrant has joined #vcwg
18:53:40 <kdeangs1_> markus_sabadello: Conceptually, the two pieces of work appear aligned. Want to get some understanding of overlaps and similarities.
18:54:14 <phila> zakim, please close the queue
18:54:14 <Zakim> ok, phila, the speaker queue is closed
18:54:25 <phila> q=
18:54:38 <dlongley> they are *very very* similar ... but not the same, unfortunately.
18:54:40 <kdeangs1_> aidan: Certain elements are aligned. There are technical differences that may affect performance and ease of implementation.
18:54:49 <phila> ack me
18:54:53 <kdeangs1_> ... There will have to be a comparison.
18:55:28 <kdeangs1_> phila: The process of cleaning, which tries to get rid of duplicates, have you considered using a SHACL shape to get rid of what you don't want?
18:55:41 <phila> s/cleaning/leaning/
18:56:10 <dlongley> i'd recommend not taking on the extra work :)
18:56:17 <kdeangs1_> aidan: One example uses SPARQL to lean graph. Can use SHACL as well.
18:56:54 <phila> https://github.com/w3c/rch-rdc
18:56:59 <phila> https://github.com/w3c/rch-rdh
18:57:00 <pchampin> RCH WG homepage: https://www.w3.org/groups/wg/rch
18:57:02 <ivan> rrsagent, draft minutes
18:57:02 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-vcwg-minutes.html ivan
18:57:03 <kdeangs1_> markus_sabadello: We have our mailing list. Encourage group to subscribe.
18:57:47 <ivan> rrsagent, draft minutes
18:57:47 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-vcwg-minutes.html ivan
18:57:56 <kdeangs1_> 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.
18:58:36 <ivan> rrsagent, draft minutes
18:58:36 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-vcwg-minutes.html ivan
18:59:05 <Orie> Thank you!
19:11:28 <gkellogg> gkellogg has joined #vcwg
19:17:22 <ivan> ivan has joined #vcwg
19:20:35 <rgrant> rgrant has joined #vcwg
19:30:26 <gkellogg> gkellogg has joined #vcwg
19:47:17 <sebastianelfors> sebastianelfors has joined #vcwg
19:52:23 <ivan> ivan has joined #vcwg
19:54:42 <gkellogg> gkellogg has joined #vcwg
19:55:47 <gkellogg> gkellogg has joined #vcwg
19:58:28 <phila> phila has joined #vcwg
19:59:21 <takuya> takuya has joined #vcwg
20:01:20 <decentralgabe> decentralgabe has joined #vcwg
20:01:23 <decentralgabe> present+
20:02:23 <Orie> present+
20:02:29 <shawnb> qwert
20:02:36 <pchampin> pchampin has joined #vcwg
20:02:38 <rgrant_> rgrant_ has joined #vcwg
20:03:19 <ivan> present+ shawnb
20:03:46 <justin_r> no, sorry -- under a deadline
20:04:26 <gkellogg> present+
20:04:27 <shigeya> present+
20:04:28 <brent> brent has joined #vcwg
20:04:30 <mary> mary has joined #vcwg
20:04:31 <rgrant_> present+
20:04:34 <justin_r> present+
20:04:36 <kristina> kristina has joined #vcwg
20:04:41 <kristina> present+
20:05:40 <dlongley> scribe+
20:05:53 <kdeangs1> kdeangs1 has joined #vcwg
20:06:01 <dlongley> brent: Our first presentation is from Gabe.
20:06:07 <YanZhang> YanZhang has joined #vcwg
20:06:09 <decentralgabe> & Orie
20:06:30 <dlongley> brent: Gabe and Orie.
20:07:27 <dlongley> decentralgabe: We're talking about multiparty and delegated credentials today. There are 3 formations and only one has been covered in the spec.
20:07:44 <wonsuk> wonsuk has joined #vcwg
20:07:46 <dlongley> decentralgabe: Will be discussing these and what should be included.
20:07:56 <hsano> hsano has joined #vcwg
20:08:05 <hsano> present+ Hiroyuki_Sano
20:08:08 <dlongley> 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.
20:08:46 <SamSmith> SamSmith has joined #vcwg
20:09:00 <dlongley> 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.
20:09:06 <dlongley> decentralgabe: Where the child is the primary subject.
20:09:42 <dlongley> 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.
20:10:13 <dlongley> 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.
20:10:25 <dlongley> Orie: The prompt here is "A 3d rendering of a confused deputy".
20:10:27 <kristina> btw there is a multi-subject JWT individual draft in IETF OAuth WG: https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
20:10:47 <dlongley> 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.
20:10:54 <brent> q?
20:11:08 <dezell> dezell has joined #vcwg
20:11:15 <dezell> present+
20:11:27 <dlongley> 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.
20:11:47 <dlongley> 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.
20:11:50 <kristina> present?
20:12:06 <dlongley> 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.
20:13:09 <dlongley> 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.
20:13:25 <dlongley> decentralgabe: I don't mean to mean these examples as a proposal, just showing one way to express things.
20:13:43 <dlongley> 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.
20:14:16 <dlongley> 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.
20:14:51 <dlongley> 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.
20:15:15 <dlongley> 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.
20:15:38 <dlongley> 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.
20:15:59 <cabernet> cabernet has joined #vcwg
20:16:03 <cabernet> present+
20:16:04 <dlongley> 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.
20:16:15 <kristina> q?
20:16:37 <dlongley> 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.
20:16:47 <dlongley> Orie: We've seen examples of each of them. The spec text around them isn't helping enough.
20:17:11 <dlongley> 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.
20:17:43 <dlongley> 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.
20:17:43 <aidhog> aidhog has joined #vcwg
20:18:08 <dlongley> 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.
20:18:49 <dlongley> 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.
20:18:55 <mkhraisha> mkhraisha has joined #vcwg
20:19:07 <dlongley> decentralgabe: I'd like to see this move past an informative example and get to strong implementation suggestions and there may be multiple interpretations.
20:19:11 <Jay> Jay has joined #vcwg
20:19:24 <kdeangs1> q?
20:19:26 <dlongley> Orie: Multiple issuers. Manu mentioned concerns about this use case -- I'd love for him to queue.
20:19:31 <kdeangs1> q+
20:19:44 <kristina> zakim, please open the queue
20:19:44 <Zakim> ok, kristina, the speaker queue is open
20:19:53 <kristina> q+ kdeangs1
20:20:19 <dlongley> 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).
20:20:41 <dlongley> 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.
20:21:15 <dlongley> 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.
20:21:42 <dlongley> 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?
20:22:27 <dlongley> 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.
20:22:36 <dlongley> Orie: Should credentials with multiple issuers even be allowed?
20:22:50 <brent> ack kdeangs1
20:22:50 <SamSmith> q+
20:23:12 <dlongley> 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.
20:23:30 <dlongley> 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.
20:23:45 <dlongley> kdeangs1: Power of attorney isn't such a case. That's a statement of my authority over another granted by them or a judge.
20:23:58 <kristina> how are multi signature use-cases being dealt right now?
20:24:05 <dlongley> 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.
20:24:17 <kristina> several iss claims?
20:24:29 <dlongley> 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.
20:24:41 <brent> ack SamSmith
20:24:43 <ivan> q+
20:24:43 <ivan> q
20:24:43 <ivan> q?
20:24:44 <dlongley> kdeangs1: I can think of a lot of examples for multiple issuers, I have some difficulty thinking of examples of multiple subjects.
20:25:29 <dlongley> 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.
20:25:46 <Orie> +1 sam, I think merging identifiers into a multi party systems is an excellent way to get rid of the "multiple issuers" case.
20:26:06 <dlongley> 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.
20:26:13 <dlongley> SamSmith: There are multiple controllers for one issuer identifier.
20:26:48 <dlongley> 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.
20:27:15 <dlongley> 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.
20:27:35 <wayne> wayne has joined #vcwg
20:27:50 <dlongley> 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.
20:27:50 <brent> ack ivan
20:28:07 <JoeAndrieu> JoeAndrieu has joined #vcwg
20:28:37 <dlongley> 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.
20:28:50 <manu> q+
20:29:07 <brent> ack manu
20:29:07 <dlongley> kristina: We have 2 minutes left, so the topic is multisubject credentials and based on the morning conversations, Manu and Joe may have opinions.
20:29:31 <dlongley> 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.
20:29:45 <dlongley> manu: I've seen that happen over the years, different definitions resulting in people talking past each other for a long period of itme.
20:29:52 <Orie> Here is a link to an issue that is related: https://github.com/w3c/vc-data-model/issues/762#issuecomment-1218428660
20:30:06 <JoeAndrieu> q+ to talk about delegating statements, verses statements that delegate
20:30:20 <dlongley> 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.
20:30:28 <kristina> the chairs agreed to spend 10 more minutes on this topic
20:30:33 <Orie> +1 to we need to cleanly separate these topics... but they are merged in the minds of many folks.
20:30:46 <brent> ack JoeAndrieu
20:30:47 <Zakim> JoeAndrieu, you wanted to talk about delegating statements, verses statements that delegate
20:30:48 <dlongley> 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.
20:30:53 <decentralgabe> q+
20:31:10 <dlongley> 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.
20:31:30 <YanZhang> +1
20:31:32 <dlongley> 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.
20:31:36 <yi> yi has joined #vcwg
20:32:05 <dlongley> 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.
20:32:28 <kristina> there seems to be 2 more slides?
20:32:31 <decentralgabe> next one please
20:32:34 <Orie> +1 protocols for building authorization on VCs seems out of scope.
20:32:42 <decentralgabe> sorry, one after this
20:32:42 <manu> q+ to note questions confuse the use cases.
20:32:45 <dlongley> 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.
20:32:45 <brent> ack decentralgabe
20:32:45 <rgrant_> +1 to stopping at the envelope
20:33:02 <Orie> but I am not sure we are "forbidding " those use cases or "allowing them" based on the spec today.
20:33:09 <dlongley> 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.
20:33:26 <dlongley> 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.
20:33:28 <manu> q+ to note issues.
20:33:34 <brent> ack manu
20:33:34 <Zakim> manu, you wanted to note questions confuse the use cases. and to note issues.
20:33:38 <JoeAndrieu> q+ to ask about use cases
20:33:58 <dezell> dezell has joined #vcwg
20:34:06 <dezell> present+
20:34:18 <dlongley> 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?
20:34:25 <Orie> Should the data model now support multiple subject credentials? even thought we can't test them concretely in VC-JWT?
20:34:51 <dlongley> 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.
20:34:52 <Orie> I will note that this leads to a "My security format is better because X..." which I am frustrated by.
20:35:08 <kristina> manu: so when you do multisig, you include only one issuer and/or subject?
20:35:13 <brent> ack JoeAndrieu
20:35:13 <Zakim> JoeAndrieu, you wanted to ask about use cases
20:35:17 <dlongley> 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.
20:35:36 <manu> Orie, it leads to a: You can do X with Y technology but not Z technology -- it's just a factual statement.
20:35:44 <dlongley> 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.
20:35:55 <Orie> manu: thats the same thing I am saying, in different words.
20:35:59 <dlongley> 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.
20:36:09 <manu> s/manu: thats/manu, thats/
20:36:18 <brent> q?
20:36:25 <dlongley> 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.
20:36:40 <dlongley> JoeAndrieu: Did you add those use cases to the core spec or use cases?
20:36:47 <dlongley> decentralgabe: Neither they are in issues in the core spec repo.
20:36:50 <Orie> -1 to moving those issues to use cases.
20:36:55 <dlongley> JoeAndrieu: Ok, let's try to get those moved over to the use cases doc.
20:37:30 <selfissued> selfissued has joined #vcwg
20:37:34 <selfissued> present+
20:37:36 <decentralgabe> issues: https://github.com/w3c/vc-data-model/issues/930, https://github.com/w3c/vc-data-model/issues/931, https://github.com/w3c/vc-data-model/issues/932
20:37:45 <dlongley> 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.
20:37:51 <dlongley> Orie: Each of those systems will have their own constraints.
20:38:17 <dlongley> 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.
20:38:41 <decentralgabe> @JoeAndrieu - use cases to prove out the need for a change to the data model
20:38:41 <dlongley> 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.
20:38:56 <dlongley> Orie: That seems unlikely that it would pan out but you could perhaps do things like that with Data Integrity.
20:39:22 <dlongley> 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.
20:39:28 <Karen> Karen has joined #vcwg
20:39:36 <dlongley> brent: Next topic is SD-JWT.
20:39:48 <dlongley> kristina: Chair hat off for the full 40 minutes from me.
20:39:48 <brent> Topic: Intro to SD-JWT
20:40:14 <dlongley> kristina: The purpose of the presentation is to introduce the concept. There are several questions / cry for help in defining certain aspects.
20:40:25 <dlongley> kristina: This is a draft adopted in the IETF and the work is happening at IETF.
20:40:38 <dlongley> kristina: The problem in the VC space is that the VC-JWTs are not selectively disclosable.
20:40:53 <dlongley> kristina: You get one signature and you can't take out one of the claims without breaking it.
20:41:01 <dlongley> kristina: So the main problem was finding a way to do selective disclosure.
20:41:16 <dlongley> sebastianelfors: As I mentioned earlier, I am part of the UDI wallet group.
20:41:26 <brent> s/UDI/EUDI/
20:41:48 <dlongley> 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.
20:41:56 <dlongley> sebastianelfors: Another problem is with BBS which is new crypto.
20:42:15 <dlongley> sebastianelfors: So we're really interested in is SD-JWT for personal identification data for the EUDI wallet.
20:42:48 <mccown> mccown has joined #vcwg
20:42:49 <dlongley> 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.
20:43:01 <dlongley> kristina: The concept is not new, it's just never been documented as a standard.
20:43:17 <dlongley> kristina: The idea is that the issuer hashes each claim, only digests are included, no claim values.
20:43:40 <dlongley> kristina: So a mapping is sent with actual claim mappings and salts and key-value pairs.
20:44:02 <dlongley> kristina: In presenting -- the whole digests are sent and only the salt and mappings/key-value pairs that the holder agrees to release.
20:44:08 <dlongley> kristina: There's an illustration for this in the slide.
20:44:30 <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
20:44:42 <dlongley> 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.
20:44:49 <dlongley> kristina: Including the information for all the digests.
20:45:16 <sebastianelfors> One more question to be discussed: Should the proposed "sd_digests" VC claim be registered as a top claim by IANA?
20:45:17 <dlongley> kristina: In selective disclosure happens with the mapping -- the holder only sends the salt and claims values for those claims that are being released.
20:45:32 <dlongley> 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.
20:45:42 <dlongley> kristina: So some examples. These examples are from the SD-JWT doc.
20:45:44 <SamSmith> The unique feature of ACDCs is a graduated disclosure mechanism using composed schema that supports contractually protected selective disclosure
20:45:55 <dlongley> kristina: The question is -- how can these concepts in the SD-JWT document be mapped to the VC model.
20:46:06 <dlongley> kristina: SD-JWT defines `sd-digests` as a top-level JWT claim.
20:46:25 <dlongley> kristina: It contains mappings and arrays with salts and values, it's opinionated but it's a draft and we expect discussion.
20:46:36 <dlongley> kristina: During presentation is the `SD-JWT-Release` container.
20:47:07 <DavidC> DavidC has joined #vcwg
20:47:07 <dlongley> 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.
20:47:12 <DavidC> present+
20:47:19 <cel> regrets+
20:47:28 <dlongley> 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.
20:47:42 <manu> q+ to ask if objects are supported, or just flat arrays of claims?
20:47:55 <dlongley> kristina: There was a long discussion around that -- so far sending the plain text without encryption ... missed ... the verifier needs to do the computation.
20:48:05 <dezell> dezell has joined #vcwg
20:48:06 <manu> q-
20:48:14 <dezell> present+
20:48:21 <dlongley> 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.
20:48:37 <dlongley> kristina: We have implementations, one in python, kotlin, rust.
20:48:39 <decentralgabe> q+
20:48:55 <dlongley> kristina: I want to bring this up with the VCWG, there's discussion in an issue between mostly me and sebastianelfors.
20:49:21 <dlongley> 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].
20:49:33 <sebastianelfors> Here's the issue on SD-JWT-VC: https://github.com/w3c/vc-data-model/issues/908
20:49:45 <dlongley> kristina: Conceptually, the claims included in the credential subject and non-SD claims.
20:50:05 <dlongley> kristina: Because there is a whole signature on the whole JWT -- the first name / last name, you won't be able to do SD.
20:50:20 <dlongley> kristina: The digest of the claims ... and claims included by value in the credential subject.
20:50:43 <dlongley> 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.
20:50:45 <SamSmith> q+
20:50:49 <dlongley> kristina: In the VP the object would be included.
20:51:18 <dlongley> 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.
20:51:32 <dlongley> kristina: Nesting / processing is not straightforward in some options.
20:51:49 <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.
20:51:57 <dlongley> kristina: Can credential subject be empty? Where do we describe SD-JWT?
20:51:58 <brent> would it work to map credentialSubject and sd_digests so they are equivalent?
20:52:02 <brent> ack decentralgabe
20:52:34 <decentralgabe> ref: https://github.com/workdaycredentials/specifications/blob/master/specifications/claim-proof.md
20:52:36 <sebastianelfors> q+
20:52:37 <dlongley> 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.
20:52:40 <brent> ack SamSmith
20:52:41 <shawnb> +1, I like what you're attempting to accomplish
20:52:43 <wayne> q+
20:52:46 <Orie> I also like the idea of it, just not the serialization backflips needed :)
20:53:40 <dlongley> 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.
20:53:49 <brent> ack sebastianelfors
20:53:50 <dlongley> SamSmith: You can generate on the fly credentials that are unlinkable as well.
20:53:59 <manu> q+ 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?
20:54:15 <dlongley> 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.
20:54:26 <dlongley> sebastianelfors: We have atomic VCs, SD-JWT and other options to add there.
20:54:29 <brent> ack wayne
20:54:33 <Jeremie> Jeremie has joined #vcwg
20:54:46 <Jeremie> +present
20:54:49 <kristina> q+
20:54:54 <dlongley> 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.
20:54:55 <kristina> q+ to respond to wayne
20:55:12 <dlongley> 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.
20:55:36 <dlongley> 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.
20:55:55 <dlongley> 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...
20:56:06 <dlongley> wayne: The term pepper might be better than salt because it's meant to be kept secret.
20:56:06 <brent> ack manu
20:56:06 <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?
20:56:07 <Orie> I'll take string encoded json over base64url encoded JSON : )
20:56:24 <dlongley> manu: I'm concerned with the complexity that we're adding here. It sounds like ...
20:56:49 <dlongley> manu: It sounds like several different securing schemes.
20:57:27 <dlongley> 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.
20:57:27 <Orie> Agree, sd-jwt feels like a stop gap, aimed at tackling ISO / mDL use cases... meaning it might be a useful stop gap.
20:57:37 <kristina> clime blinding is definitely the topic, wayne. and there is high potential it will be mandated
20:57:39 <dlongley> manu: It feels like a narrow solution -- and it's useful, but it's a lot of complexity.
20:57:46 <kristina> s/clime/claim
20:58:08 <dlongley> 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.
20:58:48 <brent> q
20:58:53 <dlongley> manu: The concern here is that we're adding a lot of complexity for a narrow use case and it will confuse people.
20:58:58 <brent> ack kristina
20:58:58 <Zakim> kristina, you wanted to respond to wayne
20:59:12 <ivan> present+ wayne
20:59:30 <dlongley> 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.
20:59:30 <phila> q+ to talk about the tyranny of choice
20:59:46 <Orie> is that horse trade on the table!?!?! thats exciting.
20:59:53 <dlongley> kristina: Those don't have the features we want -- I would argue SD is a requirement.
21:00:02 <dlongley> kristina: I would want to avoid VC-JWT because SD-JWT does SD.
21:00:22 <dlongley> kristina: The concern about keeping both is complexity and having more complexity ... and that we want the tech to be more mature.
21:00:30 <dlongley> kristina: Having SD-JWT instead of VC-JWT might be an option.
21:00:34 <brent> ack phila
21:00:34 <Zakim> phila, you wanted to talk about the tyranny of choice
21:00:37 <Orie> I think an objective is to minimize the number of "alternative" but "nearly equivalent" security formats.
21:01:01 <dlongley> 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.
21:01:01 <kristina> q+
21:01:23 <brent> ack kristina
21:01:27 <manu> q+
21:01:28 <dlongley> 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.
21:01:46 <sebastianelfors> q+
21:01:47 <nadalin> nadalin has joined #vcwg
21:01:47 <dlongley> kristina: If the explanation was not clear enough -- this is not a reinvention of VC-JWTs, we're adding a feature.
21:02:01 <brent> ack manu
21:02:02 <nadalin> present+
21:02:11 <osamu> osamu has joined #vcwg
21:02:17 <dlongley> 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.
21:02:36 <kristina> q+
21:02:53 <dlongley> 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.
21:03:38 <brent> ack sebastianelfors
21:03:41 <dlongley> 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.
21:04:06 <brent> q+ to respond to sebastianelfors
21:04:08 <manu> q+ to ask about "Must disclose" DSs, talk about "complexity" in crypto.
21:04:08 <dlongley> sebastianelfors: I wanted to clarify SD-JWT, it reduces complexity because BBS and anoncreds are extremely complex because they haven't been analyzed properly.
21:04:11 <Orie> I would offer that if v2 includes `@vocab` no changes necessary and context will work fine using the v2 version : )
21:04:15 <dlongley> sebastianelfors: I think this approach reduces complexity than anything else.
21:04:16 <brent> ack kristina
21:04:37 <dlongley> kristina: If JWP proceeds faster than SD-JWT, I would be happy to just have it.
21:04:49 <Orie> I would love for JWP to move faster... add your voice to the IETF list on the subject.
21:04:54 <dlongley> kristina: JWP started a year and a half before before SD-JWT but SD-JWT is moving faster it seems.
21:05:09 <dlongley> kristina: There are multiple implementations that are moving SD-JWT and no JWP ones.
21:05:26 <selfissued> q+
21:05:31 <dlongley> 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.
21:05:45 <Jeremie> the JWP BoF is getting scheduled, ideally in the next few weeks
21:05:47 <brent> ack brent
21:05:47 <Zakim> brent, you wanted to respond to sebastianelfors
21:05:48 <dlongley> kristina: I understand all the comments raised ... I raised this now to get stable examples, etc.
21:06:24 <dlongley> 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.
21:06:25 <brent> ack manu
21:06:25 <Zakim> manu, you wanted to ask about "Must disclose" DSs, talk about "complexity" in crypto.
21:06:51 <sebastianelfors> q+
21:06:52 <mccown> mccown has joined #vcwg
21:07:07 <dlongley> 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.
21:07:16 <dlongley> manu: It has been analyzed by different cryptographers.
21:07:36 <dlongley> 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.
21:08:11 <dlongley> 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.
21:08:37 <dlongley> 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.
21:09:03 <dlongley> manu: So, when you SD something, you really have to disclose "these three fields". I know the BBS work has this feature.
21:09:15 <Orie> agree, that it would, but disagree that it would have a material impact for sd-jwt.
21:09:22 <dlongley> manu: There may be times to selective disclose `@context` ... maybe you need to always do that so the type of context is understood.
21:09:26 <dlongley> manu: Things there to look into.
21:09:37 <brent> ack selfissued
21:09:56 <dlongley> 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.
21:10:08 <dlongley> kristina: So what happens when you apply to the VC data model and so on -- that's all in scope for the VCWG.
21:10:22 <manu> I don't think it would have a material impact, Orie, just important to consider.
21:10:26 <dlongley> selfissued: I wanted to reinforced a point from my own experience that Kristina briefly made about stability in spec development.
21:10:48 <dlongley> 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.
21:11:11 <dlongley> 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.
21:11:30 <dlongley> 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.
21:11:49 <dlongley> selfissued: Yeah, there's still some decisions to be made, but we're very close to having a core the WG could agree to.
21:11:56 <kristina> q?
21:11:58 <dlongley> selfissued: It took a while after that but mostly for JWS, JWE.
21:12:16 <dlongley> 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.
21:12:27 <dlongley> selfissued: Not everything is the same, but I do have confidence we can keep things stable through the IETF process.
21:12:30 <brent> ack sebastianelfors
21:12:52 <kristina> q+ to add color on mDL and potentially next steps
21:13:06 <dlongley> 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.
21:13:11 <brent> ack kristina
21:13:11 <Zakim> kristina, you wanted to add color on mDL and potentially next steps
21:13:46 <dlongley> 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.
21:13:51 <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.
21:14:00 <dlongley> kristina: In mDL world, SD is an absolute requirement, JWTs obviously do not do SD without SD-JWT.
21:14:10 <dlongley> kristina: Doing JSON-LD and BBS ... BBS did not exist.
21:14:30 <dlongley> kristina: There was no JSON option ... so the SD-JWT work was forced to be accelerated.
21:15:09 <dlongley> kristina: SD-JWT seems like the best bet in the middle term.
21:15:49 <dlongley> 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.
21:16:02 <brent> q?
21:16:03 <dlongley> kristina: I feel, honestly, a bit insecure in doing the definitions here and I would like the experts from this group to chime in.
21:16:11 <kristina> q?
21:16:11 <dlongley> kristina: I'd like to see if there's at least some value in doing this.
21:16:33 <brent> Topic: VC Test Suites
21:16:52 <dlongley> manu: I found this hideous slide deck, so I really wanted to use it.
21:17:05 <wayne> scribe+
21:17:23 <wayne> 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.
21:17:32 <JoeAndrieu> JoeAndrieu has joined #vcwg
21:17:58 <wayne> 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.
21:18:54 <wayne> 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.
21:19:13 <wayne> manu: no one knew how to maintain the test suite because it was in lisp. this is an example of the test.
21:19:54 <wayne> 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.
21:20:23 <wayne> 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.
21:20:24 <brent> q?
21:20:47 <wayne> ivan: when you say the driver tells the issuer to issue, then driver tells verifier to verify, does this mean one impl?
21:21:11 <wayne> 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
21:21:23 <wayne> ivan: could two implementations interop their verifiable credentials?
21:21:25 <wayne> manu: yes
21:22:09 <Orie> I'm a big fan of "docker + cli" setups.
21:22:23 <wayne> 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.
21:22:25 <gkellogg> q+
21:22:32 <wayne> manu: therefore we used a command line approach.
21:23:06 <brent> ack gkellogg
21:23:06 <wayne> 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.
21:23:09 <Orie> +1 to continuous nightly test reports!
21:23:50 <wayne> 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
21:23:55 <wayne> manu: great point, agreed
21:24:01 <Orie> +1 to gkellogg
21:24:04 <brent> +1
21:24:11 <wayne> manu: what happened in 1.1?
21:24:15 <wayne> topic: 1.1
21:24:43 <wayne> 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.
21:24:44 <wayne> topic: 2.0
21:25:14 <wayne> manu: what are some requirements that we might want to apply here? test all the must normative statements in specs.
21:25:44 <Orie> +100 to this.
21:25:57 <wayne> 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.
21:27:02 <wayne> 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
21:27:13 <TallTed> q+
21:27:13 <phila> q+
21:27:40 <DavidC> q+
21:28:16 <wayne> 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.
21:28:18 <decentralgabe> q+
21:28:31 <brent> Link to W3C Process that describes the requirements for implementation experience: https://www.w3.org/2021/Process-20211102/#implementation-experience
21:28:45 <YanZhang> q+
21:28:48 <Orie> 2 options to consider, for the record, (docker + cli) : https://identity.foundation/JWS-Test-Suite/#implementations, (postman + http): https://w3c-ccg.github.io/traceability-interop/reports/interoperability/
21:28:48 <wayne> 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.
21:29:00 <wayne> manu: that sounds very useful
21:29:40 <pchampin> https://respec.org/docs/#data-tests
21:29:43 <brent> ack TallTed
21:29:45 <wayne> ivan: we realized this around a year ago, and we could use a tool where we could take the statements and link to tests
21:29:49 <wayne> manu: sounds very useful, thanks!
21:30:11 <kdeangs1> +1 to testing shoulds
21:30:19 <wayne> 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.
21:30:28 <selfissued> q+
21:30:44 <brent> ack phila
21:30:44 <wayne> 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.
21:31:25 <wayne> 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?
21:31:37 <Orie> +1 to daily / weekly / monthly recurring tests.
21:31:41 <ivan> -> An example for what respec can give you (from an EPUB WG document) https://w3c.github.io/epub-specs/epub33/rs/#sec-epub-rs-conf-foreign-res
21:31:43 <brent> q+ to talk about difference between what is required for Rec vs conformance testing
21:31:52 <mkhraisha> huge +1 to recurring scheduled tests
21:31:57 <wayne> manu: there is at least a subset of companies that want constant testing to show their customers.
21:31:58 <wayne> phila: thanks
21:32:03 <brent> ack DavidC
21:32:30 <wayne> 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?
21:32:43 <gkellogg> q+
21:33:13 <gkellogg> q+ to note that some specs add parameters to the manifest to group tests by type or attributes.
21:33:31 <wayne> 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
21:33:35 <wayne> DavidC: what about issuers
21:33:53 <brent> ack decentralgabe
21:33:54 <wayne> 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.
21:34:22 <gkellogg> q+ to note that some specs add parameters to the manifest to group tests by type or attributes. Also, to note GH Actions infrastructure
21:34:26 <wayne> 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.
21:34:27 <Orie> A nice way to remove the infra requirement is to use docker + cli, and not use http.
21:34:28 <brent> ack YanZhang
21:35:08 <wayne> 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.
21:35:10 <wayne> manu: interactions?
21:36:04 <wayne> YanZhang: so right now, with all the test suites, you're testing automatically. but is there any technical features to test for protocols?
21:36:10 <ivan> s/topic: 1.1/topic 1.1/
21:36:35 <wayne> 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.
21:36:38 <brent> ack selfissued
21:36:40 <ivan> s/topic: 2.0/topic 2.0/
21:37:14 <wayne> 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.
21:37:41 <wayne> selfissued: for example, in the JWT spec there were statements without the normative keyword terms, but they were required nonetheless.
21:37:49 <phila> q+ to respond to Mike
21:38:15 <wayne> 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.
21:38:40 <kristina> q
21:39:16 <wayne> 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.
21:39:37 <brent> ack brent
21:39:37 <Zakim> brent, you wanted to talk about difference between what is required for Rec vs conformance testing
21:39:42 <wayne> selfissued: when do you test SHOULDs? you often improve interoperability by testing SHOULDs. in normal implementations, you usually implement them anyway.
21:40:23 <kristina> +1 to brent we should differentiate the minimum from what is ideal
21:40:28 <Orie> +1
21:40:31 <wayne> 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.
21:40:51 <brent> ack gkellogg
21:40:51 <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
21:40:53 <wayne> brent: some of the questions that the director/AC is asking for is if we have shown independent interoperable impls.
21:40:55 <Zakim> ... group tests by type or attributes. Also, to note GH Actions infrastructure
21:41:21 <wayne> gkellogg: as an implementation technique, i've seen test suites add parameterization to the tests, so you can group tests by features to pass.
21:41:50 <Orie> +1 to github actions
21:42:08 <wayne> 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.
21:42:18 <brent> ack phila
21:42:18 <Zakim> phila, you wanted to respond to Mike
21:42:23 <shawnb> shawnb has joined #vcwg
21:43:08 <ivan> q+
21:43:15 <wayne> 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.
21:43:17 <wayne> q+
21:43:22 <kdeangs1> +1 to sharing the test suite
21:43:29 <gkellogg> q+ to discuss motability of test suite after REC
21:43:30 <wayne> phila: yes, it does fulfill, but there are more things to do too.
21:43:33 <brent> ack ivan
21:44:15 <wayne> 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.
21:44:23 <manu> scribe+
21:44:24 <brent> ack wayne
21:44:50 <brent> I think github actions would be great, so implementers can use it in CI/CD
21:44:51 <manu> 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.
21:44:54 <brent> ack gkellogg
21:44:54 <Zakim> gkellogg, you wanted to discuss motability of test suite after REC
21:45:10 <kristina> q?
21:45:47 <brent> s/motability/mutability/
21:45:49 <yi> yi has joined #vcwg
21:45:57 <wayne> 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.
21:46:17 <wayne> topic 2.0 options
21:46:22 <Orie> This slide covers a few of the links I shared earlier... each of these suites has pro's and con's.
21:46:30 <Orie> Great slide Manu.
21:46:33 <wayne> manu: we could keep test suites as-is, static and from command line.
21:47:03 <wayne> 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.
21:47:13 <wayne> manu: we could use some other interface
21:47:56 <wayne> manu: [showing screen for test suite] normative statements on left, tests on right. this is what we have today.
21:48:22 <wayne> 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.
21:48:40 <wayne> Orie: just a comment as an author. this covers both JsonWebSignature2020 and also VC-JWT because they both build on JOSE
21:49:22 <wayne> Orie: keep them separate test suites, even if they're on the same docker-based deployment
21:49:53 <wayne> 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.
21:49:57 <brent> q?
21:50:08 <javadch> javadch has joined #VCWG
21:50:16 <ivan> -> another example may be https://w3c.github.io/epub-tests/
21:50:34 <wayne> 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.
21:51:15 <wayne> Orie: that's right, it covers issuance of revocable + unrevocable credentials. e.g., if you issue things will the verifier accept it?
21:51:30 <wayne> Orie: folks may not want to stand up an HTTP server to demonstrate the full conformance to the data model.
21:52:19 <wayne> 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.
21:52:21 <Orie> Credit to Mesur and Mavennet (and Transmute) for the work on the Traceability Test Suite... it also runs nightly.
21:52:51 <wayne> 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.
21:52:55 <wayne> ivan: there's another example here
21:53:26 <wayne> 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.
21:54:04 <wayne> 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.
21:54:46 <wayne> 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.
21:55:01 <kristina> q?
21:55:08 <wayne> ivan: it's a little bit different because each test is different, and we'd need to configure this.
21:55:26 <wayne> 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.
21:55:40 <phila> -> https://gs1.github.io/GS1DL-resolver-testsuite/ An alternative approach to test suites, aimed at devs
22:00:42 <gkellogg> gkellogg has joined #vcwg
22:09:10 <SamSmith> q
22:13:11 <Orie> phila thanks for the link to the digital link test suite... I love how interactive it is.
22:15:48 <brent> Topic: Internationization
22:16:17 <phila> phila has joined #vcwg
22:16:23 <gkellogg> gkellogg has joined #vcwg
22:16:37 <gkellogg> present+
22:16:58 <ivan> Topic: Internationalization
22:17:13 <shigeya> present+
22:17:13 <mccown> mccown has joined #vcwg
22:17:21 <SamSmith> so is there not going to be a discussion about JSON Schema?
22:17:47 <krisstina> krisstina has joined #vcwg
22:17:59 <kristina> kristina has joined #vcwg
22:18:03 <kristina> present+
22:18:06 <kristina> scribe+
22:18:21 <kristina> scribe-
22:18:21 <Orie> scribe+
22:18:46 <ivan> scribe+ orie
22:18:49 <Orie> shigeya: lets talk about internationalization
22:19:14 <Orie> ... I want to talk about requirements, not so much how
22:19:41 <Orie> ... lets talk about language strings among other things
22:19:56 <Orie> ... there are credentials that need to work cross-boarder
22:20:19 <Orie> ... for example, foreign students attending universities
22:20:21 <brent> s/boarder/border/
22:20:34 <kristina> q?
22:20:51 <Orie> ... typically the certifcates differ regarding education depending on the country of origin
22:21:11 <wayne> wayne has joined #vcwg
22:21:29 <Orie> ... currently the japanese government is issuing 2 types of certificates related to vaccination, based on HL7FHIR
22:21:48 <Orie> ... HL7FHIR is multilingual
22:22:15 <Orie> ... some fields are translated, other are not, such as name.
22:23:06 <Orie> ... the japanese government handles name encoding is special fields related to the patient data
22:23:38 <Orie> ... the first example of the VCDM includes a multilingual example, but there is no explanation for how it is produced.
22:23:45 <Orie> ... we probably want to remove this example
22:24:10 <Orie> ... we need normative rules for handling multilingual strings
22:24:32 <JoeAndrieu> JoeAndrieu has joined #vcwg
22:24:37 <Orie> ... do we need to use a language tag? related to BCP47?
22:24:51 <kristina> ack ivan
22:25:15 <Orie> ivan: clarifying question, does this account also for left to right and right to left, but also vertical encoding?
22:25:29 <Orie> ... JSON-LD 1.1 has a directionality encoding that is problematic
22:25:50 <Orie> <inaudible>
22:26:20 <wonsuk> wonsuk has joined #vcwg
22:26:26 <kristina> ack gkellogg
22:26:44 <Orie> gregkellog: win 1.1 we added 2 mechanisms for encoding text direction not otherwise supported by RDF
22:27:10 <Orie> ... the one that is most favored in a name space with an encoding scheme, which includes the langauge identifer and the text direction...
22:27:17 <kristina> q?
22:27:43 <TallTed> s/win 1.1/in JSON-LD 1.1/
22:27:46 <Orie> ... 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.
22:28:18 <Orie> shigeya: in the japanese language, we can manage without the veritical direction, its handled by display programs
22:28:25 <Orie> ... not sure about other languages
22:29:06 <Orie> ... how do we handle the construct
22:29:38 <Orie> ... if we need to present 2 or 3 langauges, for readable text entries... this creates complex and difficult structures
22:29:58 <Orie> ... which might harm program readers ability to process... different to single language credentials
22:30:15 <Orie> ... program interpretation of data structures remains a challenge
22:30:26 <Orie> ... do we want to standardize such mappings?
22:30:52 <Orie> ... do we have a use case for, supporting a large number of languages?
22:31:03 <Orie> ... also translating property names would be useful.
22:31:14 <Orie> ... here are some examples of several constructs we could use
22:31:30 <Orie> ... left hand side is the current approach.
22:32:09 <Orie> ... 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
22:32:30 <kristina> q?
22:32:31 <Orie> ... We should use BCP47 for language tags
22:32:47 <Orie> ... key mappings depend on construct used
22:33:10 <Orie> ... maybe we should externalize things
22:33:44 <Orie> ... we can use exact string mappings to translate between languages, but we have to consider integrity issues
22:34:01 <Orie> ... this might be useful for handling text in each credential
22:34:07 <manu> q+
22:34:10 <Orie> ... we have talked about JSON-LD compatibility
22:34:23 <Orie> ... should we implement a JSON-LD langauge map?
22:34:25 <manu> q+ to note preference for external mappings, not using current mechanisms.
22:34:31 <dlongley> having a "multilingualDictionary" property in the VC that points to a minidictionary is interesting
22:34:59 <Orie> ... next steps, we need to consult internationalization experts
22:35:03 <hsano> q?
22:35:06 <decentra_> decentra_ has joined #vcwg
22:35:10 <brent> ack manu
22:35:10 <Zakim> manu, you wanted to note preference for external mappings, not using current mechanisms.
22:35:13 <shigeya> q?
22:35:13 <shigeya> ack manu
22:35:14 <Orie> ... and draft PRs to address the mapping and externalization considerations
22:35:19 <Orie> manu: great summary of the options
22:35:44 <Orie> ivan: slide 342 i don't think this is JSON-LD
22:36:03 <dlongley> yeah, the existing examples don't work well for "simple JSON" users
22:36:08 <Orie> manu: these are options available, but not sure this is being used in practice
22:36:10 <gkellogg> q+ to question manu's assertion that they're not working out.
22:36:18 <Orie> ... the externalization use case is the most compeling
22:36:35 <Orie> ... because thats how other solutions have worked, such as language mapping files in OS
22:36:42 <decentr__> decentr__ has joined #vcwg
22:36:42 <Orie> ... it aligns with developer use
22:36:51 <Orie> ... one file can be translated in parallel
22:37:10 <Orie> ... there are a lot of benfits for handling an external representation, is you can improve over time
22:37:29 <Orie> ... maybe we want to do hashlinks, but maybe we don't so we can improve internationalization
22:37:32 <kristina> q?
22:37:48 <Orie> ... at this point I am feeling pretty -1 on slide 42 and using the existing JSON-LD language features
22:38:04 <decentr__> s/42/342
22:38:05 <kristina> s/42/342
22:38:10 <Orie> ... the experts told us to use the language features, but they didn't comment on externalization
22:38:20 <mccown> +1 for externalization.
22:38:28 <Orie> ... +1 to adding a comment on externalization
22:38:55 <Orie> gkellog: in some communities language maps are working well, maybe they are not working well here.... I like external maps idea
22:39:09 <Jay> q+ to ask translation extension at FHIR
22:39:12 <Orie> ... I think there are a lot of benefits to externalization
22:39:17 <TallTed> q+
22:39:22 <kristina> ack gkellogg
22:39:22 <Zakim> gkellogg, you wanted to question manu's assertion that they're not working out.
22:39:24 <kristina> ack Jay
22:39:24 <Zakim> Jay, you wanted to ask translation extension at FHIR
22:39:44 <Orie> Jay: Is translation extension in HL7FHIR the same approach?
22:39:58 <Orie> manu: i don't know FHIR enough to know
22:40:07 <shigeya> q?
22:40:11 <kristina> ack TallTed
22:40:25 <phila> q+ to talk about getting FHIR expertise
22:40:26 <Orie> TallTed: I am concerned that externalizing it will limit its untility, and online offline acccess
22:40:39 <shigeya> q+
22:40:42 <Orie> ... I don't know that we have really even tried the existing mechanisms
22:40:46 <dlongley> presumably the dictionary could also be embedded
22:40:46 <kristina> ack phila
22:40:46 <Zakim> phila, you wanted to talk about getting FHIR expertise
22:40:55 <Orie> ... I don't think the deployment of VCs todate has tested this
22:41:00 <kristina> ack shigeya
22:41:03 <Orie> phila: there is an expert name <unknown>
22:41:10 <brent> External mechanisms make me mildly concerned about security risks.
22:41:24 <decentralgabe> decentralgabe has joined #vcwg
22:41:26 <dlongley> yup, may be harder to do selective disclosure as well
22:41:31 <phila> s/<unknown>/Eric Prud'hommeaux (ericP in W3C circles)/
22:41:38 <Orie> shigeya: I think its good to externalize but then embed, and we can handle remote access as a seperate issue
22:41:43 <kristina> q?
22:41:52 <Orie> q+
22:41:54 <brent> q+
22:42:08 <kristina> ack Orie
22:42:53 <manu> 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.
22:42:54 <phila> q+ talk about hashlinks for this
22:43:01 <phila> q+ to talk about hashlinks for this
22:43:59 <brent> from Jay: FHIR 5.0 traslation extension in https://build.fhir.org/languages.html
22:44:06 <kristina> ack brent
22:44:08 <manu> 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
22:44:09 <manu> giving it more effort in v2.0.
22:44:23 <Orie> brentz: unless we have a way to get the external thing, it changes the threat model
22:44:40 <kristina> q?
22:44:40 <Orie> ... if you start addressing the meanings / translations... thats a potential attack.
22:44:43 <TallTed> q+
22:44:51 <kristina> ack phila
22:44:51 <Zakim> phila, you wanted to talk about hashlinks for this
22:45:03 <kristina> ack TallTed
22:45:06 <Orie> phila: I agree with Brent, and Orie... but this will effect the threat model
22:45:25 <kristina> q?
22:45:31 <Orie> TallTed: the other thing about externalization is that they impact interfaces to the user as well, form elements, not form inputs
22:45:32 <gkellogg> gkellogg has joined #vcwg
22:45:49 <Orie> kristina: there seems to be a lot of support for this work
22:45:59 <Orie> ... we should create issues for this
22:46:11 <brent> Topic: JSON Schema and VC Data Model
22:46:13 <dlongley> the resulting language map could also include a reference back to the VC and be signed by the issuer
22:46:13 <Orie> kristina: last official topic for the agenda
22:46:34 <yi> yi has joined #vcwg
22:46:35 <selfissued> selfissued has joined #vcwg
22:46:43 <Orie> decentragabe: most people here are familar with JSON Schema
22:46:43 <selfissued> present+
22:46:57 <Orie> ... it supports field level validation, regexp, etc..
22:47:07 <Orie> ... it can help with credential field validation
22:47:19 <Orie> ... it can help with defining document types
22:47:34 <Orie> ... as a holder, I want confidence that my credential will be accepted
22:48:06 <Orie> ... 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
22:48:11 <dezell> dezell has joined #vcwg
22:48:19 <dezell> present+
22:48:19 <Orie> ... JSON schema can be cached
22:48:37 <Orie> ... in the spec today, the example mentioned JSONSchemaValidator2018
22:48:44 <Orie> ... which does not exist
22:49:02 <Orie> ... in 2019 at Workday, we built a draft at the CCG to address the credentialSchema property
22:49:09 <Orie> ... the draft defines metadata about the schema
22:49:30 <Orie> ... covering authors and versioning, relative URIs and DIDS
22:49:40 <Orie> ... there are a few companies that used it in a few languages
22:49:49 <ivan> q+
22:49:52 <Orie> ... since then its gained some adoption but there are issues
22:50:07 <Orie> ... in late 2021, we wanted to improve it, but it got stale
22:50:18 <Orie> ... we need to make some updates to it
22:50:27 <Orie> ... we need a way to authenticate schemas somehow.
22:50:38 <Orie> ... we need to continue to cover the metadata
22:50:56 <Orie> ... i know at least of 2 imps that use this today
22:51:16 <Orie> ... folks are independently using JSON Schema, regardless of the CCG draft
22:51:39 <Orie> ... I asked in the DIF slack who uses JSON Schema, and several companies responded.
22:51:54 <Orie> ... at DIF, we use JSON Schema in a lot of our specs for object models
22:52:12 <Orie> ... JSON Schema has a number of IETF drafts and excellent language support
22:52:28 <Orie> ... this doesn't cover code gen, editors, etc
22:52:46 <Orie> ... I think it plays well with JSON-LD, and they pair well together.
22:52:56 <Orie> ... I think we should allow for both
22:53:01 <dezell> q+
22:53:12 <Orie> ... I asked GPT-3 why we should include it in our spec
22:53:13 <SamSmith> q+
22:53:16 <wayne> q+
22:53:21 <Orie> ... and the ai gave some good answers.
22:53:25 <kristina> ack ivan
22:53:40 <manu> q+ to support further definition of this.
22:53:58 <kdeangs1> kdeangs1 has joined #vcwg
22:54:03 <Orie> 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
22:54:22 <Orie> ... one minor caveat, last i checked, JSON Schema is still a bit of a moving target
22:54:36 <Orie> ... this makes it hard to target for standardization
22:54:55 <Orie> ... W3C has had discussions with them, they politely said no, and would like to go their own way
22:55:04 <kristina> (+1 to ivan...)
22:55:09 <Orie> ... the impact to us is, if we provide a JSON Schema, it can't be normative
22:55:13 <pchampin> q+
22:55:21 <Orie> ... the spec can't normatively rely on JSON Schema or features
22:55:33 <Orie> ... if they do find a home for it in time, we might be lucky
22:55:42 <Orie> ... apart from that, I am in favor of what you said
22:55:45 <kristina> ack dezell
22:56:10 <Orie> dezell: I am a fan of creating a schema any time you have people creating documents, even with a non normative schema
22:56:33 <Orie> ... I will reach out and see if we can't find a way to find it a home
22:56:48 <Orie> ... everyweek i write a ccouple hundred lines of JSON Schema
22:57:01 <Orie> ... I have handled awkward features of composition
22:57:09 <Orie> ... consider me available for review
22:57:11 <kristina> ack SamSmith
22:57:28 <Orie> SamSmith: +1 to all the reasons to use JSON Schema mentioned
22:57:51 <Orie> ... we like to use the composition operators, to handle single issuance and presentation with graduated disclosure
22:57:57 <kristina> q
22:58:13 <kristina> ack wayne
22:58:28 <Orie> wayne: I am supportive of this work, I think JSON Schema is a great tool to help define shapes
22:58:34 <Orie> ... I want to warn that it can be messy
22:58:50 <Orie> ... type checks, semantic vocab, etc...
22:59:09 <Orie> ... JSON Schema can start to touch field constraints such as regex
22:59:13 <kristina> ack manu
22:59:13 <Zakim> manu, you wanted to support further definition of this.
22:59:21 <Orie> manu: +1 to the work item in general
22:59:46 <Orie> ... wanted to ask
23:00:00 <Orie> ... should we define a JSON Schema 2018 type, is that right?
23:00:12 <Orie> ... are you also saying we should have a schema for the core data model
23:00:29 <Orie> decentragabe: this is more about securing the credentialSubject, but I am ok to do both
23:00:41 <Orie> manu: we can do both as long as we know they are different
23:00:49 <kristina> q?
23:00:56 <Orie> decentragabe: yep, primary mission regarding the credential subject
23:01:02 <kristina> ack pchampin
23:01:24 <Orie> 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
23:01:38 <Orie> ... some people are really interested in linking a JSON-LD context with a JSON Schema
23:01:49 <Orie> ... I also wanted to point out that those people use Open API
23:02:00 <Orie> ... maybe its a solution to the problem Ivan raised
23:02:01 <Orie> q+
23:02:19 <Orie> ... if its more stable maybe we can refer to OAS3.0 instead?
23:02:27 <Orie> ... thats why its being raised in YAML-LD context
23:02:38 <kristina> ack Orie
23:04:41 <manu> 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
23:04:41 <manu> 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.
23:04:51 <dezell> q+
23:04:52 <phila> q+
23:04:55 <manu> Orie: When you have an API, you target a specific OpenAPI version.
23:05:00 <kristina> ack dezell
23:05:10 <Orie> dezell: great minds think alike
23:05:24 <Orie> ... every JSON Schema we write, we use OAS to do it... with components
23:05:38 <Orie> ... we already use OAS, and its a great point.
23:05:42 <kristina> ack phila
23:05:55 <Orie> phila: OAS is a standard?
23:06:00 <phila> -> https://swagger.io/specification/
23:06:06 <Orie> https://swagger.io/specification/
23:06:16 <Orie> ivan: the question is can we refer to it?
23:06:35 <Orie> phila: that thing isn't a formal standard, but it seems used often... can we use it?
23:06:47 <Orie> ivan: we do refer to schema.org normatively
23:06:52 <kristina> q?
23:07:18 <Orie> kristina: great conversation
23:07:24 <Orie> ... see you on the issues
23:07:33 <Orie> ... this is the end of the official agenda
23:07:42 <manu> Topic: Editorial Work Mode
23:07:42 <Orie> topic: Editorial Work Mode
23:07:55 <Orie> brent: we had a request to reiteerate the editorial work mode
23:08:17 <Orie> ... for issues, we want the editorial team to triage and comment on issues
23:08:27 <Orie> ... for PR if its substantive, it needs WG review
23:08:38 <Orie> ... editorial cchanges, only require 1 editor to sign off
23:08:47 <manu> q+ to note "FPWDs" and timeline for that.
23:08:47 <Orie> ... if concerns are raised, you may need to revert.
23:08:51 <Orie> ... thats it
23:08:58 <kristina> ack manu
23:08:58 <Zakim> manu, you wanted to note "FPWDs" and timeline for that.
23:09:06 <Orie> manu: I think we had specified times before
23:09:14 <Orie> ... 7 day window for review, to avoid backing out PRs
23:09:23 <kristina> q+
23:09:33 <Orie> ... are we ready for FPWD on data integrity?
23:09:41 <Orie> ... in the next month?
23:09:48 <Orie> ... do we want to pull another crypto suite spec
23:09:50 <Orie> q+
23:10:03 <kristina> ack Orie
23:10:10 <kristina> scribe+
23:10:24 <kristina> orie: in general in favor of doing FPWD for data integrity
23:10:40 <decentralgabe> decentralgabe has joined #vcwg
23:10:44 <kristina> ... the main comment is, to have confidence in the doc that represent WG consensus,
23:10:55 <kristina> ... not sure there is a wg consensus on another crypto suite
23:11:15 <kristina> ... want to have more conversation on crypto suite before doing another FPWD on it
23:11:20 <manu> q+ to note we might want mandatory reviews on documents
23:11:49 <kristina> ... not sure WG fully understands the implications of another cryptsuite
23:11:54 <kristina> q-
23:11:55 <Orie> ivan: general attitude is FPWD as soon as possible
23:11:56 <kristina> q+ ivan
23:11:59 <kristina> ack ivan
23:12:04 <Orie> ... it does not have to reflect wg consensus
23:12:19 <Orie> ... i've seen FPWD with just section headings... not that we need to do that.
23:12:24 <Orie> ... its a stake in the ground
23:12:40 <Orie> ... unless there is something very shameful in it, no reason not publish
23:12:44 <kristina> I am a little concerned with a 5th working document.. seeing the progress on other ones
23:12:55 <Orie> ... it triggers patent disclosure, and gives us stable URLs
23:12:57 <kristina> ack manu
23:12:57 <Zakim> manu, you wanted to note we might want mandatory reviews on documents
23:13:05 <Orie> manu: what we could do is mandatory reviews
23:13:18 <Orie> ... usually you just tell people, to read.
23:13:42 <brent> +1 to Ivan, FPWD sooner rather than later
23:13:48 <Orie> ... 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
23:13:59 <Orie> ... there are a lot of issues that don't need to be resolved
23:14:18 <Orie> ... I think we do need to update it to reflect the rough consenus on the data integrity proof stuff
23:14:18 <kristina> agreed on FPWD for data integrity now, would like more discussion before additional cryptosuite document
23:14:35 <Orie> ... +1 to what orie said, about publishing a crypto suite along side it
23:14:41 <Orie> ... if they are both ready, sooner the better'
23:15:52 <dezell> q+
23:15:59 <mccown> q+
23:15:59 <TallTed> q+
23:16:17 <kristina> ack TallTed
23:16:30 <kristina> ack dezell
23:16:46 <pchampin> RRSAgent, draft minutes
23:16:46 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-vcwg-minutes.html pchampin
23:17:06 <phila> +1 to dezell
23:17:19 <phila> s/+1 to dezell//
23:17:54 <kristina> ack mccown
23:21:18 <Orie> sorry just got back getting a drink.
23:22:00 <Orie> kristina: if there is anything that is "ready for PR"... lets try to get to a PR.
23:22:13 <Orie> ... we got a lot done over the past few days, a huge thanks for everyone
23:22:22 <Orie> ivan: I will do my best to clean up the minutes
23:22:39 <Orie> ... it will be hard, because I don't know all names
23:22:48 <Orie> kristina: thanks to scribes
23:23:02 <Orie> ... joe, kevin, dave orie
23:23:15 <Orie> brent: we will be off next week
23:23:27 <Orie> sry...
23:23:45 <Orie> brent: we decided not to cancel next week
23:24:03 <pchampin> RRSAgent, draft minutes
23:24:03 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-vcwg-minutes.html pchampin
23:24:05 <Orie> kristina: thanks everyone!
23:24:23 <pchampin> RRSAgent, draft minutes
23:24:23 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/16-vcwg-minutes.html pchampin