Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01

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.

  -- 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