<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>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:</div><div><br></div><div><pre style="font-family: 'Courier New', Courier, monospace; font-size: small; text-align: left; padding: 4px; background-color: rgb(204, 204, 204); position: static; z-index: auto; ">{
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "<a href="https://client.example.org/cb">https://client.example.org/cb</a>",
"scope": "openid profile",
"state": "af0ifjsldkj",
"userinfo":
{
"claims":
{
"name": {"essential": true},
"nickname": null,
"email": {"essential": true, "value": "<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>"},
"email_verified": {"essential": true, "value": true},
"picture": null
}
},
"id_token":
{
"claims":
{
"auth_time": {"essential": true},
"acr": { "values":["2"] }
},
"max_age": 86400
}
}</pre><div><br></div><div><br></div><div><h3><font size="3"><span style="background-color: transparent; font-weight: normal;">If the Auth server can't return the essential claims with the values required that should return an error.</span></font></h3><div><font size="3"><span style="background-color: transparent; ">You could in principal do the same thing with any claim if we standardize the value parameter for requests.</span></font></div><div><font size="3"><span style="background-color: transparent; "><br></span></font></div><div><font size="3"><span style="background-color: transparent; ">The user_id claim in the id token doesn't require essential as it is always required by definition.</span></font></div><div><font size="3"><span style="background-color: transparent; "><br></span></font></div><div><font size="3"><span style="background-color: transparent; ">John B.</span></font></div><div><font size="3"><span style="background-color: transparent; "><br></span></font></div><div><div>On 2012-09-04, at 3:47 PM, "Dingwell, Robert A." <<a href="mailto:bobd@mitre.org">bobd@mitre.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">John,<br><br>Can you explain how to go about doing this as you stated. I've read<br>through the Request Object and claims portions a couple of times and I'm<br>not seeing it. I see where you can set that email is a required field<br>attribute to return but not something along the lines of, here is an email<br>address, make sure the user has this or don't return an id_token.<br><br>Rob<br><br><br>On 9/4/12 11:47 AM, "John Bradley" <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br><br><blockquote type="cite">You can also do that in the request object by setting the required value<br>of the email.<br><br><br>On 2012-09-04, at 12:18 PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br><br><blockquote type="cite">Blaine's use case is a bit different than the id_token case.<br>In the id_token case, the relying party already has the id_token<br>perhaps associated with the browser session. However, in Blaine's use<br>case, the use case of using a friend's computer, it is not the case.<br>The user obviously cannot supply the real verified identifier aka<br>id_token, and can only supply something like email. In his scenario,<br>the IdP should only return the positive assertion if the email<br>identifier associated with the user that logged in to the IdP includes<br>the email supplied. (Obviously, that email needs to be a verified<br>one.) So, the request being sent from the RP is essentially saying:<br><br>"give me id_token if and only if the user's verified emails includes<br>the supplied one."<br><br>Is that correct, Blaine?<br><br>Nat<br><br>On Tue, Sep 4, 2012 at 11:47 PM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br><blockquote type="cite">We have the only sign in this user_id in the request object already.<br><br>Perhaps we need clearer guidance to the IdP what they need to do in<br>that case.<br><br>This was intended for cases where you still want to let them login as<br>something else but want to have the IdP pre fill.<br><br>One thing to note is that there is no guaranteed mapping between a<br>email and a user_id.<br><br>John B.<br><br><br>On 2012-09-04, at 7:32 AM, Blaine Cook <<a href="mailto:romeda@gmail.com">romeda@gmail.com</a>> wrote:<br><br><blockquote type="cite">I'm very, very glad to see this being codified.<br><br>So, I know that it doesn't affect the security properties, and the<br>client will always need to verify that the requested user matches the<br>one that was / is expected, but rather than just a hint, would it be<br>possible for this parameter to semantically mean (on agreement between<br>a cooperating IdP and RP):<br><br>"Only sign in the user identified by user_id. If it's not possible to<br>sign in that user, please return an error."<br><br>Having this agreement would simplify the vast majority of interaction<br>design around sign in.<br><br>I've recorded a video that goes through the failure case of what<br>happens when we don't have this parameter:<br><br><a href="http://www.youtube.com/watch?v=t2MGLkB9xDw&feature=youtu.be">http://www.youtube.com/watch?v=t2MGLkB9xDw&feature=youtu.be</a><br><br>I hope that helps define this parameter. As I've said a number of<br>times before, I firmly believe that this parameter is the most<br>important one for OpenID Connect to be a viable tool.<br><br>b.<br><br><br>On 1 September 2012 09:43, Roland Hedberg <roland.hedberg@adm.umu.se><br>wrote:<br><blockquote type="cite">Nat Sakimura skrev 2012-08-31 01:54:<br><blockquote type="cite">I think we had similar discussion before and the result then was to<br>signify that it is a hint through the parameter name. I support<br>login_hint.<br></blockquote><br>+1<br><br>-- Roland<br><br>_______________________________________________<br>Openid-specs-ab mailing list<br>Openid-specs-ab@lists.openid.net<br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote>_______________________________________________<br>Openid-specs-ab mailing list<br>Openid-specs-ab@lists.openid.net<br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote><br><br>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br><br></blockquote><br><br><br>-- <br>Nat Sakimura (=nat)<br>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/">http://nat.sakimura.org/</a><br>@_nat_en<br></blockquote><br></blockquote><br></blockquote></div><br></div></div></body></html>