[Openid-specs-ab] LoginId hint

[John Bradley]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4937 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120904/3565e494/attachment.p7s>