Simple Comments and OpenID (5/5)
Simple Comments and OpenID
While most of this article has focused on the types of OpenID communications that are initiated by an RP, there's one particular type of OP initiated communication that all RPs must be aware of.
When an RP sends an end user to an OP for authentication, many OPs will perform an additional
verification step to ensure that the URL the RP sent to it really is... well... an RP. To perform
this verification, the OP will contact the
realm sent in the authentication request (in Simple Comments,
realm reported to the OP is the domain name of your site; the domain name that
was initiated through) and perform Yadis Discovery upon it in an attempt to retrieve
an XRDS file. As we discussed in an earlier
article, Yadis Discovery is now an official part of
A full description of Yadis is outside of the scope of this article (see section 6 of the XRI Resolution
specs for the details), but in brief it specifies a method whereby an interested party can retrieve
the XRDS document for the RP using only a standard URL. This method requires that the RP either 1.) modify the headers returned
as a result of HTTP requests with a pointer to the XRDS document, 2.) support content negotiation so
an XRDS file can be returned automatically when a requesting party asks specifically for it;
3.) edit the HTML document(s) returned as the result of standard HTTP requests, inserting within them
a meta tag that indicates where the XRDS file can be found; or 4.) some combination of the above.
In OpenID RP Discovery, as I've stated above, the OP uses the
realm to perform this discovery (and
in Simple Comments, the
realm is always the site's domain name). As a result, the above discovery steps
require changes either to the headers returned as a result of hits to the main domain name, direct
support for content negotiation, or modifications to the site's front page.
Once the OP finds the XRDS file, it will parse it in an attempt to find all valid OpenID endpoints at that RP; i.e., all the full URLs that the RP expects will initiate some type of OpenID communication request. It will then compare this list with the actual endpoint that's asking the question, and if it is listed in the XRDS file then RP Discovery is said to have passed. If not, RP Discovery fails.
As an example, let's say you're running Simple Comments on example.com, and
comments.pl file therefore resides at
http://example.com/cgi-bin/comments.pl. You'll need to create an
XRDS file that looks (at least) something like this:
<?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/return_to</Type> <URI>http://example.com/cgi-bin/comments.pl</URI> </Service> </XRD> </xrds:XRDS>
If you have more than one URL used for OpenID communications, you can list
them in multiple
<URI> tags in the service section. If you have other data to communicate in your XRDS you can do that, too.
What happens when RP Discovery fails is up to the OP themselves. Some may refuse to authenticate
to the RP at all, some will present a warning to the user, and some may ignore RP Discovery completely.
Yahoo, for example, will refuse to to continue if an XRDS file is found and the requesting
endpoint is not listed as a valid
Yahoo message that is provided to the user when RP Discovery fails.
Or, if the XRDS isn't found at all (Yadis Discovery fails), Yahoo warns the user that the site may be a problem, but allows them to proceed regardless at their discretion:
Yahoo message that is provided to the user when Yadis Discovery fails.
Since discovery of the RP's XRDS file requires that the OP be able to find the vendor's XRDS through hits to the site's home page (as well as potential modifications to the headers returned by the server as a result of hits to the home page, support for content negotiation, or modifications to the home page itself), it's not something that Simple Comments can do for you automatically. Nonetheless, if you want to avoid the types of responses described above, you should consider publishing an XRDS file for potential OPs to examine.
Though coded to support OpenID 2.0, Simple Comments also supports v1.1 compatibility; which is to say it should work fine with OpenID version 1.1 providers. Note that v1.1 communications with OpenID providers aren't necessarily as secure as v2 sessions, due to the inclusion of features that weren't available (or optional) in v1.1. For example, in v1.1, HMAC signatures are limited to to the weaker HMAC_SHA1 algorithm, and message nonces (unique, one-time values that are included in the messages sent from the OP to the RP) are optional (in v2, they're required). Perhaps most importantly, in v2 of the spec an OP can return a unique identifier for each claimed OpenID such that if the OP were to recycle the ID at a later time, the new user wouldn't be able to access OpenID accounts established by the previous owner.
For example, let's say that today I have an OpenID based on my Yahoo login; and let's say that ID happens to be me.yahoo.com/example. (It isn't, of course. But let's just say that it is.) I login to Simple Comments on WebRef using that OpenID, create a new account, and post a bunch of comments under that ID. Then I move to a remote island with absolutely no connectivity to the outside world. Surrounded by sun, sand and beach, I'm never seen or heard from in the civilized world again.
Since my account has been inactive for years, Yahoo decides to delete it; making the
Example ID available to the next person who happens to request
it. Since their OpenID would then also be me.yahoo.com/example, they can
now login to WebRef using it. The result is that this new person would assume control over my
user profile at WebRef, and could post comments under "my" ID. And even if I returned, I would
have no way to prove that the account belonged to me; since I would no longer have access to the Yahoo
account it was based on!
Version 2 of the OpenID specification allows for claimed identifiers to include unique fragments that can be used by RPs--like Simple Comments--to link a person's OpenID to their local user profile. In version 2, when I originally logged into WebRef in the example above, I would still do so using me.yahoo.com/example; but when Yahoo responds, it will tell the RP (Simple Comments) that my actual ID is something like me.yahoo.com/example#1234. Simple Comments will then use that ID as the link between the OpenID and the user's profile. Now, if someone else should assume control of the Example ID at Yahoo in the future, the unique ID they get when they try logging in using OpenID will be something else; say, me.yahoo.com/example#4321. Obviously, these two IDs don't match, and Simple Comments will set up a new account for this user, rather than allow them to reuse the old account.
It's not required, however, that OPs provide unique fragment identifiers; so even though they're allowed in the spec, don't expect all OPs to follow suit. It's possible that v1.1 of the spec didn't provide for this possibility.
Due to these potential 1.1 issues, some providers will refuse to authenticate to v1.1 OpenID RPs, a course that I considered taking with Simple Comments, as well. In the end it seemed harsh, since the main problem examined above (taking over another person's OpenID) can still exist with 2.0 providers (the spec provides a means of preventing the issue, but doesn't force it to be used); and also since the official 2.0 OpenID specs are only about 7 months old as of this writing. Nonetheless, I can see a potential benefit to providing a configuration option in the future that will force Simple Comments to use only v2.0 OpenID authentications. I'll keep this in mind; and in the meantime, please feel free to chime in with your thoughts on the issue.
OpenID Shortcomings in Simple Comments
Simple Comments is by no means a perfect RP. In no particular order, here are a few of the points on which Simple Comments' OpenID support could be improved in future versions:
Simple Comments will not iterate through multiple possible OpenID providers in an XRDS file. If you have an XRDS file that lists multiple OpenID providers, Simple Comments will choose one and attempt to authenticate you using it. If that authentication fails, Simple Comments will give up.
When presented with an XRDS with multiple choices for OpenID providers, Simple Comments will attempt to make the "best" choice, giving first preference to the user's highest priority OP, and then, if priorities are equal, preferring v2 OPs over v1 OPs.
As described above, v1.1 compatibility is included; but there's no way for users to force v2 compatibility only. Also, when v1.1 compatibility is used, Simple Comments doesn't provide a unique nonce value in OpenID communications; making replay-attacks possible (though difficult; since OpenID does include a unique transactional value that can only be used in a single authentication attempt).
Simple Comments includes no PAPE extension support.
XRI Resolution is now hard coded to use the xri.net resolver. If this resolver should fail or cease to exist (neither of these scenarios is expected, at least into the foreseeable future), then Simple Comments will be unable to provide XRI-based OpenID logins.
UTF-8 support is sketchy, at best; this problem will likely remain at least as long as Simple Comments supports Perl 5.6 interpreters.
OP Discovery (i.e., deciding whether or not a particular OP supports Attribute Exchange) is based on the XRDS discovered as a result of examining the OpenID provided by the user; and not as a result of directly interrogating the OP. Thus, Simple Comments may incorrectly determine that an OP is (or isn't) capable of Attribute Exchange based on the XRDS presented as a result of the end user's OpenID. This isn't as bad as it sounds, since in most cases the XRDS retrieved as a result of OpenID discovery will be created by the OPs themselves. Or, to put it another way, if my OpenID provider is Yahoo, then the XRDS file that an RP will retrieve will most likely also be retrieved from (and created by) Yahoo (and thus the XRDS file is likely to be accurate in regards to the services supported by Yahoo).
As noted on the previous page, Simple Comments support for automatically updating profile data (i.e., the ability to receive Attribute Exchange updates from OPs outside of the normal OpenID authentication exchange) is experimental. It's in the code, but I cannot say how well it will work. If someone is aware of an OP that provides these types of updates let me know and I'll check it out further!
Of course, this is just the list that I know of; OpenID Support in Simple Comments is new, and it wouldn't surprise me to learn of other inconsistencies that I'm not aware of. Please let me know if you find any other problems!
- OpenID Specifications
- The Net::OpenID::Consumer and Net::OpenID::Server packages on CPAN may be helpful to you in your own Perl-based OpenID endeavors. At of this writing, however, the modules appear to be geared specifically to OpenID 1.1 authentications, and not OpenID 2.
- The main OpenID Web site, within which can be found announcements, links to discussion lists (the general OpenID discussion list is quite active), links to the OpenID Wiki, the specifications above, and more.
While I've written five pages on the topic of OpenID support in Simple Comments, I feel like I've only scratched the surface. Is there some burning question or issue which I've not covered here? Do you want to discuss something I have said? Please feel free to leave a comment in the form below and I'll provide further information to the best of my ability! And as always, I appreciate all those of you who have tried the code and have offered your suggestions for corrections, improvements and enhancements in the past. Your suggestions continue to be welcome and I encourage you to leave them!
Created: July 31, 2008
Revised: July 31, 2008