W3C home > Mailing lists > Public > public-credentials@w3.org > November 2018

Re: STRONG -1 to "authorized capabilities", and let's consider renaming costs

From: Joe Andrieu <joe@legreq.com>
Date: Fri, 09 Nov 2018 03:46:03 -0800
Message-Id: <1541763963.1017257.1571185576.5FF93555@webmail.messagingengine.com>
To: public-credentials@w3.org
I'm also curious if there is a distinction between OCAP-LD and object
capabilities in general. The former is clearly a proper noun denoting a
specific instantiation, but is it a full enough implementation of object
capabilities to support the generic label? For instance, hypertext
transfer protocol (http) and hypertext markup language (html) clearly
met that standard. When I'm thinking from this direction, OCAP-LD feels
like a good name.
If I put my hat on in the other direction, I think points that both Mark
and Chris Webber have made are speaking to the wrong audience. I don't
think the world of people who already understand and appreciate OCAP are
the important audience for evaluating the best name. If the
specification walks like an ocap and talks like an ocap, they will
recognize this new standard is object capabilities and to the extent
that people outside that community pick it up and start to use it, they
too will embrace the term. IMO, this is why hypertext researchers,
developers, and advocates had little trouble adopting the term "the web"
rather than calling it "hypertext". Because regular people understood it
better and it captured enough of the original intention to be in
integrity with what they care about. (Interesting to note that TBL used
both from the beginning: the standard used the more technical term
"hypertext" while the world embraced the more accessible "web").
Two independent points:

First, I think the audience for the name are the developers and decision
makers we want to adopt object capabilities. Clearly, most of us are
convinced ocaps are awesome, but despite decades of research and
advocacy, they simply have not caught on. I don't think that's because
of a lack of good implementations or specifications. When a topic is a
hot item and easily understood (like the web was), devs and CTOs and
CEOs will invest what it takes to make it work, including customizing or
writing from scratch if necessary. I think a major reason they have not
been adopted is because there is too much of a cognitive burden between
the term "object capabilities" and how they help. In contrast, Access
Control Lists (ACLs) say EXACTLY what their adopters want them to do. I
love Alan Karp's point that "ACLs don't". But they are are brilliantly
named for people who WANT them to. This is a great example of winning by
framing in the way of George Lakoff.
Second, one of the most influential works in the history of naming is
_Positioning_ by Ries and Trout. I'd like to suggest that before we wrap
up our bikeshedding we take their approach to heart. In positioning, R&T
talk about anchoring the innovation to something already understood by
the target audience. That by relating the new product (or technology in
our case) to what people already understand, you enable people to
remember it within the context of their current world view. If instead
you present the innovation as some fancy new fangled neologism, you
*may* be able to make an emotional impression with your branding, but
people will struggle to remember it and even worse, struggle to
communicate it to others. This clear, almost mechanical relationship to
existing referents is what enables people to incorporate this new idea
into their existing rational framework. R&T cite Seven Up's "The UnCola"
as a brilliant example. Or Tylonol's "The non-aspirin pain reliever.
Aspirin sometimes causes stomach bleeding." Both of these products used
this approach to reach the #1 spot in their self-defined categories (non-
cola carbonated beverages and non-aspirin analgesics). If the product
doesn't relate to something your customer already understands, they
can't relate to it. And that's the core problem with most of these
naming proposals.
I want to recognize the intensity of Chris Webber's rejection of
"Authorized Capabilities". I'm not sure how it triggers the association
it does for him (to me the term invokes nothing about ACLs or
traditional "identities"), but clearly he feels strongly about it and
that matters to me. Within our community he's done as much as anyone to
connect the fabulous work of decades to our current goals. And yet... I
think it is still the best candidate. None of the other terms better
address the need for audience adoption with minimal cognitive overhead
and without violating the core premise of the technology.
"Authorized capabilities" did test better with laypeople, in my limited
trials. When compared with "Authorization capability", it conveyed more
of what we mean. If you have an authorized capability, you could do the
thing embodied in the capability; if you have an authorization
capability, you are able to authorize things. And yet, I don't think it
does anything to address Ries & Trouts lessons from _Positioning_.
"Capabilities" simply aren't something in people's common understanding--
not in the way we mean them. So I expect there are still better options
out there.
We would do well to try out our suggestions outside of this email list
with the kinds of people we are seeking to influence. Put the phrase out
there without further explanation and ask what they think it means. Do
this for a couple terms and ask for comparisons in terms of what they
would expect they could do with such a thing.
Authorization Credential? (I know, I know...)
Delegated Capability? (not much better than authorized capability at
first glance)Delegated Authorization? (hmm... not sure it connotes the digital thing
issued as opposed to the policy decision)Embodied Authorization?
Magic Key?

