On Sat, Jul 06, 2019 at 08:59:30AM -0400, Brian Campbell wrote: > 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 < > nore...@ietf.org> 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.
Currently we can say that ad...@example.com "may act" as u...@example.com. But IIUC we don't have a way to say that either adm...@example.com or adm...@example.com may do so. An array would let us indicate multiple authorized parties. I'm reluctant to actually make such a change at this point, though, since this is already deployed some places, right? -Ben > > > > > > > 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
