Re: VCs - zCaps / OCap a Discussion

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

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.

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.

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.

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.

Adrian

On Sat, Dec 19, 2020 at 3:21 PM Alan Karp <alanhkarp@gmail.com> wrote:

> Adrian Gropper <agropper@healthurl.com> wrote:
>
>> OK - then can I ask you a favor, Alan...
>>
>> Please look at section 1.4 of
>> https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/?include_text=1
>> and tell us if we could use the RO, RQ, RC, AS, RS terminology to continue
>> this discussion about the relationship between capabilities, VCs,
>> authorization, and Confidential Storage without losing any generality?
>>
>
> How cruel!  Asking an old man to learn a new language.
>
> Yes, we should stick to that terminology, but I'll probably speak with a
> heavy accent.
>
> One thing I didn't see is terminology for delegation.  What if the RQ
> wants to do a sub-scope delegation?  What do we call the delegatee?  Should
> we use a different term than RQ for the delegator?  What do we call the
> delegatee when it makes a request?
>
> --------------
> Alan Karp
>
>>