Re: VCs - zCaps / OCap a Discussion

TL; DR: My current view is that the main confusion here may be over the
difference between VCs and LD Proofs, not VCs and ZCAPs. VCs are not a
generalized container for attaching a cryptographic proof to a document.
That's what LD proofs (or JOSE style proofs) are for. VCs *use* LD
proofs (or JOSE style proofs) to attach an assertion proof to a document
that specifically models statements made by an issuer about some
subject, which is therefore inherently about the identity of that subject.

Even if we were to say "let's combine ZCAPs and VCs" -- we'd
*still* need to agree on a data model for expressing OCAPs inside VCs.
If we want that to be standard (which is what standardizing ZCAPs is
about), then that work doesn't "go away" just because you put a ZCAP in
a VC as a "credentialSubject".

Daniel,

> ... snip ..
> 
> Second, I have yet to see ANY justification for the hammer/screw
> analogy. I gave an example of using a VC to express an ocap. It was
> simple and elegant, and 100% compatible with the VC spec.

I think your example has a flaw, however, because the data itself does
not express what you said it expresses. Rather, a plain reading of it
using the VC semantic model says something else.

```
{
  "@context": [ "https://www.w3.org/2018/credentials/v1",
"https://roboticlab.cam.ac.uk/grants" ],
  "type": ["VerifiableCredential", "RobotPrivilege"],
  "issuer": "https://facebook.com/Amy",
  "issuanceDate": "2021-01-01T19:73:24Z",
  "credentialSubject": { "id":
"https://roboticlab.cam.ac.uk/~amyt/capstone-project", "allow": "operate"},
  "proof": {...}
}
```

The above does not say "It's an assertion that the bearer is
authorized." as you stated in your earlier email. It says:

The subject identified by
"https://roboticlab.cam.ac.uk/~amyt/capstone-project" has the property
"allow" with the value "operate".

This has nothing to do with any bearer of the VC. In fact, if one were
to *guess* more about the meaning of this VC, it would be that Amy's
"capstone project" is allowed to operate. Again, that's just guessing
from the English used in the terms and the identifier. This is not what
a machine would think without adding special-cased code that bends the
meaning to fit a use case. A machine would simply consider the
statements to be about whatever this subject is. This highlights that
VCs are just about making statements of identity about a particular subject.

Note that the triples here are:

<https://roboticlab.cam.ac.uk/~amyt/capstone-project> <allow> <operate>

(For some unambiguous mapping of "allow" and "operate" to full URLs).

These statements presumably say nothing about the bearer (unless the
bearer is identified by that "/capstone-project" URL). Even if so, what
would they be allowed to operate on?

So the semantics that you're layering on top through language in your
email are not present in the data itself. Another attempt will have to
be made to see what a VC would look like if it were to properly model an
OCAP.

My guess is that the VC would have to contain a fully modeled OCAP
as the `credentialSubject`. If true, it would become more obvious (in my
view) that the VC data model is merely being (mis-)used as a container
for an OCAP. Instead, applying a proof to the OCAP directly would have
sufficed and it could more accurately carry important semantics such as
that the purpose of the proof was for the delegation of authority rather
than merely asserting such authority exists (a claim of identity).

Certainly, you could express a claim that someone possesses an OCAP.
Note that this is still different from expressing a claim, for
example, that someone possess a driving license. Possession of a driving
license does not authorize you to drive *my* car. It isn't bound to a
particular object and what you can do with it extends even beyond just
driving. You could potentially present your driving license and get an
authorization to drive *my* car in return. But even then you don't get
to drive my car simply because you are saying you have an authorization
to drive *my* car. That may cause you to drive my car when your intent
was different (merely to announce that you could if you wanted).

I think this highlights some other problems with trying to fit OCAPs
into the VC/VP model. There are some odd semantics to overcome if
someone wants to "present" an OCAP using Verifiable Presentation
machinery. As they are presenting the fact that someone said they
possess an OCAP rather than creating a proof that is explicitly invoking
it. You don't invoke a Verifiable Presentation -- you invoke the OCAP,
so that's where the proofs should be attached. It seems to me that a
number of rather semantically-confusing hacks would have to be
implemented in order to cause OCAPs to travel inside of VCs.

