Re: VCs - zCaps / OCap a Discussion

While that specific use case might be a bit of an edge case, the common use
cases we expect to see brings me to the argument as to why a VC-based
specification of OCAPs (VC-CAPs??) would be extremely valuable:

- the underlying flow (issuer-holder-verifier) is essentially the same for
both.
- the need for cryptographic trust in both cases are the same (in the OCAP
case, the need for the holder to prove a binding to the initial holder --
as the same entity or a delegate)
   - in saying that, I don't mean "gov't id" type identity but rather I'm
in control of the holder's (or the holder's delegate's) private
key/cryptographic binding material
- the storage for the two is going to be the same -- some sort of wallet
that the holder can use to receive, hold/protect and present
- the protocols necessary to issue and present are if not identical,
extremely close -- and can ideally be merged (see the next point)
- the places where the two are used are often going to be the same, often
within the same flow. For example, at a hospital, I have a (perhaps
delegated) capability to do something AND I have a VC that shows I'm a
licensed medical doctor in good standing.

On that last item, I'm really not going to be happy if I have to use two
apps/devices to go through two separate flows to show I'm allowed to do
something.

I agree that a VC-CAP would need a full definition and would only be using
the VC as a transport for the capability. But the ability to combine all of
the elements of the user experience (wallets, storage, protocols, usage)
seems to me to be pretty important.

On Tue, Dec 8, 2020 at 2:42 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Trustee, Vice Chair - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*