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

Chuck Mortimore cmortimore at salesforce.com
Tue May 24 20:13:32 UTC 2011



On 5/24/11 1:00 PM, "John Bradley" <ve7jtb at ve7jtb.com> wrote:

I just proposed making it schema.  I think that is clearer.

It also avoids stepping on your use case for format.

John B.
On 2011-05-24, at 3:55 PM, Chuck Mortimore wrote:

I'd prefer something besides format.    We currently use this parameter for indicating the desired serialization.   Can we find a different name?

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.


On 5/24/11 11:32 AM, "John Bradley" <ve7jtb at ve7jtb.com <x-msg://370/ve7jtb@ve7jtb.com> > wrote:

Nice rant:)   format it is.

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?

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.

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 <x-msg://370/ve7jtb@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 <x-msg://370/Openid-specs-ab@lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net <x-msg://370/Openid-specs-ab@lists.openid.net>

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

More information about the Openid-specs-ab mailing list