Subject: Re: [OAUTH-WG] A display parameter for user authorization requests

From: David Recordon <[email-masked]>
Date: Wed, 9 Jun 2010 12:06:24 -0700

First draft of the UX Extension is at
http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-ux-00.txt.

Eran, I'm more than happy to have you take over as editor.

I included Allen and Breno as authors since I followed Allen's
suggestion and adopted the language preference parameter from the
OpenID extension. I also included Luke as an author since he wrote the
first pass of a display parameter. That said, none of them have seen
this draft yet.

--David

On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom <[email-masked]> wrote:
> At least with regards to the language preference, how about if we just copy
> the openid.ui.lang parameter from the OpenID UI Extension?
>
> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor3
>
> In flows in which the client redirects the user’s web browser to authorize
> access, the client MAY send the Authorization Server a hint regarding the
> user’s preferred language by sending the following parameter:
>
>     lang
>         The user’s preferred languages as a [BCP 47] language priority list,
> represented as a comma-separated list of BCP 47 basic language ranges in
> decending priority order. For instance, the value “fr-CA,fr-FR,en-CA”
> represents the preference for French spoken in Canada, French spoken in
> France, followed by English spoken in Canada.
>
> The language preference hint SHOULD take precedence over the Accept-Language
> HTTP header sent by the user’s browser, and SHOULD take precedence over the
> language preference inferred by the user’s IP Address.
>
> BCP 47:  http://tools.ietf.org/html/bcp47
>
> Allen
>
>
> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:
>
> Between language preferences, display configuration, and immediate check, I
> think it might be worth to move that work to another draft. Timeline-wise,
> this has the potential of slowing us down. I also fear getting what is now a
> pretty simple spec much more complicated.
>
> Anyone cares to try a first draft or outline? I can do the editorial work if
> needed, but someone needs to write something first.
>
> EHL
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 9 Jun 2010 12:23:53 -0700

> first pass of a display parameter. That said, none of them have seen

Thanks.

At a higher-level, is the extension model of OAuth2 to add new
parameters at the top-level namespace? Works fine for extensions such
as this one that are probably of interest to a large part of the
community, but I wonder if we should give guidance for a generic
approach to doing this (even if not adhering to it in the 'main'
extensions).

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

---

From: David Recordon <[email-masked]>
Date: Wed, 9 Jun 2010 12:27:32 -0700

I believe that Eran is separately working on documenting the extension
model. Let's leave that discussion for another thread.

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 9 Jun 2010 12:30:51 -0700

> model. Let's leave that discussion for another thread.

Sounds good.

-- 
--Breno

+1 (650) 214-1007 desk

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 9 Jun 2010 14:54:03 -0700

-07 will include an initial extensibility model (which I need as well for the discovery parameters, signature proposal, etc.)

EHL

On 6/9/10 12:27 PM, "[email-masked]" <[email-masked]> wrote:

On Wed, Jun 9, 2010 at 12:23 PM, Breno de Medeiros <[email-masked]> wrote:
>>> In flows in which the client redirects the user's web browser to authorize
>>> user's preferred language by sending the following parameter:
>>>
>>>     lang
>>>         The user's preferred languages as a [BCP 47] language priority list,
>>> decending priority order. For instance, the value "fr-CA,fr-FR,en-CA"
>>> HTTP header sent by the user's browser, and SHOULD take precedence over the
>>> language preference inferred by the user's IP Address.
>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 10 Jun 2010 16:18:06 -0700

Since these are all extensions to the end-user endpoint, I'd suggest we move the 'immediate' parameter here as well.

              <t hangText='immediate'>
                <vspace />
                OPTIONAL. The parameter value must be set to <spanx style='verb'>true</spanx> or
                <spanx style='verb'>false</spanx>. If set to
                <spanx style='verb'>true</spanx>, the authorization server MUST NOT prompt the
                end-user to authenticate or approve access. Instead, the authorization server
                attempts to establish the end-user's identity via other means (e.g. browser
                cookies) and checks if the end-user has previously approved an identical access
                request by the same client and if that access grant is still active. If the
                authorization server does not support an immediate check or if it is unable to
                establish the end-user's identity or approval status, it MUST deny the request
                without prompting the end-user. Defaults to <spanx style='verb'>false</spanx> if
                omitted.
              </t>
EHL

> -----Original Message-----
> From: David Recordon [mailto:[email-masked]]
> Sent: Wednesday, June 09, 2010 12:06 PM
> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] A display parameter for user authorization
> requests
> 
> I included Allen and Breno as authors since I followed Allen's suggestion and
> adopted the language preference parameter from the OpenID extension. I
> also included Luke as an author since he wrote the first pass of a display
> parameter. That said, none of them have seen this draft yet.
> 
> --David
> 
> 
> > At least with regards to the language preference, how about if we just
> > copy the openid.ui.lang parameter from the OpenID UI Extension?
> >
> > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/op
> > enid-user-interface-extension-1_0.html#anchor3
> >
> > In flows in which the client redirects the user's web browser to
> > authorize access, the client MAY send the Authorization Server a hint
> > regarding the user's preferred language by sending the following
> parameter:
> >
> >     lang
> >         The user's preferred languages as a [BCP 47] language priority
> > list, represented as a comma-separated list of BCP 47 basic language
> > ranges in decending priority order. For instance, the value "fr-CA,fr-FR,en-
> CA"
> > represents the preference for French spoken in Canada, French spoken
> > in France, followed by English spoken in Canada.
> >
> > The language preference hint SHOULD take precedence over the
> > Accept-Language HTTP header sent by the user's browser, and SHOULD
> > take precedence over the language preference inferred by the user's IP
> Address.
> >
> > Between language preferences, display configuration, and immediate
> > check, I think it might be worth to move that work to another draft.
> > Timeline-wise, this has the potential of slowing us down. I also fear
> > getting what is now a pretty simple spec much more complicated.
> >
> > Anyone cares to try a first draft or outline? I can do the editorial
> > work if needed, but someone needs to write something first.
> >
> > EHL
> >
> >
> >

