Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT)

[Denis <[e-mail]>]

Hi,

I jump into this discussion with a one day delay because we are not in 
the same time zone.

Justin and myself had a discussion on the mailing list and we came into 
the following agreement which is not reflected in the current draft.

    [Denis]  Would this mean that we strongly agree together that the
    model should not assume a closely-tied connection between an RS and
    any single AS ?

    [Justin] Correct, *we shouldn’t assume it, but we should also not
    preclude it*. I think a lot of the internet is going keep with that
    model for some time to come,
    even if it’s not universal.

I noticed the following exchange:

    [Ben] Would "AS-directed dispatch to the appropriate RS" (or
    similar) be a useful way to describe this?

    [Justin] I think that works, as it’s basically about the AS telling
    the client what to do next.

The RS (i.e. not the AS) should tell the client what to do next. Since 
an AS has not necessarily a close relationship with RSs, it is unable to 
do it.

The close relationship between ASs and RSs should only be considered for 
some kind of backward compatibility with OAuth 2.0.

Denis

> Hi Justin,
>
> On Tue, Jun 30, 2020 at 03:59:17PM -0400, Justin Richer wrote:
>> Hi Ben,
>>
>>> On Jun 30, 2020, at 3:36 PM, Benjamin Kaduk <[e-mail]> wrote:
>>>
>>> Hi Justin!
>>>
>>> On Thu, Jun 25, 2020 at 03:29:36PM -0400, Justin Richer wrote:
>>>> Hi Ben,
>>>>
>>>> Thanks for the thorough read through, as always.
>>>>
>>>> Some of my own thoughts the TODO items inline below.
>>>>
>>>>>> This group is chartered to develop a fine-grained delegation protocol
>>>>>> for authorization and API access, as well as requesting and providing
>>>>>> user identifiers and claims.
>>>>>>
>>>>>> nit: this appears to parse as "providing user claims", and I'm not sure what that
>>>>>> means.
>>>>> TODO
>>>> Yes, the is intended to parse as “providing user claims”. The idea here is that the client should be able to send claims that it has to the AS that will identify the user in a fashion that the AS can verify. In these cases, the AS can make a policy decision without directly involving the user for interaction. This is largely a gap in the OAuth 2 world, though the Resource Owner Password grant and the Assertions grant kind go in this direction, but there’s a desire in the community for a general mechanism for doing this. To be clear, GNAP is going to defer the details of these kinds of assertions to other specifications, like W3C’s Verifiable Credentials.
>>> Let me play this back to check that I've got it right: the idea is that the
>>> client might have some existing assertion or something that is evidence
>>> that the user has already consented to something, and the protocol is going
>>> to include a way for the client to convey this artifact to the AS so that
>>> the AS can validate it and skip bothering the user directly?  I think we'd
>>> probably want some additional adjective here to clarify ("user-consent
>>> claims", "user verification claims", etc.) -- my original best-guess
>>> reading was that this was "user-supplied claims", e.g., "I'd like my token
>>> to include this arbitrary claim I just made up, please".  (The latter's
>>> intermingling of user-supplied and trusted-source data is a recipe for
>>> security issues, of course.)
>> Ah, I see the confusion now; right, the idea is not about the user putting claims into something that the AS echoes back to the client. We want the AS to be able to send stuff back that it knows about the user, but the client should be able to send it to the AS as well. For stuff from the client, there are two categories of information people are interested in: identifiers that aren’t proven yet (so it’s just a hint to the AS about who the client :thinks: the user is, like a username) and provable claim sets that the AS can verify independently (and the protocol doesn’t care how that gets validated). Most likely these latter ones will be formatted as assertions. I didn’t want the charter language to limit the format, but I might be overthinking it. I wanted to make sure the charter captured the intent of user information not being a one-way flow in the protocol. How about this:
>>
>> 	… for authorization, API access, user identifiers, and identity assertions. The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request.
>>
>> It’s much, much longer, but hopefully it avoids the garden path and hopefully gets at capturing the intent.
> I think it looks good, thanks.
>
>>>>>> The protocol will decouple the interaction channels, such as the end
>>>>>> user’s browser [...]
>>>>>>
>>>>>> "interaction channels" might be a term of art that needs clarification?
>>>>> TODO
>>>> I don’t think it’s a specific term of art. I think we really meant “different ways to interact with the user”. One of OAuth 2’s limitations is that it, for the most part, assumes the user’s in a browser, and the core of the protocol is built around that. One of the goals of GNAP is to get away from that as a base assumption.
>>> Perhaps "decouple the channels by which the protocol participants
>>> communicate"?
>> That can work.
>>
>>>>>> The client and Authorization Server (AS) will involve a user to make
>>>>>> an authorization decision as necessary through interaction mechanisms
>>>>>> indicated by the protocol.
>>>>>>
>>>>>>>  From a privacy perspective, will all of the information to be made
>>>>>> available from the AS to the RS be visible to the user as they make this
>>>>>> authorization decision?
>>>>> TODO
>>>> Ultimately I don’t think we can fully specify the AS behavior here, but this is a good pillar for privacy considerations.
>>>>
>>>>>> The group will define interoperability for this protocol between different
>>>>>> parties, including
>>>>>>   - client and authorization server;
>>>>>>   - client and resource server; and
>>>>>>   - authorization server and resource server.
>>>>>>
>>>>>> [obligatory note that just because we define an AS/RS channel doesn't mean it
>>>>>> will be required to use one at runtime, given the potential for self-contained
>>>>>> tokens?]
>>>>> Are you thinking that clarification would be explicitly stated?
>>>> Note that a self-contained token is one of the communication channels that the group had in mind for AS/RS. We tried to write the requirements in such a way as to allow for self-contained messages, service-based stuff (like introspection), or even all-in-one-box solutions that don’t need “communication” apart from both reading the same database. This is an architectural pillar borrowed from OAuth 2.
>>>>
>>>>>> - Support for directed, audience-restricted access tokens
>>>>>>
>>>>>> I think we need to clarify what "directed" is intended to mean here (if it's not
>>>>>> just a synonym for "audience-restricted" in which case it should just be
>>>>>> removed).
>>>>> TODO
>>>> This one is my fault — the concept we’re talking about here is one where the AS can effectively tell the client where and how it should use the token. There are a couple different WG participants who have expressed explicit interest in this, and I’ve started a thread on that topic recently:
>>>>
>>>> https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/
>>> I think I read that one :)
>>>
>>> Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful
>>> way to describe this?
>> I think that works, as it’s basically about the AS telling the client what to do next.
>>
>>>>>> - A variety of client applications, including Web, mobile,
>>>>>>    single-page, and interaction-constrained applications
>>>>>>
>>>>>> side note: this one feels like it would be easier to phrase as "the WG will seek
>>>>>> to minimize assumptions about the form of client applications, allowing for
>>>>>> [...]"
>>>>> TODO
>>>> That seems reasonable to me, and it goes hand-in-hand with the changes to interaction mentioned above.
>>>>
>>>>>> Additionally, the group will provide mechanisms for management of the
>>>>>> protocol lifecycle including:
>>>>>> [...]
>>>>>> - Mechanisms for the AS and RS to communicate the access granted by an
>>>>>>    access token
>>>>>>
>>>>>> Maybe I'm just confused, but isn't "the access granted by an access token"
>>>>>> exactly the set of authorizations conveyed by that token, i.e., the core point of
>>>>>> the protocol?  I'm not sure what kind "protocol lifecycle management" this
>>>>>> item is intending to indicate.
>>>>> TODO
>>>> This ties into what’s above: the idea is to have a standard model for what an access token represents, and this says we’re going to standardize ways for the AS and RS to communicate that. This could be inside the token, through an introspection style service, or some other thing we haven’t figured out yet. But the thing is, all of these mechanisms should be communicating the same set of information. This is something the OAuth WG didn’t address, and so we ended up with some disparity in the handful of de-facto access token data models there. The goal was to avoid that.
>>> Ah, okay.  So is the key point that these mechanisms/data-models are
>>> "consistent across the entire set of protocol flows"?
>>>
>> Yes, exactly. We want the different pieces to have a consistent model, without turning the spec into an “abstract data model” spec itself (because we want it to be a concrete protocol). So how about:
>>
>> 	- Data model for granted access and mechanisms for the AS and RS to communicate the granted access model.
> Works for me.
>
> Thanks again!
>
> -Ben
>