Re: [OAUTH-WG] Native clients & 'confidentiality'

Paul Madsen <paul.madsen@gmail.com> Mon, 19 December 2011 17:51 UTC

Return-Path: <paul.madsen@gmail.com>
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 C377A21F8BA8 for <oauth@ietfa.amsl.com>; Mon, 19 Dec 2011 09:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 5+ApJBWuq0gF for <oauth@ietfa.amsl.com>; Mon, 19 Dec 2011 09:51:00 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64F3221F8BA6 for <oauth@ietf.org>; Mon, 19 Dec 2011 09:50:59 -0800 (PST)
Received: by laah2 with SMTP id h2so2529462laa.31 for <oauth@ietf.org>; Mon, 19 Dec 2011 09:50:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=m5UJPAd1qDPGS1q95WU8fIBfC93JCxoSvGZ9hFznlFw=; b=K99bwA4C22Qulj72p+r1Pd68nJwIsqpHPD3ujDVo9hAE/hBg5gAWVU6RHrgQwpotqW YfjXlvooF8+Sf8RL7AvTfFw0MjjlnS+4Kx2LUwTg1QxRn5/qpv/ix35mn7/sFj1dHL2G JzU0Gur7j0CraqWY35sjCu2HdGM+svDSI4o7I=
Received: by 10.152.134.50 with SMTP id ph18mr17387511lab.1.1324317058062; Mon, 19 Dec 2011 09:50:58 -0800 (PST)
Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [72.136.168.159]) by mx.google.com with ESMTPS id lr3sm17459040lab.17.2011.12.19.09.50.54 (version=SSLv3 cipher=OTHER); Mon, 19 Dec 2011 09:50:56 -0800 (PST)
Message-ID: <4EEF797D.4020608@gmail.com>
Date: Mon, 19 Dec 2011 12:50:53 -0500
From: Paul Madsen <paul.madsen@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Michael Thomas <mike@mtcc.com>
References: <4EEF2BC4.7020409@gmail.com> <4EEF71EA.3080200@mtcc.com>
In-Reply-To: <4EEF71EA.3080200@mtcc.com>
Content-Type: multipart/alternative; boundary="------------020800070702030909070700"
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Native clients & 'confidentiality'
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: Mon, 19 Dec 2011 17:51:00 -0000

Hi Mike, to some extent I think my question is not about specific 
security characteristics, but rather whether its realistic for our group 
to mandate that both server & native clients have the *same* security 
characteristics - particularly the ability to 'securely' authenticate to 
the AS on the token endpoint.

thanks

paul

On 12/19/11 12:18 PM, Michael Thomas wrote:
> On 12/19/2011 04:19 AM, Paul Madsen wrote:
>> Hi, the Online Media Authorization Protocol (OMAP) is a (as yet 
>> unreleased) profile of OAuth 2.0 for online delivery of video content 
>> based on a user's subscriptions (the TV Everywhere use case)
>>
>> We want to support both server & native mobile clients. It is for the 
>> second class of clients that I'd appreciate some clarification of 
>> 'confidentiality' as defined in OAuth 2.
>>
>> OAuth 2 distinguishes confidential & public clients based on their 
>> ability to secure the credentials they'd use to authenticate to an AS 
>> - confidential clients can protect those credentials, public clients 
>> can't.
>>
>> Notwithstanding the above definition, the spec gives a degree of 
>> discretion to the AS
>>
>>     The client type designation is based on the authorization server's
>>     definition of secure authentication and its acceptable exposure
>>     levels of client credentials.
>>
>>
>> Give this discretion, is it practical for the OMAP spec to stipulate 
>> that 'All Clients (both server & native mobile), MUST be 
>> confidential', ie let each individual OMAP AS specify its own 
>> requirements of clients and their ability to securely authenticate?
>
> Hi,
>
> Can you say exactly what your security requirements are before trying 
> to determine which
> (if either) is the right answer? I've got some concerns in this area 
> that I'm trying to understand
> and am not sure if they're related to your concern or not. Part of 
> this is that I really don't
> understand what the difference is between a "public" client and a 
> "confidential client" and
> rereading the draft isn't helping me. In particular, can a iPhone app 
> with a UIWebView *ever*
> be a "confidential" client, and if so how?
>
> Mike