Open ID Specification Work
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