<HTML>
<HEAD>
<TITLE>Re: [Openid-specs-ab] Spec call notes 23-May-11</TITLE>
</HEAD>
<BODY>
<FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>I&#8217;d prefer something besides format. &nbsp;&nbsp;&nbsp;We currently use this parameter for indicating the desired serialization. &nbsp;&nbsp;Can we find a different name?<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>format:<BR>
Specify the format of the returned output. Valid values are: &quot;urlencoded&quot;, &quot;json&quot;, and &quot;xml&quot;. &nbsp;&nbsp;Instead of using the format parameter, the client can also specify the returned format in an accept-request header using one of the following: &quot;Accept: application/json&quot;, &quot;Accept: application/xml&quot;, &quot;Accept: application/x-www-form-urlencoded&quot;. Wildcard accept headers are allowed. */* is accepted and returns JSON. &nbsp;&nbsp;&nbsp;&nbsp;A list of values is also accepted and is checked left-to-right. The format parameter takes precedence over the accept request header. &nbsp;Optional.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'><BR>
-cmort<BR>
<BR>
<BR>
On 5/24/11 11:32 AM, &quot;John Bradley&quot; &lt;<a href="ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>Nice rant:) &nbsp;&nbsp;format it is.<BR>
<BR>
Do we want to make id=... &nbsp;part of the official openID endpoint API or just leave it to the individual implementations if they want to pass user ID?<BR>
<BR>
In the user info endpoint case if the user ID and access token don't match you would get an error not the other users information.<BR>
<BR>
John B.<BR>
<BR>
On 2011-05-24, at 2:27 PM, Paul Tarjan wrote:<BR>
<BR>
&gt;<BR>
&gt;<BR>
&gt; On 5/24/11 8:55 AM, &quot;John Bradley&quot; &lt;<a href="ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>&gt; wrote:<BR>
&gt;<BR>
&gt;&gt; To capture what I thought I heard agreement on at the end of the call.<BR>
&gt;&gt; The User info endpoint will have a optional parameter.<BR>
&gt;&gt; Sending the user_id is not required.<BR>
&gt;&gt;<BR>
&gt;&gt; 4.3.1 UserInfo Request.<BR>
&gt;&gt; &nbsp;&nbsp;Client MAY send request with following parameters to the UserInfo<BR>
&gt;&gt; Endpoint to obtain further information about the user.TOC<BR>
&gt;&gt; TOC<BR>
&gt;&gt; TOCaccess_token REQUIRED. The access_token obtained above.<BR>
&gt;&gt; &nbsp;&nbsp;user_id OPTIONAL. A locally unique and never reassigned identifier<BR>
&gt;&gt; for the user. e.g. &quot;24400320&quot; or<BR>
&gt;&gt; &quot;AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4&quot;. It MUST NOT exceed 255 ASCII<BR>
&gt;&gt; characters in length. It could be a pairwise private identifier of the<BR>
&gt;&gt; enduser between the Client and the Server.<BR>
&gt;&gt; &nbsp;&nbsp;fmt &nbsp;OPTIONAL if not included the response may be a proprietary<BR>
&gt;&gt; format to support backwards computability. &nbsp;If present the values are:<BR>
&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;nor&quot; (normal) an unsigned JSON object containing the openID<BR>
&gt;&gt; schema<BR>
&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;sig&quot; &nbsp;(signed) the contents are a signed JWT openID schema<BR>
&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Other values may be defined.<BR>
&gt;<BR>
&gt; Why are we saving bytes everywhere? Bytes get cheeper, programers pulling<BR>
&gt; their hair out, do not. I vote<BR>
&gt;<BR>
&gt; format=openid (or poco, or whatever)<BR>
&gt; format=jwt<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; I removed client_id for compatibility with FB. &nbsp;I don't know what it was<BR>
&gt;&gt; adding anyway<BR>
&gt;&gt; We could list &quot;enc&quot; encrypted as a option, but I don't think it adds<BR>
&gt;&gt; anything as a option to the fmt parameter.<BR>
&gt;&gt; We could add a fb_graph option to make it clear when people are looking<BR>
&gt;&gt; for that. &nbsp;Other providers might want to support it.<BR>
&gt;&gt; Are there others we want to list?<BR>
&gt;&gt;<BR>
&gt;&gt; We need to define an error format in 4.3.3 for when someone asks for an<BR>
&gt;&gt; unsupported format. &nbsp;Something like a list of supported formats?<BR>
&gt;&gt;<BR>
&gt;&gt; So in the Facebook case you would send:<BR>
&gt;&gt; <a href="https://graph.facebook.com/me?access_token=..">https://graph.facebook.com/me?access_token=..</a>. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;To get the Facebook<BR>
&gt;&gt; version<BR>
&gt;&gt;<BR>
&gt;&gt; And<BR>
&gt;&gt; <a href="https://graph.facebook.com/me?fmt=nor&amp;access_token=..">https://graph.facebook.com/me?fmt=nor&amp;access_token=..</a>. &nbsp;&nbsp;To get the basic<BR>
&gt;&gt; openID user Info schema.<BR>
&gt;&gt;<BR>
&gt;&gt; I am expecting some folks to complain about the parameter names wanting<BR>
&gt;&gt; &quot;format&quot; instead of &quot;fmt&quot; etc.<BR>
&gt;<BR>
&gt; :)<BR>
&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; Facebook includes the user ID in the path rather than as a parameter. &nbsp;I<BR>
&gt;&gt; am assuming that for the openID endpoint we want to leave out the user ID<BR>
&gt;&gt; and let people add it back in what ever way works with there existing API?<BR>
&gt;&gt;<BR>
&gt;&gt; Paul, what happens if you do just<BR>
&gt;&gt; <a href="https://graph.facebook.com/?access_token=..">https://graph.facebook.com/?access_token=..</a>.<BR>
&gt;<BR>
&gt; We accept Ids in the query:<BR>
&gt;<BR>
&gt; <a href="http://graph.facebook.com/?id=218471">http://graph.facebook.com/?id=218471</a><BR>
&gt;<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; John B.<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; On 2011-05-23, at 8:24 PM, Mike Jones wrote:<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; Paul Tarjan<BR>
&gt;&gt; Breno de Medeiros<BR>
&gt;&gt; Marius Scurtescu<BR>
&gt;&gt; Andrew Wansley<BR>
&gt;&gt; John Bradley<BR>
&gt;&gt; Mike Jones<BR>
&gt;&gt; David Recordon<BR>
&gt;&gt;<BR>
&gt;&gt; We started the call late because the OAuth working group meeting had just<BR>
&gt;&gt; finished. &nbsp;All the open OAuth issues were discussed and either resolved<BR>
&gt;&gt; or action items were assigned to resolve them. &nbsp;All but John met in<BR>
&gt;&gt; person at Facebook. &nbsp;Facebook plans to publish this an OAuth extension.<BR>
&gt;&gt;<BR>
&gt;&gt; Paul wants to ship these soon:<BR>
&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;display=always, which always forces a user dialog,<BR>
&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;display=none, in which there is no user dialog, and user<BR>
&gt;&gt; state is sent to the redirect URI in the fragment<BR>
&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;user state can be one of {authorized, unauthorized,<BR>
&gt;&gt; unknown}<BR>
&gt;&gt;<BR>
&gt;&gt; Breno will write up a response_type=none OAuth extension, which just<BR>
&gt;&gt; redirects to the redirect URI without credentials.<BR>
&gt;&gt;<BR>
&gt;&gt; Marius wondered if the result should be an error, not a special result<BR>
&gt;&gt;<BR>
&gt;&gt; Facebook has two endpoints: &nbsp;userinfo endpoint and access token<BR>
&gt;&gt; inspection endpoint<BR>
&gt;&gt;<BR>
&gt;&gt; Paul wants the token validation endpoint to also be able to accept an<BR>
&gt;&gt; access token, returning the access token as a result. &nbsp;Facebook doesn&#8217;t<BR>
&gt;&gt; currently send an id_token. &nbsp;Breno believes this optimization is<BR>
&gt;&gt; necessary. &nbsp;Interop could be achieved by calling the calling the endpoint<BR>
&gt;&gt; to get the token that way.<BR>
&gt;&gt;<BR>
&gt;&gt; Breno discussed having a static endpoint containing public keys to enable<BR>
&gt;&gt; dynamic client registration.<BR>
&gt;&gt;<BR>
&gt;&gt; For anti-spam purposes, Paul doesn&#8217;t want dynamic apps to be able be<BR>
&gt;&gt; easily created and be spam sources. &nbsp;Breno and John discussed that<BR>
&gt;&gt; support for dynamic clients can be optional in the spec. &nbsp;We all agreed<BR>
&gt;&gt; that the method for dynamic registration is necessary for an OpenID spec.<BR>
&gt;&gt; This work is being deferred until later in the process when the problem<BR>
&gt;&gt; is better understood.<BR>
&gt;&gt;<BR>
&gt;&gt; David questioned the adoption of Portable Contacts schemas because it&#8217;s<BR>
&gt;&gt; not like what Facebook and Live are doing. &nbsp;Breno asked for a concrete<BR>
&gt;&gt; counter-proposal. &nbsp;Mike emphasized that the primary decision was not to<BR>
&gt;&gt; create a new schema. &nbsp;Breno said that a schema identifier could be passed<BR>
&gt;&gt; to the userinfo endpoint to select between data representations. &nbsp;Paul<BR>
&gt;&gt; likes format=OpenID when querying userinfo endpoint.<BR>
&gt;&gt;<BR>
&gt;&gt; Facebook is using their signed request format documented at<BR>
&gt;&gt; <a href="http://developers.facebook.com/docs/authentication/signed_request/">http://developers.facebook.com/docs/authentication/signed_request/</a> rather<BR>
&gt;&gt; than JWTs at present. &nbsp;They&#8217;re worried about the switching cost at<BR>
&gt;&gt; present.<BR>
&gt;&gt;<BR>
&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- Mike<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; _______________________________________________<BR>
&gt;&gt; Openid-specs-ab mailing list<BR>
&gt;&gt; <a href="Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><BR>
&gt;&gt; <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;<BR>
<BR>
_______________________________________________<BR>
Openid-specs-ab mailing list<BR>
<a href="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">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>