The first category of Attribute Exchange types we will look at is address types. The AX extension defines a number of address identifiers for a default address (such as a home or personal shipping location) and a business address, as shown in Table 11-4.

These are great fields for companies to support or leverage if they need to store or request data from a user for shipping purposes. For instance, if an online merchant implemented OpenID for site sign-in using a provider that supported these AX attributes, it could prepopulate all of a user’s shipping details.

The next category comprises audio and video greeting types. Depending on the service context in which they were created, these fields may include audio greetings, like those you set up on your phone, or short video greetings (Table 11-5).

A practical use case for this information is in the field of telephony, where someone might record audio and spoken name greetings—i.e., voice mail messages—for callers trying to reach him. Video greetings take this concept a step further, as in the case of video conferencing.

The Attribute Exchange extension also provides definitions for the user’s date of birth. Most providers that supply this information support only the full date of birth, but as you can see in Table 11-6, there are types defined for the individual components denoting the day, month, and year as well.

Date of birth information is perfect for sites that have certain age restrictions or those that require a user to certify that he is old enough to purchase a product (such as a game company). Even if the individual numeric values are not provided, the full birth date can be easily parsed into its individual components (just be aware of the short formats that other countries use, such as MM/DD/YYYY in the United States versus DD/MM/YYYY in Canada).

The next category, and our smallest by far, is email. The only field that is supported here is that of the user’s email address (Table 11-7). This is probably one of the most popular requests for social data, however, and an area of contention among companies providing this data. It is a prime viral channel for social developers to reach out to their user base, but this potential benefit is tempered by the risk of a service using the data for malicious spamming or phishing attempts. OpenID providers that support this type try to make their users aware that they will be sharing this data with the third-party site or service, thereby putting the onus on the user to understand the potential harm in sharing this particular piece of information.

The email field is a valuable resource for all developers. It provides a prime communication channel to the user who has authenticated your site or service. Many of the most popular OpenID providers support this field through the Attribute Exchange extension.

Images are a popular feature in any site or service that provides profile systems for its user base. These images are made available through the Attribute Exchange extension with a number of potential size fields, including the default user image, different aspect ratios, tiny favicons, and a square image that provides determinable sizes for the images. These are listed in Table 11-8.

These fields are ideal for populating a user image in a profile without requiring the user to upload or link to an existing image. This method also syncs the user image between your site or service and the provider site through which the user logged in.

Another communication channel that the Attribute Exchange extension provides is that of the user’s linked messenger accounts. The most popular messaging platforms are included in the specification (as shown in Table 11-9), providing the OpenID relaying site with a whole host of communication methods and account links about a user.

While most OpenID consumers may not want to use the user’s messenger accounts as a direct means of communication (which could easily be construed as a form of spam or an invasion of user privacy), providing these account links in the user profile allows your users to link additional accounts to their profiles, helps you search for new connections to the user, and delivers a number of other social functions that give users an easy way to build up their profiles.

Along with the user’s email address, the name provided through the AX extension is an excellent starting point for the construction of a user’s profile. Many OpenID providers allow for some basic name information to be obtained during the authentication process—most commonly, the user alias or nickname because that is how the user has chosen to be identified and it is usually part of a user’s public profile, which anyone can obtain without authentication.

Public profiles usually consist of a simple user badge comprising the user nickname, profile picture, direct profile link, and some sort of primary network. The public profile may also contain a primary URL defined by the user and a selection of the user connections. Figure 11-6 is an example of a simple public badge.

Figure 11-6. Example of a Facebook public badge

There are a number of name fields available for us to use, listed in Table 11-10.

As mentioned earlier, the name information is the perfect starting point for developing a user profile. Since you are already having the user go through the process of authenticating her account, you should at least make it as easy as possible for her to create a user profile on your site. Prepopulating users’ profiles for them with information such as their names will go a long way toward decreasing the drop-off rate that you may otherwise see during the user signup process.

Another set of fields that an OpenID provider may support through the AX extension is the user profile types for contact phone numbers (shown in Table 11-11), which deliver an alternate means of physical communication.

Direct lines of communication are beneficial fields for companies with physical user support centers, or for those who may need to contact the user at some point in the future. If you have a service that ships physical goods or provides some sort of prolonged user service (such as an ISP), accessing alternate contact methods from the OpenID authentication process can come in very handy.

The available website fields (Table 11-12) comprise a list of the more popular services that a user may link to his profile, including one default source for a custom site like a personal home page.

Linking alternate sites for a user is always a good idea when creating a profile for him on your site. Many services that provide listings of user activities (and those of user connections) may also provide a method to aggregate feeds from other networks into that activity stream. These linked accounts are a vital piece of that process.

To provide a small amount of data about the work background of the person going through the authentication process, the company name and job title types are available (Table 11-13). These fields help you flesh out the user’s profile—and the more information that you have about her, the easier it is to target offers, ads, and services specifically to her, increasing your monetization potential on a per-user basis.

If you cannot obtain the user’s industry, being able to parse her company name and job title will help you determine the appropriate knowledge bucket to assign her to. This is especially valuable when you have no distinguishing interest indicators available for the user.

Last but not least, the other personal details and preferences fields that are listed in Table 11-14 will allow the OpenID consumer to extract additional user information such as a short biography, gender, native language, and time zone.

Geography-, language-, and gender-based user targeting to invoke regionalized and personalized product interest is an excellent strategy for any consumer to employ.