If you haven't yet read the latter half of the "URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot" thread https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/jL3puNyiFD... where Nat raised an issue to do with the OAuth Mix-Up attack, please take a moment to do so before the call shortly. He has already attached similar feedback to his vote (a No vote) on the ballot, and made some specific recommendations for next actions). I'm very grateful to Nat for his comments! His application of time and expertise are always welcome. Although Kantara process does not require us to provide a disposition of comments at this stage of the proceedings, the nature of Nat's first comment particularly seems to warrant such. I've discussed the issue a bit with Justin, and right now, it's our current mutual understanding that the OAuth Mix-Up attack does *not* apply to UMA. I'll try to explain the logic briefly here, and plan to explore this in the call (and, as warranted, in continuing fashion with the WG) to ensure we get a proper understanding and consensus around this issue. Helpful resources: - https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#section-4.4 - https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01 The theory of why the attack (a client-AS MITM attack that exploits an endpoint discovery problem) applies is that the OAuth redirect_uri parameter, which the client gives to the AS to enable the AS to send the user (resource owner) back to the client after the process at the authorization endpoint is done, is directly analogous to UMA's claims_redirect_uri. However, UMA already has built-in ways to provision the client with the targeted AS and endpoint information it needs to make good endpoint-routing decisions, before the client gets to the stage of having to give the AS a claims_redirect_uri value. The first step is that the RS knows which AS is protecting whichever resource the client is trying to request, and it provides an as_loc value ("AS location"). This gets the client to the AS discovery document, where the client finds at least the token endpoint URI. (UMA doesn't have an authorization endpoint.) If the client gets an error from this endpoint that leads it to do interactive claims gathering, and it didn't yet know the claims interaction endpoint from the discovery document, it would get it from the need_info error response (the redirect_user hint) from that token endpoint. If, by chance, the client is supposed to send the requesting party to do interactive claims gathering first before approaching the token endpoint, this relies on the claims interaction endpoint also having been declared statically in the discovery document. I hope this helps us sort through the issue. Hope you can join the call. Thanks. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl