Re: [GNAP] DID as sub_id or assertion?

[Fabien Imbault <[e-mail]>]

+1 with that

On Thu, Mar 18, 2021 at 6:25 PM Justin Richer <[e-mail]> wrote:

> Fabien,
>
> Exactly, this is why I am more and more thinking that the core protocol
> should focus on the client instance->AS / client instance->RS connections
> (for which the token is opaque) and a secondary document would talk about
> the AS<->RS connection (for which the token is not opaque).
>
> The mapping of the AS and RS roles is also key. In OAuth 1, these were a
> single entity known as the “server”. In OAuth 2, we decided to split the
> roles to ease the discussion of how to deploy them. OAuth 2 doesn’t say
> anything about how they relate to each other except that the RS trusts
> tokens coming from the AS. An AS could have multiple RS’s that it protects,
> an RS could accept tokens from multiple AS’s, these relationships could be
> statically configured, they could be dynamic at runtime, etc. The community
> has come up with two key extensions — JWTs and Introspection — that allow
> for interoperable ways to make this connection, but OAuth 2’s core doesn’t
> actually care how this happens and it could be proprietary or internal (and
> often times is in practice). But in all cases, the RS has outsourced its
> trust to the AS to create tokens the RS will accept.
>
>  — Justin
>
> On Mar 18, 2021, at 1:13 PM, Fabien Imbault <[e-mail]>
> wrote:
>
> Hi Justin,
>
> "The access token is fundamentally a conversational artifact between the
> AS and the RS which the client is the carrier of."
> That's right, and a good opportunity to distinguish between the need for
> token inspection (i.e. a runtime verification, wherever that may be) and
> the need to negotiate the token format (a discovery). That last part could
> very well be an extension, as a way to open up the ecosystem beyond JWTs
> (which are fine, but come with their own limitations).
>
> Fabien
>
> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <[e-mail]> wrote:
>
>> On Mar 18, 2021, at 11:30 AM, Alan Karp <[e-mail]> wrote:
>>
>>
>> Justin Richer <[e-mail]> wrote:
>>
>>> 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.
>>>
>>
>> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's
>> implementation with VCs, or our Zebra Copy work.  Why must they be in GNAP?
>>
>>
>> The existence of the AS is exactly the reason for this. The AS is the
>> role that “knowledge about the token contents” has been outsourced to in
>> the GNAP model (which is based on the OAuth model).
>>
>> It brings significant simplicity for the client developer. The question I
>> have is — why does the client need to know what’s in the token? Not if they
>> could possibly know, but why would we expect a client to know and manage
>> the contents of the token?
>>
>> The access token is fundamentally a conversational artifact between the
>> AS and the RS which the client is the carrier of. The client is not the
>> audience of the token, nor the creator of the token, nor even the manager
>> of the token and the rights it represents. The client as a simple carrier
>> is a powerful model that allows the security layer to get out of the way of
>> the actual application logic that developers want to do.
>>
>>  — Justin
>>
>>
>> --------------
>> Alan Karp
>>
>>
>> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <[e-mail]> wrote:
>>
>>> 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
>>>>>>>>>
>>>>>>>>>
>>>
>>
>