Re: [GNAP] DID as sub_id or assertion?

[Adrian Gropper <[e-mail]>]

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