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

[Mike Jones <[e-mail]>]

Thanks for the useful review, Eric.  I’ll work with Brian and the crew to incorporate this feedback.

                                                       -- Mike

From: OAuth [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: Friday, December 29, 2017 8:41 AM
To: [e-mail]; [e-mail]
Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09

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