Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

Mark Mcgloin <> Mon, 16 January 2012 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9FC221F85E7 for <>; Mon, 16 Jan 2012 05:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.664
X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_20=-0.74]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id di9cetLh-rDq for <>; Mon, 16 Jan 2012 05:52:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8B94821F85B8 for <>; Mon, 16 Jan 2012 05:52:51 -0800 (PST)
Received: from /spool/local by with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <> from <>; Mon, 16 Jan 2012 13:52:49 -0000
Received: from ([]) by ([]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 16 Jan 2012 13:52:48 -0000
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0GDqljs2076768 for <>; Mon, 16 Jan 2012 13:52:47 GMT
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0GDqlj2003109 for <>; Mon, 16 Jan 2012 06:52:47 -0700
Received: from ( []) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q0GDql3x003106; Mon, 16 Jan 2012 06:52:47 -0700
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <4F04BF70.3 <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <OF8B311AA2.ACF026F4-ON8025797C.00460040-8025797C.004D16DC <>
X-KeepSent: F0355D8B:8B5DEE1F-8025797D:004D7295; type=4; name=$KeepSent
To: William Mills <>
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <>
From: Mark Mcgloin <>
Date: Mon, 16 Jan 2012 13:52:41 +0000
X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 16/01/2012 13:52:41
MIME-Version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
x-cbid: 12011613-5024-0000-0000-00000163D8B0
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jan 2012 13:52:52 -0000

Hi William

Sorry for slow response - comments inline below.

I really would like to close out on this set of countermeasures. I think
the differing opinions are subjective as this point and we all need to bear
in mind that the threat model is intended to advise on best practices and
not all of those will be applicable to all developers


William Mills <> wrote on 05/01/2012 16:29:02:

> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
> There's going to be a whole class of apps tat will be in violation
> of "Client applications SHOULD avoid directly asking users for the
> their credentials.".  We know that already, because the password
> grant exists and we have real use cases for it.  I think we should
> strikes that sentence and move that idea to #3 (soon to be #2)

The resource owner password credentials is intended for clients with trust
relationships with the resource server, mainly intranet apps. For all other
cases, client apps should use Oauth as it was intended, i.e. to avoid the
anti-pattern of asking users for credentials.

> I think point 2 should be struck, it's pointless.  What would matter
> here is whether the user can check that the app has been validated,
> and we're not defining that.

Agree that this countermeasure applies whether the app uses oauth or not
and because this threat is getting side tracked into advising on non-oauth
specific threats/countermeasures (i.e. user downloads malicious client)
It is just a suggestion, i.e. 'could', and may not apply to all
marketplaces. If the market place, such as apple, says the app has been
validated, then the user knows. You state elsewhere:

> "The current model is that apps are not validated first, they are pulled
if found to be hostile.   You're making a > recommendation here about how
an app marketplace should behave to be trustworthy, and I think that's
beyond the
> scope of users and client developers here.  We're already saying users
should only install trustworthy applications."

Again, it is just a suggestion. It may apply to some marketplaces more than
others, e.g. where the clients are accessing resources also under control
of the marketplace. Recommendations are aimed at resource server and
authorization server developers too.

> I would change #3 (now #2?) to:
>    3. It is RECOMMENDED that client applications use the web based
> authentication
>    flow, this takes advantage of a more trusted system component,
> e.g. the system
>    browser, and provides a consistent authentication experience for the
>    across applications.  The user is then always presenting their
> credential to a
>    known and trusted web page.  Collection and use of primary
> authentication from
>    the user by client applications is NOT RECOMMENDED.

I don't agree that your wording clarifies anything

> *From:* Mark Mcgloin <>


1. The OAuth flow is designed so that client applications never need to
know user passwords. Client applications SHOULD avoid directly asking users
for the their credentials. In addition, end users could be educated about
phishing attacks and best practices, such as only accessing trusted
clients, as OAuth does not provide any protection against malicious
applications and the end user is solely responsible for the trustworthiness
of any native application installed

2. Client applications could be validated prior to publication in an
application market for users to access. That validation is out of scope for
OAuth but could include validating that the client application handles user
authentication in an appropriate way

3. Client developers should not write client applications that collect
authentication information directly from users and should instead delegate
this task to a trusted system component, e.g. the system-browser.