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

Re: Renaming Object Capabilities to Authorization Capabilities?

From: =Drummond Reed <drummond.reed@evernym.com>
Date: Thu, 8 Nov 2018 10:21:56 -0700
Message-ID: <CAAjunnamSSBpsWpq+a52aijHjY7k6dkZNumkm1aVgb=xnS5OOg@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: Brent Zundel <brent.zundel@evernym.com>, Joe Andrieu <joe@legreq.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
+1.

On Thu, Nov 8, 2018 at 9:37 AM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 11/06/2018 12:49 AM, =Drummond Reed wrote:
>
>> 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.
>>
>
> Another option for renaming Object Capabilities is Decentralized
> Capabilities. Decentralized Capabilities enable an authorization
> framework where delegation can happen in a decentralized way, where a
> single centralized namespace for resources is not required, and where
> centralized ACL management is not required. This would get us to a
> "dcaps" short-form as well.
>
>
>> On Mon, Nov 5, 2018 at 12:24 PM, Dave Longley <dlongley@digitalbazaar.com
>> <mailto: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> <mailto: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
>>         <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>
>>                          <mailto: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>
>>                     <mailto: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>
>>                     <mailto: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
>>                     <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/
>>                     <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
>>                     <https://tinyurl.com/veres-one-launches>
>>                                  >
>>
>>
>>                      --
>>                      Joe Andrieu, PMP joe@legreq.com
>>                 <mailto:joe@legreq.com> <mailto:joe@legreq.com
>>                 <mailto:joe@legreq.com>>
>>                      LEGENDARY REQUIREMENTS
>>           +1(805)705-8651
>>                      Do what matters. http://legreq.com
>>                      <http://www.legendaryrequirements.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>
>>         <mailto:joe@legreq.com <mailto:joe@legreq.com>>
>>              LEGENDARY REQUIREMENTS
>>                               +1(805)705-8651
>>              Do what matters. http://legreq.com
>>              <http://www.legendaryrequirements.com
>>         <http://www.legendaryrequirements.com>>
>>
>>
>>
>>
>>     --     Dave Longley
>>     CTO
>>     Digital Bazaar, Inc.
>>     http://digitalbazaar.com
>>
>>
>>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>
Received on Thursday, 8 November 2018 17:22:22 UTC

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