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
