Should ld-ocap be built on top of Verifiable Credentials?

[cwebber]

This has come up in #5 and in this issue on the VC repo but it really is its own discussion.

First off, can ld-ocap be built on top of Verifiable Credentials? Probably, though it may be awkward to do so particularly because the concepts of attentuation and delegation are completely different within a capability context (they aren't advisory as to what should be done but are something that an algorithm does). But we could probably shoehorn it in and indeed both have many of the same fields, so it may appear that they should.

My feeling at the moment though is that even though we could, we shouldn't, because this will result in developers having to implement two completely different behaviors depending on whether they are using a VC or an ld-ocap capability, and developers probably won't condition-switch correctly, and so they will do things wrong. By this I mean that if you treat ld-ocap as an identity, it actually becomes an ACL, which we don't want. A clearer explaination on why this is coming in the next post :)

[cwebber]

So, why are the behaviors for these systems different? First let's look at what an ACL is vs an Object Capability:

• ACL: Authority by identity and association. You can do such a thing because someone said you could do it (Alice can access her bank account), or that you are the kind of person that can do it (Alice is a member of an audio engineering group, and audio engineers from this group are allowed backstage at this concert). This is easy for many people to understand because we are used to associating information about people. Unfortunately it can lead to security problems... if Alice would like to allow an accounting service to read her bank account transactions, she may have to give them access to her entire bank account so the bank can act "as Alice", and Alice might not like that her bank could then transfer money. It can also be hard to determine the differences of purpose in a system which can lead to "confused deputy" bugs (where it can be hard to determine what "purpose" one's authority can be used for).
• ocap: Authority by possession. You can do something because you hold onto a particular capability that lets you do something. If you have a key, you can drive a car. Using that key you may be able to derive and delegate a valet key from which one can drive the car a certain number of miles, but they can't also open the trunk. Likewise, if Alice were using capabilities for her bank account, she could hand out a capability with a caveat that permitted her accountant to be able to read her recent transactions but not to be able to purchase anything. The important thing here though is (even if the capability has this information encoded in it), we are not checking that Alice or Alice's accountant are people who are allowed to access her account... they can access it because they possess a capability that lets them do so.

Understanding now the difference between ACL identity-based-authority and ocap possession-based-authority, we can now examine how this relates to Verifiable Claims.

Verifiable Claims is an excellent system to associate information about identities. We can talk about Alice being a system administrator or being part of an audio engineering group, and these are useful things to say about Alice. But now we start to see... associating information about identities is the ACL approach. Object capabilities must not pay attention to the associated identity information at invocation time, or they will become ACLs instead... they must focus on possession, and we have an algorithm that does so. Given that, will implementors of a VC consuming system correctly identify that they need to treat object capabilities layered on top of it differently?

My experiences of working with developers and being a developer tells me "no", and thus I think that to avoid confusion, these should be two different systems. They are both useful! We need to, as humans/reasoning agents, associate information about entities. In fact, if I were to hand you, as an accountant, a capability to read my bank account information, you'd better believe I'd want to check your credentials from someone I trust!

[David-Chadwick]

One component of your argument is about the benefits of bearer credentials vs credentials that are tied to a specific holder. From a security perspective, the latter are preferred, since they cannot be stolen and used 'as is' by an attacker. So I would argue that authority by possession is actually a retrograde step and takes us back to the SAML model of bearer tokens. It is preferable from a security perspective for tokens to be tied to holders.

Secondly I do not think that you argument is technically sound. If Alice has a token that says "Alice can access her bank account" this does not mean that she has to give an accountant full access to her account, as you assert. She can delegate a restricted token to an accountant that says "accountant X can access Alice's bank account, with a caveat that permits the accountant to be able to read her recent transactions but not to be able to purchase anything". Why do you not allow the ACL approach to place similar restrictions in delegated tokens as in your OCAP approach?

[cwebber]

One component of your argument is about the benefits of bearer credentials vs credentials that are tied to a specific holder. From a security perspective, the latter are preferred, since they cannot be stolen and used 'as is' by an attacker

I didn't say anything about bearer credentials in this post! Linked Data Capabilities aren't bearer credentials, and "seeing" them gives you no power. They are certificate-style capabilities, which means the invocation must sign with a key or proof method specifically designated by the certificate chain. While there are such things as bearer based capabilities (Macaroons is one), ld-ocap is not such a system.

Secondly I do not think that you argument is technically sound. If Alice has a token that says "Alice can access her bank account" this does not mean that she has to give an accountant full access to her account, as you assert. She can delegate a restricted token to an accountant that says "accountant X can access Alice's bank account, with a caveat that permits the accountant to be able to read her recent transactions but not to be able to purchase anything". Why do you not allow the ACL approach to place similar restrictions in delegated tokens as in your OCAP approach?

The key difference is we never use ld-ocap documents to "talk about" a person, ever. It's a power to do something. VC do talk about specific entities, and that are their primary purpose. Since we do that, switching between whether we look at VC as a method to talk about someone versus covering our eyes as to who's there and checking that the certificate chain is valid given an invocation are two different implementation paths. So at least, can we agree that if using VC that it's quite likely an ACL path?

This will be made clearer as I respond to this post next.

[cwebber]

Okay, regarding this post:

Assume we have an authz token (it could be a VC or OCAP, the format is not important for now) that allows someone to drive a car. This authz token could say either

• "Fred is authorised to drive car X" or

This one is definitely an ACL because the perspective is "talking about Fred".

• "the holder is authorised to drive car X" or

This one is closer to ocap, and in fact if we did bearer-style object capabilities (eg Macaroons) we could consider this a capability because it's "what the entity holds on to that enables them to invoke some action". I agree that VC can do bearer-style ocap. However, the fact that we say "the holder is authorized" makes it sound like bearer style ocap rather than certificate style ocap, and as we did agree earlier in this thread there are many cases where "seeing" the ocap chain doesn't give you power to use it (ie certificate style ocap such as the Zebra Copy system and ld-ocap) since the invoker must also sign with a cryptographic method specified in the certificate chain.

• "Fred is an authorised driver" or
• "the holder is an authorised driver".

These are both straight-up ACL style groups/roles.

Which of these do you call an ACL model

I answered this above. Three of them are ACL perspectives, and one of them is arguably a bearer-style ocap (which could be done via VCs and that's fine), but none of them are certificate-style ocaps.

and what do you call the model for the other non-ACL models?

So maybe we should say, what is a certificate-style ocap design? A ceritificate-style ocap design requires that we ignore anything about "what type of entity" the invoker is... we are checking whether or not an invocation should move forward based on a boolean evaluation of whether or not the invocation is valid given a capability chain. This flows out of the target initially handing out a capability to itself to some entity, which can delegate and attenuate from there... in VC any entity can say something like "oh yes, this person is an authorized driver" and we may have to perform some reasoning about what we think about the issuer. That doesn't happen in ld-ocap... no reasoning involved, we just check whether the capability chain is valid.

VCs are all about identity and associating information with identities. ld-ocap does not care at all about the identity (though reasoning about identity may happen at an entry point to deciding that someone is "worthy" of being handed a capability, or deciding that we should revoke someone's access... but that is the role of reasoning agents, ie mostly humans and maybe some AI, but not the boolean pass-or-fail invocation check of ld-ocap).

Furthermore it also allows the token to be restricted to car X through a policy constraint.

This is one of the most important distinctions! Attenuation in ld-ocap (with caveats) is not a policy constraint, it is not "terms of use"... it is checked by code, not by humans. It may be valuable to combine with "terms of use" style policy, and this would be what Mark Miller calls "split contracts", where there is both a code component and also a policy component which can be checked by an arbiter specified in the system. In that way we might be able to have VC and ld-ocap cooperate!

[cwebber]

On that note there is no requirement that you be sold on ocap design, and we know that building ACLs is possible on top of Verifiable Credentials. So if your concern is mostly "ACLs vs ocap", and you say ACLs are better, there is nothing stopping you from building ACLs on top of VCs. This thread is about whether we should build ld-ocap on top of VCs... and I hope I have demonstrated by now that whether you want ACLs or ocap, trying to build ocap on top of VCs will actually accidentally result in building ACLs.

[cwebber]

BTW, some of this is documented in the ld-ocap spec itself. I'd encourage anyone considering commenting on this thread to read the following sections: Linked Data Capabilities By Example, Capabilities Are Safer, Relationship to Verifiable Credentials, and Handling Abuse.

[MostAwesomeDude]

One component of your argument is about the benefits of bearer credentials vs credentials that are tied to a specific holder. From a security perspective, the latter are preferred, since they cannot be stolen and used 'as is' by an attacker. So I would argue that authority by possession is actually a retrograde step and takes us back to the SAML model of bearer tokens. It is preferable from a security perspective for tokens to be tied to holders.

Hi! Let's talk about capabilities, or 'caps' for short. Your argument, as phrased, is a wonderful intersection of all three myths tackled in Capability Myths Demolished. To summarize, the argument that an attacker can arbitrarily invoke a stolen capability, and thus capabilities are bad, overlooks two features of capabilities: we can design delimited capabilities which cannot be arbitrarily invoked, and revocable capabilities which can be rendered useless by the issuer.

To expand this concept somewhat, consider a world where identity tokens are capabilities. Specifically, we're using a swissnum construction, so that a capability is merely an unguessable bitstring, like a cryptographic secret. Indeed, it's common for unguessable capabilities to be represented cryptographically.

In this world, one's identity cap would allow them to be known as themselves. One could lend out one's identity temporarily, or on a limited ("attenuated") basis. But an attacker who stole an identity cap would be able to impersonate them at will. It would be a game-over situation.

Now, imagine a world in which caps can represent not just identities, but arbitrary object references, as in an ocap programming language or a cloud platform like Sandstorm. In this setting, an attacker might steal non-identity caps, which would not necessarily be the end of the line in terms of security. While game-over situations still exist, an attack which exfiltrates caps or otherwise violates security invariants is not guaranteed to leak identity caps.

The punchline, of course, is that the former identity-cap-only world is the world of session fixation and user-chosen passwords and other such fun. We don't have to suffer this existence, but we choose it every time we choose to care about identity. As Chip puts it in his introduction to capabilities,

When a system, such as an OS or a website, is presented with a request for a service it provides, it needs to decide if it should actually do what the requestor is asking for. The way it decides is what we’re talking about when we talk about access control. If you’re like most people, the first thing you’re likely to think of is to ask the requestor “who are you?” The fundamental insight of the capabilities paradigm is to recognize that this question is the first step on the road to perdition.

He continues, noting,

That’s highly counterintuitive to most people, hence the related controversy.

I hope that this has been somewhat enlightening. To close with a wonderful analogy, imagine stabbing a water balloon with a knife, and then stabbing a sponge with a knife. They both leak water when damaged, but one more so than the other; the balloon has only a single barrier between the water and the outside world, while the sponge has structural reinforcement which retains many small pockets of water.

[cwebber]

@MostAwesomeDude Thanks for the helpful post! I agree with what you said there in general and these are very helpful references.

I think part of the confusion though is explaining how ld-ocap and the Zebra Copy style certificate chain style ocaps differ from the bearer style ocaps. Part of the confusion is that "certificate style ocaps" appear to separate designation from authority (which is partly what keeps them safe when interception is a possibility or when they can be observed publicly, such as on a blockchain)... which is one reason I am putting an emphasis on the paradigm of capabilities as possession (vs identity association).

[cwebber]

Much more conversation was made on this PR for Verifiable Credentials. However, we are moving conversation back here again.

[David-Chadwick]

Unless I am wrong, you seem to be asserting that ACLs should be encoded as VCs, and OCAPs as ocap-lds. I am trying to determine where the border between ACLs and OCAPs lies because I do not think it is as black and white as you think. Here is a taxonomy of 6 different types of credential. Which should be encoded as VCs and which as ocap-lds, and why? But first some definitions that I am using:

Credential: the token possessed by someone or something that gives them a certain privilege or permission. It could be a VC or an ocap-ld.
Permission = the ability to perform an action on an object e.g. drive a car, read a file, delegate a credential
Privilege = the indirect ability to perform an action on an object, by virtue of some other attribute e.g. a role, a position in society, an identity

Based on the above definitions, we have the following 6 types of credential (at least):
i) a bearer permission. This credential states the action and the object e.g. can drive car X. Anyone or anything that possesses this credential can perform the stated action on the stated object.
ii) an identity permission. This credential states (the identity of) the subject, the action and the object e.g. David can drive car X. Anyone who can prove they have the stated identity can perform the action on the object.
iii) a keyed permission. This credential states the cryptographic key material, the action and the object. e.g. Key ID Y can drive car X. Anyone or anything that has the key material Y can perform the action on the object.
iv) a bearer privilege. This credential states the attribute that the holder of the credential possesses. e.g. the bearer is the President of the US. The holder will inherit all the permissions of the President of the US.
v) an identity privilege. This credential states (the identity of) the subject and the attribute that the subject possesses e.g. David is the President of the US. Anyone who has this credential and can prove they are David will inherit the permissions of the presidency.
vi) a keyed privilege. This credential states the cryptographic key material, and the attribute that the holder of the credential possesses e.g. Key ID Y is President of the US.

