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

[Benjamin Kaduk <[e-mail]>]

Hi Roman,

Sorry to have let this slip well past the telechat...

On Thu, Jun 25, 2020 at 01:36:36PM +0000, Roman Danyliw wrote:
> Hi Ben!
> 
> A few quick, but incomplete, responses/edits before the telechat.
> 
> > -----Original Message-----
> > From: Txauth <[e-mail]> On Behalf Of Benjamin Kaduk via
> > Datatracker
> > Sent: Wednesday, June 24, 2020 11:20 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01:
> > (with COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > charter-ietf-gnap-00-01: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all email
> > addresses included in the To and CC lines. (Feel free to cut this introductory
> > paragraph, however.)
> > 
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/charter-ietf-gnap/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> >   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
> 
> >   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
> 
> >   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
> 
> >   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?

I don't think it needs to be, no.

> >   Additionally, the delegation process will allow for:
> >   [...]
> > 
> > Do all of these need to be fully fleshed out in the main protocol spec, or could
> > some of them be defered to future extensions?  Some of them feel much more
> > "core" than others, to me.
> 
> Fair.  IMO, the WG needs to have a discussion about how to appropriately decompose these capabilities, once there is an understood scope.  I'm not sure we need to decide now what capabilities are in the "core" vs. follow-on extensions.

Sure.  "Allow for" could be read either way, I suppose...

> >   - 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
> 
> >   - 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
>  
> >   - Mechanisms for conveying user, software, organization, and other
> >     pieces of information used in authorization decisions
> > 
> > nit: the "pieces of information" is in a weird place.  What are "user pieces of
> > information"?
> 
> Editorially, the read should be "user [information], software [information], etc.".
> 
> Removed "pieces of".
> 
> > (Also, this is a somewhat interesting place to put an extension point, though I
> > concede that there will eventually be need for some kind of extension here .. it
> > just seems like we should try to make use of this extension point a rare event.)
> > 
> >   - Optimized inclusion of additional information through the
> >   delegation process (including identifiers and identity assertions)
> > 
> > This seems pretty open-ended and prone to risky things.  E.g., even just a setup
> > with multiple identifiers quickly becomes complicated in terms of being able to
> > make precise statements about what specifically is being proven, whether there
> > is a guaranteed relationship between the two (or more) identities in question,
> > etc.; and this point seems even more open-ended than just that.
> 
> So the thinking is to scope down what that "additional information" might be?

That would help some, yes.  If we could phrase things such that there's
only a single entity being describe that would be best, e.g., "information
relating to the identity of the [client/whatever]"

> >   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 group is not chartered to develop extensions to OAuth 2.0, and as
> >   such will focus on new technological solutions not necessarily
> >   compatible with OAuth 2.0. Functionality that builds directly on OAuth
> >   2.0 will be developed in the OAuth Working Group, including
> >   functionality back-ported from the protocol developed here to OAuth 2.0.
> > 
> > Perhaps s/developed in/directed to/ -- we don't need this WG's charter to make
> > statements that are more appropriate in the OAuth WG's charter.
> 
> Fixed.
> 
> >   The group is chartered to develop mechanisms for conveying identity
> >   information within the protocol including identifiers (such as email
> >   addresses, phone numbers, usernames, and subject identifiers) and
> >   assertions (such as OpenID Connect ID Tokens, SAML Assertions, and
> >   Verifiable Credentials). The group is not chartered to develop new
> >   formats for identifiers or assertions, nor is the group chartered to
> >   develop schemas for user information, profiles, or other identity
> >   attributes, unless a viable existing format is not available.
> > 
> > This last bit is a decently sized loophole.  If we leave it out that would force a
> > recharter for picking up a new format, which might not be so bad.
> 
> In the consensus building to produce this text, it seemed helpful to be clear on what's in and out.
> 
> To be clear, is your concern that the text "... unless a viable existing format is not available" is the loophole?

Right.

> >   The working group will cooperate and coordinate with other IETF WGs such
> >   as OAUTH, and work with organizations in the community, such as the
> >   OpenID, as appropriate.
> > 
> > nit: "organizations in the community" is an unusual phrase; I think "external
> > organizations" is probably more common.
> 
> Fixed.  (Was cut-and-pasted from the RATS charter)

Thanks for the updates,

Ben