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

Eran Hammer <> Mon, 09 January 2012 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54CFF21F874C for <>; Mon, 9 Jan 2012 08:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hfSrP7E70QKy for <>; Mon, 9 Jan 2012 08:18:13 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 7143721F86CC for <>; Mon, 9 Jan 2012 08:18:13 -0800 (PST)
Received: (qmail 23328 invoked from network); 9 Jan 2012 16:18:05 -0000
Received: from unknown (HELO ( by with SMTP; 9 Jan 2012 16:18:05 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([]) with mapi; Mon, 9 Jan 2012 09:17:47 -0700
From: Eran Hammer <>
To: Paul Madsen <>, "" <>
Date: Mon, 09 Jan 2012 09:17:30 -0700
Thread-Topic: [OAUTH-WG] Native clients & 'confidentiality'
Thread-Index: Acy+SHHUaIAU0l0SRtauDe1MldDRHAQoUXLg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A72D0CFA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453A72D0CFAP3PW5EX1MB01E_"
MIME-Version: 1.0
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, 09 Jan 2012 16:18:15 -0000

The text is pretty straight forward in its intentions. A confidential client must had a secret - what's open is how well the secret needs to be protected (e.g. hard to extract) to qualify as 'capable of keeping' secrets. You can require all clients to be confidential, but without specifying what qualifies as confidential, this requirement is pretty useless. It eliminates clients without secrets, or open source clients with the client id hardcoded and visible, but some can claim that a obfuscated secret in a native application binary is good enough. They will be wrong, but the spec allows them to make that decision.


From: [] On Behalf Of Paul Madsen
Sent: Monday, December 19, 2011 4:19 AM
Subject: [OAUTH-WG] Native clients & 'confidentiality'

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?

Is this consistent with the OAuth definition of confidentiality?