[Openid-specs-ab] LoginId hint

Dingwell, Robert A. bobd at mitre.org
Tue Sep 4 18:47:27 UTC 2012


John,

Can you explain how to go about doing this as you stated.  I've read
through the Request Object and claims portions a couple of times and I'm
not seeing it.  I see where you can set that email is a required field
attribute to return but not something along the lines of, here is an email
address, make sure the user has this or don't return an id_token.

Rob


On 9/4/12 11:47 AM, "John Bradley" <ve7jtb at ve7jtb.com> wrote:

>You can also do that in the request object by setting the required value
>of the email.
>
>
>On 2012-09-04, at 12:18 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> 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