Simple Comments and OpenID (5/5) | WebReference

Simple Comments and OpenID (5/5)

To page 1To page 2To page 3To page 4current page
[previous]

Simple Comments and OpenID

RP Discovery

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, the realm reported to the OP is the domain name of your site; the domain name that comments.pl 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 XRI Resolution.

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 that your 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 return_to:

Yahoo refuses OpenID
authentication if the RP's XRDS is found, but the endpoint isn't listed.
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 warns the user
about the site potentially being fraudulent if an XRDS is not found.
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.

Other Considerations

v1.1 Compatibility

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:

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!

Other Resources

Conclusion

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!


To page 1To page 2To page 3To page 4current page
[previous]

Created: July 31, 2008
Revised: July 31, 2008

URL: http://webreference.com/programming/perl/comments/openid/5.html