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

[Paul Tarjan]

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
>
>
>
>
>