In openID 1.0 there was a clear relationship between the input identifier and the resulting authentication.

If I delegate my openID to Linksafe eg:
I include in the html returned by a GET on httpL//thread-safe.net



If I log in and get a positive assertion I have proved the claim that I control the URL http://thread-safe.net.

In OpenID 2.0 things change sometimes:)

If I do the same thing with openID 2.0


The OP might do exactly the same thing in exactly the same way.

Going to the OP openid.claimed_id="http://thread-safe.net" and openid.identity="=thread-safe"

The OP could return both unchanged with a positive assertion. This results in the same proof we had in openID 1.0.

The OP may however choose to alter the openid.claimed_id and could return something like openid.claimed_id="https://linksafe.name/=thread-safe"

Changing the openid.claimed_id is something Yahoo for example is doing with there OP. The RP preforms discovery on the new openid.claimed_id and if the OP is authoritative for the URL according to the rules, the RP must ether use the new openid.claimed_id or reject the login.

In the case where the person is coming directly from there OP without first being redirected from the RP (Unsolicited positive assertion, Sec 11.2), there is no Input identifier that the RP knows about.

In the case where directed identity is requested by the RP by sending openid.identity="http://specs.openid.net/auth/2.0/identifier_select", the RP should be smart enough to know that the input identifier has nothing to do with the verified resource and should not be used for any purpose.

The question is what to do in the case of a solicited response.

Consider something like the Yahoo case. There endpoint ignores the incoming openid.identity and asks me to login to my, or anyones yahoo account for that matter.




The RP sends openid.claimed_id="http://thread-safe.net" and openid.identity="https://me.yahoo.com/ve7jtb"

If I choose https://me.yahoo.com/ve7jtb as my Yahoo openID, yahoo sends a positive assertion for openid.claimed_id="http://thread-safe.net/" and openid.identity="https://me.yahoo.com/ve7jtb".

The RP accepts it like any delegation and my primary key at the RP is http://thread-safe.net/

Consider now if I log into yahoo as jbradley and select https://me.yahoo.com/jbradley as my openID

openid.claimed_id="http://thread-safe.net/" and openid.identity="https://me.yahoo.com/jbradley" are retuned by Yahoo.

There is now no relation between my input identifier, my claimed_id and my authentication.

The openID 2.0 spec talks about what to do if the openid.claimed_id changes and how we re validate that. In this case the openid.claimed_id hasn't changed only the openid.identity is different.

Clearly I was a fool for delegating my ID to Yahoo without understanding the consequences.

I did find that Plaxo detected the modification of openid.identity and failed to reverify that Yahoo was authoritative.

Other sites we won't talk about. I need to verify that my failure at Plaxo was Michael correctly detecting something was wrong or some other error I might be able to overcome.

OpenID 2.0 adds some good and powerful features. However RP's and OP's need to understand the changes to the architecture.

I am just starting to look at Directed Identity issues for XRI and how a iName OP would support the new features.

=jbradley
PS I have changed my rel tags back on thread-safe.net so forget trying to get into my accounts using this:)