Re: [GNAP] DID as sub_id or assertion?

[Justin Richer <[e-mail]>]

> On Mar 18, 2021, at 12:03 AM, Alan Karp <[e-mail]> wrote:
> 
> 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. 
> 
> How would you know if the client using the token is not the client it was given to if the two clients are in cahoots?  Sharing tokens is actually a useful pattern.  Client A running on your behalf could delegate to Client B also running on your behalf, but it's sometimes easier to share the credential.  For example, you might not mind if the client you use to retrieve the prices of stocks in your portfolio shares permission to know what stocks you own with the client you use to plot that data.  You would only need to delegate if you wanted to sub-scope, separately revoke, or have an audit trail. 

From the protocol's perspective, these are functionally the same client. Remember, “client instance” is a role in the system and it could be made up of many pieces of software deployed with their own internal sharing system. If two pieces of software have the same key material and token material, then they are, as far as GNAP is concerned, the same client instance. It’s important not to confuse the deployment pattern with the protocol roles.

GNAP has mechanisms to enable the kind of explicitly derived delegation that you’re describing here by allowing a client instance to ask for a new token in the context of an existing grant request or an existing access token. Those mechanisms have not been fully explored by the WG yet but they are based on the OAuth 2 token exchange concept.

 — Justin

> 
> --------------
> Alan Karp
> 
> 
> On Wed, Mar 17, 2021 at 4:18 PM Adrian Gropper <[e-mail] <mailto:[e-mail]>> wrote:
> 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] <mailto:[e-mail]>> wrote:
> On Mar 17, 2021, at 4:55 PM, Adrian Gropper <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <[e-mail] <mailto:[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
>