Re: [GNAP] DID as sub_id or assertion?

[Alan Karp <[e-mail]>]

Justin Richer <[e-mail]> wrote:

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

That's exactly the right perspective.  I've been surprised by how many
people don't see it that way.

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

You don't need token exchange if your tokens are certificates.

--------------
Alan Karp


On Thu, Mar 18, 2021 at 4:53 AM Justin Richer <[e-mail]> wrote:

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