Subject: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline)

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Mar 2011 07:05:12 -0700

I propose that the "or native applications" text be dropped from the
first paragraph in section 4.2 Implicit Grant  [1].

There is clearly some disagreement about what is most appropriate for
mobile/native applications and many, including myself, don't feel that
the implicit grant works well to support them (due to the lack of a
refresh token and need to repeat the authorization steps).  I
understand that the text in section 4 is non-normative, however, I
feel that the mention of native apps in 4.2 biases thinking in a
particular way (it's already led to one lengthy internal discussion
that I'd rather not have again and again).  I believe it'd be more
appropriate for the draft to remain silent on how native apps should
acquire tokens and leave it up to implementations/deployments to
decide (or an extension draft as Marius has proposed).

The "or native applications" text in is also somewhat inconsistent
with the text in the following sentence that talks about the
authentication of the client being based on the user-agent's
same-origin policy.

Removing those three words is a small change but one that I feel would
be beneficial on a number of fronts.

Thanks,
Brian

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2

On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Feel free to propose alternative preamble for the implicit and authorization code sections, describing the characteristics of what they are good for. It should fit in a single paragraph. Such a proposal would fit right in with last call feedback to -13.
>
> EHL
>
>> -----Original Message-----
>> From: Marius Scurtescu [mailto:[email-masked]]
>> Sent: Wednesday, February 16, 2011 1:39 PM
>> To: Eran Hammer-Lahav
>> Cc: Brian Campbell; OAuth WG
>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline
>>
>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav
>> <[email-masked]> wrote:
>> > The reason why we don't return a refresh token in the implicit grant is
>> exactly because there is no client authentication...
>>
>> Not sure that's the main reason. AFAIK it is because the response is sent
>> through the user-agent and it could leak.
>>
>>
>> > These are all well-balanced flows with specific security properties. If you
>> need something else, even if it is just a tweak, it must be considered a
>> different flow. That doesn't mean you need to register a new grant type, just
>> that you are dealing with different implementation details unique to your
>> server.
>>
>> The Authorization Code flow, with no client secret, is perfectly fine for Native
>> Apps IMO.
>>
>> Marius
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 06 Mar 2011 20:20:33 +0100

+1

Am 02.03.2011 15:05, schrieb Brian Campbell:
> On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav<[email-masked]>  wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Sun, 6 Mar 2011 14:12:03 -0800

-1

Many sites are using OAuth (or something like it) in native apps now. 

One of the objectives of having a standard is to bring best practices and standardization to how to solve a problem rather than "a million freakin unique snowflakes" where developers have to learn and code each mechanism to enable authorization to a native app. Brian's suggested wording may make sense in the context of where OAuth is now -- but it signals that the WG has been unable to solve what I think many viewed as an important aspect of the WG.

fwiw: I think a number of important constituents have opted out of the dialogue. An unfortunate situation.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 07 Mar 2011 11:00:24 +0100

Hi Dick,

I agree with you, the OAuth standard should offer clear patterns for 
native apps.

All native apps I'm familiar with use the authorization code, which is 
because of its support for refresh tokens. But the current text of the 
spec only suggests to use the implict grant flow to implement native 
apps whereas previous versions mentioned authz code and password flow as 
well. So in my opinion, the text is misleading to developers. And that's 
not only a feeling since I already meet people, which have been 
misguided :-(.

I think at least the misleading words shall be removed. Better would be 
to come up with a consensus after a discussion in the group.

regards,
Torsten.

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 7 Mar 2011 08:54:26 -0500

Agree with Torsten - having the mention in just that one place doesn't make sense. It should be removed or replicated throughout, but I think we might want a paragraph addressing native apps more deeply in the introduction. We don't want to give the (incorrect) impression that the implicit flow is the only or even preferred flow for native apps.

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Torsten Lodderstedt [[email-masked]]
Sent: Monday, March 07, 2011 5:00 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline)

Hi Dick,

regards,
Torsten.

---

From: "Lu, Hui-Lan (Huilan)" <[email-masked]>
Date: Mon, 7 Mar 2011 09:09:21 -0600

+1

Best regards,

Huilan LU

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Richer, Justin P.
> Sent: Monday, March 07, 2011 8:54 AM
> To: Torsten Lodderstedt; Dick Hardt
> Cc: OAuth WG
> Agree with Torsten - having the mention in just that one 
> place doesn't make sense. It should be removed or replicated 
> throughout, but I think we might want a paragraph addressing 
> native apps more deeply in the introduction. We don't want to 
> give the (incorrect) impression that the implicit flow is the 
> only or even preferred flow for native apps.
> 
>  -- Justin
> From: [email-masked] [[email-masked]] On 
> Behalf Of Torsten Lodderstedt [[email-masked]]
> I agree with you, the OAuth standard should offer clear 
> patterns for native apps.
> 
> All native apps I'm familiar with use the authorization code, 
> which is because of its support for refresh tokens. But the 
> current text of the spec only suggests to use the implict 
> grant flow to implement native apps whereas previous versions 
> mentioned authz code and password flow as well. So in my 
> opinion, the text is misleading to developers. And that's not 
> only a feeling since I already meet people, which have been 
> misguided :-(.
> 
> I think at least the misleading words shall be removed. 
> Better would be to come up with a consensus after a 
> discussion in the group.
> 
> regards,
> Torsten.
> 
> > One of the objectives of having a standard is to bring best 
> practices and standardization to how to solve a problem 
> rather than "a million freakin unique snowflakes" where 
> developers have to learn and code each mechanism to enable 
> authorization to a native app. Brian's suggested wording may 
> make sense in the context of where OAuth is now -- but it 
> signals that the WG has been unable to solve what I think 
> many viewed as an important aspect of the WG.
> >
> > fwiw: I think a number of important constituents have opted 
> out of the dialogue. An unfortunate situation.
> >
> >> mobile/native applications and many, including myself, don't feel 
> >> that the implicit grant works well to support them (due to 
> the lack 
> >> of a refresh token and need to repeat the authorization steps).  I 
> >> Removing those three words is a small change but one that I feel 
> >> would be beneficial on a number of fronts.
> >>
> >> Thanks,
> >> Brian
> >>
> >>
> >>> Feel free to propose alternative preamble for the 
> implicit and authorization code sections, describing the 
> characteristics of what they are good for. It should fit in a 
> single paragraph. Such a proposal would fit right in with 
> last call feedback to -13.
> >>>
> >>> EHL
> >>>
> >>>> Not sure that's the main reason. AFAIK it is because the 
> response 
> >>>> is sent through the user-agent and it could leak.
> >>>>
> >>>>
> >>>> need something else, even if it is just a tweak, it must be 
> >>>> considered a different flow. That doesn't mean you need 
> to register 
> >>>> a new grant type, just that you are dealing with different 
> >>>> implementation details unique to your server.
> >>>>
> >>>> The Authorization Code flow, with no client secret, is perfectly 
> >>>> fine for Native Apps IMO.
> >>>>
> >>>> Marius

---

From: Brian Campbell <[email-masked]>
Date: Mon, 7 Mar 2011 08:15:33 -0700

I don't disagree with any of that, Dick. But in the absence of any
specific solution or recommendation from the WG regarding native apps,
I am simply asking that the somewhat misleading text be removed from
the framework spec.

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 7 Mar 2011 11:37:47 -0800

Justin has well stated my view on this.  Folks here have explained how the flows can work for (or doesn't prohibit) a native app, but it also seems clear that new readers don't pick up how native apps fit into the flow in a 1st or 2nd pass.

So, in short, I agree with Brian's suggestion of (1) removing choice references to native apps, and (2) as a further (and preferred) step, a better preamble (possibly with further supporting edits) on the role of native apps. It seems Justin and Torsten are suggesting the same.

To go further than step 1 I agree we need some discussion on the story for native apps. For my part, here's how I see them fitting in:

- The general assumption is that Native apps can't keep secrets. This is mostly true except...
- Native apps with secured distribution (eg, controlled access by corporate IT departments who also can modify app preferences w/ the provider) can claim the apps keep secrets.  (A sample use case are Kiva field partners who develop simple enterprise apps for use inside a firewall).
- In truth, the question of secrets or no secrets (can authenticate or spoofable) is of primary importance for choosing a flow.
- In the common case, Native apps without secrets, an implicit flow or auth-code flow can be used. If an auth-code flow is used, there should be no client authentication. Alternatively, providers may instruct such clients to authenticate with an empty secret (since such clients should never be issued secrets to begin with).
- In the uncommon case of native apps who can keep secrets, an implicit flow cannot be used. The app must present credentials which requires an auth-code (or other) flow.
- I think there should be some note added to the auth-code flow on how a native app chooses and makes use of a redirect_uri.  This was present in draft 10 and was (i think) key to understanding the auth-code story for native apps.

I do not have strong opinions on the client-assertion flows for native apps nor the issuance of refresh tokens in an implicit flow. It does seem that some find it important to be able to issue refresh tokens to clients without secrets. I don't see a good argument to restrict this from a policy point of view (rather it seems more of issue of mechanics and/or fragment parsing), but it does seem the policy should be consistent. That is, if as an issue of policy, refresh tokens are not issued to apps without credentials, the policy applies for auth-code flows or implicit flows.

skylar

---

From: Dick Hardt <[email-masked]>
Date: Mon, 7 Mar 2011 12:09:02 -0800

Brian: I agree with your comments if native apps are not going to be supported in OAuth v2. 

my -1 is towards dropping native app support, and your suggestion was the easiest thread to comment on.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Mar 2011 12:45:50 -0700

I don't have strong views on keeping the reference to native apps, but the spec no longer offers advice on picking a grant type, other than pointing out the importance of being able to keep a secret. The term native app is undefined.

What is needed is a separate guide for helping newcomers pick the right grant type for their specific needs.

I also want to point out that this is a standard, not a tutorial.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Skylar Woodward
> Sent: Monday, March 07, 2011 11:38 AM
> To: Richer, Justin P.
> Cc: OAuth WG
> Justin has well stated my view on this.  Folks here have explained how the
> flows can work for (or doesn't prohibit) a native app, but it also seems clear
> that new readers don't pick up how native apps fit into the flow in a 1st or
> 2nd pass.
> 
> So, in short, I agree with Brian's suggestion of (1) removing choice references
> to native apps, and (2) as a further (and preferred) step, a better preamble
> (possibly with further supporting edits) on the role of native apps. It seems
> Justin and Torsten are suggesting the same.
> 
> To go further than step 1 I agree we need some discussion on the story for
> native apps. For my part, here's how I see them fitting in:
> 
> - Native apps with secured distribution (eg, controlled access by corporate IT
> departments who also can modify app preferences w/ the provider) can
> claim the apps keep secrets.  (A sample use case are Kiva field partners who
> develop simple enterprise apps for use inside a firewall).
> - In truth, the question of secrets or no secrets (can authenticate or
> spoofable) is of primary importance for choosing a flow.
> - In the common case, Native apps without secrets, an implicit flow or auth-
> code flow can be used. If an auth-code flow is used, there should be no client
> authentication. Alternatively, providers may instruct such clients to
> authenticate with an empty secret (since such clients should never be issued
> secrets to begin with).
> - In the uncommon case of native apps who can keep secrets, an implicit flow
> cannot be used. The app must present credentials which requires an auth-
> code (or other) flow.
> - I think there should be some note added to the auth-code flow on how a
> native app chooses and makes use of a redirect_uri.  This was present in
> draft 10 and was (i think) key to understanding the auth-code story for native
> apps.
> 
> I do not have strong opinions on the client-assertion flows for native apps
> nor the issuance of refresh tokens in an implicit flow. It does seem that some
> find it important to be able to issue refresh tokens to clients without secrets.
> I don't see a good argument to restrict this from a policy point of view (rather
> it seems more of issue of mechanics and/or fragment parsing), but it does
> seem the policy should be consistent. That is, if as an issue of policy, refresh
> tokens are not issued to apps without credentials, the policy applies for auth-
> code flows or implicit flows.
> 
> skylar
> 
> 
> > Agree with Torsten - having the mention in just that one place doesn't
> make sense. It should be removed or replicated throughout, but I think we
> might want a paragraph addressing native apps more deeply in the
> introduction. We don't want to give the (incorrect) impression that the
> implicit flow is the only or even preferred flow for native apps.
> >
> > -- Justin
> > From: [email-masked] [[email-masked]] On Behalf Of
> > Torsten Lodderstedt [[email-masked]]
> > apps whereas previous versions mentioned authz code and password flow
> > as well. So in my opinion, the text is misleading to developers. And
> > that's not only a feeling since I already meet people, which have been
> > misguided :-(.
> >
> > I think at least the misleading words shall be removed. Better would
> > be to come up with a consensus after a discussion in the group.
> >
> > regards,
> > Torsten.
> >
> >> One of the objectives of having a standard is to bring best practices and
> standardization to how to solve a problem rather than "a million freakin
> unique snowflakes" where developers have to learn and code each
> mechanism to enable authorization to a native app. Brian's suggested
> wording may make sense in the context of where OAuth is now -- but it
> signals that the WG has been unable to solve what I think many viewed as an
> important aspect of the WG.
> >>
> >>> There is clearly some disagreement about what is most appropriate
> >>> for mobile/native applications and many, including myself, don't
> >>> feel that the implicit grant works well to support them (due to the
> >>> lack of a refresh token and need to repeat the authorization steps).
> >>> I understand that the text in section 4 is non-normative, however, I
> >>>> Feel free to propose alternative preamble for the implicit and
> authorization code sections, describing the characteristics of what they are
> good for. It should fit in a single paragraph. Such a proposal would fit right in
> with last call feedback to -13.
> >>>>
> >>>> EHL
> >>>>
> >>>>> Not sure that's the main reason. AFAIK it is because the response
> >>>>> considered a different flow. That doesn't mean you need to
> >>>>> register a new grant type, just that you are dealing with
> >>>>> different implementation details unique to your server.
> >>>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 8 Mar 2011 09:26:03 -0500

Also, there's a big difference between "can keep secrets" and "can be
packed/shipped with secrets". Many native apps fit into the former
category but not the latter, which makes storage of refresh tokens and
other long-term credentials reasonable, but not server-issued client
secrets.

 -- Justin

---

From: Skylar Woodward <[email-masked]>
Date: Tue, 8 Mar 2011 11:22:14 -0800

To clarify, when I say "can keep secrets" I mean "can be packed/shipped with secrets."  Good point.

I assume all OAuth clients can keep secrets in the more general sense you implied. Otherwise, even bearer tokens would be useless.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 15:15:39 -0700

Done.

Also removed ' and the authentication of the client is based on the user-agent's same-origin policy'.

EHL

> From: Brian Campbell [mailto:[email-masked]]
> Sent: Wednesday, March 02, 2011 6:05 AM
> To: Eran Hammer-Lahav
> Cc: Marius Scurtescu; OAuth WG
> Subject: slightly alternative preamble (was: Re: [OAUTH-WG] Draft -12
> feedback deadline)
> 
> I propose that the "or native applications" text be dropped from the first
> paragraph in section 4.2 Implicit Grant  [1].
> 
> mobile/native applications and many, including myself, don't feel that the
> implicit grant works well to support them (due to the lack of a refresh token
> and need to repeat the authorization steps).  I understand that the text in
> section 4 is non-normative, however, I feel that the mention of native apps
> in 4.2 biases thinking in a particular way (it's already led to one lengthy
> internal discussion that I'd rather not have again and again).  I believe it'd be
> more appropriate for the draft to remain silent on how native apps should
> acquire tokens and leave it up to implementations/deployments to decide
> (or an extension draft as Marius has proposed).
> 
> The "or native applications" text in is also somewhat inconsistent with the
> text in the following sentence that talks about the authentication of the
> client being based on the user-agent's same-origin policy.
> 
> Removing those three words is a small change but one that I feel would be
> beneficial on a number of fronts.
> 
> Thanks,
> Brian
> 
> 
> > Feel free to propose alternative preamble for the implicit and authorization
> code sections, describing the characteristics of what they are good for. It
> should fit in a single paragraph. Such a proposal would fit right in with last call
> feedback to -13.
> 
> >
> > EHL
> >
> >> Not sure that's the main reason. AFAIK it is because the response is
> >> sent through the user-agent and it could leak.
> >>
> >>
> >> considered a different flow. That doesn't mean you need to register a
> >> new grant type, just that you are dealing with different
> >> The Authorization Code flow, with no client secret, is perfectly fine
> >> for Native Apps IMO.
> >>
> >> Marius
> >