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