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

Paul Madsen <> Mon, 19 December 2011 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B26721F8B81 for <>; Mon, 19 Dec 2011 10:20:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bhcB7+8lGZ+g for <>; Mon, 19 Dec 2011 10:20:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 72AAE21F8B82 for <>; Mon, 19 Dec 2011 10:20:51 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so8502833wgb.13 for <>; Mon, 19 Dec 2011 10:20:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=hkS1GFEXj1IvYBigtMTJsG6HPAv6fWnVCA3HWvlRmUQ=; b=enOqzPi+jst5j8nU7T9OhwivjDt+RWcVgEWQn2RQOE5GhZh3znVW0ufpuDIa2sQBGK FmXXIRFjsJi0Z7XtgW3cXJ8BGVO7rJR54HfjnduH3BJzWQl7joHm8WplwshCOgXdf1Qe +A/u1R0Ve3ZlA4d+JSEbXIp+E7YOnYWIjVJvE=
Received: by with SMTP id gf2mr12935522wbb.20.1324318850621; Mon, 19 Dec 2011 10:20:50 -0800 (PST)
Received: from pmadsen-mbp.local ( []) by with ESMTPS id en20sm26869008wid.10.2011. (version=SSLv3 cipher=OTHER); Mon, 19 Dec 2011 10:20:49 -0800 (PST)
Message-ID: <>
Date: Mon, 19 Dec 2011 13:20:46 -0500
From: Paul Madsen <>
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 <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050206080509020205020406"
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 18:20:52 -0000

our bearer access tokens (JWT formatted) encapsulate a set of content 
permissions, and serve to authorize the entity presenting them to the 
corresponding video content.

We dont want those tokens falling into the wrong hands, and so want to 
prevent an attacker being able to impersonate a valid client and trade 
an authz code for the token.

*Ideally*, all our clients would be confidential, and so capable of 
authenticating to the AS to prevent/mitigate the above risk



On 12/19/11 1:00 PM, Michael Thomas wrote:
> On 12/19/2011 09:50 AM, 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 given the explanation Justin just gave, they do not. As I understand
> your initial query, redefining a native/embedded app as "confidential" 
> doesn't
> alter that reality. But my first question about requirements still is 
> relevant:
> what are you trying to protect from whom, and what is the level of 
> risk that
> your profile of oauth is willing to tolerate?
> Mike
>> 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