~ Consideration for the next version of OpenID ~
HTTP based OpenID is insecure. We should not use it.
HTTPS based one is much better, but still has problems.
Consider the following case.
Case:
There are two companies, ABC Inc, and XYZ Corp. Both of them are Japanese and have .co.jp domains.
Let these domains be abc.co.jp and xyz.co.jp respectively.
These companies were each providing OpenID in their respective domains for their members.
Consider the case that ABC Inc. and XYZ Corp. merged.
By the rules for .co.jp domain, the merged company can keep only one .co.jp domain.
Let this be xyz.co.jp. Thus, abc.co.jp was released for reuse.
Note that under this circumstances, it is impossible to redirect from abc.co.jp to xyz.co.jp anymore.
Thus, we face a problem that stems from the fact the a domain name cannot be persistent in some cases.
Problem 1: (OpenID Migration at RPs)
Since abc.co.jp is transferring its users to xyz.co.jp, and the OpenID that they were issuing was domain based,
there needs to be mechanism to migrate those disappearing abc.co.jp based OpenID to xyz.co.jp based one.
Unfortunately, there is no method defined to achieve this, and currently it is impossible to do so in a standardized manner.
This result in either or both of the following two corollary problems:
Problem 2: (RP account loss)
Since the users of abc.co.jp based OpenID loses his OpenID, he will become unable to access the RPs that he had been using unless the RP provides an ability to associate multiple OpenID to a local account, or a way for the migration. Neither of them are defined in the spec.
Problem 3: (RP Account impersonation, aka OpenID reuse)
Since abc.co.jp is assigned to a new company, it is entirely possible that the same OpenID including a fragment is assigned to somebody else.
A malicious party may actually launch this kind of attack by establishing a new company and obtaining abc.co.jp for this particular purpose.
The root of the problem seems to stem from the very fact that domain is not persistent.
This means we must not be using domain name based identifier as the claimed_id securely.
Solution:
The solution to this problem would be to use a non-domain based unique persistent identifier
which allows the parties to prove the ownership of it as claimed_id. i.e., we have to be using an identifier that are:
P1. Persistent
P2. Globally unique
P3. Easy to find out if it is a legitimate one (i.e., it should be easy to find out if somebody else uses it as his identifier.)
Candidate 1: (Public Key)
One can use his public key as the claimed identifier.
It can trivially fulfill P3. P2 is true as long as he keeps his Private Key to himself only.
It will be persistent as long as he does not have to change his private key.
In fact, the last one, “persistent as long as he does not have to change his private key” is a rather problematic statement.
There has been cases such as Debian PRNG problem, which forced many people to change his private key.
Candidate 2: (Registry based unique string coupled with Public Key pair.)
This candidate is Candidate 1 pushed a little further. Here, instead of using Public Key as the identifier directly, we use a unique string as the identifier and couple it with the public key pair and register the pair at one of the registry. The registry has to make it sure that the identifier is unique.
In this case, the relying party can search the registry for the identifier and find out the public key associated with it. By checking the signature in the assertion with this public key, RP can tell whether he is dealing with the legitimate person or not.
A typical example of this kind of registry is a certificate authority. A certificate authority can issue a unique string and include it in the certificate. In this case, the identifier must contain the identifier of the CA as a part of it to avoid colliding identifier across the CAs. Having the CA identifier inside the id itself allwos the receiver of the id to evaluate its authenticity based on the certificate. Problem of this approach is that one is tied to a CA and will not be able to change it.
Another example of this type of identifier is XRI. One can find an authoritative signed XRDS that contains the public key from the persistent unique identifier (i-number). This is very close to the certificate approach, but it is not tied to a CA. However, it does require a priori defined root of resolution chain in the system.
Conclusion
HTTP and HTTPS based OpenID are facing problems 1-3.
Among the current OpenID types, only XRI is safe in this respect.
The community should seriously consider using non-domain based claimed_id coupled with public key with appropriate registry such as a Certificate Authority.
This candidate is Candidate 1 pushed a little further.