While you may have read about it on Kim’s blog and many of you were there in person, I wanted to capture screen shots from the demos to make them available, so those who weren’t there can join the discussion as well. Plus, I’ve posted the presentation that accompanied the demos, rather than reproducing that content here. Now, on to the demo, which closely follows the one actually given at the Summit…

I start by demonstrating the user experience for a first-time selector user at a a selector-enabled OpenID relying party.

The first screen shot shows a standard Plaxo login screen, but augmented behind the covers to enable it to pass its OpenID authentication request parameters to an active client, if present. I will click on the “Sign in with OpenID” button on the Plaxo signin page, invoking the selector.

In the prototype, selector-enabled relying parties use a variant of the Information Card object tag to communicate their request parameters to the selector. The object tag parameters used on Plaxo’s RP page are:
<object type="application/x-informationCard" id=infoCardObjectTag>
<param name=protocol value="http://specs.openid.net/auth/2.0"/>
<param name=tokenType value="http://specs.openid.net/auth/2.0"/>
<param name=issuer value="Google.com/accounts/o8/id Yahoo.com myOpenID.com"/>
<param name=issuerExclusive value=false/>
<param name=OpenIDAuthParameters value=
"openid.ns:http://specs.openid.net/auth/2.0
openid.return_to:http://www.plaxo.com/openid?actionType=complete
openid.realm:http://*.plaxo.com/
openid.ns.sreg:http://openid.net/extensions/sreg/1.1
openid.sreg.required:email
openid.sreg.optional:fullname,nickname,dob,gender,postcode,country,language,timezone
openid.sreg.policy_url:http://www.plaxo.com/about/privacy_policy
"/>
</object>


Here I’ve clicked on the “Sign in with OpenID” button, invoking the selector. (The “Google” and “Yahoo” buttons would have invoked the selector too.) This shows the first-time selector user experience, where it isn’t yet remembering any OpenIDs for me. The three OPs suggested by Plaxo – Google, Yahoo, and MyOpenID, are shown, as well as the option to type in a different OpenID. I click on the Yahoo suggestion.

Clicking on Plaxo’s Yahoo suggestion resulted in a Yahoo OpenID card being made available for use. Note that, by default, the selector will remember this card for me. (Those of you who know OpenID well are probably thinking “Where did the selector get the Yahoo logo and friendly name string”? For this prototype, they are baked into the selector. Longer term, the right way is for the selector to retrieve these from the OP’s discovery document. The OpenID UX working group is considering defining discovery syntax for doing just that.)

Once I’ve clicked “OK” to select the identity to use, the selector (not the RP) redirects the browser to the OP – in this case, to the Yahoo login page. The selector’s work is done at this point. The remainder of the protocol flow is standard OpenID 2.0.

This is the standard Yahoo OpenID signin page, which the selector redirected the browser to after I choose to use the suggested Yahoo OpenID. I sign into Yahoo.

The signin page is followed by the standard Yahoo permissions page. I click “Agree”.

After logging with Yahoo, I’m redirected back to Plaxo. Because I’d previously associated my Yahoo OpenID with my Plaxo account, I’m now logged into Plaxo. My status “Michael is demonstrating an OpenID selector at the OpenID Summit”, which I updated live during the demo at the OpenID Summit, is shown.

At this point in the demo, I’ve signed out of Plaxo and returned to the selector-enabled sign-in page. After clicking “Sign in with OpenID” again, the selector reappears.

This time, the selector has remembered the OpenID I last used at the site and tells me when I last used it there. (This is one of the ways that a selector can help protect people from phishing.) By default, the OpenID last used at a relying party is automatically selected – in this case, Yahoo. I click “OK” to select it, with the rest of the flow again being the standard OpenID 2.0 flow.

JanRain selector-enabled several production sites, including interscope.com, uservoice.com, and pibb.com, which use JanRain’s hosted RPX service. This could be done with no impact on users without a selector by using JavaScript to detect whether a selector is present or not, and customizing the page accordingly. The page above is the production Interscope Records page. I click the OpenID button on the right under the “Join The Community” banner.