[dlongley]

Pasting my response from the other thread over here:

@David-Chadwick,

I'm sure others will have something to say here, but here's my initial attempt at breaking things down in a simple way...

A "VC issuer" gives you a VC. A "VC verifier" gives you an OCAP.

Permission = the ability to perform an action on an object e.g. drive a car, read a file, delegate a credential

This is an OCAP.

Privilege = the indirect ability to perform an action on an object, by virtue of some other attribute e.g. a role, a position in society, an identity

This is a VC with the caveat that the issuer doesn't get to decide what the privileges are -- they simply to make claims about the characteristics/attributes that an identity possesses. It is up to a verifier of the VC to make a decision as to what permissions (capabilities) to give out on that basis. From there, the capabilities can be used without needing the identity information any longer. An OCAP-verifier may require authentication in order to accept an OCAP, but it does not require identity. OCAPs may also be delegated without the use of identity -- again needing only authentication.

OCAPs are for doing things and VCs are for talking about things.

[dlongley]

@David-Chadwick wrote:

this one still isnt resolved
ii) an identity permission. This credential states (the identity of) the subject, the action and the object e.g. David can drive car X. Anyone who can prove they have the stated identity can perform the action on the object.
@dlongley says permissions are ocap, but an OCAP does not require identity.
The above does require identity, so what is it?

