21:54:58 RRSAgent has joined #vcwg-special 21:55:02 logging to https://www.w3.org/2023/07/18-vcwg-special-irc 21:55:55 brent has changed the topic to: VCWG Special Topic Call: https://www.w3.org/events/meetings/eaf86734-c2f9-410e-86b9-1cca18d0d6c9/20230718T180000/ 21:56:03 zakim, start the meeting 21:56:03 RRSAgent, make logs Public 21:56:35 please title this meeting ("meeting: ..."), brent 21:56:35 meeting: VCWG Special Topic Call 21:56:35 chair: Brent Zundel 21:59:14 hsano has joined #vcwg-special 21:59:41 selfissued has joined #vcwg-special 21:59:46 present+ 21:59:48 mprorock has joined #vcwg-special 22:01:26 present+ 22:01:36 present+ 22:01:59 present+ 22:01:59 present+ 22:02:06 present+ 22:02:09 present+ 22:02:12 present+ 22:02:17 JoeAndrieu has joined #vcwg-special 22:02:26 scribe+ 22:02:34 present+ 22:03:03 brent: greets everyone with an introduction to the topic of the day, which is PR review 22:03:25 brent: status list, then data integrity, then data model - any others? 22:03:45 Topic: PRS 22:03:48 brent: the goals are how do we unblock and move to consensus 22:03:49 subtopic: https://github.com/w3c/vc-status-list-2021/pull/69 22:04:00 s/PRS/PRs/ 22:04:07 scribe+ 22:04:27 brent: What is this PR trying to do, what are next steps? 22:04:58 mprorock: The goal here was to get stuff pointing at the v2 stuff for the most part, some items were still pointing at other items. 22:05:59 q+ 22:06:01 mprorock: Because we now have status list available under v2 of VCs, do we need to explicitly call out things by year, for example StatusList2021Entry vs. StatusListEntry. I believe we saw call out for explicit version, a little indifferent, as long as you're pointing to v2, great, also totally fine in status list explicit property v2.0, goes along w/ v2.0 VCs, fine, open to thoughts here. 22:06:05 ack dlongley 22:06:11 Orie has joined #vcwg-special 22:06:27 +1 to not adding a "version prop" 22:06:32 present+ 22:07:00 dlongley: can live without a version in type names - would prefer versioning other than via properties - does not think that the version is sufficient in cases of future context changes 22:07:04 q+ 22:07:56 ... years makes sense for things that have a shelf life, less sense in things that don't, perhaps we use a differentiating feature or otherwise in the type name to differentiate 22:08:00 ack manu 22:08:29 manu: not broadly implemented and deployed yet, so we have some flexibility 22:08:30 q+ 22:09:21 ... uncomfortable removing versioning especially with breaking changes. -1 to not having some version specifically for this reason 22:09:27 feels like using `@type` for versioning is the same thing as "sniffing json members" for version info... 22:10:24 ... options include specific naming of status list such as 'BitStringStatusList' or something very specific, or include a version on the type, context v2 is not enough to determine type 22:10:29 Orie: the type of a thing largely defines what something is -- so i think if we're going to change what a thing is (different properties, features, core meaning, so on), it makes sense to signal that through type. 22:10:53 ... very uneasy with taking all versioning off of this 22:11:14 decentralgabe has joined #vcwg-special 22:11:17 present+ 22:11:17 Yeah, makes me wonder why https://schema.org/Organization is not https://schema.org/Organization2023 22:11:31 ... have gotten feedback from one implementer that they don't want to continue to use 2021 for current version 22:11:50 Orie: i wouldn't expect Organization to have significant breaking changes over time, only additive 22:11:54 ack mprorock 22:11:56 ... title of the spec changing to 2.0 when there wasn't a version 2.0 seems odd 22:12:00 q+ 22:12:17 Orie: and Organization is very generic ... so matches its name... "StatusList" is a pretty specific BitString-related status list thing. 22:12:28 Orie: not a generic "StatusList". 22:13:33 q+ 22:13:37 mprorock: I'm fine w/ a property based versioning approach, versioning in the name itself feels odd to me, because then you're switching on strings, never really a right answer. Totally fine w/ keeping some versioning, so what Manu and Dave are bringing up is fine... where is that done, in a property, name of type, somewhere else? 22:13:46 ack TallTed 22:15:02 +1 TallTed.. versioning is lost when context is applied... unless its on the type.... it implies heavier RDF work. 22:15:13 +1 to TallTed 22:15:28 TallTed: versioning good, versioning with years not so good, versions in name of context file is problematic as it disappears once it resolves through the context, putting the version on the type means that we should build range and domain attribute lists for these types and then those attributes need to update with changes, putting versioning on attributes itself might be worthwhile if we are changing the def of an attr 22:15:43 ack dlongley 22:15:53 ... nothing is simple and when we see interdependencies that complexity around versioning gets more complex 22:16:51 dlongley: what we see in the future will determine best path - statuslist is very generic - we could keep that, or we could get more specific around naming based on how this status list operates 22:16:54 q+ 22:17:20 ... feel like we are running into trouble because the name we chose is so general 22:17:35 q+ to ask about next step 22:17:35 q+ 22:17:38 ack manu 22:17:44 ... if we are just adding backwards compat changes in the future then this is fine, but that might not be the case 22:18:28 ack mprorock 22:18:31 q+ manu 22:18:37 mprorock: I kinda like where Dave is going with this, I think he's on to something and that's already caused some open PRs over StatusList because the name is general. I'm totally fine if we settle on a name that is specific and reflective that doesn't have a name/etc. BitsStringstatusList might be a good way to do this, it's not perfect, but at least it narrows things down. fine with that as a path forward. 22:18:41 ack brent 22:18:41 brent, you wanted to ask about next step 22:18:58 Why didn't we version VerifiableCredential and VerifiablePresentation ? 22:19:01 ack manu 22:19:05 brent: next step? proposed path forward of getting more specific with naming? any opposition? 22:19:28 Orie: they are generic enough and you can add lots of things to them without issue 22:19:30 manu: would feel differently if we were 5yrs in and things were very stable 22:19:56 So same argument as Organization... and as StatusList... now... 22:20:12 Orie: yes, except this "bit string status list" thing we have isn't a generic "status list". 22:20:18 ... raising concerns since this is very fresh and new, would prefer a version in the type as the easiest path to prevent collisions between versions 22:20:49 ... need a mechanism to identify expected properties, and then we expect only backwards compat changes 22:21:08 Orie: we could create a base StatusList type that has nothing on it ... and then extend that with a more specific type with more requirements... or just not bother with a base type like that here. 22:21:14 ... better than nothing if we accept very specific naming 22:21:34 subtopic: https://github.com/w3c/vc-data-integrity/pull/99 22:21:35 brent: feel like we have a possible path forward 22:22:06 brent: Orie, please give an overview of the pr 22:22:42 Orie: DI has some excellent stuff that is not specific to data integrity, notably controller descriptions especially of did docs 22:23:22 ... *snark about did working group* 22:23:43 ... the did working group did not define key representations or shapes 22:23:58 ... as a result of that almost all did methods have undefined terms 22:24:25 ... this PR addresses one of the predicates and recomends public key JWK as a path 22:24:41 ... there is dispute over the best way of representing keys in json-ld 22:25:01 ... the counter proposal appears to be do the same as did working group and don't specify 22:25:02 q? 22:25:02 q+ 22:25:07 ack manu 22:25:33 manu: think that the group has been clear that we should not prefer one approach or format over another 22:25:44 key material can secure both proof formats 22:25:57 +1 there's no consensus to prefer one key material over the other ... people want different things. 22:25:58 ... this PR prefers one key format over others, and feels inappropriate 22:26:00 preferring key formats would help all securing mechanisms 22:26:14 +1 let's not spend time on that disagreement again. 22:26:50 ... the other issue is that the did wg did spend a lot of time trying to improve mistakes around publishing key material, and this pr removes some guidance that could permit an implementer to publish private key material 22:26:52 q+ 22:27:07 its easier to publish multikey material with mistakes... since multikey is not a defined key format... 22:27:15 ... we should have the ability to ensure that errors are thrown when errors or leakage is detected 22:27:43 ... do agree that we should make things better, but don't think this pr makes things better 22:27:52 ... and think it removes sec guidance 22:27:53 ack mprorock 22:28:50 mprorock: I think Manu's speaking to an important point, especially because we're talking about Data Integrity and this spec and security data in general, while I have approved this PR and think that this is a good path forward, I do agree that we should also explicitly call out items and not remove items that deal with accidents we know happen in the wild. Specifically, inclusion of 'd' in a public key, just grep Github. 22:29:21 mprorock: There are things we should be careful about, we know people do bad things, we want to add back in some of these language that provides security guidance. 22:29:49 q+ 22:29:53 brent: is there a path forward for this PR and are there next steps 22:29:53 ack Orie 22:30:19 Orie: agree with comments regarding avoiding preference - might consider applying those comments more generally 22:30:21 dmitriz has joined #vcwg-special 22:30:34 q+ 22:30:41 present+ 22:30:48 ... for this PR is the sentence regarding encoding of JWK good enough, or should we carry over items from did wg 22:31:01 ... if text comes in as "may" is that actually an improvement 22:31:26 ... concerned regarding standardization path for other formats 22:31:49 ... potentially this pr should have been raised in the core data model 22:31:55 q+ 22:31:58 ack manu 22:32:01 q+ to say improvements should be made where possible and not race to the bottom if there's something we're able to say about one thing and not another 22:32:29 manu: we should be specific in security guidance. the text in red that is being removed is good text and stuff that should be said 22:32:57 ... this pr is not specific enough about what private info accidentally is leaked 22:33:22 ... the kid value items are important, and should be aligned with vc-jose-cose 22:33:41 ... should take a look at fingerprinting and compound key identifiers 22:33:57 ... agree that we should make this better, but deleting this stuff is not the way 22:34:09 Sometimes saying less, is "making things better". 22:34:24 ... disagreement is on whether or not this PR makes improvements 22:34:47 ... and over preference between multibase and jwk 22:34:53 ack mprorock 22:34:56 ... but not in this case. :) 22:36:26 mprorock: There are shades of what turned out to be a painful PR, which was the context integrity related items that came up initially in the JOSE/COSE spec, initially. We said yes, big enough issue to open issue on vc data model side... this feels a bit like that to me, particularly when we're talking about most of this, ZKPs, basically we can refer to what we're doing w/ VCs as dealing with public key crypto... so if that's the case, we should 22:36:26 pull top level guidance into security considerations ... take areas that are deleted, put them into core data model explicitly and PR on data integrity that points to that. 22:37:12 mprorock: I have similar concerns around multibase, but to me, there are other things in this PR that do merit a bigger look... next steps, pull this stuff up to security guidance and reference it clearly in VC COSE JOSE and then we're setting model on how to do this stuff right, especially when we know there are issues, good thing to do. 22:37:35 mprorock: While my preference is to rely on JWK, but rest of WG has to come to consensus on how to talk about that, fine for certain users and not ok for others. 22:37:36 q+ 22:37:41 ack dlongley 22:37:41 dlongley, you wanted to say improvements should be made where possible and not race to the bottom if there's something we're able to say about one thing and not another 22:38:03 dlongley: general comment - if we have 3 diff approaches, we should give the best advice we can about each approach 22:38:08 Our did:key implementation supports both key formats, https://did.key.transmute.industries/ speaking as an implementer... I consider this a huge waste of time, now... given did:jwk is simpler and supports x509 extensions... I think recommending experimental stuff is generally a bad idea. 22:38:31 ack manu 22:38:33 ... we should be as even handed as possible, and that doens't mean that we will say the same number of things about each item 22:39:01 manu: support for good security guidance should stay in, should get better, and we should see if we can get it in the core spec 22:39:50 ... that may be difficult, because then we are talking about securing methods in the core data model, but is worthwhile 22:40:10 multikey does not even support expressing private keys for NIST curves.... thats how safe it is. 22:40:22 ... we should make sure that errors are thrown always when things like private key material is encountered when it shouldnt be 22:40:38 subtopic: https://github.com/w3c/vc-data-model/pulls 22:40:49 brent: look forward to seeing where this goes and i will be looking for an issue on the main spec 22:40:52 Orie, not true: https://github.com/multiformats/multicodec/blob/master/table.csv#L171 22:41:15 subtopic: https://github.com/w3c/vc-data-model/pull/1203 22:41:26 q+ 22:41:38 ack manu 22:41:40 brent: feel like this is a promising pr, manu, please give an overview 22:42:09 manu: this PR is an attempt to apply the day 3 resolution and would get rid of 11xx 22:42:35 ... this is a way of giving implementers a way to show that they are compatible with the VC ecosystem, with measureable items 22:42:36 s/11xx/1100 and 1101/ 22:42:37 q+ 22:43:23 ... includes things like stating that "you have a way of converting to base data format in the spec, is it one way or bi-directional, preservation of context, etc" 22:43:40 ... tried to use language that makes that happen while avoid problematic areas 22:44:02 ... doesn't mandate a test suite but says you should do that, similar with semantic best practices, etc 22:44:38 ... CRs to date include talk about media types, possibly registered media types so there is some level of review, also requests to not downgrade refs 22:44:59 ... good healthy discussion - not seeing crazy objections yet 22:45:02 q? 22:45:09 q+ 22:45:14 identitywoman has joined #vcwg-special 22:45:17 present+ 22:45:19 ack mprorock 22:45:20 brent: sees current CRs as heading in positive direction 22:46:26 q+ to ask if pointing to VC specs dir is sufficient? 22:46:56 mprorock: I know Manu you stated that you're not so hopeful, I am hopeful of the PR, like direction, only changes I'm requesting is be specific about registered media types and include references to that stuff and not downref. There is a bit of conflict, lots of cool stuff going on in ecosystem, not all of it is standardized, but what we're putting in a TR, we should be as tight as possible while trying to be as inclusive as possible. I think I 22:46:56 only requested two words changed so far, while I would prefer not to see downrefs and examples, but that's not going to be blocker. Blocker for me is pointing to registered media types so we can be clear about what we're talking about. 22:47:00 ack JoeAndrieu 22:48:12 q+ to note "not to standard of VCWG" and "compatible with the VC Ecosystem" 22:48:12 JoeAndrieu: apologies for being the wrench on this PR, but we created together something called verifiable credentials, and calling something else a VC creates a path where someone will end up calling things a VC that don't meet the bar of VCs and that this will not create an ecosystem as the term will become meaningless with broad use 22:48:18 ack brent 22:48:18 brent, you wanted to ask if pointing to VC specs dir is sufficient? 22:48:19 +1 to what Joe is saying, but i think this PR says "compatible with the VC Ecosystem" 22:48:20 https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-2 22:48:29 "An Issuer-signed Credential whose authenticity can be cryptographically verified. Can be of any format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [VC_DATA] and [ISO.18013-5]." 22:48:44 ack manu 22:48:44 manu, you wanted to note "not to standard of VCWG" and "compatible with the VC Ecosystem" 22:48:46 brent: would links to VC specs dir be a palatable step forward 22:49:13 manu: don't see the change to registered media types as being a big change to make 22:49:14 q+ 22:49:22 hey at least a bar exists : ) thats better than did methods XD 22:49:28 manu: want people to know that it is a bit of a low bar 22:49:59 ... talk about gordians and acdcs but i don't see that as a downref - downref does not come into play for non-normative 22:50:00 +1 to what Manu is saying about refs. 22:50:03 q+ to note that you can link to things with consensus 22:50:04 +1 manu 22:50:12 +1 Manu 22:50:16 ... hard to formally object to that, etc 22:50:42 ... the way we talk about other specs is purely informative intentionally to avoid that 22:51:22 ... fairly easy to point to refs, and we would do that in a non-normative way 22:51:53 ... *funny quip about being able to sue anyone for anything* 22:52:23 ... to adress Joe concerns, the PR says that people can say that they are compat with the VC ecosystem 22:52:40 ... but after transformation they must end up with VC per core data model 22:52:48 q+ 22:52:58 q- 22:53:28 q+ to say the request I've asked in Github is the language that says one can call those other things a "Verifiable Credential" 22:53:47 ... tried very hard to make it clear that you must be able to convert to a vc and then you can say that the transformed thing is a VC 22:53:53 ... and therefore you are compat 22:53:59 ack mprorock 22:55:01 mprorock: Manu, stated all that extremely well, this is difficult language to write as we've seen from multiple prior PRs dealing w/ same topic. I am thankful that you have noted point about downrefs, those examples are purely informative, I do have issue including things that might not gain traction... we should point to where are they specified... for registered media type, you have to point /somewhere/ while it's a low bar, at least it's a bar. 22:55:42 mprorock: We also know because we've defined proper media types into what you've converted into, so notion, obviously if you convert into something you have into core data model, that IS a VC, pointing out compatability. I'm happy to approve PR if those things go in. 22:55:50 ack Orie 22:55:50 Orie, you wanted to note that you can link to things with consensus 22:55:53 brent: basically at time, two more on queue 22:55:53 Ok, so I'm noting -- add references, registered media types -- can do. 22:56:18 Orie: support adding registered media types 22:56:27 ... think we should have refs from examples 22:56:42 and it's important that the transformation is to the appropriate base media type (not to "the data model" which is abstract) 22:56:49 q+ to note, I can make those changes that Orie and MikeP noted, I think they'll go through. 22:57:02 ... regarding digital credential formats and verifiable credentials - people are using those things interchangably today 22:57:06 application/vc doesn't exist! 22:57:15 exactly 22:57:15 ack JoeAndrieu 22:57:15 JoeAndrieu, you wanted to say the request I've asked in Github is the language that says one can call those other things a "Verifiable Credential" 22:57:25 ... and we should be very careful to avoid the structured suffix conversation in this pr 22:57:59 -1 to call the untransformed thing a VC 22:58:13 +1 to call the result of the conversion a VC 22:58:18 +1 to Joe 22:58:19 manu: request specific language that says that once it is converted it is a VC, but it may not or is not a VC before conversion 22:58:21 JWT is not a VC in that interpretation 22:58:24 pretty sure that's not the intention of the PR. I didn't see that, so I'm confident the language can be tweaked 22:58:34 SD-JWT is also not a VC in that interpretation 22:58:55 manu: think these things are doable - add refs, add registered media types, and add clarification on what it is a VC 22:58:55 tranforming != secuing 22:58:58 but good luck 22:59:06 Orie: JWT-secured VC may be acceptable language to people, i don't know. 22:59:14 brent: remains confident 22:59:39 brent: loving collaboration because we are all awesome 22:59:50 ... please review the other 12 prs on core data model 22:59:59 ... hopefully see everyone tomorrow 23:00:02 SD-JWTs are JWTs 23:00:07 ... everyone is awesome 23:00:27 zakim, who is here? 23:00:27 Present: selfissued, TallTed, mprorock, dlongley, brent, shigeya, hsano, manu, JoeAndrieu, Orie, decentralgabe, dmitriz, identitywoman 23:00:29 On IRC I see identitywoman, dmitriz, Orie, JoeAndrieu, mprorock, selfissued, hsano, RRSAgent, Zakim, brent, TallTed, dlehn, csarven, shigeya, stenr, manu, dlongley 23:00:33 VC-bearing JWT. the VC is held within the JWT. 23:00:55 zakim, end the meeting 23:00:55 As of this point the attendees have been selfissued, TallTed, mprorock, dlongley, brent, shigeya, hsano, manu, JoeAndrieu, Orie, decentralgabe, dmitriz, identitywoman 23:00:58 RRSAgent, please draft minutes 23:01:00 I have made the request to generate https://www.w3.org/2023/07/18-vcwg-special-minutes.html Zakim 23:01:07 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 23:01:07 Zakim has left #vcwg-special 23:01:07 rrsagent, bye 23:01:07 I see no action items