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

John Bradley ve7jtb at ve7jtb.com
Tue May 24 19:36:39 UTC 2011


So was that a yes to the schema parameter?

John B.


On 2011-05-24, at 3:34 PM, Mike Jones wrote:

> As a design principle, we have a consensus that all data representations will be JSON.
> 
> I'm not against people defining extensions for other data representations, but, as I see it, they shouldn't occur in or distract this working group from completing its mission.
> 
> 				Cheers,
> 				-- Mike
> 
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Sent: Tuesday, May 24, 2011 12:20 PM
> To: Paul Tarjan
> Cc: Mike Jones; openid-specs-ab at lists.openid.net; awans at google.com; David Recordon
> Subject: Re: [Openid-specs-ab] Spec call notes 23-May-11
> 
> Thinking about it some more it may be better to separate out schema from the serialization.
> 
> There is no particular reason you couldn't ask for graph API schema in a signed JWT or SAML.
> (It is an example,  I am not trying to get you to support SAML for graph API, take a breath)
> 
> Perhaps the parameter should be called schema with openID ,PoCo, and FB_Graph as options.  
> 
> That allows for different serializations of the same schema for those that want it.
> 
> So it would look like:
> 
> 4.3.1 UserInfo Request.
>  Client MAY send request with following parameters to the UserInfo Endpoint to obtain further information about the user.
> 
>  access_token REQUIRED. The access_token obtained above.
>  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.
>  schema OPTIONAL if not included the response may be a proprietary format to support backwards computability.  If present the values are:
>      "openid"  the openID schema
>      "poco"  Potable Contacts Schema
>      "fb_graph"  FaceBook graph API schema
> 	A URL may be passes to define custom schemes not specified by short names.
> 
> John B.
> 
> 
> 
> 
> On 2011-05-24, at 2:27 PM, Paul Tarjan wrote:
> 
>> 
>> 
>> On 5/24/11 8:55 AM, "John Bradley" <ve7jtb at ve7jtb.com> wrote:
>> 
>>> 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.TOC TOC 
>>> 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.
>> 
>> Why are we saving bytes everywhere? Bytes get cheeper, programers 
>> pulling their hair out, do not. I vote
>> 
>> format=openid (or poco, or whatever)
>> format=jwt
>> 
>> 
>> 
>>> 
>>> 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
>>> 
>>> And
>>> 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=...
>> 
>> We accept Ids in the query:
>> 
>> http://graph.facebook.com/?id=218471
>> 
>>> 
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 



More information about the Openid-specs-ab mailing list