VC HTTP API Authorization MUST support delegation (was: Re: Request for CCG Chair Intervention in CCG Process)

Adrian, I'm going to try to help you refine your position because I don't
think you're meaning to make blanket statements (but that's certainly what I
am reading from your response):

On 8/21/21 4:58 PM, Adrian Gropper wrote:
> I will formally object to any resolution that gives the VC Issuer the power
> to censor how a VC is transported or used. OAuth 2 with Client Credentials
> is one example.

Here are other examples that enable the VC Issuer to censor how a VC is
transported or used. That is, it sounds like you'd like to ban these
mechanisms as well (which I don't think you do):

1. The use of client-side TLS certificates (typically used
   by large enterprises to secure internal client-server
   traffic).

2. The use of client IP address blocklists (typically used
   to prevent denial of service attacks).

3. The use of geolocation (typically used to prevent
   account take over or escalate the request to requiring
   a multi-factor authentication before proceeding).

Does your "I will formally object to any resolution that gives the VC Issuer
the power to censor how a VC is transported or used." apply to the mechanisms
above?

> The basis of my objection is that legacy credentials do not pose this
> added restriction on the VC subject. OAuth 2 / OIDC history has shown that
> protocol to result in platform centralization in a number of ways. That
> outcome may have been unintended at the time the standards were conceived
> but it is a demonstrated fact today.

Yes, I don't expect many would argue with your characterisation of OAuth2 and
OIDC.

In fact, I'm in violent agreement with you about that and is why we've been
pouring our money, sweat, and time into DIDs, VCs, and CHAPI (in order to
provide a more self-sovereign approach than OIDC). In the meantime, there are
also folks working on OIDC SIOP to also counter-act the damage done that you
highlight.

However, there is no cross-trust domain use of OIDC contemplated (that I know
of) for the VC HTTP API. So, I don't see how this comment is relevant. Please
help me understand why you think that OIDC is in scope?

> My proposal is: Any VC access authorization protocols MUST support
> delegation by the subject of the VC without censorship of the client or
> agent involved.

The proposal is too broad to understand, at least from my reading of it. Here
are the questions that are running through my mind:

Does this MUST apply to APIs on an internal trust boundary (as listed in the
following spreadsheet)? I expect the answer to that is "no".

https://docs.google.com/spreadsheets/d/1hlevKRxCXsJBWvJTkL30nZVp8cpF26aY3PJqzuHtIZE/edit#gid=0

Does this MUST apply to APIs on an external trust boundary? I expect the
answer to that is "yes".

Is Adrian only talking about Features 6, 7, 8, and 9 on the spreadsheet above?
It seems like that's really where we need to worry about subject censorship.
Features 10, 11, 12, and 13 already support delegation (if we're using EDVs),
so we've protected the subject from censorship there (except for all the other
attack mitigation mechanisms that servers have to be able to use listed at the
top of this email). It also feels like via DIDs or WebKMS delegation, we
support delegation for Features 6, 7, 8, and 9. It might be these assumptions
where the disconnect is happening?

Adrian, if we restated your proposal to something like this, I believe it
would have a greater chance of passing:

PROPOSAL: Any VC HTTP API endpoint where the VC subject might directly
interact with the endpoint, and that is not under the direct control of the
subject (the subject is free to choose the authorization mechanism), MUST
require authorization that supports delegation or not require authorization at
all. This applies to Features 7, 8, and 9.

... and to make sure you don't think that I have anything up my sleeves or
that I'm getting ready to play "Gotcha!", I expect that Feature 7
(notification of available presentation) might require authorization (but
based on the presentation) or be an "open, no authorization required
endpoint", and Feature 8 and 9 (start workflow / request authentication
challenges, present presentation) will be "open endpoints" and not require
authorization.

Thoughts, 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/

Received on Sunday, 22 August 2021 15:05:57 UTC