Re: VC HTTP API Endpoint Authz Needs (was: Re: Attempting to block work)

Manu,

I also appreciate the clarity of this thread.

Can we try not to respond to a privacy argument (delegation) with a
business argument (speed) because it just emboldens critics.

As Justin phrased it in another thread, making delegation a SHOULD, would
satisfy the privacy concern.

Adrian

On Sat, Jun 12, 2021 at 10:15 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 6/12/21 6:03 AM, Brian Richter wrote:
> > I know but there are implementations out in the real world so I am
> asking
> > those implementers directly.
>
> YES!
>
> These are exactly the right set of questions to be asking, Brian. Thank
> you!
>
> For those that don't know where Brian got the endpoints from, they came
> from
> these documents:
>
> https://w3c-ccg.github.io/vc-http-api/issuer.html
> https://w3c-ccg.github.io/vc-http-api/verifier.html
> https://w3c-ccg.github.io/vc-http-api/holder.html
>
> Asking and answering these *focused* questions will help us understand the
> use
> cases for each endpoint in far more detail than having a meta-conversation
> about authz, GNAP, and UMA.
>
> > To address David's questions about the endpoints. *Issuer*
> >
> > * It appears you are going for a short lived credential and the API is
> > currently setup for long lived credentials (I forgot to mention the
> update
> > endpoint only updates status)
>
> This is not a correct assumption. The endpoints are set up for both short
> lived and long lived credentials and presentations.
>
> > *Holder*
> >
> > * Yes*/presentations/prove *takes in a presentation and this prove a
> > presentation returns the presentation along with a proof
>
> Yes, although we haven't gotten to the point where at least one
> organization
> is going to object to the current construction of almost every Holder API
> endpoint. :)
>
> To be clear, the Holder endpoints are in there as a proposal; people need
> them, but they are not in their final form and everyone should expect these
> endpoints to churn once we get around to discussing them.
>
> > * /credentials/issue o I am an endpoint internal to my organization so
> the
> > authz shouldn't matter to you
>
> There are internal and external use cases for this:
>
> * internal (behind a corporate firewall)
> * external (exposed as a SaaS endpoint)
>
> In both cases, one could say that the authorization happens within the same
> trust boundary, and that's probably the determining factor here.
>
> Every use case we have right now for that endpoint has the client in the
> same
> trust boundary as the server. That endpoint is YOUR endpoint in all use
> cases
> because it is using YOUR keys to sign the VC.
>
> It is true that in the future we might allow you to delegate access to that
> endpoint, and it is true that Digital Bazaar uses ZCAPs to do this with our
> issuer software today... but we absolutely do not want to expose the group
> to
> that at present because... we don't want to hold up the work to do the
> simplest thing first, which is OAuth2 and simple bearer tokens and scopes.
> Doing that in no way blocks ZCAPs or GNAP from working in the future.
>
> > * /credentials/update o I use the internal org authz as well
>
> Same things above apply here as well. Authorization is same trust
> boundary. If
> we need to delegate, we can do that in the future.
>
> > Veronica
> >
> > * To be honest.. I verify anything you throw at me. I get upset when I
> > can't verify something. Do I really need to authz?
>
> Yes, authz is needed here. If you don't have authz, you have a denial of
> service attack vector.
>
> Yes, you will try to verify anything that is thrown at you, but you need to
> establish if the caller is in your trust boundary, and to do that OAuth2
> suffices for now... and in the future, if we want delegation, we can add
> support for delegation-aware authorization protocols. The switch is as
> simple
> as this:
>
> OAuth2 HTTP Header example:
>
> Authorization: Bearer mF_9.B5f-4.1JqM
>
> ZCAP HTTP Header example:
>
> Authorization: zcap capability=u3jf8Kf....pKq
>
> ^^ That seems to be what all of the fuss is about, and it seems to be a
> tempest in a tea pot.
>
> > Holder
> >
> > * /credentials/derive o All I do is remove information. Do I need authz?
>
> Yes, you need authz to provide denial of service attack prevention. The
> server
> also needs authz to determine which cryptographic keys to use when
> performing
> a derivation.
>
> > * /presentations/prove o I'm pretty proud of my credentials, I will prove
> > anything you want me to. Do I need authz?
>
> Same answer as above.
>
> > * /presentations/available o I don't need authz since I'm just a notify
> me
> > button to poke.
>
> This endpoint might be misguided and needs to be debated. If it stays, it
> doesn't need authz for the reason mentioned above.
>
> > * /presentation/submissions o I only take in credentials from you. I can
> > find other ways to throw away garbage. Do I need authz?
>
> Exactly -- this endpoint doesn't need authz to call it because you want
> just
> about anyone to be able to call it.
>
> Any endpoint that doesn't have authz will need to be protected using
> industry
> standard mechanisms (rate limiting by IP, DDoS detection and prevention,
> etc.)
>
> The server is almost certainly going to provide other mechanisms to throw
> away
> garbage/attacks that are layered on top of an effectively open endpoint.
>
> ------------
>
> The fundamental take away here is: OAuth2 bearer tokens are just fine for
> now,
> and it's easy to see how delegation works for ZCAPs (or any other
> delegation
> mechanism that can be triggered through the 'Authorization' header in the
> future).
>
> Hope this helps... and I hope folks in the community, Adrian included,
> start
> focusing on the endpoints themselves and the *focused* ramifications of
> authz
> on each endpoint.
>
> -- 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/
>
>
>