Archive for the 'Phishing Resistance' Category

August 26, 2007
Information Cards for OpenIDs

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 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 OpenID identifier.

Phone: (omitted)
Country: USA
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="">openid.ns:
openid.ext1.value.attr5:One Microsoft Way, Building 40/5138

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!

July 27, 2007
Information Cards at OpenID Providers

PIP InfoCardsThis week VeriSign upgraded their Personal Identity Provider (PIP) to support Information Cards. As David Recordon wrote at VeriSign’s official “Infrablog”:

Last Saturday, we completed the upgrade of our Personal Identity Provider. All accounts have been automatically upgraded and the URL is the same at We definitely encourage everyone to come try it out as we believe it is the best OpenID Provider in existence! Not only does it have all of the features from the PIP we launched last May, but adds support for OpenID 2.0, the ability to manage multiple identities within one PIP account, integration with strong authentication via our VeriSign Identity Protection network, Information Card support as one way to help protect against phishing attacks, and our SeatBelt Firefox add-on which works with a variety of OpenID Providers.

PIP supports Information Cards in two ways:

  • Logging into your PIP account: You can use a managed Information Card to log into your PIP account, providing a phishing-resistant alternative to logging in with a username and password typed into the browser.
  • Using your PIP Identities at other sites: PIP issues managed Information Cards for each of your PIP identities, which you can use to sign into sites using Information Cards for login and/or account creation. (And of course, these same identities are also OpenIDs as well.)

Images of my PIP cards for these two use cases are shown at the top of this post. I can now use my PIP account card to sign into my PIP account and my PIP identity card to sign into other sites. PIP is doubly cool because I believe it’s also the first general-purpose identity provider to be secured by an Extended Validation Certificate (see the green color of the IE7 address bar?). Great progress! LogoThis follows on last month’s launch of Ping Identity’s identity provider. lets you log into your OpenID account using a self-issued Information Card — a convenient, password-free, and phishing-resistant authentication mechanism.

Both are fantastic steps towards our shared goal of building a convenient, secure, ubiquitous identity layer for the Internet. Expect to see lots more developments like this soon!

Yours truly, and

June 23, 2007
Phishing-Resistant Authentication Specification Ready

David Recordon just posted a simple draft OpenID specification enabling OpenID relying parties to request that a phishing-resistant authentication method be used by the OpenID provider and for providers to inform relying parties whether a phishing-resistant authentication method, such as Windows CardSpace, was used. This is a major step forward in fulfilling the promise of the JanRain/Microsoft/Sxip Identity/VeriSign OpenID/Windows CardSpace collaboration announcement introduced by Bill Gates and Craig Mundie at the RSA Security Conference this year.

In his post “Bringing Useful Scalable Security to OpenIDDavid wrote:

The integration cost of OpenID as a Relying Party is extremely low, the technology is free and as Brian Ellin and I showed at Web 2.0 Expo the time commitment is also low due to a lot of great Open Source code out there which takes care of the heavy lifting. So now the RP has successfully integrated OpenID and removed the need for new users to create yet another password for their site, though they no longer have the control over the strength of a user’s authentication process. The RP may be a simple Web 2.0 site and not care beyond that the user has a password, it may store marginally sensitive information and want to make sure that the Provider did something to help protect the user from common phishing attacks, or maybe it’s a site which has truly sensitive information and wants to make sure that a second-factor device, such as a VIP token, was used.

With the OpenID Provider Authentication Policy Extension that I just published, this is now possible. This extension to OpenID 1.1 and 2.0 allows Relying Parties to express preferences around the authentication, such as “use technology which is phishing resistant” (stemming from the collaboration announcement at the RSA conference earlier in the year), for the Provider to inform the user of the request, guide them through the authentication process, and then inform the Relying Party what happened. By taking advantage of existing specifications from the likes of the National Institute of Standards and Technology (NIST), Providers can also convey information as to the strength of a password or combination of a password and digital certificate or hardware device used. While the high-end of the specification may be beyond the uses of OpenID today, it certainly fulfills the scalable security vision that we have. Through this specification not only can I now strongly protect my OpenID identity, but let others know that I’m doing so and truly take advantage of a reduction in credentials needed when browsing the web.

I can’t wait to use the implementations that are sure to follow shortly!

« Prev