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

From: Denis <[email-masked]>
Date: Wed, 1 Jul 2020 11:30:25 +0200

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 <[email-masked]> 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
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Jul 2020 19:57:57 -0700

Hi Denis,

> I jump into this discussion with a one day delay because we are not in 

Okay.

>     preclude it*. I think a lot of the internet is going keep with that

Note that "should not preclude it" means that we should allow it in some
cases, even though we don't require it.

> an AS has not necessarily a close relationship with RSs, it is unable to 

My understanding is that this "AS-directed dispatch to the appropriate RS"
functionality is intended to be an optional, not required, feature of the
protocol.  I do not see strong justification for us to force any single
workflow on the protocol at this time, whether RS-directed or AS-directed.

> some kind of backward compatibility with OAuth 2.0.

I understand that this is your belief.  I do not see much indication that
it is the WG consensus, at this time.

-Ben

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 6 Jul 2020 12:35:30 +0000

Hi!

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Tuesday, June 30, 2020 4:09 PM
> To: Justin Richer <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>; gnap-
> [email-masked]; [email-masked]
> Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-
> 01: (with COMMENT)
> 
> Hi Justin,
> 
> > >>>> 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.
> >

Added to -05.

> > >
> > >>
> > >>>
> > >>>> The protocol will decouple the interaction channels, such as the
> > >>>> end user’s browser [...]
> > >>>>
> > >> 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.
> > >

It's a little wordy, but added to -05.

> > >
> > >>>
> > >>>> The client and Authorization Server (AS) will involve a user to
> > >>>> make an authorization decision as necessary through interaction
> > >>>> mechanisms indicated by the protocol.
> > >>>>
> > >>>> 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.

No action taken here.

> > >>
> > >>>
> > >>>> The group will define interoperability for this protocol between
> > >>>> different parties, including
> > >>>> [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?]
> > >>>

No action taken here.

> > >> 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.
> > >>
> > >>>
> > >>>> 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:
> > >>
> > > Would "AS-directed dispatch to the appropriate RS" (or similar) be a
> > > useful way to describe this?
> >

Added to -05.

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

Was fixed in -04.

> > >>>> Additionally, the group will provide mechanisms for management of
> > >>>> the protocol lifecycle including:
> > >>>> [...]
> > >>>> 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.
> > >
> > 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:
> >

Added to -05.