On 09/06/2011 06:27 PM, William Mills wrote:
I think the only potential mitigation OAuth can offer is that the
authenticating sites can do more due dilligence about the clients they
allow. I say this knowing that it's not likely to happen in most
cases, but it's possible. Sites *can* limit the clients they allow,
*but* it doesn't really work for installed clients on the desktop,
software copy protection being the hard problem that it has proved to be.
Yeah, I agree that it would be hard for the authenticating side to
do much, mainly because it's hard for them to tell if the app is
doing something untoward. I wonder if triggering DOM keypress
events gets propagated up to external webview code and you could
set some honeypots or steganography... hmm. I'm sorry but I'm still
very new to thinking about this problem space.
Nobody dismisses the problem you're talking about, it's definitely a
problem. What you have not do is provided any concrete way in which
OAuth can mitigate it beyond it's present state.
At this point, it would be just nice for the industry to know that the issue
even *exists*. Hence my puzzlement at the overt hostility from some
quarters.
I personally want OAuth 2.0 to get out the door. What you seem to be
asking for (if we really go there) is a far more comprehensive and
general security considerations section that's goign to cover a huge
swath of space not specific to OAuth. I don't think what you're
asking for is specific to OAuth, so I don't think it's appropriate to
take this spec there.
I have no dog in this race. I was just very puzzled by the lack of
discussion
about the lack of applicability of the protocol in either the protocol
document
or in the threats. It made me wonder whether this scenario had even been
considered. I'm still not sure if it had been.
If you really think you've got something here, draft language and
propose it. That takes this from the theory of the problem to
specifics. It's got to be concrete though and actionable. The recent
discussions around CSRF identified a problem of CSRF in the auth
server, and the new language addresses that in an actionable way.
Like I said in my first message: the documents lack any clear description of
the problem they are trying to address, any implicit assumptions about the
trust of the various elements, and the applicability of the protocol. That
should be part of the abstract and introduction, IMO.
Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
