- From: Joe Andrieu <joe@legreq.com>
- Date: Fri, 09 Nov 2018 03:46:03 -0800
- To: public-credentials@w3.org
- Message-Id: <1541763963.1017257.1571185576.5FF93555@webmail.messagingengine.com>
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