- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Mon, 7 Dec 2020 09:41:59 +0000
- To: public-credentials@w3.org
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