Re: VCs - zCaps / OCap a Discussion

I wrote my mega-response before reading Dave's; we raise some different
points, but I think Dave frames things nicely as well.

Dave Longley writes:

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

Received on Sunday, 6 December 2020 01:38:33 UTC