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{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

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{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 <>

> 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:
> 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 -
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches

Received on Sunday, 4 April 2021 19:57:09 UTC