Mike Jones - OpenID Connect Deep Dive

Questions from the audience:

Q - is OpenID Connect logout similar to SAML single logout?

Mike - it’s simpler than SAML’s logout

John - we’re talking to the SAML folks

Q - are there any reference implementations?

Mike - at present - no. The board should consider funding libraries and implementations.

John - Several implementations from 3rd parties - not official implemenations.

Q - why does the basic profile use the implicit grant, rather than the code flow?

John - The basic document used to have both flows, but this made the basic doc too large. The majority of existing proprietary implementations appear to use the implicit flow. The code flow is safer.

Mike - You can have an RP that uses only javascript using the implicit flow. This seems to be the most common use case for Facebook Connect.

Q - Question regarding how a client can interop with servers without pre-configuration

Mike - Attend the Discovery/Dynamic breakout session later.

Q - Do we have an estimated time for the spec to be finalized?

Mike - probably can get to an implementer's draft within weeks. We should have implementations before declaring the draft finalized.

Q - Discussion topics for breakout sessions: Interoperability issues, relationship between OpenID Connect and OAuth2, Interest in claims aggregation, migration/co-existance with OpenID 2.0 to OpenID Connect, token format, strong auth, multi-factor authentication, logout, test frameworks

OpenID 2.0 / SAML Migration

- Legacy RPs register their OpenID 2.0 realm to the IdP. The IdP returns the legacy OpenID 2.0 and/or SAML identifier in the UserInfo response. The RP will recieve both the legacy OpenID 2.0 and new Connect identifiers.

Realm is needed because of PPID, and directed identity.

No solution for delegation.

RP must also trust that the OP is authoritative for the OpenID 2.0 identifier. Alternatively, the RP can make an OpenID 2.0 request to verify. (overly complicated)

Session Management

- 2 possible flows - user agent driver or webserver client

Webserver not feasible, because not all IdPs support server side sessions

Instead - server side push - IdP hosts a logout page with either iframes or images that hit each RPs logout URL. iframes are heavier, but allow to support IDPs that also an RP.