Re: Renaming Object Capabilities to Authorization Capabilities?

First, I want to say this message from Dave is exceptionally articulate
about the relationship of Verifiable Credentials (which 90% of the time I
end out just shortening, in context, to "credentials") and "Authorized
Capabilities".

However to agree with Daniel, just as I find that most of the time I can
leave out "verifiable" because it "comes with the territory" of digital
credentials, I think most of the time we'll be able to leave out
"authorized" because it "comes with the territory" of capabilities.

Ironically the short-form pairing I like perhaps even more than
"credentials" and "capabilities" is "dcreds" and "dcaps". And that
certainly reinforces the decentralized aspects of both.

On Mon, Nov 5, 2018 at 12:24 PM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> 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-f
>> ormation-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 Tuesday, 6 November 2018 05:50:22 UTC