- From: Adrian Gropper <agropper@healthurl.com>
- Date: Tue, 8 Dec 2020 17:39:48 -0500
- To: Alan Karp <alanhkarp@gmail.com>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CANYRo8j9xvvxVHL8i0Kcg65ZhvuMxLP5bFF_1L_jEwwx7pw7yw@mail.gmail.com>
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