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

Re: Renaming Object Capabilities to Authorization Capabilities?

From: Daniel Hardman <daniel.hardman@evernym.com>
Date: Mon, 5 Nov 2018 10:57:14 -0700
Message-ID: <CAFBYrUr2-5NgQ=7a2h4Ub=kpFh5go8=L-Pi-NG4TcpETWzWtgg@mail.gmail.com>
To: alake@digitalbazaar.com
Cc: Credentials Community Group <public-credentials@w3.org>
The security model known as "Capabilities" already implies authorization.
So could we consider just the one word, with no redundant adjective?

On Mon, Nov 5, 2018 at 10:49 AM Adam Lake <alake@digitalbazaar.com> 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
> <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
> 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
>
>
Received on Monday, 5 November 2018 17:57:49 UTC

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