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] >>> 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
