Re: VCs - zCaps / OCap a Discussion

Orie Steele <orie@transmute.industries> wrote:

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

Good.  I was afraid it meant a well-known key tied to a person by a
certificate authority.  Unfortunately, that's what many people think when
they hear the term "public key."

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

Revoking keys requires some way to find out which keys have been revoked
because the revoker doesn't know who to tell.  That's one reason I like
using a different key pair for each ocap.  You revoke the ocap by telling
the verifier not to honor the ocap instead of revoking the key.

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

To my mind they are the same, except a root capability has an empty proof.
The verifier just makes sure the request is signed by the private key that
created the root capability.

>
> delegation to an invoker can come in 2 flavors:
>
> a. delegation to an identifier like a DID
>

Then the request is signed by a private key associated with one of the DIDs
public keys, right?


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

I have always delegated to a key.  I have to think more about delegating to
a DID.  It has the advantage of allowing key rotation, but the verifier
needs access to the DID material.

I guess I'm just not used to thinking in a fully connected world, which is
strange.  I started a project in 1996 based on the premise that by the time
the product came out, your normal state was connected.  If you weren't, you
got connected as fast as you could.  That assumption wasn't satisfied when
the product came out in 1999, but maybe it is today.

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