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