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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
