W3C home > Mailing lists > Public > public-credentials@w3.org > June 2021

Re: Attempting to block work (was: Re: VC HTTP Authorization Conversation)

From: Joe Andrieu <joe@legreq.com>
Date: Fri, 11 Jun 2021 14:09:45 -0700
Message-Id: <dcf6e544-556f-4e1e-9ef9-85413f62604e@www.fastmail.com>
To: "Credentials Community Group" <public-credentials@w3.org>

Nobody is asking you to leave the group. Your perspective is valuable, both from your domain expertise and the particular points you are willing to fight for. As a fellow privacy advocate, I appreciate that you and I share many of the same goals in the end-result.

What people are suggesting is that affirmative statements of an intention to block the work will be seen as they are: non-collaborative belligerence.

The work we are faced with, right now, in this VC-HTTP-API effort is to distill just the right subset of the problem that we, as a community, can get consensus and closure on as a viable solution before we lose the momentum of collaboration.

That means limiting our use cases just as much as defining them.
That means deferring non-blocking work to later stages so we can advance the critical path items and move ahead.
That means accepting that we can't solve all the things at once.

It's this latter one that seems to be tripping you up. We simply can't adopt all of the potential future standards we want to support and put them in *THIS* spec. This isn't a political or even a technical problem. It's a logical one.

We can't embed standards that don't exist yet. 

What we *can* do is incorporate the work of peer standards--to the extent that it helps advance our own work--as we go. And I believe everyone who has made a comment on that issue has embraced that approach (correct me if I'm wrong). This is the approach this community has followed, with great success with both VCs and DIDs, as we appropriately separated boundaries of concern so things like ZKPs and non-ledger DIDs could still be part of the architecture even while those approaches are still being standardized.

In other words, I think we have a good track record here for being responsive to the kinds of concerns you have, just not in the way that you are requesting.

I'm hoping you can agree that 
(1) we can't adopt GNAP today because it isn't yet a standard (it will change through the standardization process and potentially in ways that would break what implementers here need).
(2) once GNAP is a standard is has a good chance of playing a powerful role in this ecosystem, again, depending on its final standardized result (I believe many share this hope).
(3) what we can do is bring in GNAP experts to advise on how best to align VC-HTTP-API work to maximize future interoperability with GNAP, and hope that as good faith operators, those same parties will take the conversations in the VC-HTTP-API work back to GNAP to influence that standard.

To my view, we are pursuing #3 in good faith with the right participants. GNAP is about as strong of a contributor as a non-standard could expect to be at this stage.

Unless I misunderstood what you were going for... Are you actually arguing for waiting for GNAP to be complete to continue the VC-HTTP-API work?


On Fri, Jun 11, 2021, at 11:18 AM, Adrian Gropper wrote:
> If anyone wants me to leave the group, all they need to do is ask.
> - Adrian 
> On Fri, Jun 11, 2021 at 1:15 PM Manu Sporny <msporny@digitalbazaar.com> wrote:
>> On 6/10/21 10:48 PM, Adrian Gropper wrote:
>> > I'm obviously missing something, and instead of explaining it to me
>> I'll try to be as delicate as I can, so please take this as advice from a
>> friendly colleague:
>> No one owes you an explanation.
>> People are going out of their way to try to explain it to you, but no one in
>> this group should be under the impression that the group owes them an
>> explanation on anything.
>> If you don't understand something, the burden to learn it is on you first and
>> then, in a very distant second and third place, your colleagues and then the
>> community.
>> That said, there have been multiple attempts... and I'm sure we'll all keep
>> trying, but coming into a work item and stating that you're going to "block
>> work" until someone explains it to you is not acceptable behaviour.
>> I'd like you to reconsider your approach.
>> > people are just shouting louder and louder at why I need to get out of the 
>> > way of progress.
>> What you're experiencing is frustration from people that have spent the time
>> and money to learn what the VC HTTP API does and doesn't do, implement
>> features, submit use cases, and in general "do the work". We now have an
>> individual entering the work that is insisting that the group take a
>> particular direction that almost every implementer in the group (of which
>> there are 7+) disagrees with and stating that they're going to block the work
>> until their issue (which is ill defined) is addressed. Even worse, that
>> individual has not implemented any of what they're proposing and is expecting
>> others in the group to implement their proposals.
>> This is not a recipe for a good engagement with any community.
>> Again, you may want to reconsider your approach, Adrian.
>> -- 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/>
Received on Friday, 11 June 2021 21:11:22 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:16 UTC