Hi
On 12/04/16 16:58, Phil Hunt (IDM) wrote:
John's assertion that RI can be used to detect mis-configured clients would
make it mandatory.
This is an AS + RS decision, right (make the tokens bound to specific
RSs only) ? So if the client wants to access RS with (from now on)
stronger security restrictions then it is up to the client to ensure it
can do so.
Yes, if the client does not have this property (directly or indirectly)
available then it won't be able to access RS but I'm not sure it
qualifies as breaking the existing clients. (similarly, if the server
updates its server certificate then the client should be made aware of
it, etc)...
To avoid that we need a config time solution for misconfiguration.
How about setting the property at the AS Client registration process
time ? Or updating the existing client's registrations to ensure the
existing clients can stay operational ?
Cheers, Sergey
Phil
On Apr 12, 2016, at 01:30, Sergey Beryozkin <[email protected]> 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 <[email protected]
<mailto:[email protected]>> 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)
<[email protected] <mailto:[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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
