This OpenID summit gives web site developers and technologists a closer look at the OpenID Connect protocol, its use cases and adoption plans by leading companies. We will introduce “Account Chooser” its implementation and user experience and provide interop testing and feedback for next generation OpenID adoption.

 Please join us on Monday, September 12, 2011 from 12:00 Noon until 5:00pm PDT and Tuesday, September 13, 2011 from 10:00am to 5:00pm PDT.

 Registration is now open at the following link: REGISTER NOW!

 Location:
Microsoft Research Silicon Valley Campus – 1288 Pear Avenue, Mountain View, CA  94043

OpenID Connect Tech  Summit 

AGENDA: Monday,
September 12, 2011 – 12:00pm-5:00pm

Noon: Lunch will be provided for attendees

12:00-12:20 – Welcome
Don Thibeau, Executive Director, The OpenID Foundation

Technical Sessions

12:20-1:00 – Overview and Update of OpenID Connect and OAuth 2.0, Mike Jones, Microsoft,
Director of Identity Partnerships

1:00-3:00 – OpenID Connect Spec development (Working Group Review led by Allen Tom and Mike Jones)
[2 hours]

• Timing goals for ratification
• Core protocol
• Dynamic RP registration and IDP discovery
• Claims
• Session Management
• Artifact Binding
• US Government OpenID Connect profile

3:20-4:00 – Open time for Technical Interop,  Allen Tom & Mike Jones [60 min]

4:00-4:40 – OpenID Connect: Building Test Infrastructure, Roland Hedberg

4:40-5:00 – Wrap-up, Don Thibeau, Executive Director, The OpenID Foundation

AGENDA: Tuesday, September 13, 2011 – 10:00am-5:00pm

Business Session

10:00-10:20 - Welcome Don Thibeau, Executive Director, The OpenID Foundation

10:20-11:00 - Feedback Review OpenID Connect Mike Jones, Microsoft
and Allen Tom, Directors, The OpenID Foundation

11:00-11:40 - Overview and Update of Account Chooser,  A presentation on a new sign in experience for the web, how to get involved, and an update on the legal status of related IP. Scott David, K&L Gates,  Basheer Tome,  Independent & Eric Sachs, Google

11:40-12:20 – Migrating Users to Identity Providers From Email/Password Logins”,  A Summary of the experience of websites, including Google, that have started to migrate users from traditional logins to identity providers.  Eric Sachs,  Google, Product Manager

12:20-1:00 – Lunch

1:00-1:40 – Microsoft as an RP and IDP, Speaker (TBD)

1:40-2:20 – Way Beyond Single Sign On, Greg Keegstra, Janrain

2:20-3:00 – The Value Proposition for OpenID Connect & Account Chooser in the Enterprise, Pam Dingle, Ping Identity

3:00-3:20 – Break

3:20-4:00 – Open Identity and Online Adoption, A discussion on trends in the adoption of social login among online businesses. Patrick Salyer, Gigya

4:00-4:40 – OpenID Connect & UMA Synergies, OpenID Connect and User-Managed Access (UMA) solve interestingly complementary problems.  This session will explore use cases and proposals for combining them.  Macie Machulak

4:40-5:00 - Wrap up Don Thibeau, Executive Director, The OpenID Foundation

Best regards,

Don Thibeau, Executive  Director
OpenID Foundation

Additional information is available at:

http://openid.net/connect/

http://accountchooser.com/

Hosted by:

OpenID Connect uses the best practices of widely used OAuth/REST/JSON based APIs to define a standard and interoperable way to authenticate users.  Developers should care because rather than having to learn an new and slightly different version of essentially the same API every time they want to integrate with a different identity provider, they can just do it in a standard way using a consistent interface.  In the long run, OpenID Connect will make the web more interoperable, because it makes it easier for developers to integrate with multiple services.

