Re: [GNAP] DID as sub_id or assertion?

[Alan Karp <[e-mail]>]

Justin Richer <[e-mail]> wrote:

> On Mar 18, 2021, at 12:08 AM, Alan Karp <[e-mail]> wrote:
>
>
> Adrian Gropper <[e-mail]> wrote:
>
>>
>> Is there an AS involved in the delegation? How and where in the
>> lifecycle of the protected resource?
>>
>
> If tokens are certificates, the AS need not be involved in subsequent
> delegations.  The AS must be involved if the tokens are opaque.
>
>
> Tokens are opaque to the client instance. They are not opaque to the AS.
> They might be opaque to the RS, but that depends on the kind of
> relationship the RS and AS have. GNAP should allow different options here
> as there are different use cases for that.
>

Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation
with VCs, or our Zebra Copy work.  Why must they be in GNAP?

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


On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <[e-mail]> wrote:

> On Mar 18, 2021, at 12:08 AM, Alan Karp <[e-mail]> wrote:
>
>
> Adrian Gropper <[e-mail]> wrote:
>
>>
>> Is there an AS involved in the delegation? How and where in the
>> lifecycle of the protected resource?
>>
>
> If tokens are certificates, the AS need not be involved in subsequent
> delegations.  The AS must be involved if the tokens are opaque.
>
>
> Tokens are opaque to the client instance. They are not opaque to the AS.
> They might be opaque to the RS, but that depends on the kind of
> relationship the RS and AS have. GNAP should allow different options here
> as there are different use cases for that.
>
> It would probably be worthwhile to separate the portions of the spec that
> talk about the RS-AS relationship into its own standalone document. A
> similar approach was taken in UMA2 and it was helpful. (Though admittedly,
> as with anything, there are missteps there that we can hopefully learn
> from.)
>
>  — Justin
>
>
> --------------
> Alan Karp
>
>
> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <[e-mail]>
> wrote:
>
>> Sure!
>>
>> Is there an AS involved in the delegation? How and where in the
>> lifecycle of the protected resource?
>>
>> Also your use of "the client" seems to imply that either there is only
>> one client or the client doesn't matter. Which is it?
>>
>> Adrian
>>
>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <[e-mail]>
>> wrote:
>>
>>> Thanks for that.
>>>
>>> Trying to reframe it:
>>> GNAP is defined as a delegation protocol so the main intent is related
>>> to a delegate of the RO (i.e. the end user) that wishes to access the RO's
>>> protected resources, through the client.
>>>
>>> Fabien
>>>
>>> Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <[e-mail]> a
>>> écrit :
>>>
>>>> At various points in the lifecycle of the protected resource the client
>>>> at the resource server (RS) might be:
>>>>
>>>>    - The RO (subject) user agent trading payment for a service promise
>>>>    - The RO user agent using the promise to access the protected
>>>>    resource
>>>>    - A delegate of the RO user agent using a different client
>>>>
>>>> What's vague is where the GNAP AS enters the picture as described
>>>> above. How would you describe it?
>>>>
>>>> Adrian
>>>>
>>>>
>>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <
>>>> [e-mail]> wrote:
>>>>
>>>>> Hi Adrian
>>>>>
>>>>> I'm still confused why you're saying the terminology is vague.
>>>>> I get the "power" neutrality is not to your liking, but RQ / user
>>>>> agent is no better in my view.
>>>>>
>>>>> Can you elaborate?
>>>>>
>>>>> Fabien
>>>>>
>>>>> Le jeu. 18 mars 2021 à 00:18, Adrian Gropper <[e-mail]>
>>>>> a écrit :
>>>>>
>>>>>> I'm sure you're right. Our vague terminology around
>>>>>> client and end-user leads to my confusion. If GNAP is primarily about
>>>>>> delegation then, of course, we should avoid any incentives to impersonate
>>>>>> or we're wasting our time. This is partly why I'm trying to study up on
>>>>>> capabilities and asking for expert advice from folks like Alan Karp and
>>>>>> Mark Miller (cc'd)
>>>>>>
>>>>>> As best I can understand it, the RS has only two choices, it can:
>>>>>>
>>>>>>    - store an attribute of the RO a [DID, email address, GNAP AS
>>>>>>    URL], or
>>>>>>    - hand the RO a capability as a sort-of promise and avoid making
>>>>>>    any entries in an ACL or equivalent.
>>>>>>
>>>>>> When a token comes back to the RS, it will either be:
>>>>>>
>>>>>>    - validated according to something associated with the stored RO
>>>>>>    attribute, or
>>>>>>    - signed by the RS itself.
>>>>>>
>>>>>> Either way, trust in the client seems moot.
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>> <snip>
>>>>>>>> > A client might not have a DID but it could have a VC as a
>>>>>>>> certificate of authenticity linked to some audit mechanism.
>>>>>>>>
>>>>>>>> To me a VC would come under the assertions umbrella (that is to say
>>>>>>>> a VC could be one type of valid assertion). The client may possess or been
>>>>>>>> presented with a VC that it could include in its request to the AS as a way
>>>>>>>> to identify the subject and perhaps prove authentication and authorization.
>>>>>>>>
>>>>>>>
>>>>>>> I do not assume that the client that interacts with the AS to make a
>>>>>>> request and receive a token is the same as the client that will present the
>>>>>>> token to the RS. In the US HIPAA use-case, for example, the root of trust
>>>>>>> is a contract between the patient-subject and the doctor-requesting party
>>>>>>> but the doctor workflow is expected to delegate the token to some other
>>>>>>> end-user that may be using a totally different client such as an EHR.
>>>>>>>
>>>>>>>
>>>>>>> If the client that gets the token is not same as the client that
>>>>>>> uses the token, that is a violation of core security principles as it
>>>>>>> allows for (and really designs for) impersonation by client software. I
>>>>>>> would have no reason to trust client software that would hand its
>>>>>>> credentials over to another piece of software, and in fact I shouldn’t
>>>>>>> trust it.
>>>>>>>
>>>>>>> I think you may be conflating several different kinds of parties
>>>>>>> under the “client” umbrella here, though. It’s entirely possible that one
>>>>>>> client might call an RS that in turn acts as a client for something else
>>>>>>> down stream. But each of those hops is different from the last.
>>>>>>>
>>>>>>>  — Justin
>>>>>>>
>>>>>>>
>