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

From: Paul Madsen <[email-masked]>
Date: Mon, 19 Dec 2011 07:19:16 -0500

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 itpractical 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?

Thanks

Paul

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Dec 2011 09:18:34 -0800

On 12/19/2011 04:19 AM, Paul Madsen wrote:
> ability to secure the credentials they'd use to authenticate to an AS 
> - confidential clients can protect those credentials, public clients 
> can't.
>
> 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

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Dec 2011 12:44:07 -0500

Native mobile clients can't really be confidential clients.

The distinction between "public" and "confidential" clients is whether 
or not they can keep deployment-time secrets; which is to say, a 
client_secret. This is not to say that they can't keep *any* secrets. In 
particular those generated at runtime, like an access token or refresh 
token, could be held perfectly safe. But at the time the app is deployed 
to its running environment, you have to ask "who has access to its code 
and configuration?"

Think of it this way. In the standard world, a native app gets copied to 
every device with the client_id and client_secret baked in. This makes 
the client_secret not very secret, and not at all unique. Anybody with 
access to the binary -- which is to say, every user -- could decompile 
the client_secret out of it and bake it into their *own* client, 
pretending to be your app and causing all kinds of havoc. This is a very 
different problem from somebody breaking into the token store and 
stealing an access token, which lets them only get to their own account.

Compare this to a server-based app where the only ones with access to 
the binary and configuration are the administrators of the server, not 
the end users. It's a much more limited list of folks that can 
potentially see it, and therefore the client_secret can actually mean 
something and add a small extra layer of security.

There are a few ways to mitigate this difference for public clients, 
such as using some kind of dynamic registration for all clients (which 
doesn't buy you much in terms of overall security) or putting up scary 
messages about native clients to try and educate your users. You can 
also use a trusted callback URL for your app on a hosted website that 
works in conjunction with your native app. This is actually the 
suggested use for the Implicit Flow, which was made for public clients 
in the browser.

Native apps also have the concern of embedded browsers vs. external 
native browsers, and what trust the user puts into them. For all OAuth 
flows, you have to trust the browser provider on the platform of choice, 
since the user's going to be logging in directly through that browser. 
It's very much outside the scope of OAuth to make that world any better 
though, and there have been long and detailed discussions on this list 
about that very topic, leading to some concrete recommendations in the 
draft as it stands today.

To answer your original query: I don't think that mandating one kind of 
client vs. the other will really help. OAuth 1.0 only had "confidential" 
clients, and that led to inane workarounds like Google's 
"anonymous/anonymous" client id/secret.

Hope this helps.

  -- Justin

On 12/19/2011 07:19 AM, Paul Madsen wrote:
> Give this discretion, is itpractical for the OMAP spec to stipulate 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Paul Madsen <[email-masked]>
Date: Mon, 19 Dec 2011 12:50:53 -0500

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:
> Can you say exactly what your security requirements are before trying 
> to determine which
> and am not sure if they're related to your concern or not. Part of 
> this is that I really don't

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Dec 2011 09:55:19 -0800

On 12/19/2011 09:44 AM, Justin Richer wrote:
> client_secret. This is not to say that they can't keep *any* secrets. 
> In particular those generated at runtime, like an access token or 
> refresh token, could be held perfectly safe. But at the time the app 
> is deployed to its running environment, you have to ask "who has 
> access to its code and configuration?"

Ah, thank you. The draft could be a *lot* more explicit about that in its
definitions. After reading it several times, I couldn't figure out who 
"public"
was to whom.

> flows, you have to trust the browser provider on the platform of 
> choice, since the user's going to be logging in directly through that 
> browser. It's very much outside the scope of OAuth to make that world 
> any better though, and there have been long and detailed discussions 
> on this list about that very topic, leading to some concrete 
> recommendations in the draft as it stands today.

As far as I can tell, the recommendations don't work.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Dec 2011 10:00:04 -0800

On 12/19/2011 09:50 AM, Paul Madsen wrote:
> 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

>>> 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.
>>>
>>> ability to secure the credentials they'd use to authenticate to an 
>>> AS - confidential clients can protect those credentials, public 
>>> clients can't.
>>>

---

From: Paul Madsen <[email-masked]>
Date: Mon, 19 Dec 2011 13:09:51 -0500

Thanks Justin, FWIW, I agree with your analysis

Seems to me we have the following breakdown of clients

- confidential server clients

- confidential native clients (somewhat theoretical at the moment, 
assumes either 1) a client registration mechanism to deliver credentials 
post installation, such as OpenID Connects Client Registration spec, or 
2) a distribution channel in which uniquely credentials can be packaged 
into the binary before delivery)

