[Openid-specs-ab] LoginId hint
Justin Richer
jricher at mitre.org
Thu Aug 30 18:22:29 UTC 2012
RPs shouldn't rely on the login_id having *any* effect on the IdP's
processing and MUST NOT have any expectations to the contrary. The
transaction could come back with a different user, it could come back
with a pseudonymous account, etc. The idea for this, as I understand it,
is just for the RP to provide a hint for better UX. It does nothing to
change the security profile.
-- Justin
On 08/30/2012 02:01 PM, Breno de Medeiros wrote:
>
>
>
> On Thu, Aug 30, 2012 at 11:00 AM, Richer, Justin P. <jricher at mitre.org
> <mailto:jricher at mitre.org>> wrote:
>
> As far as the spec is concerned, that's up to the IdP. A "Smart"
> IdP might prompt the user with something like:
>
> "You are logging in to site X who thinks you're Bob, but you're
> logged in as Alice. Click here to log in as Bob instead."
>
>
> Well, it might be useful to give RPs some expectations. For instance,
> RPs should be expecting the case where they supply a login_id but
> receive a session authenticated to a different user.
>
>
> -- Justin
>
> On Aug 30, 2012, at 1:52 PM, Breno de Medeiros wrote:
>
>> Consider the case where partners share a computer, or a user has
>> a personal account and a professional account with the same IDP.
>> If the currently logged-in user is different from the suggested
>> user via login_id, what are the expectations?
>>
>>
>> On Thu, Aug 30, 2012 at 7:55 AM, Justin Richer <jricher at mitre.org
>> <mailto:jricher at mitre.org>> wrote:
>>
>> Ryo,
>>
>> We talked about this on the call this morning. Right now,
>> we're saying that it's RECOMMENDED that they have the same
>> value, but it's not required. Since there are currently two
>> discovery setups (SWD and Webfinger/XRD) that use different
>> parameter names, it might be a moot point to try and match those.
>>
>> -- Justin
>>
>>
>> On 08/30/2012 01:28 AM, Ryo Ito wrote:
>>> Do the principal parameter at discovery request and login_id
>>> parameter have same value?
>>> If it is Yes, the unification of the parameter name or
>>> reference will help developers.
>>>
>>> Thanks,
>>> Ryo
>>>
>>> 2012/8/30 George Fletcher <gffletch at aol.com
>>> <mailto:gffletch at aol.com>>
>>>
>>> How about adding the following to section 2.1.2 of
>>> Messages... after the id_token parameter
>>>
>>> login_id
>>> OPTIONAL. A hint to the authorization service as to
>>> the login_id the user may use to authenticate (if
>>> necessary). This hint can be used by an RP if it first
>>> asks the user for their email address (or other
>>> identifier) and then wants to pass that value as a hint
>>> to the discovered authorization service.
>>>
>>> Thanks,
>>> George
>>>
>>> On 8/29/12 2:00 PM, Nat Sakimura wrote:
>>>> Hey, now I am getting the support!
>>>>
>>>> Could one of you provide the actual text proposal for it?
>>>>
>>>> =nat via iPhone
>>>>
>>>> On Aug 30, 2012, at 1:40 AM, Chuck Mortimore
>>>> <cmortimore at salesforce.com
>>>> <mailto:cmortimore at salesforce.com>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> - cmort
>>>>>
>>>>> On Aug 29, 2012, at 9:26 AM, "Pam Dingle"
>>>>> <pdingle at pingidentity.com
>>>>> <mailto:pdingle at pingidentity.com>> wrote:
>>>>>
>>>>>> +1 from me too - need this for account chooser, among
>>>>>> other things.
>>>>>>
>>>>>> On Wed, Aug 29, 2012 at 8:39 AM, Richer, Justin P.
>>>>>> <jricher at mitre.org <mailto:jricher at mitre.org>> wrote:
>>>>>>
>>>>>> +1, I've asked for this feature too.
>>>>>>
>>>>>> -- Justin
>>>>>>
>>>>>> On Aug 29, 2012, at 11:27 AM, George Fletcher wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We've run into a case where it would be nice to
>>>>>>> be able to pass into the /authorize endpoint a
>>>>>>> value to pre-fill the loginid field on the
>>>>>>> authentication UI. We allow for an id_token to
>>>>>>> be passed as a hint of the desired user, but
>>>>>>> this only works for an "already authenticated"
>>>>>>> use case.
>>>>>>>
>>>>>>> If we consider the Account Chooser case where
>>>>>>> what is stored is the user's email address, it
>>>>>>> would be nice to be able to start the identity
>>>>>>> federation flow passing that email address along
>>>>>>> to the IdP.
>>>>>>>
>>>>>>> Did I just miss support for this in the specs?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> George
>>>>>>> --
>>>>>>> Chief Architect AIM: gffletch
>>>>>>> Identity Services Engineering Work:george.fletcher at teamaol.com <mailto:george.fletcher at teamaol.com>
>>>>>>> AOL Inc. Home:gffletch at aol.com <mailto:gffletch at aol.com>
>>>>>>> Mobile:+1-703-462-3494 <tel:%2B1-703-462-3494> Blog:http://practicalid.blogspot.com <http://practicalid.blogspot.com/>
>>>>>>> Office:+1-703-265-2544 <tel:%2B1-703-265-2544> Twitter:http://twitter.com/gffletch
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> <mailto:Openid-specs-ab at lists.openid.net>
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> <mailto:Openid-specs-ab at lists.openid.net>
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Pamela Dingle* | Sr. Technical Architect
>>>>>> *Ping**Identity* | www.pingidentity.com
>>>>>> <http://www.pingidentity.com/>
>>>>>> - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>>> - - - - - - - - - - - - -
>>>>>> *O:* 303-999-5890 <tel:303-999-5890> *M:*
>>>>>> 303-999-5890 <tel:303-999-5890>
>>>>>> *Email:* pdingle at pingidentity.com
>>>>>> <mailto:pdingle at pingidentity.com>
>>>>>> - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>>> - - - - - - - - - - - - -
>>>>>> *Connect with Ping*
>>>>>> Twitter: @pingidentity
>>>>>> LinkedIn Group: Ping's Identity Cloud
>>>>>> Facebook.com/pingidentitypage
>>>>>> <http://Facebook.com/pingidentitypage>
>>>>>>
>>>>>> *Connect with me*
>>>>>> Twitter: @pamelarosiedee
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> <mailto:Openid-specs-ab at lists.openid.net>
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> <mailto:Openid-specs-ab at lists.openid.net>
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> <mailto:Openid-specs-ab at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>>
>>> --
>>> ====================
>>> Ryo Ito
>>> Email : ritou.06 at gmail.com <mailto:ritou.06 at gmail.com>
>>> ====================
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>> --
>> --Breno
>>
>
>
>
>
> --
> --Breno
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120830/4da474d5/attachment.html>
More information about the Openid-specs-ab
mailing list