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

John Kemp <> Mon, 19 December 2011 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 860DC21F85C7 for <>; Mon, 19 Dec 2011 12:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id me-PtpvZoO9i for <>; Mon, 19 Dec 2011 12:21:02 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id B0AA521F85D1 for <>; Mon, 19 Dec 2011 12:21:02 -0800 (PST)
Received: (qmail 6846 invoked by uid 0); 19 Dec 2011 20:20:40 -0000
Received: from unknown (HELO ( by with SMTP; 19 Dec 2011 20:20:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=BBufLT2dyj7CxW+eTZcBrpS13wtjsnSkf9BWDotBku0=; b=s1A2t0n5MAXPt47N5qI1D0q6cWqvzferx+CjRpYuuPxzm98+qVjGRIrtaEek34jNjy6pnURNXFIjCGZzusVsRnHPjdEs7LGHqC3c5JRVU5r+7JYPuO8roZFsL7VsX9Rv;
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from <>) id 1RcjhP-0002lZ-T6; Mon, 19 Dec 2011 13:20:40 -0700
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="windows-1252"
From: John Kemp <>
In-Reply-To: <>
Date: Mon, 19 Dec 2011 15:20:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Paul Madsen <>
X-Mailer: Apple Mail (2.1251.1)
X-Identified-User: {} {sentby:smtp auth authed with}
Subject: Re: [OAUTH-WG] Native clients & 'confidentiality'
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, 19 Dec 2011 20:21:03 -0000

Hey Paul,

On Dec 19, 2011, at 2:49 PM, Paul Madsen wrote:

> Hi John, the user identity & credentials are definitely fundamental (they allow the video content to be personalized), but given the valuable nature of the resources being accessed, many Resource Owners (that produce the video content) will expect that the clients be able to authenticate with its own credentials as well.

In which case, YMMV right, as usual, depending on the ability of the client to keep a secret? So, the expectation that clients can reliably authenticate seems still only reliable as those clients' platforms typically are (which is to say, not very reliable when put in the hands of consumers). 

> Wrt storing the user's credentials on the device, we are profiling the authz code grant type - we don't want passwords on the device , or even traded via RO creds grant type. But was that the question?

I was just trying to figure out why you care whether the client can keep a secret, assuming that it's actually and only the user authentication which determines whether the content may be accessed. If we're talking about protecting the user from phishing, you may not be as reliant on a client secret as if the content may be accessed only by authorized software installations in addition to authorized users. 

- John

> thanks
> paul  
> On 12/19/11 1:21 PM, John Kemp wrote:
>> Hi Paul,
>> On Dec 19, 2011, at 12:50 PM, Paul Madsen wrote:
>>> 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.
>> Well… from your description of your case (e.g. "based on a user's subscriptions"), I'm not sure whether the client (software) designation makes much difference. Am I correct in thinking that the credentials which really need to be protected are those assigned to a user, rather than those assigned to a client? In which case, wouldn't it be possible for even a 'public' OAuth client to acquire them from the user dynamically (rather than storing them on the device) and pass them encrypted or hashed to the server?
>> Cheers,
>> - John
>>> 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 
>>> _______________________________________________
>>> OAuth mailing list