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

+1

The term we using in standards working groups need to align to terms used
by academic research and others in the technical sphere. Our marketing
departments can find cute names to package them in to explain things to
non-technical customers.  (Which I believe is where this thread started.)

    -chrisb

On Thu, Nov 8, 2018 at 8:44 AM Mark Miller <erights@gmail.com> wrote:

> We've been using the term "object-capabilities" and "ocaps" since, IIRC,
> at least 2003 "Capability Myths Demolished", where we used it to
> distinguish the original capability paradigm (as used starting in the
> Dennis and Van Horn 1965 operating system) from the many systems that came
> afterwards that used "capability" to mean other things. The ocap term is
> adopted by all modern ocap systems and present in a *lot* of systems,
> papers, talks, .... Unlike the dilution of the original "capability" term,
> we have successfully defended the meaning of "ocap", getting other systems
> that were not ocap but using the term to change their name to something
> else.
>
> In CS, it is rare to achieve the success we had in making a term both
> widely recognized and clearly defined. 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". But
> if you mean the same thing, please do not confuse matters after our 15 year
> hard investment of effort to establish this name and its meaning, and to
> build a community of interest around these ideas.
>
> In any case, yes, I will continue to use "object-capability" for systems
> that operate according to object-capability principles. I feel confident
> that the community of other ocap researchers will as well.
>
>
>
> On Thu, Nov 8, 2018 at 6:44 AM Christopher Lemmer Webber <
> cwebber@dustycloud.org> wrote:
>
>> Naming is the ultimate bikeshed (https://shed.bike/), but I have serious
>> opinions about some of the paint colors being proposed.  Two separate
>> points.
>>
>> ==== Strong -1 to "authorized" ====
>>
>> Okay, it sounds like I wasn't heard loudly enough and other people are
>> converging on "authorized" capabilities as opposed to "authorization"
>> capabilities.  Please read what I wrote in the email quoted below.
>>
>> I am giving a *STRONG -1* to "authorized".  "Authorization" makes sense,
>> but "authorized" *WILL* lead people down the wrong path of thinking it's
>> about an "authorized entity" and *that is not what ocaps/zcaps are*.
>> (For the most part, ocaps don't consider details about what entity is
>> calling them, and this turns out to even be key for their
>> functionality.)  I have read every other proposal in this thread and so
>> far "authorization capabilities" is the only term while, not great, does
>> not lead the reader down a misleading path as far as I can tell.
>>
>> ==== As for whether we *should* rename/alias... ====
>>
>> BTW, while I think "authorization capabilities" makes sense though is
>> wordy, and "zcap" makes sense as a term (though I agree with Christopher
>> Allen that it sounds a bit too much like zero-knowledge-foo, and even
>> worse "zcaps" sounds almost just like "zcash", the most famous ZKP
>> system of all), I think it's also worth putting on the record that I
>> went to the ocap conference and fielded the term "zcap" and any renaming
>> does not appear that it will be welcomed by the existing ocap community.
>> They've been through lots of naming bikesheds before, and many of them
>> are very wary of disconnecting the term from its existing history.  Mark
>> Miller suggested not calling it "object capabilities" but just "ocaps"
>> and let that term stand on its own, though I know Manu does not agree
>> because people will wonder what "ocaps" stands for and we'll be back
>> where we started.
>>
>> But there is a risk here that we are going to split messaging efforts,
>> and people looking up information about zcaps won't be able to find
>> existing documentation about ocaps if we do this, especially a problem
>> because collaborating with the Agoric folks who are also pushing forward
>> ocaps right now may be a good idea... it may make it harder for us to
>> collaborate with them.  Naming splits can have serious consequences,
>> even when justified... the FOSS world is still hurting from many naming
>> splits today, even ones that happened 20 years ago.  The decision to
>> even alias has to be taken carefully, and might result in two
>> hurt-feeling camps that feel that they are right and weren't listened
>> to.
>>
>> That said, yes I fully understand why Manu and friends have been trying
>> to get people to understand ocaps and haven't succeeded, and why naming
>> may have a good portion to deal with it.  I agree that "object" confuses
>> people, though I think the main problem is lack of exposure to useful
>> resources and everyday usage than the name itself; programmers survive
>> all sorts of weird terms like "lexical scope", and even non-programmers
>> get a "feel" for certain terms that they don't understand why they are
>> called such; what the hell is "scrum"?  Yet lots of people are extremely
>> passionate about "scrum" being the one true way to do project
>> management.  (I didn't even know it was related to Rugby until I looked
>> up the definition after typing this sentence, despite talking to plenty
>> of people about "scrum" for years).
>>
>> My point here is, we shouldn't take this rename lightly; with sufficient
>> resources, we can succeed at getting people familiar, and even if the
>> name is "better", it does come with a serious cost.  Maybe it's still
>> worth it anyway, but we should seriously, seriously weigh that before we
>> flip the switch.
>>
>> PS: I have been talking with a couple of the folks at Agoric about some
>>   introductory materials to explain ocaps to the non-familiar and I
>>   think we may be on to something.  That can help with the above, but
>>   also demonstrates the challenge of the rename; if they don't buy in
>>   to a rename, we might not be able to easily collaborate on such a
>>   resource, because we won't even agree what to call it.
>>
>> Christopher Lemmer Webber writes:
>>
>> > I'm not as big a fan of "authorized", because while "authorization"
>> > sounds like something presents, "authorized" sounds like some entity has
>> > received authorization and we're checking so by checking against some
>> > list... eg "dlongley is authorized".  But ocaps/zcaps aren't tied to an
>> > identity, so I think "authorization capabilities" is less likely to
>> > mislead, even if longer.
>> >
>> > Joe Andrieu writes:
>> >
>> >> +1/2
>> >>
>> >> I like changing it, but I would suggest Authorized Capabilities.
>> >>
>> >> First, it's easier to say.
>> >>
>> >> Second, it states the actual function more clearly: if you have an
>> >> authorized capability, you're authorized. If you have a zCap, you're
>> >> authorized. Or, in the inevitable vernacular, if you have a capability,
>> >> you're authorized.
>> >> "Authorization Capability" reads to me as if the holder has the
>> >> capability to authorize--which is only true if its delegatable and not
>> >> true in the generalized case.
>> >> Bikeshed on...
>> >>
>> >> -j
>> >>
>> >>
>> >> On Sat, Nov 3, 2018, at 9:40 AM, Darrell O'Donnell wrote:
>> >>> +1
>> >>>
>> >>>
>> >>> *Darrell O'Donnell, P.Eng.*
>> >>> darrell.odonnell@continuumloop.com
>> >>
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Nov 3, 2018 at 12:24 PM Brent Zundel
>> >>> <brent.zundel@evernym.com> wrote:>> +1
>> >>>>
>> >>>> On Sat, Nov 3, 2018, 10:14 Jordan, John CITZ:EX
>> >>>> <John.Jordan@gov.bc.ca wrote:>>> +1
>> >>>>>
>> >>>>>  > On Nov 3, 2018, at 08:27, Manu Sporny
>> >>>>>  > <msporny@digitalbazaar..com[1]> wrote:>>>  >
>> >>>>>  > Hi all,
>> >>>>>  >
>> >>>>>  > This is related to the OCAP-LD spec that some of us are working
>> >>>>>  > on in>>>  > this community:
>> >>>>>  >
>> >>>>>  > https://w3c-ccg.github.io/ocap-ld/
>> >>>>>  >
>> >>>>>  > Digital Bazaar's engagement with customers over the past several
>> >>>>>  > months>>>  > wrt. the term "Object Capabilities" has resulted in
>> confusion
>> >>>>>  > around>>>  > exactly what an Object Capability is.
>> >>>>>  >
>> >>>>>  > Some history -- the "Object Capabilities" name was originally
>> >>>>>  > picked to>>>  > differentiate from the "Linux Capabilities"
>> stuff, which really
>> >>>>>  > didn't>>>  > have much to do with capabilities (in the
>> authorization sense).
>> >>>>>  > Object>>>  > Capabilities makes more sense when you're talking
>> about
>> >>>>>  > programming>>>  > languages, but we don't really use it in that
>> sense in this
>> >>>>>  > community.>>>  >
>> >>>>>  > I propose we name the specification more appropriately in the
>> >>>>>  > hope that>>>  > the name evokes what we're actually doing with
>> the specification.
>> >>>>>  > The>>>  > technology we're developing in this community
>> specifically has
>> >>>>>  > to do>>>  > with Authorization... capability-based
>> authorization. Thus, I'm
>> >>>>>  > suggesting the spec is renamed to "Authorization
>> Capabilities"...>>>  > shortened to "zCaps" for the cool kids in the
>> community.
>> >>>>>  >
>> >>>>>  > Also, this is a bike shed discussion, so I fully expect it to get
>> >>>>>  > out of>>>  > hand and for us to have to do a poll like we did
>> for the
>> >>>>>  > Verifiable>>>  > Credentials terminology. Please only suggest
>> names that you're
>> >>>>>  > committed>>>  > to using with your customers (or that you would
>> use with non-
>> >>>>>  > technical>>>  > folks). If we get a bunch of +1s with no strong
>> objections, we're>>>  > done... and yes, I know that's wishful thinking. :)
>> >>>>>  >
>> >>>>>  > -- 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
>