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

On Mon, May 17, 2021 at 9:08 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

>
>
> Another useful example is delegating some permission of a second resource
> to the resource provider of the first resource.  An example might be,
> "Translate the properties of this document and put those fields in this
> other document."  In this example, the resource provider of the first
> document gets write but not read permission to some fields of the second
> one.
>
>
>
> MWH>> This sounds like the preverbal “field-level security” requirement (a
> la Lotus Notes) often requested in RDBMs, n’est pas? …that is, the
> equivalent of property-level VCAs …or to make it more palatable: Property
> Set-level VCAs …that’s already built-in to the VE-ARM …you get this “for
> free”.
>

Not exactly.  As I understand it, field level security controls access to
different parts of one resource.  I am talking about a request that
involves more than one resource.  That's important because it lets you
check if you have a confused deputy vulnerability.

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


On Mon, May 17, 2021 at 9:08 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> MWH>> see below for my comments
>
>
>
> *From:* Alan Karp <alanhkarp@gmail.com>
> *Sent:* May 17, 2021 12:07 PM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* Christopher Lemmer Webber <cwebber@dustycloud.org>;
> public-credentials@w3.org
> *Subject:* Re: Capability Authorization-enabled Decentralized Object
> Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about
> zcaps]]
>
>
>
> Looks like you got it right.  Just to be sure, I've asked some other
> capability folks to take a look.
>
>
>
> A very important point you make is, "NOTE: An MI doesn’t have a subject
> property. The target object is specified by the subject property of the
> proclamation VCA."  That point is so important, not separating designation
> from authorization, that I'd like to see it in bold.
>
>
>
> MWH>> Done …with attribution.
>
>
>
> Another useful example is delegating some permission of a second resource
> to the resource provider of the first resource.  An example might be,
> "Translate the properties of this document and put those fields in this
> other document."  In this example, the resource provider of the first
> document gets write but not read permission to some fields of the second
> one.
>
>
>
> MWH>> This sounds like the preverbal “field-level security” requirement (a
> la Lotus Notes) often requested in RDBMs, n’est pas? …that is, the
> equivalent of property-level VCAs …or to make it more palatable: Property
> Set-level VCAs …that’s already built-in to the VE-ARM …you get this “for
> free”.
>
>
>
> Michael
>
>
>
> --------------
> Alan Karp
>
>
>
>
>
> On Sun, May 16, 2021 at 10:35 PM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> RE: RE: Does the model include delegation of a subset of permissions?
>
>
>
> Alan, apologies for the short (and somewhat cryptic) reply last month.  I
> now have a complete description of the VE-ARM Fully Decentralized Object
> (FDO) Model:
>
>
>
> The Verifiable Economy Architecture Reference Model (VE-ARM): Fully
> Decentralized Object (FDO) Model
>
>
> https://hyperonomy.com/2021/04/26/the-verifiable-economy-architecture-reference-model-ve-arm-fdo/
>
>
>
> The goals of this article are three-fold:
>
>
>
>    1. Introduce the concept of a Verifiable Capability Authorizations
>    (VCA) and how they can be used to implement controls over which specific
>    methods a particular party is allowed to execute against a particular
>    instance of a Fully Decentralized Object (FDO). VCAs are both delegatable
>    and attenuatable.
>    2. Illustrate how #graphitization techniques can be used for modeling
>    and visualizing:
>
>
>    1. Trusted Decentralized Identifiers (DIDs)
>       2. DID Documents
>       3. Trusted Digital Agents (and their Service Endpoints (SEPs))
>       4. Verifiable Credentials (VCs)
>       5. Verifiable Capability Authorizations (VCAs) and,
>       6. Most importantly, their myriad of interrelationships.
>
>
>    1. Use the above 2 goals to further detail and describe how to use the
>    VE-ARM model for implementing trusted, reliable, efficient, frictionless,
>    standards-based, global-scale software systems based on Fully Decentralized
>    Objects (FDOs).
>
>
>
> Best regards,
>
> 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) <mwherman@parallelspace.net>
> *Sent:* April 22, 2021 12:35 AM
> *To:* Alan Karp <alanhkarp@gmail.com>
> *Cc:* Christopher Lemmer Webber <cwebber@dustycloud.org>;
> public-credentials@w3.org
> *Subject:* RE: Capability Authorization-enabled Decentralized Object
> Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about
> zcaps]]
>
>
>
> RE: Does the model include delegation of a subset of permissions?
>
>
>
> The current vision is that the VCA delegation model includes any
> collection of methods authorizable against a subject entity by the entity’s
> AGENT wrt to a particular invocating entity.
>
>
>
> Michael
>
>
>
> *From:* Alan Karp <alanhkarp@gmail.com>
> *Sent:* April 21, 2021 8:47 PM
> *To:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Cc:* Christopher Lemmer Webber <cwebber@dustycloud.org>;
> public-credentials@w3.org
> *Subject:* Re: Capability Authorization-enabled Decentralized Object
> Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about
> zcaps]]
>
>
>
> Does the model include delegation of a subset of permissions?
>
>
> --------------
> Alan Karp
>
>
>
>
>
> On Wed, Apr 21, 2021 at 6:18 PM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
> Here’s the final first iteration of *The Verifiable Economy Architecture
> Reference Model (VE-ARM)* (at least for awhile):
> https://hyperonomy.com/2021/04/21/the-verifiable-economy-architecture-reference-model-ve-arm/
>
>
>
> The scenario used to model the VE-ARM is an example of a citizen (Erin) of
> a fictional Canadian province called Sovronia being issued and holding a
> valid physical Sovronia Driver’s License (Erin RW SDL) as well as a
> digital, verifiable Sovronia Driver’s License (Erin SDL).  It includes
> Verifiable Capability Authorization support (based on the RWoT article).
>
>
>
> The VE-ARM details every moving part (almost).  …this is potentially of
> interest to anyone of creating a new fully-decentralized, verifiable,
> credential-based economy …e.g. some of the health pass initiatives.
>
>
>
> The visualization uses some interesting queries that were created using
> Neo4j to automatically build the underlying model directly from the actual
> DID Document, Verifiable Credential, and Verifiable Capability
> Authorization JSON files used in the example scenario.
>
>
>
> Best regards,
>
> 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) <mwherman@parallelspace.net>
> *Sent:* April 17, 2021 5:54 PM
> *To:* Alan Karp <alanhkarp@gmail.com>; Christopher Lemmer Webber <
> cwebber@dustycloud.org>
> *Cc:* public-credentials@w3.org
> *Subject:* RE: Capability Authorization-enabled Decentralized Object
> Model [was RE: The "Verifiable" Economy [was RE: a few thoughts about
> zcaps]]
> *Importance:* Low
>
>
>
> It’s understandable why folks have difficulty understanding a complete,
> integrated DID, DID Document, VC, and VCA (Verifiable Capability
> Authorization) data model.
>
> Here’s a graph of the DID and Public Key ID relationships for a simple *Erin’s
> Sovronia Driver’s License* scenario I’m working on…
>
> SDL = Sovronia Driver’s License, PoS = Province of Sovronia, DD = DID
> Document, VCA MI = VCA Method Invocation.
>
>
>
>
>
> “More news at 11:15…”,
>
> 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
>
>
>
>
>
>