Open ID Specification Work

From IIW
Jump to: navigation, search

Session Topic: Open ID Specification Work (TH3&4B)

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:

Thursday 11:30

  • George Fletcher
  • Breno de Medeiros
  • Pamela Dingle
  • Vikas Jain
  • Tony Nadalin
  • Michael Buck
  • John Bradley
  • Nat Sakimura
  • Mike Jones


These people joined us during the lunch hour, as work continued:

  • Dale Olds
  • John Panzer
  • Edmund Jay


We started with the topic of the schema for the UserInfo endpoint.  Chuck Mortimore supplied this input data for the decision:

This is PoCo - also wire compatible with OpenSocial - http://portablecontacts.net/draft-schema.html

This is the early SCIM work.   We based ours on PoCo - I'd like to make sure this is overlapped and wire compatible - http://www.simplecloud.info/

RPX normalizes all their providers to PoCo - https://rpxnow.com/docs#profile_data

Here's detail on how the data that the networks will actually return - https://rpxnow.com/docs/providers


Decision:  Don’t invent something new

Decision:  Adopt a subset of the Portable Contacts schema


Fields in basic set:

  •                Display Name
  •                Nickname
  •                Full Name
  •                Photo
  •                e-Mail Address
  •                URLs (typed, with types including “profile”, “blog”, etc.)
  •                Data of Birth / Age
  •                Equivalent of everything in SREG
  •                Verified e-mail (verified other?)


                              Breno: could define a mechanism to ask about validation of claims (especially e-mail)

                              Mike:  Use claim(s) to express that e-mail and maybe other claims are verified                              

Decision:  Don’t change POCO e-mail format – add verification claim(s) that can be ignored if not understood

                              Decision:  Add “verified” into the POCO structure – parallel to “primary”                Meta – time last modified                Phone number


Breno:  May want to define second set of supplemental attributes that are not in basic set                Address                Organization


Rejected:

  •                providerName – comes at the wrong point in the flow
  •                preferred username


George:  Context and purpose form-fill for site registration


Observation:  POCO contains both fields about me and fields about what I know about others.

Decision:  We are only including fields that are about me.


Nat:  Need to extend to be able to represent information in multiple scripts

Nat has proposal for how to extend fields for multiple scripts

  •                language_script_country
    •                               ISO639_ISO15924_ISO3166

               Example:  http://axschema.org/namePerson#ja_Kana_JP

Breno:  There is an ISO format for this – Nat and Breno will investigate


Decision:  Ignore information you don’t understand


Need to discuss “id”, PPID, ephemeral ID


SCIM “id” stable and omnidirectional


Breno:  “id” omnidirectional, stable, IdP-relative.  Should not be returned if directional identifier in id_token.

Breno:  ID returned from userInfo endpoint should match the one in the id_token.  If directional, call it “ppid”.

Decision:  Single “id” field, and also an ID Type field that can be ignored if not understood.

Defined ID Type values “omnidirectional”, “directional”.  Other understood values MAY be used.


Breno:  For compatibility:  define “openid_identifier” field


Decision:  SCIM externalId, userName don’t make sense in this context