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

Re: Publication of VC API as VCWG Draft Note

From: ANTHONY NADALIN <nadalin@prodigy.net>
Date: Mon, 21 Nov 2022 00:14:24 +0000
To: 'Torsten Lodderstedt' <torsten@lodderstedt.net>, 'Manu Sporny' <msporny@digitalbazaar.com>
CC: 'W3C Credentials CG' <public-credentials@w3.org>
Message-ID: <PH7PR14MB5690F388B4771341724E3CDEAA0A9@PH7PR14MB5690.namprd14.prod.outlook.com>
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,


Am 20.11.2022 um 04:23 schrieb Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>:

On Sat, Nov 19, 2022 at 6:11 PM Daniel Hardman <daniel.hardman@gmail.com<mailto: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:


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)
Received on Monday, 21 November 2022 00:15:04 UTC

This archive was generated by hypermail 2.4.0 : Monday, 21 November 2022 00:15:05 UTC