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

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.

Again, with my Digital Bazaar hat on, and without my VC HTTP API organizer hat
on...

This isn't about authorization at W3C, it's about authorization in the VC HTTP
API... and, I just went back to check the meeting transcriptions, and we have
had a good percentage of the group weigh in on the topic over the last several
months. It might help to go back and look at the proposals we've done and the
number of people weighing in on the topic.

> 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.

Thank you, Adrian, that's far more productive. Thoughts below... I urge others
to provide feedback to Adrian as well.

> A1 - VC-HTTP API is *the one place* where the asymmetry of power between 
> issuers and subjects comes to a head.

You have yet to demonstrate why and how. This seems to be the basis of your
position, so it's hard to even consider your other points because the
foundation of your argument hasn't been established yet.

Why is the VC HTTP API the one place where the asymmetry of power between
issuers and subjects comes to a head?

Where exactly in the VC HTTP API is this concretely realized? You should be
able to point to and endpoint and say "right there".

> 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.

Yes, we could do that, one upside would be thinking through the authorizations
needed for each endpoint, which would be useful. The group seems unwilling to
consider macaroons, biscuits, ZCAPs at this stage because they're not formal
standards yet. The group also seems unwilling to define things in RAR because
it's not clear what concrete implementable thing comes about in the next 6-9
months as a result and no one is volunteering to do this work yet.

> 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.

We have volunteers to do OAuth2+client_credentials.

We do not have volunteers to do the GNAP work. If we had volunteers to
implement GNAP+RAR, I expect that work would proceed in parallel.

> 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*.

The "significant privacy and security" issues have not been identified. You
just keep asserting that they exist over and over again without 1) explaining
what they are, and 2) tying them directly to how the VC HTTP API realizes
those 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.

I believe the group continues to do this, as we've always done.

> A5 - OAuth2 has been demonstrated to drive for market consolidation
> through *vendor lock-in*.

I think OpenID Connect does that, sure.

It's not clear to me how OAuth2 does that (except through the outsourcing of
OAuth2 flows via folks like Auth0, Microsoft, SailPoint, Ping, ForgeRock, etc.).

It seems like you think the VC HTTP API will be used for OpenID Connect-style
flows?

> 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.

Yes, although I haven't heard anyone stating that that isn't our role here...
we're striving for decentralization and more consumer-favorable architectures.

> A6 - The introduction of client credentials as part of VC-HTTP API would be
> a choice (see A2).

Having a bunch of SHOULD/MAY optional choices don't drive interoperability. In
order to drive real interoperability, we need at least one concrete MUST
requirement. There can be other choices on top of that one concrete MUST, and
those choices might become MUSTs themselves in the future... but at present,
there only seems to be one MUST that implementers are willing to implement at
present.

> This choice clearly adds the power of *censorship* to the already sovereign
> issuer.

Here, again, you state something as a truth that you've yet to explain or
convince the group is true and/or possible.

It's not clear that it adds the power of censorship. How do client_credentials
enable issuers to censor?

> 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.

Again, how do client_credentials enable censorship?

Can you point to which VC HTTP API endpoint, when combined with
client_credentials, will lead to this sort of censorship?

> 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.

You seem to be bringing EDVs into the conversation again... or projecting
something that you think that GNAP will do in the future (that EDVs do today).

To speak to your healthcare use case, if a healthcare provider wants to give
access to a health record to a patient where a copy doesn't need to be made,
they can mint a ZCAP to the provider's EDV (for example). This is one way you
can do delegation and the retrieval of that health record doesn't happen
through the VC HTTP API, it happens through the EDV HTTP API.

Granted, we haven't come to consensus on this as a community, but it seems
like you think that the VC HTTP API is every HTTP API that's in the ecosystem,
when it isn't. That is, you seem to be ascribing things that the VC HTTP API
does that it does not do.

> 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.

This comment is far too nebulous to analyze. It's not clear at all why the "VC
HTTP API is special" or why "it is the most effective place in the SSI
protocols architecture to introduce Agency Law principles".

It would help me if you could do the following two things:

1. Explain why the VC HTTP API the one place where the
   asymmetry of power between issuers and subjects comes
   to a head.

2. Explain exactly where in the VC HTTP API this issue is
   concretely realized.

That's what's been missing all along, IMHO.

-- 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 Wednesday, 7 July 2021 16:27:24 UTC