The OCAP only requires authentication. The only "identity" involved is an identifier. Furthermore, the OCAP is the authority -- it's just that you can't wield (invoke) it without proving who you are.

An OCAP is the explicit representation of authority. This is an important difference from an implied sense of authority that is derived from the attributes or characteristics of who you are. The issuer of a VC doesn't get to decide what authority someone has, the verifier does.

If the verifier wants some authority to be derived from attributes/characteristics, then it may create an OCAP after verifying these attributes or characteristics. Then that authority can be used to do things.

Being explicit in this way helps prevent unintentional mistakes and confusion, establishes a separation of concerns that makes it easier for systems to decouple authorization, and enables simpler and more powerful delegation models.

[cwebber]

@dlongley I think you explained things perfectly. A few more points, or rather, summaries of previous points:

• VCs provide a lot of wiggly room for interpretation (and reasoning!) about an entity and that's extremely useful. But ocaps require a binary pass/fail operation, and it should be absolutely clear whether or not an invocation happens.
• To whether or not we could do certificate-style ocaps using VCs, it's important since VCs are so loose and because VCs are used in general to talk about an entity that we avoid modeling ocaps on VCs, because then we can have many implementations that accidentally misinterpret invocation as being about an entity, and then we get ACLs. If we have two different structures this error won't happen.

