[Openid-specs-ab] LoginId hint

Dingwell, Robert A. bobd at mitre.org
Tue Sep 4 19:17:39 UTC 2012


Thanks,  I figured it may have needed some additional wording around the value attribute of a claim.  I didn't see anything there so I wasn't sure if there was something I may have been missing.  I do like the idea of standardizing on the semantics around the value attribute for any generic claim.

Rob

From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Tuesday, September 4, 2012 3:02 PM
To: Rob Dingwell <bobd at mitre.org<mailto:bobd at mitre.org>>
Cc: Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>>, "openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>" <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Subject: Re: [Openid-specs-ab] LoginId hint

In messages 2.1.2.1.2 you pass a value for the user_id.  The response MUST contain that user_id or an error.   If prompt is none then you get an error if they are not logged in.

There is no example with email in the spec but I expect that if we define the same semantics then the request object would like this:


{
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.org/cb",
 "scope": "openid profile",
 "state": "af0ifjsldkj",
 "userinfo":
   {
     "claims":
       {
         "name": {"essential": true},
         "nickname": null,
         "email": {"essential": true, "value": "ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>"},
         "email_verified": {"essential": true, "value": true},
         "picture": null
       }
   },
 "id_token":
   {
     "claims":
       {
        "auth_time": {"essential": true},
        "acr": { "values":["2"] }
       },
     "max_age": 86400
   }
}


If the Auth server can't return the essential claims with the values required that should return an error.
You could in principal do the same thing with any claim if we standardize the value parameter for requests.

The user_id claim in the id token doesn't require essential as it is always required by definition.

John B.

On 2012-09-04, at 3:47 PM, "Dingwell, Robert A." <bobd at mitre.org<mailto:bobd at mitre.org>> wrote:

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<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




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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120904/ecf7fbbf/attachment.html>


More information about the Openid-specs-ab mailing list