Re: Attempting to block work (was: Re: VC HTTP Authorization Conversation)

On Sun, Jun 13, 2021 at 2:34 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 6/12/21 12:51 PM, Alan Karp wrote:
> > I am David the delegator.  I will have 2 endpoints.
> >
> > * I will delegate a subset of the permissions in an authorization I hold.
> > * I will revoke a delegation that I made.
>
> This is completely and totally out of scope. :)
>

Fair enough.  (When I was teaching, I always told my students that if they
were afraid to say something stupid, they'd never say anything smart.)

I raised the issue in case the API needed to allow for a separate field to
support token exchange.

>
> It exists somewhere in the ecosystem, but it's not the VC HTTP API's job to
> define it.
>
> > Attenuated delegation is fundamental.  If you don't think about it
> today,
> > you may end up with a system that doesn't support it.  For example, you
> > have to make sure your spec doesn't preclude token exchange for opaque
> > tokens.
>
> Speaking as someone that has co-authored and implemented capabilities-based
> delegation specs (zcap-ld) and libraries (ezcap, ezcap-express) -- it's not
> fundamental. You don't need delegation; it is very useful, though.
>

I don't believe that you can build a viable capability system that doesn't
support delegation except for the most trivial use cases.  Without
delegation, people will simply share their access tokens.  As a result they
will end up granting more permissions than necessary, and you'll lose
responsibility tracking.

>
> We are thinking about it today -- in fact, we've implemented ZCAP-based
> delegation for a variety of our APIs... and it's a great and powerful
> thing.
> It is nowhere near done and we need more time to let it mature.
>
> In the meantime, VCs are a global standard, and protocols for issuing,
> presenting, and verifying them are emerging (CHAPI and the VC HTTP API, to
> name just two).
>

That has been my concern of using one VC standard both for claims, e.g.,
driver's licence, and authorizations.  There is a difference in what's
important and the mechanisms used to implement features.  For example,
delegating a driver's license may not make sense, but permission to drive
your car does.  Revoking a driver's license requires quite a different
mechanism than revoking permission to drive your car.  I believe that the
experience with the VC standard is mostly (entirely?) of the claims type,
not authorizations.

>
> The spec doesn't preclude authorization, opaque token exchange, or
> anything of
> the like. If it did, Digital Bazaar would be first in line to object...
> because we want to see delegation as a reality for the API. That said, it's
> not ready now and the only thing that is going to fix that is effort and
> implementation... and while that's going on, we shouldn't block use cases
> that
> don't need delegation (which is a large number of them).


If you don't make delegation easy and part of the design from the
beginning, people will use workarounds that will be less secure.  Worse,
many of them will conclude that capabilities don't work.  There is
historical precedent.  People who built flawed capability systems reached
exactly that conclusion.

--------------
Alan Karp