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

Re: a few thoughts about zcaps

From: Alan Karp <alanhkarp@gmail.com>
Date: Mon, 5 Apr 2021 14:48:45 -0700
Message-ID: <CANpA1Z2W3VRNEOo+UYgzmwTn9wP86yERn7up09M4L-aHQzx92A@mail.gmail.com>
To: Christopher Lemmer Webber <cwebber@dustycloud.org>
Cc: "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net>, "public-credentials@w3.org" <public-credentials@w3.org>
On Mon, Apr 5, 2021 at 1:46 PM Christopher Lemmer Webber <
cwebber@dustycloud.org> wrote:

>
> >   *   language based identities
>
> If you read and grok the above two links (and sorry, it might take more
> than a quick scan) you can then read the Horton paper and it should
> click into place.
>

The Horton paper shows how you can identify responsible parties with just
object references used as capabilities.  That approach is not needed when
you have certificates or even opaque tokens as in GNAP.  I wouldn't spend
too much (any?) time trying to understand the paper.  (I can say that since
I'm one of the authors.)

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


On Mon, Apr 5, 2021 at 1:46 PM Christopher Lemmer Webber <
cwebber@dustycloud.org> wrote:

> Michael Herman (Trusted Digital Web) writes:
>
> > Chris, can you elaborate on what you mean by:
> >
> >   *   language based ocaps, and
>
> Most of the people in this space I think have gotten some notion that
> ocaps have something key to do with either a) certificates or b) URI
> structures / bearer tokens.  Not really... those are just two ways to
> encode them.
>
> The following two links explain how ocaps can be done purely in terms of
> programming languages via argument passing and lexical scope:
>
>   http://mumble.net/~jar/pubs/secureos/secureos.html
>   http://erights.org/elib/capability/ode/index.html
>
> If the parentheses throw you off, focus on the latter link.
>
> In general this is a more powerful starting place to think about ocaps
> than starting with certificates.
>
> >   *   language based identities
>
> If you read and grok the above two links (and sorry, it might take more
> than a quick scan) you can then read the Horton paper and it should
> click into place.
>
> > A quick scan of the two links didn't reveal anything.
> >
> >
> >
> > Best regards,
> >
> > Michael
> >
> >
> >
> > -----Original Message-----
> > From: Christopher Lemmer Webber <cwebber@dustycloud.org>
> > Sent: April 5, 2021 6:19 AM
> > To: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> > Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org
> > Subject: Re: a few thoughts about zcaps
> >
> >
> >
> >
> >
> > Michael Herman (Trusted Digital Web) writes:
> >
> >
> >
> >>   1.  In https://w3c-ccg.github.io/zcap-ld/, I found the "authority by
> >
> >>   possession" label to be quite confusing (and hence, the car key
> >
> >>   metaphor).  When I read "authority by possession", I read "authority
> >
> >>   by [simple] possession" and this couldn't be further from what is
> >
> >>   presented in
> >
> >>
> https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/draft-documents/lds-ocap/lds-ocap.md.
> When
> >
> >>   I read the latter, I interpret that scenario as "authority by
> >
> >>   delegation" ...delegation of a capability to a specific subject
> >
> >>   (e.g. grantedkey in the latter; invoker in the former).  The
> >
> >>   Proclamation is only valid in the hands of the Delegatee ...not an
> >
> >>   arbitrary possessor.
> >
> >>
> >
> >>   2.  The (conventional) car key analog is confusing because car keys
> >
> >>   are generally not bound to any specific person/subject.  Perhaps if
> >
> >>   it was a car key on Alyssa's keyring, that would be a better analogy
> >
> >>   ...but it doesn't really help ...because then it becomes clear that
> >
> >>   we're talking about delegation of the use of the car key ...and not
> >
> >>   the actual car.
> >
> >
> >
> > This means the metaphor is doing a good job then, because ocaps
> traditionally aren't either.  Language based ocaps aren't bound to an
> identifier at all:
> >
> >
> >
> >   http://mumble.net/~jar/pubs/secureos/secureos.html
> >
> >
> >
> > To some degree the delegation *is* bound to a subject in zcap-ld, but
> it's much more accurate that it's bound to "specific cryptographic
> material".  The identity of the agent it's bound to isn't too important.
> >
> >
> >
> > In language based identities, binding to an identity has to be done as a
> separate layered step, as it is here in Hortin:
> >
> >
> >
> >   http://www.erights.org/elib/capability/horton/
> >
> >
> >
> > It's possible to argue that zcap-ld accomplishes this automatically
> since the identity who's been delegated to is explicit.  However I think
> it's maybe the wrong impression to think this is too important;
> hyperfixicating on the delegee can lead to problems.
> >
> >
> >
> >>   1.  https://w3c-ccg.github.io/zcap-ld/#example-1 appears to be a
> >
> >>   capability to control the entire car (e.g. open the trunk, change
> >
> >>   the oil, repaint the exterior) ...not simply the capability to drive
> >
> >>   the car.  This is contrary to the statement "The following document
> >
> >>   delegates authority from the car (who always has authority over
> >
> >>   itself) to Alyssa so that she may drive".  Where is the "Drive"
> >
> >>   attenuation specified in Example 1?
> >
> >
> >
> > This is a good point.  Mind filing an issue?
> >
> >
> >
> >> In general, I found the presentation of this subject to be much more
> >
> >> clear and digestible in the RWoT paper.
> >
> >
> >
> > Having written most of both, I generally agree. ;)
> >
> >
> >
> > There is a lot of useful material from the RWoT paper that didn't make
> it into the spec... some of that should be corrected (the chaining
> diagrams), some of it I'm unsure about (the part that explains how
> composition abilities in language ocaps are more powerful than what's
> available to certificate ocaps, eg the timer backup example).
> >
> >
> >
> >>
> >
> >>
> >
> >> Best regards,
> >
> >>
> >
> >> Michael
> >
> >>
> >
> >>
> >
> >>
> >
> >> -----Original Message-----
> >
> >> From: Manu Sporny <msporny@digitalbazaar.com<mailto:
> msporny@digitalbazaar.com>>
> >
> >> Sent: April 4, 2021 7:09 AM
> >
> >> To: public-credentials@w3.org<mailto:public-credentials@w3.org>
> >
> >> Subject: Re: a few thoughts about zcaps
> >
> >>
> >
> >>
> >
> >>
> >
> >> On 4/3/21 2:39 PM, Nikos Fotiou wrote:
> >
> >>
> >
> >>> I was reading zcaps draft, as well as related work, mostly macaroons
> >
> >>
> >
> >>> (https://research.google/pubs/pub41892/).
> >
> >>
> >
> >>
> >
> >>
> >
> >> Hi Nikos, attempts at responding to your concerns below...
> >
> >>
> >
> >>
> >
> >>
> >
> >>> Something that I found confusing  about capability documents is that
> >
> >>
> >
> >>> they do not make clear the actions they concern. For example from
> >
> >>> this
> >
> >>
> >
> >>> https://w3c-ccg.github.io/zcap-ld/#example-1 it is not clear that
> >
> >>> this
> >
> >>
> >
> >>> is a capability for "driving a car".
> >
> >>
> >
> >>
> >
> >>
> >
> >> Yes, that document needs an overhaul and is a bit dated. It's good to
> get some of the basics, but still needs to be made more accessible.
> >
> >>
> >
> >>
> >
> >>
> >
> >> For example, I don't think much time is spent on expressing the caveats
> and actions... or why one would pick a zcap over a VC... which you get to
> below.
> >
> >>
> >
> >>
> >
> >>
> >
> >>> From this, it is clear not only the importance of caveats, but also
> >
> >>
> >
> >>> how challenging is to implement and evaluate them correctly, e.g., a
> >
> >>
> >
> >>> caveat can only confine a capability you already have.
> >
> >>
> >
> >>
> >
> >>
> >
> >> Yes, the specification needs to be updated and your feedback is very
> good feedback.
> >
> >>
> >
> >>
> >
> >>
> >
> >> We are still trying to figure out how to explain these things to people.
> >
> >>
> >
> >> Capabilities-based systems are not a new concept; they're decades old
> at this point. The challenge has always been in communicating why they're
> useful and have a place in modern security systems.
> >
> >>
> >
> >>
> >
> >>
> >
> >> The Encrypted Data Vault work uses zcaps, and it's there that we're
> trying hard to explain to developers how to use it:
> >
> >>
> >
> >>
> >
> >>
> >
> >> https://identity.foundation/confidential-storage/#introduction
> >
> >>
> >
> >>
> >
> >>
> >
> >> The documentation is lacking around zcaps, but it's an active area of
> development and we're trying very hard to communicate not only the core
> technology, but some concrete design patterns around them.
> >
> >>
> >
> >>
> >
> >>
> >
> >> All this to say that you make very good points and we're working on
> >
> >> it... and would love some help if you can spare the time. :)
> >
> >>
> >
> >>
> >
> >>
> >
> >> -- manu
>
>
>
Received on Monday, 5 April 2021 21:49:10 UTC

This archive was generated by hypermail 2.4.0 : Monday, 5 April 2021 21:49:12 UTC