John's assertion that RI can be used to detect mis-configured clients would make it mandatory.
To avoid that we need a config time solution for misconfiguration. Phil > On Apr 12, 2016, at 01:30, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > > Hi >> On 11/04/16 23:19, Phil Hunt (IDM) wrote: >> I am objecting to modifying the protocol in the default case as a >> majority do not need RI in the case of fixed endpoints. >> >> Migration would be challenging because the change is breaking and >> affects existing clients. > How does it break the existing clients given this is an optional feature ? > Can you please describe the situation where the existing clients get broken ? > > Brian, would it make sense to update the text to mention that the clients do > not have to be directly configured and instead it can be set during the > registration time, so that the property gets seamlessly linked to client > access tokens, etc, without the client applications having to be set up with > the resource indicators manually ? > > Thanks, Sergey > >> Dynamic discovery are up and coming cases and a relatively green field. >> Dealing with it at configuration/discovery makes broader sense as it has >> no impact on existing clients. >> >> Phil >> >> On Apr 11, 2016, at 12:18, Brian Campbell <bcampb...@pingidentity.com >> <mailto:bcampb...@pingidentity.com>> wrote: >> >>> 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) >>> <phil.h...@oracle.com <mailto:phil.h...@oracle.com>> 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 >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
