RE: Chairs' decision on VC-ACDC Proposal

In Miami we didn't decide what work items we should pursue.  Nothing in the Miami resolution talks about that.

The ACDC proponents can still define a mapping per the resolution that makes ACDCs VCs.  That's true whether or not the working group decides to adopt an ACDC work item.

In terms of the chairs' decision about adopting the ACDC work at this time, there were three -1s and lots of 0s on the proposal.  That's why the chairs decided that there wasn't consensus for the proposal to pass.  That is independent of the agreement made in Miami.

   Best wishes,
   -- Mike

-----Original Message-----
From: Personal Sam Smith <sam@samuelsmith.org> 
Sent: Tuesday, March 21, 2023 8:24 AM
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: public-vc-wg@w3.org
Subject: Re: Chairs' decision on VC-ACDC Proposal

In Miami we discussed a path for other external proof formats to be "compliant" which came down to a sufficient requirement that the external proof format provide a one way transformer to a compliant VCDM in json-ld with @context.

In the discussion around the vc-acdc proposal last week, it was argued by those opposed to vc-acdc as an external proof format that there was no need to name vc-acdc as a work item because merely by providing a one-way transformer then vc-acdc would be compliant. Several members of the community argued against this interpretation.  Of course, if that interpretation were true then vc-jwt does not need to be a named external proof either to be compliant. 

This then leaves the interpretation of the compromise in Miami in disarray. Which interpretation is correct?  I can't tell. The vc-acdc proposal followed what I thought was the agreed upon path to complaince as an external proof, but apparently as the first interpretive test of the compromise that agreed upon path failed because the community could not come to rough consensus on how to apply the compromise.

I now think it entirely premature to go to feature freeze given we do not evidently have consensus over the interpretation and practical application of the "compromise".



> On Mar 21, 2023, at 07:58, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On Tue, Mar 21, 2023 at 4:18 AM ProSapien Sam Smith <sam@prosapien.com> wrote:
>> So much for a big tent. Given that the -1s came from those companies that directly benefit from vc-jwt only and not others, it seems that any rough consensus will be impossible in the future for any variant of a big tent.
> 
> Editor hat on, company hat off: I defer to the decision made by the 
> Chairs; having the Chairs call "rough consensus" when there is a lack 
> of W3C-style consensus is the process the WG agreed to follow.
> 
> Editor hat off, company hat off...
> 
> I thought we were following the BCPs of "rough consensus" defined in
> RFC2418 and RFC7282:
> 
> https://www.rfc-editor.org/rfc/rfc2418#section-3.3

> https://www.rfc-editor.org/rfc/rfc7282

> 
> If the Chairs could share their reasoning, that might help enlighten 
> the group? Is this a note of a temporary lack of rough consensus, or 
> is this a final decision?
> 
> I share Sam's concerns regarding the external messaging here: "a 
> perceived gatekeeping of external proof formats by a vc-jwt 
> minority"... which Christopher touched upon last week. How are we 
> intending to have a level playing field here?
> 
> -- 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 Wednesday, 22 March 2023 15:15:16 UTC