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:
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):
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.
Address: One Microsoft Way, Building 40/5138
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:email@example.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).