Re: [GNAP] DID as sub_id or assertion?

[Adrian Gropper <[e-mail]>]

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