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 08:36:16 -0700
Message-ID: <CANpA1Z2swY8dKSTPTqV9e+Rfw_W0yMUeLD_6ViEfB41+nWLYMw@mail.gmail.com>
To: David Chadwick <d.w.chadwick@verifiablecredentials.info>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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 Tuesday, 22 June 2021 15:38:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 22 June 2021 15:38:35 UTC