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

I see all of this converging into a Capability Authorization-enabled Decentralized Object Model.  "More news at 11..."

[cid:image004.jpg@01D72B84.DB167B00]


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

[cid:image001.jpg@01D72B84.B2026DA0]

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

[cid:image005.jpg@01D72B84.DB167B00]



From: Michael Herman (Trusted Digital Web)
Sent: April 4, 2021 11:22 AM
To: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; public-credentials@w3.org<mailto: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<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



--

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