- From: Moses Ma <moses.ma@futurelabconsulting.com>
- Date: Mon, 5 Nov 2018 10:19:23 -0800
- To: Public-Credentials <public-credentials@w3.org>
- Message-ID: <02cdf741-9e6c-47f7-a364-a4f96ed32247@Moses-iPad-Pro-105>
I have a question... since most of the time the user is delegating a capability authorized by some other entity, wouldn’t a better term be delegated capability?
For example, the capability to pick up a prescription is not really “authorized” by the user, the root authorization is from the doctor, which is sourced by regulatory compliance agencies managing prescription drugs. Or in the smart key/car example, the user is delegating the capability to operate the vehicle to a roommate provided by the manufacturer... but that roommate also needs an authorization from the eDMV, in the form of a verified electronic drivers license. Without both, the roommate would not be able to operate the vehicle. In other words, rights and authorizations should not be conflated. This would align with Daniel Hartman’s recommendation to avoid the use of a redundant adjective.
In my favorite example, empowering security tokens, an issuer of a token could provide a VC to an investor, enabling them to receive better information or services from a third party. That investor may wish to delegate that capability to receive better data to his or her broker or family office, but is not providing the “core authorization” or market data permissioning. (BTW, I’m writing a paper about the use of DIDs in security tokens, which I’m calling the Security Token Protocol, and I’d love to get some feedback if any of you are interested. Just send me a private email and I’ll send you a rough draft, as it’s not suitable for an open mailing list yet.)
Anyway, my 2 cents in this relaxing diversion into bikeshedding.
Moses
-
Moses Ma | FutureLab Consulting Inc
moses.ma@futurelabconsulting.com | moses@ngenven.com
v +1.415.952.7888 (tel:+1.415.952.7888) | m +1.415.568.1068 (tel:+1.415.568.1068) | skype mosesma
>
> On Nov 5, 2018 at 9:47 AM, <Adam Lake (mailto: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 (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
>
>
Received on Monday, 5 November 2018 18:19:53 UTC