Sxip Identity just finished a draft specification that enables a really useful form of convergence between OpenIDs and Information Cards: presenting your OpenID as an Information Card you select rather than as a string you type. Johnny Bufu’s OpenID general mailing list note introduces this specification for community review.

This combination has several advantages over standard OpenID usage. First, there’s no OpenID string to type when you use your OpenID, which should make OpenIDs easier for more people to use. Second, this is a phishing-resistant authentication method. Finally, it lets you recognize and choose your OpenID visually, based on the card graphics supplied by the OpenID provider.

Sxip also backed this specification by a sample implementation, which you can check out at https://openidcards.sxip.com/. Now for some more details….

Here’s how it works: In this model, the OpenID relying party asks for an OpenID Information Card using an object tag on the page rather than having the user type the OpenID as a string (while probably also giving the user the option to instead type in the string for backwards compatibility). The user’s Identity Selector then lets the user choose which OpenID card to send to the site. The card transmits the actual OpenID string to the site as a claim. From that point on, standard OpenID protocol interactions ensue.

For instance, the sample relying party page asks you to “Login with an OpenID InfoCard” and requests the card using this evocative graphic:

OpenID InfoCard

Upon clicking the graphic, my identity selector is invoked, which shows me that I can use this OpenID Information Card at the site (which I’d previously obtained here):

Sxip OpenID InfoCard

After that, the sample performed a standard OpenID attribute exchange and the relying party greeted me with:

Welcome! You have logged in using your https://openidcards.sxip.com/i/mbj OpenID identifier.

Phone: (omitted)
Country: USA
Email: mbj@microsoft.com
City: Redmond
Address: One Microsoft Way, Building 40/5138
LastName: Jones
FirstName: Mike

Behind the scenes, the relying party had received this OpenID assertion:

<openid:OpenIDToken xmlns:openid="http://specs.openid.net/auth/2.0">openid.ns:http://specs.openid.net/auth/2.0
openid.op_endpoint:https://openidcards.sxip.com/op/
openid.claimed_id:https://openidcards.sxip.com/i/mbj
openid.response_nonce:2007-08-26T20:55:34Z0
openid.mode:id_res
openid.identity:https://openidcards.sxip.com/i/mbj
openid.return_to:https://openidcards.sxip.com/demorp/
openid.assoc_handle:f27d249fc4108198
openid.signed:op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle
openid.sig:gKKpDjEbgByJo48Q800Jq4gCJng=
openid.ns.ext1:http://openid.net/srv/ax/1.0-draft4
openid.ext1.mode:fetch_response
openid.ext1.type.attr1:http://axschema.org/contact/phone/default
openid.ext1.value.attr1:(omitted)
openid.ext1.type.attr2:http://axschema.org/contact/country/home
openid.ext1.value.attr2:USA
openid.ext1.type.attr3:http://axschema.org/contact/email
openid.ext1.value.attr3:mbj@microsoft.com
openid.ext1.type.attr4:http://axschema.org/contact/city/home
openid.ext1.value.attr4:Redmond
openid.ext1.type.attr5:http://axschema.org/contact/postalAddress/home
openid.ext1.value.attr5:One Microsoft Way, Building 40/5138
openid.ext1.type.attr6:http://axschema.org/namePerson/last
openid.ext1.value.attr6:Jones
openid.ext1.type.attr7:http://axschema.org/namePerson/first
openid.ext1.value.attr7:Mike
</openid:OpenIDToken>

One final technical note that will be of interest to some of you: OpenID Information Cards do not use SAML tokens. They use one of two variants of openid:OpenIDToken tokens (depending upon whether the OpenID relying party uses OpenID 1.1 or 2.0 authentication).

Go get yourself an OpenID Information Card and give it a spin! Read and comment on the spec. Or even better yet, implement it and tell us about your experience!