[David-Chadwick]

@dlongley. I think your statement "A "VC issuer" gives you a VC. A "VC verifier" gives you an OCAP" is the clearest description of the difference that I have heard, and it a clarifies a lot. However, do you know of any situations in which this 'rule' might be broken? for example
i) who should issue a credential to drive any car in the car pool? I don't think it could be the car itself. But could a car in the car pool accept this if it was issued by management, or would it need to have a specific ocap credential that it issued itself before allowing an employee to drive it?

ii) who should issue a credential to go to a specific concert? We have already suggested that a bearer VC can be used for this, but if it is issued by the concert then shouldn't it be an ocap-ld?

@cwebber by saying 'ocaps require a binary pass/fail operation' do you mean a single binary operation? Because if I am a car in the car pool and I receive a credential from a person saying they can drive any car in the car pool, then I am obviously capable of making a binary pass/fail decision, because I know I am a car in the car pool.

[dlongley]

@David-Chadwick,

i) who should issue a credential to drive any car in the car pool? I don't think it could be the car itself. But could a car in the car pool accept this if it was issued by management, or would it need to have a specific ocap credential that it issued itself before allowing an employee to drive it?

I think the proper way to implement this is for the person to show their driver's license (a VC) and any other required VCs (e.g. proof of insurance) to management. Management then issues them an OCAP to drive any car. Then the person takes their OCAP (which is essentially their "car key") out to any car and uses it to get in and drive. Furthermore, this exact same model would allow you to generate an attenuated OCAP that you give to a valet so they can park it once you arrive at your destination -- without changing anything about the car and without contacting management.

