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

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/

Received on Tuesday, 6 July 2021 21:14:35 UTC