Re: The ezcap-express library

const url = '/my-account/items/123';const capability = await
getCapabilityFromDatabase({url}); // defined by your code
// reading a URL using a zcap will result in an HTTP Responseconst
response = await zcapClient.read({url, capability});
// retrieve the JSON dataconst items = await response.json();

You have separated the designation of the resource, url, from the
authorization, capability, in the request.  What happens if someone uses a
different url for that capability?

The standard approach is to use the capability to both designate and
authorize.

const petname = 'itemForFred';
const capability = await getCapabilityFromDatabase({petname}); // defined
by your code

// reading a URL using a zcap will result in an HTTP Response
const response = await zcapClient.read({capability}); // Capability
specifies URL

// retrieve the JSON data
const items = await response.json();


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


On Sun, Apr 4, 2021 at 12:12 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 4/4/21 2:26 PM, Alan Karp wrote:
> > Sounds like a good way to get people to understand the basics, but you
> > might have simplified too much.  Attenuated delegation is key to
> > capability systems, but I didn't see that in your write-up.  Maybe you
> can
> > add some examples in your Github repository.
>
> Those exist here:
>
> https://github.com/digitalbazaar/ezcap#delegating-a-capability
>
> The docs go into far more detail than is useful for an introductory email
> to a
> mailing list. For folks that know about delegation, attentuation, and
> caveats;
> the link above should prove useful.
>
> > The one thing you know is that any invoker of a resource must understand
> > the API.  In Zebra Copy we took advantage of that fact by representing
> > each method of the API being authorized as a string included in the
> > authorization certificate.
>
> ezcap does this by mapping URLs to root capabilities and then delegating
> from
> there.
>
> > I don't think that would be much harder for developers to understand.  In
> > the case of RESTful services, you could allow all 4 CRUD methods instead
> of
> > just Read and Update.
>
> The proposal wasn't "Read and Update", it was "read and write", where write
> includes CREATE, UPDATE, and DELETE. We may have erred on something too
> simple, but also note that it is trivial to add methods to the library...
> and
> again, the library is intended to be an easy way to enter the ecosystem --
> not
> a complete solution for advanced use cases.
>
> We had considered all CRUD operations, but then found it not to be a common
> use case where one can UPDATE but not CREATE... or DELETE but not CREATE.
> Those ended up being corner cases, as they do in most database systems.
>
> The other challenge was that you don't really CRUD in REST, but rather GET,
> POST, PUT, DELETE, and PATCH... which are, again, confusing to most when
> designing a system. Easier to look at being able to read/write resources.
>
> In other words, the library is opinionated; we expect other people to have
> different opinions, which is fine... opinionated libraries tend to employ
> certain philosophies, which doesn't mean that other philosophies aren't as
> useful or powerful.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>
>