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 On Fri, Jun 11, 2010 at 8:59 AM, Allen Tom <[email protected]> wrote: > 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 > > > > On 6/10/10 9:13 PM, "David Recordon" <[email protected]> wrote: > >> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-ux-0 >> 1.txt >> >> >> On Thu, Jun 10, 2010 at 5:32 PM, David Recordon <[email protected]> wrote: >>> +1 for moving immediate here as well. >>> >>> >>> On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav <[email protected]> >>> wrote: >>>> 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 protected]] >>>>> 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 >>>>> >>>>> 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 protected]> 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/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. >>>>>> >>>>>> BCP 47: http://tools.ietf.org/html/bcp47 >>>>>> >>>>>> Allen >>>>>> >>>>>> >>>>>> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <[email protected]> >>>>> 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 protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>> >>> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
