<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The trick is passing on that hint to a arbitrary landing page at the RP.<div><br></div><div>I suspect the RP will need some sort of special landing page that takes a id_token and destination page.</div><div><br></div><div>I think it probably needs to be s signed hint/id_token to avoid clever XSRF attacks. The RP should be able to tell the request originated from the IdP in a safe way before bouncing them back in a iframe for the actual authentication.</div><div><br></div><div>John<br><div><div>On 2011-11-03, at 9:35 PM, Breno de Medeiros wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, Nov 3, 2011 at 17:24, Allen Tom <span dir="ltr"><<a href="mailto:allentomdude@gmail.com">allentomdude@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
OK, this seems to make sense.<div><br></div><div>The IdP can link directly to the the RP's service. If the user is not already logged into the RP, the RP can redirect the the user back to the IdP's authorization URL to authenticate the user - which is the same scenario as if the user had started off at the RP.</div>
<div><br></div><div>There are a couple minor gotchas, which might not matter: </div><div><br></div><div>1) It might be necessary for the IdP to include a hint about which IdP to use, if the landing page on the RP is linked to from multiple IdPs. For instance, if the RP is <a href="http://mail.example.com/" target="_blank">mail.example.com</a>, how is the RP supposed to know which IdP to send the user?</div>
<div><br></div><div>2) It's possible that the user is already logged into the RP, but as a different user than the user that's logged into the IdP - aka "the wrong user problem." Perhaps one solution would be for the IdP to pass along a user hint, and the RP can redirect the browser back to the IdP if the wrong user is logged in. </div>
<span class="HOEnZb"><font color="#888888">
<div><br></div></font></span></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><span class="HOEnZb"><font color="#888888"><div>
</div><div>Allen</div></font></span><div class="HOEnZb"><div class="h5"><div><br><br><div class="gmail_quote">On Thu, Nov 3, 2011 at 9:48 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Wed, Nov 2, 2011 at 21:39, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. is what Justin is talking about and is the way to go, IMHO. </blockquote><div><br></div></div><div>I agree. I think the IDP should simply redirect the user to a URL at the RP with a clue about what IDP should be used. The RP will then initiate the request. This is simpler to maintain (the IDP doesn't need to know what the RP wants to ask in requests, which can evolve over time) and better for security (the RP can implement other features such as XSRF protection to prevent assertion leakage).</div>
<div><div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>=nat<div><div><br><br><div class="gmail_quote">
On Thu, Nov 3, 2011 at 6:44 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">No, it will require some sort of extension.<div><br></div><div>A OAuth 2.0 response doesn't have enough information in it. </div>
<div>We are sending the id_token that dose have enough information in it.</div><div>However basic clients rely on the check_id endpoint. They don't have enough information to find it, without looking in the id_token.</div>
<div><br></div><div>Possible solutions are:</div><div>1. make every RP capable of directly inspecting the id_token, all they need to do is base64url decode the token body to find the issuer and lookup the check_id endpoint if they can't process signatures. </div>
<div>2. Add an additional response paramater of issuer to unsolicited assertions. </div><div>3. Add a special RP API to setup the login.</div><div><br></div><div>1&2 have the problem of working around the RP's XSRF protection, as well as the IdP knowing what client_id and return URL to use, they may change over time.</div>
<div><br></div><div>People weren't interested when I raised the issue the first time. I agree that we probably need to address this.</div><div><br></div><div>There are a bunch of issues that need to be considered.</div>
<div><br></div><div><br></div><div>John B.</div><div><div></div><div><div><br></div><div><br><div><div>On 2011-11-02, at 6:14 PM, Allen Tom wrote:</div><br><blockquote type="cite"><div>Hi John -</div><div><br></div>
<div>The scenario that I'm talking about is where the user starts on IdP's site in an authenticated state, and is presented with a list of links to services hosted on other sites. The user clicks on one of the links and is seamlessly logged into one of the services without having to re-authenticate.</div>
<div><br></div><div>So for example, imagine that the user is an employee and is authenticated into her work intranet portal. The portal has a link to check the user's mail, which is hosted on a different domain. The user should be able to click on the [check mail] link and be able to use the mail application without having to authenticate again.</div>
<div><br></div><div>This is a pretty common use case - many companies outsource corporate applications like mail, expense reports, calendaring, payroll, travel bookings, etc to 3rd parties. The user logs into their employer's corporate portal and should be able to click on the links to the different apps, without having to re-authenticate.</div>
<div><br></div><div>Does OpenID Connect have a solution for this use case?</div><div><br></div><div>Allen</div><div><br></div><div><br></div><div><br></div><br><br><div class="gmail_quote">On Tue, Nov 1, 2011 at 7:11 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Yes but that, can't be done with the existing OAuth flow in connect. The OAuth presumption is that the user is starting at the RP and the RP stores state about what IdP the user is going to.<div>
<br></div><div>There is not enough info in the authentication response alone for the RP to figure out where it came from.</div><div><br></div><div>We need an extension to OAuth that would start the flow from the IdP and send the extra info, as well as protecting against XSRF.</div>
<div><br></div><div>John<br><div><div>On 2011-11-01, at 2:21 AM, Harald Petersilka wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div lang="DE-AT" link="blue" vlink="purple">
<div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">Hi John,<u></u><u></u></span></div>
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><span style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"><u></u> <u></u></span></div>
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><span lang="EN-GB" style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">I was more thinking of a kind of dashboard located at an IdP where I can collect my OpenID sites and just have to click them to be logged in.<u></u><u></u></span></div>
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><span lang="EN-GB" style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">There I’d send the user to the RP with the already known OpenID as GET/POST parameter to initiate the common authentication procedure just without forcing the user to enter his OpenID every time.<u></u><u></u></span></div>
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><span lang="EN-GB" style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"><u></u> <u></u></span></div>
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><span lang="EN-GB" style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)">BG, Harry<u></u><u></u></span></div>
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><span lang="EN-GB" style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"><u></u> <u></u></span></div>
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><span lang="EN-GB" style="font-size:11pt;font-family:Calibri, sans-serif;color:rgb(31, 73, 125)"><u></u> <u></u></span></div>
<div><div style="border-right-style:none;border-bottom-style:none;border-left-style:none;border-width:initial;border-color:initial;border-top-style:solid;border-top-color:rgb(181, 196, 223);border-top-width:1pt;padding-top:3pt;padding-right:0cm;padding-bottom:0cm;padding-left:0cm">
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><b><span lang="DE" style="font-size:10pt;font-family:Tahoma, sans-serif">Von:</span></b><span lang="DE" style="font-size:10pt;font-family:Tahoma, sans-serif"><span> </span><a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>]<span> </span><b>Im Auftrag von<span> </span></b>John Bradley<br>
<b>Gesendet:</b><span> </span>Dienstag, 01. November 2011 01:32<br><b>An:</b><span> </span>Allen Tom<br><b>Cc:</b><span> </span><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Betreff:</b><span> </span>Re: [Openid-specs-ab] IdP initiated login<u></u><u></u></span></div></div></div><div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">I agree that the user needs to go back to the IdP. <u></u><u></u></div>
<div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
I was saying the first step of getting the user to the RP can't be OAuth, because it doesn't have enough info.<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">I was thinking that the IdP would need to have the user full frame and present some sort of dialog before sending the request to the RP.<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">Otherwise the attacker XSRFs the IdP to get to the RP.<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
You seem to have another use case where the attacker is cooperating with a bad IdP to log the user into a RP as some 4th party that the attacker controls?<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">John<u></u><u></u></div><div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
On 2011-10-31, at 9:22 PM, Allen Tom wrote:<u></u><u></u></div></div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><br><br>
<u></u><u></u></div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">Hi John -<u></u><u></u></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">I think that there's still an XRSF vulnerability even if the the IdP shows a dialog before generating the assertion.<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
The attacker could login to the IdP with the attacker's own account, then go through the flow to see the dialog. The attacker could then click through the dialog and capture the assertion (possibly using a browser extension, or modified client) and then send the assertion to a victim (possibly via IM or email) to have the victim be signed into the RP using the attacker's account.<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
This is why the RP needs to bounce the browser back to the OP to have the OP verify that the assertion was issued to the same browser before sending the browser back to the RP.<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">I used to think that Login XRSF was not a big deal (who cares if an attacker can get someone else to login as the attacker?) - however there are a few interesting scenarios where a victim could have their privacy compromised.<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
Allen<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
On Mon, Oct 31, 2011 at 5:10 PM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" style="color:blue;text-decoration:underline" target="_blank">ve7jtb@ve7jtb.com</a>> wrote:<u></u><u></u></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
If the IdP is not presenting a dialog then it leaves the user open to XSRF. <u></u><u></u></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">In a code flow you only get code and state from the IdP it is the RP's responsibility to figure out where it came from, so that wouldn't work.<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">If you used the Token flow the RP would need to look into the id_token to see where it came from. <u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">That would be a problem for simple clients, because they need the introspection endpoint, and to get that they need to get the issuer from inside the token.<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
I think we need a separate API that takes as its parameters:<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
issuer<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"> nonce<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
hmac of issuer & nonce with client secret.<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">That way the RP can tell that the IdP is sending the request and not a 3rd party.<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
The RP would do a normal authentication with prompt=none to the issuer.<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">There is a extra hop.<u></u><u></u></div></div>
<div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
We need to identify & authenticate the issuer/IdP somehow in the first step.<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">John B.<u></u><u></u></div></div><div><div><div>
<div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
On 2011-10-31, at 5:42 PM, Allen Tom wrote:<u></u><u></u></div></div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><br><br>
<u></u><u></u></div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">Hi John -<u></u><u></u></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">Is this the Unsolicited Assertion use case - where the user clicks on a sponsored link hosted on the IdP's site and gets authenticated on the RP's site?<u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
I think we had discussed this at IIW a couple years ago, and the general consensus was that upon receiving an unsolicited positive assertion, the RP would need to redirect the user's browser back to the OP to have the OP re-generate the assertion and resend it back to the RP. <u></u><u></u></div>
</div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
The downside is that the UX would suffer due to the extra round trip.<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">Allen<u></u><u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div><div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
On Mon, Oct 31, 2011 at 6:56 AM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" style="color:blue;text-decoration:underline" target="_blank">ve7jtb@ve7jtb.com</a>> wrote:<u></u><u></u></div><p class="MsoNormal" style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:12pt;font-size:12pt;font-family:'Times New Roman', serif">
Just a note on a possible idea.<br><br>The when the RP registers a client ID it sets unsolicited_login_url: to some return_url<br><br>The IdP then sends the id_token with nonce set to a time stamp + entropy , and a claim of idp_initiated: true .<br>
<br>We probably need to restrict this to the code flow.<br><br>RP could then check that the id_token was not generated by XSRF and set it's cookies.<br><br>I don't see a general way that a unmodified RP is going to be able to safely.<br>
<br>This should probably be an extension.<br><br>John B.<br>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" style="color:blue;text-decoration:underline" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color:blue;text-decoration:underline" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></p></div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
<u></u> <u></u></div></div></div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div></div></div></div>
</div><div style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif"><u></u> <u></u></div></div></div><p class="MsoNormal" style="margin-top:0cm;margin-right:0cm;margin-left:0cm;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman', serif">
</p></div></div></div></div></div></span></blockquote></div><br></div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div><br>
</font></span></div>
<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>--Breno<br>
</font></span><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>--Breno<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>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>