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 <e...@hueniverse.com>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" <mscurte...@google.com> 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 <record...@gmail.com> > wrote: > > +1 for moving immediate here as well. > > > > > > On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav <e...@hueniverse.com> > 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:record...@gmail.com <record...@gmail.com> > ] > >>> 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 <a...@yahoo-inc.com> > 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" <e...@hueniverse.com> > >>> 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 > >>> > OAuth@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/oauth > >>> > > >>> > > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
