is OpenID Connect on the roadmap?

[Cantor, Scott]

On 11/1/12 8:35 AM, "mike at gluu.org" <mike at gluu.org> wrote:
>
>1) The idea that OpenID Connect is only for large consumer IDPs is
>misleading.

Do you believe that the forces behind that technology are supportive of a
world with many IdPs? I do not.

That's not about technology, but about avoiding hard problems and using
the pressures of hard problems to drive people toward a business model
that serves their interests. It's a happy "accident".

>I think the idea is that universities need to use the same
>federation protocol as large consumer IDPs--but obviously your "university
>identity" is needed to control access to university resources.  For better
>or worse, SAML has not been widely adopted by websites on the Internet.

Neither has a meaningful trust or security model. That's not an accident
or coincidence, or a function of technology.

>3) OAuth2 went standard at the IETF several weeks ago. This is a major
>achievement, and dismissing it is misleading.

If you want to know my opinion of OAuth, read Eran's blog when he left the
working group, because I'm in total agreement about it.

> The JOSE standard is in the
>final stages of approval--this is the JSON equivalent of SAML assertions
>(signed tokens).

No, it's not. JWT is the parallel. JOSE is the parallel to XML
signature/encryption.

>4) Peter is correct that IDP initiated workflow is out of scope for OpenID
>Connect.

It should be, that¹s a security problem, and has been for SAML all along.

>5) In my opinion, having a hook for authorization at the IDP greatly
>improves an IDP's functionality. Although YouApprove was good work, this
>is something SAML never addressed with proven usability.

How is trust protocol agnostic, but this isn't? "SAML" doesn't have to
address it, any more then OpenID did or will. It's orthogonal. SAML
products might have to, that's a different matter.

But part of the reason for the V3 work was to get the framework in place
to support those hooks.

>With that said... at a high level, I completely agree with Peter's
>conclusion, but for a slightly different reason. I made the case to Nicole
>Harris at RSA Europe that perhaps the Shibboleth Foundation should align
>with the OX project (http://ox.gluu.org) for OpenID Connect support. All
>OX code is currently MIT license (could be converted to Apache2), and the
>server is one of the most comprehensive (as confirmed in the last interop:
>http://openidtest.uninett.no/results) How is Shibboleth going to add value
>by re-implementing the same endpoints?

We may not, in which case it won't make sense to do it. But if we think
the code that exists sucks, or doesn't provide the kind of feature set we
want, then we might well decide we should.

But as with everything else that we add, we usually do it because people
want a single software stack that does multiple things. We may add value
simply because of that, and ultimatey that will be decided by the funding
sources of the project with the input of the project team.

-- Scott