W3C home > Mailing lists > Public > public-credentials@w3.org > June 2021

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 12 Jun 2021 10:10:43 -0400
To: public-credentials@w3.org
Message-ID: <5a2b4c3e-60cb-70ca-ea2e-111c204a6f96@digitalbazaar.com>
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/
Received on Saturday, 12 June 2021 14:11:15 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 12 June 2021 14:11:44 UTC