Re: [OAUTH-WG] sites with wildcard

["Manger, James H" <[e-mail]>]

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