The OpenID button invokes the RPX “NASCAR” experience. (Arguably, this page could be omitted from the experience if a selector is detected.) I click the OpenID button on the “NASCAR” page.

The selector is invoked by Interscope (really, by RPX) to let me choose an OpenID. My Yahoo OpenID is shown and the “Never used here” tells me that I haven’t used it at this site before. I could choose it by clicking OK or hitting Enter. Instead, I click the “Other OpenIDs” button to explore other options.

The “Other OpenIDs” tile shows me the OpenID providers suggested by Interscope – in this case, Flickr, Yahoo, and Google. I click on the Google suggestion.

The selector has created a Google OpenID card for me to use. It is marked “Verified” because it (like Yahoo) was on a whitelist in the selector and considered “safe” to use. Of course, in production use, such a whitelist would have to be maintained by a neutral third party or parties and dynamically updated. In the prototype, we hard-coded a few common providers so we could show a user experience that relies on a whitelist of OPs, to start the discussion about that possibility. I hit Enter to use the new Google card at Interscope.

Once I chose to use my Google card, the selector redirected me to Google’s signin page, with the actual RP for Interscope being signup.universalmusic.com. I sign into Google.

Following signin, Google asks me permission to release information to signup.universalmusic.com. I allow it.

I’m redirected back to Interscope, which asked me to complete a sign-up process by supplying more information via a web form.

When visiting Interscope again after having signed out, signing in with OpenID shows me that I last used my Google OpenID here. For that reason, it’s selected as the default. I can also see that I haven’t used my Yahoo OpenID here.

Andrew Arnott created the first selector-enabled relying party site for us, which is shown above. I click “Log in using your OpenID Selector”.

Now I have both Yahoo and Google cards, but neither have been used at test-id.org. I notice that I can get more details about my cards, and click “More details” on the Google card.

“More details” tells me where and when I used the card (signup.universalmusic.com), the discovered OpenID endpoint, and that this OpenID was on the selector’s whitelist. I could now use either of these OpenIDs, but I select “Other OpenIDs” instead.

The “Other OpenIDs” panel shows me OPs suggested by the site, as well as a dialog box to enter another OpenID. I decide to enter my blog URL self-issued.info, which is also an OpenID.

Here I’m entering my blog URL self-issued.info into the selector. I then click Verify or OK to have the selector perform discovery on the OpenID to add it as one of my choices.

Discovery has succeeded, but the OP my blog is delegated to, signon.com, is not on the selector’s whitelist. Because it’s not, a warning shield is shown, rather than the OP logo. I’ll also have to make an explicit decision to trust this OpenID provider before the selector will let me use it. The same would have happened if I chose an OP suggested by the RP if the OP was not on the whitelist. This is another aspect of the selector’s phishing protection. I check the “Continue, I trust this provider” box.

After checking the “Continue, I trust this provider” box, the warning shield is replaced by either the OP logo, if it can be discovered, or a generic OpenID logo, as in this case. I click OK to use this OpenID.

The selector follows my delegation link from self-issued.info and redirects me to signon.com. (Ping, are you going to fix the signon.com UX issue above someday?) I sign into signon.com.

Having signed into my OpenID at signon.com, I’m redirected back to the test site, which received an authentication response from the OP. I click “Reset test” to sign out, in preparation for another test.

Upon a second visit to test-id.org, the selector has remembered that I last used the OpenID self-issued.info, which is actually delegated to mbj.signon.com. I click “More details” to learn more about this OpenID.

“More details” tells me where and when I last used the OpenID and that the OpenID has been verified. But unlike my Google OpenID, which was verified via the whitelist, I told the selector to trust this OpenID myself.

At the OpenID Summit, people wanted to see the untrusted user experience again, so I entered an OpenID that I was sure wasn’t on our built-in whitelist – davidrecordon.com. However, verifying the OpenID actually brought me and those in attendance a surprise…

