Simple Comments and OpenID (4/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=a6b5c41That'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.
[previous] [next] |
Created: July 31, 2008
Revised: July 31, 2008
URL: http://webreference.com/programming/perl/comments/openid/4.html
