<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Sprechblasentext Zchn";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.E-MailFormatvorlage19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.SprechblasentextZchn
{mso-style-name:"Sprechblasentext Zchn";
mso-style-priority:99;
mso-style-link:Sprechblasentext;
font-family:"Tahoma","sans-serif";}
.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">Thanks!<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""> John Bradley [mailto:ve7jtb@ve7jtb.com]
<br>
<b>Gesendet:</b> Dienstag, 28. April 2015 15:40<br>
<b>An:</b> Lodderstedt, Torsten<br>
<b>Cc:</b> GONZALO FERNANDEZ RODRIGUEZ; Torsten Lodderstedt; openid-specs-mobile-profile@lists.openid.net<br>
<b>Betreff:</b> Re: [Openid-specs-mobile-profile] login_hint behaviour<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Yes,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Sorry I probably missed the !=.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If the session is interactive the user may be prompted to switch accounts based on the hint, but if they don’t they can authenticate with a different account, or use an existing session.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The Client always needs to check the response. There is no assumption that there is a one to one mapping of the hint to subject, hints may be reassigned etc.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The id_token hint is about the sub and that SHOULD return an error if the subs of the existing session or a new session doesn’t match. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The client MUST always check the sub in the response, as the request could be tampered with in the browser.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Someone probably had some use case that prevented the id_token_hint from being a MUST, but I don’t remember what it was off the top of my head.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Apr 28, 2015, at 8:54 AM, Lodderstedt, Torsten <<a href="mailto:t.lodderstedt@telekom.de">t.lodderstedt@telekom.de</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi John,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">so I probably got your earlier posting wrong.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I asked “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?”</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">You answered:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">“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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Clients sending users off to reauth need to be able to deal with the case of a different user coming back.”</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Now you are saying “login_hint is a hint to the IdP that can be ignored at the IdP’s discretion.”</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">My bottom line is: the OP may ignore the conflict and return the user id of the existing session to the client.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Correct?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">best regards,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Torsten.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Von:</span></b><span class="apple-converted-space"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> </span></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">John
Bradley [<a href="mailto:ve7jtb@ve7jtb.com">mailto:ve7jtb@ve7jtb.com</a>]<span class="apple-converted-space"> </span><br>
<b>Gesendet:</b><span class="apple-converted-space"> </span>Montag, 27. April 2015 17:33<br>
<b>An:</b><span class="apple-converted-space"> </span>Lodderstedt, Torsten<br>
<b>Cc:</b><span class="apple-converted-space"> </span>GONZALO FERNANDEZ RODRIGUEZ; Torsten Lodderstedt;
<a href="mailto:openid-specs-mobile-profile@lists.openid.net">openid-specs-mobile-profile@lists.openid.net</a><br>
<b>Betreff:</b><span class="apple-converted-space"> </span>Re: [Openid-specs-mobile-profile] login_hint behaviour</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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>
<br>
login_hint<br>
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>
<br>
In the case of id_token_hint.<br>
<br>
id_token_hint<br>
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>
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>
<br>
Because the sub is included in the id_token the IdP SHOULD return an error rather than a different sub.<br>
<br>
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>
(note that the same applies to SAML)<br>
<br>
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>
<br>
So login_hint is sufficiently specified, it just may not do what some people are looking for.<br>
<br>
Clearly id_token_hint can only be used after the person logs-in the first time.<br>
<br>
I think what you may be looking for is the claims request parameter (Sec 5.5) <br>
<br>
eg <br>
a claims request like this would return a phone_number claim in the id_token<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"> {<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> "id_token":<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> {<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> "auth_time": {"essential": true},<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> "acr": {"values": ["urn:moderna:iap:silver"] },<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> “phone_number”:{“value”:”+16045551212”,"essential": true}<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> }<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> }<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">You could also return it from the user_info endpoint as easily.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">You may also need to specify that “<span style="font-size:10.0pt;font-family:"Verdana","sans-serif";background:white">phone_number_verified”:</span> {“value”:true,"essential": true} .<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The IdP must return an error if the user doesn’t login to an account that can provide the correct claim. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The client still needs to validate the subject and or the claim value, as an attacker can modify the request. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">On Apr 27, 2015, at 5:42 AM, Lodderstedt, Torsten <<a href="mailto:t.lodderstedt@telekom.de"><span style="color:purple">t.lodderstedt@telekom.de</span></a>> wrote:<br>
<br>
Hi Gonzalo,<br>
<br>
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>
<br>
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>
<br>
Best regards,<br>
Torsten.<br>
<br>
Von: Openid-specs-mobile-profile [<a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net"><span style="color:purple">mailto:openid-specs-mobile-profile-bounces@lists.openid.net</span></a>] Im Auftrag von GONZALO FERNANDEZ RODRIGUEZ<br>
Gesendet: Montag, 27. April 2015 10:19<br>
An: GONZALO FERNANDEZ RODRIGUEZ; Torsten Lodderstedt; John Bradley<br>
Cc: <a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a><br>
Betreff: Re: [Openid-specs-mobile-profile] login_hint behaviour<br>
<br>
Even worse,<br>
<br>
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>
<br>
Best,<br>
Gonza.<br>
<br>
De: Gonzalo Fernandez Rodriguez <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com"><span style="color:purple">gonzalo.fernandezrodriguez@telefonica.com</span></a>><br>
Fecha: lunes 27 de abril de 2015 09:57<br>
Para: Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net"><span style="color:purple">torsten@lodderstedt.net</span></a>>, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com"><span style="color:purple">ve7jtb@ve7jtb.com</span></a>><br>
CC: "<a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a>" <<a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a>><br>
Asunto: Re: [Openid-specs-mobile-profile] login_hint behaviour<br>
<br>
Hi guys,<br>
<br>
Thanks a lot for your responses, I still have a doubt…., please consider next use case:<br>
<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span class="apple-tab-span"> </span><span class="apple-converted-space"> </span>• The "sub" value is supported as login_hint (is something that we were talking last week with Matthieu from Orange).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span class="apple-tab-span"> </span><span class="apple-converted-space"> </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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span class="apple-tab-span"> </span><span class="apple-converted-space"> </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)<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <br>
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>
<br>
Best,<br>
Gonza.<br>
<br>
De: Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net"><span style="color:purple">torsten@lodderstedt.net</span></a>><br>
Fecha: sábado 25 de abril de 2015 18:09<br>
Para: John Bradley <<a href="mailto:ve7jtb@ve7jtb.com"><span style="color:purple">ve7jtb@ve7jtb.com</span></a>><br>
CC: Gonzalo Fernandez Rodriguez <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com"><span style="color:purple">gonzalo.fernandezrodriguez@telefonica.com</span></a>>, "<a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a>"
<<a href="mailto:openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">openid-specs-mobile-profile@lists.openid.net</span></a>><br>
Asunto: Re: [Openid-specs-mobile-profile] login_hint behaviour<br>
<br>
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>
<br>
Am 25. April 2015 16:13:07 MESZ, schrieb John Bradley <<a href="mailto:ve7jtb@ve7jtb.com"><span style="color:purple">ve7jtb@ve7jtb.com</span></a>>:<br>
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>
<br>
Clients sending users off to reauth need to be able to deal with the case of a different user coming back. <br>
<br>
Sent from my iPhone<br>
<br>
On Apr 25, 2015, at 5:47 AM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net"><span style="color:purple">torsten@lodderstedt.net</span></a>> wrote:<br>
<br>
Hi John,<br>
<br>
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>
<br>
Best regards,<br>
Torsten.<br>
<br>
<br>
<br>
Am 24.04.2015 um 23:58 schrieb John Bradley <<a href="mailto:ve7jtb@ve7jtb.com"><span style="color:purple">ve7jtb@ve7jtb.com</span></a>>:<br>
<br>
Agreed.<br>
<br>
The exception would be in the prompt=none case where you can’t display a UI.<br>
<br>
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>
<br>
<br>
On Apr 24, 2015, at 5:17 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net"><span style="color:purple">torsten@lodderstedt.net</span></a>> wrote:<br>
<br>
Hi Gonzalo,<br>
<br>
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>
<br>
best regards,<br>
Torsten.<br>
<br>
Am 22.04.2015 um 13:38 schrieb GONZALO FERNANDEZ RODRIGUEZ:<br>
Hi guys,<br>
<br>
<br>
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>
<br>
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>
<br>
Best,<br>
Gonza.<br>
<br>
<br>
<br>
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>
<br>
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>
<br>
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>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
<a href="mailto:Openid-specs-mobile-profile@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile"><span style="color:purple">Openid-specs-mobile-profile@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</span></a><br>
<br>
_______________________________________________<br>
Openid-specs-mobile-profile mailing list<br>
<a href="mailto:Openid-specs-mobile-profile@lists.openid.net"><span style="color:purple">Openid-specs-mobile-profile@lists.openid.net</span></a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile"><span style="color:purple">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile</span></a><br>
<br>
<br>
<br>
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>
<br>
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>
<br>
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>
<br>
<br>
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>
<br>
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>
<br>
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<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>