Thanks for the useful review, Eric. I’ll work with Brian and the crew to
incorporate this feedback.
-- Mike
From: OAuth [mailto:[email protected]] On Behalf Of Eric Rescorla
Sent: Friday, December 29, 2017 8:41 AM
To: [email protected]; [email protected]
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
