Re: Request for CCG Chair Intervention in CCG Process

To be crystal clear,

If the working group consensus is determined to be X, as an editor I will
implement whatever X is when directed to do so by the chairs.

Until that time, I will keep pointing out that there is no consensus, but
ultimately, that's not for ANY editor to decide...

In these matters it's the chairs who make such calls.... not editors.

The chairs could say 51% is enough, they could say 80% is enough.

It is the chairs responsibility to identify what constitutes consensus when
it's disputed, and to help the group move on if that's what consensus
should be defined as for this particular case.

Editors can't do that, it's a conflict of interest.

This is a good example of why having chairs and editors that are not the
same people, or acting in the same capacity is important.

Chairs should decide a winner, or split the work item so everyone is
equally unhappy :)

Splitting the work item is a solution of last resort, since it weakens its
usefulness and limits contribution, admitting that the group couldn't
handle basic api security recommendations sends probably not the signal we
were all hoping for... but it is an accurate reflection of the current
state of the work.

With my Transmute hat on.... I would much prefer to just see GNAP and RAR
moved to an out of scope section.

GNAP and RAR are supported by a vocal minority, and not supported by any
existing implementers, on the last call I heard Transmute, Mesur,
SecureKey, Mavenet, Digital Bazaar say they are not planning on supporting
GNAP / RAR.

I heard Adrian claim he was implementing the API.

I have heard nothing from Danube Tech or Mattr, they appear to be unable to
attend the calls at the current time.

I did not hear anyone say they were planning on or seeking interoperability
using GNAP or RAR, other than Adrian.

Chairs please advise the group how to proceed.

OS

On Thu, Aug 19, 2021 at 3:31 PM Wayne Chang <wyc@fastmail.fm> wrote:

