IETF Logo Mail Archive

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

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 13 May 2010 23:54 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 D40F53A6ABC for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.475
X-Spam-Level: *
X-Spam-Status: No, score=1.475 tagged_above=-999 required=5 tests=[AWL=-0.224, 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 VBZFFEidlzzm for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:54:54 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id AC4733A69C9 for <oauth@ietf.org>; Thu, 13 May 2010 16:54:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,225,1272808800"; d="scan'208";a="2558107"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 14 May 2010 09:54:43 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,5981"; a="1959522"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbni.tcif.telstra.com.au with ESMTP; 14 May 2010 09:54:43 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 14 May 2010 09:54:43 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Evan Gilbert <uidude@google.com>
Date: Fri, 14 May 2010 09:54:42 +1000
Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid
Thread-Index: AcrytXxo4x83RRX6Tuaa6g1JfrbrKAAPsZzg
Message-ID: <255B9BB34FB7D647A506DC292726F6E112634659EC@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <AANLkTincZ8_0-t2r_Ey9BestA_knMciYsxRLyHcOvSVO@mail.gmail.com> <g2xfd6741651005071106if93ba794q7e9739669eb22fc2@mail.gmail.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>
In-Reply-To: <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@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] 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 23:54:54 -0000

Evan,

> we have no API endpoints that are only arrived at by links

This doesn't sound very web-friendly. Your APIs don't have to follow a web-style, but an IETF spec should support web-style APIs.

I am a bit surprised with your statement as a whole lot of Google APIs do have API endpoints arrived at by links. I thought most Google Data APIs followed the Atom Publishing Protocol. This uses links extensively. For instance, <link rel="edit" href="..."/> tells the client the API endpoint to at which an entry can be updated.

There are lots and lots of <link rel="..." href="..."/> relations defined: in the Atom spec, in the APP spec, in GData docs (not specific to particular APIs) etc.

Definitions of none of these link relations state that they MUST or MUST NOT be part of the same API.
 


> 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.

Presumably the client needs to store the access token, the expiry date, perhaps the scopes etc. Easy solution: store the base64-encoding of the JSON representation of the token details.


--
James Manger

v2.23.0 | Report a Bug | By Email