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

[Roman Danyliw <[e-mail]>]

Hi!

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

Added to -05.

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

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

No action taken here.

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

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.
> > >>
> > >>>
> > >>>> - 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_JksY515Fg
> > >> mHFj0/
> > >
> > > 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.

Added to -05.

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

Was fixed in -04.

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

Added to -05.

> Thanks again!
> 
> -Ben