I'm not sure I follow the distinction you're making — what is the difference between "concept of integration with the user's session at the identity provider" and the "user's choice of identity provider"?<div>
<br></div><div>While the token/cookie stored via XAuth in the browser's localStorage may contain whatever information the identity/service provider wishes to include, my suspicion is that most IDPs and SPs will just indicate that a session exists at a particular provider.</div>
<div><br></div><div>Since many RPs already know or have some idea which IDPs or SPs they want to integrate with (or the types of services they're interested in), they just need to look in the list for matches and then offer them up to the user as familiar options.<br>
<br></div><div>I'd be interested in knowing more about your experience here — and what adoption pitfalls you've run into, and whether it's likely that the central service is likely to go away any time soon.</div>
<div><br></div><div>Chris</div><div><br><div class="gmail_quote">On Mon, Apr 19, 2010 at 12:14 PM, Nate Klingenstein <span dir="ltr"><<a href="mailto:ndk@internet2.edu">ndk@internet2.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Chris,<br>
<br>
Here's the final specification for one of the models you're referring to, the Discovery Service. It existed for many years prior to that as the "WAYF" -- "where are you from?" service, and it's the one with wide purchase in academia.<br>
<br>
<a href="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.html" target="_blank">http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.html</a><br>
<br>
The XAuth proposal seems also, on quick, distract glance, to have flavors of the "common domain cookie" in the original SAML specs, but that failed in deployment.<br>
<br>
But most of the technical distinctions appear to me to built around the concept of integration with the user's session at the identity provider. That would be radically different from what we've done thus far, which caches and maintains nothing more than the user's choice of identity provider; not even whether they're a legitimate user there.<br>
<br>
It appears to place an enormous amount of power and centralization into the hands of the XAuth service. We've always wanted the DS to be an independent, optional piece of infrastructure, not the central cog around which everything else rotates.<br>
<br>
Interested to learn more, to see whether my initial reading here is off.<br><font color="#888888">
Nate.</font><div><div></div><div class="h5"><br>
<br>
On Apr 19, 2010, at 6:24 PM, Chris Messina wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In fact, this model is widely used in academia and in Europe to simplify federated authentication.<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Chris Messina<br>Open Web Advocate, Google<br><br>Personal: <a href="http://factoryjoe.com">http://factoryjoe.com</a><br>Follow me on Buzz: <a href="http://buzz.google.com/chrismessina">http://buzz.google.com/chrismessina</a> <br>
...or Twitter: <a href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a> <br><br>This email is: [ ] shareable [X] ask first [ ] private<br>
</div>