I spent two days at the Internet Identity Workshop 10. IIW events are set in an open space, unconference style. True to its workshop designation, it’s a place to do work collegially. It’s not a place to give scholarly papers or some polished slide gesticulation.
I list hereafter the topics that I engaged on at IIW10, in a similarly frugal style. They complete my sweep of the Identosphere that I had started here.
OAuth 2.0 – The authors clarified several points in the specification (is the refresh token entirely optional? yes) and kindly requested help to turn the I-D into a RFC that can pass muster with the IETF security directorate (esp. for the security considerations section);
UMA – User Managed Access provides a method for a user to control access to her resources, wherever they might be. For this, UMA defines an authorization manager. The authorization manager reacts to requests by online services acting on a user’s behalf and makes access decisions based on user policy. My colleague and identity extraordinaire Eve Maler is a leading force behind this effort. UMA is set to leverage OAuth 2.0 and various card, token technologies. I saw the demo of a UMA system built by the SMART team at Newcastle University;
OpenID Connect – It combines OpenID federated login with OAuth 2.0 access authorization;
PingPong IdP Discovery 1.0 – We all advocate the freedom to register with one or more Identity Providers (IdP) among many available. As such, we need a protocol to assist in the IdP discovery and thus determine which IdP(s) can authenticate a given user;
Mozilla’s account manager – This work exemplifies identity in the browser. Unlike password managers, it includes ways for a site to advertise to the browser multiple styles of identity artifact (e.g. Openid, InfoCards, or plain old passwords) and current state (signed in or not);
A meta-point: These identity systems are distributed systems and, not surprisingly, pose the same challenges as any other distributed system: get the naming rules right, identify and manage all dependencies, spell out consistency requirements and the companion failure semantics, etc.