Simple Comments and OpenID (4/5) | WebReference

Simple Comments and OpenID (4/5)

To page 1To page 2To page 3current pageTo page 5
[previous] [next]

Simple Comments and OpenID

OpenID Extensions

Associations, authentication queries, OP assertions and verification requests aren't the only types of communications that might occur between an RP and an OP. As it turns out, there's a wealth of additional information that the OP might have and might be willing to share that an RP might want access to. Enabling these particular types of mights are OpenID Extensions, which were developed by the OpenID folks as a means to "piggyback" additional communication parameters on top of the standard OpenID messages, allowing an RP and OP to provide each other with additional types of info desired without requiring them to send additional and separate communications with one another. The extension mechanism itself--i.e., how the additional parameters are named and how they should be included in an OpenID message--is defined directly within the OpenID specifications. The actual extensions--i.e., the exact parameters exchanged and their meanings--are defined externally to the OpenID specifications; allowing the extensions to evolve separately and independently from the core OpenID specs. Let's take a quick look at the primary OpenID extensions available as of this writing.

Simple Registration

The Simple Registration extension was originally designed for use with version 1.1 of OpenID. It provides for the passing of a fixed set of basic user registration information from the OP to the RP as part of a positive assertion. i.e., when the OP responds saying that the user owns the identifier they claim to own, they send along common data about the user, such as their desired display name (nickname in the spec itself), E-mail address, location, etc. Worthy OpenID providers ask the user's permission to send this data before actually doing so.

This information is useful to RPs maintaining their own user profiles--which includes Simple Comments--since it allows the RP to automatically "fill in" the user's basic registraton data without requiring them to actually fill in the forms. The extension itself allows the RP to either require specified data to be present for full registration, or make it optional; though ultimately the OP chooses which data to actually send regardless of the RP's desires. Some OPs, such as Yahoo!, for example, won't send any registration data to the RP regardless of what the RP requests.

A draft, updated version of Simple Registration is also provided on the OpenID site that updates the spec to directly support the extension mechanism described as part of OpenID 2.0 (which is the extension method described at the top of this page).

Simple Comments supports this updated version of the Simple Registration extension, and will use it unless the OP is known to support the more robust Attribute Exchange (see below). If registration information is sent from the OP, it (the information) will, if possible, be incorporated into the user's Simple Comments profile. It's important to realize that not all data sent from the OP will be compatible with Simple Comments profiles. For example, if an OpenID user logs in with a potential display name that an existing user already has, then the new user's requested display name must be ignored. Since the spec writers couldn't possibly envision all the possible data incompatibilities that may result, they wisely state in the specifications that the RP should treat data differences in the same manner that they would if the user entered the data manually. In the interest of streamlining the OpenID login process, Simple Comments will ignore data that does not meet the Simple Comments profile requirements; with the exception that if the supplied display name matches an existing display name, the user's OpenID itself will be used as their display name (they can always change it, and any other registration discrepancies, via a subsequent profile change after they're logged in, if they wish). The existing Simple Comments parameter require_registration_approval will continue to be supported for both regular profile registrations and new OpenID logins; specifically, if you require registrations to be approved, then you'll need to approve the new registrations from OpenID users, as well.

Attribute Exchange

While Simple Registration is useful in and of itself, it's easy to see its main shortcoming. What if you want a piece of data that isn't listed in the specification? While Simple Registration is exactly that (Simple), it provides no room for extension. You can get up to the nine fields listed in the actual specifications and no more; unless that specification itself were to be updated.

Rather than continue to update Simple Registration with additional field definitions, the OpenID spec-sters created a new extension called OpenID Attribute Exchange, which allows the RP and OP to collaborate on exactly which fields they'd like to exchange with one another without defining the actual fields as part of the specification itself. Similar to the logic that resulted in the definition of OpenID Extensions as part of the OpenID specifications (without defining what those extensions would be), this model allows for the definition of the fields that will be exchanged between the RP and OP outside of the actual specification, and enables them (the field definitions) to be extended independently of the Attribute Exchange process.

Specifically, the RP sends URL/URN references to the OP that they can use to uniquely decide what data to send in return. If the URL can actually be resolved (i.e., if the OP can find data at the URL), then it can use that data to determine what data is being requested. This allows the extension to itself be extended; since cooperating RPs and OPs can use whatever identifiers they wish to (and have agreed to use). One such repository of attribute definitions that can be used exists at AXSchema.org, though in my testing I found that many of the OpenID providers I tried didn't recognize attributes via AXSchema definitions. Thus, Simple Comments uses schema.openid.net ids (for example, http://schema.openid.net/namePerson/friendly, http://schema.openid.net/namePerson), etc. In contrast to the AXSchema.org listings, the schema.openid.net pages don't actually exist (at least not as of this writing), nonetheless the OpenID community (read: Most OPs) seems to support them readily enough.

