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

["Richer, Justin P." <[e-mail]>]

+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]<mailto:[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]<mailto:[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]<mailto:[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]<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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth