00:02:54 <gkellogg> gkellogg has joined #vcwg
00:30:14 <gkellogg> gkellogg has joined #vcwg
00:47:31 <gkellogg> gkellogg has joined #vcwg
00:56:33 <gkellogg> gkellogg has joined #vcwg
01:05:51 <gkellogg> gkellogg has joined #vcwg
01:05:51 <gkellogg> gkellogg has joined #vcwg
01:09:23 <gkellogg> gkellogg has joined #vcwg
01:26:13 <gkellogg> gkellogg has joined #vcwg
01:27:58 <gkellogg> gkellogg has joined #vcwg
01:42:43 <gkellogg> gkellogg has joined #vcwg
02:12:41 <gkellogg> gkellogg has joined #vcwg
02:16:32 <gkellogg_> gkellogg_ has joined #vcwg
02:32:38 <gkellogg> gkellogg has joined #vcwg
03:00:49 <gkellogg> gkellogg has joined #vcwg
03:22:51 <gkellogg> gkellogg has joined #vcwg
03:31:18 <gkellogg> gkellogg has joined #vcwg
03:48:01 <gkellogg> gkellogg has joined #vcwg
06:05:21 <tpac-breakout-bot> tpac-breakout-bot has joined #vcwg
06:05:23 <tpac-breakout-bot> RRSAgent, make logs public
06:05:24 <tpac-breakout-bot> RRSAgent, draft minutes
06:05:25 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/26-vcwg-minutes.html tpac-breakout-bot
06:05:32 <tpac-breakout-bot> RRSAgent, bye
06:05:32 <RRSAgent> I see no action items
15:44:58 <RRSAgent> RRSAgent has joined #vcwg
15:44:58 <RRSAgent> logging to https://www.w3.org/2024/09/26-vcwg-irc
15:45:07 <TallTed> 3 hour VCWG overlap with RDFstarWG. I think more that will benefit from my live input is over there. You can /msg if needs be.
15:45:07 <TallTed> regrets+
15:45:08 <TallTed> meeting: Verifiable Credentials Working Group
15:45:08 <TallTed> rrsagent, draft minutes
15:45:09 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/26-vcwg-minutes.html TallTed
15:45:10 <TallTed> rrsagent, make logs public
15:47:00 <ivan> Meeting: Verifiable Credentials Working Group F2F at TPAC, 1st day
15:47:00 <ivan> Date: 2024-09-26
15:47:00 <ivan> Agenda: https://www.w3.org/events/meetings/25b6f567-2d0d-4dee-9b9b-5906fd555aba/
15:47:00 <ivan> chair: brent
15:47:01 <ivan> ivan has changed the topic to: Meeting Agenda 2024-09-26: https://www.w3.org/events/meetings/25b6f567-2d0d-4dee-9b9b-5906fd555aba/
15:49:23 <KevinDean> KevinDean has joined #vcwg
15:49:29 <KevinDean> present+
15:49:48 <manu_> manu_ has joined #vcwg
15:51:47 <bigbluehat> bigbluehat has joined #vcwg
15:52:07 <ivan> present+
15:52:14 <ivan> present+ gabe
15:52:20 <ivan> present+ manu
15:52:33 <ivan> present+ bigbluehat
15:52:49 <ivan> present+ TallTed
15:53:28 <ivan> present+ gregb
15:53:55 <mandyv> present+
15:54:07 <ivan> present+ Wesley
15:55:41 <brent> brent has joined #vcwg
15:56:24 <decentralgabe> decentralgabe has joined #vcwg
15:57:34 <brent> present+
15:58:10 <ivan> present+ DavidE
15:59:00 <shigeya> present+
15:59:01 <Roy> Roy has joined #vcwg
15:59:23 <ivan> present+ jennie
15:59:28 <Roy> Roy has left #vcwg
15:59:58 <denkeni> present+
16:00:07 <wes-smith> wes-smith has joined #vcwg
16:01:16 <JennieM> JennieM has joined #vcwg
16:03:11 <ivan> present+ selfissued
16:04:39 <Wip> Wip has joined #vcwg
16:04:44 <Wip> present+
16:05:15 <Isaac> Isaac has joined #vcwg
16:05:26 <laurens> laurens has joined #vcwg
16:05:30 <GregB> GregB has joined #VCWG
16:05:30 <laurens> present+
16:05:40 <GregB> present+
16:05:46 <dlongley> present+
16:05:50 <dezell> dezell has joined #vcwg
16:05:52 <rigo> rigo has joined #vcwg
16:06:09 <JennieM> present+
16:07:02 <Bert> Bert has joined #vcwg
16:07:35 <KevinDean> q+
16:07:50 <Kyle> Kyle has joined #vcwg
16:07:59 <HeatherF> HeatherF has joined #vcwg
16:08:02 <selfissued> selfissued has joined #vcwg
16:08:07 <selfissued> present+
16:08:18 <KevinDean> https://docs.google.com/spreadsheets/d/18As8BMku1s536XxrJNvKus-08w-bGc1bRqvqzrGPpE0/edit?gid=179611341#gid=179611341
16:08:28 <decentralgabe> present+
16:08:29 <KevinDean> q-
16:08:30 <morimori4> morimori4 has joined #vcwg
16:08:31 <Jay> Jay has joined #vcwg
16:09:00 <jets> jets has joined #vcwg
16:10:19 <ivan> present+ jay
16:10:19 <JennieM> https://docs.google.com/presentation/d/1rjt4fgajEqqQzdF72JUeh6_h4gICQanExOfcoW4l0GM/edit#slide=id.p
16:10:32 <jets> present+ Brian_McManus
16:11:36 <yangsamy> yangsamy has joined #vcwg
16:12:55 <brent> q?
16:13:12 <wes-smith> scribe+
16:13:30 <morimori8> morimori8 has joined #vcwg
16:13:41 <wes-smith> brent: going to do introductions, lots of folks who might not have been to a meeting before
16:14:00 <wes-smith> ... no real format to the intros, who you are, who the member org you represent is, fun fact
16:14:16 <cc> cc has joined #vcwg
16:14:28 <wes-smith> ... Brent zundel, mesur.io, we sponsored the gala last night, been involved with VCWG for very long time
16:14:47 <wes-smith> ... happy to be here, if my feet could taste my socks would have to taste like beef jerky
16:15:32 <wes-smith> decentralgabe: Gabe Cohen, block, want to let you know that snails have over 20k teeth
16:16:23 <wes-smith> denkeni: working with Taiwan's government with VCs
16:16:41 <pauld_gs1> pauld_gs1 has joined #vcwg
16:16:54 <wes-smith> max: Max, involved with VCs for many years, first time at one of these meetings
16:17:57 <wes-smith> ???: Enrique Xavier, here as an observer
16:18:04 <dezell> dezell has joined #vcwg
16:18:21 <SinYong> SinYong has joined #vcwg
16:18:53 <wes-smith> ???:  member of automotive working group, involved with DID working group, VCWG, South Korea already develops and uses DIDs/VCs for mobile driver's license
16:19:13 <wes-smith> Laurens: chair of linked web storage working group, here as on observer
16:19:18 <ivan> s/???/Wonsuk Lee/
16:19:27 <Wonsuk> Wonsuk has joined #vcwg
16:19:28 <steele> steele has joined #vcwg
16:19:47 <sven> sven has joined #vcwg
16:19:54 <Davidc> Davidc has joined #Vcwg
16:19:57 <wes-smith> morimori8: primary area at w3c is authentication, identity proving naturally becoming important, I learned about this WG last year, excited to see the progress
16:20:06 <EricS> EricS has joined #vcwg
16:20:23 <Davidc> present+
16:20:25 <EricS> present+
16:20:30 <wes-smith> jay: Jay Kishigami, W3C team. Thank you for the people who joined "Web on the Moon" yesterday Breakout session. Interested in VC because of high expectations for VCs.
16:20:44 <wes-smith> JennieM: Jennie from digital contract design
16:20:52 <wes-smith> kevindean: kevindean from legendary requirements
16:21:00 <wes-smith> mandyv: Mandy venables, digital bazaar
16:21:13 <wes-smith> bigbluehat: Benjamin young, digital bazaar, I have an extra vertebrae
16:21:21 <wes-smith> Ivan: Ivan Herman, w3c, staff contact for this working group
16:21:55 <Davidc> Can someone send me the zoom url please as I am travelling today
16:22:03 <pauld_gs1> present+
16:22:03 <Isaac> Isaac has joined #vcwg
16:22:09 <wes-smith> selfissued: Mike Jones
16:22:10 <Max> Max has joined #VCWG
16:22:20 <HeatherF> present+
16:22:26 <shiyu> shiyu has joined #vcwg
16:22:36 <selfissued> selfissued has joined #vcwg
16:22:44 <osamu> osamu has joined #vcwg
16:22:44 <selfissued> present+
16:22:51 <osamu> present+
16:23:01 <wes-smith> dezell: David Ezell with Conexxus, standards org for retail space, we use VCs heavily, successful program going bc convenience stores have bad reputation for keeping up with age verification etc, and bad rep for handling private information, VCs are a game changer for us
16:23:11 <wes-smith> wip: will abramson, digital contract design
16:23:19 <HeatherF> HeatherF: Heather Flanagan, Spherical Cow Consulting, Observer and chair of the FedID WG (and the IETF SPICE WG)
16:23:52 <Geun-Hyung> Geun-Hyung has joined #vcwg
16:23:53 <wes-smith> GregB: Greg Bernstein, independent, invited expert, I generate test vectors in the crypto suites, if you are implementing and run into problems please contact me, I have open source code to help, also working on crypto suite drafts and privacy preserving signatures at the IETF
16:24:06 <wes-smith> ... putting in things like anonymous holder binding and pseudonyms
16:24:21 <wes-smith> ... help get privacy going alongside secure cryptography
16:24:35 <wes-smith> sven: Steven Venema, joined MSFT recently, new to the space, happy to learn
16:24:55 <wes-smith> ???: cryptographer at Meta, just observing
16:25:32 <wes-smith> manu_: Manu, Digital Bazaar, one of the editors here
16:25:34 <manu_> wes-smith: Wes Smith, Digital Bazaar, happy to be here.
16:25:36 <steele_> steele_ has joined #vcwg
16:25:58 <wes-smith> ???: from ??? university with Shigeya
16:26:22 <GregB> Extra info for cryptosuite interested folks: https://www.grotto-networking.com/VerifiableCredentials.html, has links to presentations, specs, and open source code for test vectors and more.
16:26:34 <wes-smith> ???: Kay from Singapore gvt, using VCs in work on digitalizing international trade documents, if you have attended breakout session yesterday we talked about VCs and NFTs to handle trade docs
16:26:50 <Davidc> Davidc has joined #Vcwg
16:27:17 <wes-smith> cc: Calvin from Gvt technology agency of Singapore, working with Kay and other colleagues on technology side, we have open attestation framework, looking to try to promote that to be published
16:27:40 <wes-smith> SinYong: also with infocom media development at Singapore, working on project to digitize trade documents
16:27:51 <wes-smith> Isaac: also from IMDA Singapore, nice to meet you
16:28:01 <shiyu> Shi Yu from GovTech Singapore
16:28:27 <Bert> I'm Bert Bos, W3C team, here as an observer.
16:28:30 <wes-smith> wes-smith has joined #vcwg
16:28:32 <Max> Max has joined #VCWG
16:28:47 <jets> I'm Brian McManus from Ignite Retail Technology. I go by 'jets' on IRC. We joined W3C in January and are new to this working group. When I found out IRC was used for scribing and managing meetings, I told a colleague, 'I'm with my people!' David Ezell from Conexxus encouraged us, as retailers, to get involved. We're particularly interested in exploring Verifiable Credentials for loyalty programs in convenience stores
16:28:56 <Kyle> Kyle: Kyle from GovTech Singapore, Software Engineer on the OpenAttestation framework
16:29:14 <Kay> Kay has joined #vcwg
16:29:15 <steele> steele has joined #vcwg
16:29:18 <wes-smith> jets:  Brian, we joined W3c in Jan, new to this working group, using VCs for loyalty programs in retail space
16:29:35 <wes-smith> rigo: From w3c team, interested in the semantics side of VCs
16:29:43 <wes-smith> ???: from Ericsson research
16:29:45 <MacTed> MacTed has joined #vcwg
16:30:12 <osamu> osamu from KEIO Univ.
16:30:27 <Kay> Hello, Infocomm Media Development Authority, working in a project that entails using VCs to digitalise cross-border trade documents
16:30:44 <Kay> Name = Kay Ren Yuh
16:30:58 <wes-smith> dlehn: David from Digital Bazaar
16:31:01 <ivan> present+ dlehn
16:31:09 <shigeya> s/???: from ??? university with Shigeya/kurosaka: Tatsuya Kurosaka from Keio University and Originator Profile CIP, shigeya's colleague/
16:31:14 <gkellogg_> gkellogg_ has left #vcwg
16:31:47 <shigeya> s/osamu from KEIO Univ./osamu: Osamu Nakamura from KEIO Univ./
16:31:54 <wes-smith> elundberg: Emil Lindberg from Yubico, here as an observer, active in European identity work
16:32:29 <elundberg> elundberg has joined #vcwg
16:32:31 <ivan> preresent+ shigeya
16:32:56 <mirja> mirja has joined #vcwg
16:32:57 <wes-smith> Paul_gs1: Paul Dietrich from GS1, standards org that does identity for supply chain
16:33:02 <ivan> present+ dlongley
16:33:27 <wes-smith> dlongley: Dave Longley, digital bazaar, fun fact, the congressman who wrote the legislation preventing commerce on the internet represented DB's hometown
16:33:33 <rigo> rrsagent, pointer?
16:33:33 <RRSAgent> See https://www.w3.org/2024/09/26-vcwg-irc#T16-33-33
16:33:40 <ivan> present+ pauld_gs1
16:33:40 <wes-smith> s/Paul_gs1/pauld_gs1
16:33:41 <dlongley> s/preventing/permitting/
16:34:05 <Davidc> Davidc has joined #Vcwg
16:34:24 <wes-smith> Ivan: not going to walk through VCWG charter, voting ended a week ago, no problems, enough yes votes, there are some comments and abstentions
16:34:34 <brent> q?
16:34:34 <wes-smith> ... one abstention also included comments, we could choose to ignore them but would prefer not to
16:34:41 <Bert> present+ Bert_Bos
16:34:53 <wes-smith> ... I prefer with a few non-obvious changes to have feedback from the group
16:35:23 <ivan> https://github.com/w3c/vc-wg-charter/pull/125
16:35:54 <wes-smith> ... one PR which I already made that includes the changes, the comment came because we did not change a particular statement from the old charter, we did not check to make sure it was still valid
16:36:26 <wes-smith> ... two notable things, one was that the ??? WG has finished its work and is in maintenance mode, we don't expect to do anything with them, no need to list as liaison, the PR removes that one
16:36:32 <wes-smith> ... also there was an incorrect URL
16:37:07 <wes-smith> ... for the other liaison statement, I would like feedback from the group, liaisons for other WGs are not controversial, liaisons outside the WG I personally cannot judge if they are valid or not
16:37:46 <wes-smith> ... the external organizations here, tell me if there is one or two you would prefer to remove
16:37:51 <wes-smith> ... or tell me it is good as is and to move on
16:38:18 <wes-smith> ... Brent and I looked at it, the only thing that at that point we we unsure of was whether hyperledger Aries was still active
16:38:18 <manu_> q+
16:38:25 <wes-smith> ... unsure if that liaison is still worth having
16:38:47 <brent> ack manu
16:38:54 <brent> ack manu_
16:39:07 <wes-smith> manu_: AFAIK the Canadian gvt, which uses VCs, is heavily invested in hyper ledger Aries, the acapy implementation for VCs is associated (maybe) with aries
16:39:09 <wes-smith> Ivan: leave as is, then
16:39:18 <wes-smith> ... are there any other switches the group would like
16:39:21 <wes-smith> ... once
16:39:22 <wes-smith> ... twice
16:39:28 <wes-smith> ... please put up the other pull request
16:40:00 <Wip> https://github.com/w3c/vc-wg-charter/pull/126
16:40:11 <wes-smith> ... this one refers specifically to the reference to a CCG document on HTTP API for digital credentials, it was said that this document is normative looking, either it should be listed as a deliverable/rec track document or be removed
16:40:42 <selfissued> selfissued has joined #vcwg
16:40:45 <wes-smith> ... we have discussed this separately, it turned out the CCG intends to potentially submit that document to either this WG or a later incarnation as a rec track document, which for me means that it must be removed from the charter as is right away
16:40:51 <selfissued> present+
16:41:14 <wes-smith> ... in the last change of W3C process, it's no longer a real thing to create a WG note which then is turned into a rec track document later, for some reason that is now frowned upon
16:41:23 <wes-smith> ... counterproductive to have this doc as a deliverable/WG note
16:41:27 <wes-smith> ... should immediately remove this
16:41:32 <wes-smith> ... also would satisfy commenter
16:41:37 <wes-smith> ... any pros/cons?
16:41:40 <brent> q?
16:41:41 <manu_> q+
16:41:46 <brent> ack manu_
16:41:55 <wes-smith> manu_: +1 to remove it, the intention is to take it rec track, cannot publish as note
16:41:56 <Davidc> Davidc has joined #Vcwg
16:42:05 <wes-smith> Ivan: I will merge this PR
16:42:16 <wes-smith> ... I will ask management to start the new charter on 1 Nov
16:42:29 <wes-smith> ... if we all agree that's all I have to ask
16:42:38 <dmitriz> dmitriz has joined #vcwg
16:42:46 <wes-smith> Brent: from our perspective, the IPR has not changed in new charter, no members need to rejoin?
16:42:50 <wes-smith> Ivan: correct
16:42:51 <dmitriz> present+
16:42:55 <manu_> q+
16:42:59 <wes-smith> Ivan: I wish all items today were as easy as this one
16:43:08 <brent> ack manu_
16:43:26 <wes-smith> manu_: great news, in the current charter/new charter, we will continue the work we started, finish it, then maintenance mode
16:43:38 <wes-smith> ... in there was continuing to finalize things like renderMethod, confidenceMethod?
16:43:41 <wes-smith> Ivan: correct
16:43:52 <wes-smith> ... I made the PR to add those, DB rep approved
16:44:20 <wes-smith> Brent: Done with intro section, have our first major topic through the break
16:44:41 <brent> Topic: VC Data Model
16:44:47 <manu_> https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240918/
16:45:03 <wes-smith4> wes-smith4 has joined #vcwg
16:45:06 <wes-smith4> scribe+
16:45:27 <wes-smith4> manu_: this is our core spec, we are attempting to publish version 2.0 ASAP, this defines a core data model for VCs
16:45:48 <wes-smith4> ... provides short intro, high level overview, basic concepts for credentials
16:46:18 <wes-smith4> ... what the credential is about (credentialSubject), validity period, associate info with the credential like status info, allows you to associate data schemas with the credential to make sure the credential is well formed
16:46:44 <wes-smith4> ... then we get into securing mechanisms, how do you cryptographically protect the credential, number of securing mechanisms we will discuss, this is the thing that makes the credential verifiable
16:46:50 <wes-smith4> ... then talk about verifiable presentations
16:47:27 <wes-smith4> ... advanced concepts section talks about trust model, ensuring integrity of linked resources, ZKPs, representing time, terms of use, how other ecosystems can be compatible with VC ecosystem, complex topics like graph based data model, securing mechanism specifications
16:47:41 <wes-smith4> ... syntaxes section, used to talk about multiple syntaxes, now focus on JSON-LD
16:47:50 <wes-smith4> ... talk about media types, algorithms for verification
16:47:59 <wes-smith4> ... privacy/security considerations sections in the document as well
16:48:10 <wes-smith4> ... also talk non-normatively about verification vs validation
16:48:18 <wes-smith4> ... talk about contexts and how to secure them and use them safely
16:48:23 <wes-smith4> ... finally we talk about media types
16:48:52 <wes-smith4> ... it's a large document, we have been processing issues, went into first CR months ago, have been processing mostly editorial but some normative issues, we will need second CR, will talk about that today
16:48:58 <wes-smith4> ... let's look at the issue tracker
16:49:13 <ivan> present+ dmitriz
16:49:20 <wes-smith4> ... we have 6 issues left on the spec, 3 of them have been marked for future (deferred)
16:49:29 <wes-smith4> ... two of the remaining are editorial, one has PR ready to merge
16:49:38 <wes-smith4> ... asserting we don't need to discuss these
16:49:56 <manu_> Test suite: https://w3c.github.io/vc-data-model-2.0-test-suite/#Basic%20Conformance
16:49:56 <wes-smith4> ... the other thing is our test suite, we have the results of our test suite
16:50:03 <ivan> present+ steele
16:50:33 <bigbluehat> q+
16:50:38 <wes-smith4> ... if we look at our test suite, our slides say we have 5 implementations, it is now 6, the Implementations are looking good, there are a couple where weird conformance statements might need their tests removed
16:51:06 <wes-smith4> ... if we go to presentations section, only 1 implementation, I know that there are multiple implementations, have been waiting on media type decision for vc-jose-cose specs to finalize those
16:51:23 <wes-smith4> ... we have more than enough implementations, there are features we expect implementers to implement once we make a decision tomorrow
16:51:55 <wes-smith4> ... the spec is in good shape, we circulated a static version of it a while ago, just using CR draft, we have 6 implementations, for the issues that don't have enough implementations right now, going to mark them "at risk" before CR2
16:52:01 <wes-smith4> ... expect those at risk markers to be removed
16:52:03 <bigbluehat> q-
16:52:44 <wes-smith4> ... the next thing we could do is pass a proposal to go into CR2 with the VC core data model, the current proposal is a 30 day review period on CR2 with clearly marking features w/o enough implementations as at risk
16:52:49 <ivan> q+
16:52:53 <wes-smith4> ... for open issues, we have PRs and will merge those before 2nd CR
16:53:11 <wes-smith4> Brent: which of these PRs could we merge right now?
16:53:18 <wes-smith4> manu_: remove problem detail integer error codes
16:53:23 <wes-smith4> ... all of them except the top one
16:53:28 <wes-smith4> ... a little concerned about merge conflicts
16:53:33 <wes-smith4> Ivan: let's not do that there [laughs]
16:53:44 <wes-smith4> manu_: presumption is we will merge all of these before CR2
16:53:58 <wes-smith4> ... one of them we might not, abstract one, but that is editorial
16:54:11 <wes-smith4> ... revised statement: some of the editorial stuff might not be merged before CR2 because it can be handled in CR2
16:54:11 <brent> q?
16:54:27 <brent> ack ivan
16:54:38 <wes-smith4> Ivan: practical question, do we intended to synchronize that publication with other CR2s
16:54:41 <manu_> q+
16:54:45 <wes-smith4> manu_: [nodes]
16:54:45 <manu_> q-
16:54:49 <wes-smith4> s/nodes/nods
16:55:17 <wes-smith4> Brent: next PR is one that absolutely must be merged before we go to CR2, it has been open for weeks, my suggestion is that we merge it
16:55:37 <wes-smith4> manu_: has plenty of approvals, 2 weeks of review, no objections, unless there are objections here we can merge
16:55:40 <wes-smith4> Brent: please do
16:56:13 <wes-smith4> manu_: merged
16:56:30 <selfissued> q+
16:56:48 <brent> q?
16:56:48 <wes-smith4> Brent: I tweaked the language in Manu's proposal, anyone that would like to suggest changes to this language?
16:56:53 <brent> ack selfissued
16:57:08 <GregB> Link to slides: https://docs.google.com/presentation/d/1rjt4fgajEqqQzdF72JUeh6_h4gICQanExOfcoW4l0GM/edit#slide=id.g477278097e_0_13
16:57:12 <wes-smith4> selfissued: I'd like us to discuss that there is normative dependencies on this spec to chain of other specs, DI, Jose-cose, controller document
16:57:26 <wes-smith4> ... don't anticipate us making changes to this spec bc of resolutions to the others, but might occur
16:57:35 <wes-smith4> ... might be prudent to send them all down the pipeline at the same time
16:57:36 <wes-smith4> Brent: that's the plan
16:57:41 <wes-smith4> Ivan: no, what he says is the resolutions
16:57:41 <manu_> q+
16:58:01 <brent> ack manu_
16:58:02 <wes-smith4> selfissued: the proposal makes it sound like we will publish second CR before we are ready for second CR for specs it has dependencies on, not ok with this
16:58:34 <wes-smith4> manu_: my concern is controller document, a number of things to discuss there tomorrow, I thought the agreement was it would be fine to publish controller document, DI, as second CR, because we don't expect any changes in controller document
16:58:48 <ivan> q+
16:59:00 <wes-smith4> ... publication of VCDM 2.0, DI, in a chunk, if we can, publish VC Jose-cose, but decouple so that if we had a problem with those documents it wouldn't hold up other ones
16:59:24 <wes-smith4> ... goal was to publish things ready now (DI, VCDM, EC/EDDSA crypto suites), attempt to publish other documents
16:59:25 <brent> ack ivan
16:59:29 <selfissued> q+
16:59:53 <brent> ack selfissued
16:59:54 <wes-smith4> Ivan: things only have to sync up at recommendation phase
17:00:05 <wes-smith4> selfissued: I would prefer that we wait to do this until near the end of the day tomorrow
17:00:21 <wes-smith4> ... there are substantive issues for vc-jose-cose that could require normative changes to the data model
17:00:27 <manu_> q+
17:00:37 <brent> ack manu_
17:00:38 <wes-smith4> ... we should make decisions at the end of tomorrow and discuss specs first
17:00:45 <wes-smith4> manu_: what would change? I don't know what would change
17:00:51 <wes-smith4> selfissued: the media type could change
17:00:59 <wes-smith4> ... we need to be creative about how to resolve that across all specs
17:01:03 <wes-smith4> ... in a consistent way
17:01:21 <manu_> q+
17:01:22 <wes-smith4> ... would like us to resolve all issues we can before we push the button
17:01:28 <brent> ack manu_
17:01:41 <decentralgabe> q+
17:01:46 <wes-smith4> manu_: for the record, Digital Bazaar would not prefer to do that, we have a lot to do tomorrow, will delay everything if we cannot pass these resolutions, no material impact on the specification
17:01:52 <brent> q+ to remind folks of our MO
17:02:04 <wes-smith4> ... if we change something fairly drastic, we can claw back the resolutions, any large change at this point would raise objections
17:02:10 <wes-smith4> ... such that the change would not be made
17:02:12 <brent> ack decentralgabe
17:02:31 <brent> ack brent
17:02:31 <Zakim> brent, you wanted to remind folks of our MO
17:02:33 <wes-smith4> decentralgabe: will suggest what Manu said, should go forward with this proposal for sake of agility, if it needs to change we can run another proposal
17:03:14 <wes-smith4> Brent: our operating mode is such that when we make a resolution, there is a 7 day countdown window where anyone can object, that person can have voted for it in the first place. in my opinion as chair, passing this resolution now is in line with selfissued's suggestion
17:03:19 <wes-smith4> selfissued: OK
17:03:40 <wes-smith4> Brent: once again asking, any proposed adjustments to this text that you see as necessary before we run it as a proposal
17:03:58 <wes-smith4> ... not seeing anyone on the queue
17:04:05 <ivan> q+
17:04:12 <brent> ack ivan
17:04:22 <decentralgabe> https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240926/
17:04:30 <HenriqueXavier> HenriqueXavier has joined #vcwg
17:04:32 <wes-smith4> Ivan: the URL there is probably no longer true, you have made a merge of the docs, the latest version we are trying to publish does not have that date
17:04:46 <wes-smith4> manu_: can use new CRD
17:04:49 <bumblefudge> bumblefudge has joined #vcwg
17:04:51 <wes-smith4> Ivan: remove the URL and put something there
17:05:46 <brent> PROPOSAL: Publish the latest VC Data Model v2.0 as a 2nd Candidate Recommendation with a 30 day review period after PRs for AT RISK features and all current open issues have been addressed.
17:05:49 <brent> +1
17:05:50 <decentralgabe> +1
17:05:50 <ivan> +1
17:05:59 <dmitriz> +1
17:05:59 <dlongley> +1
17:05:59 <manu_> +1
17:05:59 <shigeya> +1
17:05:59 <wes-smith4> +1
17:05:59 <bigbluehat> +1
17:05:59 <Wip> +1
17:05:59 <Jay> +1
17:05:59 <Davidc> +1
17:06:00 <JennieM> +1
17:06:21 <pauld_gs1> +1
17:06:22 <ivan> present+ davidc
17:06:27 <wes-smith4> Brent: seeing and hearing no objections
17:06:29 <brent> RESOLVED: Publish the latest VC Data Model v2.0 as a 2nd Candidate Recommendation with a 30 day review period after PRs for AT RISK features and all current open issues have been addressed.
17:06:49 <wes-smith4> ... that takes us to the end of our first session
17:06:56 <wes-smith4> ... early for our break, time is wrong anyway
17:07:00 <wes-smith4> ... on slides
17:07:10 <wes-smith4> ... break starts at 10:08, lasts until 11
17:07:26 <osamu> osamu has joined #vcwg
17:07:33 <ivan> rrsagent, draft minutes
17:07:35 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/26-vcwg-minutes.html ivan
17:08:15 <Geun-Hyung> present+
17:11:17 <steele> steele has joined #vcwg
17:11:22 <dmitriz> dmitriz has joined #vcwg
17:11:26 <Kyle> Kyle has left #vcwg
17:13:34 <Jay> Jay has joined #vcwg
17:18:01 <steele> steele has joined #vcwg
17:21:04 <Kurosaka> Kurosaka has joined #vcwg
17:21:13 <shigeya> present+ Kurosaka
17:24:18 <steele> steele has joined #vcwg
17:24:50 <Bert> Bert has left #vcwg
17:29:27 <gkellogg> gkellogg has joined #vcwg
17:38:21 <steele> steele has joined #vcwg
17:40:29 <Tatsuya> Tatsuya has joined #vcwg
17:43:17 <rigo> rigo has joined #vcwg
17:45:13 <steele> steele has joined #vcwg
17:45:19 <gkellogg> gkellogg has joined #vcwg
17:58:21 <brent> brent has joined #vcwg
18:00:11 <Jay> Jay has joined #vcwg
18:00:53 <KevinDean> KevinDean has joined #vcwg
18:00:55 <KevinDean> present+
18:00:56 <KevinDean> scribe+
18:01:07 <Tatsuya> Tatsuya has joined #vcwg
18:01:07 <dlongley> present+
18:01:16 <Tatsuya> present +
18:01:19 <laurens> laurens has joined #vcwg
18:01:21 <manu_> manu_ has joined #vcwg
18:01:26 <KevinDean> Brent: Next session is all about data integrity
18:01:33 <Wip> Wip has joined #vcwg
18:01:36 <Wip> present+
18:01:36 <gkellogg> gkellogg has joined #vcwg
18:01:45 <decentra_> decentra_ has joined #vcwg
18:01:52 <wes-smith> wes-smith has joined #vcwg
18:01:54 <brent> Topic: Data Integrity
18:01:59 <brent> q?
18:01:59 <gkellogg> gkellogg has joined #vcwg
18:01:59 <JennieM> JennieM has joined #vcwg
18:02:01 <mandyv> mandyv has joined #vcwg
18:02:02 <GregB> GregB has joined #VCWG
18:02:09 <GregB> present+
18:02:15 <manu_> https://www.w3.org/TR/2024/CRD-vc-data-integrity-20240919/
18:02:24 <KevinDean> manu: Link to current candidate recommendation
18:02:25 <shigeya> present+
18:02:29 <osamu> osamu has joined #vcwg
18:02:52 <KevinDean> ...VC Data Integrity is one of the securing mechanisms in the VCDM. In order for a credential to be verifiable, it must be secured.
18:03:30 <KevinDean> ...The data integrity spec establishes a baseline way to secure something. To make it concrete, you have to apply a cryptographic suite, specifying algorithm and key type and the process of securing and verifying the payload.
18:03:35 <selfissued> selfissued has joined #vcwg
18:03:42 <selfissued> present+
18:03:57 <osamu> present+
18:03:58 <KevinDean> ...Document has boilerplate stuff followed by a data model.
18:05:11 <KevinDean> ...Talk about things like sets of proofs (parallel signatures), proof chains (dependent proofs, e.g., individual followed by notary), proof graphs (proof separate from the data that it is securing), proof purposes (e.g., authentication, assertion of some statement), resource integrity, JSON-LD context and vocabulary, relationship to linked data and
18:05:11 <KevinDean> VCs, base cryptographic suite type.
18:05:32 <Kyle> Kyle has joined #vcwg
18:05:47 <KevinDean> ...There are algorithms as well for adding a proof and verifying a proof, how to do context validation (added due to issues raised), defining processing errors and types for developers.
18:05:55 <Isaac3> Isaac3 has joined #vcwg
18:06:04 <KevinDean> ...Health-sized security and privacy considerations sections.
18:06:13 <Tatsuya> present+
18:06:22 <KevinDean> ...Detailed explanation of how proofs work in an appendix.
18:06:31 <manu_> https://www.w3.org/TR/2024/CRD-vc-di-ecdsa-20240916/
18:07:38 <brent> q?
18:07:39 <cc> cc has joined #vcwg
18:07:51 <KevinDean> ...Paired with this document, using ECDSA as an example, we have cryptosuite specifications covering things like the data model specific to the algorithm, how the proof is represented, and the algorithms for adding a proof (RDF or JSON canonicalization, selective disclosure, derivation, etc.).
18:07:57 <GregB> q+
18:08:06 <mandyv> present+
18:08:10 <KevinDean> ...ECDSA as an example provides three cryptosuites.
18:08:20 <KevinDean> ...RDF, JSON-LD, JSON.
18:08:51 <KevinDean> ...There are test suites. The way that we test these documents is to test the data integrity specification in each cryptosuite.
18:09:35 <SinYong> SinYong has joined #vcwg
18:10:04 <KevinDean> ...You'll note that session title says "Data Integrity" and then which cryptosuite is being tested. We rerun the tests for every single cryptosuite.
18:10:27 <KevinDean> ...We have demonstrated multiple interoperable implementations for ECDSA.
18:10:56 <KevinDean> ...We have at least one that doesn't have many implementations. When that happens, we mark it as at risk when we go to candidate recommendation.
18:11:18 <KevinDean> ...It is interesting to see when one organization generates a signature and another verifies it, we find gaps in implementations.
18:11:38 <KevinDean> ...That's important because interoperability is important.
18:11:45 <KevinDean> ...We test VC 1.1 and 2.0 in the crypto suites.
18:11:50 <ivan> q+
18:12:24 <KevinDean> ...Brent just said that he didn't see anything that didn't have at least two implementations.
18:12:37 <KevinDean> bigbluehat: We went through everything and there are at least two for each.
18:12:58 <brent> q?
18:13:01 <brent> ack GregB
18:13:46 <KevinDean> GregB: I want to point out that appendices on test vectors are very worked-through examples for anyone trying to do implementations. They show a developer all the steps and we keep those very up-to-date with the text. When we add any normative change, we update the test vectors.
18:14:09 <SinYong> SinYong has joined #vcwg
18:14:09 <KevinDean> ...My implementation may be lagging, but they are there to help folks keep up. Every cryptosuite has those.
18:14:23 <brent> ack ivan
18:15:05 <manu_> q+
18:15:19 <KevinDean> Ivan: You treated that table on interoperability sort of off-hand saying that it's not required but we did it. I say that it is required even though not in the text. If we didn't have it, we would get feedback saying that we didn't test interoperability. I think it's important and hope that we have the same table in all cryptosuites.
18:15:33 <brent> ack manu_
18:15:36 <bigbluehat> q+
18:15:41 <KevinDean> manu: We haven't had to do that in other working groups.
18:15:55 <GregB> Note all cryptosuites have "test vectors" which are fully worked through examples of securing a VC. The code for producing these vectors is open source. See links on my VC page: https://www.grotto-networking.com/wson.html.
18:15:57 <KevinDean> Ivan: We had comments that we have to prove the interoperability of these things.
18:16:17 <brent> ack bigbluehat
18:16:27 <KevinDean> bigbluehat: Required or not, we have it.
18:16:31 <KevinDean> ...Go team!
18:17:13 <shiyu> shiyu has joined #vcwg
18:17:17 <KevinDean> Manu: Data Integrity has three issues, two editorial. ECDSA has three issues, two editorial. EdDSA has zero issues.
18:18:00 <KevinDean> ...The test suite for Data Integrity has eight implementations, ECDSA has six, EdDSA has eight. If there are any features in the test suites that don't have at least two independent implementations we would mark them as at-risk before going to CR-2.
18:18:23 <KevinDean> ...Issue 76.
18:18:37 <brent> subtopic: https://github.com/w3c/vc-di-ecdsa/issues/76
18:18:41 <dmitriz> dmitriz has joined #vcwg
18:19:56 <KevinDean> Ivan: For whatever reason, we have now the cryptosuite and the DI spec and the controller document. Not interested in how it came into being. The controller document has been put forward as abstracting a number of features, terms, and data types that are shared by different specifications, including some not in this group. I think that's a good
18:19:57 <KevinDean> think. At least in my mind, a controller document should ge usable in applications that have nothing to do with VCs or DIDs.
18:20:44 <KevinDean> ...The multikey format (abstract) has been put into the controller document. The multikey specification format is useful if its defined for each algorithm (ECDSA etc.).
18:21:48 <KevinDean> ...Currently, this definition is duplicated. That's bad. We don't repeat ourselves, otherwise we get into trouble. It is my fairly strong position that it must be in the controller document and only there. Let's say that I want to make an application that signs an email. That has nothing to do with credentials or cryptosuites. Multikey gives me a
18:21:48 <KevinDean> compact representation form.
18:22:22 <KevinDean> ...Using ECDSA, I may have to go to the data integrity specification to get full details.
18:22:26 <sven> sven has joined #vcwg
18:22:26 <manu_> q+
18:22:31 <KevinDean> ...The right place is to have it in the controller document only.
18:22:31 <brent> ack manu_
18:22:57 <cc> cc has joined #vcwg
18:23:25 <KevinDean> manu: The slide has three options. There are a couple of challenges with putting all of the key definitions in the controller document. Multikey and multibase have jumped specifications multiple times; they should be their own specifications so that people can refer to them in their own way. We're not doing that.
18:23:39 <KevinDean> ...We tried to publish at IETF and were blocked, so we put them back here.
18:23:59 <KevinDean> ...The thing I'm most concerned about is that cryptosuites need to specify which key types work with them.
18:25:04 <KevinDean> ...Let's say we create a new cryptosuite that uses a new key type. If so, we would have to reopen the controller document to define the key type. I think that the right approach is for cryptosuites to define their own key types and for their key types to be in a registry somewhere.
18:25:41 <KevinDean> ...We have comments that people didn't want to refer to other documents for the key specification.
18:25:47 <ivan> q+
18:26:00 <KevinDean> ...Putting it in the controller document means that you would have to reopen the controller document for each new key format.
18:26:27 <brent> ack ivan
18:26:35 <KevinDean> ...Putting it in the cryptosuite document makes it easier to add new key types. The way that we have it now is unfortunate but is a compromise that allows us to get through without objections.
18:27:29 <manu_> q+
18:27:35 <KevinDean> Ivan: I won't lie in the road to get in the way. I see a fourth possible approach, possibly sub-optimal, that we move everything into the controller document, publish everything because we're under time pressure, and then in maintenance we work out a way for people to add new keys on a website or similar.
18:27:50 <KevinDean> ...We don't have the time to do it fully and cleanly, but we can open the way to do it later.
18:27:50 <brent> ack manu_
18:28:03 <steele> steele has joined #vcwg
18:28:27 <KevinDean> manu: We have the VC extensions. We could add another table there where we could add new registries there that would allow you to add stuff. My concern is still the same. Cryptosuite specifications need to be able to define the key types.
18:28:42 <ivan> q+
18:28:46 <dlongley> +1 to using extensions and language that says cryptosuite spec authors can define new/reference new key types
18:28:47 <KevinDean> ...As long as we have language that allows cryptosuite authors to add key types, we're probably fine.
18:28:49 <brent> ack ivan
18:29:43 <manu_> q+
18:29:44 <KevinDean> Ivan: I have the impression that this is something that should be there anyway. The statement that you made is regardless of whether the cryptosuite has them or not. That guidance should be there, regardless of the outcome of this issue. Putting it into VC extension for now works for me. We can clean up in maintenance.
18:29:47 <brent> ack manu_
18:29:50 <bumblefudge> bumblefudge has joined #vcwg
18:30:07 <KevinDean> Manu: I'm worried about the changes that this might make to the specification. Can we take those definitions out of the specs and put them in the registry?
18:30:09 <KevinDean> Ivan: No.
18:30:27 <KevinDean> Manu: I'm worried that there's some language in the cryptosuite specification that may trigger some kind of issue if we do this.
18:30:49 <manu_> q+
18:31:00 <KevinDean> Ivan: After cursory look, for me, there is one paragraph that could be replaced with "look at table in controller document".
18:31:04 <brent> ack manu_
18:31:10 <cc> cc has joined #vcwg
18:31:11 <KevinDean> ...Definition for multikey for ECDSA is a single paragraph.
18:31:34 <GregB> Sorry wrong link for test vector code links. See https://www.grotto-networking.com/VerifiableCredentials.html
18:31:38 <KevinDean> Manu: What if we say that the controller document establishes a registry for multikey and multibase and then we point to the registry.
18:31:39 <selfissued> q+
18:31:46 <brent> q+
18:31:52 <brent> ack selfissued
18:31:56 <KevinDean> Ivan: The registry can define multikey with no additional references required.
18:32:32 <KevinDean> selfissued: I disagree. Registries are never the authoritative definition; they refer to authoritative definitions in specifications.
18:32:34 <brent> ack brent
18:32:46 <manu_> q+
18:32:47 <KevinDean> Brent: What registry are y'all taking about? We ain't got none of those.
18:33:09 <brent> ack manu_
18:33:15 <KevinDean> ...This group decided very firmly to not have anything to do with registries, which, on the record, I disagree with.
18:33:30 <ivan> q+
18:33:46 <KevinDean> Manu: The changes would be that the controller document would point to the VC extensions list, if you're interested in any of the values, go to that table.
18:33:52 <brent> ack ivan
18:33:56 <KevinDean> ...It would be the same content but shifted over to VC extensions.
18:34:18 <KevinDean> Ivan: That document can't have the authoritative definition of a key because it's a note.
18:34:18 <dlongley> +1 to using VC extensions and have each entry there list the spec where the key definition is
18:34:40 <manu_> q+
18:34:54 <KevinDean> ...We open up a table which can point back to the controller document. If at some time later someone comes up to an authoritative definition for multikey, we can point to that definition.
18:35:24 <KevinDean> ...For the WG purpose today, we have a table for all multikeys that we define in the controller document and we create an index for developers to find them easily.
18:35:24 <brent> ack manu_
18:35:45 <decentra_> q+
18:35:49 <KevinDean> Manu: What that means is that we cannot add anything new if we do not have a working group.
18:36:05 <brent> ack decentra_
18:36:12 <KevinDean> ...Other working groups can, but we would not be in a position to say that what they did is authoritative.
18:36:32 <manu_> q+
18:36:36 <ivan> q+
18:36:36 <brent> ack manu_
18:36:40 <KevinDean> decentra_: We need an approach that allows us to register new security mechanisms after this group has left.
18:36:58 <KevinDean> manu: The other thing to consider is that the thing that is normative is the specification, not the registry.
18:37:12 <bumblefudge> present+
18:37:38 <brent> q?
18:37:39 <KevinDean> ...That means that that list doesn't need to be normative. We can have a statement in a normative document pointing to a note.
18:38:14 <KevinDean> ...In the controller document, we can have a section that says that if you're interested in key types, go to this list of extensions, and it will list all the key types.
18:38:14 <brent> ack ivan
18:38:35 <Max> Max has joined #VCWG
18:38:59 <dezell> dezell has joined #vcwg
18:39:06 <KevinDean> Ivan: You are doing a sneaky way of doing what is there. My idea is almost what you say but not exactly. In your scheme, you keep the ECDSA version in the ECDSA cryptosuite. My variant is to have what we define in the working group in the controller document.
18:39:09 <manu_> q+ to note fine w/ that.
18:39:21 <dlongley> +1 to Ivan's proposal
18:39:22 <brent> ack manu_
18:39:22 <Zakim> manu_, you wanted to note fine w/ that.
18:39:29 <KevinDean> ...We can then point to an index to look up additional definitions and move what we have defined into the controller spec.
18:39:38 <KevinDean> manu: I would be fine with that as a compromise.
18:39:57 <selfissued> q+
18:40:03 <brent> subtopic: https://github.com/w3c/vc-data-integrity/issues/272
18:40:13 <brent> ack selfissued
18:40:23 <KevinDean> selfissued: A lot was said in the last ten minutes about what changes have been proposed.
18:41:12 <KevinDean> manu: We are going to put the key definitions for multikey in the controller document; they are already there and will remain. We are going to modify the controller document to point to a list of other key extensions and remove the definitions from the cryptosuites.
18:41:19 <KevinDean> ...Back to 272.
18:41:26 <denkeni> +1 to the current resolution here. It helps from the developer’s side to avoid confusion.
18:42:03 <KevinDean> ...Currently there are 145 comments regarding security vulnerabilities.
18:42:15 <KevinDean> ...The matter of concern is about security the context: using content integrity on the context.
18:42:46 <wes-smith> wes-smith has joined #vcwg
18:42:47 <KevinDean> ...We have made adjustments to the core specification to add vocab, no longer using it by default.
18:42:59 <wes-smith> s/add vocab/@vocab
18:43:05 <morimori> morimori has joined #vcwg
18:43:08 <brent> q+
18:43:09 <KevinDean> ...We have enhanced the content of the validation process in the data model and the data integrity specifications.
18:43:34 <KevinDean> ...We have enhanced the document process and have committed to adding the attack initially described to the test suites.
18:43:35 <ivan> S/@vocab/`@vocab`/
18:43:56 <KevinDean> ...There has been a partial implementation/discussion around content integrity protection over the context.
18:44:27 <KevinDean> ...There have been a number of discussions where if the verifier knows what context they're process, that there is no attack.
18:45:10 <KevinDean> ...One of the proposals on the table is that if an issuer secures the context, a verifier must verify the context. That would enable issuers that are concerned about this to force verifiers to do what they want.
18:45:35 <KevinDean> ...Securing the context means adding a cryptographic hash of the context to the context URL in the VC.
18:45:39 <brent> ack brent
18:46:28 <KevinDean> Brent: You said something during the break, Manu, that the changes that have already been made mean that when an issuer proves a context, the verifier needs to already be aware of the context prior to receiving the context.
18:46:32 <KevinDean> q+
18:46:40 <manu_> scribe+
18:46:41 <brent> ack KevinDean
18:47:19 <manu_> KevinDean: An immediate concern with verifier receiving content... there may be contexts that are extensions of those that are already known. I could receive something that builds on top of existing context, relies on underlying context when I'm processing.
18:47:32 <manu_> KevinDean: Seems highly restrictive for verifier to know what they have to receive.
18:47:35 <manu_> q+
18:47:36 <dlongley> q+
18:47:38 <KevinDean> s/receiving the context/receiving the content/
18:47:43 <manu_> q- later
18:47:46 <brent> ack dlongley
18:49:07 <KevinDean> DLongley: A context URL is either well-known or opaque. A well-known URL will appear as a constant in source code. You've written your application against the terms defined in the context. Otherwise, you have an opaque URL. Your application cannot process against that as it's not known to the application.
18:49:52 <KevinDean> ...If your application wants to process opaque contexts, the document must be transformed to one that the application understands.
18:49:56 <SinYong> SinYong has joined #vcwg
18:50:12 <KevinDean> ...It's OK to read the terms you understand and ignore the ones you don't.
18:50:13 <brent> ack manu_
18:50:31 <dmitriz> q+
18:50:47 <KevinDean> Manu: An attack has not been demonstrated. There's no code that demonstrates an attack that the specification defines for context management.
18:50:52 <brent> ack dmitriz
18:51:49 <dlongley> q+
18:51:57 <brent> ack dlongley
18:52:01 <KevinDean> dmitriz: I don't take issue with there being no attack demonstrated. It would not go amiss if we required cryptographic verification by the verifier of the terms in a related context. We have this resource, we have cryptographic protection, so why not make it required by the verifier even if there is no demonstrated attack?
18:53:03 <dmitriz> q+
18:53:10 <brent> ack dmitriz
18:53:12 <KevinDean> dlongley: If an opaque URL shows up, you must transform that document to something you can understand before you can consume it. On top of this, the cryptosuites protect the document, so verification must take place first. Only after that does the context define how the document must be processed.
18:53:28 <brent> q+
18:53:52 <bigbluehat> q+ to say adding hash verification is unnecessary and added cost for non-technical reasons
18:54:02 <jets> present+ Brian_McManus
18:54:15 <denkeni> +1 to dmitriz
18:54:15 <KevinDean> dmitriz: Adding that requirement to verifiers has additional benefits. It prevents developer confusion if the context changed. I agree that hash checking isn't required but adds value to the verification.
18:55:04 <dlongley> dmitriz, what you're talking about to me, is "differently identified contexts, which happen to be content identified" which, to me, is a separate consideration entirely
18:55:05 <manu_> q+ to note as long as it's optional for issuers, we can hold our nose, but to be clear -- a successful attack hasn't been demonstrated.
18:55:05 <bumblefudge> this could perhaps be called an "ergonomic" or "developer experience" argument, since "oh wait i'm storing linked documents wrong" is a more helpful error message than "signature failed"
18:55:08 <KevinDean> Brent: The solution we are discussing and that has been discussed in the past is the proposal that if an issuer elects to protect the integrity of the context through the related resource property, we should add a requirement that a verifier must verify the integrity of the context.
18:55:26 <KevinDean> ...The change that is being proposed, "If that's done, the verifier must check".
18:55:40 <bumblefudge> even if, functionally, they're the same outcomes
18:55:40 <KevinDean> ...Dave has pointed out that in this particular this, that may be moot.
18:55:55 <ivan> present+ bumblefudge
18:56:15 <KevinDean> ...How do folks feel about requiring that the verifier validate the integrity if the issuer specifies it? This would elevate SHOULD to MUST for resource integrity protection.
18:56:59 <KevinDean> ...Whether or not it directly addresses the issue doesn't matter. On the one hand, it's a general thing that makes sense to folks. On the other hand, it makes the people that raised the issue to be happy.
18:57:29 <brent> ack brent
18:57:33 <brent> ack bigbluehat
18:57:33 <Zakim> bigbluehat, you wanted to say adding hash verification is unnecessary and added cost for non-technical reasons
18:58:04 <KevinDean> bigbluehat: I think we need to separate the "why" because this is not enhancing the security and is adding processing cost.
18:58:11 <Isaac> Isaac has joined #vcwg
18:58:33 <ivan> q+
18:58:45 <KevinDean> ...If we restrain it to context files, forcing people to process related resources may be OK, but I don't believe that the expense of verifying all related resources (e.g., a PDF that is not actually used) can be expensive.
18:59:08 <KevinDean> ...It does not enhance security. We should be clear on why we're doing it and at what cost.
18:59:30 <brent> ack manu_
18:59:30 <Zakim> manu_, you wanted to note as long as it's optional for issuers, we can hold our nose, but to be clear -- a successful attack hasn't been demonstrated.
18:59:33 <KevinDean> ...Right now, I don't think the origin of the idea is not addressed by the idea itself.
18:59:44 <bengo> bengo has joined #vcwg
19:00:09 <KevinDean> manu: +1 to what Benjamin said. As long as it's optional for issuers for contexts, that seems like it would be acceptable to verifiers.
19:00:24 <KevinDean> ...Again, a successful attack has not been demonstrated.
19:01:17 <KevinDean> ...We are creating the expectation that can trip up developers where contexts are required to be validated but other related resources are not.
19:01:20 <brent> ack ivan
19:01:22 <dlongley> q+ to propose that if your application reads the related resource field to dereference a URL, your application must check the hash
19:02:03 <KevinDean> Ivan: The only thing I could add to that is that I think we should do it, and we should draw attention to the fact that issuers should treat this feature with care because of the high cost to verifiers.
19:02:05 <KevinDean> q+
19:02:08 <brent> ack dlongley
19:02:08 <Zakim> dlongley, you wanted to propose that if your application reads the related resource field to dereference a URL, your application must check the hash
19:02:31 <KevinDean> dlongley: Something that would make a lot of sense to me to propose that if your application reads the related resource field, it must check the hash.
19:02:34 <bigbluehat> q+ to note there's no reason implementers cannot do this now
19:02:51 <KevinDean> ...If you are going to read the related resource and there is a hash, you must check it.
19:02:57 <KevinDean> q-
19:03:01 <dmitriz> @dlongley - that's really elegant. it fits with what Benjamin/bigbluehat was saying (that we don't need to /automatically/ check the URLs), but if you DO dereference/fetch.. yeah
19:03:13 <brent> q?
19:03:18 <brent> ack bigbluehat
19:03:18 <Zakim> bigbluehat, you wanted to note there's no reason implementers cannot do this now
19:03:36 <KevinDean> bigbluehat: It's possible now. You can do this now. Your implementer can use related resource. We added language saying that you can do that.
19:03:49 <brent> q+
19:03:50 <selfissued> q+
19:03:58 <KevinDean> ...My point is that making it a MUST or stronger than it is now is necessary.
19:04:07 <brent> ack brent
19:04:35 <KevinDean> Brent: The part of it that was clarified for me is that, if you are planning to dereference the URL, you MUST check it. I think that's a very sane thing to add to the spec.
19:04:35 <bumblefudge> +1 to brent
19:04:36 <brent> ack selfissued
19:04:58 <KevinDean> selfissued: As I see it, related resource is a security feature. It makes no sense, if it is present, to not require it as a security feature.
19:05:15 <KevinDean> Brent: I think we're at the point where we can entertain language for the proposal.
19:06:00 <KevinDean> Manu: Proposed language.
19:06:17 <selfissued> q+
19:06:29 <brent> ack selfissued
19:06:31 <KevinDean> Brent: Proposal is to add this language to the specification to address issue 272, raise as PR and close 272.
19:06:52 <brent> q+
19:06:54 <manu_> q+ to note "if listed" concerns.
19:07:04 <KevinDean> selfissued: Not OK with the beginning part. I think the way it should be worded is that, if something is listed in the related resources list, its integrity must be checked.
19:07:09 <steele> steele has joined #vcwg
19:07:09 <dmitriz> q+ to point out the 'cached' use case
19:07:15 <brent> ack brent
19:07:39 <KevinDean> Brent: What if it says, "If it makes use of a resource..."?
19:07:56 <selfissued> q+
19:08:00 <KevinDean> ...If there are resources there that a verifier is never going to touch, is it necessary to verify anyway?
19:08:07 <brent> ack manu_
19:08:07 <Zakim> manu_, you wanted to note "if listed" concerns.
19:08:28 <cc0> cc0 has joined #vcwg
19:08:35 <KevinDean> Manu: e.g., What happens if I like to a 5GB video? I don't need to check it unless I actually access it.
19:08:42 <dlongley> +1 to manu, it's a bigger security problem to force downloads
19:08:58 <dlongley> it's also a privacy problem.
19:09:01 <dmitriz> +1
19:09:03 <brent> ack dmitriz
19:09:03 <Zakim> dmitriz, you wanted to point out the 'cached' use case
19:09:03 <KevinDean> ...I'm concerned about VCs that link to lots of other documents. That could create a DoS attack on verifiers.
19:09:28 <decentra_> q+
19:09:55 <KevinDean> dmitriz: Agreed with Manu. Another nuance is that the other reason to not say that if it's there it must be verified. If it's cached, it should not need to verify it again as it already has a local copy.
19:10:04 <brent> ack selfissued
19:10:50 <decentra_> q-
19:10:56 <KevinDean> selfissued: I get the 5GB video example. That's not the motivating case. What we're talking about are the contexts that are going to be a few kB. To partially address the issue, we should say that if the related resource is a context issue, it must be checked.
19:10:56 <bigbluehat> q+
19:10:57 <KevinDean> q+
19:11:06 <brent> ack bigbluehat
19:11:37 <KevinDean> bigbluehat: We could use language like "activate". For example, the subresource spec for HTML doesn't process them until they're used.
19:11:46 <decentra_> q+ to talk about verifiability at the time of issuance
19:11:56 <KevinDean> ...Context files can be quite large, e.g., schema.org.
19:12:06 <brent> ack KevinDean
19:12:09 <KevinDean> ...Maybe there's better language as yo might have it on hand.
19:12:12 <bumblefudge> bumblefudge has joined #vcwg
19:12:16 <KevinDean> s/as yo /as you /
19:12:26 <ivan> scribe+ manu_
19:12:31 <manu_> KevinDean: Back to the question of there being multiple context files that are not known to the verifier.
19:12:41 <bumblefudge> +1 to bigbluehat - aligning with SRI language or other WG precedent sounds good
19:12:46 <dlongley> +1 to Kevin.
19:12:47 <selfissued> q+
19:13:03 <brent> q+ to chair
19:13:05 <manu_> KevinDean: It's not that you're going to process them because you don't understand them, those context files are irrelevant for the verifier, no need to download them. I don't see any issue with the idea that if you're not going to use it, you're not going to check it.
19:13:38 <bigbluehat> q+ to mention requiring dereferencing of contexts can be a privacy violation
19:13:39 <brent> ack decentra_
19:13:41 <Zakim> decentra_, you wanted to talk about verifiability at the time of issuance
19:13:44 <manu_> KevinDean: Caching might be considered verified if its already verified and cached. If there is content integrity on something you're going to use, you don't need toverify it. I don't think we need to call out contexts as a type of file, because there are some that you will not use.
19:13:56 <denkeni> q+
19:14:00 <KevinDean> decentra_: I'm struggling to understand the use case where it's there but not going to be used.
19:14:01 <KevinDean> q+
19:14:08 <brent> ack selfissued
19:14:11 <dlongley> to answer Gabe, in the three party model, you don't know what verifiers will use and what they won't.
19:14:25 <dlongley> and different verifiers can make different choices.
19:14:28 <decentra_> q+
19:14:32 <dmitriz> @gabe - no, it's more like, the VC is gonna be useful to many parties. SOME parties will actually use the video. and some won't. doesn't make it less legitimate
19:14:39 <dlongley> +1 to dmitriz
19:14:50 <decentra_> if some will use it then it should be verifiable
19:14:55 <brent> q- later
19:15:14 <KevinDean> selfissued: I'm fine with if you're verifying something you already have cached you don't need to verify again. If something is listed in a context, are you free to not use the context? I thought that there are context things that have non-local effects so you have to look at all contexts.
19:15:15 <brent> ack bigbluehat
19:15:15 <Zakim> bigbluehat, you wanted to mention requiring dereferencing of contexts can be a privacy violation
19:16:00 <KevinDean> bigbluehat: To the question about JSON-LD, in broader JSON-LD land, there are moments and times where you need to get all context files, cached or not.
19:16:17 <KevinDean> ...If you don't use terms from another context file, you don't need to retrieve it.
19:17:11 <KevinDean> ...There's no way to know that unless you signed with data integrity. If I have a pile of context files and you give me a signature over the set of the quad, if I run things through a separate process and get the same hash from the same graph, then I don't need the context files.
19:17:22 <selfissued> q+
19:17:37 <KevinDean> ...As long as it maps to the same URLs, I can get the same signature.
19:18:08 <brent> ack selfissued
19:18:09 <KevinDean> ...As long as your quads are signed, which is what data integrity is about, you're fine.
19:18:40 <KevinDean> ...I get that what data integrity gives you is the signed quads, but the issue description gives the attacker the ability to change the meaning.
19:18:41 <dlongley> and you must never read a mapping you don't understand -- securing the contexts does not "fix it".
19:18:59 <KevinDean> bigbluehat: It doesn't change the semantic meaning. The quads you would get out would not succeed.
19:19:00 <dlongley> (because that's not the problem... the problem is reading terms from a context you don't understand, which must never be done)
19:19:15 <dlongley> (you must translate to context you do understand firsT)
19:19:29 <KevinDean> selfissued: I have tried to bring all of this to Tobias to weigh in again.
19:19:39 <KevinDean> Brent: I feel we are on the cusp of a decision.
19:20:16 <KevinDean> ...Mike, you're the only one to object to the proposed wording.
19:20:19 <ivan> q?
19:20:36 <selfissued> What is the current proposed resolution wording?
19:20:43 <brent> ack denkeni
19:22:08 <KevinDean> denkeni: I would like to propose that libraries be updated to check all the information in the VC. We are at the early stage of VC adoption. If we don't enforce that in standard libraries...
19:22:17 <brent> ack KevinDean
19:22:37 <manu_> KevinDean: In answer to question about why have resources  you don't reference... gernreric credential could have image, you're not interested in image, jut want name and address.
19:22:37 <dlongley> +1 KevinDean
19:22:43 <brent> ack decentra_
19:23:16 <denkeni> I propose discussing the boundary of safety boundary. To me, vc standard should be self-consistent in terms of chekcimg
19:23:29 <KevinDean> decentra_: My question is, should we support issuing credentials that some verifiers may not be able to verify? Should we allow verifiers to not verify related resources? I will not block resolution.
19:23:54 <denkeni> …integrity of all information within the vc itself. That’s a great security improvement.
19:23:56 <KevinDean> Brent: Current proposal is as above.
19:24:18 <shigeya> +1 decentra_
19:24:19 <KevinDean> ...Other language includes "if the verifier makes use of the resource...".
19:24:27 <manu_> q+ to suggest we could run two proposals?
19:24:31 <denkeni> If we don’t, libraries developers out there might not check it at all.
19:24:34 <manu_> q-
19:24:39 <KevinDean> bigbluehat: Revision proposed.
19:25:03 <dmitriz> @decentra_ - re issuing credentials that some verifiers may not be able to verify -- that happens ALL the time though. for example, if a verifier just doesn't support the signature algorithm. can't verify.
19:25:15 <denkeni> …that’s for the safety of the standard, for the rest of the world.
19:25:48 <shigeya> @dmitriz I don't think that is the normal case.
19:25:59 <ivan> +1
19:26:04 <GregB> +1
19:26:14 <dmitriz> +1
19:26:21 <pauld_gs1> "a related resource property" or "the related resource property"?
19:26:28 <KevinDean> Brent: If there's language that would change your -1 vote, let us know.
19:26:36 <Isaac> Isaac has joined #vcwg
19:26:43 <dmitriz> it should be 'a', yeah
19:26:45 <KevinDean> +1 to "a" instead of "the".
19:26:52 <pauld_gs1> +1
19:27:02 <Jay> +1
19:27:15 <denkeni> +1
19:27:16 <brent> PROPOSAL: add the following text to VCDM 2.0 to address DI Issue 272: If a verifier makes use of a resource listed in a relatedResource property, it MUST check the content integrity of the resource as specified in a relatedResource entry.
19:27:19 <manu_> +1
19:27:20 <decentra_> +1
19:27:21 <wes-smith> +1
19:27:21 <ivan> +1
19:27:22 <brent> +1
19:27:22 <GregB> +1
19:27:22 <bigbluehat> +1
19:27:22 <KevinDean> +1
19:27:22 <dlongley> +1
19:27:25 <denkeni> +1
19:27:26 <Jay> +1
19:27:26 <dmitriz> +1
19:27:27 <pauld_gs1> +1
19:27:28 <shigeya> +1
19:27:37 <Wip> +1
19:27:45 <bumblefudge> +1
19:28:23 <selfissued> 0
19:28:28 <bumblefudge> i kinda liked "activate" but that can always be a followup PR if anyone wants to bikeshed
19:28:28 <brent> RESOLVED: add the following text to VCDM 2.0 to address DI Issue 272: If a verifier makes use of a resource listed in a relatedResource property, it MUST check the content integrity of the resource as specified in a relatedResource entry.
19:28:47 <KevinDean> Manu: I will raise a PR for this.
19:29:03 <KevinDean> Brent: It's lunchtime.
19:29:20 <gkellogg> gkellogg has joined #vcwg
19:29:26 <KevinDean> Manu: There are three proposals related to data integrity to look at tomorrow.
19:29:32 <pauld_gs1> Brent, can you confirm the time for tomorrows meeting?
19:30:01 <Kyle> Kyle has left #vcwg
19:33:02 <gkellogg> gkellogg has joined #vcwg
19:33:46 <steele> steele has joined #vcwg
19:44:05 <steele> steele has joined #vcwg
19:54:06 <dmitriz> dmitriz has joined #vcwg
19:54:46 <gkellogg> gkellogg has joined #vcwg
20:19:54 <gkellogg> gkellogg has joined #vcwg
20:22:25 <gkellogg_> gkellogg_ has joined #vcwg
20:30:22 <gkellogg> gkellogg has joined #vcwg
20:33:58 <rigo> rigo has joined #vcwg
20:46:36 <steele> steele has joined #vcwg
20:48:17 <manu_> manu_ has joined #vcwg
20:49:37 <rigo> rigo has joined #vcwg
20:57:07 <gkellogg> gkellogg has joined #vcwg
21:08:12 <steele> steele has joined #vcwg
21:29:34 <Zakim> Zakim has left #vcwg
21:29:41 <steele> steele has joined #vcwg
21:29:49 <yangsamy> yangsamy has joined #vcwg
22:03:42 <steele> steele has joined #vcwg
22:04:18 <steele> steele has joined #vcwg
22:28:19 <steele> steele has joined #vcwg
23:00:19 <steele> steele has joined #vcwg
23:02:35 <gkellogg> gkellogg has joined #vcwg
23:09:01 <manu_> manu_ has joined #vcwg
23:12:56 <gkellogg_> gkellogg_ has joined #vcwg
23:22:08 <steele> steele has joined #vcwg
23:29:35 <gkellogg> gkellogg has joined #vcwg
23:31:47 <gkellogg> gkellogg has joined #vcwg
23:39:52 <rigo> rigo has joined #vcwg
23:49:46 <manu_> manu_ has joined #vcwg