- From: Alan Karp <alanhkarp@gmail.com>
- Date: Tue, 22 Jun 2021 22:15:36 -0700
- To: Adrian Gropper <agropper@healthurl.com>
- Cc: David Chadwick <d.w.chadwick@verifiablecredentials.info>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CANpA1Z2RNM8Bbg_Qt6EtMKppUuBuUCf+tY4T6eG_K04atdNzCA@mail.gmail.com>
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 05:16:09 UTC