ii) who should issue a credential to go to a specific concert? We have already suggested that a bearer VC can be used for this, but if it is issued by the concert then shouldn't it be an ocap-ld?

I think you should present your VC proof of age (if needed based on the type of concert) and VC band/venue loyalty card (or whatever else) to the (online) ticketmaster and they give you an OCAP to get access to your seat. Then you show up at the concert and wave your OCAP over the turnstyle to get in ... or wave it in front of the door to get into your fancy box seats or, who knows, maybe this is a venue where people really care about which specific seat you're in and there's a lock at your seat that wave it over to release.

[David-Chadwick]

@dlongley Unfortunately your statement 'Management then issues them an OCAP to drive any car' breaks your rule that the verifier issues the ocap. The car (the verifier) did not issue the OCAP in this case.

[dlongley]

@David-Chadwick,

Unfortunately your statement 'Management then issues them an OCAP to drive any car' breaks your rule that the verifier issues the ocap. The car (the verifier) did not issue the OCAP in this case.

First, any party could play more than one role in a given scenario. Second, management is the VC verifier here -- verifying a VC driver's license from the DMV (a VC issuer) and a VC proof of insurance from an insurance company (another VC issuer). Management then grants an OCAP.

The car is not involved with VCs at all. It's a consumer of OCAPs.

[David-Chadwick]

@dlongley . Clearly I misunderstood your distinction between VCs and OCAPs. From the above it appears that the OCAP issuer and OCAP verifier can be different entities (or different roles). So clearly the concepts of issuer and verifier are not the determining factor between VCs and OCAPs as both have issuers and verifiers.
Consider the following:
a) a credential that says the holder can drive Car A, signed by management
b) a credential that says the holder can drive any car in the car pool, signed by management
c) a credential that says the holder is a driver, signed by management
Assuming Car A trusts the management to issue credentials,
Car A can accept credential a) when it is configured to know it is Car A and that drive means 'operate me'
Car A can accept credential b) when it is configured to know it is a car in the car pool and that drive means 'operate me'
Car A can accept credential c) when it is configured to know that drivers can 'operate me'.
Are you saying that a) and b) are ocaps and c) is not?
There seems to be little difference between the three from the car's perspective.

[dlongley]

@David-Chadwick,

VCs are used to make verifiable statements about an identity to be shared with a third party. A VC verifier may use a VC to give someone the right to do something, where that "something" may be different for every verifier for the same VC. The third party decides what the VC is useful for. The same VC can have many purposes -- as it is merely a set of statements about identity.

That "right to do something" mentioned above can be modeled as an OCAP. OCAPs are statements of authority that designate an object that can be acted upon in some specific fashion. OCAPs can only be granted by those with the authority in the first place. This authority is transferable and its invocation may be delayed -- or it may be invoked immediately (which is a common use case). But, there is no third party that can change the authority granted by the OCAP or its designated target. It has exactly one purpose. (Caveat: an OCAP may be delegated with reduced authority, but the nature or target of the authority may not change).

Back to our car example...

Cars have no agency. It is management that has the authority to control and configure the cars and they therefore play the roles of OCAP issuer and OCAP verifier even if it is the software at the front desk that issues the OCAP and the software in the car that is literally doing the verifying.

