It's almost ideal for the government use-case: private sector IDCs can offer identity/attribute verification services if the government provides an assurance and audit framework. The potential number of digital commercial transactions this could enable are mind-boggling. It's also privacy-preserving due to its attributes-based approach to access control and its federated nature.
Also likely to result in a competitive market for IDCs instead of YAGM (yet another government monopoly) due to the low (technical) barrier to entry: I'm a terrible programmer and I spent less time coding a mock RP/client implementation straight from the spec than I did searching around for pre-canned libraries (which didn't seem to exist at the time).
It's a shame no-one would listen to us. From what I hear, they're going with some kind of centralised RBAC system. Boy it's going to be fun when some welfare payment or tax concession eligibility criteria is tweaked, forcing them to audit and update roles for 10-15 million people :)
Yea..many people only remember the failed OpenID 1 & 2 specs...so, out-of-the-box there is some developer fatigue associated with Connect. However, federation standards have proven to be pretty sticky--SAML was written 10+ years ago. Hopefully as Connect continues to be developed, marketed, and implemented by developers, it will over shadow previous unsuccessful versions of the protocol.
OpenID 2.0 is deprecated. Don't use it.
The current OpenID authentication protocol = OpenID Connect.
In the not too distant future, no one will even remember that something called OpenID 2.0 existed.
Maybe OpenID Connect should be OpenID 3.0? I think the idea was to show alignment with Facebook Connect's design...but more open. Remember, at the time Facebook Connect provided some good data--it was a massive user acceptance test.
IMHO, the blame lies with the OIDF for not delivering this message. OpenID Connect has been final for 4+ years. What's taking so long? Maybe it's not in the interest of the OIDF's controlling board members to promote this distributed identity infrastructure? MSFT wants you to use Azure AD. Google wants you to use their IDP. Maybe they don't want to promote until they have product ready? Stay tuned... I think when it's in the interest of the current finanical backers of the OIDF to promote OpenID Connect, no one will remember that old OpenID 2.0 thing.
They are very different things.
I am glad to see this advice. At CoreOS we have now built API servers, command line tools, and web apps using OpenID Connect and are happy with its development in Open Source and third-party services as well.
> OAuth2 was left generic so that it could be applied to many authorization requirements,
When we started developing Dex[1] we lovingly referred to OpenID as "OAUTH 2.0 with types".
Overall, from integrating OpenID Connect into our products, enabling Kubernetes[2] to use OpenID Connect Providers, and building both an OpenID Connect provider and clients we are pretty happy with the choice we made.
My only complaint is the name of OpenID Connect is simply confusing.
[1] https://github.com/coreos/dex [2] http://kubernetes.io/docs/admin/authentication/#openid-conne...