FYI, the working group *is* planning to reorganize the specs to have the minimal set of OpenID Connect functionality be contained in a single document, although this will likely not be in place for a few weeks.  Even before that is done, we wanted to make people aware of this set of specs now so early implementation work and technical feedback can occur.  Remaining edits to the specs should consist of corrections, clarifications, and reorganization, rather than additions of significant new functionality.  For now, developers should start with the (admittedly awkwardly named) OpenID Connect HTTP Redirect Binding spec.

Let the feedback and prototyping begin! [*1]

[*1] The easiest way to do is to join the AB list at http://lists.openid.net/mailman/listinfo/openid-specs-ab, submit the contribution agreement from http://openid.net/intellectual-property/ (which you can now do online!), and then send comments to the openid-specs-ab@lists.openid.net .

The “co-evolution” of OAuth and OpenID

Late last year, the members of the OpenID Artifact Binding and OpenID Connect Working Groups joined forces to develop a simple, common specification. The result had been informally referred to as “OpenID Artifact Binding/Connect” or “OpenID ABC”. Key contributors from both working groups have been working on a core specification ever since. Weekly specification calls have methodically focused on identifying and closing open issues. A key milestone was reached at IIW earlier this month: the remaining open issues were identified, tradeoffs debated, and all issues closed – with consensus decisions recorded in the Artifact Binding mailing list archives. The working group is now refining the specifications to reflect those decisions, as well as tracking the evolution of closely related specifications like OAuth 2.0.

Having passed this gate, the OpenID board decided to brand the result “OpenID Connect” and solicit as wide and diverse feedback as possible. The OpenID Retail Summit at PayPal, the “Security” Summit at Symantec, and last week’s OpenID Summit in Munich at the European Identity Conference all featured detailed briefings and feedback on OpenID Connect. While still a work in progress, OpenID Connect has achieved the levels of participation and consensus needed to advance to the next phase: interoperability testing for multiple use cases in several venues worldwide. We’ll continue to engage developers and potential deployers about OpenID Connect at upcoming OpenID Summits, including the next summit on July 19 in Colorado sponsored by Ping Identity, in to better understand, critique, refine, test, and ready OpenID Connect for prime time.

A look under the hood of OpenID Connect:

- web and developer friendly, building upon OAuth 2.0 and JSON
- simple site registration functionality (the “Connect” part)
- works well on mobile phones (the “Artifact Binding” part)
- simple JSON-based claims model
- reuses claims definitions from existing Portable Contacts specification
- can achieve a range of security characteristics, spanning use cases from social networks to those needing higher levels of assurance
- modular specifications, so deployers need only implement the functionality their applications need.

The strength of the open standards is the ongoing scrutiny from a global community of supporters and skeptics. Progress depends on those with the “courage of the first draft.” Our special thanks go to OpenID Board members Mike Jones, Nat Sakimura, and John Bradley, together with Breno de Medeiros from Google and Chuck Mortimore from Salesforce: working group participants whose dedication and perspectives were critical to building consensus, closing the open issues, and setting the stage for OpenID’s next act.

Don Thibeau
Executive Director

We plan to take advantage of face to face discussions on the around the next version of openID.

For those attending and others I want to point to the various potions of the spec work so that people have that in hand for IIW.

One of the changes from openID 2.0 is that the new specification is more modular.

The following diagram illustrates the components and links to the specs:

(Click on the diagram to see each specifications.)

Everything is built on top of OAuth 2.0 and the Bearer Token Profile of OAuth.

We are supporting multiple OAuth Flows for different device types.

The heart of OpenID Connect is the Core spec that describes the abstract protocol.

Discovery of user identifiers such as email for URI is performed by a profile of Simple Web Discovery

Session Management is currently a separate spec, however it may be folded into Core.

Revised: Core 1.0d03 incorporates the session management endpoints and eliminates some duplication.

Outstanding Issues

We are hoping to use our face 2 face time around IIW to resolve some of the outstanding issues:

We will be producing a implementers guide to make it easier for people to build clients without having to wade through all of the separate specs.

Expect an update after IIW in May.

John B.

