Thanks for explaining, I now believe I understand the use case.
But I would point out that this is really an unsolved problem in general and if
we are to tackle it we have to deal with real concerns such as – what happens
if in the time since the site list was provided and when the token was used the
list was changed? If an attacker now controls a previously listed site then the
attacker can just swallow the bearer token and do bad things. So now we have to
think about expiration information on the site list or a revocation mechanism
or some kind of negotiation.
One wonders if it wouldn’t be simpler for clients that are in doubt to just
make another token request to the original service’s token issuer with a scope
for the desired site. That works with the existing protocol and mitigates the
previous attack.
Just a thought,
Yaron
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Monday, May 10, 2010 5:31 PM
To: Yaron Goland; OAuth WG (oauth@ietf.org)
Subject: RE: sites with wildcard
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
