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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 05 Jul 2019 20:56:42 -0700

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

---

From: Brian Campbell <[email-masked]>
Date: Sat, 6 Jul 2019 08:59:30 -0400

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-masked]> wrote:

> I'm balloting Yes; this document is solid and well-written.

Thanks!

  I do have a
> 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.

> nit: hyphenate "token-type-agnostic".

done

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

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

> I'd say "don't bother"...

Not bothering...

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 6 Jul 2019 13:42:27 -0500

> to express it and has no overhead for the likely most common case of just a

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

---

From: Brian Campbell <[email-masked]>
Date: Sun, 7 Jul 2019 09:32:15 -0400

On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk <[email-masked]> wrote:

> > for "may_act". Do you mean for "act"?
>

Okay, sorry, I'm a bit slow but I follow you now.

Indeed this has been deployed in a number of places already. I'd honestly
don't know if anyone is making use of this particular claim but changing
from an object to array of objects would be a breaking change. And a
breaking change is something I'd really like to avoid unless there's a very
compelling reason to do so.  And while your point here is taken, I don't
think it rises to that level of compelling.

I see two options at this point:
1) leave it as is
2) adjust the language around  "may_act" such that it could also identify
an eligible group - this would allow for it to indicate multiple authorized
parties but just not by one by one name, which is maybe more desirable
anyway

What do you think?

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Jul 2019 20:13:46 -0500

> parties but just not by one by one name, which is maybe more desirable

Either option is fine with me.  I don't remember how much precedent we have
in the OAuth ecosystem for groups that are  identified in  this manner, but
if it's a fairly common thing that seems to be slighly preferred.
(Even if we go with (1) and this does become an issue at some point, it
shouldn't be too hard to add a "may_also_act" or similar with the array
semantics.)

-Ben

---

From: Brian Campbell <[email-masked]>
Date: Mon, 15 Jul 2019 06:21:17 -0600

I believe there's a fair amount of precedent for something like it but
typically it's indicating group membership or roll(s) of a user that's
uniquely identified by other claims in a JWT. And, as far as I know,
there's nothing standardized for it so it's done more ad hoc. Thus there's
not really precedent from a standards perspective and, as I think about it
more, it's probably not a terribly good idea to try and define new
semantics like that at the 11th hour. So I'm gonna go with the '1) leave it
as is' option. And you're right that there are things that could be done
without too much issue, should it ever prove to be an issue (which I kinda
don't think will happen anyway).

On Fri, Jul 12, 2019 at 7:13 PM Benjamin Kaduk <[email-masked]> wrote:

> > > > Not to my recollection. I'm honestly not even sure what an array
> would
> > > mean