[Openid-specs-ab] LoginId hint

Nat Sakimura sakimura at gmail.com
Tue Sep 4 15:18:58 UTC 2012


Blaine's use case is a bit different than the id_token case.
In the id_token case, the relying party already has the id_token
perhaps associated with the browser session. However, in Blaine's use
case, the use case of using a friend's computer, it is not the case.
The user obviously cannot supply the real verified identifier aka
id_token, and can only supply something like email. In his scenario,
the IdP should only return the positive assertion if the email
identifier associated with the user that logged in to the IdP includes
the email supplied. (Obviously, that email needs to be a verified
one.) So, the request being sent from the RP is essentially saying:

"give me id_token if and only if the user's verified emails includes
the supplied one."

Is that correct, Blaine?

Nat

On Tue, Sep 4, 2012 at 11:47 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> We have the only sign in this  user_id  in the request object already.
>
> Perhaps we need clearer guidance to the IdP what they need to do in that case.
>
> This was intended for cases where you still want to let them login as something else but want to have the IdP pre fill.
>
> One thing to note is that there is no guaranteed mapping between a email and a user_id.
>
> John B.
>
>
> On 2012-09-04, at 7:32 AM, Blaine Cook <romeda at gmail.com> wrote:
>
>> I'm very, very glad to see this being codified.
>>
>> So, I know that it doesn't affect the security properties, and the
>> client will always need to verify that the requested user matches the
>> one that was / is expected, but rather than just a hint, would it be
>> possible for this parameter to semantically mean (on agreement between
>> a cooperating IdP and RP):
>>
>> "Only sign in the user identified by user_id. If it's not possible to
>> sign in that user, please return an error."
>>
>> Having this agreement would simplify the vast majority of interaction
>> design around sign in.
>>
>> I've recorded a video that goes through the failure case of what
>> happens when we don't have this parameter:
>>
>> http://www.youtube.com/watch?v=t2MGLkB9xDw&feature=youtu.be
>>
>> I hope that helps define this parameter. As I've said a number of
>> times before, I firmly believe that this parameter is the most
>> important one for OpenID Connect to be a viable tool.
>>
>> b.
>>
>>
>> On 1 September 2012 09:43, Roland Hedberg <roland.hedberg at adm.umu.se> wrote:
>>> Nat Sakimura skrev 2012-08-31 01:54:
>>>> I think we had similar discussion before and the result then was to
>>>> signify that it is a hint through the parameter name. I support login_hint.
>>>
>>> +1
>>>
>>> -- Roland
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> 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
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


More information about the Openid-specs-ab mailing list