On 01/24/2012 05:57 AM, Justin Richer wrote:
Keep in mind that a major purpose of this document is to encourage best
practices by well-meaning developers. We want to make it clear for people who
want to do the right thing what the right thing to do is. No document in the
world will make ill-meaning developers do the right thing.
That what BCP's are for. A threat document is supposed to outline threats
and what good guys can do to mitigate them. Telling bad guys to be good
is completely useless.
Mike
-- Justin
On 01/23/2012 07:17 PM, Michael Thomas wrote:
On 01/23/2012 01:47 PM, S Moonesamy wrote:
Minor Issues:
4.4.1.4 2nd bullet. The explanation of why this wouldn't work for
native clients wasn't comprehensible to me. I'm suspicious of any
such claims because I can emulate most things a browser can do in a
mobile client. Perhaps this would be obvious to someone who is an
OAuth2 implementor.
Actually I'd say that it is *not* obvious because I joined the working
group mailing list as an oauth deployer who had precisely questions
along these lines expecting that I was *wrong* in worrying about this
attack.
I'd also say in this section and others like it dealing with native apps
that saying:
" Assumption: It is not the task of the authorization server to protect the
end-user's
device from malicious software"
Is wrong headed. It's not the authorization server's task to protect the end
user,
but the authorization server *surely* has an interest in protecting *itself*
from
rogue clients. An attack by a malicious client is an attack against the end user
*and* the authorization server.
4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a
Web Browser control embedded in the native app. If that's not what it
means, I don't understand what it's saying. If this is true, then the
second bullet point is probably wrong.
I agree, and don't think the first bullet makes any sense either:
"Native applications SHOULD use external browsers instead of
embedding browsers in an iFrame when requesting end-user authorization"
Who exactly is the attacker here? If it's the native app itself, then
this isn't a countermeasure at all because the rogue client will ignore
this SHOULD. If it's not the native app, then what is the an external
browser doing that an embedded browser cannot?
I don't understand the third bullet in this one either, but if only works
in older browsers it's probably not worth mentioning.
Mike
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
