Re: [OAUTH-WG] Indicating sites where a token is valid

[Evan Gilbert <[e-mail]>]

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. <[e-mail]>wrote:

>  +1
>
> Any information that the client needs to care about should live outside the
> token.
>
>  -- Justin
>
>  ------------------------------
> *From:* [e-mail] [[e-mail]] On Behalf Of Eran
> Hammer-Lahav [[e-mail]]
> *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:* [e-mail] [mailto:[e-mail]] *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 <[e-mail]>
> 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
> <[e-mail]> 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
> > <[e-mail]>:
> >
> > 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:[e-mail]]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>