01:00:44 <gkellogg> gkellogg has joined #vcwg
01:00:57 <gkellogg> gkellogg has joined #vcwg
01:01:55 <rigo> rigo has left #vcwg
01:16:17 <gkellogg> gkellogg has joined #vcwg
01:21:36 <gkellogg_> gkellogg_ has joined #vcwg
01:37:16 <gkellogg> gkellogg has joined #vcwg
01:53:42 <gkellogg> gkellogg has joined #vcwg
02:11:43 <gkellogg> gkellogg has joined #vcwg
02:33:02 <gkellogg> gkellogg has joined #vcwg
03:50:07 <gkellogg> gkellogg has joined #vcwg
04:01:57 <gkellogg> gkellogg has joined #vcwg
04:20:11 <gkellogg> gkellogg has joined #vcwg
04:38:04 <gkellogg> gkellogg has joined #vcwg
04:57:20 <gkellogg> gkellogg has joined #vcwg
05:00:25 <gkellogg_> gkellogg_ has joined #vcwg
05:02:57 <gkellogg> gkellogg has joined #vcwg
05:19:44 <gkellogg> gkellogg has joined #vcwg
05:24:07 <manu_> manu_ has joined #vcwg
05:36:37 <gkellogg> gkellogg has joined #vcwg
05:53:33 <gkellogg> gkellogg has joined #vcwg
06:00:23 <gkellogg_> gkellogg_ has joined #vcwg
06:03:58 <gkellogg> gkellogg has joined #vcwg
06:20:20 <gkellogg> gkellogg has joined #vcwg
07:35:54 <gkellogg> gkellogg has joined #vcwg
07:53:03 <gkellogg> gkellogg has joined #vcwg
08:04:58 <gkellogg> gkellogg has joined #vcwg
08:21:59 <gkellogg> gkellogg has joined #vcwg
08:39:54 <gkellogg> gkellogg has joined #vcwg
09:56:11 <gkellogg> gkellogg has joined #vcwg
10:12:05 <gkellogg> gkellogg has joined #vcwg
10:30:41 <gkellogg> gkellogg has joined #vcwg
10:47:45 <gkellogg> gkellogg has joined #vcwg
11:06:24 <gkellogg> gkellogg has joined #vcwg
11:22:38 <gkellogg> gkellogg has joined #vcwg
11:40:21 <gkellogg> gkellogg has joined #vcwg
11:56:39 <gkellogg> gkellogg has joined #vcwg
12:13:16 <gkellogg> gkellogg has joined #vcwg
12:29:29 <gkellogg> gkellogg has joined #vcwg
13:36:07 <gkellogg> gkellogg has joined #vcwg
13:59:46 <manu_> manu_ has joined #vcwg
14:33:56 <TallTed> RRSAgent, draft minutes
14:33:57 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-vcwg-minutes.html TallTed
14:34:04 <TallTed> RRSAgent, bye
14:34:04 <RRSAgent> I see no action items
15:48:52 <RRSAgent> RRSAgent has joined #vcwg
15:48:52 <RRSAgent> logging to https://www.w3.org/2024/09/27-vcwg-irc
15:48:55 <Zakim> RRSAgent, make logs Public
15:48:57 <Zakim> please title this meeting ("meeting: ..."), ivan
15:49:02 <mandyv> mandyv has joined #vcwg
15:49:10 <ivan> Meeting: Verifiable Credentials Working Group F2F at TPAC, 2nd day
15:49:10 <ivan> Date: 2024-09-27
15:49:10 <ivan> Agenda: https://www.w3.org/events/meetings/e72511c0-04a5-495d-87d9-48f473667403/
15:49:10 <ivan> chair: brent
15:49:11 <ivan> ivan has changed the topic to: Meeting Agenda 2024-09-26: https://www.w3.org/events/meetings/e72511c0-04a5-495d-87d9-48f473667403/
15:49:20 <ivan> present+
15:50:02 <ivan> present+ manu, kdean
15:50:29 <ivan> present+ wip, shigeya
15:50:41 <gkellogg> gkellogg has joined #vcwg
15:50:43 <ivan> present+ brent
15:51:47 <mandyv> present+
15:54:01 <ivan> present+ jenniem
15:54:13 <brent> brent has joined #vcwg
15:54:26 <ivan> guest+ plh
15:55:12 <bigbluehat> bigbluehat has joined #vcwg
15:57:03 <ivan> present+ selfissued
15:57:16 <brent> present+
15:58:54 <mandyv> scribe+
15:59:12 <Wip> Wip has joined #vcwg
15:59:15 <JennieM> JennieM has joined #vcwg
15:59:15 <manu> present+
16:00:06 <Wip> present+
16:00:06 <bigbluehat> present+
16:00:35 <DavidC> DavidC has joined #vcwg
16:00:42 <DavidC> present+
16:01:15 <wes-smith> wes-smith has joined #vcwg
16:01:15 <mandyv> brent: going over agenda, JOSE COSE discussion this morning, controller document discussion before lunch
16:01:28 <mandyv> after lunch hours for every other rec track document
16:01:54 <ivan> present+ joe
16:01:55 <mandyv> ... I think we're at 9, that's insane and a lot
16:02:01 <manu> q+
16:02:12 <mandyv> ... our day ends with looking at use cases doc, things have been happening there
16:02:12 <ivan> s/after/...after/
16:02:47 <DavidC> I need a passcode to enter the Zoom meeting
16:02:49 <mandyv> ... final session is joint session with security group for feedback and security reviews to see what they have to say.
16:02:53 <manu> q+ selfissued
16:02:55 <dlongley> present+
16:03:09 <brent> ack manu
16:03:10 <JennieM> JennieM has joined #vcwg
16:03:14 <decentralgabe> decentralgabe has joined #vcwg
16:03:15 <mandyv> selfissued: Jeff ??? coming this afternoon
16:03:22 <decentralgabe> present+
16:03:23 <mandyv> manu: 3 proposals from yesterday
16:03:27 <JennieM> present+
16:03:27 <ivan> s/???/Yaskin/
16:03:38 <mandyv> brent: during every other rec track
16:03:40 <SinYong> SinYong has joined #vcwg
16:03:42 <selfissued> selfissued has joined #vcwg
16:03:46 <brent> ack selfissued
16:03:49 <selfissued> present+
16:03:58 <JoeAndrieu> JoeAndrieu has joined #vcwg
16:04:12 <plh> plh has joined #vcwg
16:04:24 <KevinDean> KevinDean has joined #vcwg
16:04:27 <KevinDean> present+
16:04:35 <JoeAndrieu> present+
16:04:45 <mandyv> ... anyone who did not get to introduce themselves yesterday
16:04:47 <Sheri_B-H> Sheri_B-H has joined #vcwg
16:04:53 <mandyv> Josh Thomas from Ignite Retail
16:05:03 <JoeAndrieu> q+
16:05:06 <mandyv> Filippe, staff, Ivan told me to be here
16:05:07 <TallTed> present+
16:05:19 <Sheri_B-H> present+
16:05:25 <mandyv> JoeAndrieu: From legendary
16:05:29 <ivan> s/Filippe/Philippe/
16:05:34 <brent> ack JoeAndrieu
16:05:34 <Susan> Susan has joined #VCWG
16:05:45 <DavidC> ivan thankyou. It works. But I am the only person in the Zoom meeting.
16:05:50 <mandyv> brent: jump into JOSE COSE
16:07:05 <vkuntz> vkuntz has joined #vcwg
16:07:12 <vkuntz> present+
16:07:26 <brent> slide deck https://docs.google.com/presentation/d/1rjt4fgajEqqQzdF72JUeh6_h4gICQanExOfcoW4l0GM/edit#slide=id.g2a8b040676_0_27
16:08:41 <brent> q?
16:09:01 <Isaac> Isaac has joined #vcwg
16:09:13 <mandyv> decentralgabe: hoping for a fewer number of proposals, giving history on media types and considerations on what we should do
16:09:32 <mandyv> [overview slide]
16:09:58 <mandyv> [history slide]
16:10:04 <cc> cc has joined #vcwg
16:10:15 <shiyu> shiyu has joined #vcwg
16:11:30 <Kyle> Kyle has joined #vcwg
16:12:00 <jthomas> jthomas has joined #vcwg
16:12:05 <mandyv> ... media type for core data model /vc /vp are registered
16:12:52 <mandyv> ... conflict with IETF spec for ??? have their own model that wants to use a conflicting type, we cannot register the same thing without meeting with them, participating but have not reached consensus
16:12:57 <jthomas> present+
16:12:59 <mandyv> ... currently at a stalemate
16:13:37 <mandyv> ... as things stand, core data model has /vc and /vp, when securing the data model what media types should there be, not submitted for registration yet
16:14:19 <mandyv> ... IETF JWT has been there for a long time, COSE, why not use CBOR web token? Because they use CBOR maps, would not be a good fit
16:14:46 <mandyv> ... COSE is the right media type for securing CBOR representations of the data model
16:15:05 <mandyv> ... SD-JWT, hoping to be on standards track but is not registered
16:15:18 <mandyv> selfissued: the wg completed last call
16:15:29 <mandyv> brent: right at the cusp of it being a standard'
16:16:06 <mandyv> decentralgabe: SD-JWT, no guarantee that it will be accepted or they will agree to go forward
16:16:08 <brent> q?
16:16:11 <manu> q+
16:16:16 <brent> ack manu
16:16:53 <mandyv> manu: worth highlighting, this conflict is not new, a number of members try to use the media type and re-using the word VC to mean something different, data models are incompatible and causing confusion
16:17:02 <cc> cc has joined #vcwg
16:17:02 <dlehn> present+
16:17:07 <mandyv> ... customer believe IETF work is compatible with W3C VC
16:17:17 <dlongley> +1 that the confusion extends far beyond media types because of the use of "VC" to mean something other than what this group has created and produced
16:17:51 <mandyv> ... discussion with people on internet draft, please differentiate from W3C work, but instead it looks like the plan is to push VC + SD-JWT and retroactively say it is in production
16:18:13 <mandyv> ... I view that as problematic behavior, coordination is needed between WGs and editors
16:18:27 <mandyv> ... this issue has been happening for a year
16:18:41 <mandyv> decentralgabe: is it formal objection Friday?
16:19:21 <mandyv> ... current state of VC JOSE COSE, use static types, was proposal before types were accepted in IANA, if we do not find consensus this is the state of things
16:19:58 <mandyv> ... dave longley suggested using ???, no consensus, but wanted to ensure it was brought up
16:20:08 <mandyv> selfissued: I blocked it, but I will support it
16:20:36 <mandyv> decentralgabe: we could not issue any new types, diplomatic world
16:20:44 <Wip> s/???/vc-env to represent a enveloping format/
16:21:11 <mandyv> ... easy to implement, devs already know these, no new media types, this is not an obvious choice
16:21:47 <mandyv> ... in a perfect world, if there was no IETF, we could register the types we think are best and make the most sense
16:22:04 <mandyv> ... JWT, SD-JWT, COSE
16:22:04 <DavidC> q+
16:22:35 <mandyv> ... clear and unambiguous, gives good foundation to secure core data model, best estimate is 2 formal objections and tension
16:22:56 <mandyv> ... add note that we should not be afraid of formal objections, "what merit does their objection have?"
16:23:45 <mandyv> ... imperfect world, where we try to do the previous proposal, we could register the types that are not in conflict, puts ??? in awkward spot, but gives us time to move forward to figure stuff out with IETF folks
16:24:25 <mandyv> ... we are able to register the types we know are best, enable us to leave CR sooner, cons are if we go forward and cannot resolve conflict, we are in a bad spot
16:24:51 <plh> q+
16:25:12 <mandyv> ... in summary, we want to comply with best practices, avoid formal objections, if we get them we want to have thought through how to respond, good relationship with IETF, and move out of CR asap
16:25:13 <manu> q+
16:25:28 <denkeni> present+
16:25:30 <selfissued> q+
16:25:35 <mandyv> brent: goal is group consensus around a proposal
16:26:05 <mandyv> ... will any of the proposals be acceptable, will you formally object, and if none are acceptable, come with a new proposal
16:26:14 <shiyu> shiyu has joined #vcwg
16:26:20 <jets> present+ Brian_McManus
16:26:32 <mandyv> ... gabe did a good job outlining all of the options
16:26:33 <brent> q?
16:26:41 <brent> ack DavidC
16:27:08 <manu> -1 for prefixing with "w3c"
16:27:12 <dlongley> would -1 that :)
16:27:16 <mandyv> DavidC: propose a meta-level proposal, everywhere it says VC or VP, we pre-fix with W3
16:27:26 <mandyv> ... differentiates that we are not part of the IETF
16:27:38 <JoeAndrieu> -1
16:27:39 <brent> ack plh
16:27:39 <manu> We don't put "w3c" in front of any other media type that W3C has registered, to my knowledge.
16:28:01 <mandyv> plh: prior to CR, send email to media types ???, my guess is that did not happen
16:28:06 <mandyv> manu: it did happen
16:28:13 <brent> ack manu
16:28:13 <mandyv> brent: not for new media types
16:28:27 <mandyv> manu: supportive for 3 and 3.5, although 3.5 kicks the can down the road a bit
16:28:35 <plh> --> https://www.w3.org/2020/01/registering-mediatypes Register an Internet Media Type for a W3C Spec
16:28:54 <brent> q+
16:28:57 <mandyv> ... strong opposition to 2, it avoids the more fundamental problem of misbehavior in the ecosystem
16:29:21 <mandyv> ... it will harm work at W3C and IETF, confusion around VCs and such will lead to business and devs being confused
16:29:41 <mandyv> ... proposal 2 is just avoiding having that discussion
16:29:57 <plh> s/media types ???/media-types@iana.org/
16:30:07 <mandyv> ... media type is a thing now in the wg at IETF, it does not convey the same semantics as the W3C spec does
16:30:23 <bigbluehat> s/proposal 2 is just/proposal 1 is just
16:31:20 <mandyv> ... propsal 3 is the ideal way forward, it's not incompatible with what IETF wants to do, we will share the media type with them, content type will be different but typ and media will be the same
16:31:36 <mandyv> ... 3 is workable,
16:31:39 <brent> ack selfissued
16:32:03 <brent> q+ to talk about chair vs personal view
16:32:42 <mandyv> selfissued: respond to comment about others are using the term VC, it's become a generic term, mdoc and jwts are VCs, family of specifications in open ID foundation that use VC as generic
16:33:09 <JoeAndrieu> q+ to point out that the dilution of verifiable credentials is an intentional attack on the meaning of our work
16:33:16 <mandyv> ... using in EU wallet deployments, whether or not it only applies to this work is a ship that has sailed
16:33:29 <dlongley> -1 to helping other groups use our branding, we don't control others surely, but that doesn't mean we have to help other groups that attempt to reuse our branding and efforts to do something else -- that confuses the market; it would be fine if our work was compatible with it.
16:33:32 <mandyv> ... we should declare victory and not say people are misbehaving by using the VC term
16:33:57 <mandyv> ... next topic, to brent, I would support option 0, leaving things the way they are
16:34:31 <mandyv> ... option 1, using envelope, I think VC-LD is better than VC-ENV, willing to drop objection
16:34:54 <mandyv> ... finally, I would oppose conflict with OAuth wg
16:35:44 <mandyv> ... we were proposing VC+LD + ?, there was no conflict, we changed our mind to not continue multi+ media types, the reason there is conflict is we changed our mind
16:36:07 <mandyv> ... finally there is no concept of ??? media type, we can use any prefix and + we want
16:36:20 <bigbluehat> s/??? media type/base media type
16:36:27 <mandyv> ... even if there were a base media type notion there is not a conflict
16:36:52 <plh> -1 to not registering media types
16:36:55 <ivan> q?
16:37:02 <wes-smith> wes-smith has joined #vcwg
16:37:02 <mandyv> ... finally I am against proposal 2, as the author of JWT best practices doc, we would not know what is being secured
16:37:15 <manu> q+ to note that we use "application/vc+ld+json", it was always used before, this is misbehavior, and mdoc doesn't re-use verifiable credentials -- a bit revisionist history going on here.
16:37:19 <brent> ack brent
16:37:19 <Zakim> brent, you wanted to talk about chair vs personal view
16:37:35 <dlongley> my understanding is that `cty` says what is being secured (content type)
16:38:01 <mandyv> brent: with my chair hat I have used the words regrettable that if we cannot come to an agreement with IETF that are intending to register ???, that would be a failure of diplomancy
16:38:36 <mandyv> ... personal view is, in light of possibility to different using the cty value, I would be fine moving forward with registering VC+ as the base media type for JOSE COSE
16:38:43 <mandyv> ... in conflict with chair self
16:38:43 <brent> ack JoeAndrieu
16:38:43 <Zakim> JoeAndrieu, you wanted to point out that the dilution of verifiable credentials is an intentional attack on the meaning of our work
16:38:45 <dlongley> +1 to brent, and sorry your selves are in conflict
16:38:53 <plh> q+
16:39:13 <mandyv> JoeAndrieu: in support of 3, IETF is transparent and intentional to grab a term that W3C coined
16:39:22 <mandyv> ... we found VC term to be the right solution
16:39:41 <mandyv> ... some people took the work and the name to go venue shopping to get other features they wanted
16:39:51 <mandyv> ... W3C will not maintain a trademark on VC
16:40:10 <mandyv> ... we should not endorse this behavior, it's undermining our work
16:40:32 <mandyv> ... it is damaging to our collaborations. We've reached out and have not had success moving the needle
16:40:37 <brent> ack manu
16:40:37 <Zakim> manu, you wanted to note that we use "application/vc+ld+json", it was always used before, this is misbehavior, and mdoc doesn't re-use verifiable credentials -- a bit revisionist
16:40:38 <selfissued> selfissued has joined #vcwg
16:40:39 <bumblefudge> bumblefudge has joined #vcwg
16:40:39 <mandyv> ... endorse 3
16:40:41 <Zakim> ... history going on here.
16:40:42 <dlongley> +1 to Joe's comments
16:40:44 <selfissued> present+
16:40:50 <dmitriz> dmitriz has joined #vcwg
16:41:16 <decentralgabe> q+
16:41:42 <mandyv> manu: respond to selfissued, you said when ??? was suggested, we were doing something different, we had direct interactions and told people it was the same base media type. The base media type exists, there is consensus,
16:42:25 <bigbluehat> s/when ??? was suggested/when `application/vc+ld+json` was suggested
16:42:52 <mandyv> ... +1 what JoeAndrieu just said, this is blatant misbehavior, we are being ignored, where we are being taken advantage of, mdocs are not VCs, they are called mdocs, people are not confused, there is clear separation
16:43:01 <selfissued> q+
16:43:09 <mandyv> ... we have asked IETF to create separation by using different language and media types
16:43:21 <bumblefudge> *cough cough* PLENARY *cough cough*
16:43:42 <mandyv> ... technical argument, proposal 3 is fine from a technical perspective, it has the benefit of letting us share the base media type with IETF
16:43:53 <brent> ack plh
16:44:00 <TallTed> Noting that IETF has declared that *one* `+` is all that is allowed, "base media types" are the part to the left of the `+`. "structured suffixes" are the part to the right of (and indluding) the `+`.
16:44:52 <mandyv> plh: meeting with IETF with lunch yesterday, folks that help with IETF relationship, will bring this issue up with the IETF liason
16:44:54 <plh> --> https://www.w3.org/trademarks/ W3C Trademarks and generic terms
16:45:11 <mandyv> ... on subject of trademark, we claim generic terms, I don't see VC there
16:45:29 <mandyv> ... lastly, the wiki page on VCs says it's W3C
16:45:32 <brent> ack decentralgabe
16:45:52 <mandyv> decentralgabe: speak to VC ???, open ID has re-named to digital credentials
16:45:57 <JoeAndrieu> @Plh Ralph Swick had told me the organization would not defend verifiable credentials as a generic
16:46:03 <mandyv> ... +1 what brent said about cty
16:46:18 <brent> ack selfissued
16:46:25 <JoeAndrieu> @plh (when he was acting CEO)
16:46:25 <mandyv> ... I would like to see us find consensus on proposal 3
16:46:31 <brent> q+ to talk consensus
16:47:02 <brent> ack brent
16:47:02 <Zakim> brent, you wanted to talk consensus
16:47:04 <mandyv> selfissued: on VC brand, discussion will not help us move to consensus, we should celebrate people using the term
16:47:26 <mandyv> brent: not hearing clear consensus, but 3 has gotten most comments in it's favor
16:47:48 <selfissued> q+
16:47:53 <mandyv> ... poll for moving forward with proposal 3
16:47:53 <brent> poll: Proposal 3?
16:47:58 <Wip> +1
16:47:59 <manu> +1
16:48:00 <dlongley> +1
16:48:00 <JoeAndrieu> +1
16:48:00 <selfissued> -1
16:48:01 <wes-smith> +1
16:48:03 <JennieM> +1
16:48:03 <dmitriz> +1
16:48:04 <KevinDean> +1
16:48:05 <decentralgabe> +1
16:48:05 <brent> +1
16:48:07 <bigbluehat> +1
16:48:08 <TallTed> +1
16:48:14 <denkeni> +1
16:48:15 <jets> +1
16:48:27 <bumblefudge> bumblefudge has joined #vcwg
16:48:37 <brent> ack selfissued
16:48:42 <cc> +1
16:48:47 <TallTed> q+
16:48:48 <bigbluehat> q+
16:48:53 <manu> q+
16:49:02 <mandyv> selfissued: knowingly stepping on what others are doing is not collaborative behavior and I cannot support that
16:49:34 <bigbluehat> q-
16:49:44 <mandyv> brent: before going back to q, having a conversation with Brian Campbell, editor of SD-JWT, he helped come up with proposal 3,
16:49:46 <mandyv> ... objected with cty cavet
16:49:50 <brent> ack TallTed
16:49:58 <manu> q-
16:50:27 <mandyv> brent: drafting proposal
16:50:29 <ivan> q+
16:51:00 <mandyv> ivan: I did not fully understand what you said about Brian Campbell's reaction
16:51:18 <manu> q+
16:51:23 <mandyv> ... why is he ok with that when it goes against what the group does?
16:51:31 <dlongley> +1 to just go on record to say that i believe we are pushing back against the very behavior Mike has described.
16:51:34 <brent> ack ivan
16:51:38 <brent> ack manu
16:51:45 <decentralgabe> BC's comment here https://github.com/w3c/vc-jose-cose/issues/282#issuecomment-2289946119
16:51:59 <mandyv> manu: it would allow the IETF to use the same top level media type but they would pick a different value for the cty value
16:52:05 <mandyv> ivan: are they ready for that?
16:52:09 <mandyv> manu: we don't know
16:52:17 <selfissued> I'll look at the spec and see what cty value they're currently using
16:52:17 <gkellogg> gkellogg has joined #vcwg
16:52:35 <mandyv> ... the technical argument is it allows both groups to use the same media type
16:52:49 <mandyv> ... the only thing that would change between the 2 groups is the cty value
16:52:59 <mandyv> ivan: unless they want to claim our cty values
16:53:10 <Wip> q?
16:53:13 <decentralgabe> q+
16:53:38 <plh> q+
16:53:39 <selfissued> https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-05.html currently has no "cty" value
16:53:45 <JoeAndrieu> +1 to continuing communications
16:53:47 <manu> Agree with decentralgabe
16:53:50 <mandyv> decentralgabe: frame that is this proposal passes, we should proceed with trying to register this, but also have a conversation with IETF
16:54:04 <selfissued> They would naturally use application/sd-jwt as their "cty" media type, if they add one
16:54:41 <brent> q?
16:54:45 <brent> q?
16:54:55 <ivan> ack decentralgabe
16:55:03 <brent> ack plh
16:55:26 <mandyv> plh: we will have to elevate the issue to our IETF contacts,
16:55:29 <JennieM> JennieM has joined #vcwg
16:55:36 <TallTed> i/ack TallTed/TallTed: I am pleased to hear selfissued does not support the current IETF behavior of stepping on our work by diluting the meaning of "Verifiable Credential"
16:56:12 <ivan> q+
16:56:29 <brent> ack ivan
16:56:46 <dlongley> +1 to ivan's suggestion
16:56:49 <sven> sven has joined #vcwg
16:56:56 <mandyv> ivan: for outsiders, for the second part, making it clear that this wg intends to use ??? for the cty value
16:56:56 <manu> +1 to ivan
16:57:06 <denkeni> +1 to ivan to make it clear
16:57:43 <brent> PROPOSAL: For VC-JOSE-COSE, we will proceed with a request to register application/vc+jwt, application/vp+jwt, application/vc+cose, application/vp+cose, application/vc+sd-jwt, and application/vp+sd-jwt. We will note in particular that the cty property is the point of differentiation for others that may wish to use identical media types. This group intends to use application/vc and application/vp as the cty values.
16:57:45 <manu> +1
16:57:48 <decentralgabe> +1
16:57:48 <JoeAndrieu> +1
16:57:48 <TallTed> +1
16:57:48 <DavidC> 0
16:57:49 <dlongley> +1
16:57:49 <denkeni> +1
16:57:49 <selfissued> -1
16:57:50 <dmitriz> +1
16:57:50 <brent> +1
16:57:53 <bigbluehat> +1
16:57:53 <ivan> s/???/`application/vc` and `application/vp`/
16:57:56 <shigeya>  0
16:57:58 <Wip> +1
16:57:58 <JennieM> +1
16:58:01 <ivan> +1
16:58:03 <wes-smith> +1
16:58:55 <mandyv> brent: selfissued: will you formally object
16:59:05 <jets> +1
16:59:07 <mandyv> selfissued: I am undecided pending discussion with others
16:59:08 <jthomas> +
16:59:20 <brent> RESOLVED: For VC-JOSE-COSE, we will proceed with a request to register application/vc+jwt, application/vp+jwt, application/vc+cose, application/vp+cose, application/vc+sd-jwt, and application/vp+sd-jwt. We will note in particular that the cty property is the point of differentiation for others that may wish to use identical media types. This group intends to use application/vc and application/vp as the cty values.
16:59:20 <mandyv> brent: calling this resolved
16:59:28 <mandyv> ... who will be the voice of the group?
16:59:35 <mandyv> decentralgabe: I can do that
16:59:42 <Kyle> Kyle has joined #vcwg
16:59:48 <mandyv> brent: decentralgabe will serve as the voice of the group, talk to him about it
16:59:48 <plh> RRSAgent, generate minutes
16:59:50 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-vcwg-minutes.html plh
17:00:28 <mandyv> ... comments have been made that have not facilitated consensus, individuals can use their voice, but make it clear they are not speaking for the group
17:00:47 <ivan> i/brent: going over agenda/topic: VC JOSE COSE Media types/
17:00:50 <shigeya> +1 brent (for record)
17:00:58 <mandyv> ... I appreciate the calm and sensibility, it is valuable that we can have differences of opinion and still be civil,
17:01:10 <manu> q+ to note other items w/ VC JOSE COSE
17:01:13 <brent> Topic: more VC JOSE COSE
17:01:16 <mandyv> selfissued: we should merge a PR
17:01:27 <brent> ack manu
17:01:27 <Zakim> manu, you wanted to note other items w/ VC JOSE COSE
17:01:29 <selfissued> https://github.com/w3c/vc-jose-cose/pull/292
17:01:34 <mandyv> brent: is there more you would like feedback from the group on
17:01:48 <Kyle_> Kyle_ has joined #vcwg
17:03:02 <mandyv> manu: looking at vc-jose-cose spec, thought I requested language around selective disclosure and things you have to keep a look out for, one thing being commentary around, if you use sd-jwt and the issuer uses things it wants to make sure the verifier always checks, things like related resources for contexts are always selectively disclosed
17:03:14 <mandyv> ... I think we do need a vc-jose-cose spec
17:03:25 <decentralgabe> https://github.com/w3c/vc-jose-cose/pull/288/files
17:03:27 <mandyv> ... I didn't see those statement in the spec, can the editors speak to that?
17:03:34 <dlongley> +1 to tell issuers to consider what needs to be mandatory to disclose and highlight some important items from the VCDM
17:03:55 <mandyv> decentralgabe: issue 285
17:04:05 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/285
17:04:08 <decentralgabe> q+
17:04:14 <mandyv> brent: let's talk about this issue
17:04:16 <brent> ack decentralgabe
17:04:33 <manu> q+ to note things to consider.
17:04:37 <mandyv> decentralgabe: I might have missed something when addressing this issue, we should re-open it to add language
17:04:47 <mandyv> brent: I will re-open the issue
17:05:05 <mandyv> decentralgabe: preparing PR for that
17:05:16 <brent> ack manu
17:05:16 <Zakim> manu, you wanted to note things to consider.
17:05:51 <ivan> q+
17:06:03 <mandyv> manu: to add detail, I think the things that need to be considered are: we need special language about selectively disclosing the @context field, whether or not to expose type value, changes around credential status
17:06:26 <ivan> s/@context/`@context`/
17:06:26 <mandyv> ... our org is not looking very closing at this stuff, we have not done an implementation, hopefully someone else is paying really close attention
17:06:50 <mandyv> .... sd-jwt is a ??? and it makes assumptions about the data model
17:07:11 <mandyv> ... sd-jwt by itself is unaware of the things that should always be selectively disclosed
17:07:25 <TallTed> q+
17:07:25 <dlongley> +1 to Manu's general concerns
17:07:29 <brent> ack ivan
17:07:31 <pauld_gs1> pauld_gs1 has joined #vcwg
17:07:34 <pauld_gs1> present+
17:07:40 <mandyv> ... it feels like there is more work to be done, but because we're not doing an implementation we cannot see the trip wires
17:08:11 <dlongley> q+
17:08:16 <mandyv> ivan: my memory is related resources must be checked, what must be used if all?
17:08:19 <brent> ack TallTed
17:08:21 <TallTed> https://github.com/w3c/vc-jose-cose/pull/304#pullrequestreview-2334075128
17:09:20 <manu> q+ to speak to how its used in CA DMV.
17:09:22 <mandyv> TallTed: link to comment in a PR that was merged, it says the jwt claim names vc and vp must not be present in claim set, this doc is jose-cose, not jwt, so we can't be making that restriction
17:09:24 <selfissued> q+
17:09:59 <brent> subtopic: related resource
17:10:06 <brent> ack dlongley
17:10:41 <mandyv> dlongley: respond to ivan: this issue with selective disclosure is not about if they are using related resources, but if the issuer wants to use them they need to make it mandatory,
17:10:46 <Jem> Jem has joined #vcwg
17:10:57 <mandyv> ... since jwt does not sign the quads, it is important that issuers are aware of it and make it mandatory
17:11:04 <brent> ack manu
17:11:04 <Zakim> manu, you wanted to speak to how its used in CA DMV.
17:11:50 <mandyv> manu: repsonse to TallTed: putting CA DMV vendor hat on, we use vc and vp claim types in ca dmv implementation, we had to make the decision 2 years ago, we have a plan to upgrade, removing that in vc 2.0 is ok
17:11:58 <TallTed> s/must not be present in claim set/must not be present in JWT claim set/
17:11:59 <brent> ack selfissued
17:12:06 <mandyv> ... I believe CA DMV wants to move away so removal is ok
17:12:08 <TallTed> q+
17:12:29 <mandyv> selfissued: not new language, this was in first CR, the reason it is there is vc-jwt 1.1 which defined the use of claims
17:12:55 <brent> ack TallTed
17:12:57 <mandyv> ... that caused duplication of data model contect into the envelope, editorally this showed up as new text, but it's because it was moved
17:13:30 <selfissued> Our first CR https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/ includes "The JWT Claim Names vc and vp MUST NOT be present."
17:13:36 <mandyv> TallTed: I don't care how long ago it was approved, it is putting a restriction on jwt in sd-jwt, you cannot restrict jwts within sd-jwts
17:13:36 <selfissued> This is not new text
17:13:41 <selfissued> q+
17:13:45 <brent> ack selfissued
17:13:53 <TallTed> q+
17:14:33 <mandyv> selfissued: as the author of jwt (with others) and many spec that profile jwt, it is fully the intent of the jwt spec to be profiled, it is up to profile specs such as this one, it is up to the spec to say what claims must be used, what are optional
17:15:04 <mandyv> brent: what TallTed said cleared this up, he said you can't limit things, but he clarified that it's not limiting for sd-jwts, but jwts ???
17:15:06 <brent> ack TallTed
17:15:31 <mandyv> TallTed: if I have to object I will
17:15:49 <mandyv> brent: next step is for selfissued to raise a PR
17:16:20 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/292
17:16:44 <mandyv> brent: PR raised by selfissued, comments by decentralgabe,
17:17:17 <mandyv> decentralgabe: spec was unclear about detached payloads, this PR adds that language,
17:17:25 <mandyv> ... they allow for detached payloads, so should we
17:17:30 <selfissued> q+
17:17:58 <brent> ack selfissued
17:17:58 <mandyv> ... my company makes use of detached payloads, it's more efficient to store the signature separately
17:18:23 <manu> q+ to note that if we're profiling, we should profile to use cases for VCs... are we supporting detached payloads for other items?
17:18:46 <mandyv> selfissued: as discussed in the issue, the jwt spec and the cose spec permit detached payloads and we are using them normatively, if we do nothing they are allowed, if we merge this PR it doesn't change the meaning but it does explicitly say detached payloads are allowed
17:19:01 <brent> ack manu
17:19:01 <Zakim> manu, you wanted to note that if we're profiling, we should profile to use cases for VCs... are we supporting detached payloads for other items?
17:19:01 <mandyv> ... ok to close or merge, would object to change that would try to inhibit the use
17:19:56 <mandyv> manu: this came about because the default example changed, will note that I oppose this because it's the first time we're talking about using detached payloads for VCs
17:20:08 <mandyv> ... I have an opinion but want to see what the group has to say
17:20:24 <mandyv> as selfissued said, if it's allowed then it's allowed, and find decentralgabe use case compelling
17:20:29 <decentralgabe> q+
17:20:46 <mandyv> ... concerned about hexadecimal signature in example, would rather follow the same format as other examples
17:21:02 <mandyv> ... waiting on feedback from decentralgabe
17:21:05 <brent> ack decentralgabe
17:21:28 <manu> q+
17:21:30 <mandyv> decentralgabe: feel like there was regression in code, example should show full payload, it may be useful to show examples for attached and detached
17:21:32 <brent> ack manu
17:21:49 <selfissued> q+
17:22:02 <mandyv> manu: concerned about detached payloads were viewed negatively and used as an example of the group not knowing what it is doing
17:22:18 <ivan> present+ dmitriz
17:22:22 <mandyv> ... not technical concern, but do we want to invite criticism back in?
17:22:54 <mandyv> ... incubate in a group. Alternative is to write it up now, but concern without implementations
17:23:19 <mandyv> brent: proposal is to close this PR now, raise another one where the examples are only attached payloads
17:23:30 <brent> ack selfissued
17:23:38 <mandyv> manu: clear up the example to show full payloads
17:23:51 <mandyv> selfissued: if we close the PR we should close the issue
17:24:21 <mandyv> ... if we get other criticism about detached payloads I will take it on, they fail safe because of crypto
17:24:34 <mandyv> brent: but you are not disagreeing
17:24:37 <mandyv> selfissued: yes
17:24:57 <dlongley> +1 detached payloads are fine, signatures fail safe if the payload doesn't match
17:25:02 <mandyv> brent: anyone who would disagree about closing this PR and issue?
17:25:03 <cc> cc has joined #vcwg
17:25:16 <mandyv> brent: no opposistion
17:25:26 <mandyv> brent: end session, be back at 11
17:26:03 <mandyv> RRSAgent, draft minutes
17:26:04 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-vcwg-minutes.html mandyv
17:26:10 <Kyle_> Kyle_ has left #vcwg
17:55:51 <gkellogg> gkellogg has joined #vcwg
17:57:52 <JennieM> JennieM has joined #vcwg
17:58:23 <dmitriz> dmitriz has joined #vcwg
17:58:38 <brent> brent has joined #vcwg
18:00:10 <selfissued> selfissued has joined #vcwg
18:00:16 <selfissued> present+
18:00:35 <KevinDean> KevinDean has joined #vcwg
18:00:47 <wes-smith> wes-smith has joined #vcwg
18:00:50 <wes-smith> scribe+
18:02:50 <wes-smith> Brent: let's get started, we will start by talking about controller document
18:03:00 <mandyv> mandyv has joined #vcwg
18:03:17 <sven> sven has joined #vcwg
18:03:21 <shigeya> present+
18:03:41 <wes-smith> Brent: in controller document we have gotten feedback from PING and TAG, Jeff Yasskin will be here to discuss TAG, we can discuss the privacy review now
18:04:00 <JoeAndrieu> JoeAndrieu has joined #vcwg
18:04:06 <KevinDean> present+
18:04:06 <JennieM5> JennieM5 has joined #vcwg
18:04:16 <brent> Topic: Controller Document
18:04:28 <JennieM7> JennieM7 has joined #vcwg
18:04:33 <laurens> laurens has joined #vcwg
18:04:35 <JoeAndrieu> present+
18:04:38 <laurens> present+
18:04:44 <brent> subtopic: https://github.com/w3c/controller-document/issues/93
18:04:46 <wes-smith> ... the issue that was raised is issue 93
18:05:02 <wes-smith> ... this is a response from Nick Doty of the privacy group, going to have it on the screen for folks to read through
18:05:17 <wes-smith> ... this is the privacy review, as you read, think about what specific issues need to be raised in order to address the concerns that were brought up
18:05:27 <wes-smith> ... additionally, what are we going to do to address those issues
18:05:36 <ivan> present+ pchampin
18:05:52 <wes-smith> ... for those of you just joining us, we are looking at issue 93, the PING review of the controller document spec
18:06:05 <manu> manu has joined #vcwg
18:06:08 <wes-smith> ... a question for the group is, what issues should be raised to track the concerns here, and what are we going to do about them
18:06:08 <ivan> present+ jyasskin
18:06:09 <brent> q?
18:06:09 <manu> q+
18:06:13 <brent> ack manu
18:06:34 <JennieM> JennieM has joined #vcwg
18:07:38 <wes-smith> manu: I worked on an editor's response to PING, in general PING had good feedback, at a high level there was a concern about the specification being fairly generic, they did not understand the need for something like this. They said it was so abstract it was hard to understand use cases. The use cases here are similar to DID use cases, just with
18:07:38 <wes-smith> URLs instead of DIDs.
18:08:38 <wes-smith> ... Pointing to the DID use case could help. The review mentioned that it would be a lot of work to profile this document, and it's kind of hard to reason about the privacy properties of the document. We did mention that the document is largely about publishing crypto keys, there is a new PR that adds service descriptions to the document, but we
18:08:38 <wes-smith> mention that the main reason controller document exists is because vc-jose-cose spec wanted something that did what DID documents did but without DIDs
18:08:48 <wes-smith> ... we mention that DID core WG is planning on using this document as well.
18:08:51 <ivan> q+
18:09:18 <wes-smith> ... Largely the response was that the privacy concerns are fairly limited based on the limited set of things that the document is supposed to be doing, as it is largely around crypto  key communication, extensions largely out of scope
18:10:04 <wes-smith> ... they mentioned they were interested in pairwise identifiers, might be good to couple that with W3C language around the origin model of the web, I noted that we do talk about it but could expand the section around identifier-based correlation risks to talk about the Web's origin model. This has been a regular request from groups to talk about
18:10:04 <wes-smith> the Web's origin based security/privacy model.
18:10:08 <dezell> dezell has joined #vcwg
18:10:40 <wes-smith> ... They also noted that we say you shouldn't store personal data, but PING suggested that crypto keys are personal data, so a clarification that we meant name, address, etc, rather than crypto material.
18:10:51 <Susan> Susan has joined #VCWG
18:10:53 <babygazelle> present+
18:10:57 <wes-smith> ... Finally, there was a question around the difference between "id" and "controller", we have 2 issues open to discuss that.
18:11:18 <wes-smith> ... A lot of the commentary was editorial in nature, I think that we're going to wait to hear from Nick or PING on exactly what he would like to see done.
18:11:50 <wes-smith> ... We can raise issues on additional language, modification of existing language, etc. I didn't see a request for a fundamental design change in here, will want to clarify that. I did ask about these being largely editorial changes and for PING to let us know if that is not the case.
18:12:10 <brent> ack ivan
18:12:12 <denkeni> +present
18:12:13 <wes-smith> ... Nick and the PING will look at this, do another round of comments, and either raise issues or we will raise issues on their behalf.
18:12:30 <jets> present+ Brian_McManus
18:13:17 <JoeAndrieu> q+ to open the bikeshedding
18:13:23 <manu> q+ to note that it's service descriptions as well... and noted that it's a "resource document" :)
18:13:27 <wes-smith> Ivan: I must admit, when we started to work on this document, I really had difficulty getting my head around the naming. "Controller Document" does not fit what is there, as the emphasis of this document is to store references to crypto key material and metadata. That's all we are doing. I wonder whether we should rename the document to make it
18:13:27 <wes-smith> clear what the document is talking about. I know there is a PR on the service. We will come back to this.
18:13:29 <resakai> resakai has joined #vcwg
18:13:57 <wes-smith> Brent: A couple more minutes on this topic then will move to another issue.
18:13:58 <brent> ack JoeAndrieu
18:13:58 <Zakim> JoeAndrieu, you wanted to open the bikeshedding
18:14:01 <selfissued> q+
18:14:10 <decentra_> decentra_ has joined #vcwg
18:14:32 <brent> zakim, close the queue
18:14:32 <Zakim> ok, brent, the speaker queue is closed
18:14:39 <wes-smith> JoeAndrieu: Advocating taking the time for bike shedding, at one point this was called something else, it was framing the conversation around something that should be separated into VCs, we already have the idea that controller name is problematic, but we haven't taken the time to fix it
18:14:54 <brent> ack manu
18:14:54 <Zakim> manu, you wanted to note that it's service descriptions as well... and noted that it's a "resource document" :)
18:15:06 <Isaac> Isaac has joined #vcwg
18:15:12 <pchampin> pchampin has joined #vcwg
18:15:14 <wes-smith> manu: we have talked about renaming it before and failed to find a better name, I suggested that this was a resource on the web, everyone hated that
18:15:23 <wes-smith> ... it is expressing key information but could be expressing anything else
18:15:27 <wes-smith> Ivan: let's not go there
18:15:37 <JoeAndrieu> q+ to say it SHOULD NOT say anything about the DID subject
18:16:02 <wes-smith> manu: just saying we had that discussion, in the DID WG we discussed how it did not have service descriptions in it, based on a request by that WG I raised a PR to add service descriptions into controller document, no longer just a bag of keys, now more general tool to engage with the subject
18:16:07 <brent> ack selfissued
18:16:25 <wes-smith> selfissued: yeah, we have tried to change the name before, I am repeating Manu, but nobody has come up with a better name, people know this name, it is a done deal
18:16:32 <wes-smith> Brent: moving to issue 94
18:16:43 <brent> subtopic: https://github.com/w3c/controller-document/issues/94
18:16:43 <wes-smith> ... which is our TAG review issue
18:16:55 <wes-smith> ... I am happy to frame this convo however you would like
18:17:30 <manu> q+
18:17:37 <brent> zakim, open the queue
18:17:37 <Zakim> ok, brent, the speaker queue is open
18:17:58 <jyasskin> I'm Jeffrey Yasskin, on the TAG, ready to talk about issue 94.
18:18:25 <wes-smith> manu: first of all, thank you very much for the review, really appreciate it, I think that at a high level the TAG had a number of concerns around the document and some of the functionality in there. Some of it seemed to be more general uneasiness around some of the stuff that we are doing, and there were some very specific questions towards the
18:18:25 <wes-smith> end. At a high level, the TAG acknowledged that it was useful to express a more generalized form of this.
18:18:48 <wes-smith> ... Going through the comments, again with an editorial hat on I attempted to provide feedback on the review, there are some items we will need to discuss as a WG today.
18:19:12 <wes-smith> ... The first concern was - this seems like a bag of keys specification, so a spec for expressing a set of keys, and there was a little doubt that it's not clear that other systems will find use in profiling this thing.
18:19:25 <wes-smith> ... It would take considerable effort to profile it, and there is a question around that.
18:19:25 <jyasskin> q+
18:20:07 <brent> ack jyasskin
18:20:11 <wes-smith> ... The response was that the reason we created the spec was that some WG members wanted it profiled, did not want to normatively refer to DID core, Data Integrity, we had to create a Switzerland specification that people could refer to. The DID core and DI specs as well as VC-JOSE-COSE will profile here.
18:20:30 <wes-smith> jyasskin: the worry that it might not be widely usable is not an argument against publication, maybe only against generic naming
18:20:39 <pchampin> q+
18:20:49 <wes-smith> manu: the group has struggled with if this is worth it, we are now committed to getting it out there as we have dependencies in other specifications.
18:20:50 <brent> ack pchampin
18:21:24 <wes-smith> pchampin: I think that the linked web storage WG should probably try to reuse part of this, this needs to be discussed by the WG but I will encourage this
18:21:37 <wes-smith> manu: some of the activity pub community would like this, BlueSky is using DID documents and would look at this
18:22:44 <wes-smith> manu: next item up, there was concern in the TAG that defining a generic format could introduce security vulnerabilities, citing things like alg:none, there is agreement that generalizing a security format can add vulnerabilities, at present we do not know of any, the only counteraction we can think of is to be in a position where we can actively
18:22:44 <wes-smith> modify or errata the spec to clean those up.
18:23:01 <wes-smith> jyasskin: That seems reasonable, security considerations to warn people about past vulnerabilities when they did this sort of thing
18:23:05 <Wip> Wip has joined #vcwg
18:23:26 <wes-smith> ... one example: VC work has needed a feature from json-LD to add a feature, that WG has not been quick to add that, it would be nice for this group to have a quicker response
18:23:55 <ivan> present+ hadleybeeman
18:23:57 <laurens> laurens has joined #vcwg
18:24:15 <wes-smith> manu: There was also a note that said that you were happy to see that the document does not try to add a format that could be interpreted as JSON/JSON-LD at the same time, however there is discussion around using context parsing documents as JSON-LD using hash ??? values
18:24:24 <wes-smith> ... concern around implicit interoperability that is not in the spec
18:24:34 <wes-smith> ... and attackers may try to exploit the complexity of JSON-LD processing
18:24:52 <wes-smith> ... This one wasn't as clear about what we could do, it sounded like the TAG wanted more language in the spec to clearly document how you can safely process a controller document
18:25:06 <wes-smith> ... I will note that in the VC spec, we have gone to great lengths to tell people what the processing model is and what they should be aware of
18:25:13 <wes-smith> ... Would langauge like that be helpful?
18:25:24 <wes-smith> jyasskin: would like to introduce hadleybeeman
18:25:43 <wes-smith> jyasskin: for this specifically, more strict instructions on how to process it would help
18:25:53 <wes-smith> ... the next couple paragraphs are questioning if this should be JSON-LD at all
18:25:55 <ivan> q+
18:25:59 <wes-smith> ... if that goes back to JSON it solves some of this worry
18:26:08 <brent> ack ivan
18:26:44 <Susan> Susan has joined #vcwg
18:26:48 <wes-smith> Ivan: I do not know which version of the document you looked at, because there was a fairly extensive discussion on the JSON-LD presence in the document, it is now much more isolated than before, the document speaks about the vocabulary in general, it is much more concentrated now
18:27:18 <wes-smith> jyasskin: another thing that I saw in the discussion after we wrote this comment is that json-ld implementations are expected to internally inject the context instead of expect it to be present, that helps with the interoperability concern about mixing JSON/JSON-LD
18:27:54 <wes-smith> manu: high level, the desire is to make sure that no matter if you do JSON/JSON-LD, the outcome is the same, the meaning of all of the fields doesn't change between those two mechanisms
18:28:03 <wes-smith> ... we do need to write some more language to make that very clear
18:28:21 <wes-smith> ... to insist that you cannot get a different result with JSON/JSON-LD
18:28:33 <wes-smith> ... if you think you are in that situation you should throw an error immediately
18:28:50 <wes-smith> ... we could add text to the specification that conveys that more clearly, that the semantics between the two versions are the same when it comes to how you should operate
18:29:02 <wes-smith> ... "authentication" means "authentication" regardless of JSON/JSON-LD forms
18:29:32 <wes-smith> jyasskin: I think that the TAG is likely to stay uncomfortable with this sort of document, but putting something in the specification to say it is a specification bug if you can get different results with JSON/JSON-LD
18:29:40 <wes-smith> ... that would help
18:29:40 <wes-smith> manu: we can certainly put that language in there
18:30:10 <wes-smith> ... speaking to the longer discussion with the TAG, the alternative is to force a format, which will lead to objections in the group, in VCs we did that and it resulted in the group splitting and people going to IETF, now we have a market problem on our hands
18:30:27 <wes-smith> ... what was holding everyone together was this dual mode thing, the experiment in the VC group did not result in a good outcome, I would expect the same result here
18:30:52 <wes-smith> ... If the TAG has any suggestion on how to navigate that, it is not a tech problem, it is a political thing, the TAG, this group, and the VC group should engage more on the guidance for future groups
18:31:14 <wes-smith> jyasskin: We could write something about when it is appropriate to use JSON-LD, we may not have time or expertise to do this, but it would be good to be clear about the technical reasons to pick one or the other
18:31:59 <wes-smith> manu: That would be helpful. Moving on to the next comment, skepticsm that JSON-LD is necessary for controller document, extensibility could be achieved through registries. You recognize that the DID WG sees registries as decentralized but the TAG disagrees.
18:32:19 <wes-smith> ... Removing JSON-LD would lead to formal objections, we are moving forward with everyone unhappy, that is the state we are in.
18:32:54 <wes-smith> ... moving on to the inclusion around multihash and multibase, the TAG believes it is best to mandate that implementations align on base encodings and cryptographic digests
18:33:08 <wes-smith> ... I mentioned that there are good reasons to pick different base encodings and hashes
18:33:21 <wes-smith> ... the best way to encode data into a QR code is base45, for example
18:33:27 <brent> q+ to say maybe the spec could strongly recommend profiles of the document being opinionated
18:34:07 <wes-smith> ... if you were to use base64url you pay a nasty price. The same is true for crypto digest algorithms, we are finding that in some of the newer selective disclosure and unsinkable disclosure technologies, using things like cryptographic circuits, certain hashing mechanisms are easier to implement in a cryptographic circuit than others by orders of
18:34:07 <wes-smith> magnitude
18:34:23 <wes-smith> ... Demonstrated by the European digital identity work, we could pick a specific hashing format and have it create negative consequences
18:34:25 <jyasskin> q+
18:34:41 <hadleybeeman> q+
18:34:43 <wes-smith> ... The point is taken, if we could pick one digest algorithm and encoding that would improve interoperability, but at the cost of harming some of our use cases.
18:35:16 <JennieM> JennieM has joined #vcwg
18:35:27 <wes-smith> ... Given that we know that the market has several different mechanisms, can we encode that in a different field. The cryptographic specifications do make a choice of mechanism. The choice is made at the crypto suite/key expression layer, and not controller document.
18:35:28 <brent> ack brent
18:35:28 <Zakim> brent, you wanted to say maybe the spec could strongly recommend profiles of the document being opinionated
18:35:43 <wes-smith> Brent: maybe the controller document spec should strongly recommend or say that, when you profile this, pick one. That would be a step closer.
18:35:48 <brent> ack jyasskin
18:36:32 <manu> q+ to note that Multibase and Multikey are used elsewhere.
18:36:47 <wes-smith> jyasskin: I had a couple thoughts. The first is that the base encoding is implied by QR codes or a couple other situations, but in controller document, it doesn't seem like you have to use the same base encoding as you might need for a QR code, you are conveying bits that you can re-encode or switch encodings on. I think I still prefer one base
18:36:47 <wes-smith> encoding. The argument about hashes is interesting, and I wonder if the document could explain the benefit of hash choices.
18:36:49 <wes-smith> q+
18:37:19 <wes-smith> jyasskin: it might make sense to have each crypto suite specification pick one specific hash, even if the controller document is more generic.
18:37:20 <brent> ack hadleybeeman
18:37:54 <KevinDean> q+
18:37:58 <brent> ack manu
18:37:58 <Zakim> manu, you wanted to note that Multibase and Multikey are used elsewhere.
18:37:59 <wes-smith> hadleybeeman: I wonder if you have considered standardizing for use case, it would make a big step towards standardizing for interoperability. For example, for QR codes, standardize for base 45, you would have done the hard work for the implementers.
18:39:02 <jyasskin> q+ to address multibase/multihash and disagreement within the TAG
18:39:25 <wes-smith> manu: The reason multibase and multi hash are in the controller document is historical, ideally they would be totally different specifications, they are in there because the implementation community was using multibase/multihash, not just controller documents that could use them, long history of different use cases. That said, the reason it is
18:39:25 <wes-smith> there is we needed normative documentation. I believe that work should be done, but I don't know if the right place is the controller document specification, for example nothing we are doing has anything to do with QR codes.
18:40:03 <ivan> q+
18:40:10 <wes-smith> ... In the future, these specs should probably be pulled out into their own specifications. In the meantime we could write that language in there, not opposed to that.
18:41:08 <wes-smith> hadleybeeman: we are regularly reminding ourselves that we have no power, you can do what you like, I will say that we have had this conversation before regarding interoperability around crypto, and that will continue to come up as a stumbling block. We will continue to say there are opportunities here. I was imagining per-use case profiles for the
18:41:08 <wes-smith> ecosystem.
18:41:20 <wes-smith> ... That then makes it easier for implementations to be interoperable.
18:41:33 <manu> scribe+
18:41:36 <brent> ack wes-smith
18:42:11 <manu> wes-smith: Wanted to speak to point about specifying pros/cons of differen hashing mechanisms. That can be difficult to do wrt. cryptographic circuit stuff, new set of requirements and tradeoffs, difficult to note that sort of stuff ahead of time.
18:42:41 <brent> ack KevinDean
18:43:20 <wes-smith> KevinDean: as someone from the supply chain and barcodes, I would strongly recommend against aligning anything with an encoding mechanism for a specific barcode format. There is work underway to add support to other formats with different compression and encoding algorithms.
18:43:38 <wes-smith> hadleybeeman: Is it complex enough to not write up that nuance?
18:43:54 <manu> q+ to move on to next input
18:43:56 <shigeya> +1 KevinDean
18:44:06 <wes-smith> KevinDean: if you knew ahead of time you could, but from experience at GS1 with QR codes, we found that the compression algorithms built into the barcode format was about as good as anything we could come up with ourselves, not worth the extra effort.
18:44:13 <brent> ack jyasskin
18:44:13 <Zakim> jyasskin, you wanted to address multibase/multihash and disagreement within the TAG
18:44:48 <wes-smith> jyasskin: The team has not come to consensus on if multibase/multihash is good to use, have already talked about how the spec profiles to only a few of the options therein, the TAG will continue discussing that.
18:44:50 <brent> ack ivan
18:44:54 <jyasskin> s/team/TAG/
18:45:25 <selfissued> q+
18:45:48 <wes-smith> Ivan: as someone who is pretty much a newcomer in crypto related things, I have the impression that doing something like what you refer to goes beyond the scope of W3C. The crypto community is huge and has an enormous amount of work going at various organizations. Not up to W3C to make judgement calls on key formats, hash functions - the only thing
18:45:48 <wes-smith> we can do is give the possibility for various things to be used, up to various implementations to decide what to use. Not W3C's business.
18:45:51 <brent> ack manu
18:45:51 <Zakim> manu, you wanted to move on to next input
18:46:04 <brent> ack selfissued
18:46:23 <wes-smith> selfissued: Ivan I was once in a W3C WG that called itself Web Crypto that made choices about what algorithms and formats to use/deprecate.
18:47:17 <wes-smith> manu: jyasskin this is about your comment on the TAG continuing to think about it. There is a common misconception around the multi formats that they suggest that you could use any of them in an application. What we are trying to say is no - you should pick one. The reason the multiformats exist is that the reality is that we have many different
18:47:17 <wes-smith> formats, and applications are using them without using any kind of header.
18:47:30 <wes-smith> ... The problem with base encodings is that you cannot tell the difference between them.
18:48:10 <wes-smith> ... The multiformats are an attempt to encode that into the data itself, so the data is self describing, so if you know they are using a multiformat, interoperability is increased because the first byte tells your application how to process the rest of the data.
18:48:58 <wes-smith> ... The multiformats exist because specs/application developers have picked wildly different things, we are trying to put a header on those things and unify how to recognize a byte stream. The TAG has that deliberation, please convey that this is not the Wild West, we are saying to please pick one thing, but across applications we can increaes
18:48:58 <wes-smith> inter.
18:49:02 <jyasskin> We'll make sure that's part of the TAG discussion in the future.
18:49:02 <wes-smith> s/inter/interop
18:49:45 <JoeAndrieu> JoeAndrieu has joined #vcwg
18:49:47 <wes-smith> manu: One of the feedbacks is that it seems risky in some cases - this has to do with who can make changes to a controller document. We have a field that can point to something else in the world, controller doc not always self contained, other authorities can have the ability to change a document.
18:50:12 <wes-smith> ... That doesn't make sense on the web, it was designed for decentralized ledgers, blockchains, DHTs, things where you can point to other things in the world and the ledgers have rules about document updates.
18:50:28 <wes-smith> ... The commentary from the TAG is that it can be dangerous to point to an external resource without pinning that resource.
18:51:55 <jyasskin> q+ to security considerations
18:52:11 <wes-smith> ... And it's true, there is a risk there. The first question is, the controller document can choose to take on that risk or not. There are use cases where external pointing is useful, e.g. parent child relationship, this document has a guardian that is external. Or, an account recovery service that is external to your document. That's where we are
18:52:11 <wes-smith> conveying that external parties might need ability to change a controller document. It is possible to create a hash for that, we have a digest property that allows you to pin external data to your document. However, if you do this, you don't support key rotation on the other side. You can get to a place where the external party cannot make changes.
18:52:32 <wes-smith> ... We could add language to describe how to pin external data, but it would remove the ability for external key rotation.
18:52:44 <wes-smith> jyasskin: This was not a request for a particular change, just to add text to security considerations.
18:52:50 <JoeAndrieu> q+ to talk about digest pinning
18:52:53 <wes-smith> manu: agreed, but we should raise an issue about digest pinning.
18:52:56 <brent> ack jyasskin
18:52:56 <Zakim> jyasskin, you wanted to security considerations
18:53:02 <brent> ack JoeAndrieu
18:53:02 <Zakim> JoeAndrieu, you wanted to talk about digest pinning
18:53:29 <dmitriz> +1 Joe
18:53:33 <wes-smith> JoeAndrieu: Just want to be a voice against digest pinning, DIDs unique ability to have indirection between identifier and crypto material.
18:53:51 <wes-smith> Brent: I think the group would oppose mandating digest pinning, maybe would support language making it optional.
18:55:03 <wes-smith> manu: Last set of feedback from the TAG has to do with a potential caching attack against keys. Currently in the spec we use a full URL to identify key information in the document (or you can), the question from the TAG is, if you have a full URL for Key A, and the attacker sees Key A, uses the same URL as the other person, and we have dmitriz over
18:55:03 <wes-smith> there, we know that the good actor wants to interact with dmitriz, we will interact with dmitriz first with Key A.
18:55:20 <wes-smith> ... There is some kind of confusion attack where dmitriz caches the bad actor's Key A not the good actor's Key A.
18:55:30 <wes-smith> ... The question from the TAG is, have you thought about this, how does it work.
18:55:53 <wes-smith> ... dlongley responded and said that the algorithm explicitly says not to cache, but if there is a misimplementation there could be caching.
18:56:00 <wes-smith> ... suggestion from the TAG was to use local identifiers.
18:56:30 <wes-smith> jyasskin: I did get this in the issue, it seems like a complication that arises because you are using JSON-LD where local names don't really exist where you wind up with names that look global but are only usable if they are in the requested document.
18:57:53 <wes-smith> manu: just to clarify, local names do not exist, but fragments do, fragments could achieve what you are suggesting. We could also say that URLs are invalid if they do not align with the base of the document and add tests to a test suite to test that. The concern is that we would have to be careful about how we do that, as there are use cases we
18:57:53 <wes-smith> have explored where you may keep key information that's yours external to the document. We would have to work through details, the controller is an example where you point outside of the document, and that is part of the security model. As a result of that feature, we have to care about external links, need to assume that is part of the core
18:57:53 <wes-smith> operating model.
18:58:03 <JoeAndrieu> q+ to ask a related question. can a DID document point to a verification method defined elsewhere?
18:58:14 <brent> ack JoeAndrieu
18:58:14 <Zakim> JoeAndrieu, you wanted to ask a related question. can a DID document point to a verification method defined elsewhere?
18:58:35 <wes-smith> JoeAndrieu: manu answered my direct question, which is that in DID document A, I can define a verificationMethod that is defined in another DID document/controller document
18:59:11 <wes-smith> ... you are saying we have always had that feature. If we believe that the VDR controls the state of the DID document and the resolver is correctly executing, a bad actor would not be able to act on the threat you described.
18:59:42 <JoeAndrieu> q+
18:59:45 <jyasskin> q+
19:00:06 <wes-smith> manu: they can, it's a confusion attack, meaning that you have DID doc A,B, DID doc B uses same identifiers as DID doc A, I could see there are variations of the attack where small misimplementations make the attack work, people need to defend themselves. I want to note this has nothing to do with JSON-LD and exists because we are using URLs so our
19:00:06 <wes-smith> security model is more complex.
19:00:07 <brent> ack JoeAndrieu
19:00:46 <wes-smith> JoeAndrieu: either I don't understand who is referring to who or I disagree. If DID document A is pointing, say attestation method, refers to a verification method in Document B, the listing of that in DID A is entirely under the control of DID document A, not DID document B
19:00:56 <babygazelle> babygazelle has joined #vcwg
19:01:14 <wes-smith> manu: that's not the attack. DID A has a URL that is Key A. DID B, the bad actor, will use the same URL that's in DID A for the purposes of confusing someone what the proper key is.
19:01:31 <brent> ack jyasskin
19:01:44 <JoeAndrieu> +1 to describe this conundrum
19:02:02 <wes-smith> wes-smith has joined #vcwg
19:02:06 <wes-smith> scribe+
19:02:20 <wes-smith> jyasskin: don't need to solve this right now, can put it in security considerations.
19:02:26 <hadleybeeman> please do!
19:02:34 <wes-smith> Brent: thank you for the time and review, anything else you want to express to the group from TAG, are we on the right track?
19:02:54 <wes-smith> jyasskin: there are likely to be some concerns that the WG decides not to address, that is fine, you are on track to address the rest of the concerns.
19:02:54 <manu> q+
19:03:04 <brent> ack manu
19:04:06 <wes-smith> manu: jyasskin, you and I had a nice brief chat about continuing engagement with the TAG as we mature the work, the TAG will continue to have concerns about the work that the DID and VC WGs are doing, this is not resolvable in 6 months. Everyone being aware of that is good, I don't know what the engagement mechanisms is other than horizational
19:04:06 <wes-smith> review, but some discussion here goes beyond horizationtal review comments, e.g. the discussion on multibase. What is the venue there?
19:04:40 <wes-smith> hadleybeeman: you can always open a TAG issue/TAG review, we would love to have discussions there other than "here is a done spec, please check it". We can offer help at the architecture stage, share our experience, connect you to people, etc.
19:04:53 <KevinDean> q+
19:05:13 <wes-smith> ... Similarly, TAG issues don't have to be "this is a particular feature", they can be "let's talk about this big question", whether that is broad or use-case specific.
19:05:19 <gkellogg> gkellogg has joined #vcwg
19:05:32 <wes-smith> ... We are happy to discuss it, and the way we do that is by beginning the discussion on Github as an issue and can continue the discussion in multiple ways.
19:05:51 <wes-smith> ... we are here to help, genuinely, as trite as that sounds, and are not a rubber-stamping "you are finished" body.
19:06:27 <ivan> q+
19:06:33 <wes-smith> ... The more we can have discussions around what we can help the better off we will be. We have had exchanges with other WGs that have brought finished specs to us seeking rubber stamp, we can look at it, but we don't want to be in the position where we are checking other people's homework.
19:06:35 <brent> ack KevinDean
19:07:08 <brent> ack ivan
19:07:08 <wes-smith> KevinDean: Just would like to add a big +1 to that, I am still a member of the GS1 architecture group where we have the same model helping groups progress standards and ensure alignment, I would reiterate, as with the TAG, we don't bite.
19:07:45 <wes-smith> Ivan: We don't have to go into the details here, but what you say is something that should be better reflected in how the process works. The way current transitions go, and staff contacts communicate with the people in charge of these things, is different than what you said.
19:07:53 <wes-smith> hadleybeeman: There was some discussion of that this week.
19:08:08 <manu> q+
19:08:43 <wes-smith> Brent: we have about 20 minutes before lunch and could spend that time in any number of ways, we could bike shed a name for the spec, we could dim the lights and have a relaxing time, we could jump back into issue 93 which is the privacy review, although I feel like we covered that, or we could jump into other issues or PRs
19:08:48 <ivan> q+
19:09:00 <wes-smith> selfissued: If we can finish the privacy review and propose something
19:09:21 <wes-smith> manu: agreed that would be useful, I also went through and marked a large number of issues as editorial that we could do in CR, with a goal of measuring how close to CR we are
19:09:22 <brent> ack manu
19:09:43 <JoeAndrieu> JoeAndrieu has joined #vcwg
19:09:52 <brent> subtopic: next topic?
19:10:04 <brent> ack ivan
19:10:06 <wes-smith> ... I think that the vast majority of the remaining issues are editorial, so we could handle them in CR, which would accelerate us into CR, the TAG and privacy reviews have added things for us to do, but they are largely editorial. I feel we could transition to CR after we do the TAG/privacy things, we could discuss that.
19:10:31 <wes-smith> Ivan: I don't know how crucial it is, but I put in some comments this morning about the PR for the service thing, I don't know if we want to discuss that here or leave it for the usual channels.
19:10:41 <wes-smith> Brent: Timeboxing a 10 minute conversation about issue 93.
19:11:05 <wes-smith> ... We will then spend the rest of the time looking at the issues in general to see how close we are to CR. Should that wrap up before lunch, we will go into the PR, but that can be during our normal calls.
19:11:07 <brent> subtopic: https://github.com/w3c/controller-document/issues/93
19:11:32 <manu> q+
19:11:40 <brent> ack manu
19:12:15 <wes-smith> manu: I think these are largely editorial, the things that have specific things we could write are editorial, the other things we need PING to respond on, I didn't see any massive design changes we need to make. In some cases they have the same questions we do, e.g. difference between subject and controller.
19:12:46 <wes-smith> Brent: my recommendation is to reframe them, instead of saying "is this right", say "here is our interpretation of what you said and how we are moving forward, let us know if that is incorrect"
19:13:04 <wes-smith> ... we are operating in good faith and making the best assumptions we can, where we absolutely need a response I can reach out as chair to PING
19:13:14 <wes-smith> ... for the most part we have a decent idea of what we are looking for
19:13:27 <wes-smith> Brent: anything else on 93?
19:13:33 <wes-smith> selfissued: sounds like a plan
19:13:38 <wes-smith> Brent: next topic, how close are we to CR
19:13:43 <brent> subtopic: Controller to CR?
19:14:44 <wes-smith> ... looking at those issues, as we can see we have our horizontal review, we have self reviews and responses we have talked through, we will have a number of changes in response to what we heard from TAG and what we believe PING is looking for, other than that these are the issues. They have been triaged, you can see the labels here. All of them
19:14:44 <wes-smith> are marked as during CR except for 67.
19:14:57 <wes-smith> ... which is marked both discuss and "pending close".
19:15:09 <wes-smith> manu: we can talk about it now, we just need selfissued's eyes on it.
19:15:12 <brent> subtopic: https://github.com/w3c/controller-document/issues/67
19:15:22 <gkellogg> gkellogg has joined #vcwg
19:15:54 <wes-smith> ... We had duplicate content on the spec between Data Integrity and controller document. Ivan raised a PR to remove the content that was merged. selfissued suggested that we move a line from the controller document to the Data Integrity spec, but that text already exists in the DI spec, so that's why I have marked it pending close.
19:16:05 <wes-smith> Brent: selfissued, we believe we have addressed your concern, need your feedback.
19:16:20 <wes-smith> selfissued: so we did delete the hash of the data integrity URL, if that is the case I will agree to close this.
19:16:46 <wes-smith> Brent: that was the only issue marked as not during CR, except another one, role of the subject
19:16:55 <ivan> q+
19:17:02 <brent> subtopic: https://github.com/w3c/controller-document/issues/33
19:17:20 <wes-smith> manu: that one is during CR as well, I believe JoeAndrieu has language for that that will be PR'd, in theory we can address that, one option is to mark it at risk and change the defn during CR, which is appropriate, or we can handled it now
19:17:21 <brent> ack ivan
19:17:29 <mandyv_> mandyv_ has joined #vcwg
19:17:41 <wes-smith> Ivan: I will repeat what I said on the DID working group, the whole discussion of controllers that took place on Tuesday at the DID WG should in fact take place here
19:17:46 <wes-smith> ... the DID spec only refers to the controller document
19:18:03 <wes-smith> ... I must admit I was a bit lost with the discussion so cannot go into details, but there are some issues from the DID WG that should be transferred here.
19:18:47 <wes-smith> manu: that's only pre CR if JoeAndrieu believes there is some kind of huge normative change that we are going to make that is going to change... I don't know why we couldn't deal with it in CR if we mark it "at risk". I don't think it would change an implementation, whatever we end up doing.
19:19:04 <wes-smith> Ivan: It's difficult to say that, you put a feature at risk, not the definition of a feature.
19:19:12 <wes-smith> manu: then it's not at risk, it's just going to maybe change.
19:19:16 <JoeAndrieu> q+ to say the feature at risk is good
19:19:35 <brent> ack JoeAndrieu
19:19:35 <Zakim> JoeAndrieu, you wanted to say the feature at risk is good
19:19:36 <wes-smith> Ivan: if the defn now is acceptable for everyone, if JoeAndrieu gets to the point that something need to be fundamentally reengineered, that needs to happen now.
19:19:50 <ivan> q+
19:20:46 <wes-smith> JoeAndrieu: not sure why putting it "at risk" is not good enough, we have the issue where dlongley, selfissued, and I went back and forth about what you prove and how this document lets you evaluate proofs created by the controller, that is an editorial cleaning up. What is at risk is the property "controller", and what text is in the spec right
19:20:46 <wes-smith> now nobody supports. The language will probably trend towards "should, and if you do, you must".
19:20:54 <brent> ack ivan
19:20:59 <wes-smith> ... That feels like cleaning up that is close enough to consensus that we will get there.
19:21:34 <gkellogg> gkellogg has joined #vcwg
19:21:48 <wes-smith> Ivan: As a reminder, the "at risk" thing is used when you go to CR with a property but you are not sure it will be implemented. It's not questioning the definition itself, it is whether it is implemented or not, you reserve the right to ignore that term. What you are discussing is not that, it is the definition of the controller. You are not
19:21:49 <wes-smith> removing controller altogether.
19:21:57 <wes-smith> JoeAndrieu: removing controller is on the table.
19:22:18 <JoeAndrieu> q+ to agree
19:22:29 <brent> ack JoeAndrieu
19:22:29 <Zakim> JoeAndrieu, you wanted to agree
19:22:30 <wes-smith> Ivan: In CR you can remove it without further ado if it is not implemented. The CR needs to prove that the spec can be implemented. At risk shows that something can or may not be implemented. Leaning too much on at risk in this discussion.
19:22:48 <wes-smith> JoeAndrieu: You have convinced me Ivan, I will get something on this this week, will get us to CR hopefully soon.
19:23:04 <wes-smith> ... This brings in issue 75.
19:23:16 <wes-smith> Ivan: need to liaise this back to DID, this is where the two WGs are related.
19:23:38 <wes-smith> Brent: any other issues that the editors feel the group should discuss?
19:23:46 <wes-smith> manu: the name of the document
19:23:50 <wes-smith> Ivan: no >:(
19:24:11 <wes-smith> Brent: I will queue up the conversation, we are stopping at 12:30, folks can continue to talk about it over lunch
19:24:21 <JoeAndrieu> q+ to call it a verification document
19:24:32 <wes-smith> ... this conversation is strictly time boxed to 6 minutes
19:24:34 <brent> subtopic: https://github.com/w3c/controller-document/issues/100
19:24:40 <brent> ack JoeAndrieu
19:24:40 <Zakim> JoeAndrieu, you wanted to call it a verification document
19:24:58 <manu> q+ to say what's in it.
19:25:00 <wes-smith> JoeAndrieu: just want to say that a lot of my confusions around what a DID document has or should have was clarified when I understood how verification methods and relationships worked, so why not verification document.
19:25:02 <brent> ack manu
19:25:03 <Zakim> manu, you wanted to say what's in it.
19:25:16 <decentra_> q+
19:25:16 <brent> q+ to talk services
19:25:44 <ivan> q+
19:26:07 <pchampin> q+
19:26:16 <brent> ack decentra_
19:26:18 <wes-smith> manu: that's a good candidate. We are potentially going to add services into this, modulo concerns, if we do that it is about engaging with an entity, so an option is an "engagement document", verification methods and services. I am not saying we do this, but someone could use this for expressing their social media accounts, things like that. "How
19:26:18 <wes-smith> to get in touch with and authenticate an entity".
19:26:40 <wes-smith> decentra_: would make sense to call it an "identifier document". All these docs have identifiers, seems like an obvious name.
19:26:40 <brent> ack brent
19:26:40 <Zakim> brent, you wanted to talk services
19:26:56 <Wip> Wip has joined #vcwg
19:26:58 <JoeAndrieu> q+ maybe "Identifier Descriptor"
19:27:12 <JoeAndrieu> q- maybe
19:27:30 <JoeAndrieu> q- "identifier, Descriptor"
19:27:50 <wes-smith> Brent: I added myself to talk a bit about the services thing. Controller document as we conceived of it came from ??? specs which were taken from the DID specs, there was a question around "where are our services", the assumption during the DID call was that there was a common document, after thinking about it I think that services should not be
19:27:50 <wes-smith> pulled up into controller document.
19:27:56 <brent> ack ivan
19:28:10 <JoeAndrieu> q+ to say maybe "Identifier Descriptor" ; we are using services to reach the controller of the identifier
19:29:16 <wes-smith> Ivan: two things, what you just said, from a general POV, is the same as what I was saying in my comment on a technical POV, and I don't want to go into the details now but would also favor not to have the services. The other point is that, for you guys certain crypto things are natural, that is not true for outsiders. For me, the fact that you
19:29:16 <wes-smith> have a document that can combine crypto information with identifiers is a central element that an outsider understands. The crypto element is central to the whole thing, and I would like that to be reflected in the title.
19:29:17 <brent> ack pchampin
19:29:32 <wes-smith> pchampin: I don't like "engagement document", maybe "entity document"?
19:29:35 <wes-smith> [general laughing]
19:29:47 <brent> ack JoeAndrieu
19:29:47 <Zakim> JoeAndrieu, you wanted to say maybe "Identifier Descriptor" ; we are using services to reach the controller of the identifier
19:29:55 <TallTed> "cryptomogriphication document"
19:30:40 <bigbluehat> q+ to go to lunch
19:30:42 <bigbluehat> ack bigbluehat
19:30:42 <Zakim> bigbluehat, you wanted to go to lunch
19:30:44 <jets> With that we're done (Joe gets the last word) =)
19:30:53 <mandyv> mandyv has joined #vcwg
20:06:17 <gkellogg> gkellogg has joined #vcwg
20:24:49 <cc> cc has joined #vcwg
20:24:55 <brent> brent has joined #vcwg
20:31:38 <decentralgabe> decentralgabe has joined #vcwg
20:47:49 <wes-smith> wes-smith has joined #vcwg
20:50:56 <brent> brent has joined #vcwg
20:51:44 <decentra_> decentra_ has joined #vcwg
20:53:14 <JennieM> JennieM has joined #vcwg
20:56:57 <GregB> GregB has joined #VCWG
20:57:07 <GregB> present+
20:57:27 <shigeya> present+
20:57:38 <wes-smith> wes-smith has joined #vcwg
20:58:15 <manu> manu has joined #vcwg
20:58:52 <jets> present- Brian_McManus
20:59:22 <Wip> Wip has joined #vcwg
21:00:05 <gkellogg> gkellogg has joined #vcwg
21:00:50 <Wip> scribe+
21:01:15 <manu> present+
21:01:25 <Wip> brent: Welcome to the final VCWG session before the joint session with the security group
21:01:27 <dmitriz> dmitriz has joined #vcwg
21:01:34 <Wip> ... This session focuses on all other rec track docs
21:01:58 <JoeAndrieu> JoeAndrieu has joined #vcwg
21:01:59 <TallTed> present+
21:02:04 <Wip> ... our main goal has been to understand what we need to do to get these documents done
21:02:05 <JennieM> present+
21:02:22 <pauld_gs1> pauld_gs1 has joined #vcwg
21:02:24 <pauld_gs1> present+
21:02:26 <Wip> ... We will hopefully pass some resolutions to move these rec track documents to their next phase of existence
21:02:37 <Wip> ... additionally we will be talking test suites
21:03:10 <Wip> ... This will take up the next 90 minutes
21:03:16 <brent> Topic: Every Other Rec Track Document
21:03:30 <Wip> brent: beginning with the proposals
21:03:46 <brent> q?
21:04:08 <Wip> manu: there are three proposals that are very similar to publish VC data integrity the ecdsa and eddsa cryptosuites as CR2
21:04:23 <Wip> ... these are in pretty good shape with at least 2 impls of the features
21:04:51 <Wip> ... for data integrity there is 8 impls. Ecdsa has 6 implementations and eddsa has 8 implementations
21:05:12 <Wip> ... We dont expect to see any features with less than 2 implementations, if we do we will add feature at risk markers
21:05:17 <ivan> q+
21:05:20 <Wip> ... where necesssary
21:05:37 <brent> https://docs.google.com/presentation/d/1rjt4fgajEqqQzdF72JUeh6_h4gICQanExOfcoW4l0GM/edit#slide=id.g302b406d124_0_31
21:05:40 <brent> ack ivan
21:05:41 <Bert> Bert has joined #vcwg
21:05:43 <Wip> ... The proposals are at the above slide
21:05:52 <Isaac> Isaac has joined #vcwg
21:05:59 <Wip> ivan: in the propsal text we should not put the explicit URL
21:06:06 <Wip> ... as they can get outdated
21:06:18 <Wip> ... We have not talked about bbs yet
21:06:32 <Bert> present+ Bert_Bos
21:06:48 <Wip> brent: changes to the proposal, get rid of the links from the text
21:06:49 <denkeni> present+
21:06:52 <KevinDean> KevinDean has joined #vcwg
21:06:55 <KevinDean> present+
21:07:10 <cc> cc has joined #vcwg
21:07:17 <Wip> q?
21:07:20 <JennieM3> JennieM3 has joined #vcwg
21:07:41 <gkellogg> gkellogg has joined #vcwg
21:08:05 <bigbluehat> scribe+
21:08:21 <SinYong> SinYong has joined #vcwg
21:08:34 <JennieM> JennieM has joined #vcwg
21:09:01 <Wip> ivan: Suggest adding one resolution for all three documents
21:09:14 <Wip> manu: makes sense, reworking the proposal
21:10:16 <Wip> manu: 3 outstanding issues on data integrity. 2 are ready for P.R, the other has been discussed and resolved
21:10:27 <Wip> brent: Any suggestions or modifications to the proposal?
21:11:14 <Wip> selfissued: Why is vc-jose-cose not on the list?
21:11:27 <Wip> brent: We are going to do that, I didn;t know vc-jose-cose was ready
21:11:50 <ivan> s/didn;t/didn't/
21:11:55 <Wip> brent: Is this proposal okay, selfissued?
21:12:44 <selfissued> selfissued has joined #vcwg
21:12:48 <selfissued> present+
21:13:32 <Wip> selfissued: This does not include vc data model?
21:13:38 <Wip> ivan: That was resolved yesterday
21:13:50 <brent> PROPOSAL: Publish the latest VC Data Integrity, ECDSA Cryptosuite, and EdDSA Cryptosuite specifications as a 2nd Candidate Recommendations with a 30 day review period after PRs for AT RISK features and all current open issues have been addressed.
21:13:52 <Wip> brent: Not hearing any change requests
21:13:53 <ivan> +1
21:14:02 <manu> +1
21:14:02 <GregB> +1
21:14:02 <denkeni> +1
21:14:02 <decentra_> +1
21:14:02 <Wip> +1
21:14:02 <wes-smith> +1
21:14:02 <dmitriz> +1
21:14:02 <bigbluehat> +1
21:14:18 <TallTed> +1
21:14:34 <JennieM> +1
21:14:35 <pauld_gs1> +1
21:14:48 <KevinDean> +1
21:14:51 <brent> RESOLVED: Publish the latest VC Data Integrity, ECDSA Cryptosuite, and EdDSA Cryptosuite specifications as a 2nd Candidate Recommendations with a 30 day review period after PRs for AT RISK features and all current open issues have been addressed.
21:15:01 <Wip> brent: Hearing no opposition, we are resolved
21:15:18 <Wip> ... manu anything else to discuss related to data integrity, lets talk about bbs
21:15:38 <brent> subtopic: BBS
21:16:02 <Wip> manu: We are not ready to go to CR2 with BBS. GregB has done a great job finishing off the base specification at the IETF
21:16:15 <Wip> ... There are two new specs added to do with pseudonyms
21:16:27 <Wip> ... The review is not yet complete at IETF (cryptographic review)
21:16:55 <Wip> GregB: This is different from general cryptographers. There is an assigned person. This has been outstanding till January
21:17:16 <Wip> ... We are trying to get ready for last call, but waiting for the person for the review panel
21:17:33 <Wip> manu: A number of other IETF groups also depending on BBS and pushing for this to get done
21:17:53 <Wip> manu: Also bringin in other folks with specializations in BBS to get this throrugh the IETF
21:17:56 <ivan> q+
21:18:10 <Wip> ... We have two interoperable implementations that meet all the features
21:18:33 <brent> ack ivan
21:18:35 <Isaac> Isaac has joined #vcwg
21:18:38 <Wip> ... Had the review at IETF been done, we would have been ready to move this to CR2. But since it isn't we are waiting on IETF for this
21:19:14 <Wip> ivan: There was a comment on BBS in the charter that mentioned the timing challenges with IETF. I will reply telling them we are aware of these challenges
21:19:23 <decentralgabe> decentralgabe has joined #vcwg
21:19:37 <Wip> ... I also said there is no normative dependencies on other specifications to BBS so it does not hold up any other specs
21:19:51 <Wip> brent: Are there no other things left to do on the BBS data integrity spec?
21:20:10 <Wip> GregB: There are two key features that we are getting demand for: Anonymous holder binding and pseudonyms
21:20:32 <Wip> ... The API on the IEFT is getting cleaned up, this will affect our spec
21:21:03 <Wip> ... Pseudonyms allow remembering parties who use BBS with anon holder binding and unlinkability
21:21:03 <brent> q?
21:21:10 <manu> q+
21:21:24 <Wip> ... Other places need these features
21:21:28 <Wip> brent: Any further questions?
21:21:29 <manu> q-
21:21:42 <Wip> manu: There is very little that needs doing
21:21:57 <brent> subtopic: VC JSON Schema
21:22:00 <Wip> brent: Right, but there may be normative changes due to changes in the base ietf spec that are holding us back
21:22:17 <Wip> decentralgabe: We are missing another implementation for the test suite
21:22:27 <Wip> brent: No normative changes require a second CR phase?
21:22:32 <Wip> decentralgabe: No
21:22:56 <brent> subtopic: VC Bitstring Status list
21:23:01 <Wip> manu: vc bitstring status list is not ready for CR2. But, it is doing pretty well
21:23:14 <Wip> ... It has been held up, due to us focusing on other specifications
21:23:23 <Wip> ... There are 8 open issues, a number are editorial
21:23:23 <brent> q+
21:23:39 <Wip> ... There are 5 normative issues that could use some discussion
21:24:00 <Wip> ... Because of those issues being normative, we are not ready for CR2
21:24:19 <Wip> ... Additionally, we are lacking the implementations against the test suite
21:24:28 <brent> ack brent
21:24:29 <Wip> ... We are waiting on these issues being resolved
21:24:46 <Wip> brent: Mesur is intending to demonstrate an implementation of the bitstring status list
21:24:59 <Wip> manu: Great. We are expecting many more
21:25:10 <Wip> brent: Okay. lets look at some issues
21:25:33 <brent> subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/93
21:25:37 <Wip> manu: First issue is aligning the bitstring structure with the token status list structure at IETF
21:25:37 <brent> q+
21:25:52 <Wip> ... We all agree alignment would be great. I do not know the status of this alignment
21:26:19 <Wip> ... At this point, we are either aligned or not. I don't know how much energy there is to change the structure of the statuslist
21:26:21 <brent> ack brent
21:26:27 <Wip> ... Be great to hear from the group
21:26:56 <Wip> brent: The associated issue tracking this on IETF side is still open, but the last I heard was there was too great a drift. There i no IETF appetite for alignment
21:27:12 <Wip> ... So we either do extactly what they did, or we continue with what we have
21:27:27 <Wip> ... Option A: is to do nothing
21:27:48 <Wip> ... Option B is to do a lot of work to align with IETF. But no gaurantee that their spec is stable
21:27:51 <manu> q+ to provide DB's opinion.
21:28:01 <JoeAndrieu> +1 to option A. the effort feels unnecessary and likely unproductive
21:28:05 <Wip> ... For B we would be effectively having a normative reference of their specification
21:28:15 <Wip> ... I am fine if this issue would be closed
21:28:16 <brent> ack manu
21:28:16 <Zakim> manu, you wanted to provide DB's opinion.
21:28:34 <Wip> manu: As DB, we have implemented what is currently in the spec. We have no interest in changing this
21:28:41 <Wip> ... So +1 for option A
21:28:52 <Wip> brent: Marking it with pending close
21:29:06 <Wip> ... Any additional issues?
21:29:06 <Wip> manu: 2 issues 175 and 176
21:29:14 <Wip> ... Around status messages and status size
21:29:18 <brent> subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/175
21:29:28 <brent> q+
21:29:31 <Wip> ... There is maybe only one implementer for this feature at this point
21:29:37 <ivan> https://github.com/w3c/vc-bitstring-status-list/issues/176
21:29:48 <Wip> ... Dont think it is currently marked as at risk
21:30:08 <Wip> manu: Actually it is already marked at risk
21:30:11 <brent> ack brent
21:30:17 <Wip> ... So we are waiting for implementations
21:30:30 <Wip> brent: My understanding is mesur implementes these features
21:30:44 <Wip> manu: Great. I think Spruce may also be using it, so leaving it in awaiting implementations
21:30:50 <brent> subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/174
21:30:59 <Wip> manu: Moving on. The next issue has to do with the time to live (TTL) feature
21:31:10 <Wip> ... The spec currently states TTL default is 5 hours
21:31:38 <Wip> ... The status list becomes invalid after 5 hours. Some implementations do not want to do this. Retail stores sometimes go offline for a week at a time
21:31:50 <Wip> ... They still want to be able to process things after a 5 hour timeout
21:32:19 <Wip> ... An option here would be to state TTL is completely optional with no TTL default. This would allow others to profile this and constrain TTL per their use case
21:32:20 <cc> cc has joined #vcwg
21:32:23 <JoeAndrieu> +1 TTL optional
21:32:41 <Wip> brent: Do we know the reasons it was not wrote optional in the first place
21:32:53 <Wip> manu: MikeProrock wrote this language. We should ask him
21:32:56 <Wip> brent: I can do that
21:32:59 <JoeAndrieu> q+
21:33:05 <brent> ack JoeAndrieu
21:33:23 <Wip> JoeAndrieu: What does the language say should happen after TTL has been passed
21:34:11 <manu> https://w3c.github.io/vc-bitstring-status-list/#bitstringstatuslistcredential
21:34:11 <JoeAndrieu> q+
21:34:20 <brent> https://w3c.github.io/vc-bitstring-status-list/#:~:text=credentialSubject.ttl
21:34:41 <brent> ack JoeAndrieu
21:34:57 <Wip> JoeAndrieu: I have issues with this language. It feels like an application related thing. That the Verifier should refresh the cache
21:35:07 <manu> q+
21:35:12 <brent> ack manu
21:35:13 <KevinDean> q+
21:35:16 <Wip> ... Sometimes they will not be able to. So saying that they MUST NOT use cached data is an overreach
21:35:22 <dmitriz> q+
21:35:39 <Wip> manu: I agree, but the problem with weakening it makes the TTL kind of irrelevant
21:36:22 <Wip> ... many of us do not like the TTL at all. Potential for conflicting representations with HTTP headers
21:36:36 <Wip> ... Additionally there is the validFrom and validUntil fields
21:36:38 <shigeya> present-
21:36:48 <Wip> ... This is a questionable/problematic feature
21:36:56 <Wip> ... A few implementations plan on just ignoring it anyway
21:37:02 <JoeAndrieu> q+
21:37:09 <Wip> ... For those that want it, they can use it but there are dangers
21:37:10 <brent> ack KevinDean
21:37:38 <Wip> KevinDean: Wondering if it would not be acceptable to state that if the target is unreachable, the Verifier may proceed with the older cache of the status list
21:37:50 <Wip> ... I think TTL is an important parameter in some cases
21:37:55 <brent> I would be in favor of Kevin's suggestion
21:38:01 <Wip> ... It should be the application can decide what to do if it is unreachable
21:38:03 <brent> ack dmitriz
21:38:20 <Wip> dmitriz: Puzzled why we are discussing the valid issues of TTL. This is a direct redundancy of validUntil
21:38:38 <Wip> ... two problems. 2 fields that do the same thing. Secondly, should we make the TTL property optional
21:38:40 <pauld_gs1> +1
21:38:41 <brent> ack JoeAndrieu
21:38:43 <Wip> JoeAndrieu: I agree with dmitriz
21:39:05 <decentralgabe> q+
21:39:06 <Wip> ... It feels like if we enshrine it as a property that is optional we are giving people the option to advertise something that is confusing and optional
21:39:08 <wes-smith> q+
21:39:10 <manu> q+ to note the use case.
21:39:12 <Wip> ... It introduces the wrong mental model
21:39:30 <Wip> q?
21:39:34 <brent> ack decentralgabe
21:39:51 <brent> ack wes-smith
21:39:51 <Wip> decentralgabe: Fine with removing it. Wondering if there is some aspect of this property that is useful though
21:40:22 <KevinDean> +1 to that
21:40:29 <brent> ack manu
21:40:29 <Zakim> manu, you wanted to note the use case.
21:40:32 <Wip> wes-smith: Adding some nuance. The TTL and validUntil are not the same thing. TTL is around how long the cache of the status list. Wheras validUntil is on the core credential
21:40:33 <brent> +1 to Wes
21:40:38 <Wip> ... They are different but conflicting
21:41:06 <JoeAndrieu> q?
21:41:08 <cc> cc has joined #vcwg
21:41:08 <JoeAndrieu> q+
21:41:09 <Wip> manu: The usecase around TTL is, you want to set a long expiration time for your status list. But tell the verifiers that you may make changes within a certain window
21:41:17 <Wip> ... TTL is around caching semantics
21:41:31 <Wip> ... That said, http caching headers are about this too
21:41:39 <JoeAndrieu> q+ to say "MUST" makes the semantics the same as validUntil
21:41:53 <Wip> ... A counterpoint is that you might not have access to the system that fetched the status list. This is where TTL on the status list itself may be useful
21:41:56 <brent> ack JoeAndrieu
21:41:56 <Zakim> JoeAndrieu, you wanted to say "MUST" makes the semantics the same as validUntil
21:42:20 <Wip> JoeAndrieu: reputing the usecase. because this is MUST it says that the status list is not valid after the TTL
21:42:29 <Wip> ... Therefore you would have to expire
21:42:46 <wes-smith> q+
21:42:54 <brent> ack wes-smith
21:43:20 <JoeAndrieu> q+ to say you can use an expired credential
21:43:20 <Wip> wes-smith: Responding to JoeAndrieu. I agree if TTL has expired you can't use it. The verifier would fail to verify because the status list has expired
21:43:29 <Wip> ... This still does not make TTL and validUntil the same
21:43:34 <Wip> ... Does that make sense?
21:43:35 <brent> ack JoeAndrieu
21:43:35 <Zakim> JoeAndrieu, you wanted to say you can use an expired credential
21:43:49 <wes-smith> q+
21:43:56 <Wip> JoeAndrieu: You can use an expired credential. Validation happens after verification
21:44:07 <Wip> ... This language says I cannot use it in conformant software
21:44:19 <manu> q+ to suggest a way forward.
21:44:22 <brent> ack wes-smith
21:44:33 <Wip> ... This prevents the usecase that manu mentioned. If it is a MUST that the list is no longer valid then it excludes this usecase
21:44:35 <brent> ack manu
21:44:35 <Zakim> manu, you wanted to suggest a way forward.
21:45:07 <Wip> manu: concrete proposal to shift the language to a MAY. This makes the semantics different from validUntil. You can continue to use it past the TTL
21:45:14 <Wip> ... Any objections to this change to the TTL field
21:45:22 <Wip> ... This will make the TTL field a purely optional thing
21:45:40 <Wip> ... If it is there, then you should check.
21:45:45 <Wip> q+
21:45:53 <brent> ack Wip
21:45:58 <manu> scribe+
21:46:07 <manu> Wip: Are we saying the TTL will have no default value there?
21:46:25 <Wip> manu: I would suggest it doesnt have a default value. Because it is usecase specific
21:46:47 <Wip> ... e.g. a trading floor might have microseconds
21:46:53 <Wip> ... I dont think picking a value makes sense
21:47:01 <dlehn> q+
21:47:02 <Wip> ... applications can profile it
21:47:05 <brent> ack dlehn
21:47:24 <Wip> dlehn: The issue says 5 hours, but the spec currently says 5 minutes
21:47:53 <Wip> brent: Sounds like there is enough input for someone to raise a PR
21:47:57 <Wip> manu: yep, I can take that
21:48:02 <Wip> brent: Any other issues
21:48:28 <Wip> manu: We still need to discuss decoy entries.
21:48:46 <Wip> ... Waiting on nick doty to let us know if we addressed his concerns
21:49:10 <Wip> brent: We are acting in good faith. If this ends up holding us up, lets close it
21:49:29 <JoeAndrieu> q+ to ask for analysis
21:49:31 <Wip> manu: The PR that got merged was an issue marker stating that in general decoys reduce the privacy of the status list
21:49:41 <Wip> ... We haven't talked about it since then
21:49:48 <brent> subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/150
21:49:59 <Wip> ... We need to say if we think decoy values are harmful. say nothing. Or recommend decoy values
21:50:07 <KevinDean> q+
21:50:15 <Wip> ... I think decoy values are harmful, because adding decoys shrinks the set size
21:50:20 <Wip> ... Reducing privacy
21:50:21 <wes-smith> q+ to ask about decoy values
21:50:39 <Wip> ... The argument here is that you should set bits in the list randomly. Don't waste any bits in the list for decoy values
21:50:48 <brent> ack JoeAndrieu
21:50:48 <Zakim> JoeAndrieu, you wanted to ask for analysis
21:50:51 <brent> q+
21:50:54 <Wip> ... We could also say you can use decoy values if you want. Seems conterintuitive though
21:51:04 <Wip> JoeAndrieu: I am not convinced on this argument
21:51:29 <Wip> ... The k-anonymity argument is how many people can I be confused with. I think with decoys I can be confused with a decoy. That is a good thing
21:51:31 <brent> ack KevinDean
21:51:50 <Wip> KevinDean: I agree with JoeAndrieu. It is possible to create a properly randomised list. And one that is expandable over time
21:52:02 <Wip> ... I can drop a link to this
21:52:16 <brent> ack wes-smith
21:52:16 <Zakim> wes-smith, you wanted to ask about decoy values
21:52:35 <Wip> wes-smith: I am confused with what manu said about decoys cutting the group privacy of the set
21:52:52 <Wip> ... Is the idea over time that verifiers can learn which entries are decoys in the list
21:53:04 <brent> q-
21:53:09 <Wip> manu: Yep that is one attack. The other argument is why don't you just use a much larger set
21:53:42 <KevinDean> Fisher-Yates shuffler Python code: https://github.com/KDean-Dolphin/Python-Shuffler. IIW presentation: https://drive.google.com/file/d/1wtT2GUQrl7lKCarHYkWvyPbcRmm1Dvji/view?usp=sharing.
21:53:44 <Wip> ... Otherwise you have to perfectly model the rate of issuance to real people to decoys then you can statistically determine which entries are likely to be decoys
21:54:06 <decentralgabe> q+
21:54:08 <Wip> ... e.g. if someone is issuing decoys at 4am (a bad example) then you can easily detect when decoys are being added
21:54:19 <Wip> ... This is how the reduction of privacy occurs
21:54:33 <brent> q+
21:54:41 <decentralgabe> q-
21:54:43 <wes-smith> q+
21:54:47 <Wip> ... The language says in general it is harmful to add decoys. Because it requires expertise to add decoys. It is a roll your own crypto type thing
21:54:55 <Wip> ... Easy to do the wrong thing
21:54:56 <brent> ack brent
21:55:20 <denkeni> +1 to the security best practice
21:55:21 <Wip> brent: In general, is it possible to start the bit string status list with a randomised string
21:55:27 <Wip> ... Then every entry could be a decoy
21:55:44 <decentralgabe> q+
21:55:55 <Wip> manu: Yes, but if you know the issuer always issues inactive things. You know the k-size
21:56:31 <brent> ack wes-smith
21:56:37 <Wip> brent: It sounds like a way to address this issue might be. Perfect deployment of decoy values would increase the privacy protections of the set. However, the degratdation that occurs though improper use of decoys leads us to not recommend this approach
21:57:04 <Wip> wes-smith: Thanks for clarifying. The language that we started with is not the best language. Decoys do not harm privacy, BUT it is hard to use the correctly
21:57:06 <brent> ack decentralgabe
21:57:34 <Wip> decentralgabe: Thanks this makes sense now. We should add language around updating status lists and the risks around eroding privacy
21:57:48 <JoeAndrieu> q+ to say it's about not rolling your own, not NOT using decoyr
21:57:55 <brent> ack JoeAndrieu
21:57:55 <Zakim> JoeAndrieu, you wanted to say it's about not rolling your own, not NOT using decoyr
21:57:59 <Wip> ... I agree you can use decoys in a safe manner, but not sure it is worth talking about in the sepc
21:58:23 <manu> q+
21:58:30 <brent> ack manu
21:58:31 <Wip> JoeAndrieu: The language around not rolling your own is on point. But there might be tools written by experts that people can use
21:58:40 <Wip> manu: I am concerned that this does not exist yet.
21:59:01 <Wip> ... People will try to do this, but may not do it well
21:59:29 <Wip> brent: I think that is all the CR normative issues for bit string status list
21:59:34 <Wip> ... Any notion of the timeline for this
21:59:56 <ivan> q+
22:00:04 <Wip> manu: This wont be ready by january. Because of the other specs that are in need of attention
22:00:09 <brent> ack ivan
22:00:31 <Wip> ivan: I would prefer to keep the goal of January. We are not that far away
22:00:43 <manu> q+
22:00:56 <Wip> ... The result from the discussion with jeffery today was that there are 3 or 4 editoral changes required to the controller document
22:01:04 <Wip> ... The only outlier is BBS spec
22:01:13 <brent> ack manu
22:01:14 <Wip> ... I believe it is still possible to aim for January
22:01:28 <Wip> manu: Reminding everyone it could go fast if people did a PR
22:01:39 <cc> cc has joined #vcwg
22:02:02 <Wip> ivan: This is true. Many things are independent PRs that can be done in parralel.
22:02:23 <ivan> q+
22:02:32 <Wip> brent: I think we have a solid idea for all our specs and next steps
22:02:39 <ivan> q-
22:02:47 <Wip> ... We had a great conversation with vc-jose-cose. We know what is left
22:02:52 <decentralgabe> q+
22:03:01 <Wip> ... At what point do we anticipate a second CR from vc-jose-cose
22:03:06 <brent> subtopic: VC JOSE COSE timing
22:03:11 <brent> ack decentralgabe
22:03:19 <manu> q+
22:03:24 <Wip> decentralgabe: After the media types PR goes in there a no other normative issues to resolve
22:03:33 <Wip> ... we should go to a second CR after that
22:03:42 <ivan> q+
22:03:45 <Wip> brent: Any issues passing a resolution to talk to that
22:03:46 <brent> ack manu
22:04:10 <Wip> manu: During that conversation I raised there is still no language around mandatory reveal of contexts. We should address that before CR2
22:04:13 <brent> ack ivan
22:04:32 <brent> q+ to talk timeline
22:04:39 <Wip> ivan: My understanding is Phillipe has already contacted IETF after our discussion this morning
22:05:07 <Wip> ... If we have a positive response that I agree we can go to second PR. This may take a couple of weeks
22:05:08 <TallTed> q+
22:05:09 <brent> ack brent
22:05:09 <Zakim> brent, you wanted to talk timeline
22:05:34 <Wip> brent: Talking timelines for vc-jose-cose. decentralgabe has raised a PR to address the resolution passed this morning
22:05:42 <Wip> ... After the review period the PR will be merged
22:05:55 <brent> ack TallTed
22:05:59 <Wip> ... Our first meeting back we may have a conversation about advancing jose-cose to CR2
22:06:18 <selfissued> q+
22:06:39 <Wip> TallTed: The text I flagged in 305 is no longer what I expected. It makes me concerns with the git history throughout the spec
22:07:18 <Wip> selfissued: I am about to create a PR to address this. It turns out a PR that did exist has been deleted. I will flag you as a reviewer to the PR
22:07:37 <Wip> TallTed: That is all good. However, I cannot find the commit that shows the change removing language that I raised my commends against
22:08:06 <gkellogg> gkellogg has joined #vcwg
22:08:14 <Wip> s/commends against/comments against/
22:08:42 <JennieM> JennieM has joined #vcwg
22:08:42 <Wip> brent: Please continue to look at the history for us TallTed
22:08:45 <decentralgabe> this is it? 41b73cca80ebfee7b221087414681504275e9b7c
22:08:58 <Wip> TallTed: This should not be possible in git
22:09:06 <brent> q?
22:09:16 <brent> ack selfissued
22:09:27 <decentralgabe> q+
22:09:37 <Wip> manu: This is why we always do rebase commited so as not to confuse git in these ways and loose git history
22:10:05 <Wip> ... If you do merge commits you can point to alternate histories
22:10:14 <Wip> dmitriz: rebase commit turns git into a blockchain
22:10:27 <brent> ack decentralgabe
22:10:35 <Wip> manu: Yes, this is why you dont do merge commits
22:10:57 <Wip> decentralgabe: I posted the commit in, it was a result of the squash commit i used
22:11:21 <brent> Topic: Use Cases and Requirements update
22:11:43 <TallTed> q+
22:12:12 <decentralgabe> I have disabled squash and the repo it won't happen going forward
22:12:15 <brent> ack TallTed
22:12:25 <Wip> TallTed: Sorry, the commit you found decentralgabe is not quite right
22:12:42 <Wip> ... There is disclaimer test that includes test that I added
22:12:50 <selfissued> q+
22:13:18 <Wip> selfissued: If you approve the PR I just sent that language will come back
22:13:21 <brent> ack selfissued
22:13:27 <Wip> TallTed: That is good. I am still concerned with how this came about
22:13:49 <pauld_gs1> present -
22:14:04 <pauld_gs1> Have to drop off gang.  Great to see the progress.
22:14:08 <Wip> KevinDean: Reminder the UseCase document can be found at the ??? URL
22:14:22 <Wip> ... Some material may move the the VC-overview document
22:14:28 <Wip> ... We are still looking for some new usecases
22:14:51 <Wip> ... The short usecases are small simple usecases. These exist already. They are self contained and generally unrelated to other usecases
22:15:08 <Wip> ... There are 30 currently, not generally looking for more. But if there are good ones we may consider replacing
22:15:17 <denkeni> https://www.w3.org/TR/vc-use-cases/
22:15:23 <bigbluehat> s/at the ??? URL/at https://www.w3.org/TR/vc-use-cases/
22:15:49 <Wip> ... The extant use case are from usecase that exist in the market. Either in production, or proof of concept. Looking for a title and very short description and URL
22:16:28 <Wip> ... Finally, focus use case is a deeper diver into a VC application. This is highly detailed. With title, background, list of actors, validation requirements and threat model
22:16:46 <Wip> ... We proposed a timeline, but did not get much contributions
22:16:50 <Wip> ... We would like to close this by the end of 2024
22:17:04 <brent> q?
22:17:27 <Wip> JoeAndrieu: One major addition in this version of this usecase was the GS1 usecase. Particularly that deals with delegated authorization
22:17:32 <Wip> ... Thanks KevinDean
22:17:54 <KevinDean> https://github.com/w3c/vc-use-cases/issues/157
22:18:01 <Wip> ... There is another trade supply usecase that we are working to unpack. This aims to make a concrete case for selective disclosure in products going through the supplychain
22:18:04 <manu> q+ to speak to tradetrust use case.
22:18:09 <Wip> KevinDean: This is issue 157
22:18:45 <Wip> JoeAndrieu: I want to mine the test suite for implementers to find people using VCs in the wild
22:18:58 <Wip> ... Right now the extant usecases is empty
22:18:59 <brent> ack manu
22:18:59 <Zakim> manu, you wanted to speak to tradetrust use case.
22:19:10 <hadleybeeman> hadleybeeman has left #vcwg
22:19:19 <Wip> manu: Do the tradetrust folks(issue 157) want to speak to their usecase
22:19:21 <cc> cc has joined #vcwg
22:20:14 <KevinDean> q+
22:20:17 <manu> q+
22:20:39 <brent> ack KevinDean
22:20:49 <manu> q-
22:20:51 <Wip> SinYong: If I issue an invoice to you, you may want to hide your name from me. To obfuscate from the invoices. This applies to suppliers of products.You have to pay to ship you product from point a to point b. You do no want your downstream parties to know how much you paid
22:21:03 <manu> q+
22:21:04 <JoeAndrieu> q+ to ask does the final signature retain original authority?  Do we have crypto that does that?
22:21:24 <manu> q+ to note that this is signalling for a lack of a securing mechanism that allows this sort of behaviour.
22:21:32 <brent> ack manu
22:21:32 <Zakim> manu, you wanted to note that this is signalling for a lack of a securing mechanism that allows this sort of behaviour.
22:21:37 <Wip> KevinDean: That is true in many supply chain cases. I may need proof that I am a retailer, without knowing exactly who I am
22:21:53 <Wip> manu: This is a really important usecase, because it signals we do not have a cryptosuite that is capable of this yet
22:22:12 <Wip> ... This use case is, I get a VC and want to selectively redact information on that VC without violating the signature
22:22:17 <Isaac> q+
22:22:22 <KevinDean> q+
22:22:33 <Wip> ... Each point in the supply chain can redact additional data from the VC
22:22:47 <brent> ack JoeAndrieu
22:22:47 <Zakim> JoeAndrieu, you wanted to ask does the final signature retain original authority?  Do we have crypto that does that?
22:22:53 <SinYong> SinYong has joined #vcwg
22:23:15 <Wip> JoeAndrieu: Is this possible? There is innovative/novel cryptography that can do this
22:23:20 <Wip> ... I just want to know it is possible
22:23:24 <SinYong> +q
22:23:29 <brent> ack Isaac
22:23:29 <Wip> manu: Yes, it is possible
22:23:48 <gkellogg> gkellogg has joined #vcwg
22:24:33 <cc> q+
22:24:35 <Wip> SinYong: When we do our project, the holder ???,  We do not want to issue VCs to every party along the supplychain. We use the VC to represent a tree structure. It does not issue the VC to any particular holder
22:24:37 <brent> ack KevinDean
22:24:56 <Kyle> Kyle has joined #vcwg
22:25:14 <Wip> KevinDean: interesting. In redaction you still have the same public key to identify the issuer. This can't go with the credential. It may still give the opportunity to identify who the supplier might be
22:25:15 <brent> ack SinYong
22:25:22 <brent> ack cc
22:25:37 <Isaac> Isaac has joined #vcwg
22:25:46 <denkeni> q+ on threat model and trust model
22:25:52 <brent> ack denkeni
22:25:52 <Zakim> denkeni, you wanted to comment on threat model and trust model
22:25:56 <Wip> cc: Our merkle proof signatures are going to bepublished and made into an extension
22:26:29 <Wip> denkeni: We are starting to explore an open ecosystem of VC and DIDs. We could contribute our research back to the community.
22:26:52 <Wip> ... Our first focus is on the threat model. Do we need to deal with the W3C threat modelling group here?
22:26:52 <manu> q+ to speak to Threat Model group
22:26:57 <Wip> brent: I think yes
22:27:08 <JoeAndrieu> q+ to mention our "threat model" notion
22:27:13 <Wip> ... We will be meeting with the security people after the break
22:27:14 <brent> ack manu
22:27:14 <Zakim> manu, you wanted to speak to Threat Model group
22:27:36 <Wip> manu: +1 to brent. Simone is putting together a threat modelling approach for multiple groups to go through
22:27:44 <brent> ack JoeAndrieu
22:27:44 <Zakim> JoeAndrieu, you wanted to mention our "threat model" notion
22:27:47 <Wip> ... There is going to be collaboration in the future
22:28:14 <Wip> JoeAndrieu: We do have a section about threats in the use case document. But this is not based on any of the work. What we have is closer to a risk analysis
22:28:18 <denkeni> q+ more on threat model
22:28:19 <Wip> ... A much simpler model.
22:28:30 <Wip> ... It would be great to use whatever Simone is producing
22:28:32 <brent> ack more
22:28:32 <Zakim> more, you wanted to comment on threat model
22:29:22 <Wip> denkeni: I know in W3C the threat modelling is an overview. In our work, we have a more detailed threat modelling of specific usecases. We are focused on threat modelling for issuers, holders and verifiers. We may be able to contribute this
22:29:44 <Wip> brent: Any additional comments?
22:29:47 <SinYong> SinYong has joined #vcwg
22:29:59 <Wip> ... Not hearing anything. meet back here in 1 hour
22:30:45 <ivan> rrsagent, draft minutes
22:30:47 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-vcwg-minutes.html ivan
22:31:37 <brent> q?
22:51:24 <dmitriz> dmitriz has joined #vcwg
23:09:10 <gkellogg> gkellogg has joined #vcwg
23:22:42 <Bert> Bert has left #vcwg
23:24:40 <gkellogg> gkellogg has joined #vcwg
23:26:16 <brent> brent has joined #vcwg
23:26:29 <GregB> GregB has joined #VCWG
23:27:47 <selfissued> selfissued has joined #vcwg
23:27:52 <selfissued> present+
23:32:16 <GregB> present+
23:32:49 <JennieM> JennieM has joined #vcwg
23:33:25 <wes-smith> wes-smith has joined #vcwg
23:33:51 <wes-smith> scribe+
23:34:08 <Susan> Susan has joined #vcwg
23:34:22 <jthomas> present+ Josh_Thomas
23:34:24 <simone> simone has joined #vcwg
23:34:27 <wes-smith> Brent: Welcome to the final VCWG session of TPAC 2024, this is our joint session with Security. This is scheduled for 90 minutes.
23:34:28 <Kyle> Kyle has joined #vcwg
23:34:44 <Wip> Wip has joined #vcwg
23:34:50 <wes-smith> ... The goals of this session: first, find actionable feedback for us to take on the specs, second, for us to know what the process should be moving forward as far as specs moving into CR and PR and onward.
23:34:59 <wes-smith> ... as that relates to further security review.
23:35:10 <mandyv> mandyv has joined #vcwg
23:35:22 <jets> present+ Brian_McManus
23:35:31 <brent> Topic: Meeting with Security
23:35:33 <morimori> morimori has joined #vcwg
23:35:38 <ivan> present+ simone
23:35:45 <cc> cc has joined #vcwg
23:35:47 <wes-smith> ... first, does the Security group have anything they would like to share with the VCWG as far as the review specs?
23:36:09 <wes-smith> simone: happy to be here, there are some volunteers that have already started working, people you already know such as Jaromil (?)
23:36:47 <wes-smith> ... there is a long list of documents to be reviewed, my idea is to move forward together into threat modeling to put security risks + threats as well as privacy issues together, to kill two birds with one stone
23:36:52 <denkeni> present+
23:37:05 <wes-smith> ... the threat model in this case should only be the start - we are already testing information leakage in BBS
23:37:19 <wes-smith> ... if the implementation and test vectors are ready we can do this testing
23:37:53 <wes-smith> ... working with ETH Zurich to find researchers to do this analysis
23:38:07 <wes-smith> ... also will talk with IETF to discuss the BBS work
23:38:35 <wes-smith> ... we also need to work with the CG for post-quantum tools
23:38:46 <wes-smith> ... next steps involve ZKPs for post-quantum, we do not have that capability yet
23:39:07 <wes-smith> ... initial feedback, the thread model is already ?? pages, there is more work to be done on credential formats
23:39:47 <Wip> s/thread model is already ??/threat model is already 50/
23:39:52 <wes-smith> ... we can organize a meeting structure to better understand what we are working on together, reading the spec is nice but it's easier to discuss with the WG
23:39:53 <manu> q+ to note interest in a threat model call wrt. VCs and the securing specifications.
23:39:59 <JoeAndrieu> JoeAndrieu has joined #vcwg
23:40:23 <wes-smith> ... we should also try to better understand what collaboration with other entities is needed, e.g. IETF
23:40:24 <morimori> q+ ZKP for PQC?
23:40:38 <brent> ack manu
23:40:38 <Zakim> manu, you wanted to note interest in a threat model call wrt. VCs and the securing specifications.
23:40:38 <wes-smith> ... there was an idea to have Security Directorate support for our standards, there is joint work potential there as well
23:40:54 <wes-smith> manu: just to note interest in participating in the threat model work, especially as it relates to VCs and their securing specifications
23:40:56 <simone> s/Jaromil (?)/jaromil/
23:41:24 <wes-smith> ... as far as timeline is concerned, we are going into second CR phase, we are hoping to go into proposed recommendation realistically by January, so not a lot of time
23:41:46 <bigbluehat> scribe+
23:41:57 <wes-smith> ... I am wondering if we could split the review up into two passes, we have another 2 years in the group and can maintain the documents, I am wondering if we could do a high-level review to find major concerns from a security perspective as soon as the group has started
23:42:15 <wes-smith> ... then move into a work mode where we do longer term analysis. Quick review before PR then continuous review.
23:42:33 <bigbluehat> simone: you have in the charter that you will update the spec if a security issue is found
23:42:40 <bigbluehat> ... that's a nice approach. thank you
23:42:50 <bigbluehat> ... if there are some blockers, I don't think there are
23:42:59 <brent> ack ZKP
23:42:59 <Zakim> ZKP, you wanted to discuss PQC?
23:43:00 <bigbluehat> ... what we have now, I don't see any imminent issues
23:43:34 <bigbluehat> morimori: what did you mean using ZKPs to deal with post-quantum
23:43:50 <bigbluehat> ... why is ZKP being used for post-quantum
23:43:56 <bigbluehat> simone: it's a long-term objective
23:44:02 <manu> q+ to speak to unlinkable postquantum approaches.
23:44:05 <bigbluehat> ... when we were thinking about these security sections
23:44:12 <bigbluehat> ... we wanted to note that there was future work to do
23:44:27 <bigbluehat> ... it's good to point to things that need addressing in the future
23:44:35 <bigbluehat> ... they're notes to address later
23:44:50 <bigbluehat> ... each time we do a review, we can update it with the latest info
23:45:08 <bigbluehat> morimori: maybe PKC could attack the recent crypto in ZKP
23:45:15 <bigbluehat> ... maybe I'm wrong...but tihs is interesting
23:45:20 <bigbluehat> simone: it's OK. these were just notes
23:45:35 <bigbluehat> ... sorry for the confusion
23:45:42 <bigbluehat> ... this is really to keep it on our radar
23:45:51 <Wip> Here is an example of people looking at ZKP in lattices. In particular they are trying to achieve the same properties as BBS I believe https://web.archive.org/web/20220428172452id_/https://eprint.iacr.org/2022/509.pdf
23:45:58 <bigbluehat> ... the approach we are trying to implement is to start from the threat model
23:46:05 <bigbluehat> ... and note areas of possible concern
23:46:12 <bigbluehat> ... and security is always a trade-off
23:46:22 <bigbluehat> ... so we work to keep an eye on the future
23:46:30 <bigbluehat> brent: to recap
23:46:47 <bigbluehat> ... there isn't any outstanding issue that would prevent us from moving the specs forward
23:47:05 <bigbluehat> ... so when we submit CR2 requests we should be able to say "security review has been done so far"
23:47:34 <bigbluehat> simone: yes. we can stay in touch as the threat model document develops
23:47:37 <ivan> q+
23:47:43 <bigbluehat> brent: but we can move forward, correct?
23:47:52 <bigbluehat> simone: yes. the threat model document is general
23:47:57 <bigbluehat> ... and we want to do it together
23:47:57 <dezell> dezell has joined #vcwg
23:48:04 <bigbluehat> brent: not a problem.
23:48:08 <dezell> present+ David_Ezell
23:48:09 <bigbluehat> ivan: we need a yes or no
23:48:20 <bigbluehat> brent: we need to know if we're waiting on this work
23:48:36 <bigbluehat> simone: we should organize a 2-4 hours about answering this question
23:48:39 <brent> ack manu
23:48:39 <Zakim> manu, you wanted to speak to unlinkable postquantum approaches.
23:48:49 <jets> present+ Brian_McManus
23:49:12 <bigbluehat> manu: so, you're saying we should meet with the group for 2-4 hours and at that point we should have an answer?
23:49:15 <bigbluehat> simone: yes.
23:49:27 <bigbluehat> manu: maybe the editors can commit to that
23:49:34 <bigbluehat> ... can we do it in the next couple of weeks?
23:49:36 <bigbluehat> simone: yes
23:49:47 <brent> ack ivan
23:49:53 <bigbluehat> manu: so, we can do CR2, then this meeting, and hopefully go to PR after
23:50:01 <bigbluehat> ivan: the transition request takes 1-2 weeks
23:50:10 <bigbluehat> ... so for us, getting through this is our top priority
23:50:22 <bigbluehat> ... at this moment, this has a higher priority than working on the threat model
23:50:37 <KevinDean> KevinDean has joined #vcwg
23:50:40 <KevinDean> present+
23:50:48 <bigbluehat> ... with all the timing and delays from the security review, we need to move forward without waiting on the threat model document
23:50:56 <bigbluehat> simone: the threat model has existed since march
23:51:03 <bigbluehat> ... so it's already been worked on
23:51:17 <bigbluehat> ... but now that I am working alone...it may take longer to review
23:51:26 <bigbluehat> ivan: is the plan that the review will be done by the new group?
23:51:28 <GregB> More up to date paper: Practical Post-Quantum Signatures for Privacy (https://eprint.iacr.org/2024/131)
23:51:29 <manu> q+
23:51:40 <bigbluehat> simone: yes, but the group is not formed yet
23:51:58 <bigbluehat> ivan: then I with drawl all my optimism
23:52:19 <bigbluehat> ... with all the overhead of setting up the new group...we will be waiting for weeks...if not longer
23:52:35 <bigbluehat> ... the soonest we could meet at the soonest early November
23:52:45 <bigbluehat> ... it's almost October
23:52:58 <bigbluehat> ... and then there's a review meeting...
23:53:11 <bigbluehat> ... we cannot submit the publication request without the review being done
23:53:20 <bigbluehat> ... so mid-November would be the soonest it could be on the Web
23:53:34 <bigbluehat> ... adding 30 days review...we're essentially in January...because holidays
23:53:46 <brent> q?
23:53:53 <bigbluehat> simone: I am sadly working alone
23:54:17 <brent> ack manu
23:54:21 <brent> q+
23:54:22 <bigbluehat> ... I can check with others who can possibly contribute
23:54:30 <bigbluehat> manu: I think the timelines are reasonable
23:54:40 <bigbluehat> ... given all the constraints
23:54:56 <bigbluehat> ... it would not be healthy to have a single reviewer, so waiting makes since
23:55:06 <gkellogg> gkellogg has joined #vcwg
23:55:09 <bigbluehat> ... as long as it can be one of the first things that this new group works on
23:55:17 <bigbluehat> brent: we were supposed to be done in July
23:55:22 <bigbluehat> manu: I get it...but...
23:55:26 <bigbluehat> ... this is where we are
23:55:30 <ivan> q+
23:55:31 <bigbluehat> ... everyone's doing the best we can
23:55:51 <bigbluehat> ... and the things we can do is to help find contributors to the security group
23:55:54 <bigbluehat> ... so they can start sooner
23:56:04 <bigbluehat> ... we're also throwing a lot of documents at them
23:56:17 <bigbluehat> ... and it's not a walk in the park...there's a lot going on in our group
23:56:21 <brent> ack brent
23:56:26 <bigbluehat> ... the editors are happy to help.
23:56:37 <bigbluehat> brent: in recognition, there is no security group
23:56:43 <bigbluehat> ... our request has consequently timed out
23:56:53 <bigbluehat> ... we will move forward with our documents
23:57:07 <manu> q+ to note it's fine for us to go to CR2.
23:57:13 <bigbluehat> ... because there's not security group, we are not able to wait on this group to do it's job since it doesn't exist
23:57:27 <bigbluehat> ... I'm not saying it should have somehow been done by one person
23:57:40 <bigbluehat> ... but we're in this transition where we need a review and there's no one to do it
23:57:50 <bigbluehat> ... and it's needed in the past...but here we are still needing it
23:58:01 <bigbluehat> ... my preferred course of action is to not continue to wait
23:58:09 <bigbluehat> ... let's transition our documents
23:58:25 <bigbluehat> ... with the plan to continue to do security review as this group becomes available
23:58:32 <brent> ack ivan
23:58:33 <bigbluehat> ... our charter covers security changes
23:58:34 <manu> q+ to note difficult to go beyond PR.
23:58:47 <bigbluehat> ivan: staff hat on, I'm happy to do what you say
23:58:59 <bigbluehat> ... but I fear we will be asked to wait for at least the PR publication
23:59:13 <bigbluehat> ... whether the delay happens on CR2 or PR is a technicality
23:59:21 <bigbluehat> ... so we can just submit it and see what happens
23:59:34 <bigbluehat> ... this delay will happen at some point, and this is the last minute that we can do this
23:59:47 <bigbluehat> ... so I will submit the request for the new charter to be accepted