Verifiable Credentials WG Telco — Minutes
Date: 2022-03-09
See also the Agenda and the IRC Log
Attendees
Present: Ivan Herman, Oliver Terbu, Orie Steele, David Chadwick, Dave Longley, Brent Zundel, Justin Richer, Manu Sporny, Mahmoud Alkhraishi, Kristina Yasuda, Marty Reed, Dmitri Zagidulin, Charles Lehner, Gregory Natran, Ryan Grant, Kyle Den Hartog, Ted Thibodeau Jr.
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Mahmoud Alkhraishi
Content:
Brent Zundel: Agenda. 1st item: conversation about Registries in VC WG. All conversations will be about charter for 2.0. will discuss registries the PRs then issues.
Marty Reed: Intro to group, working on aligning IMS global work with this work!.
Brent Zundel: Starting by talking about registries..
1. VCWG Registries.
Brent Zundel: a number of ways we can go either 85 or 98, 98 probably a faster path to consensus.
Manu Sporny: is anyone going to object to 85? I believe it synthesises what we’ve been talking about in the group but if we want to build up to it thats fine too. 85 just tries to get it done in one shot..
Kristina Yasuda: I was going to propose we start incrementally, with the four PRs given we have a strong objection from mike..
Brent Zundel: starting with 98, this PR steals all the commits from 85 and trims it down to just a normative registries section, in support of the normative deliverables. straightforward PR with a number of approvals.
… CR from manu about the sentence that took it away from being the simple PR..
1.1. Do we want registries?.
Joe Andrieu: I don’t think we have the constitutional capability to do registries, I will not oppose the may language, but if other forks thinks registries is not the best thing for W3c to be doing then i wanted to float it..
Brent Zundel: I personally feel that registries in the vcwg will be different than didwg for a couple of reasons..
… first we dont have anything on the vc side that is equivalent to did:method, extensions and others are not quite as freeform as the did:method registries.
… most of the pain was because of the did:method registries.
… second in the did-wg we began with the did registries as a note, and didn’t have the wg process to rely on. It was inarguably painful and I believe it will be less in the vcwg.
Manu Sporny: philosophically aligned with Joe, I think people will object repeatedly until we do a registry. I agree with brent that the things that were controversial are the did:method. I think it is inevitable we will kick the can down the road, and the may protects us and we can hopefully convince people registries do not need to be done..
Orie Steele: +1 manu.
Oliver Terbu: +1 manu.
Joe Andrieu: I think in some ways it is worse to have registries with VCs, because VCs are about anyone saying anything. having a centralized registry makes it so only some people can use some terms. Not sure why we’re creating centralization in a place that should be decentralized..
Orie Steele: Evidence of existing W3C Registries… https://www.w3.org/2018/credentials/v1 … https://www.w3.org/2018/credentials/#VerifiableCredential.
Orie Steele: Another example of a W3C Registry… https://www.w3.org/ns/activitystreams.
Ivan Herman: in my view JSON-LD doesn’t solve everything. I know in semantic web world, the fact of finding the right vocab is a major issue and therefore there are places where they have collections of references to vocabs that are available for various sources. We can haggle around the terminology but what the registries give us is what are the available entries and extension points people can use. Not necessary to have them for developers maybe but end users who create VC-s.
… The other thing is you had a side remark, but W3C now has a registry process which we did not have in the did-wg.
Manu Sporny: Orie, those are namespaces, specs, etc… not registries – they’re not updated out of band w/ the spec – but we should probably move on…
A JSON-LD Context is /not/ a registry (as defined by W3C Registry).
It is a JSON-LD Context… that’s it..
Joe Andrieu: +1 to separate the specification from extension points.
Manu Sporny: It’s problematic to say that “all of these things are registries”..
Orie Steele: wanted to comment on the tech involved in v1 of vc model. there is a normative requirement for @context, if you click that term you will find w3c as a centralized entity. W3C describes what a VC is and everyone benefits from that definition. There are decentralized extensions that dont need w3c and I hear Joe say he likes that feature. W3C VCs would be useless without those centralized terms, but they also wont be useful without the decentralized parts.
… we made decisions in ignorance in did-wg, im strongly in favour of registries in w3c and strongly in favour of decentralization for extensions.
Kristina Yasuda: +1 Orie.
Brent Zundel: about halfway through the time, if any concrete proposals for moving forward lets focus on that.
Gregory Natran: Orie preempted me and I agree with what he says..
Joe Andrieu: I agree with distinction Orie made, the spec itself is a point of centralization, thats a spec not a registry, and adjustments go through open process. Extension points are not that, having registries for extension points is an orthogonal issue..
Dave Longley: +1 to Orie, +1 to Joe … all good points … but also a good point that having a “vocabulary phone book” (how I heard Ivan) is useful.
Ryan Grant: (chiming in on IRC due to audio problems) +1 to Ivan in that there appears to be a language discovery problem that eg. schema.org may not completely solve, and that’s not the right reason about registries. +1 to being even more decentralized…
Brent Zundel: will run a proposal to get a pulse from the group.
Proposed resolution: the VCWG Draft Charter will not mention Registries. (Brent Zundel)
Mahmoud Alkhraishi: -1.
Joe Andrieu: +1.
Marty Reed: -1.
Orie Steele: -1.
Ivan Herman: -1.
Kristina Yasuda: -1.
Manu Sporny: +0.2.
Kyle Den Hartog: -1.
Oliver Terbu: 0.
Justin Richer: -1.
Dmitri Zagidulin: -0.
Ryan Grant: -0.
Dave Longley: 0.
David Chadwick: 0.
Gregory Natran: 0.
Brent Zundel: appears that its Joe and a percentage of manu in support, but results are not very conclusive.
… how opposed are you to talk about PRs and getting language in with may language.
Joe Andrieu: we don’t have it in the org to manage the complexity and I really think its a bad idea due to issues im running into.
Proposed resolution: the VCWG Draft Charter will mention Registries. (Brent Zundel)
Ryan Grant: -0.21.
Ivan Herman: +1.
Kristina Yasuda: +1.
Kyle Den Hartog: +1.
Justin Richer: +1.
Orie Steele: +1.
Joe Andrieu: -1.
Mahmoud Alkhraishi: +1.
Marty Reed: +1.
David Chadwick: +1.
Manu Sporny: +0.2.
Oliver Terbu: 0.
Dave Longley: 0.
Ted Thibodeau Jr.: +0.7.
1.2. The WG may produce registries (pr vc-wg-charter#98)
See github pull request vc-wg-charter#98.
Brent Zundel: looks like we have rough agreement, we want registries in the charter for the most part.
… can you throw your approval instead of the stale CR, any opposition to merging this PR.
Joe Andrieu: I oppose, for reasons stated.
Brent Zundel: Joe your opposition is noted, and will go into the comments on the PR.
Oliver Terbu: does registries include data integrity proof registry, my concern is it should be permissive enough, and if we can get that right then I’m on board.
Manu Sporny: +1 to registry not being restrictive… it needs to be permissive..
Brent Zundel: the charter doesn’t restrict as of yet but the vcwg may restrict at a later date.
… over the noted objection from joe will merge the PR.
… two other PRs that build towards what 85 was aiming for, looking at 99 next..
1.3. A non-exhaustive set of possible registries (pr vc-wg-charter#99)
See github pull request vc-wg-charter#99.
Brent Zundel: 99 steals the table from 95, removes the input table column and says we might do some or all, its very hand-wavy.
Manu Sporny: in all the other sections of the charter, we have tried to exhaustively list the documents in the group to be clear on things we want to work on. i think this is a good idea for registries too, so AC reviewers get an understanding of our intent..
… this PR highlights a number of registries that a number of us feel are important, this PR tries to be explicit which i think is a good thing..
Kyle Den Hartog: i think its better not to be explicit because it buys us time, and allows us to re-split if we find there’s a better arch pattern for this, instead of leading with that expectation. This expectation could bite us. Would like to lead with fewer expectations than implied greater expectations..
Brent Zundel: the words non-exhaustive selection of registries is in the PR so this does not tie us to anything..
Kyle Den Hartog: yeah I saw that, but that’s where I was thinking that by still explicitly stating them we’re setting expectations from the outset which I don’t believe is necessary at this point.
Joe Andrieu: before we enshrine any particular registries i think we should put in the charter, before we name any such registries, exactly what we mean by permissive..
Oliver Terbu: +1 joeandrieu.
Manu Sporny: +1 to Joe.
Joe Andrieu: would like to enshrine the concepts of permissiveness and non-exhaustiveness.
Manu Sporny: i’d like ot push this PR a bit more, im hearing you’re opposed to it, will you object? I think we need to settle if we’re putting this kind of language in, i’d like to hear why the registries section compared to the other sections. Being vague hurt us in the did-wg, it would be best to have the discussion now, and at least come up with a core set. these are MAYs and we shouldn’t have issues at CR or REC.
Kyle Den Hartog: i wouldn’t formally object, and I don’t think i can due to invited expert status. my intent is to see it be done in a way as inclusive as possible.
Kristina Yasuda: we do have a strong objection from mike, though he is not on this call; I’m not sure if it will lead to FO but I know he has strong objections..
… I think a statement that lets put this in because it might lead to less future objections, theres already a may, and if you interpret it as it is, you can include anything, and theres nothing out of scope. You can’t say anything is out of scope. I think hearing objections of joe and kyle, I think the may statement strikes a good balance.
Orie Steele: -1 to the suggestion that “being vague” is a good idea… we have plenty of evidence that is a bad idea..
Kristina Yasuda: that’s why I said, I cannot speak for Mike.
I did not say he would.
Manu Sporny: I don’t think that speaking for others is not a good mode of communication. If mike isn’t gonna be here then anyone speaking on his behalf is problematic, and potentially stops us from reaching consensus. If people will object they need to be in the group or write to the group.
Kristina Yasuda: “I said he might but I cannot speak for him”.
please do not twist what I said.
Manu Sporny: Not trying to twist what you said – “he might” is in the same class of statement..
Manu Sporny: Ok, well, if we’re going to take that approach, then we can’t talk about registries today, can we?.
Kyle Den Hartog: I know mike has an opinion and it seems he has the strongest opinion, can we come back to this on later weeks?.
1.4. Registries and standardized entries (pr vc-wg-charter#101)
See github pull request vc-wg-charter#101.
Brent Zundel: will spend the last few minutes on 101 instead of 100.
… this adds a line to the section we just merged, that says “ registries for extension points that are mandatory to use, for any of the above normative deliverables (for example, Verifiable Credential properties that MUST be included in … must have one standardized entry”.
Kyle Den Hartog: a must for required properties and a should for optional, allows us to get to a more solid ground. This lets us define how extension points work in an interop way.
Joe Andrieu: My question is what does standardized mean?.
Kyle Den Hartog: +1.
Joe Andrieu: all but one SO calls their standards standard, we need to clarify that language to know what it means..
Kyle Den Hartog: we can replace with REC Track document.
Kyle Den Hartog: ahh yeah makes sense.
Dave Longley: “REC track or equivalent level?”.
Brent Zundel: we cant say rec track because it might be from IETF or ISO, there is a general understanding and it may be defined somewhere.
Ivan Herman: See “normative references” for W3C.
david: don’t think it makes sense to have a must or a should for registries, if you take terms of use the semantics of it is very broad..
… to say you should/must doesn’t make sense when the semantics are wide..
Orie Steele: Should we even be using BCP14 language on ANY charter item? - https://github.com/w3c/vc-wg-charter/pull/101/files#r822616764.
Manu Sporny: we can use the same definition, for making a normative reference in the w3c and thats a well known tried and true mechanism. I agree with david chadwick said, I was under the same impression that terms of use status etc, but this PR does not apply to them. This only applies to the proof block. We’re saying if you’re using an embedded proof, you need ot use a REC track entry. IDK if others had this same understanding, this applies to almost no entry except the proof block.
Ivan Herman: manu almost said but normative reference in w3c recommendations says which kind of document I can refer to normatively, which covers the various things Joe wants, and that is very appropriate add a reference to in the charter..
Kyle Den Hartog: for this PR its probably beneficial to not talk about the should but leave open the issue for optional properties, i think there’s consensus on the must aspect. I think the issuer property needs to be more strongly defined, in how we dereference it to Public key materials, which will affect the proof properties.
Joe Andrieu: this does only apply to normatively defined properties but it binds the group in what i think is a bad idea. it means we can’t define a normative field that doesn’t have a predefined process. I think making it mandatory is premature..
2. VCWG Charter - PRs.
Brent Zundel: VCWG Charter - PRs.
Brent Zundel: https://github.com/w3c/vc-wg-charter/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc.
Brent Zundel: moving to general PRs.
2.1. renaming a deliverable to “Securing Verifiable Credentials 1.0” (pr vc-wg-charter#102)
See github pull request vc-wg-charter#102.
Brent Zundel: 6 approvals no CRs any opposition?.
Manu Sporny: +1 to merge this.
Oliver Terbu: +1.
Brent Zundel: merged..
2.2. Clarify that DI should focus on VCs but ensure generality. (pr vc-wg-charter#96)
See github pull request vc-wg-charter#96.
Brent Zundel: PR 96 clarifies that DI should focus on VCs but ensure generality.
Manu Sporny: this came out of something jeremie miller said, the way I read the charter data integrity isn’t in scope at all. That was concerning to me, is because we’ve been trying to get DI in scope for a while. People still believe the stuff that is in scope isn’t. When it isn’t in scope people are literally reading the charter, so the DI is only for VC. The danger is people in WG get the impression that we’re doing a point solution for VC when it can be used beyond that.
… to generalized tech. The misinterpretation is concerning to me. The language is making it clear the wg is not harming the generality of the DI solution. We can point to the minutes..
Ivan Herman: some of us have gone through a long and excruciating discussion with the semantic web community where this doc was going through another wg charter. I don’t remember the number of emails but it went well over 100. The core problem that we hit was to say “if you want to solve DI in general, the consider X,Y,Z issues too” which included things like how do you secure integrity of google’s knowledge graph..
… the basic argument is what works for relatively small graphs, does not scale to a bigger one. if we want to go to generality we need to make a statement about what it applies to. In the end is we decided that it will not fly, the message we got back is do it for VC because thats what this group has an expertise in..
Dave Longley: well bounded graphs / datasets.
Ivan Herman: my big fear is if we go down that way we will get FO from members who care about this; we should not open the flood gates..
… perfectly fine if we say “members of this group should not put in obstacles for generalization” but that is crazy, because nobody would do that anyway. As far as i’m concerned we’re going down a dangerous road and charter is good as is..
Brent Zundel: i felt roughly the same until i read the PR. I fear the floodgates being open, but i don’t think the language does that..
Orie Steele: I think the language is helpful, its better to be more explicit, we know in these cases, that the two formats embedded and external both secure data. Both formats have been applied to things other than VCs, if we’re objecting to this language we’re making an absurd statement about the usage of some of the tech in wider scope..
Manu Sporny: I think just asking hte question in the group is also helpful. Security VCs is the handwavy name, my expectation is we’re not going to try to shove VC JWT, integrity etc, into a single spec..
… is anyone here intending to make the DI spec a point solution for VCs? If no one is speaking up, then we have no intent in the group to do that..
… modified the language to focus on VCs and well-founded data sets.
Kyle Den Hartog: the one thing i’d says is we should double check with jeremy as he is dissenting but not on the call.
… I’m stating it because it was for the purposes of gaining an understanding without actually forcing FOs.