Hi John -<div><br></div><div>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?</div><div><br></div><div>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. </div>
<div><br></div><div>The downside is that the UX would suffer due to the extra round trip.</div><div><br></div><div>Allen</div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Mon, Oct 31, 2011 at 6:56 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">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;">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">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>