142 VIEWS
Pinterest LinkedIn LINE

Now, assuming that OpenID will be incorporated into Xoops in the near future, what does OpenID provide to the “Relying Party (RP)” (in this case, Xoops as the recipient of information)?

OpenID authenticates that the person who is now trying to visit is the owner of the URL they have declared to be their own web page (assuming that web page has not been compromised). Conversely, that is all it does. This is probably sufficient as authentication when commenting on a blog, but when providing higher-value services, it will likely need to be combined with something else.

For example, consider a service for people who live in Open City (pronounced Ōpun-shi), such as an online bookstore offering an Open City resident discount. To authorize a person who logged in with OpenID to use the service, it would be necessary not only to authenticate the OpenID, but also to go to a service that authenticates that the OpenID’s owner is an Open City resident and obtain that assertion as well.

In that case, it would be natural for city hall to be the provider of that attribute authentication service, so let us proceed on that assumption.

Open City probably manages residents internally using resident numbers or something similar. To provide this service, it must link that resident number to the user’s OpenID. For example, if the user’s resident number were 12345678 and their OpenID were http://example.com/suzuki , the two would have to be linked somewhere in advance. Perhaps the initial 1 time would involve submitting a paper application when moving into the city or on some similar occasion… It is also conceivable that Open City itself might already provide OpenIDs. When someone moves into the city, an OpenID would be issued to them. Let us suppose that OpenID were http://open-city.or.jp/12345678 . (The http:// prefix will be omitted below because it is cumbersome.)

Then it would be sufficient if example.com/suzuki could be registered as an attribute of open-city.or.jp/12345678. If that were done, it would be possible to prove that example.com/suzuki is an Open City resident. There are 2 methods.

(1) The RP queries open-city.or.jp to verify the attribute.
In this case, example.com/suzuki must either have configured a rule in advance
to make this attribute public, or there must be some mechanism for granting
individual approval.
(2) The example.com/suzuki side obtains an assertion from open-city.or.jp
and presents it.
The consumer would tell the user, “Please go prove at open-city.or.jp that you
are a resident,” probably attaching a one-time session ID and redirecting them.
Since the user is already logged in as example.com/suzuki, they would then be
logged in automatically to open-city.or.jp via SSO, have a resident-certification
signature applied to the URL example.com/suzuki, and return to the consumer.
(For greater security, the consumer could issue the one-time session ID and
have that signed instead.)
This would likewise prove that the user is a resident.

Well, (1) and (2) are almost equivalent. (Or rather, it seems SAML has bindings for both…)†

Perhaps it is only once we get this far that it actually becomes useful.

Still, it does seem convenient.

The problem is that the example.com/suzuki used as an OpenID could be reused by a different person. Suppose Ichiro Suzuki initially used example.com/suzuki. At some point, however, suppose he left this provider and moved to newexample.com/suzuki. That seems entirely plausible. This itself is not a problem. But then suppose Hanako Suzuki, a resident of Cross City, joined example.com and began using example.com/suzuki. Furthermore, suppose Ichiro Suzuki had forgotten to update open-city.or.jp/12345678. In scenario (1) above, Hanako Suzuki could then receive the Open City resident discount even though she is a Cross City resident. (That means method (2) is preferable.)

This problem could be avoided by guaranteeing that IDs are never reused, but that seems difficult within the OpenID framework alone.

Could this also be why OpenID incorporates i-names? (I should ask Drummond…) With an i-name, there is an i-number underneath it (an absolute number that is always issued when an i-name is obtained and is never reused), and machines use that instead. Thus, Ichiro Suzuki’s example.com/suzuki and Hanako Suzuki’s example.com/suzuki above would not be confused with each other.


† Incidentally, something called OpenID Attribute Exchange is under consideration.
I will cover that on another occasion.

Related posts