Yes clients that are dynamically configured would need to check the returned resources, or send the resource if you want to detect misconfiguration.
This check is at run time and can be enforced by the AS. A discovery check is fake-able if the web-finger URI is compromised. Likely in my opinion if the resource is compromised in the config. It also can not be enforced. Other than that it is a fine idea. John B. > On Apr 12, 2016, at 11:58 AM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote: > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
