<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I just proposed making it schema. I think that is clearer.<div><br></div><div>It also avoids stepping on your use case for format.</div><div><br></div><div>John B.</div><div><div><div>On 2011-05-24, at 3:55 PM, Chuck Mortimore wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>
<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="x-msg://370/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="x-msg://370/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="x-msg://370/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="x-msg://370/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>
</div>
</blockquote></div><br></div></body></html>