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

Tue May 24 20:00:53 UTC 2011

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

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