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

[Brian Campbell <[e-mail]>]

Yes, thank you for the review, Eric. A new draft -11 has been published
incorporating the feedback.

On Fri, Dec 29, 2017 at 10:48 AM, Mike Jones <[e-mail]>
wrote:

> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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