Re: Publication of VC API as VCWG Draft Note

They are better then phone home systems.

To suggest this community hasn’t really thought about privacy and human rights considerations is really a bit much Adrian.

The earlier options protocol wise that we had for identity were all persistent identifiers and requires phoning home.

See my paper seeing SSI in historical context.

https://identitywoman.net/topics/my-papers/seeing-ssi-in-historical-context/

Sent from my iPhone

> On Nov 20, 2022, at 5:49 PM, Adrian Gropper <agropper@healthurl.com> wrote:
> 
> 
> Thanks for the context, Kalya. 
> 
> Given standardized VC's that apply to pretty much every human and every thing, VC protocols have a large potential impact on human rights. Is W3C set up to consider the human rights considerations that apply and how would they be applied?
> 
> Adrian
> 
>> On Sun, Nov 20, 2022 at 8:18 PM Kyle Den Hartog <kyle@pryvit.tech> wrote:
>> I'm hoping to help achieve consensus here by drawing attention to the previous discussions on this topic. This document was something that was discussed extensively during the formation of the charter and a few issues popped up in regard to this:
>> 
>> [1]: https://github.com/w3c/vc-wg-charter/issues/72
>> [2]: https://github.com/w3c/vc-wg-charter/issues/24
>> [3]: https://github.com/w3c/vc-wg-charter/pull/43
>> 
>> The two resulting PRs (and the links to the relevant WG call notes - H/T Ivan for getting the notes linked in each PR/Issue) that achieved consensus and led to the current charter text can be found here:
>> 
>> [4]: https://github.com/w3c/vc-wg-charter/pull/66
>> [5]: https://github.com/w3c/vc-wg-charter/pull/70
>> 
>> Reasonably based on my reading of this there's been push back and unachievable consensus on adopting this VC-API document outright, so I don't believe this is the best approach to finding consensus within the WG. From what I can tell from the discussion in PR 66, the goal here was to be able to comment on different approaches to using VCs in a variety of different protocols and APIs which everyone appears to have been alright with. This could take on various forms from my reading which include commenting non normatively within the spec itself or authoring a developer's guide specifically about using VCs in these various different protocols and APIs.
>> 
>> Based on this context, it doesn't seem like this was ever intended to be done by publishing an exact copy of the VC-API document as a note which contains normative language. In fact, by definition the very act of including normative language in this spec seems to run against the purpose of a note as defined in section 6.4.1 [6] which states, "A Group Note (NOTE) is published to provide a stable reference for a useful document that is not intended to be a formal standard". The inclusion of normative language here suggests that this is not the case and this document is intended to be standardized in the future. So, to me placing this document on the notes track rather than the standard track actually seems harmful to those who wish to actually see this work standardized, not helpful.
>> 
>>  In summary, here's my suggestion based on participation in the original chartering discussions. I'd think the best way to achieve consensus here would be to author a separate meta document that points to various approaches non normatively. That appears to have the most non contentious approach and would settle this discussion with everyone at least voting +0 or +1. 
>> 
>> [6]: https://www.w3.org/2021/Process-20211102/#Note
>> 
>> -Kyle
>> 
>> P.S. Even if this is or isn't "standardized" you're all still going to be tilting at windmills over which protocol is the best solution until you've got a sore throat from shouting into the wind. It may make more sense to start stuffing more of the "protocol" logic into the data model itself since doing this is able to achieve consensus more easily. This would have the effect that VCs will be able to work interoperably across protocols. Therefore, the "winning" and "losing" protocols present less risk to customers utilizing this technology if people place their bets wrong, and would minimize the switching costs for customers.
>> 
>>  
>> 
>>> On Mon, Nov 21, 2022 at 1:17 PM ANTHONY NADALIN <nadalin@prodigy.net> wrote:
>>> I also don't understand what the purpose of this would be since this cannot be a normative document, but in the CCG it can be a normative document and an actual specification. If it was to be a note in the working group, all normative references would have to be changed and there might be additional changes made. And since it's not a normative document, we could not do any testing on it because it wouldn't have any normative language to do testing against. Just puzzles me while we would do this.
>>> 
>>> What is emotive to submit to the working group? As a note, what do you expect to gain? To me you lose the normative aspects.
>>> 
>>> Get Outlook for Android
>>> From: nadalin@prodigy.net <nadalin@prodigy.net>
>>> Sent: Sunday, November 20, 2022 2:44:24 PM
>>> To: 'Torsten Lodderstedt' <torsten@lodderstedt.net>; 'Manu Sporny' <msporny@digitalbazaar.com>
>>> Cc: 'W3C Credentials CG' <public-credentials@w3.org>
>>> Subject: RE: Publication of VC API as VCWG Draft Note
>>>  
>>> +1 Torsten
>>> 
>>>  
>>> 
>>> I have read over the APIs and well they need a lot more work to be anything I would endorse and this WG does not have APIs in its charter and to publish as a note I don’t want to endorse these APIS w/o further work. So suggest that a new WG be formed or the VC WG charter is updated to include working on APIs. If people are using them now they can continue to use them since it does not seem that standardization matters.
>>> 
>>>  
>>> 
>>> From: Torsten Lodderstedt <torsten@lodderstedt.net> 
>>> Sent: Sunday, November 20, 2022 10:36 AM
>>> To: Manu Sporny <msporny@digitalbazaar.com>
>>> Cc: W3C Credentials CG <public-credentials@w3.org>
>>> Subject: Re: Publication of VC API as VCWG Draft Note
>>> 
>>>  
>>> 
>>> Hi Manu,
>>> 
>>>  
>>> 
>>> if there is so much support for VC API, it should be easy to get it adopted as a formal work item in the VC working group or to spin up a new working group at W3C to work on it. 
>>> 
>>>  
>>> 
>>> Why do you insist on publishing it as a note? As far as I understand W3C processes this would be a non-normative document. A normative document would be much better suited for an API specification and would have much more weight since it needs to go through to a full review and voting process. 
>>> 
>>>  
>>> 
>>> As far as I understand the current work on VC API happens at the W3C CCG, whose charter states 
>>> 
>>>  
>>> 
>>> "Our tasks include drafting and incubating Internet specifications for further standardization ...“
>>> 
>>>  
>>> 
>>> I guess VC API has reached that point.
>>> 
>>>  
>>> 
>>> best regards,
>>> 
>>> Torsten.   
>>> 
>>> 
>>> 
>>> 
>>> Am 20.11.2022 um 04:23 schrieb Manu Sporny <msporny@digitalbazaar.com>:
>>> 
>>>  
>>> 
>>> On Sat, Nov 19, 2022 at 6:11 PM Daniel Hardman <daniel.hardman@gmail.com> wrote:
>>> > Publishing such a note is thus a political move by its proponents.
>>> 
>>>  
>>> 
>>> We are documenting what is happening in the marketplace. We currently have 17 implementations of the VC API specification, at varying levels of interoperability, per the last JFF plugfest. 
>>> 
>>>  
>>> 
>>> That is many more implementations that many W3C Recommendations and IETF RFCs achieve as official global standards. 
>>> 
>>>  
>>> 
>>> This is the current reality and it is best if we document what's going on here, especially because we contemplated just that in the chartering of the VCWG:
>>> 
>>>  
>>> 
>>> <image.png>
>>> 
>>>  
>>> 
>>> Variations of the VC API have existed since early 2020 and the VC API Work Item group at CCG has existed for well over a year with weekly scribed meetings and regular participants that are also implementing:
>>> 
>>>  
>>> 
>>> https://w3c-ccg.github.io/meetings/ (search for "vcapi")
>>> 
>>>  
>>> 
>>> > The fact is that, although such a document is non-normative, it gets bundled with normative items in the minds of many, and the normative distinction is unlikely to be emphasized by VC-API proponents in their narratives.
>>> 
>>>  
>>> 
>>> The market mistaking the document as a normative W3C specification seems unlikely given this thread. Even if the proponents don't highlight that this is currently a non-normative document, I expect the detractors (all of whom are not implementers of the specification) will ensure that no one mistakes the document for an "official W3C Recommendation". I can't imagine customers looking kindly on any vendor that misrepresents the state of the open standards that they conform to and their current status in the standardization pipeline.
>>> 
>>>  
>>> 
>>> -- manu
>>> 
>>> -- 
>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>> Founder/CEO - Digital Bazaar, Inc.
>>> News: Digital Bazaar Announces New Case Studies (2021) 
>>> https://www.digitalbazaar.com/
>>> 
>>>  
>>> 
>>>