- public clients (no option of client authn, but still possible to have 
some protection against token leakage via other mitigating mechanisms)

thanks again

paul

On 12/19/11 12:44 PM, Justin Richer wrote:
> Think of it this way. In the standard world, a native app gets copied 
> to every device with the client_id and client_secret baked in. This 
> makes the client_secret not very secret, and not at all unique. 
> Anybody with access to the binary -- which is to say, every user -- 
> could decompile the client_secret out of it and bake it into their 
> *own* client, pretending to be your app and causing all kinds of 
> havoc. This is a very different problem from somebody breaking into 
> the token store and stealing an access token, which lets them only get 
> to their own account.
>
> To answer your original query: I don't think that mandating one kind 
> of client vs. the other will really help. OAuth 1.0 only had 
> "confidential" clients, and that led to inane workarounds like 
> Google's "anonymous/anonymous" client id/secret.
>
> Hope this helps.
>
>  -- Justin
>

---

From: Paul Madsen <[email-masked]>
Date: Mon, 19 Dec 2011 13:20:46 -0500

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

thanks

paul

On 12/19/11 1:00 PM, Michael Thomas wrote:
>>>> Give this discretion, is it practical for the OMAP spec to 
>>>> stipulate that 'All Clients (both server & native mobile), MUST be 
>>> Can you say exactly what your security requirements are before 
>>> trying to determine which
>>> rereading the draft isn't helping me. In particular, can a iPhone 
>>> app with a UIWebView *ever*

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 Dec 2011 10:38:43 -0800

> authenticating to the AS to prevent/mitigate the above risk

If there's any incentive at all to decompile an .apk (for example) and steal
the client secret, you can be guaranteed that somebody will do that.
Consider also that most developers area going to use whatever sample
code there is and do just about nothing to hide the key as best they
can regardless of how many warnings you put in your sample code.
So the attack is not likely to even be particularly difficult. Is it really
too much to ask app developers to spend $7/month for a shared hosting
service to keep their client secret a lot more secure?

Another thing to consider: in your client enrollment process how would
you insure/police that they are actually in compliance that it actually is
actually coming from confidential client?

Mike

>> your initial query, redefining a native/embedded app as 
>> "confidential" doesn't
>>>> (if either) is the right answer? I've got some concerns in this 
>>>> area that I'm trying to understand

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 19 Dec 2011 18:47:57 +0000

Not really sure how you came to the conclusion that native mobile clients can't be confidential? As pointed out in section 3.7 of the http://www.ietf.org/id/draft-ietf-oauth-v2-threatmodel-01.txt there are guidelines that confidential clients should follow, but does not distinguish between native clients or native mobile clients.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, December 19, 2011 9:44 AM
To: Paul Madsen
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Native clients & 'confidentiality'

The distinction between "public" and "confidential" clients is whether or not they can keep deployment-time secrets; which is to say, a client_secret. This is not to say that they can't keep *any* secrets. In particular those generated at runtime, like an access token or refresh token, could be held perfectly safe. But at the time the app is deployed to its running environment, you have to ask "who has access to its code and configuration?"

Think of it this way. In the standard world, a native app gets copied to every device with the client_id and client_secret baked in. This makes the client_secret not very secret, and not at all unique. Anybody with access to the binary -- which is to say, every user -- could decompile the client_secret out of it and bake it into their *own* client, pretending to be your app and causing all kinds of havoc. This is a very different problem from somebody breaking into the token store and stealing an access token, which lets them only get to their own account.

Compare this to a server-based app where the only ones with access to the binary and configuration are the administrators of the server, not the end users. It's a much more limited list of folks that can potentially see it, and therefore the client_secret can actually mean something and add a small extra layer of security.

