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

Re: Renaming Object Capabilities to Authorization Capabilities?

From: Joe Andrieu <joe@legreq.com>
Date: Mon, 05 Nov 2018 10:38:59 -0800
Message-Id: <1541443139.2669900.1566401160.5FAA0269@webmail.messagingengine.com>
To: public-credentials@w3.org
Adam,

I agree. I think we're on the same page: the authorization happens at
the issuance of the capability (ignoring any separation of creation &
transmittal). Hence, my preference for the past participle "authorized".
The semantics are that if you have the auth* capability, you can
exercise the capability because the capability *has* been authorized.
Flip it around and it might be clearer. To my reading, an "unauthorized
capability" would be like stolen car keys. You have the capability, but
you aren't authorized. In contrast, an "unauthorization capability"
reads to me that you have the capability to remove authorization, to
unauthorize something.
The past participle, "authorized" reads as modifying capability, whereas
the little known FCE nounification [1] of "authorize" into
"authorization" reads as the capability to do the verb "authorize"
To add another coat of paint to the zCap thing. Since zkp seems to have
run away with the zzzzs, ACap might work well with either Auth*
Capability.
-j

[1] http://www.tinyteflteacher.co.uk/learning-english/FCE/word-formation-ion-nouns.html
    FWIW, I knew all about gerunds "-ing" noun forms. I didn't know
    about FCE until Google enlightened me.
On Mon, Nov 5, 2018, at 9:47 AM, Adam Lake wrote:
> Joe, 


> I think I get your point but don't the capabilities exist prior to be
> used? That is, they are Authorization Capabilities until they are used
> to delegate, or authorize, a capability?> I agree that Authorized Capabilities flows off the tongue a bit easier
> than Authorization Capabilities.> Adam 


> 
> On 11/3/2018 2:10 PM, Joe Andrieu wrote:
>> +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
>>>>> > 
>>>>> 
>> 
>> --
>> Joe Andrieu, PMP
>> joe@legreq.com>> LEGENDARY REQUIREMENTS
>> +1(805)705-8651>> Do what matters.
>> http://legreq.com[2]>> 
>> 
>
> -- Adam Lake Director, Business Development Digital Bazaar Veres.io
> 540-285-0083
--
Joe Andrieu, PMP
joe@legreq.comLEGENDARY REQUIREMENTS
+1(805)705-8651Do what matters.
http://legreq.com[3]


Links:

  1. mailto:msporny@digitalbazaar.com
  2. http://www.legendaryrequirements.com
  3. http://www.legendaryrequirements.com
Received on Monday, 5 November 2018 18:39:25 UTC

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