[Openid-specs-ab] Notes from UserInfo endpoint discussions at IIW

Mike Jones Michael.Jones at microsoft.com
Tue May 24 00:39:53 UTC 2011



From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Mike Jones
Sent: Thursday, May 05, 2011 4:03 PM
To: iiwnotes at gmail.com; openid-specs-ab at lists.openid.net
Cc: John Panzer; Dale Olds; George Fletcher; Jain, Vikas; Michael Buck
Subject: [Openid-specs-ab] Notes from Thursday mid-day IIW OpenID Specification session

Session:  OpenID Specification Work
Organizer:  Mike Jones
When:  May 5, 2011, 11:30 (Sessions 3 & 4), Room B
Note Taker:  Mike Jones

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110524/21921221/attachment-0001.html>


More information about the Openid-specs-ab mailing list