<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;" class="">Well it MUST be consistent.<div class=""><br class=""></div><div class="">I think it was MUST in both places then there was a discussion that it is the responsibility of the client to check the sub in the returned id_token, so it may be better in some cases to have the IdP respond with a positive response for a diffrent sub rather than an error. </div><div class=""><br class=""></div><div class="">Saying both would be the worst of both worlds.</div><div class=""><br class=""></div><div class="">If we are certain that RP really validate the sub in prompt=none cases then SHOULD is fine. If clients are sloppy with that then having it a MUST is better as it will stop clients from mistakenly thinking that a positive response is fro the same user.</div><div class=""><br class=""></div><div class="">I think I was the one arguing for MUST at the time, but I tend to be conservative.</div><div class=""><br class=""></div><div class="">We must have missed the other reference when it was changed to SHOULD.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 7, 2015, at 8:10 AM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" class="">bcampbell@pingidentity.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><dl class=""><dt class="">Core has two mentions of id_token_hint (not counting self issued and IANA registration), which are quoted below. It seems that one says that an error SHOULD be returned if the end-user identified by the id_token_hint isn't the current user while the other says an error MUST be returned.</dt></dl><p class="">Is this an oversight that should maybe be fixed in errata v.next? <br class=""></p><p class="">Or is there something more subtle or intentional here?<br class=""></p><dl class=""><dt class=""><br class=""></dt><dt class=""><a href="http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest" class="">http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest</a></dt><dd class=""><br class=""></dd><dt class=""> id_token_hint</dt><dd class="">
OPTIONAL.
ID Token previously issued by the Authorization Server
being passed as a hint about the End-User's current or past
authenticated session with the Client.
<b class=""> If the End-User identified by the ID Token is logged in or is logged in by the request,
then the Authorization Server returns a positive response;
otherwise, it SHOULD return
an error, such as <tt class="">login_required</tt>.</b>
When possible, an <tt class="">id_token_hint</tt>
SHOULD be present when <tt class="">prompt=none</tt> is used
and an <tt class="">invalid_request</tt> error
MAY be returned if it is not;
however, the server SHOULD respond successfully when possible,
even if it is not present.
The Authorization Server need not be listed as an
audience of the ID Token when it is used as an
<tt class="">id_token_hint</tt> value.
</dd></dl><p class=""><br class=""></p><p class=""><a href="http://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation" class="">http://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation</a></p><p style="margin-left:40px" class="">If the <tt class="">sub</tt> (subject) Claim
is requested with a specific value for the ID Token,
the <b class="">Authorization Server MUST only send a positive response
if the End-User identified by that <tt class="">sub</tt> value
has an active session with the Authorization Server
or has been Authenticated as a result of the request.
The Authorization Server MUST NOT reply with an ID Token or
Access Token for a different user,</b>
even if they have an active session with the Authorization Server.
Such a request can be made either using an
<tt class="">id_token_hint</tt> parameter
or by requesting a specific Claim Value
as described in <a class="" href="http://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests">Section 5.5.1</a>,
if the <tt class="">claims</tt> parameter
is supported by the implementation.
</p><p class=""><br class=""></p></div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></body></html>