- From: Adrian Gropper <agropper@healthurl.com>
- Date: Wed, 23 Jun 2021 00:53:49 -0400
- To: Alan Karp <alanhkarp@gmail.com>
- Cc: David Chadwick <d.w.chadwick@verifiablecredentials.info>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CANYRo8jTeg=8pjue9sZERHCrDhtT0MzMM-fUqBEjCSe5RzgqaQ@mail.gmail.com>
+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 04:54:25 UTC