- From: Adrian Gropper <agropper@healthurl.com>
- Date: Wed, 23 Jun 2021 07:47:43 -0400
- To: David Chadwick <d.w.chadwick@verifiablecredentials.info>
- Cc: public-credentials@w3.org
- Message-ID: <CANYRo8jVLFos9QcgYuo11LkyZbsk+GhcnOVjHAMBH199Ecz5bg@mail.gmail.com>
That’s progress! - Adrian On Wed, Jun 23, 2021 at 4:38 AM David Chadwick < d.w.chadwick@verifiablecredentials.info> wrote: > I can agree with SHOULD rather than MAY. But not MUST for reasons already > explained. > > Kind regards > > David > On 23/06/2021 06:15, Alan Karp wrote: > > I think Adrian and I agree. My position is that if you implement a system > with authorization tokens that system must support attenuated delegation of > them. The SHOULD means that you don't have to implement such a system. Of > course, I'm strongly in favor of it. > > -------------- > Alan Karp > > > On Tue, Jun 22, 2021 at 9:54 PM Adrian Gropper <agropper@healthurl.com> > wrote: > >> +1 to Alan’s security point around “confused deputy”. We should try to >> avoid authentication based access control whenever possible. >> >> I disagree with David’s MUST conclusion: >> >> “Thus it seems to me that delegation and attenuation must be optional >> features of both the issuer and verifier APIs, and be determined by the >> issuer and the RP respectively.” >> >> OAuth experience has shown that if we make delegation optional, issuers >> will gravitate to that which is easiest and least risky for them. The >> result is Sign-in with Google or Facebook and the death of Sign-in with >> OpenID Connect as well as hardly any dynamic client registration in the >> wild. >> >> The alternative definition of “optional” is the make delegation a SHOULD. >> That forces issuers to explain why they do not support delegation in any >> particular context. >> >> - Adrian >> >> On Tue, Jun 22, 2021 at 11:06 PM Alan Karp <alanhkarp@gmail.com> wrote: >> >>> Attribute-Based Access Control falls into the family of >>> autheNtication-Based Access Control (NBAC) schemes discussed in our "From >>> ABAC to ZBAC" paper, >>> https://www.hpl.hp.com/techreports/2009/HPL-2009-30.html. (It was >>> published in the Journal of Information Warfare, but that link is dead.) >>> It, like Identity- and Role-Based Access Control suffers from the problem >>> of ambient permission that leads to confused deputy vulnerabilities. The >>> problem arises when authentication (of identity, role, or attributes) is >>> used when a request is received to look up whether the requester has the >>> needed permissions. Capability systems do not separate designation of the >>> resource from the permission to use it, so they do not suffer from the >>> confused deputy problem. >>> >>> -------------- >>> Alan Karp >>> >>> >>> On Tue, Jun 22, 2021 at 1:43 PM David Chadwick < >>> d.w.chadwick@verifiablecredentials.info> wrote: >>> >>>> Hi Alan >>>> >>>> sorry that we are submerged in a sea of acronyms. It does make >>>> conversations difficult especially for people who are new to an area. By >>>> ABAC I meant attribute based access control e.g. as standardised in XACML >>>> (by OASIS). We have had a discussion about this years ago, only then it was >>>> with reference to X.509 ACs. But as I have indicated previously, VCs are >>>> simply a new incarnation of X.509 ACs, with many improvements of course. >>>> Whether a VC is a capability and contains the actual operation (e.g. >>>> validate VP) or is an indirection to it by containing an attribute (e.g. >>>> Trusted RP, which maps into validate VP by the verifier) depends upon the >>>> requirements of the verifier. Both mechanisms have their advantages. Both >>>> are feasible. And both can support attenuated delegation. In the ABAC/RBAC >>>> case the attribute could be part of a role hierarchy and the superior role >>>> holder could delegate a subordinate role to a delegate. Alternatively the >>>> VC could contain a set of attributes and a subset could be delegated. In >>>> the capability case, one would have to define what an attenuation of the >>>> authz command is e.g. what could you delegate from validate VP? >>>> >>>> Kind regards >>>> >>>> David >>>> On 22/06/2021 16:36, Alan Karp wrote: >>>> >>>> On Tue, Jun 22, 2021 at 4:09 AM David Chadwick < >>>> d.w.chadwick@verifiablecredentials.info> wrote: >>>> >>>>> Hi Alan >>>>> >>>>> You are completely ignoring the ABAC model for authorisation in your >>>>> statements below. If ABAC is used for authz then a VC is perfectly >>>>> acceptable on its own as an authz token for gaining access to a resource >>>>> >>>> >>>> By ABAC do you mean Authorization-Based Access Control? That acronym >>>> is commonly used for Attribute-Based Access Control, which is why I >>>> introduced the term ZBAC. >>>> >>>> I believe that a VC is a perfectly acceptable authz token only if the >>>> spec includes attenuated delegation. If it does not, I would prefer that >>>> people who want ZBAC use a different token spec that does support >>>> delegation, even if they are using VCs for non-authorization claims. >>>> >>>> -------------- >>>> Alan Karp >>>> >>>> >>>> On Tue, Jun 22, 2021 at 4:09 AM David Chadwick < >>>> d.w.chadwick@verifiablecredentials.info> wrote: >>>> >>>>> Hi Alan >>>>> >>>>> You are completely ignoring the ABAC model for authorisation in your >>>>> statements below. If ABAC is used for authz then a VC is perfectly >>>>> acceptable on its own as an authz token for gaining access to a resource >>>>> >>>>> Kind regards >>>>> >>>>> David >>>>> >>>>> >>>>> On 21/06/2021 21:47, Alan Karp wrote: >>>>> >>>>> >>>>> I asked a number of people expert in capability systems if delegation >>>>> is necessary to have a viable system. They concluded it was unless every >>>>> holder of an authorization token proxies every request in lieu of >>>>> delegating. I don't know how viable proxying is in the VC use cases. >>>>> >>>>> Given that information, I would like to see an option specifying that >>>>> verified credentials MUST NOT be used as authorizations unless they support >>>>> attenuated delegation (I believe the OAuth term is sub-scope >>>>> re-delegation.) and that any such system SHOULD support revocation. >>>>> >>>>> If you don't support delegation, people will be forced to share access >>>>> tokens. The result will be loss of an audit trail and the likelihood that >>>>> they will share more permissions than necessary. The result is a less >>>>> secure system that is harder to use. >>>>> >>>>> -------------- >>>>> Alan Karp >>>>> >>>>> >>>>> On Mon, Jun 21, 2021 at 12:52 PM Manu Sporny < >>>>> msporny@digitalbazaar.com> wrote: >>>>> >>>>>> Hi all, Here are some of the proposals that we didn't get to on the >>>>>> call last >>>>>> week. We'll be processing them this week (these are all proposals >>>>>> that have >>>>>> been circulated on the mailing list, I'm just summarizing them here): >>>>>> >>>>>> PROPOSAL: Implementations SHOULD support authorization delegation by >>>>>> using >>>>>> technologies such as GNAP and Authorization Capabilities. >>>>>> >>>>>> PROPOSAL: Implementations MUST support authorization delegation by >>>>>> using >>>>>> technologies such as GNAP and Authorization Capabilities. >>>>>> >>>>>> PROPOSAL: Implementations are informally urged to support >>>>>> authorization >>>>>> delegation. Implementations MAY support other authorization >>>>>> mechanisms, >>>>>> especially ones that support authorization delegation. >>>>>> >>>>>> PROPOSAL: Implementations MUST support OAuth2 for the >>>>>> /credentials/verify >>>>>> endpoint. Implementations MAY support other authorization mechanisms >>>>>> for the >>>>>> /credentials/verify endpoint. >>>>>> >>>>>> We will be running these proposals tomorrow to come to some decisions >>>>>> wrt. the >>>>>> direction of the authorization aspect of the work... after we process >>>>>> a few >>>>>> PRs and issues. >>>>>> >>>>>> -- manu >>>>>> >>>>>> -- >>>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/ >>>>>> Founder/CEO - Digital Bazaar, Inc. >>>>>> News: Digital Bazaar Announces New Case Studies (2021) >>>>>> https://www.digitalbazaar.com/ >>>>>> >>>>>> >>>>>> >>>>>>
Received on Wednesday, 23 June 2021 11:48:17 UTC