W3C home > Mailing lists > Public > public-credentials@w3.org > December 2020

Re: VCs - zCaps / OCap a Discussion

From: Adrian Gropper <agropper@healthurl.com>
Date: Tue, 8 Dec 2020 17:39:48 -0500
Message-ID: <CANYRo8j9xvvxVHL8i0Kcg65ZhvuMxLP5bFF_1L_jEwwx7pw7yw@mail.gmail.com>
To: Alan Karp <alanhkarp@gmail.com>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
A request for an authorization token could be encoded as a VC presented to
a controller service endpoint but I'm not sure that makes sense. The
Subject of the request is the requesting party but they are acting on
behalf of some employer. Alan makes this distinction quite clear as we
discuss revocation of Bob's capabilities.

As for the Subject of the authorization token issued by the controller
service, it sounds like we want that Subject to be Bob's employer rather
than Bob himself. The authorization token is presented to a policy
enforcement point that may choose to 'introspect' the token or not. This
has a direct impact on both revocation and audit. In a Zero Trust
Architecture, it is desirable to provide a confidential audit capability
for activity at the policy enforcement point that is separate from the
audit capability at the policy decision point. How do we do that while
keeping the policy enforcement point blind to the requesting party and
purpose components of the initial request?

I've added a related comment to the Confidential Storage issues.
https://github.com/decentralized-identity/confidential-storage/issues/128#issuecomment-741131968

Adrian

On Mon, Dec 7, 2020 at 6:16 PM Alan Karp <alanhkarp@gmail.com> wrote:

> Forgot to Reply All.
>
> --------------
> Alan Karp
>
>
> ---------- Forwarded message ---------
> From: Alan Karp <alanhkarp@gmail.com>
> Date: Mon, Dec 7, 2020 at 2:59 PM
> Subject: Re: VCs - zCaps / OCap a Discussion
> To: David Chadwick <D.W.Chadwick@kent.ac.uk>
>
>
> David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
>
>>
>> On 07/12/2020 22:22, Alan Karp wrote:
>> >
>> >     As a boss, if I revoked an employee's permission I would want all
>> >     instances of this to be revoked.
>> >
>> >
>> > You need a different mechanism for that.  The solution is to give Bob
>> > an ocap to use a Bob-agent, which holds all the ocaps that have been
>> > delegated to Bob.  When Bob gets fired you revoke his Bob-agent ocap.
>> > This solution also works in the case in which the boss gets fired.  If
>> > you didn't do something like this, every delegation the boss made
>> > would be revoked, and nobody would be able to get any work done.
>> >
>> We seem to be getting rather complex here. Does this mean that every
>> user has two "selfs". His real self that is directly given ocaps, and an
>> agent-self that is only given delegated ocaps?
>
>
> This example shows that the answer depends on who is in charge.  In the
> enterprise case, Bob, the person, doesn't have permissions to company
> resources; only Bob, the employee, has those permissions.  The Bob-agent,
> access to which is controlled by the company, is the way you represent that
> fact.  In the personal space, Bob has permissions to his house, car, bank
> account, etc., some of which were delegated to him personally.
>
> --------------
> Alan Karp
>
Received on Tuesday, 8 December 2020 22:40:13 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 8 December 2020 22:40:14 UTC