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

[Benjamin Kaduk <[e-mail]>]

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

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

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

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

Thanks,

Ben