[OpenID] Microsoft and OpenID Q&A

Claus Färber GMANE at faerber.muc.de
Tue Feb 27 12:15:00 UTC 2007

Josh Hoyt <josh at janrain.com> schrieb/wrote:
> Other than that, it's pretty much the same as it was.  Are these the
> things that you're worried about? Aside from Yadis support, most of
> the new things are not required, or can be implemented minimally (e.g.
> do not support any extensions, so don't muck with the extension
> namespaces)

> What is it about OpenID 2 that [...] is hard compared to OpenID 1?

Well, IMO there are several things that add complexity:

. Yadis requires an additional parser, an XML parser.
. Yadis adds several discovery methods: HTTP header, HTTP content
  negotiation, HTML http-equiv meta elements. (OpenID 1 only had one).
. XRIs requires special treatment at several steps.
. RPs must implement two different OpenID protocols (v1 and v2).

OpenID 1 is quite simple if you only want to authenticate the user:

1. Normalise the URI provided (i.e. prepend http://)
2. Download the document from the OpenID URI, find the OpenID provider.
3. Redirect the user there.
4. When the user comes back, set a cookie.

With v2, it gets much more complicated:

1. Check if the identifier is an XRI; normalise the identifier using
   different rules for URIs and XRIs.
2. If the identifier is an XRI, do XRI discovery (probably by
   downloading an XRDS document from an xri.net);
   if it's an URI, do Yadis/OpenID discovery:
   a. set the HTTP headers for the first HTTP request
   b. download the document and find the OpenID provider by:
      - checking if the document is a XRDS document
      - finding and downloading an XRDS document from the location given
        in a HTTP header or the HTML head.
      - looking for OpenID's HTML-based discovery
3. Redirect the user to the OpenID provider; use the protocol version
   identified in discovery.
4. When the user comes back, set a cookie.

Please note that additional complexity in the RP also increases the
probability that some RP implementors will get some aspects wrong. For
example, one RP might work with traditional URIs but get the XRI
resolution wrong. The result is bad user experience.


More information about the general mailing list