Re: VCs - zCaps / OCap a Discussion

Orie Steele <orie@transmute.industries> wrote:

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).
>
> You didn't answer my last question.

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?



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

Thanks for explaining.  I've used Tyler Close's waterken system that used
unguessable URLs as ocaps.

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

Got it.  The fact that two of the strings start with "z19" threw me off.

>
> When verifying the invocation, the verification algorithm will check:
>
> 1. the invocation key is authoritative for the invoker
>

What does "authoritative for the invoker" mean?  In the approach we took,
the "invoker" was a public key, and the request had to be signed by the
corresponding private key.  Is that the same thing?  (I feel we're like the
US and England, two countries separated by a common language.)


> 2. the capability that is invoked is valid and signed with keys
> authoritative for the delegator
>

Same question.  In our case the delegation was signed by the private key
corresponding to the "invoker" public key in the delegator's ocap.


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

That should not be a problem since they should be created on the fly for
each particular use.

>
> 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 our scheme the invocationTarget was the verifier, but it didn't have to
be the resource server.  (I guess there could be a separate field in the
ocap for the revocation target.)  In the US Navy case, the invocationTarget
was the PEP for the resource.  You revoked by telling the invocationTarget
not to honor an ocap with that id, including proof that you were the
delegator.  (An open question was if anyone earlier on the chain was
allowed to revoke.  We had good reasons both ways.)

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

Including the delegator's ocap in the proof field would mean that it's
always available.

I noticed that you didn't include an expiration time.  We found it useful
for garbage collecting revoked capabilities.  Using it only for that means
the ocap can live a long time, one year in our case.

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