Re: VCs - zCaps / OCap a Discussion

authoritative keys are keys that are currently active for an identifier, or
that were active at the time the capability was created and have not been
since revoked.... this is conceptual similar to the well-known jwks uri
that OIDC uses, which allows an authorization server to rotate keys
frequently.

I use the term "authoritative" instead of. "currently active" because there
are some folks who want to issue credentials (and I assume capabilities)
from keys that were active, but no longer are, but they want the
verification to still succeed.... for example, by pinning to a specific
version of a DID Document, they keys will always be available, but if they
are later compromised, an attack will be able to issue many fraudulent
credentials, with keys that are "authoritative" but only up until some
"revocation event".... none of this is described very well, and honestly I
find the idea a little confusing, but you can read more about it here:
https://github.com/w3c/did-core/issues/337#issuecomment-756224896

I am not sure I understand your question regarding delegation / proofs... I
tried to answer it by saying:

There are 2 kinds of capabilities:

1. "root capabilities" which are just links to key material
2. "proof capabilities" which are linked data proofs that support
attenuated delegation from some root capability.

delegation to an invoker can come in 2 flavors:

a. delegation to an identifier like a DID
b. delegation to an identifier like a DID URL (a specific key)

a.) supports key rotation without re-issuing the capility, b.) does not.

did:key is perhaps confusing in this example since it does not support key
rotation, so it receives none of the benefits from a.)

did:key:z6MkgBEUKrGrHvSUKCSkhLNB7wfGTSYFksJx5SmqTyBJCNT7

and

did:key:z6MkgBEUKrGrHvSUKCSkhLNB7wfGTSYFksJx5SmqTyBJCNT7#z6MkgBEUKrGrHvSUKCSkhLNB7wfGTSYFksJx5SmqTyBJCNT7

are always going to return the same thing...

https://did.key.transmute.industries/did:key:z6MkgBEUKrGrHvSUKCSkhLNB7wfGTSYFksJx5SmqTyBJCNT7#z6MkgBEUKrGrHvSUKCSkhLNB7wfGTSYFksJx5SmqTyBJCNT7

in other did methods, making the invoker a DID vs a DID URL would allow you
to switch capabilityInvocation / capabilityDelegation without re-issuing
the whole chain... potentially.

having capabilities expire seems like a really good idea :)

OS



On Thu, Jan 7, 2021 at 6:01 PM Alan Karp <alanhkarp@gmail.com> wrote:

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


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

<https://www.transmute.industries>