<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; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>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.</div>
<div><br>
</div>
<div>Rob</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, September 4, 2012 3:02 PM<br>
<span style="font-weight:bold">To: </span>Rob Dingwell <<a href="mailto:bobd@mitre.org">bobd@mitre.org</a>><br>
<span style="font-weight:bold">Cc: </span>Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>>, "<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>" <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openid-specs-ab] LoginId hint<br>
</div>
<div><br>
</div>
<div>
<div 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 <<a href="mailto:roland.hedberg@adm.umu.se">roland.hedberg@adm.umu.se</a>><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>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><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>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><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>
</div>
</div>
</span>
</body>
</html>