-
Recent Posts
Categories
-
Recent Comments
- WordPress 2.8 Tips and Tricks Collection | Fresh News - Blog Design, Wordpress, Blogger, and Web Development on Authentication in WordPress 2.8
- Building the user-centered web | Ben Werdmuller on The Open Stack (in PHP)
- ??? » Blog Archive » WordPress 2.8?? for ???? on Authentication in WordPress 2.8
- Stefan on git: Duplicate Signed-off-by lines
- WordPress 2.8 Beta RC1 | Fresh News - Blog Design, Wordpress, Blogger, and Web Development on Authentication in WordPress 2.8
Comparison of Support among OpenID Providers
This table shows the varying degrees of support by a few OpenID providers, both in terms of OpenID discovery and the OpenID protocols themselves. A detailed explanation of each is available below the table. The small “x” link next to each provider is the OpenID URL I used for testing. If any providers would like to be added to the list, please let me know.
Table Last Updated: Wed, 10 Jun 2009 01:14:24 -0700
Protocol Tests
Discovery Support
Discovery is the process by which a website advertises that it can be used as an OpenID Identifier, and in turn how OpenID consumers detect that information. The information can be embedded directly into the site’s HTML code, or in a separate metadata document. OpenID providers need not support every possible discovery method, but since many OpenID consumers only attempt discovery using a subset of the methods, it’s good to support as many as possible.
The metadata document for the Identifier can be retrieved using HTTP content negotiation by sending the following header in the request:
The URL for the metadata document is advertised in the HTTP response using the following response header:
The URL for the metadata document is advertised in the site’s HTML code using the following meta tag:
Identical to xrds-html, but using an older version of the http-equiv value:
The OpenID server and delegate are advertised in the site’s HTML code using the following to link tags. If the delegate tag is omitted, the URL of the page itself is used.
Identical to openid-html but uses rel values that indicate support for OpenID version 2.0.
OpenID Protocol Support
As OpenID has matured over the years, multiple versions of the specification have been published. OpenID providers can advertise their support for different OpenID versions using any of the discovery methods above.
In addition, several specifications have been published which extend the functionality of OpenID. All of the OpenID extensions to date must be advertised in the metadata document for the OpenID Identifier.
It is important to note that this table only reflects which OpenID protocol versions and extensions are advertised by the OpenID provider. No attempt has been made to test the actual functionality of these protocols. That being said, it has been my experience OpenID providers do in fact support the protocols advertised.
The OpenID provider supports OpenID Authentication 1.0. OpenID 1.0 is wire-compatible with OpenID 1.1. Support for OpenID 1.0 is advertised by the following Service Type URL in the metadata document.
The OpenID provider supports OpenID Authentication 1.1.
Support for OpenID 1.1 is advertised in the site’s HTML or by the following Service Type URL in the metadata document.
The OpenID provider supports OpenID Authentication 2.0.
OpenID 2.0 is not compatible with OpenID 1.x, though many providers support both protocols simultaneously.
Support for OpenID 2.0 is advertised in the site’s HTML or by the following Service Type URL in the metadata document.
The OpenID provider supports Simple Registration 1.0.
Support is advertised by the following Service Type URL in the metadata document.
The OpenID provider supports Simple Registration 1.1.
Support is advertised by the following Service Type URL in the metadata document.
The OpenID provider supports Attribute Exchange 1.0.
Support is advertised by the following Service Type URL in the metadata document.
The OpenID provider supports one or more of the authentication policies defined in Provider Authentication Policy Extension 1.0.
Support for each authentication policy is advertised individually in the metadata document.
Support for “phishing resistant” is advertised using the following Service Type URL.
Support for “multi-factor authentication” is advertised using the following Service Type URL.
Support for “physical multi-factor authentication” is advertised using the following Service Type URL.