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

[Nat Sakimura]

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.

=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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110511/8174770d/attachment.html>