We say that “designation implies authorization”. To designate a particular lock means we are authorized to use it (with any key we have). The designate a particular key means we are authorized to use it as well (in any lock we know). It is only in combination, designating the right lock and the right key, that the door can be opened.
Forgive my confusion here - is this an example of “rights amplification” as ocap folk mean it? I was thinking is was something more like Cap A:“do some specific thing passing a parameter to another machine” and Cap B:“read some specific data from this application” and when you “combine” those you get “the right to do that specific-thing passing some specific data from this application as a parameter to another machine.”
IIRC, the “traditional” example is a can and can-opener. The can-opener is needed to access the contents of the can, but the opener is only useful if you have access to the can itself. Sealer/Unsealer is often used this way, as in section 18.104.22.168 of The Heart of Spritely.
Hopefully some of the “ocap folk” here will help clarify and/or correct this.
“In object capability literature, privilege unlocking refers to two separate capabilities, which when combined, enable a set of rights that the two individually do not, similar to how a lock and a key combined permit opening a door.”
This is me experimenting with “what if we used that term and I was explaining it in a document”
What about capability enhancement and capability restriction?
I think these are more commonly understood than “amplification” and “attenuation”, though those might provide a more accurate metaphor.
I also wonder whether the use of “rights” or “privileges” obscures the fact that we’re actually talking about capabilities. In an ocap system, doesn’t having a “right” or “privilege” to do something mean having a “capability” to do that thing? Introducing redundant terminology makes it harder to grok.
Allow me to attempt to respond and see if the more seasoned ocap folks can weigh in. “Ocaps are one way to get a right or privilege, but you can also get them via other mechanisms such as ACLs (though we do not recommend that).” However, I couldn’t personally tell you what a right vs a privilege is, if there is any distinction.
To add two other terms to the mix, @markm has much more specific language about “permissions” vs “authority” in Chapter 8 of his highly recommendable dissertation. I’ve gotten a little bit better about understanding those two, but if you add “right” and “privilege” to the mix I get really confused. At least “capability” means something clear to me.
I do not have clear definitions of “rights” or “privileges”. However I do coin “erights” — as a form of transferable electronic right that can includes assayability and exclusive-rights transfer. This is a distinct layer of abstraction above ocaps.
But these erights are probably not really relevant to your question. Yes, I do define “permission” and “authority” and try to use them precisely. These are generic across access control systems. Both ACLs and ocaps have both permission and authority. In an ocap system, a capability (an object reference) is a permission.
Ah. Given the title of this thread, “Rights Amplification”, I need to point out that these rights have nothing to do with erights. I suppose I now must concede that the term does not rest of settled terminology.
I am still somewhat unsure of what rights amplification means, and I thought of two scenarios to try to clarify it:
Imagine a text search object that takes in a capability to read a sequence of bytes and uses that to create a capability to read a full text index of those bytes. Is this rights amplification? Or is more like composition?
What if I take these two capabilities (the ‘read text’ and the ‘read full text index’ capabilities) and hand them to another object to display them on the screen along with a search bar? Is that composition or rights amplification?