Re: VCs - zCaps / OCap a Discussion

in general, all the URLs can be dereferenced to either a JSON document with
a proof that has a capability chain... or a "root capability" which ends in
verification methods (like a did document).

all the URIs in this example are not secured by guessability, they are
secured by dereferencing to public key material, or dereferencing to a
proof which is linked back to public key material.... I agree the URIs are
confusing...

especially since in many cases they are the same as the invocationTarget,
except for the "/zcaps/" capability part.... for example, this is really
what is happening in the example linked:

controller creates a vault "z19wp9zi7tw4F8qKu74revXhY" with root capability
determined by the controller
"did:key:z6MktCi29iAwUiVDaewSStHVW5qhBxZTGXBFXM9YD9RisbFn"
which has public keys for capabilityDelegation.

then that same controller creates a document with id
"z19pgwFikcSTBjbRTbCBKBUB3" in that vault....

Then the first controller delegates read access to the second controller
"did:key:z6MksVScCyr9ygGpHv6g6NKhqXm8zJFiEZfhnMxagwkC8xNv", which has keys
for capabilityInvocation.

now the second controller can invoke that read access on the invocation
target of the delegation "
http://localhost:9876/edvs/z19wp9zi7tw4F8qKu74revXhY/documents/z19pgwFikcSTBjbRTbCBKBUB3
"

When verifying the invocation, the verification algorithm will check:

1. the invocation key is authoritative for the invoker
2. the capability that is invoked is valid and signed with keys
authoritative for the delegator
3. the capability was delegated from a root capability which ends in in the
original controller (who is also the only delegator, in this example)

because these DIDs are all did:key they are basically just public keys so
no network requests are required to access key material, but the keys
cannot be rotated or revoked.

theoretically the delegation chain verification could be broken by rotating
the capability delegation keys of the first controller, the root
capability, or revoking the capability with a second proof.

similar to gpg, a verifier must know of the revocation in order to fail the
chain verification, which means that either dereferencing should fail, or
some set of the capabilities must be rejected by the verifier.

In the case of encrypted data vaults, the verifier is the resource server
which stores the vaults, documents and some associated capabilities /
revocations... but the edv does not need to store all capabilities to
verify an invocation, and in fact is capable of verifying capability chains
that have been delegated man times, from the root capability of the
document / vault, as long as the chain is unbroken / available and still
valid.

OS



On Mon, Jan 4, 2021 at 5:34 PM Alan Karp <alanhkarp@gmail.com> wrote:

> Orie Steele <orie@transmute.industries> wrote:
>
> Digging my way out from the holidays...
>>
>
> Welcome back.  I hope Santa was good to you.
>
>>
>> However, let me take this opportunity to pull out an example that "works
>> today":
>>
>> {
>>   "@context": "https://w3id.org/security/v2",
>>   "id": "
>> http://localhost:9876/edvs/z19wp9zi7tw4F8qKu74revXhY/documents/z19pgwFikcSTBjbRTbCBKBUB3/zcaps/z1A9djR82X4aCHXmAxDcR5JLL
>> ",
>>   "invocationTarget": "
>> http://localhost:9876/edvs/z19wp9zi7tw4F8qKu74revXhY/documents/z19pgwFikcSTBjbRTbCBKBUB3
>> ",
>>   "invoker":
>> "did:key:z6MksVScCyr9ygGpHv6g6NKhqXm8zJFiEZfhnMxagwkC8xNv#z6MksVScCyr9ygGpHv6g6NKhqXm8zJFiEZfhnMxagwkC8xNv",
>>   "allowedAction": "read",
>>   "parentCapability": "
>> http://localhost:9876/edvs/z19wp9zi7tw4F8qKu74revXhY/zcaps/documents/z19pgwFikcSTBjbRTbCBKBUB3
>> ",
>>   "proof": {
>>     "type": "Ed25519Signature2018",
>>     "created": "2021-01-04T00:58:29Z",
>>     "capabilityChain": [
>>       "
>> http://localhost:9876/edvs/z19wp9zi7tw4F8qKu74revXhY/zcaps/documents/z19pgwFikcSTBjbRTbCBKBUB3
>> "
>>     ],
>>     "jws":
>> "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..Moq6U30hJcufrY36Lxy9b1tud9QFnuSsSzK1of0wNZwxqzgf-L9y0vJ0UtWzjgeVN2mHjWsvKCYsfnKctlPcDw",
>>     "proofPurpose": "capabilityDelegation",
>>     "verificationMethod":
>> "did:key:z6MktCi29iAwUiVDaewSStHVW5qhBxZTGXBFXM9YD9RisbFn#z6MktCi29iAwUiVDaewSStHVW5qhBxZTGXBFXM9YD9RisbFn"
>>   }
>> }
>>
>> I'm confused because all the domain names are the same.  It looks like
> you have to send every delegation you create to some central place.  I
> think it's important to make clear which locations must be the same and
> which can be different.  For example, must the invocation target be at the
> same location as the parent capability?  Also, the unguessable strings in
> your URLs are all the same.  That didn't confuse me, but still ...
>
> Is there a reason the proof isn't just a copy of the
> delegator's capability?  Doing it that way enables delegation when there is
> less than full connectivity, or are the days when you have to worry about
> connectivity behind us?
>
> --------------
> Alan Karp
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>