---

From: David Recordon <[email-masked]>
Date: Thu, 10 Jun 2010 17:32:35 -0700

+1 for moving immediate here as well.

---

From: David Recordon <[email-masked]>
Date: Thu, 10 Jun 2010 21:13:44 -0700

http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-ux-01.txt

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 11 Jun 2010 06:57:21 -0700

There was discussion about a username hint parameter, in general this
is needed when immediate is used. Should username go to this UX
Extension, or rather immediate and username should go to a separate
one together?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 11 Jun 2010 08:09:44 -0700

I think username needs to be covered in the OpenID Connect spec (i.e. Identity layer on top of OAuth). Just a hint isn't enough. The client needs to be able to verify that the server response is what was asked, and also the server needs to inform the client of who logged in.

EHL

On 6/11/10 6:57 AM, "Marius Scurtescu" <[email-masked]> wrote:

Marius

---

From: Allen Tom <[email-masked]>
Date: Fri, 11 Jun 2010 08:59:22 -0700

Hi David,

Thanks a lot for writing this up! Some feedback:

1) If the user is required to enter their credentials (aka their password),
the UI must be displayed in an independent browser window (not in an inlined
iframe), with the address bar displayed. The AS must return framebusting JS
code to ensure that the login form is not iframed

2) It might be desirable to inline/lightbox the approval UI, if the user
already is logged into the AS and does not have to enter their password to
approve the request. In this case, the AS does not need to return
framebusting code, but should return anti-clickjacking code to protect the
approval button from being clickjacked

3) #2 implies that the client will have a way of determining if the user is
already logged into the AS before spawning either a popup window (if the
user is not logged in) or displaying an inline lightbox (if the user is
already logged in) An API similar to the OpenID openid.ui.mode=x-has-session
parameter or the FB.getLoginStatus() API is needed.

http://developers.facebook.com/docs/reference/javascript/FB.getLoginStatus
http://code.google.com/apis/accounts/docs/OpenID.html#Parameters

I'll be happy to contribute some of the text.

Thanks
Allen

---

From: David Recordon <[email-masked]>
Date: Fri, 11 Jun 2010 09:03:26 -0700

Cool, want to take a stab at the security considerations section of
this? #1 and #2 feel like they fit there.

I agree with #3 being nice, but without an API wouldn't you make an
immediate mode request, see that it failed, and then make a normal
request?

--David

---

From: Evan Gilbert <[email-masked]>
Date: Sun, 13 Jun 2010 03:07:03 -0700

The "immediate" parameter is can have unintended consequences without some
way to attach it to an existing user. Examples here:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter.

I'd prefer to link these two parameters (username and immediate) in one spec
- @David, this can be the User Experience Extension if you'd like, althought
my preference would probably be to move both to a separate doc.

On Fri, Jun 11, 2010 at 8:09 AM, Eran Hammer-Lahav <[email-masked]>wrote:

>  I think username needs to be covered in the OpenID Connect spec (i.e.
> Identity layer on top of OAuth). Just a hint isn’t enough. The client needs
> to be able to verify that the server response is what was asked, and also
> the server needs to inform the client of who logged in.
>
> EHL
>
>
>
> >> Since these are all extensions to the end-user endpoint, I'd suggest we
> move the 'immediate' parameter here as well.
> >>
> >>              <t hangText='immediate'>
> >>                <vspace />
> >>> From: David Recordon [mailto:[email-masked] <[email-masked]>
> ]
> suggestion and

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 13 Jun 2010 08:30:01 -0700

'username' moves OAuth into the identity realm, which is something the OpenID Connect proposal is going to address. I don't care if the immediate mode moves into the OpenID Connect proposal, but I am against moving username into the UX draft. As for yet another draft, I am not sure what its scope will be.

EHL

From: Evan Gilbert [mailto:[email-masked]]
Sent: Sunday, June 13, 2010 3:07 AM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu; [email-masked]; OAuth WG
Subject: Re: [OAUTH-WG] A display parameter for user authorization requests

The "immediate" parameter is can have unintended consequences without some way to attach it to an existing user. Examples here: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter.

I'd prefer to link these two parameters (username and immediate) in one spec - @David, this can be the User Experience Extension if you'd like, althought my preference would probably be to move both to a separate doc.

On Fri, Jun 11, 2010 at 8:09 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
I think username needs to be covered in the OpenID Connect spec (i.e. Identity layer on top of OAuth). Just a hint isn't enough. The client needs to be able to verify that the server response is what was asked, and also the server needs to inform the client of who logged in.

EHL

On 6/11/10 6:57 AM, "Marius Scurtescu" <[email-masked]<http://[email-masked]>> wrote:
There was discussion about a username hint parameter, in general this
is needed when immediate is used. Should username go to this UX
Extension, or rather immediate and username should go to a separate
one together?

Marius

On Thu, Jun 10, 2010 at 5:32 PM, David Recordon <[email-masked]<http://[email-masked]>> wrote:
> On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav <[email-masked]<http://[email-masked]>> wrote:
>>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom <[email-masked]<http://[email-masked]>> wrote:
>>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <[email-masked]<http://[email-masked]>>
>>> wrote:
>>> >
>>> > [email-masked]<http://[email-masked]>
> [email-masked]<http://[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth