OpenID Connect love/hate - 23rd

Notes

Ajay explains the reason for the session: is there a use case for OpenID Connect next to SAML, should it replace SAML or should we ignore it.

Joost points out that hub-n-spoke federations could implement OpenID Connect as "just another protocol"

Ajay ask whether there are SPs that already support OIDC; Joost says no

Joost points out we had the same approach with OpenID 2; implemented on federation hub; no SPs have shown up so far that connect through OID2

Ajay mentions that an implementation of OIDC will be made on top of the OAuth2 implementation made by GN3-JRA3-T2; currently there is no developer available though

Roland 1 says there are OIDC implementations in Java, Ruby, JavaScript; they don't align with the last version of the spec though. Roland 1 explains how difficult it is to implement OIDC currently since most of the underlying specs are still moving targets. The analogy of houses is used; we have a roof but no foundation. Luckily, most of the underlying standards haven't changed very much in recent times and are pretty stable; still, they are in flux and have not been finalised as RFCs (or the equivalent thereof in other standardisation bodies)

Roland 2 asks Roland 1 if there is a movement toward a stable spec; Roland 1 says that the core team now perceives the standard as stable so we should see a final spec soonish

Ajay asks who will be the big players in OIDC in the near future (from an implementation perspective); Roland 1 says: AOL, eBay, Gluu, Google, IBM, MyTrip, Orange, PingIdentity, and a number of personal implementations (some quite good, some research-producty)

Roland 1 explains how he collaborates with Andreas on their implementation. Andreas did the front end, user facing stuff, Roland 1 did all the protocol stuff that runs in the background.

Roland 1 mentions that he als knows people implementing OIDC in PHP, in Japan.

We now go into the business case of supporting OIDC

Roland 1 mentions that users showing up at universities will have an identity at some IDP that supports OIDC (i.e. social login). So from the perspective of account linking, or for bootstrapping identity management we can use their OIDC identities. 

Joost approaches the discussion from a different perspective. The driving force for him to support OIDC would be service providers moving to OIDC.

We discuss whether we will see more consumption of third party identities with the introduction of OIDC. Roland 1 believes this to be the case since there would be a convergence to one protocol for social identities.

We discuss the merits of OIDC vs SAML and whether one would win over the other. We conclude that OIDC and SAML differ in perspective; OIDC is "person-centric", SAML is more "organisation-centric". There is a huge uptake of SAML in the enterprise arena and there are no signs of that stopping anytime soon; SAML aligns much better with the way of thinking in the enterprise arena.

Ajay asks whether OIDC will allow things that aren't currently possible with SAML

Roland 2 argues that OIDC puts developers in a different mindset since attribute release is done through a backchannel (attribute queries) by default, rather than the de-facto way we use SAML nowadays which is through the front channel. This may open up new possibilities since clients may be designed with a different paradigm in mind.

Roland 1 notes that OIDC also has provenance of attributes built-in by default which is also interesting

Roland 1 also mentions that OIDC allows users to revoke or allow access to certain attributes in an existing relationship with an SP. This is actually supported by most (or all) implementations.

Note, not just hub and spoke.  Several mesh federations can quite happily use openID connect as well.  I think it is inevitable and preferable that SAML and OIDC will live side by side.