[Openid-specs-ab] Spec call notes 23-May-11
Mike Jones
Michael.Jones at microsoft.com
Tue May 24 19:34:17 UTC 2011
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