[Openid-specs-ab] Spec call notes 23-May-11

John Bradley ve7jtb at ve7jtb.com
Tue May 24 15:55:01 UTC 2011

To capture what I thought I heard agreement on at the end of the call.

The User info endpoint will have a optional parameter.
Sending the user_id is not required.

4.3.1 UserInfo Request.
	Client MAY send request with following parameters to the UserInfo Endpoint to obtain further information about the user.
TOCaccess_token REQUIRED. The access_token obtained above.
	user_id OPTIONAL. A locally unique and never reassigned identifier for the user. e.g. "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length. It could be a pairwise private identifier of the enduser between the Client and the Server.
	fmt  OPTIONAL if not included the response may be a proprietary format to support backwards computability.  If present the values are:
		"nor" (normal) an unsigned JSON object containing the openID schema
		"sig"  (signed) the contents are a signed JWT openID schema
		Other values may be defined.

I removed client_id for compatibility with FB.  I don't know what it was adding anyway
We could list "enc" encrypted as a option, but I don't think it adds anything as a option to the fmt parameter.
We could add a fb_graph option to make it clear when people are looking for that.  Other providers might want to support it.
Are there others we want to list?

We need to define an error format in 4.3.3 for when someone asks for an unsupported format.  Something like a list of supported formats?

So in the Facebook case you would send:
https://graph.facebook.com/me?access_token=...      To get the Facebook version

https://graph.facebook.com/me?fmt=nor&access_token=...   To get the basic openID user Info schema.

I am expecting some folks to complain about the parameter names wanting "format" instead of "fmt" etc.

Facebook includes the user ID in the path rather than as a parameter.  I am assuming that for the openID endpoint we want to leave out the user ID and let people add it back in what ever way works with there existing API?

Paul, what happens if you do just https://graph.facebook.com/?access_token=...   

John B.

On 2011-05-23, at 8:24 PM, Mike Jones wrote:

> Paul Tarjan
> Breno de Medeiros
> Marius Scurtescu
> Andrew Wansley
> John Bradley
> Mike Jones
> David Recordon
> We started the call late because the OAuth working group meeting had just finished.  All the open OAuth issues were discussed and either resolved or action items were assigned to resolve them.  All but John met in person at Facebook.  Facebook plans to publish this an OAuth extension.
> Paul wants to ship these soon:
>                display=always, which always forces a user dialog,
>                display=none, in which there is no user dialog, and user state is sent to the redirect URI in the fragment
>                user state can be one of {authorized, unauthorized, unknown}
> Breno will write up a response_type=none OAuth extension, which just redirects to the redirect URI without credentials.
> Marius wondered if the result should be an error, not a special result
> Facebook has two endpoints:  userinfo endpoint and access token inspection endpoint
> Paul wants the token validation endpoint to also be able to accept an access token, returning the access token as a result.  Facebook doesn’t currently send an id_token.  Breno believes this optimization is necessary.  Interop could be achieved by calling the calling the endpoint to get the token that way.
> Breno discussed having a static endpoint containing public keys to enable dynamic client registration.
> For anti-spam purposes, Paul doesn’t want dynamic apps to be able be easily created and be spam sources.  Breno and John discussed that support for dynamic clients can be optional in the spec.  We all agreed that the method for dynamic registration is necessary for an OpenID spec.  This work is being deferred until later in the process when the problem is better understood.
> David questioned the adoption of Portable Contacts schemas because it’s not like what Facebook and Live are doing.  Breno asked for a concrete counter-proposal.  Mike emphasized that the primary decision was not to create a new schema.  Breno said that a schema identifier could be passed to the userinfo endpoint to select between data representations.  Paul likes format=OpenID when querying userinfo endpoint.
> Facebook is using their signed request format documented at http://developers.facebook.com/docs/authentication/signed_request/ rather than JWTs at present.  They’re worried about the switching cost at present.
>                                                             -- Mike
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110524/a37f2f59/attachment.html>

More information about the Openid-specs-ab mailing list