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

On Sun, Aug 22, 2021 at 11:07 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

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

*Absolutely not. These mechanisms are not intended to give control to the
Subject of the VC. Quite the opposite. This was the work I referenced in
earlier threads that UMA calls the Adrian Clause. It's the background for
how I model the VC access issue. *

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

*The issue has to do with Dynamic Client Registration instead of Client
Credentials. Consider a request to Sign-In (to a service as Verifier) with
OIDC instead of Google / Facebook. The relying party as verifier would need
to trust the attributes presented by the Info Endpoint as Issuer of a VC.
With SSI, we expect the trust chain to go through the VC rather than
through Client Credentials of the Verifier. All the Subject needs to do is
give the Verifier a capability to get the VC from the Info Endpoint as
Issuer.*

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

*No, indeed. But I'm terrified that regulatory capture will mean that
sovereign Issuers will extend that practice to external requests if they
can. What's to stop them? People might say it's up to "governance" to
regulate the issuers. This is not the spirit of blockchains or other
self-sovereign designs. It's not how we approached "herd privacy" and other
aspects of the VC and DID data models. Plain English: After a decade of
working around OAuth 2 and UMA, I don't trust the Issuers to do anything to
respect decentralization.*

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

*Yes. See above about giving Issuers a tool for internal use that then is
applied to external use. This is exactly the problem I'm hoping to deal
with. I see it as a back door to censorship.*

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

*" Any VC HTTP API endpoint where the VC subject might directly*

*interact with the endpoint, and that is not under the direct control of
thesubject (the subject is free to choose the authorization mechanism)," is
very hard for me to parse.*

*PROPOSAL: Any VC HTTP API endpoint that could be protected by a capability
issued to the Subject or by registration of an authorization server chosen
by the Subject, MUST require authorization that supports delegation or not
require authorization at all. This applies to endpoints where a VC might be
requested or issued as well as status and other requests where the Subject
would benefit from the ability to delegate to their chosen self-sovereign
or fiduciary agent.*

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