Re: [GNAP] DID as sub_id or assertion?

[Fabien Imbault <[e-mail]>]

There are 2 different things :
- there's a generic protocol where the client doesn't need to understand
the token, based on some joint knowledge between the RS and the AS (i.e.
what these tokens represent)
- and there could be some additional assumptions (e.g. token format, RS
preflight, etc.) on how the RS gets involved in a more dynamic way.

Both views are valid, but the goal is to keep easy things simple, and allow
complex stuff too.

"if the token is opaque, then of course it has to be introspected by some
entity the RS trusts, such as an AS." not necessarily, it's entirely
possible for the RS to simply say "thanks reputable AS, I accept to process
that access token". Or you might introspect at run time. Or in some more
sensitive scenarii you might really want to go one step further and indeed
establish some agreement on what tokens mean. All I'm saying is that there
are shades in what is possible.

On your last point that's just to say that the client posture may be part
of the policy decision (since you asked if the client matters).

Fabien

Le jeu. 18 mars 2021 à 05:21, Adrian Gropper <[e-mail]> a
écrit :

> ... "the knowledge the AS has of the RO" is a combination of policies the
> RO controls and the promise the RO received from the RS.
>
> Once the RS has made and signed a promise in some form, why does it need
> to know whether an AS was involved as long as the token has privileges that
> are equal or less than the promise?
>
> As Alan says, if the token is opaque, then of course it has to be
> introspected by some entity the RS trusts, such as an AS. Was that AS set
> as part of the promise made to the RO?
>
> What does client registration have to do with any of this?
>
> Adrian
>
> On Thu, Mar 18, 2021 at 12:07 AM Fabien Imbault <[e-mail]>
> wrote:
>
>> Yes, the AS is the policy manager and the token issuer for that
>> delegation, based on the knowledge it has of the RO.
>> We don't assume much on the lifecycle of the protected resource, except
>> that they expect a valid access token issued by the AS to provide access.
>>
>> We defined client instances related to one client software. The client
>> does matter, we could even define its class or posture, but it's possible
>> to make a request to the AS even if you're not pre registered.
>>
>> Fabien
>>
>> Le jeu. 18 mars 2021 à 04:54, Adrian Gropper <[e-mail]> a
>> écrit :
>>
>>> 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
>>>>>>>>
>>>>>>>>