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

Adrian,

I've been following the conversation around privacy concerns with
respect to OAuth2 + VC HTTP API for a while now and I just can't figure
out what the specific problems are. You seem to be speaking in the
abstract every time you try to raise the concerns and there's some kind
of disconnect there that's not enabling me to understand you. I think
others feel the same way.

Below you've provided yet another list of high level, abstract concerns.
Instead of doing this, could you attempt to create some concrete
examples that clearly demonstrate where an actor, let's say, "Alice",
experiences some kind of harm to her privacy or agency?

For example, if we were talking about presenting credentials and the
"phone home problem", we may discuss it using a concrete example that
helps explain the privacy issue. It may look like this:

1. Alice receives a credential from an issuer.
2. Suppose this credential can only be verified by asking the issuer for
verification.
3. When Alice presents the credential to a verifier, the verifier will
have to phone home to the issuer to ask for verification before
accepting it.
4. Therefore, every time Alice presents a credential, the issuer of the
credential will be notified of her usage.
5. This is harmful to Alice's privacy because the issuer gets to keep
track all of the places where Alice has presented her credential.
6. If Alice's credential could be verified without notifying the issuer,
this privacy concern could be mitigated.

Hopefully, this makes a specific privacy concern (the issuer getting to
track Alice's usage of a credential) clear. Can you create one or more
similar concrete examples that explain your privacy concerns around
OAuth2 and the VC HTTP API? The template would be something like this:

1. Alice does X...
2. Suppose OAuth2 tokens are used for authz ...
3. This is harmful to Alice because...
4. If GNAP/RAR/Macaroons/Biscuits/ZCAPs were used, it would be mitigated
because...

I think if you could do this, it would be tremendously helpful. Thank you.

On 7/6/21 8:25 PM, Adrian Gropper wrote:
> 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
> <mailto: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/
>     <https://www.linkedin.com/in/manusporny/>
>     Founder/CEO - Digital Bazaar, Inc.
>     News: Digital Bazaar Announces New Case Studies (2021)
>     https://www.digitalbazaar.com/ <https://www.digitalbazaar.com/>
> 
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Wednesday, 7 July 2021 17:03:38 UTC