Good idea. <br><br><div class="gmail_quote">On Thu, May 12, 2011 at 12:28 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, May 11, 2011 at 07:29, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a>> wrote:<br>
> On Wed, May 11, 2011 at 01:14, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br>
>> For language and script descriptor, we have RFC4646 and RFC4647.<br>
>> It uses ja-Kana-JP like notation, i.e., "hyphen"<br>
>> In the proposal, I changed the hyphen to underscore "_" because PHP replaces<br>
>> "-" that it received as part of parameter name with "_".<br>
>> I am fine with sticking with RFC4646/7 but we should make the PHP community<br>
>> aware of the replacement if we do.<br>
><br>
> I am in favor of following existing specs on this.<br>
<br>
</div>Also, the spec should not refer to RFC 4646/7 directly, but instead to BCP 47<br>
<br>
RFC 4646/7 and its predecessors define specific sets of language tags.<br>
Whenever a new set of language specs is approved by the IETF<br>
Internationalization WG a new RFC spec must be issued, and the latest<br>
one is marked deprecated. This is necessary so that folks have stable<br>
targets to demonstrate compliance against.<br>
<br>
BCP 47 is the 'cover' spec for that spec series -- it does not define<br>
specific language tag sets, but is regularly updated with references<br>
to the most recent definition spec. It would be appropriate to refer<br>
to BCP 47 so that our spec is not obsoleted by the addition of new<br>
language tags. Nobody needs to demonstrate compliance against BCP 47,<br>
and in any case most IDPs do not and will never support the full set<br>
of tags defined in any of these RFCs.<br>
<div><div></div><div class="h5"><br>
><br>
>> =nat<br>
>> On Fri, May 6, 2011 at 8:02 AM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>><br>
>> wrote:<br>
>>><br>
>>> Session: OpenID Specification Work<br>
>>><br>
>>> Organizer: Mike Jones<br>
>>><br>
>>> When: May 5, 2011, 11:30 (Sessions 3 & 4), Room B<br>
>>><br>
>>> Note Taker: Mike Jones<br>
>>><br>
>>><br>
>>><br>
>>> Thursday 11:30<br>
>>><br>
>>><br>
>>><br>
>>> George Fletcher<br>
>>><br>
>>> Breno de Medeiros<br>
>>><br>
>>> Pamela Dingle<br>
>>><br>
>>> Vikas Jain<br>
>>><br>
>>> Tony Nadalin<br>
>>><br>
>>> Michael Buck<br>
>>><br>
>>> John Bradley<br>
>>><br>
>>> Nat Sakimura<br>
>>><br>
>>> Mike Jones<br>
>>><br>
>>><br>
>>><br>
>>> These people joined us during the lunch hour, as work continued:<br>
>>><br>
>>> Dale Olds<br>
>>><br>
>>> John Panzer<br>
>>><br>
>>> Edmund Jay<br>
>>><br>
>>><br>
>>><br>
>>> We started with the topic of the schema for the UserInfo endpoint. Chuck<br>
>>> Mortimore supplied this input data for the decision:<br>
>>><br>
>>> · This is PoCo - also wire compatible with OpenSocial -<br>
>>> <a href="http://portablecontacts.net/draft-schema.html" target="_blank">http://portablecontacts.net/draft-schema.html</a><br>
>>><br>
>>> · This is the early SCIM work. We based ours on PoCo - I'd like<br>
>>> to make sure this is overlapped and wire compatible -<br>
>>> <a href="http://www.simplecloud.info/" target="_blank">http://www.simplecloud.info/</a><br>
>>><br>
>>> · RPX normalizes all their providers to PoCo -<br>
>>> <a href="https://rpxnow.com/docs#profile_data" target="_blank">https://rpxnow.com/docs#profile_data</a><br>
>>><br>
>>> · Here's detail on how the data that the networks will actually<br>
>>> return - <a href="https://rpxnow.com/docs/providers" target="_blank">https://rpxnow.com/docs/providers</a><br>
>>><br>
>>><br>
>>><br>
>>> Decision: Don’t invent something new<br>
>>><br>
>>> Decision: Adopt a subset of the Portable Contacts schema<br>
>>><br>
>>><br>
>>><br>
>>> Fields in basic set:<br>
>>><br>
>>> Display Name<br>
>>><br>
>>> Nickname<br>
>>><br>
>>> Full Name<br>
>>><br>
>>> Photo<br>
>>><br>
>>> e-Mail Address<br>
>>><br>
>>> URLs (typed, with types including “profile”, “blog”, etc.)<br>
>>><br>
>>> Data of Birth / Age<br>
>>><br>
>>> Equivalent of everything in SREG<br>
>>><br>
>>> Verified e-mail (verified other?)<br>
>>><br>
>>> Breno: could define a mechanism to ask about<br>
>>> validation of claims (especially e-mail)<br>
>>><br>
>>> Mike: Use claim(s) to express that e-mail<br>
>>> and maybe other claims are verified<br>
>>><br>
>>> Decision: Don’t change POCO e-mail format –<br>
>>> add verification claim(s) that can be ignored if not understood<br>
>>><br>
>>> Decision: Add “verified” into the POCO<br>
>>> structure – parallel to “primary”<br>
>>><br>
>>> Meta – time last modified<br>
>>><br>
>>> Phone number<br>
>>><br>
>>><br>
>>><br>
>>> Breno: May want to define second set of supplemental attributes that are<br>
>>> not in basic set<br>
>>><br>
>>> Address<br>
>>><br>
>>> Organization<br>
>>><br>
>>><br>
>>><br>
>>> Rejected:<br>
>>><br>
>>> providerName – comes at the wrong point in the flow<br>
>>><br>
>>> preferred username<br>
>>><br>
>>><br>
>>><br>
>>> George: Context and purpose form-fill for site registration<br>
>>><br>
>>><br>
>>><br>
>>> Observation: POCO contains both fields about me and fields about what I<br>
>>> know about others.<br>
>>><br>
>>> Decision: We are only including fields that are about me.<br>
>>><br>
>>><br>
>>><br>
>>> Nat: Need to extend to be able to represent information in multiple<br>
>>> scripts<br>
>>><br>
>>> Nat has proposal for how to extend fields for multiple scripts<br>
>>><br>
>>> #language_script_country<br>
>>><br>
>>> #ISO639_ISO15924_ISO3166<br>
>>><br>
>>> Example: <a href="http://axschema.org/namePerson#ja_Kana_JP" target="_blank">http://axschema.org/namePerson#ja_Kana_JP</a><br>
>>><br>
>>> Breno: There is an ISO format for this – Nat and Breno will investigate<br>
>>><br>
>>><br>
>>><br>
>>> Decision: Ignore information you don’t understand<br>
>>><br>
>>><br>
>>><br>
>>> Need to discuss “id”, PPID, ephemeral ID<br>
>>><br>
>>><br>
>>><br>
>>> SCIM “id” stable and omnidirectional<br>
>>><br>
>>><br>
>>><br>
>>> Breno: “id” omnidirectional, stable, IdP-relative. Should not be<br>
>>> returned if directional identifier in id_token.<br>
>>><br>
>>> Breno: ID returned from userInfo endpoint should match the one in the<br>
>>> id_token. If directional, call it “ppid”.<br>
>>><br>
>>> Decision: Single “id” field, and also an ID Type field that can be<br>
>>> ignored if not understood.<br>
>>><br>
>>> Defined ID Type values “omnidirectional”, “directional”. Other understood<br>
>>> values MAY be used.<br>
>>><br>
>>><br>
>>><br>
>>> Breno: For compatibility: define “openid_identifier” field<br>
>>><br>
>>><br>
>>><br>
>>> Decision: SCIM externalId, userName don’t make sense in this context<br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Openid-specs-ab mailing list<br>
>>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Nat Sakimura (=nat)<br>
>> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
>> <a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> --Breno<br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<font color="#888888">--Breno<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>