Returning a scope parameter with issued tokens is not a bad idea. But this, and also the sites parameter suggested by James, can both potentially be solved with a transparent token format. Such a token can make explicit the: - expiry time - scopes - sites - etc.
The Simple Web Token spec goes along these lines. SWT has a parameter called Audience, which I assumed would point to the client, but it could also represent "sites". Marius On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Additionally, I would propose to indicate the scope associated with a token > to the client using a scope response parameter. This is especially useful > (1) if the client did not pass a scope parameter but the server decided to > associate a scope based on its policy or (2) if the user decided to > authorize a subset of the requested scope only. > Regards, > Torsten. > > > > Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt > <tors...@lodderstedt.net>: > > what about an additional realm response value? > > If there is a binding between realm and token, the client can decide based > on the realm attribute discovered using a WWW-Authenticate response which > token to use. > > regards, > Torsten. > > Am 07.05.2010 07:06, schrieb Manger, James H: > > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clients > being told by the server about the sites at which the secret > (cookie/password/token) can be used (and, more importantly, where is must > not be used). This occurs without requiring service-specific knowledge in > the client app. OAuth aims to replace some of these uses. > > > > HTTP Basic authentication works safely from clients with no service-specific > knowledge because the client knows not to send the password it gets from the > user to other sites. > > > > HTTP Digest authentication allows a password to used to across a set of > domains specified in a WWW-Authenticate response header, but the password > will not be used at arbitrary other sites. > > > > Cookies are sent in requests to the same site, sites with the same parent, > or only https sites, depending on details from the service when setting the > cookie. > > > > > > To date, OAuth has assumed every client app has lots of service-specific > knowledge to make these choices. OAuth needs to remove the need for so much > service-specific knowledge to be as interoperable as other standard auth > mechanism, otherwise it is a poor replacement. > > > > -- > > James Manger > > > > From: David Recordon [mailto:record...@gmail.com] > Sent: Friday, 7 May 2010 2:05 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > > > > Hey James, > > Do you have a specific example in mind where this either has been an issue > or will be an issue? Most client implementations I've seen of OAuth (and > technologies like OAuth) have a strong binding between the access token(s), > site they were issued by, and user they belong to. So I haven't heard of > this being a problem in the wild... > > > > --David > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
