Re: [GNAP] DID as sub_id or assertion?

[Fabien Imbault <[e-mail]>]

Yes, the AS is the policy manager and the token issuer for that delegation,
based on the knowledge it has of the RO.
We don't assume much on the lifecycle of the protected resource, except
that they expect a valid access token issued by the AS to provide access.

We defined client instances related to one client software. The client does
matter, we could even define its class or posture, but it's possible to
make a request to the AS even if you're not pre registered.

Fabien

Le jeu. 18 mars 2021 à 04:54, Adrian Gropper <[e-mail]> a
écrit :

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