> Good to hear, sounds like we’re reaching consensus to descope
> authorization protocols from this work item, but this does not prevent
> further derivative work items nor notes on authorization protocols within
> this work item—including proper caution regarding production deployments
> that forgo an appropriate one. Thanks everyone, I will be reviewing
> consensus at the next weekly call.
>
> On Thu, Aug 19, 2021, at 3:57 PM, Adrian Gropper wrote:
>
> I'm in favor of Orie's suggestion. The issue of authorization protocols
> crosses many CCG and SSI work items and would best be discussed in a
> broader group than VC-HTTP API. Please see
> https://github.com/decentralized-identity/waci-presentation-exchange/issues/93#issuecomment-901512330
> for some details.
>
> - Adrian
>
> On Thu, Aug 19, 2021 at 3:39 PM Mike Prorock <mprorock@mesur.io> wrote:
>
> Orie,
> I would request you revisit the following link included in the prior email
> from the Chairs: https://www.w3.org/2020/Process-20200915/#Consensus
>
> Quoting:
> "Where unanimity is not possible, a group should strive to make consensus
> decisions where there is significant support and few abstentions. The
> Process Document does not require a particular percentage of eligible
> participants to agree to a motion in order for a decision to be made. To
> avoid decisions where there is widespread apathy, (i.e., little support and
> many abstentions), groups should set minimum thresholds of active support
> before a decision can be recorded. The appropriate percentage may vary
> depending on the size of the group and the nature of the decision. A
> charter may include threshold requirements for consensus decisions. For
> instance, a charter might require a supermajority of eligible participants
> (i.e., some established percentage above 50%) to support certain types of
> consensus decisions."
>
>
> Michael Prorock
> CTO, Founder
> mesur.io
>
> On Thu, Aug 19, 2021, 14:57 Orie Steele <orie@transmute.industries> wrote:
>
> > Should they be removed entirely, as well?
>
> Yes, PRs for resolutions that have objections should not be merged.
>
> Editors are responsible for implementing consensus and acknowledging when
> it does not exist.
>
> As an editor, based on my experience on the calls, I recommend the
> chairs direct the editors to move API authorization out of scope for the
> work item and into a separate document, that can explain the pro's and
> con's of GNAP and OAuth, and have the main spec simply refer to that
> document, and note that the working group could not agree to any normative
> requirements regarding securing HTTP APIs.
>
> Perhaps new work items called "vc-http-api-with-gnap" and
> "vc-http-api-with-oauth", or similar.
>
> As an implementer, Transmute has no plans to support GNAP at this time,
> and we can't afford to participate on a work item that bundles support for
> it as a requirement.
>
> If other implementers feel the same about OAuth2, the only option I can
> see is to not discuss either in the VC-HTTP-API work item calls.
>
> OS
>
>
>
>
> On Thu, Aug 19, 2021 at 12:06 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
> Thank you for the quick and thorough response. I believe the other two
> resolutions made that day do not meet the criteria for group consensus.
> Should they be removed entirely, as well?
>
> - Adrian
>
>
> On Thu, Aug 19, 2021 at 12:50 PM Heather Vescent <heathervescent@gmail.com>
> wrote:
>
> Dear Community,
>
> At CCG, all decisions should be driven by consensus of the community for a
> particular work item. As a W3C community group, we have the W3C processes
> at our disposal, but these are as a best practice, not a requirement if
> another process is in the best interest of the community. In this case we
> refer to consensus from this document:
> https://www.w3.org/2020/Process-20200915/#Consensus
>
> In the topic of VC-HTTP-API and GNAP, both sides have been collaborating
> in good faith despite opposing perspectives. Based on discussion of this
> issue and review of it by the three CCG co-chairs, we offer the following
> clarifications:
>
> 1) We believe as chairs that most importantly all parties are acting in
> good faith, and we ask the community to extend that good faith to each
> other especially with those with opposing viewpoints.
>
> 2) The work item escalation processes is first to raise objections to the
> work item spec editors (in this case: Manu Sporny, Markus Sabadello, Mike
> Varley, Orie Steele, Mahmoud Alkhraishi). If this does not result in a
> resolution or there is a principled objection, the escalation can be
> brought to the CCG Chairs.
>
> 3) While there is a formal process to approve an official CCG work item;
> we do not have formally defined operational requirements for individual
> work items. The chairs will document the escalation process described above
> (#2) in the work item process document:
> https://w3c-ccg.github.io/workitem-process.
>
> 4) We as chairs do not believe based on call transcripts and github
> discussions that the "RESOLUTION: One of the authorization mechanisms
> defined for the VC HTTP API MUST be GNAP" has group consensus, and as
> chairs recommend removing it entirely.
>
> 5) We as chairs recommend in the future as a best practice that any PRs be
> separated with a single PR per resolution wherever possible.
>
> The chairs believed a reasoned and swift response was in the best interest
> of forward momentum of the work.
>
> - The CCG Chairs
> Heather, Mike & Wayne
>
> On Thu, Aug 19, 2021 at 7:52 AM Mike Prorock <mprorock@mesur.io> wrote:
>
> The chairs are meeting today to begin discussion on the issue.   We will
> try and be timely with a response.
>
> Michael Prorock
> CTO, Founder
> mesur.io
>
> On Wed, Aug 18, 2021, 21:31 Joe Andrieu <joe@legreq.com> wrote:
>
>
>
> On Wed, Aug 18, 2021, at 2:52 PM, Manu Sporny wrote:
>
> This is a request for intervention by the CCG Chairs on a CCG Process
> question
> that has been raised in the VC HTTP API Work Item group.
>
>
> Yes, please.
>
> I answered Manu's latest in Github. You can find my position articulated
> at https://github.com/w3c-ccg/vc-http-api/pull/224#issuecomment-901536833
>
> TLDR: subgroup/task force call facilitators should not be free to
> manipulate voting processes. Especially when doing to with the express
> purpose of bypassing consensus. Spectext without consensus should not be
> merged.
>
> The chairs are the appropriate authority for resolving this impasse.
>
> -j
>
> On Wed, Aug 18, 2021, at 2:52 PM, Manu Sporny wrote:
>
> This is a request for intervention by the CCG Chairs on a CCG Process
> question
> that has been raised in the VC HTTP API Work Item group.
>
> The crux of the issue is that there are some in the VC HTTP API Work Item
> group that believe that there is no clear escalation process for resolving
> decisions that are unable to achieve group consensus.
>
> Some have asserted that the definition of "consensus" is not clear and that
> the CCG does not necessarily follow W3C Process (because it has created its
> own bespoke rules over the years).
>
> A recent attempt at polling for consensus, and then when that failed,
> backing
> off to a majority vote of those present, and when that failed, using a
> simple
> majority vote of those that were present:
>
> https://w3c-ccg.github.io/meetings/2021-07-13-vchttpapi/#topic-4
>
> ... has resulted in an objection that the approach is not acceptable for
> the CCG:
>
> https://github.com/w3c-ccg/vc-http-api/pull/224#discussion_r682106281
>
> ... which then resulted in a meta discussion about CCG process:
>
> https://w3c-ccg.github.io/meetings/2021-08-17-vchttpapi/#topic-3
>
> Chairs, please clarify the escalation process for decisions that don't
> achieve
> consensus.
>
> My personal suggestion is to make the following clarifications:
>
> 1. Clarify that the applicable definitions and
>    sections of the W3C Process document are the base
>    definitions and operating procedure for the CCG and the
>    Work Item groups. Refer to the document explicitly
>    from the CCG Process.
>
> 2. Clearly state that all decisions are to be made
>    by group consensus (as defined by the W3C Process
>    Document). If consensus fails, the Editors
>    of a particular document can make a binding consensus
>    decision to get the group to move on. That decision can
>    be appealed with the W3C CCG Chairs who will make
>    the final decision.
>
> Please provide a resolution to this issue sooner than later, as it
> continues
> to negatively impact the VC HTTP API work.
>
> -- 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/
>
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>
>
> --
> Heather Vescent <http://www.heathervescent.com/>
> Co-Chair, Credentials Community Group @W3C
> <https://www.w3.org/community/credentials/>
> President, The Purple Tornado, Inc <https://thepurpletornado.com/>
> Author, The Secret of Spies <https://amzn.to/2GfJpXH>
> Author, The Cyber Attack Survival Manual
> <https://www.amazon.com/Cyber-Attack-Survival-Manual-Apocalypse/dp/1681886545/>
> Author, A Comprehensive Guide to Self Sovereign Identity
> <https://ssiscoop.com/>
>
> @heathervescent <https://twitter.com/heathervescent> | Film Futures
> <https://vimeo.com/heathervescent> | Medium
> <https://medium.com/@heathervescent/> | LinkedIn
> <https://www.linkedin.com/in/heathervescent/> | Future of Security Updates
> <https://app.convertkit.com/landing_pages/325779/>
>
>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>