Perhaps the problem is in distinguishing between verifier as software and a verifier as a role. We've bumped up against this in the working group before.

[David-Chadwick]

The problem I am grappling with is where the transition point between VCs and OCAPs lies. At one extreme e.g. a credential issued by the government saying what my name is, we clearly have a VC. At the other extreme, e.g. a credential issued by car A saying the holder can drive car A, is clearly an OCAP. But we have many shades of grey in between these, and I am trying to tease out at what point a credential should be classified as one (a VC) or the other (an OCAP).

So, a credential issued by management saying the holder can drive a pool car, does not have a single resource or target, but has many (all the cars in the car pool). Which type is this?
A credential issued by management saying the holder is a pool car driver serves the same purpose as the latter, but is actually a role credential. Which type is this?

Now suppose the garage next door comes to an agreement to share pool cars with this garage for reasons of efficiency and cost savings. Taking both of the above credentials (drive pool car and pool car driver) issued by this garage X, which type are they now that another entity (car from garage Y) under different management will still allow the holder of the credential to drive it.

[dlongley]

@David-Chadwick,

So, a credential issued by management saying the holder can drive a pool car, does not have a single resource or target, but has many (all the cars in the car pool). Which type is this?

This is about authorization, so it's not a VC, but an ocap. Management gives the user an ocap that they can use at a car dispenser. They walk out to the lot, pick a car, and use the ocap on the car dispenser -- which has the knowledge to enforce granting authorization to a single car. The dispenser consumes the ocap and gives the user a new one, that is for the specific car they picked. Then they can drive just that car. Note: Doing it any other way may result in the user picking more than one car! (or a more complex security system to ensure they can't do that).

A credential issued by management saying the holder is a pool car driver serves the same purpose as the latter, but is actually a role credential. Which type is this?

A statement made about someone is a VC. It does not represent a grant of authorization but rather claims made about someone (or some thing). A VC verifier could look at it and make a judgment call about whether or not to grant some specific authorization (which would be represented by an ocap). Note that they may also require some other VCs such as a driver's license, insurance proof, and a clean background check. I imagine that the user could present these VCs to a VC verifier which would grant them authorization to receive a car from the car pool via an ocap that the car dispenser would accept.

Now suppose the garage next door comes to an agreement to share pool cars with this garage for reasons of efficiency and cost savings. Taking both of the above credentials (drive pool car and pool car driver) issued by this garage X, which type are they now that another entity (car from garage Y) under different management will still allow the holder of the credential to drive it.

Nothing much changes here from the above.

The user with the VC ("pool car driver") approaches management at one of the two garages. Seeing as the VC allows management to make a judgment call, management at X or Y may accept the same VC (regardless of whether X or Y issued it) and grant authorization (represented as an ocap) for either garage X's dispenser or garage Y's dispenser, respectively.

The user with the ocap ("drive pool car" .. or perhaps better as "dispense car") for garage X will have to use it at the dispenser for garage X (this is a feature, not a bug!). Presumably, this ocap is fairly ephemeral -- intended only to exist as long as it takes for the user to pick their car from the dispenser at garage X. Again, once the user picks their car, they receive another ocap to drive the car they picked.

[kephas]

@David-Chadwick, I don't understand where you see an unclear limit between VC and ocap.

To get back to the real-world analogy, my driver's licence or my certificate as a pool driver don't make me able to drive a car. There is nowhere in the car that I can put any of these so the car will start. These are VCs.

Now, presenting both to the pool manager gets me a key to the garage's key box (that key is an ocap). The key box, like the car, doesn't care about me waving any ID or contract in front of it. But if I invoke the ocap, that is, if I put the key in the box's lock, then I get access to the various car keys. If I get one such key (also an ocap, obviously), I can then invoke it by putting it in the car's door to open it. If it's just a valet key, I cannot invoke it to open the glove compartment, but I can still invoke it to start the car.

When another garage makes an arrangement with the first to let their respective drivers use all cars, they will have to issue new keys. Either I get a master key that open both key boxes, or I keep the first box key and get a second one for the second garage.