Re: VC-HTTP-API - A follow up on the RAR presentation

There have been maybe a dozen threads on authorization and related topics
in W3C. Only a small number of people have weighed in. Let's try our
time-honored tactic of Numbering succinct issues and proposals to try and
make it easier to get as many voices on this as possible.

Addressing points in this thread, in no particular order:

A1 - VC-HTTP API is *the one place* where the asymmetry of power between
issuers and subjects comes to a head. Turfing authorization to EDV does not
deal with the problem because EDVs are a commodity with almost no power
impact on either the subject or the issuer.

A2 - We have established that VC-HTTP API does not have to extend its scope
into privacy engineering.* We can reduce our scope* to RAR + [macaroons,
biscuits, ZCAP] and develop clear implementation standards and tests.

A3 - If VC-HTTP API wants to put *client-credentials* in-scope, then we can
choose to implement OAuth2 and GNAP simultaneously and give the subjects
the leverage they don't have now.

A4 - Arguments about how long it will take to implement privacy and
security protections like GNAP and capabilities in the VC-HTTP API context
are not a useful way to drive consensus around *significant privacy and
security issues*. As we have done for the past 5 years, let's deal with the
privacy and security issues raised by protocols the way we dealt with
privacy and security issues raised by data models.

A5 - OAuth2 has been demonstrated to drive for market consolidation
through *vendor
lock-in*. To the extent the VCs exposed by VC-HTTP API are designed to
promote decentralization or facilitate a generation of more
consumer-favorable regulations inspired by GDPR and CCPA and Open Banking,
we, as mostly engineers, need to recognize and accept our role.

A6 - The introduction of client credentials as part of VC-HTTP API would be
a choice (see A2). This choice clearly adds the power of *censorship* to
the already sovereign issuer. Much of our effort on VC and DID has
been designed to reduce the opportunity for censorship. Let's try to avoid
client credentials in VC-HTTP API.

A7 - *Data minimization* is core to both privacy and security architecture.
By linking control to possession, VC-HTTP API would force unnecessary
copying of VCs in many cases. Separation of concerns through delegated
authorization like GNAP gives the subject the leverage to decide if a copy
is needed or not. It therefore tends to reduce the asymmetry of power
relative to the sovereign issuers.

A8 - For centuries, Common Law has recognized the need for *agency to
protect subjects*. It's why we have a choice of defense lawyers and doctors
and clergy. VC-HTTP API is special, in the sense that it is the most
effective place in the SSI protocols architecture to introduce Agency Law
principles. Nonetheless, we can find other places to introduce agency by
adopting A2 or something like it.

All, please take A1-8 not as resolutions to be voted up or down but as
opportunities to make a point, sharpen our argument and *do our job as
mostly engineers*.

- Adrian

On Tue, Jul 6, 2021 at 5:16 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 7/6/21 2:44 PM, Adrian Gropper wrote:
> > In other words, a significant privacy-driven objection aligned with
> > self-sovereign identity principles will be sidelined because all of the
> > participating implementers are focused on selling to sovereign issuers
> and
> > verifiers starting with DHS and BC Gov.
>
> That's quite the accusation! :)
>
> "Not only do the corporations and governments not care about individual
> privacy, but they're profiting from the violation of self-sovereignty! How
> tragically misguided at best, and evil at worst!" <-- this is how your
> statement is coming across.
>
> I know you're frustrated, Adrian, but this path is not going to win hearts
> and
> minds.
>
> Without my VC HTTP API organizer hat on, and with my Digital Bazaar
> corporate
> hat on. I can only speak for my organization, the other implementers
> involved
> in the work will have to weigh in on what they think of your
> characterization.
>
> Here are some of the concerns with your framing:
>
> You have failed to convey a specific privacy concern that you are worried
> about, nor have you pointed out how the VC HTTP API realizes that concern.
> You've been asked multiple times to provide a concrete example and what you
> have responded with is inscrutable, at least to me, and I've been in this
> space for a while.
>
> You have asked the group to explore the space around authorization and the
> possibilities. The group has spent a number of frustrating weeks exploring
> the
> options, so has been executing upon what you asked for. We are ending up
> in a
> place that you don't support, but it's not clear why or what concrete
> action
> we could take, that has the possibility to reach consensus (or majority
> agreement), that would address your concerns.
>
> You have asked the implementers to use authorization technologies that
> none of
> the implementers seem to want to implement at present for the VC HTTP API
> (because they're not ready). I will highlight that we *are* supporting
> delegation and attenuation with the Encrypted Data Vault work, through the
> use
> of ZCAPs... so it's not like the group is unaware of these technologies...
> they just have different risk appetites for various parts of the
> ecosystems.
> So, the argument that the implementers don't seem to know and/or care about
> attenuated delegation use cases (or privacy) falls flat.
>
> It is a reality that enterprises use OAuth2 for authorization today. It is
> also a reality that implementers are expected to meet a minimum bar for
> authorization to their HTTP APIs, and OAuth2 with client_credentials is a
> very
> common minimum bar. It doesn't mean that other concrete mechanisms won't
> come
> along that are better and support attenuated delegation... no one is
> closing
> that door.
>
> I suggest that you focus on addressing the problems with your framing above
> rather than attempting to project accusations and motives onto the people
> that
> are trying their best to realize these SSI technologies (and have valid
> disagreements with your framing that they have clearly articulated).
>
> -- 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/
>
>
>