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

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. :)

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.

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

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

-- 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 Sunday, 13 June 2021 21:30:54 UTC