[OpenID] New OpenID Customer Research Activity - Google research on federated login
Eric Sachs
esachs at google.com
Wed Sep 24 17:48:50 UTC 2008
>> I'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. I do feel that XRI could play a much greater role on a
"business-class" openid that it does today without losing the UCIness of
OpenID; but I also believe hardly anyone agrees with me.
Actually, I think most SaaS vendors do agree with you. Google'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.
Other SaaS vendors like Salesforce.com have taken that approach, and it is
working very well. So we definitely should learn from that.
However, irregardless of issues of "user control" and "URL vs. E-mail
identifiers," it is hard to use SAML to enable an IDP to support a new RP
"on-the-fly." It can be done, but the OpenID community has focused a lot
more on that use case. Similarly, it is hard for an RP to use SAML to trust
a new IDP "on-the-fly." Again, it can be done with SAML, but the OpenID
community has focused more on it.
So as the saying goes, "Let's not let the perfect be the enemy of the good."
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. 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.
On Wed, Sep 24, 2008 at 9:48 AM, Peter Williams <pwilliams at rapattoni.com>wrote:
> 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.
>
>
> Isn't this all very "unUCI". Im supposed in OpenID culture to be picking my
> own OP (or "be" my own OP).
>
> If I reject that, Id have to look at OpenID through the prism of the
> design's/designers' experience in trust modeling and managing open trading
> partner agreements (harkening back 30 years to EDI through PKI).
>
> I'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. I do feel that XRI could play a much greater role on a
> "business-class" openid that it does today without losing the UCIness of
> OpenID; but I also believe hardly anyone agrees with me.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080924/c51049ad/attachment-0001.htm>
More information about the general
mailing list