Re: [GNAP] DID as sub_id or assertion?

[Fabien Imbault <[e-mail]>]

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