Because davidrecordon.com is delegated to myopenid.com, which is on the whitelist, it turns out that the prototype considered davidrecordon.com to be trusted as well. Upon reflection, this is probably the right behavior, but I’d never seen it until giving the demo live. (Great job, Oren!) I tried factoryjoe.com next and got the same result. Finally Will Norris helped me out by saying that willnorris.com isn’t delegated, so we got to see the untrusted user experience again.

I’d like to thank Chuck Reeves and Oren Melzer for quickly building a killer prototype and to thank Ariel Gordon and Arun Nanda for helping design it, as well as others, both from Microsoft and other companies, who provided feedback that helped us fine-tune it as we built it. See the presentation for a much more comprehensive list of thank-yous.

I’ll close by saying that in the OpenID v.Next planning meeting at IIW, there was an unopposed consensus that optional active client support should be included as a feature of v.Next. Hopefully our demo, as well as those by others, including Markus Sabadello of Higgins, helped the community decide that this is a good idea by enabling people to concretely experience the benefits that an active client can bring to OpenID. If so, I’d call the experiment a success!

Come join us!

Tuesday and Wednesday, April 8 and 9 at RSA 2008, Moscone Center, San Francisco, California
Location: Mezzanine Level Room 220
Interactive Working Sessions: Tuesday and Wednesday, 11am – 4pm
Demonstrations: Tuesday and Wednesday, 4pm – 6pm
Reception: Wednesday, 4pm – 6pm

Turns out that the Bandits, in their inimitable style, have been quietly churning out useful code. In this case, Duane Buss built Python relying party code to use at the Bandit Project’s Code pages (Bandit Trac) and also released it for general use. After only minimal cajoling, he also created a demo Python relying party.

Meanwhile JanRain, another group well-known for producing high-quality identity code, also built a Python relying party implementation, in their case to use at MyOpenID.com. As Brian Ellin just wrote, JanRain has released their Python code for accepting self-issued Information Cards for all to use. Have at it, Python hackers!

The JanRain team has done a fantastic job integrating account sign-up, sign-in, and recovery via Information Cards into their OpenID provider. I’m really impressed by how well this fits into the rest of their high-quality offering.

I should have expanded upon my point “fantastic job integrating account sign-up” to explicitly call out that no passwords are needed. Notice the Information Card button on the sign-up page below. Thanks Vittorio and Kim, for sharing your excitement about this. I’m hoping that as other sites integrate Information Card sign-in to their user experience that they’ll also follow this example (and the guidance in the deployment guide) and enable password-less sign-up with Information Cards.

Related to this is JanRain’s earlier announcement that they are including PAPE support in their widely-used OpenID relying party libraries. As Kevin Fox wrote:

Just a note to let everyone know that we are developing and will release relying party libraries supporting PAPE once the specification is finalized.
We have deployed an example relying party available here:
openidenabled.com/python-openid/trunk/examples/consumer/
The example fully supports OpenID 2.0 draft 12, and can request phishing-resistant authentication using PAPE. Feel free to use it for testing.
PAPE allows sites that use OpenID 2.0 authentication to get information about the way that the user authenticated to the provider. This is an important step on the way to getting the convenience needed of OpenID authentication for higher-valued transactions. It’s trivial to implement and will be included in JanRain’s OpenID 2.0 libraries as well as Sxip’s libraries.

Gary Krall also added that:

Verisign will also be releasing an update to the JOID library which we use on the PiP for as you may know we have added PAPE support to the PiP.

And I’ll add that MyOpenID.com and SignOn.com both also support PAPE on their OpenID providers.

Why is this exciting? Because it means that without use of without any use of passwords, people can create and use OpenIDs with their Information Cards. And that sites accepting OpenIDs can ask for phishing-resistant authentication when you sign in – which these OpenIDs will do for you. All more great steps towards building a convenient, secure, ubiquitous identity layer for the Internet!

Last night OSIS and the Burton Group held the third in a series of user-centric identity Interop events where companies and projects building user-centric identity software components came together and tested the interoperation of their software together. Following on the Interops at IIW in May and Catalyst in June, the participants continued their joint work of ensuring that the identity software we’re all building works great together.

