Grant Negotiation and Authorization Protocol
charter-ietf-gnap-01

* Define "resource server" in the intro paragraphs before it's first
  encountered in a bulleted list?

Some quick comments:
- the charter itself is rather verbose, sometimes convoluted, and often directive (looking like the charter is about rubber stamping existing work)
- nits please expand "AS" before first use
- missing milestones dates ?
- should this new WG work with others?

   "...the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible."

Should there be explicit chartered work about it?  It didn't seem to me that any of the proposed milestones covered migration, potential impact on existing operations, etc..

> (in contrast
> with OAuth 2.0 which is initiated by the client redirecting the user’s
> browser)

Editorial nit: This needs a comma after “OAuth 2.0”.

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

This sentence seems very clumsy and unclear.  The primary thing that bothers me is “mechanisms indicated by the protocol”: can we rephrase that to make it clearThe primary thing that bothers me is “mechanisms indicated by the protocol”: can we rephrase that to make it clearer what we’re talking about, perhaps by splitting the sentence, explaining what this means first, and then putting the rest of the sentence after it?  Maybe something like this:

NEW
The protocol will include interaction mechanisms that <some brief explanation>.  The client and Authorization Server (AS) will use those mechanisms to involve a user, as necessary, to make authorization decisions.
END

> - Support for directed, audience-restricted access tokens

What does “audience-restricted” mean?  Maybe this would be better phrased as, “Support for directed access tokens that restrict <explanation>” ?

> - Optimized inclusion of additional information through the
> delegation process (including identifiers and identity assertions)

Editorial nit: the parenthetical is misplaced:

NEW
- Optimized inclusion of additional information (including
identifiers and identity assertions) through the delegation process
END

> The group is chartered to develop mechanisms for conveying identity information
> within the protocol including identifiers […] and assertions
> […]
> The group is
> not chartered to develop new formats for identifiers or assertions

It would be good to add “existing” after “including”, for emphasis.

  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.

  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?

  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?

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

  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.

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

  - 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 [...]"

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

  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.

  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.

  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.

  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.

s/HTTP/HTTPS

Should it be HTTP/2 and HTTP/3 instead of HTTP2 and HTTP3?