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

David Recordon <recordond@gmail.com> Fri, 07 May 2010 18:06 UTC

Return-Path: <recordond@gmail.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE47D3A65A5 for <oauth@core3.amsl.com>; Fri, 7 May 2010 11:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_05=-1.11, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqen-h+mP0iw for <oauth@core3.amsl.com>; Fri, 7 May 2010 11:06:37 -0700 (PDT)
Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 4FCD43A67EC for <oauth@ietf.org>; Fri, 7 May 2010 11:06:37 -0700 (PDT)
Received: by gxk9 with SMTP id 9so997937gxk.8 for <oauth@ietf.org>; Fri, 07 May 2010 11:06:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=R6smjDGNQkcsOT649JqQN4F3k46Tlp8hFPAK+3aeGd8=; b=Ft2gTlyWCXaN1M/K5C7wkx5+pp/xEGV+qngUk9ZabKEW/rxuf+WhvWHaSy/NeXLe0t Kn5HE68SFxt164D6y5aZybXvueDZshYXp04eliJiFQB1fvo+X4fkdcWEhLclPLfUmSP6 OFXZ4zztuL/ibpXwKReaY9n/ZPGQ5K4Bm1TN8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BhMUdDCkihDUCSTQ6NkrnH6unH4ouGrSV+W58S61SQVxib3LQDIW6CAUgmUmBTbi7h zAZnT8r0PbbszMnBLn9ZU4epjZrBl8yaCykPNsNNAfVh3BSdKlY3GqOJYYhoaiYEKBR6 aOluqp0ErvLflSdP6aQIebuB9Zvip+fKurnPE=
MIME-Version: 1.0
Received: by 10.231.166.77 with SMTP id l13mr145362iby.63.1273255579867; Fri, 07 May 2010 11:06:19 -0700 (PDT)
Received: by 10.231.183.195 with HTTP; Fri, 7 May 2010 11:06:19 -0700 (PDT)
In-Reply-To: <AANLkTincZ8_0-t2r_Ey9BestA_knMciYsxRLyHcOvSVO@mail.gmail.com>
References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <q2hfd6741651005062105y46152452x370fac0dd12d55c6@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <BC9EED4C-B667-4AC2-A663-CEAC0B7CB620@lodderstedt.net> <AANLkTincZ8_0-t2r_Ey9BestA_knMciYsxRLyHcOvSVO@mail.gmail.com>
Date: Fri, 07 May 2010 11:06:19 -0700
Message-ID: <g2xfd6741651005071106if93ba794q7e9739669eb22fc2@mail.gmail.com>
From: David Recordon <recordond@gmail.com>
To: Marius Scurtescu <mscurtescu@google.com>
Content-Type: multipart/alternative; boundary="001636d33eb98bde0f048604ea95"
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2010 18:06:38 -0000

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 <mscurtescu@google.com>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
> <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
> >
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>