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

Nat Sakimura sakimura at gmail.com
Wed May 11 15:31:55 UTC 2011


Good idea.

On Thu, May 12, 2011 at 12:28 AM, 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. 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
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110512/ff5a6ddb/attachment.html>


More information about the Openid-specs-ab mailing list