Re: [OAUTH-WG] problem statement

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Thu, 08 September 2011 00:17 UTC

Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5021F8D87 for <oauth@ietfa.amsl.com>; Wed, 7 Sep 2011 17:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.547
X-Spam-Level:
X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zkGqEuC4SGe for <oauth@ietfa.amsl.com>; Wed, 7 Sep 2011 17:17:17 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id E739521F8CB3 for <oauth@ietf.org>; Wed, 7 Sep 2011 17:17:16 -0700 (PDT)
Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1R1SKg-0000nK-BC; Thu, 08 Sep 2011 01:19:06 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
In-Reply-To: <4E67D149.8080200@mtcc.com>
Date: Thu, 08 Sep 2011 01:19:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D02EDDCE-4498-4B75-9C5F-340A439F0190@niven-jenkins.co.uk>
References: <4E665B25.6090709@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <CAMrm-MJHKTxaj1iEm_Lr=X92sOiWZcYN4F6dNqb5w5gh4OPndQ@mail.gmail.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <E3DEC4C8-6BB0-44EE-821A-7589F5DC6462@jkemp.net> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C6C9.1070704@stpete! r.im> <4E67C893.5060505@mtcc.com> <E37B0B59-787B-4F23-B708-596235235C79@gmail.co! m> <4E67D149.8080200@mtcc.com>
To: Michael Thomas <mike@mtcc.com>
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] problem statement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2011 00:17:19 -0000

Mike,

On 7 Sep 2011, at 21:17, Michael Thomas wrote:

> On 09/07/2011 12:56 PM, Kristoph wrote:
>> Mike,
>> 
>> I am an implementer of this specification. I am struggling to understand what it is you are trying to communicate.
>> 
>> The only thing I can discern is that you believe there is a large cadre of software architects / developers who you think have the skill to read and understand this specification, design and implement an OAuth 2.0 server, and yet not understand that a rogue embedded UA would compromise the end users credentials. Is that basically your concern?
>>   
> 
> I think that the fine point of a rogue embedded UA will be lost on
> people, yes. Especially those who are specing out the higher level
> authentication service deployment.

I've been observing this thread as well as the OAuth mailing list without participating for some time and I think what you write above gets to the heart of the matter.

I have some sympathy for the issue you are trying to raise but it is a common issue across many security protocols and the document to discuss it in is not the protocol specification which (IME in IETF) is typically focussed on how to implement (inter-operably) the protocol itself, not on best practices for deploying an implementation of the protocol.

IMO articulating the concerns you have are best placed either in the "threats" document (which I will admit I have not read) or a separate informational document (or possibly a BCP if there is sufficient deployment experience).

Your original e-mail that started this thread was not targeted at a specific document and my interpretation is that some of the hostility you have experienced is due to a frustration that your request is seen as a potential obstacle to getting the protocol specification out the door because the issue you want to discuss is not directly related to how a developer might implement the protocol.

If I may be so bold, could I suggest that you propose some text that articulates the issue that you would like to see documented and then the group can assess that text on its merits and try to reach consensus on which document, if any, it is best placed to reside within.

At the risk of offending you or others, I would suggest that if you're not willing to propose text for whatever reason then I'd suggest we put an end to this thread as it is reminding me of this Dilbert cartoon: http://www.dilbert.com/2010-12-22/

Regards
Ben