Re: [GNAP] DID as sub_id or assertion?

[Fabien Imbault <[e-mail]>]

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