I'm not sure where the idea that it's only applicable to special uses like collaboration services is coming from. The pattern described in the draft (using a different parameter name but otherwise the same) is deployed and in-use for normal OAuth cases including and especially the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM) <[email protected]> wrote: > I am finding I am not happy with solving the bad resource endpoint config > issue with resource indicator. At best I see this as a special use draft > for things like collab services or things which aren't resource owner > centric. > > Yet resource endpoint config is a concern for all clients that configure > on the fly. Is it reasonable to make resource indicator mandatory for all > clients? Probably not. > > As OAuth depends primarily on TLS, it feels wrong not to have a solution > that confirms the server host names are correct either via config lookup or > some other mechanism. > > Tokbind is also a solution but I suspect it may only appeal to large scale > service providers and may be further off as we wait for load balancers to > support tokbind. Also there are issues with tokbind on initial user binding > where the mitm attack might itself establish its own token binding. I have > to think this through some to confirm. But the issue of worry is what is > happening on initialization and first use if the hacker has already > interceded a mitm. That would make validation at config time still critical. > > Hopefully somebody can arrive at an alternative for broader oauth use > cases. > > Phil > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
