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

Re: VCs - zCaps / OCap a Discussion

From: Alan Karp <alanhkarp@gmail.com>
Date: Wed, 9 Dec 2020 14:08:06 -0800
Message-ID: <CANpA1Z2joJ71TZMK7VaGa5PtKnQDMGpVQSgSSr00SoyjLnA0gA@mail.gmail.com>
To: Adrian Gropper <agropper@healthurl.com>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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.
>

It's easier to understand by starting at the beginning.  Company A creates
a service.  It delegates a subset of the methods of the service to company
B.  Company B delegates a subset of those permissions to Bob-as-employee.
(The delegation chain can be longer.)  Bob-as-employee then makes a request
of the service.  The policy decision point doesn't have to know anything
about Bob, as-employee or otherwise.  It just verifies that the request and
the delegations were signed by the correct private keys and that each
delegation is a (proper) subset of the delegator's permissions.

Our Zebra Copy <https://www.hpl.hp.com/techreports/2007/HPL-2007-105.html>
paper
has more detail.  (Don't be put off by the length.  The last 60 pages are a
walkthrough of the code.)


> The authorization token is presented to a policy enforcement point that
> may choose to 'introspect' the token or not.
>

My understanding is that the PEP never looks at the request.  It just
forwards the request to the PDP (policy decision point) and gets back an
Allow/Deny decision.


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

The delegation chain can provide blind enforcement.  When company A
delegates to company B, it includes in the certificate an opaque identifier
that only it knows refers to company B.  Company B does the same when
delegating to Bob-as-employee.  If someone on the delegation chain does
something bad, the direct delegator will be able to identify the culprit.

--------------
Alan Karp

>
Received on Wednesday, 9 December 2020 22:08:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 9 December 2020 22:08:32 UTC