Re: VCs - zCaps / OCap a Discussion

Digging my way out from the holidays... I recently spent a lot more time
with ocap-ld, and in particular delegation of capabilities with linked data
proofs....

I will have more code / examples to share soon as this is related to
ongoing work in:

https://github.com/decentralized-identity/confidential-storage

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

In this example, there are a couple things I want to draw out attention to:

1. https://w3id.org/security/v2 shares a remarkable amount with
https://github.com/w3c/vc-data-model/blob/master/contexts/credentials/v1

In many cases the terms are in fact identical in their definition (meaning
the information is meant to be interpreted exactly the same way).

2. "capabilityChain" is a set of URIs that resolve to credentials or
verification material (like a DID Document)... the material does not have
to be a DID Document, in this case,

"
http://localhost:9876/edvs/z19wp9zi7tw4F8qKu74revXhY/zcaps/documents/z19pgwFikcSTBjbRTbCBKBUB3"
may resolve to a "root capability" which looks like this:

{
"@context": "https://w3id.org/security/v2",
"id": "
http://localhost:9876/edvs/z19wp9zi7tw4F8qKu74revXhY/zcaps/documents/z19pgwFikcSTBjbRTbCBKBUB3
",
"invocationTarget": "
http://localhost:9876/edvs/z19wp9zi7tw4F8qKu74revXhY/documents/z19pgwFikcSTBjbRTbCBKBUB3
",
"controller": "did:key:z6MktCi29iAwUiVDaewSStHVW5qhBxZTGXBFXM9YD9RisbFn",
"invoker": "did:key:z6MktCi29iAwUiVDaewSStHVW5qhBxZTGXBFXM9YD9RisbFn",
"delegator":
"did:key:z6MktCi29iAwUiVDaewSStHVW5qhBxZTGXBFXM9YD9RisbFn#z6MktCi29iAwUiVDaewSStHVW5qhBxZTGXBFXM9YD9RisbFn"
}

Like VCs, Linked Data Proof based capabilities are not restricted to DIDs,
but they work nicely with any URI that can resolve to structured data....

The difference between the ocap-ld examples that are used with "encrypted
data vaults" today, and my previous proposal is almost entirely semantic
sugar... except that you can't use ocap-ld with JWTs... which invites
political drama that we all don't need.

Sure, if we decided to use
https://github.com/transmute-industries/authorization-credentials or
something more "VC Data Model" based we would need up update the code that
currently works just fine with OCAP-LD.... but IMO that update is worth it
for a number of reasons....

1. clearly demonstrate the value of capability systems without inviting a
holy war over assertion formats.
2. align capabilities, and in particular verification relationships
https://w3c.github.io/did-core/#verification-relationships with more than
just "Identity based Credentials"...
3. Better peer review / formality behind OCAP-LD-like functionality from a
larger more competitive group of reviewers.

After speaking with many of the folks who built OCAP-LD, its clear to me
that VCs are dangerously close to being considered digital identification
documents for subjects.... which kinda misses the entire point of binding
verifiable claims for an IDENTIFIER.... if we want VCs to just be for
people, organizations and assets.... we should make sure the VC Data Model
NEVER adds any other verificationMethod types, so that "assertionMethod" is
the only allowed proof type for VCs... that way, you can only use a VC to
make assertions about a subject.....

You can see in the example I provided above the proof purpose is
"capabilityDelegation"..... meaning this proof is not related to
"assertionMethod"... and is not a "VC Data Model" compliant verifiable
credential.

IMO... this is more confusing for developers.... why are some proofPurposes
only used in VC Data Model, and others reserved for linked data
capabilities?

Why do DID Documents support multiple "verification relationships" but the
vc data model only supports "assertionMethod"?

How can I use OCAP-LD with JWTs? .... you can't : )

Don't get my wrong, I don't love JOSE or JWTS.... I think base64url encoded
is the sadest form of canonicalization imaginable... but I'm also not about
to pretend like the verification relationships of "capabilityDelegation"
and "capabilityInvocation" will only ever apply to linked data proof based
object capabilities (not JWTs)..... and if they are... well... that seems
like not a good strategy for advancing capability systems....

The VC Data Model gave JWTs something they didn't have before, that is only
needed in a complex system... semantic disambiguation.... this same
property is useful for capability systems... that's why the examples i
showed above use the same definitions for things like:

https://github.com/w3c/vc-data-model/blob/master/contexts/credentials/v1#L104

http://w3id.org/security/#proofPurpose

If I had to choose between only linked data proofs for credentials and
capabilities, or credentials and capabilities that support both JWT and VCs
using THE EXACT SAME semantics... I feel like this is not a hard decision
to make... why fight with the JWT folks forever by refusing to let them
share a vocabulary and specification for semantically unambiguous
capability systems?

I think if we pulled the capabilities work that is already working well
into the next version of the VC Data Model, we can take the best parts of
linked data, without forcing the worst part on all implementers (the worst
part of linked data proofs is that they are not trivial to implement with
off the shelf JOSE implementations :).

Hopefully this long post doesn't result in an epic JSON-LD flame war....
Our goal should be to enable the next version of VC-JWT to be capable of
certifying object capabilities by extending the vc data model to support
the verification relationships we have added to DID Core, and that are used
by OCAP-LD... so we can keep fighting about canonicalization, not a JSON
data model that should be pretty easy to agree on.

:)

OS



On Mon, Dec 28, 2020 at 12:13 PM Alan Karp <alanhkarp@gmail.com> wrote:

> David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
>
>>
>> >
>> > You may still want to delegate a bearer capability for sub-scoping and
>> > responsibility tracking.
>>
>> Yes you can do that, but only for a non-bearer credential that you have.
>> A bearer credential by its very definition does not belong to anyone
>> specifically. Some external (to the credential) mechanism would be
>> needed to track its provenance, rather like banks track your money in
>> its account. They cannot track the notes you hold unless they record
>> their serial numbers.
>>
>
> You're right.  My thinking is colored by my work using SAML certificates,
> which are assumed to be public documents.  That ruled out true bearer
> credentials.  We noted you could get behavior similar to a bearer
> credential by sharing the certificate and the private key it was issued
> to.  Any holder could then do a sub-scope delegation.  That approach
> doesn't work with true bearer credentials.
>
> --------------
> Alan Karp
>


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

<https://www.transmute.industries>