Hi, I am Nat Sakimura, the chairman of the OpenID Foundation, and a senior Researcher at Nomura Research Institute. Today, I want to talk a bit about the new identity protocol we are building: OpenID Connect, an identity layer on top of Oauth 2.0. But before diving into it, I need to define “identity”, which we often talk vaguely. Luckily, ITU-T and ISO has defined it in the IT context for us: it is “Set of attributes related to an entity” To understand this definition, we have to understand entity identity model. Entity is like us, human being, or machines, services, whatever. But we do not perceive entities directly, but indirectly through various attributes about the entity, like he has blond hair, wears glasses, 6 feet 5 inches tall, etc. and we want to express ourselves depending on who we are talking to by controlling what set of attributes, identity, we show. So, your identity to your friends and identity to your boss are naturally different so we have multiple identities Men are said to have typically a few identities, like Work, Husband, Father and women have a lot more We pick and choose which identity we use depending on the context The same holds for web sites. You want to use different identities depending on the sites you go to get better service. That’s the identity layer, and with OpenID Connect, we have chosen to build it over OAuth 2.0. This is often called “Authentication” as well. But you may ask “Why not just OAuth? Facebook does the same with OAuth do not they? Well, not quite. OAuth itself has no notion of identity. OAuth is an access granting protocol, also known as delegation. Alice granting an access to Betty’s profile data to Cindy does not mean that Alice is Betty nor Cindy is Betty. Unfortunately though, many services make this mistake and make it easy for a service to impersonate a user. Facebook’s case is different. They do not use OAuth for authentication as is, , but have built an extension called signed request, which is essentially the same as the OpenID Connect’s ID_token, except for the fact that it works only with facebook as the identity identity provider, and the signature format is proprietary while OpenID Connect works with multiple IdPs and uses IETF’s JSON Web Signature standard. In essence, what it does is to provide the web sites “Who got authenticated”, “Where, When and How it was”, “What attributes he want to give to you and Why” All of these defined in an interoperable manner — that is OpenID Connect. It is Interoperable Simple & mobile friendly, secure and flexible To be interoperable, we have to define a standard way of requesting and responding claims. So we have defined standard scopes, a method to ask for more granular claims, ID Token and UserInfo endpoint from which you can get the attributes as well as the translated tokens. It’s also very simple. It is JSON based, REST friendly, in simplest cases, it’s just copy and paste to implement a simple relying party and mobile and that’s friendly because that was an explicit design principle and thanks to OAuth 2. Its security model can scale all the way up to extremely secure, spanning from ISO 29115 Level of Assurance 1 to 4 leveraging on crypto and other techniques. It’s also very flexible. You can make a granular request through JSON based request object, which makes data minimization easy. To return the claims, you have the choice of aggregated and distributed claims with different privacy characteristics. OpenID Connect not only supports large identity providers, but you can actually have your own identity providers. For example, you can choose to use a dedicated identity provider on your phone. Current status of the specs are that they are waiting for some underpinnings such as JOSE specs and webfinger go final. Once that is done, we can finalize OpenID Connect and put it to the final membership vote. In the meantime, people are implementing current draft. Right now, 14 solutions are performing interops encompassing over 120 feature tests. So, start Building OpenID Now!