Re: VCs - zCaps / OCap a Discussion

Adrian Gropper <agropper@healthurl.com> wrote:

> I would ask Justin (cc'd) abot the right way to implement sub-scope
> delegation with GNAP terminology.
>

As I recall, oauth.xyz implemented it, so I expect GNAP does, too.

>
> My guess is that this is no problem. The scope issued to the RQ via the
> authorization token is signed but not encrypted. If the RQ wants to
> delegate it after a restriction, the signature of the AS would become
> invalid and it would be replaced by the signature of AS-2. AS-2 is not
> registered with or known to the RS.
>

One nice thing about using certificates for ocaps is that the AS does not
need to be involved in delegation.  The delegator locally creates a new
certificate specifying the desired scope and includes its own certificate
as evidence that the delegation is legitimate.

>
> The sub-scope would be presented by an RC, maybe the same RC that would
> have been used by the RQ or maybe a different RC used by RQ-2. It would be
> up to the RS to decide, as it always is, whether to trust the RC or not. If
> the RS does not trust the RC because it is presenting a scope signed by an
> unknown AS, then the RS should notify the AS associated with the resource
> as part of the token introspection process. (The RC should notify the AS
> about any exception unless it is prohibited from doing so by some law such
> as a national security gag order.) The RC-AS token introspection process
> should include whatever software statement or other claims are being
> presented by the RC.
>

Any attempt to refuse a legitimate delegation results in worse security.
The RQ wishing to delegate a specific zcap to an RC can share the
corresponding private key if the RS doesn't trust that RC.  (Note that this
private key should be a one-off key created just for this zcap.)  Now
you've lost responsibility tracking since you have two parties holding the
same private key.

>
> The AS could decide to accept the sub-scoped authorization based on the RC
> claims or other knowledge it collected incidental to the RQ request. Or,
> the AS could not accept and the sub-scoped delegation would fail. In this
> way, my hope is that either way, the AS 'learns' as much as possible and
> the RS 'learns' as little as possible from each transaction.
>

The AS must only reject a request if it is not authorized by the zcap or
there's an improper delegation.  Any criterion tied to the requester will
result in sharing of private keys.

>
> This use-case is almost the norm in healthcare (the RQ delegates to staff
> assistants using the same Electronic Health Record as AS-2 and RC) and will
> probably be key to zero-trust architectures that want to keep the RQ and
> the RC both separately accountable. The RS is free to scrutinize every
> transaction and to share RC claims as well as the scopes with any auditor.
>

Making delegation easy leads to the behavior you want.

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

>