Just before the latest Internet Identity Workshop, a few dozen members of the OpenID Foundation met at Facebook for a technology summit. Sessions ranged from the future of OpenID – looking at Connect and Artifact Binding – to details around profile data, signing, and encryption. Over the afternoon the group came to consensus around a number of different technical proposals.

You can find my notes from the day at http://bit.ly/b69H7d and we encourage you to continue discussion on the mailing lists. If you were at the Summit, please feel free to add anything we may have missed.

This announcement is significant for several reasons:

1. The number and breadth of industries represented by the new members
2. The use of OpenID by member companies for commercial transactions
3. Collaboration between OpenID Japan and Liberty Alliance Japan
4. An earlier survey by internet.com and Marsh Research of Japanese internet users found that 28% of knew about OpenID and 15% were using OpenID

Congratulations to OpenID Japan on these significant milestones.

There was some discussion from a few people yesterday claiming that Google’s implementation was a fork of OpenID. Today, Eric Sachs, Google’s lead on this effort, has another post responding to some of this early criticism:

That registration requirement also led to some confusion because users wanted to be able to use existing websites that accept OpenID 2.0 compliant logins by simply entering gmail.com (or in some cases their E-mail address) into the login boxes on those websites. … Once the XRDS file is live, end-users should be able to use the service by typing gmail.com in the OpenID field of any login box that supports OpenID 2.0, similar to how Yahoo users can type yahoo.com or their Yahoo E-mail address (In the meantime, if you feel really geeky, you can type https://www.google.com/accounts/o8/id into an OpenID 2.0 login box).

Although these are both considered “preview releases” by both companies, the fact that they have put code out there that developers can start to work with is absolutely fantastic. Both Google and Microsoft have stated that these are testing implementations and as such, their may be certain limitations while they work on localization, scaling and general UI.

Mike Jones talks about some of the details of the Microsoft LiveID testing:

One feature of the OpenID 2.0 implementation that I’d like to call your attention to is that they give users a choice, on a per-relying party basis, whether to use a site-specific OpenID URL at the site for privacy reasons, or whether to use a public identifier for yourself – explicitly enabling correlation of your identity interactions on different sites.

We also have an episode of theSocialWeb.tv where we have Eric Sachs from Google talking about this historic week with David Recordon, Joseph Smarr and John McCrea:

While OpenID has seen rapid adoption in the “user generated content” segment (blogs, discussion groups, wikis, etc.), we were very excited to see increased interest from mainstream media companies and affinity organizations. Participants at this event included AARP, AOL, BBC, Google, Hearst Magazines, JanRain, Meredith, MySpace, National 4-H, National Public Radio (NPR), The New York Times, Reed Business Information, Six Apart, Time Inc., Vidoop, and Yahoo!.

Throughout the day we covered a wide range of topics including:

• Business case for OpenID — use cases and economic impact
• Best practices for OpenID Providers and Relying Parties in the areas of user experience, data support, security, and product features
• Optimal Content Provider user experience
• Data Management — sources, integration, industry specific data, accuracy, security & trust
• Coming Enhancements — Provider Authentication Policy Extension (PAPE), OAuth, Portable Contacts API, MySpace Data Availability, and integration of OpenID into browsers.

Yahoo!, Google, and MySpace all presented information about their OpenID Provider services, thoughts on user experience and lessons learned, and some future plans. National 4-H presented a summary of an OpenID-based integrated National, State, and Local web platform that they will be deploying in the coming months. We shared a case study on Japan Airlines (JAL) federated partner commerce using OpenID with the proposed Trusted Data Exchange (TX) extension that Nomura Research Institute (NRI) has been developing. There was extensive discussion between existing and potential Relying Parties and the OpenID Providers about what would facilitate faster and broader adoption of OpenID in the Content Provider community. The session was moderated and feedback captured by Market Focus, a strategic marketing consulting firm who will be performing additional customer and market research on behalf of the OpenID Foundation.

If other content providers would like to join this advisory committee, please contact Johannes Ernst or Brian Kissel of the OpenID Foundation Customer Research Committee for further information.

Additionally, many members of the OpenID community will be attending the upcoming Internet Identity Workshop (IIW) on November 10-12 at the Computer History Museum in Mt. View, CA. This will provide a great venue for face to face discussions and additional opportunities to provide input and feedback on the future direction of OpenID.

Earlier today, ReadWriteWeb wrote more about how Mixi Brings Sophisticated OpenID to Millions of Japanese Users asking why Facebook isn’t using OpenID for their Connect APIs and providing a good overview of why mixi adopting OpenID with Simple Registration is helping to push the envelope:

The moral of the story, though, is that another major social network now supports OpenID and is pushing the envelope with the features included. They aren’t acting as a relying party yet, allowing users to login with OpenID from other networks, but the functionality of Mixi user profiles has now increased dramatically thanks to open standards.

Along with mixi’s launch last week, Six Apart released a mixi commenting plugin for Movable Type. (Disclosure: I work for Six Apart) This plugin allows mixi users to comment on Movable Type powered blogs and have their name from their profile show up next to their comment.

All in all, great news for OpenID coming out of Japan!

One of the greatest parts of the OpenID community is that the people developing this technology react so quickly to problems that inevitably arise. There is no such thing as 100% secure with anything on the Internet but we can (and have) put measures into place to react quickly as a community when issues like this occur.

OpenID has two challenges it faces to increase adoption and use; security and usability. This afternoon, Randall Stross of the New York Times published his “Digital Domain” column criticizing OpenID on both of these points. Its great to see people looking at security with regards to OpenID and asking the hard questions and it also highlights a few common misconceptions:

• Authentication is out of scope for OpenID: Because there is no silver bullet for security, the way you authenticate your OpenID is actually out-of-scope of the protocol. As such, you can use whatever level of security you want to protect your OpenID. We have seen vendors offer unique solutions like Verisign’s VIP, JanRain’s CallVerifID and Vidoop’s ImageShield created to provide alternatives to passwords for authenticating users’ OpenID’s. OpenID allows companies both large and small to experiment with ways to authenticate their users without requiring buy-in from sites across the Internet.
• Information Cards solve a different problem than OpenID’s: In his article, Randall mentions how Information Cards are more superior in terms of authentication compared to OpenID. In actuality, you can use an Information Card to secure your OpenID if you want and there has been a lot of work on this within the OpenID community. VeriSign’s OpenID provider even supports Information Cards in addition to token based authentication. Information Cards provide the means to securely authenticate you assuming you have the technology installed on your machine. In addition, Information Cards lack the ability to take advantage of one of OpenID’s main strengths, the destination or URL that a user has proved they own. The potential for this end-point for services is limitless and may serve as one of the key components driving OpenID use; the ability to move data from somewhere on the Internet that you have proved you own.
• Nobody is really adopting OpenID: I’m always surprised to hear people say that just because the big players are only OpenID providers (and not consumers) that we’re failing here. I always try to remind people that this technology is only three years old and we’ve made tremendous strides since its inception. Not only that, the latest graphs continue to show hyperbolic growth. These things take time and again, security and usability will be key drivers to OpenID adoption moving forward.

I’m excited to see a lot of interesting efforts from the community to help with usability. Tom from Barnraiser.org has been doing a series of articles that describe some of these usability issues. We’ve seen community efforts such as Email Address to URL Translation, which allows users to enter their email addresses instead of URL’s and Identity in the Browser (IDIB) which is hoping to bake OpenID functionality (and increased security) into all of the modern browsers.

On the security front, we’re seeing traction in the development of the OpenID Provider Authentication Policy Extension (PAPE) which will help sites be able to determine which providers they will trust based on the means of authentication the user has used to get access. Both Sxip and JanRain have implemented early prototypes of PAPE on their OpenID providers.

We’ve got a long way to go here with OpenID and getting it to a point where it can stand in the face of criticism but I’m confident of this community that has come together through the first three years to get where we are today. I still firmly believe the best is yet to come.