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

[Benjamin Kaduk <[e-mail]>]

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 <
> [e-mail]> 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 [e-mail] "may act" as [e-mail].
But IIUC we don't have a way to say that either [e-mail] or
[e-mail] 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._