An actual Attribute Exchange message in OpenID can be quite lengthy; since both the attribute types, and in some cases the counts, must be provided explicitly (and each type, in turn, is referenced via a full URL). This example, lifted from the Attribute Exchange specifications, requests the fullname, gender, favorite dog, and the three most favorite movies of the end user; with the name and gender required fields (but as in Simple Registration, it's up to the OP to honor or deny attribute requests; required or not). Note that this example does not include whatever OpenID parameters would also need to be included as part of the exchange (i.e., the necessary parameters sent from the RP to the OP as a normal part of OpenID Authentication):

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.type.fname=http://example.com/schema/fullname
openid.ax.type.gender=http://example.com/schema/gender
openid.ax.type.fav_dog=http://example.com/schema/favourite_dog
openid.ax.type.fav_movie=http://example.com/schema/favourite_movie
openid.ax.count.fav_movie=3
openid.ax.required=fname,gender
openid.ax.if_available=fav_dog,fav_movie
openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41

That's a lot of data for a few pieces of information; and may explain why some OPs and RPs prefer to stick with Simple Registration, instead. (The resulting response from the OP is equally verbose.) Nonetheless, the extensibility of Attribute Exchange makes the data length worth the effort; and Simple Comments supports Attribute Exchange for those providers that use it (giving preference to Attribute Exchange over Simple Registration).

The actual fields that Simple Comments will ask for mirror those in the Simple Comments registration form, and are listed at the bottom of the CommentOpenID.pm package. If you want to reduce the amount of data you're sending back and forth to OPs, you might consider commenting out some of the requested fields, in which case Simple Comments won't ask for them. For example, I've removed the city, state, and each of the instant messenger ID fields:

our $ax_fields   = { 'nickname' => 'http://schema.openid.net/namePerson/friendly',
                     'email'    => 'http://schema.openid.net/contact/email',
                     'fullname' => 'http://schema.openid.net/namePerson',
                     'dob'      => 'http://schema.openid.net/birthDate',
                     'country'  => 'http://schema.openid.net/contact/country/home',
                     'url'      => 'http://schema.openid.net/contact/web/default',
#                     'aimid'    => 'http://schema.openid.net/contact/IM/AIM',
#                     'icqid'    => 'http://schema.openid.net/contact/IM/ICQ',
#                     'msnid'    => 'http://schema.openid.net/contact/IM/MSN',
#                     'yahooid'  => 'http://schema.openid.net/contact/IM/Yahoo',
#                     'skypeid'  => 'http://schema.openid.net/contact/IM/Skype',
#                     'city'     => 'http://schema.openid.net/contact/city/home',
#                     'state'    => 'http://schema.openid.net/contact/state/home',
                     'title'    => 'http://schema.openid.net/company/title'
                   };

Reducing the number of AX fields requested may reduce your communication to the point where form-based redirects (see page 1 of this article) will no longer be necessary.

Simple Comments will then process the returned information in the same way as it would Simple Registration information; if the data is compatible with a Simple Comments profile, it will be added to the user's initial profile as a result of their first OpenID login.

Update Information

There's one other key feature of Attribute Exchange that you won't find in Simple Registration; and that's the possibility of two-way communications that can occur outside of the normal flow of OpenID authentications. In other words, RPs and OPs can update one another with a user's attribute information whenever they deem it necessary. Simple Comments supports the receiving of update information from an OP, but as of this writing doesn't send updated information back to the OP. And the ability to receive updates from OPs is, at best, experimental; I was unable to test the feature against any live OPs that actually provided that capability (if you know of one, drop me a note and I'll let you know how Simple Comments handles it).

Provider Authentication Policy Extension (PAPE)

The final entry in our review of the main OpenID extensions is PAPE, or the Provider Authentication Policy Extension. In brief, PAPE allows an RP to request a specific type of authentication policy from the OP (such as multi-factor authentication, for example); and additionally allows the OP to report back to the RP the type of authentication that was actually employed. PAPE communications are purely informational, since the actual authentication policies used by the OP are completely transparent to the RP. In other words, PAPE is an honor-based system; an RP can only trust the responses received to PAPE requests as much as it trusts the OP itself.

Simple Comments does not, as of this writing, support PAPE informational exchanges.

Other Extensions

Other extensions listed on the OpenID.net site include those for the advertising and discovery of an entity's public keys, and for the creation and or verification of DTP messages. Neither of these extensions is currently used in Simple Comments. For more information I refer you to the OpenID Specifications themselves.

Accountability is a two way street; and in addition to RPs examining OP messages for validity, the OpenID specification also provides a means for OPs to check out RPs before blindly sending the user back with a positive assertion. That process is called RP Discovery, and it's the lead topic on the next and final page of this article.


To page 1To page 2To page 3current pageTo page 5
[previous] [next]

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

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