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

(Hit return to soon)

I didn't see anything about revocation.  There are two important points.

First, you can revoke a VCA by simply notifying the service endpoint.  You
can give the VCA a relatively long expiration time so the service endpoint
doesn't have to keep revocations forever.

Second, you need to define who can revoke.  The holder, for deniability?
The direct delegator?  Anyone in the delegation chain?  Don't specify a
policy and leave it up to the verifier?

--------------
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.
>    3. 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
>
>
>
>
>
>