During a recent meeting @alanhkarp suggested that the term “Rights Amplification” is easily misunderstood by non-capability folk. (Alan, please expand.)
What might be a clearer, more intuitive term? Or should we consider terms that currently have no current well-defined meaning, so we can claim a space that demands definition?
People misconstrue “rights amplification” to mean that you can “amplify” the rights of a given capability. We mean something closer to “combining” the rights of more than one capability.
I think “combination” is an excellent term. Rights are combined, sometimes achieving power greater than they have individually.
An example of this would be great!
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 3.3.3.3 of The Heart of Spritely.
Hopefully some of the “ocap folk” here will help clarify and/or correct this.
I also found this term counter intuitive. Too close to privilege escalation.
“privilege unlocking” ?
“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”
@dale.schumacher is correct. The term is in the ancient access control literature, which is where I picked up on it. Norm instead used the term “synergy”, which I’m ok with. But to understand why I like “rights amplification” better, see Bringing Object-orientation to Security Programming (Mark S. Miller, Google) - YouTube starting at 28:17 . Though it makes more sense in context, so I’d really recommend watching that talk from the beginning 
The loose electric circuit analogy fits both “amplification” and “attenuation” together so well, it’s like they were both coined together based on this analogy.
All that said, Norm’s “synergy” seems a fine alternative.
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.
Agoric + Protocol Labs // Higher-order Smart Contracts across Chains - Mark Miller - YouTube is probably my best self-contained explanation of the nature of erights.
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.
Besides my thesis, for the formally inclined, I recommend Permission and Authority Revisited: towards a formalization – Google Research . Even though it points out that I made a technical error in my thesis, if you’re not formally inclined, I recommend my thesis anyway.
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 sometimes used authority amplification or access amplification to mean the same. The former usually just after I have explained the difference between permission and authority.
“authority amplification” is good. Still works well with the electric circuits analogy I mention above. Thanks.
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?
A simpler example is an encrypted file. You need capabilities for both the encrypted version and an object that decrypts it.
Ahhh, so it’s referring to when a combo of things (decrypter, item to decrypt) provide access to a new thing that is only accessible with both (a plain text file). Got it, thanks Alan!