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

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/
>>>
>>>
>>>
>>>