Re: VCs - zCaps / OCap a Discussion

Agreed this is a great discussion!

Responding to Daniels last email in the original thread here, responses are
inline.

> Okay, excellent. I believe we've zeroed in on one root of our divergence,
which is *whether VCs are a general mechanism for verifiable statements, or
are specially dedicated to establishing identity*. This is progress.
Commentary on that subtopic is indented below

I agree, I believe this is the source of disagreement.

> It is true that identity use cases predominate in the minds of VCs
proponents today. However, I don't believe it's correct to consider them
inherently related to identity. Here are several quotes from the VC spec
that might be relevant:

While I agree the extracts you have made, make it sound like the VC
standard sets out an appropriate vehicle for communicating tokens of
authorization, they are however IMO just extracts from the standard and I
don't think they capture the intent of the spec. Instead I think reading
the abstract, introduction and what is a VC section quite clearly outline
that a VC is a cryptographically secure assertion format for communicating
identity claims.

> This is a second point of divergence, also important. *Is it really true
that a capability describes the authority to do something, that this
doesn't describe a subject in some capacity, and that this makes a
capability a different animal from a VC?*


Yes I believe it is truly different to a VC and for good reason, however
given your examples, it depends on who you take the credentialSubject to
be. If the subject of the VC is the intended invoker of the capability,
then the perhaps over-used but relevant example that is given in the
OCAP-LD spec about a physical car key I believe captures why this should
not be the case. In the physical word a traditional car key makes no
attempt to involve the identity of the party using the key to drive the car
it enables, so why should a digital equivalent be any different? An
important nuance here too is even though in a digital representation of a
car key we may elect to bind capabilities to cryptographic keys that are
required to invoke the capability and or delegate the authority it allows,
it does not mean the identity of the party those cryptographic keys are
under the control of need be involved.


> It seems indisputable to me that this assertion is easily represented as
a verifiable credential, without any distortion or abuse of the standard:


Agreed, I don't see any problem with your first example, issuer is amy,
subject of her assertion is the university and the claim she is making is
an opinion about the course she attended. However and I'm sure we both
agree this does not communicate any authority to do something?


> So, now let's imagine that Amy wants to let a few of her friends play
with the robot prototype she's been developing as her capstone project. She
makes another verifiable statement framed in a way that satisfies the VC
spec:


I understand the usage here and I cite Manu's statement in the last email
that this feels a bit like using a hammer to drive a screw to me also. In
particular I would ask:



1. Semantically the use of credentialSubject property here doesn't fit for
me, logically who are you intending is the subject? It appears you are
making the target resource (the thing you want to get access to) the
subject and then using claims (statements within the credentialSubject
property) to describe what the capability permits as authorized actions?
The problem is that from a VC data model perspective, these claims
(describing the actions) look to be instead statements that are describing
the target resource.

2. How does one exercise this "capability", or delegate it if it were
making use of binding the capability to cryptographic material as a
requirement for correct invocation? Again I agree with @David Longley
<dlongley@digitalbazaar.com> in the sense that even if we were to bend the
VC data model in some capacity to try and express tokens of authorization,
there would still be gaps in the data model that are required to be filed
(e.g the invoker, parentCapability properties from the OCAP-LD spec are
examples).


Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Sun, Dec 6, 2020 at 9:22 AM Dave Longley <dlongley@digitalbazaar.com>
wrote:

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

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.