<div dir="ltr">&gt;&gt;&nbsp;<span class="Apple-style-span" style="border-collapse: collapse; ">I&#39;m getting the feeling, at this juncture, that having an OpenID shim on top of a robust SAML (and assured hardware crypto) - with all that mature use case based modeling of the whole spectrum of issues- was a good move on my part. &nbsp;I do feel that XRI could play a much greater role on a &quot;business-class&quot; openid that it does today without losing the UCIness of OpenID; but I also believe hardly anyone agrees with me.</span><br>
<br><div>Actually, I think most SaaS vendors do agree with you. &nbsp;Google&#39;s primary experience as an RP is with our SaaS outsourcing service called GoogleAppsForYourDomain where we only use SAML, and there is a strong contract between Google and the payment customer who runs their own IDP. &nbsp;Other SaaS vendors like Salesforce.com have taken that approach, and it is working very well. &nbsp;So we definitely should learn from that.<div>
<br></div><div>However, irregardless of issues of &quot;user control&quot; and &quot;URL vs. E-mail identifiers,&quot; it is hard to use SAML to enable an IDP to support a new RP &quot;on-the-fly.&quot; &nbsp;It can be done, but the OpenID community has focused a lot more on that use case. &nbsp;Similarly, it is hard for an RP to use SAML to trust a new IDP &quot;on-the-fly.&quot; &nbsp;Again, it can be done with SAML, but the OpenID community has focused more on it.</div>
<div><br></div><div>So as the saying goes, &quot;Let&#39;s not let the perfect be the enemy of the good.&quot; &nbsp;Hopefully we can take the best of the experiences from the SAML community, with the hard work of the OpenID community, and develop a solution for federated login that is much better then what we have today, even if it is not perfect. &nbsp;We can then work to improve in areas like reducing E-mail SPAM and credit card fraud and phishing which look to be much harder problems.</div>
<div><br></div><div><br><div class="gmail_quote">On Wed, Sep 24, 2008 at 9:48 AM, Peter Williams <span dir="ltr">&lt;<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">One compromise I have discussed with some RPs is to establish a legal agreement between the RP and the IDP where the RP commits to erasing the old global E-mail address of the user if the IDP sends both the old E-mail address and a new RP-specific E-mail address.<br>

<br>
<br>
</div>Isn&#39;t this all very &quot;unUCI&quot;. Im supposed in OpenID culture to be picking my own OP (or &quot;be&quot; my own OP).<br>
<br>
If I reject that, Id have to look at OpenID through the prism of the design&#39;s/designers&#39; experience in trust modeling and managing open trading partner agreements (harkening back 30 years to EDI through PKI).<br>

<br>
I&#39;m getting the feeling, at this juncture, that having an OpenID shim on top of a robust SAML (and assured hardware crypto) - with all that mature use case based modeling of the whole spectrum of issues- was a good move on my part. &nbsp;I do feel that XRI could play a much greater role on a &quot;business-class&quot; openid that it does today without losing the UCIness of OpenID; but I also believe hardly anyone agrees with me.<br>

</blockquote></div><br></div></div></div>