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

Evan Gilbert <uidude@google.com> Thu, 13 May 2010 16:16 UTC

Return-Path: <uidude@google.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 2A83E3A6877 for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.773
X-Spam-Level:
X-Spam-Status: No, score=-103.773 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 Eqs3jBF+2nkx for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:16:36 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DE6903A6926 for <oauth@ietf.org>; Thu, 13 May 2010 09:16:34 -0700 (PDT)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o4DGGObB012153 for <oauth@ietf.org>; Thu, 13 May 2010 09:16:24 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273767384; bh=l2ZOUBKFBb7gtgwcdr9xKDAudgU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=xZu14Zhk3Yc/CE1jO6diTS07LhfMBO6ytAlyEyLJPaa64zduNGkdscUotJoiNK+Vj BczUBOzd/fJ+qbjntjRng==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=EVJzmfL/OpumgOjq8S3tUSd0o8c2/g/B43Y3boYL0BWx4LC/M8Z77w1+JAj8sYnax nWXo8NNZN/5NJqmNjaNmg==
Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by hpaq2.eem.corp.google.com with ESMTP id o4DGGMuG014594 for <oauth@ietf.org>; Thu, 13 May 2010 09:16:22 -0700
Received: by gwb11 with SMTP id 11so738580gwb.1 for <oauth@ietf.org>; Thu, 13 May 2010 09:16:21 -0700 (PDT)
Received: by 10.150.55.9 with SMTP id d9mr568557yba.238.1273767376304; Thu, 13 May 2010 09:16:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.94.18 with HTTP; Thu, 13 May 2010 09:15:56 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Evan Gilbert <uidude@google.com>
Date: Thu, 13 May 2010 09:15:56 -0700
Message-ID: <AANLkTik0dKSLLVQDhodhFsO--bR43PvZKborWG1uK15t@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: multipart/alternative; boundary="000e0cd70f4afdba1c04867c1386"
X-System-Of-Record: true
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: Thu, 13 May 2010 16:16:38 -0000

On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote:

> You are trying to match a mechanism designed for automatic discovery with a
> system designed to require paperwork. It sounds like for your use cases, you
> will not be using this optional parameter and just document how to use your
> API (i.e. hardcode your security setup and API format).
>

I'm saying it should be a fully automatic discovery or use paperwork. Having
an API return valid URL prefixes to send the token to without having an API
to determine the actual URLs you send tokens to seems odd.

>
>
> The whole point of this is that the developer isn’t involved. The library
> takes care of everything. All the developer does is ask to get a protected
> resource. The library will check if it already has a valid token for that
> resource (based on the security restrictions provided by the sites
> parameter, and the scope requirements – two very separate things).
>

This is an incomplete mechanism for automatic discovery. How does the
developer find out where to ask for the protected resource in the first
place?

>
>
> So yes – if your developers have plenty of stuff to hardcode already, this
> adds little value.
>
>
>
> EHL
>
>
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Evan Gilbert
> *Sent:* Thursday, May 13, 2010 9:00 AM
>
> *To:* Manger, James H
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid
>
>
>
>
>
> On Wed, May 12, 2010 at 11:52 PM, Manger, James H <
> James.H.Manger@team.telstra.com> wrote:
>
> Evan,
>
>
> > The key point is that this discovery covers a lot of the same grounds as
> the sites parameter, and it's hard  to define semantics around a sites
> parameter without understanding the semantics of scopes and API endpoints.
>
> I strongly disagree. The semantics are crystal clear:
>  "Here is a token. It is INSECURE to send it anywhere not in this list."
> These semantics are useful regardless of what the API does, how the client
> is using it, or how much (or how little) the client knows about the API.
>
>
>
> To expand - it's hard to define *useful* semantics around a sites parameter
> without understanding the semantics of scopes and API endpoints. Yes, you
> can define crystal clear semantics, but these are not useful unless they
> work well with the way developers figure out the endpoints to call APIs.
>
>
>
>
>
> > Clients need to [know] more about these links (at least the response
> format).
>
> That knowledge comes from other standards (HTML, Atom, wiki of rel
> values...) and is totally independent of whether a token should or should
> not be sent.
>
>
>
> In our use cases, clients almost always need to know more about the API:
>
> - How to call directly - we have no API endpoints that are only arrived at
> by links
>
> - Response format of the data
>
>
>
>
>
> > The mechanism they use to find out about these links - documentation,
> discovery, data returned with token request - could also provide the
> information about whether a token should be sent to a particular API.
>
> Could, but shouldn't and doesn't in practise.
> It is much much better to have the information about how to use a token
> securely delivered at the same time & place as receiving that token, and
> with minimal assumptions about how much the client apps knows about the
> service.
>
>
>
> So why wouldn't we return a list of specific API endpoints instead of a
> "sites" parameter?
>
>
>
> Developers are going to call the APIs endpoints that they know about. If
> there is a conflict between this and the sites parameter, what should they
> do? For example, if facebook returns a sites parameter "
> https://unknown.facebook.com/", do we think the developer is going to not
> try to use the access token on https://graph.facebook.com/<https://graph.facebook.com/*>
>  ?
>
>
>
> Separating the concept of sites from API endpoints feels like a bad idea.
> Discovery / docs will give you a list of URLs where you should send tokens.
> The "sites" parameter will give you a list of URLs where you can send
> tokens. This is redundant, and will lead to developers / libraries not
> respecting the sites parameter. If developers / libraries don't respect it,
> then the service can't rely on it for enforcing security.
>
>
>
> Another note: Where do we anticipate clients storing the sites parameter in
> the User-Agent flow? Right now the access token can be set as an HTTP cookie
> by the client. Do we expect them to set a separate "sites" cookie and
> respect this on their server when making requests? This seems complicated.
>
>
>
>
>
> > I should be more concrete about the use cases I see. Let's assume there's
> an API where there are two endpoints, each with an associated permission
> > - contacts.list permission ->
> http://contacts.serviceprovider.com/contacts/list
> > - calendar.get permission ->
> http://calendar.serviceprovider.com/calendar/get
> >
> > If the response to an authorization request includes the authorized
> scopes (contacts.list, calendar.get), then the "sites" parameter is
> redundant.
>
> I'll admit that "sites" is redundant if a client has *perfect* knowledge
> about a service, but so is pretty much any standard at that point.
>
> Consider a generic search spider tool that you point at
> http://calendar.serviceprovider.com/calendar/get. It can do its job with
> no knowledge about what "calendar.get" means -- but it still needs to know
> (as it spiders along) when it is safe to expose the token.
>
>
>
> How does the generic search spider know to call to
> http://calendar.serviceprovider.com/calendar/get in the first place?
>
>
>
>
>
> --
> James Manger
>
>
>