Re: VCs - zCaps / OCap a Discussion

On 06/12/2020 15:38, Christopher Lemmer Webber wrote:
> David Chadwick, you are completely correct that these are not new, and
> that Verifiable Credentials can be used as an authorization system, and
> as an authorization system resembles RBAC and ABAC, which are both in
> the ACL-style world of identity-based authroization systems.  I agree
> that this is possible, and what we get out of layering authorization on
> top of an identity-oriented system.
>
> Now the question is, is an RBAC/ABAC/ACL style system *equivalent to*
> an ocap/zcap style system?  And I'm going to say: no.  And I'm not the
> first one!  This is called "the equivalence myth" in ocap circles,
> and has been long documented:
>
>    https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
>    http://www.erights.org/elib/capability/duals/myths.html#equiv-myth
>
> So now that we've established that VCs as an authorization system will
> result in ACL/RBAC/ABAC systems,


Sorry no we have not established that. What we have established is that 
VCs can act as an ACL/RBAC/ABAC system (which I termed indirect authz) 
by assigning an identity to a key, and also as a capability system 
(which I termed direct authz) by attaching a capability to a key, or to 
use your text "Action/command (ocaps/zcaps)"

Kind regards

David

>   and that such systems are *different*
> from ocap/zcap style systems, the question is now a design *choice*.
> I have made, at length, my argument for why, understanding this, we want
> a clean separation and thus to choose ocaps/zcaps for authority at great
> length already in the following post:
>
>    https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html
>
> But I appreciate your clear categorization of which authorization-camp
> we will end up if we build such authorization on top of VCs.  That helps
> make the conversation much easier!
>
>
> David Chadwick writes:
>
>> Conceptionally Verifiable Credentials are not new. They were first
>> standardised in the 1960s by ECMA as PACs (Privilege Attribute
>> Certificates).
>>
>> "Authentication and Privilege Attribute Security Application with
>> related key distribution
>> functions" Standard ECMA-219, 2nd edition - March 1996
>>
>> They have always been authorisation tokens, whether directly or
>> indirectly. Using them for identity is simply indirect authorisation
>> via ABAC and RBAC.
>>
>> Every plastic card I have in my physical wallet today is an
>> authorisation token, whether directly or indirectly. If it did not
>> confer some privilege on me, I would not make space for it.
>>
>> I agree with Daniel, schemas will need to be defined to store
>> different types of authz credentials in VCs, But that is not new
>> either. Schemas are needed for all the properties that are assigned to
>> VC subjects.
>>
>> Kind regards
>>
>> David
>>
>> On 06/12/2020 01:37, Christopher Lemmer Webber wrote:
>>> 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 Monday, 7 December 2020 09:42:18 UTC