[OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-token-exchange-17: Yes

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


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting Yes; this document is solid and well-written.  I do have a
few additional (largely editorial) suggestions and a question or two,
though.

Section 2.1

   The client makes a token exchange request to the token endpoint with
   an extension grant type using the HTTP "POST" method and including
   the following parameters using the "application/x-www-form-
   urlencoded" format with a character encoding of UTF-8 in the HTTP
   request entity-body as described in Appendix B of RFC6749 [RFC6749].

This is a really long sentence.  I see how it got that way, and the RFC
Editor staff will probably have some thoughts on how to reword it, but
if you happen to have thoughts as well, feel free to have at it.

Section 2.2.1

   expires_in
      RECOMMENDED.  The validity lifetime, in seconds, of the token
      issued by the authorization server.  Oftentimes the client will
      not have the inclination or capability to inspect the content of
      the token and this parameter provides a consistent and token type
      agnostic indication of how long the token can be expected to be
      valid.  For example, the value 1800 denotes that the token will

nit: hyphenate "token-type-agnostic".

Section 4.4

Refresh my memory: did we already have a discussion about may_act as an
object vs. an array of objects?

Section 5

I'd consider also mentioning/linking the OAuth 2.0 security
considerations -- the fact that the STS is colocated with the token
endpoint takes care of ensuring a lot of its security properties.

Section 7

It's common (but not required, since it will not be relevant upon
publication as an RFC) to note that the indicated values are reflected
in early allocations from the indicated IANA registries.  In this case
I'd say "don't bother"...

Appendix B

Uh-oh, now we are up to five security ADs that have been around for this
document...