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

Joe,

First, it’s good that we’re moving beyond “shoot the messenger”.

Second, digital identity has had a PR problem since EFF first raised it,
and the recent Apple announcement demonstrates the urgency for our
community to hear and maybe respond to the message.

Third, I am not insisting that VC-HTTP API be the prototype for the
solution. I have reached out to chairs and other leadership for many weeks
now hoping for this privacy discussion to be given a home. I was not asked
to back off.

I can’t speak to the business issues that are driving the urgency to add
authorization to VC-HTTP.  Nor can I estimate whether considering GNAP
draft 05 and IETF explicitly in VC-HTTP would actually harm anyone’s
business prospects.

I do think that DHS and other influencers are missing an opportunity to
comment on this issue. Someone in gov seems like they made a deal with
Apple that may not adequately consider our standards work.

- Adrian

On Fri, Jun 11, 2021 at 5:15 PM Joe Andrieu <joe@legreq.com> wrote:

> Adrian,
>
> 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?
>
> -j
>
>
> 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>
>
>
>