[OpenID] About Facebook, MySpace and OpenID

Breno de Medeiros breno at google.com
Fri Apr 3 18:31:41 UTC 2009

On Fri, Apr 3, 2009 at 11:12 AM, John Bradley <john.bradley at wingaa.com>wrote:

> Believe me almost nothing is stranger than me defending MySpace.
> However I think they have done a reasonable job with there OP.
> They are compliant with openID 2.0,  true some older RP libs may have a
> problem if they are not compliant.
> If a openID 2.0 RP can't do a authentication at the MySpace OP it is
> broken!
> The exception to that would be MS health Vault or other sites that by
> policy don't allow non SSL connections or require PAPE multi factor etc.
> Those are policy decisions by the RP, and are not the OPs responsibility.
> OpenID 2.0 authentications can be performed without associations,
> Associations are a performance optimization not a security feature.
> If I were MySpace I would have made a SSL OP URI available rather than the
> http one.
> That would have broken a larger but different set of RPs that don't support
> SSL.
> The choice from an OP point of view is, use SSL and exclude all non SSL RPs
> or have a non SSL URI and prevent RPs that don't support DH from
> associating, but they can still authenticate in dumb/stateless mode.
> You can have two endpoints and the RP gets to select the SSL version if it
> supports SSL.
> That seems like a good idea,  but the RP's who have a discovery lib that
> can recognize URI priority in the XRDS and fail over properly are not the
> ones who have the problem.    This is the technically correct solution but
> probably breaks more RPs than it helps.
> To have SSL be useful it needs to protect the meta-data discovery step.  If
> I can replace your XRDS/or HTML tags at the RP, I own you!   Securing the
> rest of the transaction with SSL is as useful as locking your windows and
> leaving the front door open.
> So if I am MySpace or any other large provider the cost of making all of my
> user profile pages SSL could run into the millions of dollars.   I would
> probably think twice about it myself if I were them.
> The choice MySpace made is reasonable.
> No this is not hopeless.  The XRI-TC which now includes representation from
> Google, Yahoo and others is working on a trust model for signing XRD/S
> documents.   This will be part of the upcoming XRD 1.0 spec and may find its
> way into an openID >= 2.1 near you at some point in the future.
> Yes MySpace could include Sreg or better yet AX.   Given that to my
> knowledge we have one OP that hands out an validated email address in AX
> (that is still beta, and bends the AX spec),  so I wouldn't say MySpace is
> holding things up.
> We have a way to ask for an email address as an optional claim in AX,  a RP
> needs a white list of OP's it trusts have verified it, or round trip the
> email if the OP is not on the validated e-mail white list, and they care.
> What OPs need to do:
> Vidoop:  Nothing works now
> MyOpenID:  Get with the program and support the standard claim URI.,
> otherwise it would work now.
> Google:  Stop ignoring AX requests that are not marked required.   The word
> doesn't revolve around you.

Well, should the world revolve around the users? They keep telling anyone
who would listen that they don't like checkboxes.  Checkboxes are also
terrible for accessibility.

Suggestions appreciated.

> MySpace: Support AX please
> AOL:  Support openID 2.0 + AX
> Yahoo:  Support AX
> OP's have had the specs and tools to do this for a long time now.  It is
> not like we need to invent something new.
> Lets get what we have working well,  please.
> Regards
> John Bradley
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general


+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090403/b24457ba/attachment-0002.htm>

More information about the general mailing list