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

Breno de Medeiros breno at google.com
Wed May 11 15:28:41 UTC 2011


On Wed, May 11, 2011 at 07:29, Breno de Medeiros <breno at google.com> wrote:
> 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.

Also, the spec should not refer to RFC 4646/7 directly, but instead to BCP 47

RFC 4646/7 and its predecessors define specific sets of language tags.
Whenever a new set of language specs is approved by the IETF
Internationalization WG a new RFC spec must be issued, and the latest
one is marked deprecated. This is necessary so that folks have stable
targets to demonstrate compliance against.

BCP 47 is the 'cover' spec for that spec series -- it does not define
specific language tag sets, but is regularly updated with references
to the most recent definition spec. It would be appropriate to refer
to BCP 47 so that our spec is not obsoleted by the addition of new
language tags. Nobody needs to demonstrate compliance against BCP 47,
and in any case most IDPs do not and will never support the full set
of tags defined in any of these RFCs.

>
>> =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
>



-- 
--Breno


More information about the Openid-specs-ab mailing list