<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The names are relatively clear.  login_hint is a hint to the IdP that can be ignored at the IdP’s discretion.   The IdP could refuse to let the user login but that generally is not considered a good user experience.<br class=""><br class="">login_hint<br class="">OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.<br class=""><br class="">In the case of id_token_hint.<br class=""><br class="">id_token_hint<br 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. 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 login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request 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 id_token_hint value.<br class="">If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, 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 id_token_hint value.<br class=""><br class="">Because the sub is included in the id_token the IdP SHOULD return an error rather than a different sub.<br class=""><br class="">Remember that unless you are using a signed request tied to the session the user can always tamper with the request.   It is never safe for the client to assume that the sub or hint it asks for is what it gets back.   That leads to real security problems.<br class="">(note that the same applies to SAML)<br class=""><br class="">If you are using a request object you can ask for a response that must contain a claim that contains a particular value for “sub”, email or phone.<br class=""><br class="">So login_hint is sufficiently specified, it just may not do what some people are looking for.<br class=""><br class="">Clearly id_token_hint can only be used after the person logs-in the first time.<br class=""><br class="">I think what you may be looking for is the claims request parameter (Sec 5.5) <br class=""><br class="">eg <br class="">a claims request like this would return a phone_number claim in the id_token<br class=""><br class=""><div class=""> {</div><div class="">   "id_token":</div><div class="">    {</div><div class="">     "auth_time": {"essential": true},</div><div class="">     "acr": {"values": ["urn:moderna:iap:silver"] },</div>     “phone_number”:{“value”:”+16045551212”,"essential": true}<div class="">    }</div><div class="">  }</div><div class=""><br class=""></div>You could also return it from the user_info endpoint as easily.<div class=""><br class=""></div><div style="widows: 1;" class="">You may also need to specify that “<span style="widows: 1; background-color: rgb(255, 255, 255);" class=""><font face="verdana, charcoal, helvetica, arial, sans-serif" size="2" class="">phone_number_verified”:</font></span> {“value”:true,"essential": true} .</div><div style="widows: 1;" class=""><br class=""></div><div style="widows: 1;" class="">I note in the bank case if the bank is sending an encrypted login hint then by design it doesn’t know the misden in the hint (otherwise there would be no point in encrypting it), so it can’t know if the user entered a different misden at the IdP.    That is the privacy goal.</div><div style="widows: 1;" class=""><br class=""></div><div style="widows: 1;" class="">If the bank has the users phone number on file to use as a second factor then it should use the direct API interface to get the issuer like a mobile app would do.  </div><div style="widows: 1;" class="">The user logs in with there first factor and the bank looks up the number to use and sends it in the claims request, and as the login_hint.</div><div style="widows: 1;" class=""><br class=""></div><div style="widows: 1;" class="">The IdP must return an error if the user doesn’t login to an account that can provide the correct claim. </div><div style="widows: 1;" class=""><br class=""></div><div style="widows: 1;" class="">The client still needs to validate the subject and or the claim value, as an attacker can modify the request. </div><div style="widows: 1;" class=""><br class=""></div><div style="widows: 1;" class="">This did happen to some openid 2 RP who were using email addressees at google and not properly verifying the response and assuming that it was what they requested.</div><div style="widows: 1;" class=""><br class=""></div><div style="widows: 1;" class="">The attacker modified the request in the browser to change it to an account they controlled,  logged in and the RP gets a positive response but didn’t check the value of the email returned.   </div><div style="widows: 1;" class=""><br class=""></div><div style="widows: 1;" class=""><br class=""></div><div style="widows: 1;" class="">John B.</div><div style="widows: 1;" class=""><br class=""></div><div class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 27, 2015, at 5:42 AM, Lodderstedt, Torsten <<a href="mailto:t.lodderstedt@telekom.de" class="">t.lodderstedt@telekom.de</a>> wrote:<br class=""><br class="">Hi Gonzalo,<br class=""> <br class="">it seems to me the semantics of login_hint is not sufficiently enough specified in the core spec. That’s why I asked John for advice. I would recommend we reach out to the OpenID Connect WG and ask for clarification.<br class=""> <br class="">Regarding sub/enc login hint: the OpenID Connect core specification neither supports sub nor encrypted login hints. If there is a need to define a respective extension, we should do so. We already had discussions regarding the encrypted login hint and came up with the idea of a new parameter carrying a JWT containing the MSISDN (or whatever is needed) to the OP. That could be a sub as well. Based on a discussion w/ Vodafone we had in the context of the German Trial last week, we (DT&VF) see the need for sub as hint as well.<br class=""> <br class="">Best regards,<br class="">Torsten.<br class=""> <br class="">Von: Openid-specs-mobile-profile [<a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net" class="">mailto:openid-specs-mobile-profile-bounces@lists.openid.net</a>] Im Auftrag von GONZALO FERNANDEZ RODRIGUEZ<br class="">Gesendet: Montag, 27. April 2015 10:19<br class="">An: GONZALO FERNANDEZ RODRIGUEZ; Torsten Lodderstedt; John Bradley<br class="">Cc: <a href="mailto:openid-specs-mobile-profile@lists.openid.net" class="">openid-specs-mobile-profile@lists.openid.net</a><br class="">Betreff: Re: [Openid-specs-mobile-profile] login_hint behaviour<br class=""> <br class="">Even worse,<br class=""> <br class="">If the Bank (Service Provider) sends an MSISDN or an encrypted MSISDN (the first time) as login_hint and the OIDC provider prompts the user to enter an MSISDN and he introduces another one, the Service Provider will receive a "sub" that not correspond with the MSISDN that it has.<br class=""> <br class="">Best,<br class="">Gonza.<br class=""> <br class="">De: Gonzalo Fernandez Rodriguez <gonzalo.fernandezrodriguez@telefonica.com><br class="">Fecha: lunes 27 de abril de 2015 09:57<br class="">Para: Torsten Lodderstedt <torsten@lodderstedt.net>, John Bradley <ve7jtb@ve7jtb.com><br class="">CC: "openid-specs-mobile-profile@lists.openid.net" <openid-specs-mobile-profile@lists.openid.net><br class="">Asunto: Re: [Openid-specs-mobile-profile] login_hint behaviour<br class=""> <br class="">Hi guys,<br class=""> <br class="">Thanks a lot for your responses, I still have a doubt…., please consider next use case:<br class=""> <br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The "sub" value is supported as login_hint (is something that we were talking last week with Matthieu from Orange).<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">      </span>• A Service Provider use Mobile Connect as a 2nd factor authentication. The Service Provider already know who the user is, probably he/she has been authenticated using another credentials, (banks use case). It sends the login_hint of the user to re-authenticate him to authorize a transaction for example.<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">       </span>• The OIDC provider is not able to realize who the user is (it doens't support this kind of login_hint, or another reason)<br class=""></div> <br class="">If the OIDC prompts the user to enter the MSISDN and he introduces one that is different from the expected with the login_hint provided in the authentication request, the Service Provider will receive a "sub" different from the expected. Could this use case be possible?<br class=""> <br class="">Best,<br class="">Gonza.<br class=""> <br class="">De: Torsten Lodderstedt <torsten@lodderstedt.net><br class="">Fecha: sábado 25 de abril de 2015 18:09<br class="">Para: John Bradley <ve7jtb@ve7jtb.com><br class="">CC: Gonzalo Fernandez Rodriguez <gonzalo.fernandezrodriguez@telefonica.com>, "openid-specs-mobile-profile@lists.openid.net" <openid-specs-mobile-profile@lists.openid.net><br class="">Asunto: Re: [Openid-specs-mobile-profile] login_hint behaviour<br class=""> <br class="">So far and in contrast to id token hint, I interpreted the login hint as "nice to have but not a strong requirement". The semantics you describe is much stronger. I was unable to find a text in the spec describing the use case we are discussing. Can you refer to some text?<br class=""><br class="">Am 25. April 2015 16:13:07 MESZ, schrieb John Bradley <ve7jtb@ve7jtb.com>:<br class="">Sending an error that authentication is needed.  The client needs to retry without prompt=none so the user can sort it out at the AS. <br class=""> <br class="">Clients sending users off to reauth need to be able to deal with the case of a different user coming back. <br class=""><br class="">Sent from my iPhone<br class=""><br class="">On Apr 25, 2015, at 5:47 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:<br class=""><br class="">Hi John,<br class=""> <br class="">what behavior would you expect if the user id in the login hint conflicts with the user id of the existing session and prompt != none?<br class=""> <br class="">Best regards,<br class="">Torsten.<br class=""><br class=""><br class=""><br class="">Am 24.04.2015 um 23:58 schrieb John Bradley <ve7jtb@ve7jtb.com>:<br class=""><br class="">Agreed.<br class=""> <br class="">The exception would be in the prompt=none case where you can’t display a UI.<br class=""> <br class="">If the login hint or id_token hint is for a different account than the one with the current session you would need to return a error that authentication is required.<br class=""> <br class=""> <br class="">On Apr 24, 2015, at 5:17 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:<br class=""> <br class="">Hi Gonzalo,<br class=""><br class="">I would suggest to ignore invalid login_hint values and prompt the user again. As the parameter name suggests, it is just a hint.<br class=""><br class="">best regards,<br class="">Torsten.<br class=""><br class="">Am 22.04.2015 um 13:38 schrieb GONZALO FERNANDEZ RODRIGUEZ:<br class="">Hi guys,<br class=""> <br class=""> <br class="">We are testing our IDGW and we have a doubt about the behaviour that it should be have regarding the authentication in case of a login_hint is provided in the authentication request. Anyone of you can help us in this topic?<br class=""> <br class="">If the MNO is not able to resolve who is the user which the login_hint refers to, what should it do? Return an error or prompt the user to introduce its MSISDN?. In case of asking the user for its MSISDN it could happen that the MSISDN is not the same as the one referred by the login_hint (from the Service Provider side).<br class=""> <br class="">Best,<br class="">Gonza.<br class=""> <br class=""> <br class=""><br class="">Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.<br class=""><br class="">The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.<br class=""><br class="">Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">Openid-specs-mobile-profile mailing list<br class="">Openid-specs-mobile-profile@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile<br class=""> <br class="">_______________________________________________<br class="">Openid-specs-mobile-profile mailing list<br class="">Openid-specs-mobile-profile@lists.openid.net<br class="">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile<br class=""> <br class=""> <br class=""><br class="">Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.<br class=""><br class="">The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.<br class=""><br class="">Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição<br class=""> <br class=""><br class="">Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.<br class=""><br class="">The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.<br class=""><br class="">Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição<br class=""></blockquote><br class=""></div></body></html>