Open ID Specification Work (Cont.)

From IIW

Session Topic: OPEN ID Specification Work (cont) (TH5B)

Convener: Mike Jones

Notes-taker(s): Mike Jones

Tags for the session - technology discussed/ideas considered:


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


George Fletcher

Nat Sakimura

John Bradley

Pamela Dingle

Tony Nadalin

Dale Olds

Vikas Jain

Breno de Medeiros

Edmund Jay

Mike Jones

Michael Buck



How do we request directional or omnidirectional identifiers?

In OpenID 2.0, could only request directional identifiers.  ICAM profile has PAPE parameter to ask for directional identifiers.

Decision:  Allow “idType” claim value in request.  Default type is omnidirectional.

IdPs should be allowed to only support one idType.

MUST be illegal to return omnidirectional if directional or ephemeral requested.

Discussion:  “ephemeral”, “transactional” may be a request types we define in the future, based upon use cases.


Unsigned JWT:  base64url({“sig”:”none”}).base64url({claims…}).


Breno:  Define maxAuthAge=seconds query parameter as common case

Breno:  If a defined parameter occurs twice, it should be an error


Nat:  Wants requested language preference of RP to be expressible to IdP.  Canada wants the same thing.


==

Final remaining open issue:  OpenID 2.0 compatibility/migration issues


One element of support:  “openid_identifier” UserInfo field

OpenID 2.0 allows identifier delegation – we already decided not to support this in ABC

George:  Need a way for IdP to say that old identifier and new identifier are the same

Breno:  Treat identifier migration as a form of account recovery – John:  it’s an account linking problem


Breno:  need to define an OpenID discovery endpoint to allow OPs to discover the clientID of RP realm for the issuer to enable migration


Breno:  For compatibility, have openid_realm parameter in request, which must match beginning substring of redirect URI               

  • Then can generate OpenID 2.0 OP local identifier and put it in the UserInfo endpoint


RP must verify that OP is authoritative for OP local identifier returned

Need OpenID 2.0 service that identifies OpenID ABC endpoint


WE APPEAR TO HAVE CLOSED ALL THE OPEN ISSUES!!!


Spec editing tasks:

Revise spec to reference (not include!) OAuth 2.0

Breno:  Spec as a whole needs to be reworked to be much more readable, complete

John:  John, Nat, Mike together in Munich next week – take an initial pass at it together

Compatibility not in core spec – Breno volunteered for this

UserInfo endpoint schema in its own spec – Pamela volunteered for this

Claims request and claims response – Mike will write up, Edmund will then turn into spec language

Retrieved from "https://iiw.identitycommons.net/index.php?title=Open_ID_Specification_Work_(Cont.)&oldid=4272"