W3C home > Mailing lists > Public > public-credentials@w3.org > June 2021

Re: PROPOSALs for VC HTTP API call on 2021-06-22

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

This archive was generated by hypermail 2.4.0 : Wednesday, 23 June 2021 05:16:13 UTC