There are a few ways to mitigate this difference for public clients, such as using some kind of dynamic registration for all clients (which doesn't buy you much in terms of overall security) or putting up scary messages about native clients to try and educate your users. You can also use a trusted callback URL for your app on a hosted website that works in conjunction with your native app. This is actually the suggested use for the Implicit Flow, which was made for public clients in the browser.

Native apps also have the concern of embedded browsers vs. external native browsers, and what trust the user puts into them. For all OAuth flows, you have to trust the browser provider on the platform of choice, since the user's going to be logging in directly through that browser. It's very much outside the scope of OAuth to make that world any better though, and there have been long and detailed discussions on this list about that very topic, leading to some concrete recommendations in the draft as it stands today.

To answer your original query: I don't think that mandating one kind of client vs. the other will really help. OAuth 1.0 only had "confidential" clients, and that led to inane workarounds like Google's "anonymous/anonymous" client id/secret.

Hope this helps.

 -- Justin

On 12/19/2011 07: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

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?

Thanks

Paul

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Mon, 19 Dec 2011 14:10:34 -0500

Hi Paul,

Is the need to authenticate the client a need to ensure that the content 
is only displayed on certain devices/clients? Or prevent 
phishing/stealing of authz bearer tokens?

As you point out, it's possible to protect the bearer tokens and 
associated refresh tokens "via other mitigating mechanisms". I'm not 
sure it's possible to authenticate the device/client with out the 
device/client having some special "hardware" that can be leveraged in 
the authentication step.

Even dynamic registration doesn't solve the security issues (the 
device/client can still be disassembled and associated values 
discovered) of the device/client, just mitigates the exposure risk. 
However, this does cause increased work for the AS as it will now be 
tracking each and every device as a unique client. It's also likely for 
the device registration steps to be discovered, in which case 
restricting to a particular device again fails.

It seems like trying to bind the bearer token to a device/client 
instance might be a better approach. That way you know that the customer 
correctly authorized that device/client instance and it is "allowed" to 
present the bearer token. Of course enforcing/proving the "allowed" part 
sort of breaks the "bearer" part:)

Thanks,
George

On 12/19/11 1:09 PM, Paul Madsen wrote:
> assumes either 1) a client registration mechanism to deliver 
> credentials post installation, such as OpenID Connects Client 
> Registration spec, or 2) a distribution channel in which uniquely 
> credentials can be packaged into the binary before delivery)
>
> - public clients (no option of client authn, but still possible to 
> have some protection against token leakage via other mitigating 
> mechanisms)
>
> thanks again
>
> paul
>
>> The distinction between "public" and "confidential" clients is 
>> whether or not they can keep deployment-time secrets; which is to 
>> say, a client_secret. This is not to say that they can't keep *any* 
>> secrets. In particular those generated at runtime, like an access 
>> token or refresh token, could be held perfectly safe. But at the time 
>> the app is deployed to its running environment, you have to ask "who 
>> has access to its code and configuration?"
>>
>> the token store and stealing an access token, which lets them only 
>> get to their own account.
>>
>> the binary and configuration are the administrators of the server, 
>> not the end users. It's a much more limited list of folks that can 
>> such as using some kind of dynamic registration for all clients 
>> (which doesn't buy you much in terms of overall security) or putting 
>> up scary messages about native clients to try and educate your users. 
>> You can also use a trusted callback URL for your app on a hosted 
>> website that works in conjunction with your native app. This is 
>> actually the suggested use for the Implicit Flow, which was made for 
>> public clients in the browser.
>>
>> native browsers, and what trust the user puts into them. For all 
>> OAuth flows, you have to trust the browser provider on the platform 
>> of choice, since the user's going to be logging in directly through 
>> that browser. It's very much outside the scope of OAuth to make that 
>> world any better though, and there have been long and detailed 
>> discussions on this list about that very topic, leading to some 
>> concrete recommendations in the draft as it stands today.
>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Dec 2011 14:31:37 -0500

A part of what George has outlined below is captured in the OpenID 
Connect Dynamic Registration flow. In that, the Dynamic Registration 
endpoint MAY be an OAuth2 protected resource. If you could mint your 
distributed clients with unique identifiers of some type, they could use 
those as bearer tokens to the registration endpoint, thereby getting a 
client id and secret.

The AS still has to keep track of all of these registered clients, and 
you've still got to find some way mint and manage all of those bearer 
tokens in the first place. But this approach does at least give you an 
OAuth-friendly way to bootstrap the whole process.

  -- Justin

On 12/19/2011 02:10 PM, George Fletcher wrote:
> Hi Paul,
>
> Is the need to authenticate the client a need to ensure that the 
> content is only displayed on certain devices/clients? Or prevent 
> tracking each and every device as a unique client. It's also likely 
> for the device registration steps to be discovered, in which case 
> instance might be a better approach. That way you know that the 
> customer correctly authorized that device/client instance and it is 
> "allowed" to present the bearer token. Of course enforcing/proving the 
> "allowed" part sort of breaks the "bearer" part:)
>
> Thanks,
> George
>
>>> token or refresh token, could be held perfectly safe. But at the 
>>> time the app is deployed to its running environment, you have to ask 
>>> "who has access to its code and configuration?"
>>>
>>> Think of it this way. In the standard world, a native app gets 
>>> copied to every device with the client_id and client_secret baked 
>>> in. This makes the client_secret not very secret, and not at all 
>>> unique. Anybody with access to the binary -- which is to say, every 
>>> user -- could decompile the client_secret out of it and bake it into 
>>> their *own* client, pretending to be your app and causing all kinds 
>>> of havoc. This is a very different problem from somebody breaking 
>>> into the token store and stealing an access token, which lets them 
>>> only get to their own account.
>>>
>>> Compare this to a server-based app where the only ones with access 
>>> to the binary and configuration are the administrators of the 
>>> server, not the end users. It's a much more limited list of folks 
>>> that can potentially see it, and therefore the client_secret can 
>>> actually mean something and add a small extra layer of security.
>>>
>>> up scary messages about native clients to try and educate your 
>>> users. You can also use a trusted callback URL for your app on a 
>>> hosted website that works in conjunction with your native app. This 
>>> is actually the suggested use for the Implicit Flow, which was made 
>>> for public clients in the browser.
>>>

