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

Breno de Medeiros breno at google.com
Tue May 24 20:01:47 UTC 2011


On Tue, May 24, 2011 at 12:55, Chuck Mortimore
<cmortimore at salesforce.com> wrote:
> I’d prefer something besides format.    We currently use this parameter for
> indicating the desired serialization.   Can we find a different name?

I'd prefer the name schema because format seems to indicate something
like JSON vs. XML and we are not at this point contemplating such
support.

I support a schema name because otherwise there's not path to ever
change/update the schema.

>
> format:
> 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.
>
> -cmort
>
>
> On 5/24/11 11:32 AM, "John Bradley" <ve7jtb at 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> 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
>>>
>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>



-- 
--Breno


More information about the Openid-specs-ab mailing list