Re: [OAUTH-WG] problem statement

[Michael Thomas <[e-mail]>]

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