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

Breno de Medeiros breno at google.com
Wed May 11 15:31:53 UTC 2011


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

In the previous sentence, please note that the verbing of 'obsolete'
is probably non-compliant with the US English grammar specs.

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



-- 
--Breno


More information about the Openid-specs-ab mailing list