---

From: John Kemp <[email-masked]>
Date: Mon, 19 Dec 2011 13:08:41 -0500

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

>> 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*

---

From: John Kemp <[email-masked]>
Date: Mon, 19 Dec 2011 13:21:20 -0500

Hi Paul,

Cheers,

- John

---

From: Paul Madsen <[email-masked]>
Date: Mon, 19 Dec 2011 14:49:41 -0500

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.

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?

thanks

paul

On 12/19/11 1:21 PM, John Kemp 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.
>>>> 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.
>>>>
>>>> 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,
>>>

---

From: Paul Madsen <[email-masked]>
Date: Mon, 19 Dec 2011 15:11:23 -0500

Hi George, inline

thanks

paul

> phishing/stealing of authz bearer tokens?
I'm not best qualified to answer but I believe it's the latter, ie not 
DRM motivated
> device/client having some special "hardware" that can be leveraged in 
are you referring to a 'bootstrap' problem?
> restricting to a particular device again fails.
yes, but as you imply an attacker will only access those credentials 
specific to that particular copy of the native client. Hopefully too 
much work to be able to see Glee Season 2.

Can you clarify what you mean about the device registration steps being 
'discovered'?
> "allowed" part sort of breaks the "bearer" part:)
yeah, how do we bind a bearer token to anything? :-) Doesnt that by 
definition take us towards MAC?

---

From: John Kemp <[email-masked]>
Date: Mon, 19 Dec 2011 15:20:36 -0500

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

---

From: Paul Madsen <[email-masked]>
Date: Mon, 19 Dec 2011 15:45:33 -0500

thanks John, inline

On 12/19/11 3:20 PM, John Kemp 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.
indeed, which points out that 'confidentiality <--> public' is a continuum.
> 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.…
A decision to release a vid could depend both on the user's 
subscriptions as well as the client being registered/valid. So, yes we 
care about clients keeping secrets, and so are able to authenticate to 
the AS in order to get tokens

As Justin pointed out, the challenge is more in getting the secret to a 
native client than keeping it hidden once obtained.

---

From: George Fletcher <[email-masked]>
Date: Wed, 21 Dec 2011 08:55:53 -0500

More inline:)

> are you referring to a 'bootstrap' problem?
Well... more thinking about whether the set of devices/clients allowed 
to go through the "dynamic registration" process is "restricted" in some 
way (e.g. a certain manufacturer, or application running on a device). 
Given that the dynamic registration steps can be discovered, it become 
difficult to restrict what devices/clients can go through the dynamic 
registration steps.

> Can you clarify what you mean about the device registration steps 
> being 'discovered'?
(see above). Basically, the question becomes... is any device/client ok 
to be used as long as it goes through the dynamic registration process 
and is "authorized" by the AS? If the answer is yes, then I think 
dynamic registration is a great solution.  Given all transactions are 
over SSL, getting any of client credentials, refresh_token or 
access_token is going to be difficult without access to the device/client.

There is the issue of the client sending the token to a rogue protected 
resource. Though that is pretty unlikely based on a native 
device/client. It would require a both a rogue client and a rogue 
protected resource. If this is a concern, then you are sort of back into 
the problem of needing to be able to at least identify the device/client.

