Re: [OAUTH-WG] SWT for indicating sites where a token is valid

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 12 May 2010 00:31 UTC

Return-Path: <James.H.Manger@team.telstra.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 660153A688C for <oauth@core3.amsl.com>; Tue, 11 May 2010 17:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.431
X-Spam-Level: *
X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
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 PnNax7EmJS5n for <oauth@core3.amsl.com>; Tue, 11 May 2010 17:31:04 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 633613A6C18 for <oauth@ietf.org>; Tue, 11 May 2010 17:31:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,210,1272808800"; d="scan'208";a="2473120"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 12 May 2010 10:30:48 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,5979"; a="1791560"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 12 May 2010 10:30:49 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 12 May 2010 10:30:48 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Marius Scurtescu <mscurtescu@google.com>
Date: Wed, 12 May 2010 10:30:47 +1000
Thread-Topic: [OAUTH-WG] SWT for indicating sites where a token is valid
Thread-Index: AcrxNovgwHx2+CJ0R7KPmX4n0FIfBgAJkobA
Message-ID: <255B9BB34FB7D647A506DC292726F6E112633147DC@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <BC9EED4C-B667-4AC2-A663-CEAC0B7CB620@lodderstedt.net> <AANLkTincZ8_0-t2r_Ey9BestA_knMciYsxRLyHcOvSVO@mail.gmail.com> <g2xfd6741651005071106if93ba794q7e9739669eb22fc2@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> <AANLkTinUEWwq2pxLukMrwDHeth-86THV_uvGWCrFjskU@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1126328511A@WSMSG3153V.srv.dir.telstra.com> <AANLkTimgXfVZc5-51FPsamrQPhj8EyXIeAa5qpQFhe3S@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1126328531E@WSMSG3153V.srv.dir.telstra.com> <AANLkTikTeg36ZgwHHNT2sKumMd1N-F0z8Qb1xIBqYsV1@mail.gmail.com>
In-Reply-To: <AANLkTikTeg36ZgwHHNT2sKumMd1N-F0z8Qb1xIBqYsV1@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] SWT for 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: Wed, 12 May 2010 00:31:05 -0000

Marius,

> If the protected resource sends a redirect instead of serving the
> resource then probably it knows what it is doing.

Sure, the server knows what it is doing. However it is completely legitimate for a server to knowingly redirect to an external site, to a site configured by a user, to a site matching a search term etc.
The server knows whether a redirect (or link) might cross a security boundary, but the issue is how does the client know.


> Following links, how do you see that happening? Normally a client will
> not follow links without understanding them and at the same time send
> access tokens.

A client app understands that’s a URI in an <img> tag or a Facebook "photos" link should lead to an image. It is far less obvious what the security context for that image is: is it part of the same API, or an arbitrary image on the Internet.


>> "sites" does help. If its value was:
>>  "sites": ["https://api.example.com", "https://img.example.com"]
>> Then no HTTP URI matches so the token is never sent in the clear.

> Yes, but HTTP and WIFI can compromise tokens even if sent to the
> proper sites. Right?

Yes, but only if the server explicitly decided that particular token was suitable for sending in the clear and explicitly told the client so by including an HTTP string in the "sites" field.


Marius