<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
span.E-MailFormatvorlage18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">the semantics differs significantly in that the OP must ensure the identity passed in the id_token_hint is authenticated by the transaction whereas
 login_hint_token is just this, an hint. The result of the authentication transaction may another identity.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Can we relax the semantics of this parameter? I think it could be useful for other use cases as well, e.g. if a RP wants to preset the identity
 to a certain PPID (but does not want to enforce this particular identity).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Torsten.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Von:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces@lists.openid.net]
<b>Im Auftrag von </b>John Bradley<br>
<b>Gesendet:</b> Donnerstag, 3. Dezember 2015 16:20<br>
<b>An:</b> Openid-specs-mobile-profile<br>
<b>Betreff:</b> [Openid-specs-mobile-profile] login_hint_token format.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One possibility if we were to mandate the format to be encrypted JWT would be to use the existing id_token_hint parameter.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We would have the discovery service produce an encrypted (pseudo) id_token with no “sub” and the extra claims.  <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This is almost exactly what we have, but have been thinking that it would fit because it is not produced by the IdP. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On one hand using a different parameter name has little expense, on the other having two of something almost the same may be more confusing to developers.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The IdP already needs to support receiving encrypted id_tokens/JWT as the value of the parameter, so it would decrypt it and then look at the issuer to check the signature.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If the issuer is itself it is an id_token, if the issuer is the discovery service then it would know to take the extra parameter as the hint, rater then the sub.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thoughts.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif"">id_token_hint<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;background:white"><span style="font-family:"Verdana","sans-serif"">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. 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 </span><tt><span style="font-size:10.0pt;color:#003366">login_required</span></tt><span style="font-family:"Verdana","sans-serif"">.
 When possible, an </span><tt><span style="font-size:10.0pt;color:#003366">id_token_hint</span></tt><span style="font-family:"Verdana","sans-serif"">SHOULD be present when </span><tt><span style="font-size:10.0pt;color:#003366">prompt=none</span></tt><span style="font-family:"Verdana","sans-serif""> is
 used and an </span><tt><span style="font-size:10.0pt;color:#003366">invalid_request</span></tt><span style="font-family:"Verdana","sans-serif""> 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 </span><tt><span style="font-size:10.0pt;color:#003366">id_token_hint</span></tt><span style="font-family:"Verdana","sans-serif""> value.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;background:white"><span style="font-family:"Verdana","sans-serif"">If the ID Token received by the RP from the OP is encrypted, to use it as an </span><tt><span style="font-size:10.0pt;color:#003366">id_token_hint</span></tt><span style="font-family:"Verdana","sans-serif"">,
 the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as
 the </span><tt><span style="font-size:10.0pt;color:#003366">id_token_hint</span></tt><span style="font-family:"Verdana","sans-serif""> value.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>