Re: [OAUTH-WG] Indicating sites where a token is valid

[Evan Gilbert <[e-mail]>]

On Thu, May 13, 2010 at 4:54 PM, Manger, James H <
[e-mail]> wrote:

> Evan,
>
> > we have no API endpoints that are only arrived at by links
>
> This doesn't sound very web-friendly. Your APIs don't have to follow a
> web-style, but an IETF spec should support web-style APIs.


I didn't say that our endpoints can't be arrived at by links. I said our
APIs all can be called directly and clients need to know how to call them
directly.

Clients need to have a way of finding out:
1. The available endpoint URLs, and
2. The scopes to ask for to access these URLs

"sites" by itself is insufficient to be useful to our developers.


> I am a bit surprised with your statement as a whole lot of Google APIs do
> have API endpoints arrived at by links. I thought most Google Data APIs
> followed the Atom Publishing Protocol. This uses links extensively. For
> instance, <link rel="edit" href="..."/> tells the client the API endpoint to
> at which an entry can be updated.
>
> There are lots and lots of <link rel="..." href="..."/> relations defined:
> in the Atom spec, in the APP spec, in GData docs (not specific to particular
> APIs) etc.
>
> Definitions of none of these link relations state that they MUST or MUST
> NOT be part of the same API.
>
>
>
> > Another note: Where do we anticipate clients storing the sites parameter
> in the User-Agent flow? Right now the access token can be set as an HTTP
> cookie by the client. Do we expect them to set a separate "sites" cookie and
> respect this on their server when making requests? This seems complicated.
>
> Presumably the client needs to store the access token, the expiry date,
> perhaps the scopes etc. Easy solution: store the base64-encoding of the JSON
> representation of the token details.
>

Currently the client side flow is really simple:
1. Set access token as a cookie, with
2. An expiration matching the expires_in time

Are you suggesting the client parse the URL parameters, create a JSON block,
base64 encode the block, and then write an HTTP cookie?


>
> --
> James Manger
>
>