[OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09

[Eric Rescorla <[e-mail]>]

Full-featured review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4278

As noted in inline comments, some additional words about the security model
in which this document is embedded seem like they are needed. In
particular, it's pretty unclear to me what checks the STS is supposed to do
on a given request to determine whether to fulfill it. Where is that
documented?

*INLINE COMMENTS*
View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1580>
draft-ietf-oauth-token-exchange.txt:129
securing access to HTTP and RESTful resources but do not provide
everything necessary to facilitate token exchange interactions.

Can you say a bit more about what is missing here?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1581>
draft-ietf-oauth-token-exchange.txt:265
REQUIRED. The value "urn:ietf:params:oauth:grant-type:token-
exchange" indicates that a token exchange is being performed.

I note that S 4.5. says that the grant_type is "defined by the
authorization server" but that's not the case here, right?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1582>
draft-ietf-oauth-token-exchange.txt:268
resource
OPTIONAL. Indicates the physical location of the target service
or resource where the client intends to use the requested security

Do you actually mean "physical" here? Presumably if it's a URI it's most
likely a network address. I would take "physical" to mean "geographic"

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1583>
draft-ietf-oauth-token-exchange.txt:304
target services with a mix of logical names and physical
locations.

But it seems you can only specify one of each, right?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1584>
draft-ietf-oauth-token-exchange.txt:310
security token in the context of the service or resource where the
token will be used.

It's not clear to me where these values would come from. Can you expand on
this?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1585>
draft-ietf-oauth-token-exchange.txt:341
REQUIRED when the "actor_token" parameter is present in the
request but MUST NOT be included otherwise.

It's not entirely clear to me from this text how these tokens authenticate
the request. It's clear if they are bearer tokens, but if they are some
sort of token over a public key, then how does that work.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1586>
draft-ietf-oauth-token-exchange.txt:587
2.0 [OASIS.saml-core-2.0-os] assertion, respectively. Other URIs to
indicate other token types MAY be used.

This feels like it would be better as some kind of list (maybe bulleted)?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1587>
draft-ietf-oauth-token-exchange.txt:666
it as the current actor and that can be used at
https://backend.example.com.

Where can I find the definitions of "iss" and "sub"?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1588>
draft-ietf-oauth-token-exchange.txt:689
response, "act" has the same semantics and format as the claim of the
same name.

It's not entirely clear to me how I'm supposed to evaluate these from an
access control perspective.

Is the assumption here that the entity producing the JWT has ensured the
correct chain of issuers and subs?

Is it the RP's job to evaluate whether each entity in the chain could have
performed the action?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1589>
draft-ietf-oauth-token-exchange.txt:755
claims such as "exp", "nbf", and "aud" are not meaningful when used
within a "may_act" claim, and therefore should not be used.

I'm having a hard time understanding this claim. Can you provide an example
to me (in email is fine, it doesn't need to be in the draft) of how it
would be used?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D4278#inline-1590>
draft-ietf-oauth-token-exchange.txt:1273
produced under the chairmanship of Hannes Tschofenig and Derek Atkins
with Kathleen Moriarty and Stephen Farrell serving as Security Area
Directors. The following individuals contributed ideas, feedback,

You may want to update this

*REPOSITORY*
rIETFREVIEW ietf-review

*REVISION DETAIL*
https://mozphab-ietf.devsvcdev.mozaws.net/D4278

*EMAIL PREFERENCES*
https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/

*To: *ekr-moz, ekr
*Cc: *ekr