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

Re: Renaming Object Capabilities to Authorization Capabilities?

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Mon, 5 Nov 2018 15:24:23 -0500
To: Brent Zundel <brent.zundel@evernym.com>, Joe Andrieu <joe@legreq.com>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Message-ID: <ff498bfa-23c9-66b6-baa3-d7c9c8b0d8b8@digitalbazaar.com>
On 11/05/2018 02:54 PM, Brent Zundel wrote:
> 
> 
> On Mon, Nov 5, 2018, 11:40 Joe Andrieu <joe@legreq.com 
> <mailto:joe@legreq.com> wrote:
> 
>     __
>     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.
> 
> 
> This does not fit with my understanding of how the ecosystem could work. 
> I might receive a credential from an issuer, but authorization couldn't 
> happen until the presentation of that credential is verified.
> So authorization happens at verification.

This discussion is about capabilities, not credentials. I think it's
important that we don't mix the two (some others disagree).

Verifiable Credentials are about describing things. Verifiable
Credentials allow you to say things about others in a way they can
independently share whilst preserving the trust that you said it. This
tech can be used as part of an authorization framework, but it does not
constitute one on its own.

Authorized Capabilities are directly about authorization. They allow you
to delegate authorization to take some action with some resource to
others such that they can also independently delegate it (with
restrictions). An Authorized Capability must be cryptographically
invoked (and/or delegated). Invocation may require some additional
caveats, such as the possession of certain attributes by the invoker.

This is one way that the two technologies can be used together: a
Verifiable Credential can provide a trusted claim that an entity
possesses the required attributes to invoke an Authorized Capability.


> 
> 
>     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
>>>>     <mailto:darrell.odonnell@continuumloop.com>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     On Sat, Nov 3, 2018 at 12:24 PM Brent Zundel
>>>>     <brent.zundel@evernym.com <mailto:brent.zundel@evernym.com>> wrote:
>>>>
>>>>         +1
>>>>
>>>>         On Sat, Nov 3, 2018, 10:14 Jordan, John CITZ:EX
>>>>         <John.Jordan@gov.bc.ca <mailto:John.Jordan@gov.bc.ca> wrote:
>>>>
>>>>             +1
>>>>
>>>>             > On Nov 3, 2018, at 08:27, Manu Sporny
>>>>             <msporny@digitalbazaar..com
>>>>             <mailto:msporny@digitalbazaar.com>> 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 <mailto:joe@legreq.com>
>>>     LEGENDARY REQUIREMENTS                        +1(805)705-8651
>>>     Do what matters. http://legreq.com
>>>     <http://www.legendaryrequirements.com>
>>>
>>>
>>
>>     -- 
>>     Adam Lake
>>     Director, Business Development
>>     Digital Bazaar
>>     Veres.io
>>     540-285-0083
> 
>     --
>     Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com>
>     LEGENDARY REQUIREMENTS                                              
>               +1(805)705-8651
>     Do what matters. http://legreq.com
>     <http://www.legendaryrequirements.com>
> 
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com
Received on Monday, 5 November 2018 20:24:50 UTC

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