Re: [GNAP] DID as sub_id or assertion?

[Adrian Gropper <[e-mail]>]

Yes, I think we can close the current thread. Justin's explanation above of
how we're using client is clear to me.

Adrian

On Thu, Mar 18, 2021 at 9:42 AM Fabien Imbault <[e-mail]>
wrote:

> Yes I think we can close the current thread.
> Compared to the original objective of the thread, I just want to summarize
> what I understood as a rough consensus for the WG : go along with sub_ids,
> and consider DIDs as identifiers (knowing that the demand has been pushed
> to the related WG).
>
> Best
> Fabien
>
> On Thu, Mar 18, 2021 at 2:39 PM Denis <[e-mail]> wrote:
>
>> Hi Justin,
>>
>> You wrote:
>>
>> Tokens are opaque to the client instance.
>>
>> This is certainly your point of view, but not mine. This topic is still
>> under discussion under the issue #145 (Opaque / Non opaque access token)
>> that you would like to close next week. But it closely relates to the
>> issue #214 (Trust relationships) to which you have not yet participated.
>>
>> I took a look at the subject of this thread which is [GNAP] DID as sub_id
>> or assertion?  We are far beyond the original topic of this thread.
>>
>> Denis
>>
>> On Mar 18, 2021, at 12:08 AM, Alan Karp <[e-mail]> wrote:
>>
>>
>> Adrian Gropper <[e-mail]> wrote:
>>
>>>
>>> Is there an AS involved in the delegation? How and where in the
>>> lifecycle of the protected resource?
>>>
>>
>> If tokens are certificates, the AS need not be involved in subsequent
>> delegations.  The AS must be involved if the tokens are opaque.
>>
>>
>> Tokens are opaque to the client instance. They are not opaque to the AS.
>> They might be opaque to the RS, but that depends on the kind of
>> relationship the RS and AS have. GNAP should allow different options here
>> as there are different use cases for that.
>>
>> It would probably be worthwhile to separate the portions of the spec that
>> talk about the RS-AS relationship into its own standalone document. A
>> similar approach was taken in UMA2 and it was helpful. (Though admittedly,
>> as with anything, there are missteps there that we can hopefully learn
>> from.)
>>
>>  — Justin
>>
>>
>> --------------
>> Alan Karp
>>
>>
>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <[e-mail]>
>> wrote:
>>
>>> Sure!
>>>
>>> Is there an AS involved in the delegation? How and where in the
>>> lifecycle of the protected resource?
>>>
>>> Also your use of "the client" seems to imply that either there is only
>>> one client or the client doesn't matter. Which is it?
>>>
>>> Adrian
>>>
>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <
>>> [e-mail]> wrote:
>>>
>>>> Thanks for that.
>>>>
>>>> Trying to reframe it:
>>>> GNAP is defined as a delegation protocol so the main intent is related
>>>> to a delegate of the RO (i.e. the end user) that wishes to access the RO's
>>>> protected resources, through the client.
>>>>
>>>> Fabien
>>>>
>>>> Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <[e-mail]>
>>>> a écrit :
>>>>
>>>>> 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
>>>>>>>>
>>>>>>>>
>>
>>
>>