> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Yaron Goland > Sent: Tuesday, May 11, 2010 4:29 PM > To: Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] sites with wildcard > > 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.
Tokens can be short lived - that's why we have refresh tokens. And if there is a chance of the sites list changing, the tokens should not be issued to overlap with such a change. But in general, this is really not a real concern in any production environment where people lose control over their domain names in such a timeframe. > 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. That's a very bad user experience (having to grand access again for the same client), assuming there even is a user to bug about authorization. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
