W3C home > Mailing lists > Public > public-credentials@w3.org > November 2022

Re: Publication of VC API as VCWG Draft Note

From: Adrian Gropper <agropper@healthurl.com>
Date: Sun, 20 Nov 2022 20:46:05 -0500
Message-ID: <CANYRo8h8T-=K1ewS7PZZxw-7_tEiH9B+E0+f6nj8xH-_q+0fyw@mail.gmail.com>
To: Kyle Den Hartog <kyle@pryvit.tech>
Cc: ANTHONY NADALIN <nadalin@prodigy.net>, Torsten Lodderstedt <torsten@lodderstedt.net>, Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
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 <https://aka.ms/AAb9ysg>
>> ------------------------------
>> *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/
>>
>>
>>
>>
>>
>
Received on Monday, 21 November 2022 01:46:30 UTC

This archive was generated by hypermail 2.4.0 : Monday, 21 November 2022 01:46:31 UTC