-j


On Thu, Nov 8, 2018, at 8:05 PM, Mark Miller wrote:
> Hi Manu!
> 
> No, I don't mind a different name if the name is trying to draw
> attention to a distinction. I don't think "decentralized-capabilities"
> works for the distinction you have in mind, but I understand it is
> just an example. I don't see anything about them that is specific to
> decentralized systems. To figure out what category you're trying to
> name, consider some similar systems and try to determine whether they
> are or are not in the same category:> * CapCert
>   http://wiki.erights.org/wiki/Capability-based_Active_Invocation_Certificates> * The signed c-list messages of
>   https://www.youtube.com/watch?v=YXUqfgdDbr8&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2> * SPKI/SDSI
> * Macaroons
> 
> Note that I consider the first two to be cert encodings of ocap
> messages, whereas the last two are not.> 
> I like "reference-capabilities", but they are an example of a
> different principle. Reference-capabilities are *not* object-
> capabilities, but they are closely related; close enough to consider
> them a distinct kind of capability. Pony and Kappa have both reference-
> capabilities and object-capabilities. The most elegant statement of
> the difference comes from Elias Castegren of Kappa. Paraphrasing:> 
> By holding an object-capability, you can do certain things.
> By holding a reference-capability, you know that others cannot do
> certain things.> 
> In both cases, what is held is a reference to an object, where the
> reference has both natures. It's reference-capability nature is in
> its static type of the reference; similar to the reference types of
> Rust. Its object-capability nature is the static type of the objects
> it can point at, and especially in what actual object it dynamically
> points at,> 
> 
> 
> On Thu, Nov 8, 2018 at 2:38 PM Manu Sporny
> <msporny@digitalbazaar.com> wrote:>> On 11/8/18 11:42 AM, Mark Miller wrote:
>>  > If you mean something other than what we mean by 
>>  > "object-capabilities", by all means, *please* use a different name>>  > rather than dilute the meaning of "object-capabilities".
>> 
>>  Would you be opposed to naming a specific subset of "object-
>>  capabilities"?>> 
>>  For example, the currently named OCAP-LD specification is a
>>  certificate-based system that kinda sorta separates designation from>>  authority and is used almost purely in decentralized systems.
>>  It's still>>  part of the "object-capabilities" ecosystem.
>> 
>>  So, would you be opposed to something like "Decentralized
>>  Capabilities",>>  which are a sub set of the broader "object-capabilities" space
>>  like what>>  was done for "Reference Capabilities"?
>> 
>>  -- manu
>> 
>>  -- 
>>  Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)>>  Founder/CEO - Digital Bazaar, Inc.
>>  blog: Veres One Decentralized Identifier Blockchain Launches
>> https://tinyurl.com/veres-one-launches
> 
> 
> -- 
>   Cheers,
>   --MarkM

--
Joe Andrieu, PMP
joe@legreq.comLEGENDARY REQUIREMENTS
+1(805)705-8651Do what matters.
http://legreq.com[1]


Links:

  1. http://www.legendaryrequirements.com
Received on Friday, 9 November 2018 11:46:26 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:50 UTC