I really like the idea behind the "sites" parameter I think this idea relates closely to scopes and probably needs to be bound more tightly to the inbound scope parameter. Both identify a set of protected resources that can be accessed with the token - one is the requested resources, the other is the granted resources. In both cases you need to have a way to find a mapping from protected resource identifier -> API endpoint you can call.
On Mon, May 10, 2010 at 5:18 AM, Richer, Justin P. <[email protected]>wrote: > +1 > > Any information that the client needs to care about should live outside the > token. > > -- Justin > > ------------------------------ > *From:* [email protected] [[email protected]] On Behalf Of Eran > Hammer-Lahav [[email protected]] > *Sent:* Sunday, May 09, 2010 5:29 PM > *To:* David Recordon; Marius Scurtescu > > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid > > The idea of embedding this information into the token is wrong. This is > clearly token metadata and that information belongs alongside the token, > just like ‘expires_in’. > > > > EHL > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *David Recordon > *Sent:* Friday, May 07, 2010 11:06 AM > *To:* Marius Scurtescu > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid > > > > Using SWT for your access tokens seems like a reasonable way to resolve > this for servers which care. > > > > On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu <[email protected]> > wrote: > > 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 > <[email protected]> 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 > > <[email protected]>: > > > > 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:[email protected]] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