Seems like a unique set of client credentials for every instance of the 
device/client plus short-lived access_tokens should be good enough for 
this use case. The associated refresh_token can always be revoked as 
well. All this doesn't obviate the need for "risk based authN/authZ" at 
the AS.
>> "allowed" to present the bearer token. Of course enforcing/proving 
>> the "allowed" part sort of breaks the "bearer" part:)
I know, I'm stating the obvious... but thankfully it sounds like you 
don't need that level of security:)
>>>> time the app is deployed to its running environment, you have to 
>>>> ask "who has access to its code and configuration?"
>>>>
>>>> user -- could decompile the client_secret out of it and bake it 
>>>> into their *own* client, pretending to be your app and causing all 
>>>> kinds of havoc. This is a very different problem from somebody 
>>>> breaking into the token store and stealing an access token, which 
>>>> lets them only get to their own account.
>>>>
>>>> There are a few ways to mitigate this difference for public 
>>>> clients, such as using some kind of dynamic registration for all 
>>>> clients (which doesn't buy you much in terms of overall security) 
>>>> or putting up scary messages about native clients to try and 
>>>> educate your users. You can also use a trusted callback URL for 
>>>> your app on a hosted website that works in conjunction with your 
>>>> native app. This is actually the suggested use for the Implicit 
>>>> Flow, which was made for public clients in the browser.
>>>>
>>>> that browser. It's very much outside the scope of OAuth to make 
>>>> that world any better though, and there have been long and detailed 
>>>> To answer your original query: I don't think that mandating one 
>>>> kind of client vs. the other will really help. OAuth 1.0 only had 
>>>>> Give this discretion, is itpractical for the OMAP spec to

---

From: [email-masked]
Date: Thu, 22 Dec 2011 10:58:04 +0800

In theory,  if only native clients could keep  deployment-time secret 
undisclosed, then we can say they are confidential clients. 
Actually, if native client applications are difficult to be 
reverse-enginnered, e.g., Skype,  it's possible to gain the above goal.
However, in most existing mobile apps, I guess reverse engieering  should 
be quite easy. 
In this case, there is almost no way for these apps to hide anything. 

Best wishes,

Ruishan 

deployment-time secrets

Not really sure how you came to the conclusion that native mobile clients 
can’t be confidential? As pointed out in section 3.7 of the 
http://www.ietf.org/id/draft-ietf-oauth-v2-threatmodel-01.txt there are 
guidelines that confidential clients should follow, but does not 
distinguish between native clients or native mobile clients.
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Justin Richer
Sent: Monday, December 19, 2011 9:44 AM
To: Paul Madsen
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Native clients & 'confidentiality'

The distinction between "public" and "confidential" clients is whether or 
not they can keep deployment-time secrets; which is to say, a 
client_secret. This is not to say that they can't keep *any* secrets. In 
particular those generated at runtime, like an access token or refresh 
token, could be held perfectly safe. But at the time the app is deployed 
to its running environment, you have to ask "who has access to its code 
and configuration?"

Think of it this way. In the standard world, a native app gets copied to 
every device with the client_id and client_secret baked in. This makes the 
client_secret not very secret, and not at all unique. Anybody with access 
to the binary -- which is to say, every user -- could decompile the 
client_secret out of it and bake it into their *own* client, pretending to 
be your app and causing all kinds of havoc. This is a very different 
problem from somebody breaking into the token store and stealing an access 
token, which lets them only get to their own account. 

Compare this to a server-based app where the only ones with access to the 
binary and configuration are the administrators of the server, not the end 
users. It's a much more limited list of folks that can potentially see it, 
and therefore the client_secret can actually mean something and add a 
small extra layer of security. 

There are a few ways to mitigate this difference for public clients, such 
as using some kind of dynamic registration for all clients (which doesn't 
buy you much in terms of overall security) or putting up scary messages 
about native clients to try and educate your users. You can also use a 
trusted callback URL for your app on a hosted website that works in 
conjunction with your native app. This is actually the suggested use for 
the Implicit Flow, which was made for public clients in the browser.

Native apps also have the concern of embedded browsers vs. external native 
browsers, and what trust the user puts into them. For all OAuth flows, you 
have to trust the browser provider on the platform of choice, since the 
user's going to be logging in directly through that browser. It's very 
much outside the scope of OAuth to make that world any better though, and 
there have been long and detailed discussions on this list about that very 
topic, leading to some concrete recommendations in the draft as it stands 
today.

Hope this helps.

 -- Justin

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.

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? 

Thanks

Paul