[Openid-specs-ab] Notes from Thursday mid-day IIW OpenID Specification session

[Breno de Medeiros]

On Wed, May 11, 2011 at 01:14, Nat Sakimura <sakimura at gmail.com> wrote:
> For language and script descriptor, we have RFC4646 and RFC4647.
> It uses ja-Kana-JP like notation, i.e., "hyphen"
> In the proposal, I changed the hyphen to underscore "_" because PHP replaces
> "-" that it received as part of parameter name with "_".
> I am fine with sticking with RFC4646/7 but we should make the PHP community
> aware of the replacement if we do.

I am in favor of following existing specs on this.

> =nat
> On Fri, May 6, 2011 at 8:02 AM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>



-- 
--Breno