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

Re: Capability Authorization-enabled Decentralized Object Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about zcaps]]

From: Alan Karp <alanhkarp@gmail.com>
Date: Wed, 7 Apr 2021 19:53:32 -0700
Message-ID: <CANpA1Z2yeUkvBKV2rdumfEnbAzCY2ArDZXySkkGaq_8qt8o8dA@mail.gmail.com>
To: "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net>
Cc: Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>, Christopher Lemmer Webber <cwebber@dustycloud.org>
On Wed, Apr 7, 2021 at 6:50 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> RE: You made my day.  I just want to make sure your proposal can handle
> cases more complex than requesting a single file from a resource server.
>
>
>
> I’ll look at the HP Labs paper in a minute but I believe the following
> RWOT paper already speaks to how to solve most of this scenario with
> verifiable capability authorizations:
>
>
>
>
> https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/draft-documents/lds-ocap/lds-ocap.md
>
>
>
Yes, what they describe does the job, but the example involves only a
single resource.  The key point about the example I gave is that Alice
specifies one resource, Bob specifies another, and Carol uses them both.
You can often make simpler examples work with authentication-based
approaches, but I don't think you can with my use case.

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


On Wed, Apr 7, 2021 at 6:50 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> RE: You made my day.  I just want to make sure your proposal can handle
> cases more complex than requesting a single file from a resource server.
>
>
>
> I’ll look at the HP Labs paper in a minute but I believe the following
> RWOT paper already speaks to how to solve most of this scenario with
> verifiable capability authorizations:
>
>
>
>
> https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/draft-documents/lds-ocap/lds-ocap.md
>
>
>
> Michael
>
>
>
> *From:* Alan Karp <alanhkarp@gmail.com>
> *Sent:* April 7, 2021 11:53 AM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org;
> Christopher Lemmer Webber <cwebber@dustycloud.org>
> *Subject:* Re: Capability Authorization-enabled Decentralized Object
> Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about
> zcaps]]
>
>
>
> On Wed, Apr 7, 2021 at 7:09 AM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> I see all of this converging into a Capability Authorization-enabled
> Decentralized Object Model.  “More news at 11…”
>
>
>
> You made my day.  I just want to make sure your proposal can handle cases
> more complex than requesting a single file from a resource server.  I
> believe that any system that can handle the example in
> https://www.hpl.hp.com/techreports/2008/HPL-2008-204R1.pdf is general
> enough.  (It won Best Paper at ARES 2010, so you don't think I'm blowing
> smoke.)
>
>
>
> In that scenario, Alice wishes to use Bob's backup service, which relies
> on Carol's copy service.  We show that authentication-based schemes can
> lead to bad results.  For example, Alice specifies a file she is not
> allowed to read, and Bob specifies a file he does not have permission to
> write. Nevertheless, Carol reads the input and writes it to the
> output, potentially destroying one of her files.  These problems cannot
> arise with capabilities.
>
>
> --------------
> Alan Karp
>
>
>
>
>
> On Wed, Apr 7, 2021 at 7:09 AM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> I see all of this converging into a Capability Authorization-enabled
> Decentralized Object Model.  “More news at 11…”
>
>
>
>
>
>
>
> *From:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Sent:* April 4, 2021 8:36 PM
> *To:* Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org
> *Subject:* The "Verifiable" Economy [was RE: a few thoughts about zcaps]
>
>
>
> After ruminating on ZCAPs, VCs, DIDs, and DID Documents over Easter
> dinner, it occurred to me that we’re on the verge of creating a model for a
> “verifiable” economy…
>
>
>
>
>
> …glaze the above with your favorite verifiable digital currency and voila!
>
>
>
> Best wishes,
>
> Michael Herman
>
> Far Left Self-Sovereignist
>
>
>
> Self-Sovereign Blockchain Architect
>
> Trusted Digital Web
>
> Hyperonomy Digital Identity Lab
>
> Parallelspace Corporation
>
>
>
>
>
>
>
>
>
> *From:* Michael Herman (Trusted Digital Web)
> *Sent:* April 4, 2021 11:22 AM
> *To:* Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org
> *Subject:* RE: a few thoughts about zcaps
>
>
>
>    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.
>
>
>
>    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?
>
>
>
> In general, I found the presentation of this subject to be much more clear
> and digestible in the RWoT paper.
>
>
>
> Best regards,
>
> Michael
>
>
>
> -----Original Message-----
> From: Manu Sporny <msporny@digitalbazaar.com>
> Sent: April 4, 2021 7:09 AM
> To: 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
>
>
>
> --
>
> 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
>
>
>
>
>
>

image001.jpg
(image/jpeg attachment: image001.jpg)

image002.jpg
(image/jpeg attachment: image002.jpg)

image004.jpg
(image/jpeg attachment: image004.jpg)

Received on Thursday, 8 April 2021 02:54:05 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 8 April 2021 02:54:06 UTC