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

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

From: Christopher Lemmer Webber <cwebber@dustycloud.org>
Date: Thu, 08 Nov 2018 09:44:06 -0500
To: Joe Andrieu <joe@legreq.com>
Cc: public-credentials@w3.org
Message-ID: <87d0rffx3d.fsf@dustycloud.org>
Naming is the ultimate bikeshed (https://shed.bike/), but I have serious
opinions about some of the paint colors being proposed.  Two separate

==== 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

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
>>>>>  >
Received on Thursday, 8 November 2018 14:44:30 UTC

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