Hey James, I guess the way that we solved this was having the Protected Resource include the access token in links as applicable. We don't do cross site access tokens and I'd hate to see us standardize this more complex use case without real world deployment experience.
Do you have an implementation with this problem that we can look at? Thanks, --David On Mon, May 10, 2010 at 5:31 PM, Manger, James H <[email protected]> wrote: > Yaron, > > > >> I don’t understand the scenario that requires this feature. When does >> someone ask for a token without knowing where it is going? > > > > Example: > > A client app gets a token to make an API call to a protected resource that > returns an Atom feed. > > The feed contains lots of entries, with links to photos, style sheets, and > scripts. > > The client app gets the photos. > > > > Should it send the token when getting the photos? > > > > On service A the Atom feed and the photos are all served from the same HTTPS > host, with the same protection, so the token must be sent. > > > > On service B the photos are hosted on a separate outsourced content > distribution network. The photos are protected by using long unguessable > URIs (the URIs are effectively “capabilities” to read the photos). The token > does not need to be sent. > > > > On service C the photos are any images from anywhere on the Internet that > the user has chosen to link to. The Atom collection is protected, but not > the photos. The token absolutely must not be sent when getting the photos. > > > > > > A client app needs to know whether the service it is accessing is like A, B, > or C. It needs to know for redirects, for links in HTTP headers, for links > to images, for any other sort of link that is can derive from the response. > > > > Some services might be completely walled gardens so the client can assume > they are like A. > > Some services might explicitly state in their documentation: which links and > redirects are always guaranteed to be other API calls (send the token); > which will always be to other security contexts (don’t send the token); and > which might be either (don’t send the token, see if you get a 401/403, > guess, send the token). > > > > In general, the web is about following links. Clients need to know when > following a link crosses a security boundary. Cookies provide this; Basic > provides this; Digest provides this; OAuth needs this too. > > > > > > -- > > James Manger > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
