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