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

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
<torsten@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
> <torsten@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:recordond@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
>
>