This Interop had a broader scope along several dimensions than the previous ones:

• We welcomed new participants a.t.e Software, Fraunhofer, JanRain, LinkSafe, ooTao, Sun Microsystems, Siemens, and ThoughtWorks.
• We tested interoperation of OpenID software (including i-name software) in addition to Information Card software.
• Several kinds of interop between Information Card and OpenID software were demonstrated, including:
  1. OpenID providers implementing the OpenID phishing-resistant authentication specification using Information Cards to enable phishing-resistant sign-in to OpenIDs, and
  2. using OpenID Information Cards to supply OpenIDs to OpenID relying parties.
• Unlike previous Interops, the endpoints and testing results are all publicly available so that others can benefit from them.
• Many of the participants have committed to keeping their sites up beyond Catalyst to allow for continued public interop testing. For instance, Microsoft’s sites will remain up at http://www.federatedidentity.net/.

An excerpt from Bob Blakley’s insightful-as-always commentary on the Interop is:

The participants have posted their results on the wiki, and a few words are in order about these results. The first thing you’ll notice is that there are a significant number of “failure” and “issue” results. This is very good news for two reasons.

The first reason it’s good news is that it means enough new test cases were designed for this interop to uncover new problems. What you don’t see in the matrix is that when testing began, there were even more failures – which means that a lot of the new issues identified during the exercise have already been fixed.

The second reason the “failure” and “issue” results are good news is that they’re outnumbered by the successes. When you consider that the things tested in Barcelona were all identified as problems at the previous interop, you’ll get an idea of how much work has been done by the OSIS community in only 4 months to improve interoperability and agree on standards of component behavior.

Be sure to read his full post for more details on what the participants accomplished together. And of course, this isn’t the end of the story. An even wider and deeper Interop event is planned for the RSA Conference in April 2008. Great progress on building the Internet identity layer together!

The JanRain OpenID team is pleased to announce Information Card support has been added to MyOpenID.com.

What is an Information Card?

What can I do with it? With a self-issued Information Card you can sign-in to MyOpenID, as well as sign-up and recover your account, without ever having to enter your password. Anywhere on MyOpenID that you can enter a password will now allow you to use an Information Card instead. With the addition of Information Card support MyOpenID is able to offer another solid option for people wanting to protect their OpenID account from phishing attacks and remember fewer passwords.

We were able to work with Microsoft’s Mike Jones and Kim Cameron who have both been long time proponents of OpenID + Information Card support.

As noted by Kim Cameron “Cardspace is used at the identity provider to keep credentials from being stolen. So the best aspects of OpenID are retained.” While one of the less desirable aspects (confusing user experience) has been improved for someone using an Information Card to login to their OpenID provider.

Support for Information Cards has been growing as more software projects implement the technology. It is important to note that this technology is being supported by many other organizations besides Microsoft. Information Card support is available for Windows platforms (Vista / XP) as well as Mac OS X and Linux.

The JanRain team has done a fantastic job integrating account sign-up, sign-in, and recovery via Information Cards into their OpenID provider. I’m really impressed by how well this fits into the rest of their high-quality offering.

There’s another kind of integration they also did that makes this even more impressive in my mind: connecting their new Information Card support with their existing support for the draft OpenID phishing-resistant authentication specification. This is another significant step 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. Because of this work, this sequence is now possible:

1. A person goes to an OpenID relying party and uses an OpenID from MyOpenID.com.
2. The OpenID relying party requests that MyOpenID.com use a phishing-resistant authentication method to sign the user in.
3. The person signs into his MyOpenID.com OpenID with an Information Card.
4. MyOpenID.com informs the relying party that the user utilized a phishing-resistant authentication method.

This means that MyOpenID users will be able to get both the convenience and anti-phishing benefits of Information Cards at OpenID-enabled sites they visit and those sites can have higher confidence that the user is in control of the OpenID used at the site. That’s truly useful identity convergence if you ask me!