IMO, this suggests to me that trying to fit OCAPs into the existing
VC/VP standard may be moving backwards toward a world where the
semantics for VCs are in people's heads, not in the data itself. A major
reason for much of the VC work was to make data more self-describing and
capable of being used across contexts without needing to go through a
centralized authority for extensibility.

Existing work (JWT claims, etc.) could not do this and were very limited
in what they could convey across contexts. This is because they really
were more useful as authorizations for a specific party, not merely
statements of identity. The existing work emphasized the authorization
use cases first rather than the identity ones and then said "This could
work in the identity cases too" without a focus there. The result was a
half-measure that never really solved the bulk of the identity use
cases; that's why VCs sprung into existence. I suspect we'd be making
the same mistake in the opposite direction to try and bend VCs back
toward authorizations ... just because maybe we could squint and make it
work.

OCAPs are an improvement over other authorization schemes for a variety
of reasons, and flavors such as ZCAP-LD do include some level of
self-describing information as well, but it is less of a concern because
they are intentionally not used across contexts. There is only one
"verifier" or one "type" of object for a given capability. What you can
"do" with an OCAP is not open-ended -- it is strictly defined by the
verifier (which is the same party as the original "issuer"). VCs are the
opposite and intentionally split the issuer and verifier parties apart
-- even if you can have one party play both roles for some use cases.

This means OCAPs and VCs have very different economics as well. VCs are
designed for an ecosystem where issuers can create valuable VCs to be
broadly used across many verifiers precisely because they are fully
self-describing and issuers are confined to only making statements
that express properties of identity about subjects. Issuers needn't be
concerned about what authority is conferred because they do not grant
any authority. Only verifiers do that. Issuers do not *need* to know or
care about how these properties may be used -- and interesting new ways
to use them may crop up long after issuance.

OCAPs are quite the opposite; their use is strictly defined and limited
by the original granter of authority. This also means that, as a granter
of a capability, you don't need to gather as much community consensus
around what the meaning of a particular authorization is in order for
what you're granting to be useful across contexts ... because that would
be an abuse of the OCAP. You are explicitly not making a statement of
authority that is intended to be used *anywhere* except on the target
object.

Of course, since VCs are based on an open world model, you can try and
put anything you want into them. That doesn't mean it won't get
cumbersome or that everything *should* be put into them. Furthermore, a
VC is always: "An issuer says these things are true about X". This is
perhaps more restrictive than some people are thinking.

Sure, you can substitute anything into "these things" or "X", but you
can't change the rest of that sentence. A VC cannot say you have
authority, it can say an issuer says you have authority. It is not an
authorization itself. It could be used by some decision engine to
*decide* to grant authorization, but that "granted authorization" is
what an OCAP is. The OCAP *is* the authorization: delegatable and
invocable at a particular target object -- and not to be confused with a
statement of identity. Similarly, as mentioned above, a VP does not say
you're invoking an OCAP -- if you were to present one "as a VC". Rather,
it would say that you're *announcing* that an issuer *says* you have an
OCAP. I think these differences are important and confusing them leads
to subtle vulnerabilities.

My current view is that the main confusion here may be over the
difference between VCs and LD Proofs, not VCs and ZCAPs. VCs are not a
generalized container for attaching a cryptographic proof to a document.
That's what LD proofs (or JOSE style proofs) are for. VCs *use* LD
proofs (or JOSE style proofs) to attach an assertion proof to a document
that specifically models statements made by an issuer about some
subject, which is therefore inherently about the identity of that subject.

Lastly, even if we were to say "let's combine ZCAPs and VCs" -- we'd
*still* need to agree on a data model for expressing OCAPs inside VCs.
If we want that to be standard (which is what standardizing ZCAPs is
about), then that work doesn't "go away" just because you put a ZCAP in
a VC as a "credentialSubject".


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Saturday, 5 December 2020 20:20:33 UTC