Thanks Ben, I'll publish an -18 shortly with these suggestions. A bit more detail is inline below.
On Fri, Jul 5, 2019 at 11:57 PM Benjamin Kaduk via Datatracker < [email protected]> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm balloting Yes; this document is solid and well-written. Thanks! 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. > I had at it a little bit and broke it up into two sentences. > > 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". > done > Section 4.4 > > Refresh my memory: did we already have a discussion about may_act as an > object vs. an array of objects? > Not to my recollection. I'm honestly not even sure what an array would mean for "may_act". Do you mean for "act"? I suppose an array of objects could be used as the value of "act" as a way to express a chain of delegation. However, the object with optional nesting seemed (to me) a more natural way to express it and has no overhead for the likely most common case of just a single actor. > > 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. > Makes sense. I'll add that. And refs to RFC6819 and draft-ietf-oauth-security-topics to round it out. > 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"... > Not bothering... > Appendix B > > Uh-oh, now we are up to five security ADs that have been around for this > document... > <sigh> an oversight on my part and unfortunate reminder about just how long this document has been in progress. I'll add Roman. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
