Re: VC HTTP Authorization Conversation

On 6/10/21 10:48 PM, Adrian Gropper wrote:
> Here's what I think I understand: * The VC-HTTP endpoint needs to be
> protected by some kind of bearer *token* from a client or a cookie from a
> browser.

Remove "a cookie from a browser" -- just simplify to "authorization token".

> * This *token* is subject to some "bootstrapping" protocol *that may or
> may not be in scope* for this group.

Yes, and the path that has the least amount of resistance at present is that
the bootstrapping protocol is out of scope.

> * Simply stopping with the token is "kicking the can down the road" 
> inadequate for the group.

Yes.

> * So the group wants to do something with OAuth2 that might or might not
> put the "bootstrap" in scope.

No, the group wants to do something with OAuth2 that DOES NOT put bootstrap in
scope.

> * In (Alice-to-Bob) delegation use-cases where the client presenting the 
> token has not pre-registered with the VC-HTTP server, OAuth2 may not be 
> sufficient.

We already know OAuth2 will not be sufficient for this use case, but it's not
clear that Alice-to-Bob delegation use cases require this.

For example, delegation can easily be done at the VC/ZCAP layer in the
presentation exchange and does not need any sort of OAuth2-based authorization
flow. It could work, but I don't know of anyone that's going to be depending
on OAuth2 for delegation.

This might be where you think authorization at the VC HTTP API layer comes
into play, when it's really happening at a higher layer (VC protocols).

> * In these delegation use cases, the VC-HTTP endpoint would need to be 
> protected by UMA or GNAP.

No, that is not a given. If delegation happens through another mechanism, like
VCs (which it shouldn't), or ZCAPs (more likely), those could be used as well.
It's just too early to talk about those use cases because implementations in
the space are too early. For example, Digital Bazaar has such a delegation use
case, but it's premature to talk about that right now.

> * But nobody here is arguing for UMA and GNAP is seen as presenting a
> delay to progress.

Yes, because no one has implemented UMA or GNAP for the delegation use cases.
We can't force people to implement these things and without implementing them,
we don't know if the spec is a work of fiction or not.

I've heard of no support for UMA from any implementer.

No implementer that we know of is willing to be the canary in the coal mine
with GNAP. Speaking for Digital Bazaar, we see promise in GNAP, but we are
unwilling at present to spent the hundreds of thousands of dollars that it
will take to integrate it into our products. That may change over time as GNAP
finds success in the marketplace, but for now, we would rather use OAuth2 to
solve the direct customer problems in front of us today.

That no one wants to implement UMA or GNAP will result in an unnecessary delay
to progress for the VC HTTP API, because there will be no authorization
mechanism defined... when there could be... OAuth2 is just fine for internal
use cases.

> * So folks want Adrian to stop insisting that Bob can be delegated by
> Alice to access the VC-HTTP endpoint because all of their use cases are
> fine with Alice and Alice's client always being an intermediary holder for
> the VC.

No, folks want Adrian to put a concrete proposal in front of the group that
will enable them to implement OAuth2 now for internal VC HTTP API calls and
then implement GNAP, ZCAPS, or whatever else comes down the authorization road
later for external/presentation-based VC HTTP API calls.

> I'm OK if the group wants to keep "bootstrap", and OAuth2 along with it,
> out of scope but that does not seem to be acceptable to some.

What's not acceptable to some is tying "bootstrap" to "OAuth2". You can
specify the latter without having to specify the former, especially in the
early experimental stage that the VC HTTP API is in.

-- 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 Friday, 11 June 2021 17:55:56 UTC