2007-01-09 OpenID plug in fails to us an OpenID URI which "delegates" to another URI location eg:
Using the following code withing the </head> section of the html page
<link rel="openid.server" href="http://pip.verisignlabs.com/server" />
<link rel="openid2.provider" href="http://pip.verisignlabs.com/server" />
<meta http-equiv="X-XRDS-Location" content="http://pip.verisignlabs.com/user/markcross/yadisxrds" />
I have come across this several times before and it has been a simple problem of parsing the page.
3.1.1. Delegating Authentication
If the End User's host is not capable of running an Identity Provider, or the End User wishes to use one running on a different host, they will need to delegate their authentication. For example, if they want to use their website, http://www.example.com/
, as their Identifier, but don't have the means, or desire, to run an Identity Provider.
If they have a LiveJournal account (say, user "exampleuser"), and know that LiveJournal provides an OpenID Identity Provider and that it'll assert that they control the Identifier http://exampleuser.livejournal.com/
they would be able to delegate their authentication to LiveJournal's Identity Provider..
So, to use www.example.com as their Identifier, but have Consumers actually verify http://exampleuser.livejournal.com/
with the Identity Provider located at http://www.livejournal.com/openid/server.bml
, they'd add the following tags to the HEAD section of the HTML document returned when fetching their Identifier URL.
<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml">
<link rel="openid.delegate" href="http://exampleuser.livejournal.com/">
Now, when a Consumer sees that, it'll talk to http://www.livejournal.com/openid/server.bml
and ask if the End User is exampleuser.livejournal.com, never mentioning www.example.com anywhere on the wire.
The main advantage of this is that an End User can keep their Identifier over many years, even as services come and go; they'll just keep changing who they delegate to.