From zeltsan@alcatel-lucent.com Thu Oct 1 09:22:58 2009 Return-Path: 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 D836B28C120 for ; Thu, 1 Oct 2009 09:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599] 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 m9Jlr-hQ+PTI for ; Thu, 1 Oct 2009 09:22:57 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 90F953A69C4 for ; Thu, 1 Oct 2009 09:22:57 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n91GOKl4014140 for ; Thu, 1 Oct 2009 11:24:20 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n91GOK2Z029989 for ; Thu, 1 Oct 2009 11:24:20 -0500 (CDT) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 1 Oct 2009 11:24:20 -0500 From: "Zeltsan, Zachary (Zachary)" To: "oauth@ietf.org" Date: Thu, 1 Oct 2009 11:24:19 -0500 Thread-Topic: [OAUTH-WG] [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] Thread-Index: AcoyP8X3nD1IZlrIR+m8bThcHTkRLgF9GyfAAp8ZU+A= Message-ID: <5710F82C0E73B04FA559560098BF95B124EDE09F3D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Vrancken, Bart Bv \(Bart\)" Subject: [OAUTH-WG] FW: [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:22:58 -0000 =20 This is reminder of the draft draft-vrancken-oauth-redelegation-00.txt. The= authors of the draft would like to get feedback on the proposed work (othe= rwise I should assume that there are no objections to accepting the proposa= l as a work item). With best regards, Zachary > -----Original Message----- > From: Zeltsan, Zachary (Zachary)=20 > Sent: Friday, September 18, 2009 3:54 AM > To: Peter Saint-Andre > Cc: oauth@ietf.org; Faynberg, Igor (Igor); Richard Barnes > Subject: RE: [OAUTH-WG] [Fwd: I-D=20 > ACTION:draft-vrancken-oauth-redelegation-00.txt] >=20 > Peter, >=20 > We briefly introduced the draft in the original email, which=20 > Richard has mentioned. As Igor has explained, the goal of the=20 > draft is to describe a use case for the "four-legged" OAuth.=20 > (Richard's and Igor's messages are attached). The term=20 > "four-legged" was criticized at the Breakfast BoF, so it is=20 > not used (although is mentioned) in the draft. The draft also=20 > explains the use of the OAuth for the recursive ("n-legged")=20 > delegation. >=20 > Zachary > =20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org=20 > [mailto:oauth-bounces@ietf.org] On Behalf=20 > > Of Igor Faynberg > > Sent: Thursday, September 10, 2009 1:54 PM > > To: Richard Barnes > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] [Fwd: I-D > > ACTION:draft-vrancken-oauth-redelegation-00.txt] > >=20 > > Richard, > >=20 > > The authors are traveling now, so I will be happy to chime-in.=20 > > (Incidentally, Zachary had sent a notice to this list some time=20 > > before.) > >=20 > > In short, this is a follow-up on 1) an interesting=20 > discussion on the=20 > > list Re: > > "four-legged" approach; and 2) the bar meeting at the last=20 > IETF, which=20 > > Zachary attended. > >=20 > > Here, in compliance with what appeared to be the consensus=20 > of the bar=20 > > meeting, the term of "four-legged" was dropped. The concept=20 > has been=20 > > described as "recursive delegation." The goal of the draft was to=20 > > document it and provide a use case. > >=20 > > With best regards, > >=20 > > Igor > >=20 > > On 9/9/2009 9:34 PM, Richard Barnes wrote: > > > Think they already did, to first order: > > > > > >=20 > > >=20 > > > Peter Saint-Andre wrote: > > >=20 > > >>-----BEGIN PGP SIGNED MESSAGE----- > > >>Hash: SHA1 > > >> > > >> > > >> > > >>As seen on the i-d-announce@ietf.org list just now. Perhaps the=20 > > >>authors would like to provide a friendly introduction to > > their work?=20 > > >>:) > > >> > > >>/psa > > >> > > >>- -------- Original Message -------- > > >>Subject: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt > > >>Date: Wed, 9 Sep 2009 09:15:01 -0700 (PDT) > > >>From: Internet-Drafts@ietf.org > > >>Reply-To: internet-drafts@ietf.org > > >>To: i-d-announce@ietf.org > > >> > > >>A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > >>directories. > > >> > > >> > > >> Title : Using OAuth for Recursive Delegation > > >> Author(s) : B. Vrancken, Z. Zeltsan > > >> Filename : draft-vrancken-oauth-redelegation-00.txt > > >> Pages : 11 > > >> Date : 2009-9-4 > > >>=09 > > >> This document describes a use case for delegating > > authorization by a > > >> Resource Owner to another user via a Client using the > > OAuth protocol. > > >> OAuth allows Clients to access server resources on behalf of=20 > > >> another party (such as a different Client or an > > end-user). This document > > >> describes the use of OAuth for delegating one Client's > > authorization > > >> to another Client - a scenario, which is also known as > > four-legged > > >> authorization. > > >> > > >>A URL for this Internet-Draft is: > > >>http://www.ietf.org/internet-drafts/draft-vrancken-oauth-red > > elegation- > > >>00.txt > > >> > > >>-----BEGIN PGP SIGNATURE----- > > >>Version: GnuPG v1.4.8 (Darwin) > > >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > >> > > >>iEYEARECAAYFAkqn1roACgkQNL8k5A2w/vyW1wCeImOus7lIB1MV4wqQ1cF25mWz > > >>DZUAnjqmTRH8JX4vKFbkeOEHS1ahVijP > > >>=3DrPFC > > >>-----END PGP SIGNATURE----- > > >>_______________________________________________ > > >>OAuth mailing list > > >>OAuth@ietf.org > > >>https://www.ietf.org/mailman/listinfo/oauth > > >> > > >=20 > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > >=20 > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > >=20 > = From eran@hueniverse.com Thu Oct 1 10:27:40 2009 Return-Path: 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 CE67928C1A0 for ; Thu, 1 Oct 2009 10:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.655 X-Spam-Level: X-Spam-Status: No, score=-3.655 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_00=-2.599] 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 MwsgSZBOzHpE for ; Thu, 1 Oct 2009 10:27:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8CD5628C17D for ; Thu, 1 Oct 2009 10:27:39 -0700 (PDT) Received: (qmail 12470 invoked from network); 1 Oct 2009 17:29:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Oct 2009 17:29:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Oct 2009 10:26:46 -0700 From: Eran Hammer-Lahav To: "Zeltsan, Zachary (Zachary)" , "oauth@ietf.org" Date: Thu, 1 Oct 2009 10:29:18 -0700 Thread-Topic: [OAUTH-WG] FW: [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] Thread-Index: AcoyP8X3nD1IZlrIR+m8bThcHTkRLgF9GyfAAp8ZU+AAAwB3kA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF24DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5710F82C0E73B04FA559560098BF95B124EDE09F3D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B124EDE09F3D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Vrancken, Bart Bv \(Bart\)" Subject: Re: [OAUTH-WG] FW: [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 17:27:40 -0000 I object to making the proposal a work item until we are ready to move the = current two drafts to last-call. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Zeltsan, Zachary (Zachary) > Sent: Thursday, October 01, 2009 9:24 AM > To: oauth@ietf.org > Cc: Vrancken, Bart Bv (Bart) > Subject: [OAUTH-WG] FW: [Fwd: I-D ACTION:draft-vrancken-oauth- > redelegation-00.txt] >=20 >=20 > This is reminder of the draft draft-vrancken-oauth-redelegation-00.txt. > The authors of the draft would like to get feedback on the proposed > work (otherwise I should assume that there are no objections to > accepting the proposal as a work item). >=20 > With best regards, >=20 > Zachary >=20 > > -----Original Message----- > > From: Zeltsan, Zachary (Zachary) > > Sent: Friday, September 18, 2009 3:54 AM > > To: Peter Saint-Andre > > Cc: oauth@ietf.org; Faynberg, Igor (Igor); Richard Barnes > > Subject: RE: [OAUTH-WG] [Fwd: I-D > > ACTION:draft-vrancken-oauth-redelegation-00.txt] > > > > Peter, > > > > We briefly introduced the draft in the original email, which > > Richard has mentioned. As Igor has explained, the goal of the > > draft is to describe a use case for the "four-legged" OAuth. > > (Richard's and Igor's messages are attached). The term > > "four-legged" was criticized at the Breakfast BoF, so it is > > not used (although is mentioned) in the draft. The draft also > > explains the use of the OAuth for the recursive ("n-legged") > > delegation. > > > > Zachary > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org > > [mailto:oauth-bounces@ietf.org] On Behalf > > > Of Igor Faynberg > > > Sent: Thursday, September 10, 2009 1:54 PM > > > To: Richard Barnes > > > Cc: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] [Fwd: I-D > > > ACTION:draft-vrancken-oauth-redelegation-00.txt] > > > > > > Richard, > > > > > > The authors are traveling now, so I will be happy to chime-in. > > > (Incidentally, Zachary had sent a notice to this list some time > > > before.) > > > > > > In short, this is a follow-up on 1) an interesting > > discussion on the > > > list Re: > > > "four-legged" approach; and 2) the bar meeting at the last > > IETF, which > > > Zachary attended. > > > > > > Here, in compliance with what appeared to be the consensus > > of the bar > > > meeting, the term of "four-legged" was dropped. The concept > > has been > > > described as "recursive delegation." The goal of the draft was to > > > document it and provide a use case. > > > > > > With best regards, > > > > > > Igor > > > > > > On 9/9/2009 9:34 PM, Richard Barnes wrote: > > > > Think they already did, to first order: > > > > archive/web/oauth/current/msg00284.html> > > > > > > > > > > > > Peter Saint-Andre wrote: > > > > > > > >>-----BEGIN PGP SIGNED MESSAGE----- > > > >>Hash: SHA1 > > > >> > > > >> > > > >> > > > >>As seen on the i-d-announce@ietf.org list just now. Perhaps the > > > >>authors would like to provide a friendly introduction to > > > their work? > > > >>:) > > > >> > > > >>/psa > > > >> > > > >>- -------- Original Message -------- > > > >>Subject: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt > > > >>Date: Wed, 9 Sep 2009 09:15:01 -0700 (PDT) > > > >>From: Internet-Drafts@ietf.org > > > >>Reply-To: internet-drafts@ietf.org > > > >>To: i-d-announce@ietf.org > > > >> > > > >>A New Internet-Draft is available from the on-line > > Internet-Drafts > > > >>directories. > > > >> > > > >> > > > >> Title : Using OAuth for Recursive Delegation > > > >> Author(s) : B. Vrancken, Z. Zeltsan > > > >> Filename : draft-vrancken-oauth-redelegation-00.txt > > > >> Pages : 11 > > > >> Date : 2009-9-4 > > > >> > > > >> This document describes a use case for delegating > > > authorization by a > > > >> Resource Owner to another user via a Client using the > > > OAuth protocol. > > > >> OAuth allows Clients to access server resources on behalf of > > > >> another party (such as a different Client or an > > > end-user). This document > > > >> describes the use of OAuth for delegating one Client's > > > authorization > > > >> to another Client - a scenario, which is also known as > > > four-legged > > > >> authorization. > > > >> > > > >>A URL for this Internet-Draft is: > > > >>http://www.ietf.org/internet-drafts/draft-vrancken-oauth-red > > > elegation- > > > >>00.txt > > > >> > > > >>-----BEGIN PGP SIGNATURE----- > > > >>Version: GnuPG v1.4.8 (Darwin) > > > >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > >> > > > >>iEYEARECAAYFAkqn1roACgkQNL8k5A2w/vyW1wCeImOus7lIB1MV4wqQ1cF25mWz > > > >>DZUAnjqmTRH8JX4vKFbkeOEHS1ahVijP > > > >>=3DrPFC > > > >>-----END PGP SIGNATURE----- > > > >>_______________________________________________ > > > >>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 From stpeter@stpeter.im Thu Oct 1 10:28:09 2009 Return-Path: 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 CD1E728C19F for ; Thu, 1 Oct 2009 10:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599] 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 TQWg7er3FaSo for ; Thu, 1 Oct 2009 10:28:08 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5369528C17D for ; Thu, 1 Oct 2009 10:28:08 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D60EE4007B; Thu, 1 Oct 2009 11:29:31 -0600 (MDT) Message-ID: <4AC4E6FA.2020608@stpeter.im> Date: Thu, 01 Oct 2009 11:29:30 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Zeltsan, Zachary (Zachary)" References: <5710F82C0E73B04FA559560098BF95B124EDE09F3D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B124EDE09F3D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] FW: [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 17:28:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/1/09 10:24 AM, Zeltsan, Zachary (Zachary) wrote: > > This is reminder of the draft > draft-vrancken-oauth-redelegation-00.txt. The authors of the draft > would like to get feedback on the proposed work (otherwise I should > assume that there are no objections to accepting the proposal as a > work item). Our charter (i.e., our "contract" with the IESG) states: After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions... Naturally we can discuss draft-vrancken-oauth-redelegation (and other specs) on this list. And I don't think we absolutely must wait until draft-ietf-oauth-authentication and draft-ietf-oauth-web-delegation are delivered to the IESG before taking on additional WG items. However, I am at least hesitant to take attention away from the core specs (and draft-hammer-oauth as informational documentation of "OAuth Core 1.0 Revision A" with errata) until we have consensus on the major issues we've been discussing recently: mandatory signature algorithms, the appropriate place to communicate client credentials, simplifying request normalization, token expiration, improved error codes, interaction of OAuth with HTTP caching, etc. I also think it would be very helpful for members of this list to complete reviews of the above-mentioned I-Ds (perhaps after the document editor has had a chance to incorporate the results of recent list discussion). That said, if the group comes to consensus that it would like to accept draft-vrancken-oauth-redelegation as an official work item of the OAuth WG, we could proceed with doing so. If the authors would like the chairs to issue a consensus call on this matter, please let us know. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrE5voACgkQNL8k5A2w/vyuUQCgvmtiKTSsfpp9EoqQE38RYx+y tycAn30XJx74n5/7LbX6gEzcTN45zCur =+lG6 -----END PGP SIGNATURE----- From faynberg@alcatel-lucent.com Thu Oct 1 10:46:07 2009 Return-Path: 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 0318E3A69D9 for ; Thu, 1 Oct 2009 10:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 mvsi1RjuPgZG for ; Thu, 1 Oct 2009 10:46:05 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 67CC83A6895 for ; Thu, 1 Oct 2009 10:45:42 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n91Hl6W4023806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Oct 2009 12:47:06 -0500 (CDT) Received: from [135.244.35.74] (faynberg.lra.lucent.com [135.244.35.74]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n91Hl3qe003460; Thu, 1 Oct 2009 12:47:03 -0500 (CDT) Message-ID: <4AC4EB16.9020405@alcatel-lucent.com> Date: Thu, 01 Oct 2009 13:47:02 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Saint-Andre References: <5710F82C0E73B04FA559560098BF95B124EDE09F3D@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4AC4E6FA.2020608@stpeter.im> In-Reply-To: <4AC4E6FA.2020608@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: OAuth WG Subject: Re: [OAUTH-WG] FW: [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 17:46:07 -0000 I think Peter's advice is very reasonable. Ultimately the point here is to get the discussion going without delaying the schedule for the agreed deliverables. It surely is the WG chairs' prerogative to decide on what ought to be done first. Personally, I don't see any reason to issue a call for consensus before the draft has been discussed. I remember the burst of discussions on the mailing list before the "bar session," which clearly indicated an interest, so I thought we would see more of it after the draft has been published. I hope that we will get a chance to discuss this in Hiroshima. Igor Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 10/1/09 10:24 AM, Zeltsan, Zachary (Zachary) wrote: > >> This is reminder of the draft >> draft-vrancken-oauth-redelegation-00.txt. The authors of the draft >> would like to get feedback on the proposed work (otherwise I should >> assume that there are no objections to accepting the proposal as a >> work item). >> > > Our charter (i.e., our "contract" with the IESG) states: > > After delivering OAuth 1.1, the Working Group may consider > defining additional functions and/or extensions... > > Naturally we can discuss draft-vrancken-oauth-redelegation (and other > specs) on this list. And I don't think we absolutely must wait until > draft-ietf-oauth-authentication and draft-ietf-oauth-web-delegation are > delivered to the IESG before taking on additional WG items. However, I > am at least hesitant to take attention away from the core specs (and > draft-hammer-oauth as informational documentation of "OAuth Core 1.0 > Revision A" with errata) until we have consensus on the major issues > we've been discussing recently: mandatory signature algorithms, the > appropriate place to communicate client credentials, simplifying request > normalization, token expiration, improved error codes, interaction of > OAuth with HTTP caching, etc. I also think it would be very helpful for > members of this list to complete reviews of the above-mentioned I-Ds > (perhaps after the document editor has had a chance to incorporate the > results of recent list discussion). > > That said, if the group comes to consensus that it would like to accept > draft-vrancken-oauth-redelegation as an official work item of the OAuth > WG, we could proceed with doing so. If the authors would like the > chairs to issue a consensus call on this matter, please let us know. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrE5voACgkQNL8k5A2w/vyuUQCgvmtiKTSsfpp9EoqQE38RYx+y > tycAn30XJx74n5/7LbX6gEzcTN45zCur > =+lG6 > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Oct 1 16:10:41 2009 Return-Path: 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 B44D63A6824 for ; Thu, 1 Oct 2009 16:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.639 X-Spam-Level: X-Spam-Status: No, score=-3.639 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599] 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 6YBGm3FOK84h for ; Thu, 1 Oct 2009 16:10:40 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A20FB3A6819 for ; Thu, 1 Oct 2009 16:10:40 -0700 (PDT) Received: (qmail 10723 invoked from network); 1 Oct 2009 23:12:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 1 Oct 2009 23:12:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Oct 2009 16:09:27 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 1 Oct 2009 16:12:01 -0700 Thread-Topic: Proposal for a New 2617 Scheme: Token Thread-Index: AcpC7JT+nhGmdMmgRUK5lgEp+Mvwxw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 23:10:41 -0000 This is my draft proposal for replacing the auth scheme defined in the auth= entication draft in the upcoming version. Feedback requested! Background OAuth Core 1.0 uses the 'oauth' scheme name in HTTP authentication headers.= It also uses the oauth_version=3D"1.0" parameter to indicate the authentic= ation version used. The version parameter has been poorly defined in the 1.= 0 spec and therefore provides little transitional value. We also know that = we are going to change the version number of the protocol (I am advocating = a 2.0 approach instead of the initial 1.1 direction). I think it is better = to drop version numbers in favor of using different scheme names to identif= y different version. Unlike Basic and Digest which are based on a username/password pair, OAuth = is based on a Token/Secret pair. The distinction between username and token= isn't just technical but has an application meaning. Username implied dire= ct access while Token implies delegated access. It is important to make sur= e a server can reply to a protected resource request with more than one aut= h header to indicate that both usernames and tokens are welcomed. This is w= hy we cannot use Basic or Digest to send token credentials, even if the two= protocols provide all the necessary technical coverage. Given the recent discussion about the requirement to use the HTTP authentic= ation headers, I am proposing that (for the time being) we drop support for= form-encoded or URI query authorization parameters. We can discuss adding = some form of support for non-header delivery of authentication parameters l= ater but that will require special handling and other headers to prevent br= eaking the web. Proposal The new scheme (I am proposing 'Token' as scheme name but an open for other= suggestions) will replace the 'OAuth' scheme name and will use the followi= ng syntax (please help with an ABNF version please...): WWW-Authenticate: Token realm=3D"", , ... Authorization: Token , , ... Core sub-schemes: * Plain - Just like Basic without base64 encoding (since it really adds not= value and just a waste of time): WWW-Authenticate: Token Plain realm=3D"" Authorization: Token Plain * HMAC - Similar to the Core 1.0 signature method (with hopefully simpler n= ormalization rules): WWW-Authenticate: Token HMAC realm=3D"", algorithm=3D"SHA1 SHA2 MD5" Authorization: Token HMAC algorithm=3D"SHA1", nonce=3D"", timestam= p=3D"", digest=3D"", body-hash=3D"" (the 'body-hash' is an optional parameter that if included, must also be i= ncluded in the HMAC text) I am purposely not including the RSA option since it is no sufficiently def= ined. If there is a need for it (Google was the only company asking for it = and they now support other alternatives) we can discuss how to implement it= in this new proposal. We should establish a registry for new sub-schemes and use an established r= egistry for algorithm names. EHL From jpanzer@google.com Thu Oct 1 16:32:05 2009 Return-Path: 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 0A5A03A6781 for ; Thu, 1 Oct 2009 16:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 qWrLWSlkcWtk for ; Thu, 1 Oct 2009 16:32:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id AD9813A691B for ; Thu, 1 Oct 2009 16:32:03 -0700 (PDT) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id n91NXTPg007953 for ; Thu, 1 Oct 2009 16:33:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254440009; bh=lPyAnr4lhvniTU8XxgAOM6z9z+8=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=Uw35Jf ImThw28sgxVP5l0NApNk5kkA324XbfczBWLdSalGSxOT0wtMr/IupC/7aAwMH+mgEWj EcT+nPnCB9Mig== 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=j5w/6EZGzK+T/3KZQYeR5RUpVsJ0GzxeFPnNdfBiYwMrw5BoJnA8MKJlr+959ox06 Ai0OPNJdm0Yksm/GZqidQ== Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by zps38.corp.google.com with ESMTP id n91NXRwu019597 for ; Thu, 1 Oct 2009 16:33:27 -0700 Received: by gxk22 with SMTP id 22so810197gxk.0 for ; Thu, 01 Oct 2009 16:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.55.28 with SMTP id d28mr3267180yba.309.1254440007150; Thu, 01 Oct 2009 16:33:27 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 1 Oct 2009 16:33:07 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd70c6a04d21e0474e81327 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 23:32:05 -0000 --000e0cd70c6a04d21e0474e81327 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 1, 2009 at 4:12 PM, Eran Hammer-Lahav wrote: > This is my draft proposal for replacing the auth scheme defined in the > authentication draft in the upcoming version. Feedback requested! > > Background > > OAuth Core 1.0 uses the 'oauth' scheme name in HTTP authentication headers. > It also uses the oauth_version="1.0" parameter to indicate the > authentication version used. The version parameter has been poorly defined > in the 1.0 spec and therefore provides little transitional value. We also > know that we are going to change the version number of the protocol (I am > advocating a 2.0 approach instead of the initial 1.1 direction). I think it > is better to drop version numbers in favor of using different scheme names > to identify different version. > > Unlike Basic and Digest which are based on a username/password pair, OAuth > is based on a Token/Secret pair. The distinction between username and token > isn't just technical but has an application meaning. Username implied direct > access while Token implies delegated access. It is important to make sure a > server can reply to a protected resource request with more than one auth > header to indicate that both usernames and tokens are welcomed. This is why > we cannot use Basic or Digest to send token credentials, even if the two > protocols provide all the necessary technical coverage. > > Given the recent discussion about the requirement to use the HTTP > authentication headers, I am proposing that (for the time being) we drop > support for form-encoded or URI query authorization parameters. We can > discuss adding some form of support for non-header delivery of > authentication parameters later but that will require special handling and > other headers to prevent breaking the web. > > Proposal > > The new scheme (I am proposing 'Token' as scheme name but an open for other > suggestions) will replace the 'OAuth' scheme name and will use the following > syntax (please help with an ABNF version please...): > > WWW-Authenticate: Token realm="", , > ... > Authorization: Token , , ... > > Core sub-schemes: > > * Plain - Just like Basic without base64 encoding (since it really adds not > value and just a waste of time): > > WWW-Authenticate: Token Plain realm="" > > Authorization: Token Plain > > * HMAC - Similar to the Core 1.0 signature method (with hopefully simpler > normalization rules): > > WWW-Authenticate: Token HMAC realm="", algorithm="SHA1 SHA2 MD5" > Is the realm literally just an empty string (for compatibility with RFC 2617)? > > Authorization: Token HMAC algorithm="SHA1", nonce="", > timestamp="", digest="", body-hash="" > > (the 'body-hash' is an optional parameter that if included, must > also be included in the HMAC text) > > > I am purposely not including the RSA option since it is no sufficiently > defined. If there is a need for it (Google was the only company asking for > it and they now support other alternatives) we can discuss how to implement > it in this new proposal. > I think RSA should be included. > > We should establish a registry for new sub-schemes and use an established > registry for algorithm names. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd70c6a04d21e0474e81327 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 1, 2009 at 4:12 PM, Eran Hammer-Laha= v <eran@huenive= rse.com> wrote:
This is my draft proposal for replacing the auth scheme defined in the auth= entication draft in the upcoming version. Feedback requested!

Background

OAuth Core 1.0 uses the 'oauth' scheme name in HTTP authentication = headers. It also uses the oauth_version=3D"1.0" parameter to indi= cate the authentication version used. The version parameter has been poorly= defined in the 1.0 spec and therefore provides little transitional value. = We also know that we are going to change the version number of the protocol= (I am advocating a 2.0 approach instead of the initial 1.1 direction). I t= hink it is better to drop version numbers in favor of using different schem= e names to identify different version.

Unlike Basic and Digest which are based on a username/password pair, OAuth = is based on a Token/Secret pair. The distinction between username and token= isn't just technical but has an application meaning. Username implied = direct access while Token implies delegated access. It is important to make= sure a server can reply to a protected resource request with more than one= auth header to indicate that both usernames and tokens are welcomed. This = is why we cannot use Basic or Digest to send token credentials, even if the= two protocols provide all the necessary technical coverage.

Given the recent discussion about the requirement to use the HTTP authentic= ation headers, I am proposing that (for the time being) we drop support for= form-encoded or URI query authorization parameters. We can discuss adding = some form of support for non-header delivery of authentication parameters l= ater but that will require special handling and other headers to prevent br= eaking the web.

Proposal

The new scheme (I am proposing 'Token' as scheme name but an open f= or other suggestions) will replace the 'OAuth' scheme name and will= use the following syntax (please help with an ABNF version please...):

=A0 =A0 =A0 =A0WWW-Authenticate: Token <sub-scheme> realm=3D"&q= uot;, <sub-scheme-param>, ...
=A0 =A0 =A0 =A0Authorization: Token <sub-scheme> <token>, <= sub-scheme-param>, ...

Core sub-schemes:

* Plain - Just like Basic without base64 encoding (since it really adds not= value and just a waste of time):

=A0 =A0 =A0 =A0WWW-Authenticate: Token Plain realm=3D""

=A0 =A0 =A0 =A0Authorization: Token Plain <token> <secret>

* HMAC - Similar to the Core 1.0 signature method (with hopefully simpler n= ormalization rules):

=A0 =A0 =A0 =A0WWW-Authenticate: Token HMAC realm=3D"", algorith= m=3D"SHA1 SHA2 MD5"

Is the realm literal= ly just an empty string (for compatibility with RFC 2617)?
=A0

=A0 =A0 =A0 =A0Authorization: Token HMAC <token> algorithm=3D"S= HA1", nonce=3D"", timestamp=3D"", digest=3D"&= quot;, body-hash=3D""

=A0 =A0 =A0 =A0(the 'body-hash' is an optional parameter that if i= ncluded, must also be included in the HMAC text)


I am purposely not including the RSA option since it is no sufficiently def= ined. If there is a need for it (Google was the only company asking for it = and they now support other alternatives) we can discuss how to implement it= in this new proposal.

I think RSA should be included.
=A0

We should establish a registry for new sub-schemes and use an established r= egistry for algorithm names.

EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--000e0cd70c6a04d21e0474e81327-- From beaton@google.com Thu Oct 1 16:43:02 2009 Return-Path: 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 4F8143A691B for ; Thu, 1 Oct 2009 16:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 kuvTA9YFuSDL for ; Thu, 1 Oct 2009 16:42:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id A62173A67A7 for ; Thu, 1 Oct 2009 16:42:58 -0700 (PDT) Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id n91NiNoV016579 for ; Thu, 1 Oct 2009 16:44:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254440664; bh=SxU/DRcmC/bKkJIsEE8Al7nJogA=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=jhJAeO/gvmJzbLo5t2 +/RuRuC4fJIQ0Pev8vAxdoEQqqFa6x3Wr3HjTp9uPTETOt+G5HOCkGyLoa0Mjo1TdDr Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=a8GS/Cnk3kc9x3Hd5LZQx1Wz35O2zmiU34QeTsEnwWCwVlKcUtUgpvZl2Y8xp12bM GjjeNfaWVaskWRSg5wVtg== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by spaceape14.eur.corp.google.com with ESMTP id n91NiKwP012550 for ; Thu, 1 Oct 2009 16:44:20 -0700 Received: by pxi7 with SMTP id 7so828344pxi.17 for ; Thu, 01 Oct 2009 16:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.25.19 with SMTP id c19mr281035wfj.87.1254440659792; Thu, 01 Oct 2009 16:44:19 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 1 Oct 2009 16:44:19 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 23:43:02 -0000 On Thu, Oct 1, 2009 at 4:12 PM, Eran Hammer-Lahav wro= te: > The new scheme (I am proposing 'Token' as scheme name but an open for oth= er suggestions) will > replace the 'OAuth' scheme name and will use the following syntax > (please help with an ABNF version please...): Any pressing reason to change from "OAuth" to "Token"? > =A0 =A0 =A0 =A0WWW-Authenticate: Token realm=3D"", , ... Should probably drop "realm" unless we can define the semantics. (I can't.= ) I think that the ABNF should probably just be the prefix, followed by name-value pairs. I don't see a reason to have a separate sub-scheme. Out of curiosity, what would people think if instead of defining yet-another-serialization-format, we used JSON for this, e.g. WWW-Authenticate: Token > I am purposely not including the RSA option since it is no sufficiently d= efined. > If there is a need for it (Google was the only company asking for it and = they now > support other alternatives) we can discuss how to implement it in this ne= w proposal. RSA is important. Public key crypto is a building block we shouldn't leave out. Not having it means we can't ever do any kind of automatic consumer discovery. That said, RSA might only get used when requesting access tokens, not when using them. There is no RSA private key associated with an access token, so it's kind of hard to use it. =3D) Cheers, Brian From James.H.Manger@team.telstra.com Thu Oct 1 17:33:28 2009 Return-Path: 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 2CA763A6907 for ; Thu, 1 Oct 2009 17:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 T9AYfPA2Dkfm for ; Thu, 1 Oct 2009 17:33:27 -0700 (PDT) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id 26A7F3A63EC for ; Thu, 1 Oct 2009 17:33:26 -0700 (PDT) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipbi.vtcif.telstra.com.au with ESMTP; 02 Oct 2009 10:33:32 +1000 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 842DF1DAA1 for ; Fri, 2 Oct 2009 10:33:31 +1000 (EST) Received: from WSMSG3705.srv.dir.telstra.com (wsmsg3705.in.telstra.com.au [172.49.40.203]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA10399 for ; Fri, 2 Oct 2009 10:33:30 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 2 Oct 2009 10:33:29 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 2 Oct 2009 10:33:28 +1000 Thread-Topic: Proposal for a New 2617 Scheme: Token Thread-Index: AcpC7JT+nhGmdMmgRUK5lgEp+MvwxwAAsS2w Message-ID: <255B9BB34FB7D647A506DC292726F6E11231D1880B@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 00:33:28 -0000 PiBJdCBpcyBpbXBvcnRhbnQgdG8gbWFrZSBzdXJlIGEgc2VydmVyIGNhbiByZXBseSB0byBhIHBy b3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0DQo+IHdpdGggbW9yZSB0aGFuIG9uZSBhdXRoIGhlYWRl ciB0byBpbmRpY2F0ZSB0aGF0IGJvdGggdXNlcm5hbWVzIGFuZCB0b2tlbnMgYXJlIHdlbGNvbWVk Lg0KPiBUaGlzIGlzIHdoeSB3ZSBjYW5ub3QgdXNlIEJhc2ljIG9yIERpZ2VzdCB0byBzZW5kIHRv a2VuIGNyZWRlbnRpYWxzLA0KPiBldmVuIGlmIHRoZSB0d28gcHJvdG9jb2xzIHByb3ZpZGUgYWxs IHRoZSBuZWNlc3NhcnkgdGVjaG5pY2FsIGNvdmVyYWdlLg0KDQoNCkkgdGhpbmsgdGhhdCByZWFz b25pbmcgaXMgd3JvbmcuIERpZmZlcmVudCAicmVhbG0iIHZhbHVlcyBjYW4gaW5kaWNhdGUgZGlm ZmVyZW50IGNyZWRlbnRpYWwgZ3JvdXBzIGlmIG5lY2Vzc2FyeSAodXNlcm5hbWUgdnMgdG9rZW4p IHdoaWxlIHVzaW5nIHRoZSBzYW1lIHNjaGVtZS4NCg0KUkZDIDI2MTcgIkhUVFAgQXV0aGVudGlj YXRpb24iIGV4cGxpY2l0bHkgc3RhdGVzOg0KICAiTm90ZSB0aGF0IHRoZXJlIG1heSBiZSBtdWx0 aXBsZSBjaGFsbGVuZ2VzIHdpdGggdGhlIHNhbWUgYXV0aC1zY2hlbWUgYnV0DQogICBkaWZmZXJl bnQgcmVhbG1zLiINCg0KQSBzZXJ2ZXIgY2FuIHF1aXRlIGxlZ2l0aW1hdGVseSByZXR1cm46DQog IDQwMSBVbmF1dGhlbnRpY2F0ZWQNCiAgV1dXLUF1dGhlbnRpY2F0aW9uOiBCQVNJQyByZWFsbT0i VXNlciBhY2Nlc3MiDQogIFdXVy1BdXRoZW50aWNhdGlvbjogQkFTSUMgcmVhbG09IkRlbGVnYXRl ZCBhcHAgYWNjZXNzIg0KDQpXZWIgYnJvd3NlcnMgKGF0IGxlYXN0IElFOCBhbmQgRkYzKSBqdXN0 IGFjdCBvbiB0aGUgZmlyc3Qgb2YgdGhlc2UgaGVhZGVyIC0tIHdoaWNoIGlzIHdoYXQgd2Ugd2Fu dC4NCg0KV2hlbiBpc3N1aW5nIGEgdG9rZW4sIE9BdXRoIGNvdWxkIGluZGljYXRlIHRoZSByZWFs bSB0byB3aGljaCB0aGUgdG9rZW4gYXBwbGllcyBzbyBhIGNsaWVudCBrbm93cyB3aGljaCBXV1ct QXV0aGVudGljYXRpb24gaGVhZGVyIGlzIGFwcHJvcHJpYXRlLg0KV2hlbiBpc3N1aW5nIGEgdG9r ZW4sIE9BdXRoIHNob3VsZCBpbmRpY2F0ZSB0aGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtKHMp IGFsbG93ZWQgd2l0aCB0aGUgdG9rZW4sIHdoaWNoIGFsc28gaGVscHMgdGhlIGNsaWVudCBwaWNr IGFuIGFwcHJvcHJpYXRlIFdXVy1BdXRoZW50aWNhdGlvbiBoZWFkZXIuDQoNCg0KQWNjZXB0aW5n IHVzZXJuYW1lcyBhbmQgdG9rZW5zIHdpbGwgbm90IGdlbmVyYWxseSBiZSBhIHByb2JsZW0gYXMg YW55IGNhbGxlciAoYSB1c2VyJ3MgYnJvd3NlciBvciBhbiBPQXV0aCBjbGllbnQpIHdpbGwgb25s eSBoYXZlIG9uZSBvciB0aGUgb3RoZXIgLS0gaXQganVzdCB1c2VzIHdoYXQgaXQgaGFzLg0KDQpJ dCBtYXkgYmUgdHJpY2tpZXIgaWYgc2VydmVycyBuZWVkIHRvIGluZGljYXRlIHRoYXQgT0F1dGgg Y2xpZW50IGNyZWRlbnRpYWxzIChlZyBhcHAtaWQvYXBwLXNlY3JldCkgYW5kIGRlbGVnYXRpb24g Y3JlZGVudGlhbHMgKHRva2VuL3NlY3JldCkgY2FuIGJvdGggYmUgdXNlZCB0byBhY2Nlc3MgYSBn aXZlbiBwcm90ZWN0ZWQgcmVzb3VyY2UuIERpZmZlcmVudCByZWFsbXMgYXJlIG9uZSBzb2x1dGlv bi4gT2Z0ZW4gdGhlIGNsaWVudCB3aWxsIGtub3cgd2hpY2ggY3JlZGVudGlhbHMgYXJlIGFwcHJv cHJpYXRlIGFzIGl0IGtub3dzIHRoZSBjb250ZXh0IGluIHdoaWNoIGl0IGlzIG1ha2luZyB0aGUg Y2FsbC4gSWYgaXQgaXMgdG9vIGhhcmQsIHNlcnZlcnMgY2FuIGp1c3QgdXNlIGRpZmZlcmVudCBV UklzIGZvciBhY2Nlc3MgYnkgdXNlcnMsIGNsaWVudHMtYXMtdGhlbXNlbHZlcywgYW5kIGNsaWVu dHMtb24tYmVoYWxmLW9mLXVzZXJzLg0KDQoNCg0KSmFtZXMgTWFuZ2VyDQpKYW1lcy5ILk1hbmdl ckB0ZWFtLnRlbHN0cmEuY29tDQpJZGVudGl0eSBhbmQgc2VjdXJpdHkgdGVhbSDigJQgQ2hpZWYg VGVjaG5vbG9neSBPZmZpY2Ug4oCUIFRlbHN0cmENCg== From eran@hueniverse.com Thu Oct 1 18:29:37 2009 Return-Path: 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 5B4E13A681E for ; Thu, 1 Oct 2009 18:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599] 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 XLteWHdeLwE1 for ; Thu, 1 Oct 2009 18:29:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EF0DD3A680C for ; Thu, 1 Oct 2009 18:29:35 -0700 (PDT) Received: (qmail 6873 invoked from network); 2 Oct 2009 01:31:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 01:31:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Oct 2009 18:31:00 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Thu, 1 Oct 2009 18:31:15 -0700 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpC8RtlL8ChzezoTyutJR3neuuz2wADeudw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF25B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 01:29:37 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Thursday, October 01, 2009 4:44 PM > Should probably drop "realm" unless we can define the semantics. (I > can't.) I think 2617 defines realm pretty well. It is a URI string that identifies = the set of resources accessible with a given credential. If you feel we nee= d to spell out the lessons (restrictions) learned from Basic, we can look i= nto that. =20 > I think that the ABNF should probably just be the prefix, followed by > name-value pairs. I don't see a reason to have a separate sub-scheme. Why define a parameter when it is clearly a sub-scheme? I makes client much= simpler by being able to look for the first two words in the header and kn= own what is going on. Otherwise we need to define a certain order for param= eters which is ugly. =20 > Out of curiosity, what would people think if instead of defining > yet-another-serialization-format, we used JSON for this, e.g. >=20 > WWW-Authenticate: Token That's crazy talk. =20 > RSA is important. Public key crypto is a building block we shouldn't > leave out. Not having it means we can't ever do any kind of automatic > consumer discovery. >=20 > That said, RSA might only get used when requesting access tokens, not > when using them. There is no RSA private key associated with an > access token, so it's kind of hard to use it. =3D) Then we need to define how it works in the context of authentication. Keep = in mind that this is ONLY for accessing protected resources once a token ha= s been obtained. We will deal with obtaining tokens separately and there we= can include PK support as part of the client credentials package. EHL From James.H.Manger@team.telstra.com Thu Oct 1 18:29:41 2009 Return-Path: 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 6760C3A68B0 for ; Thu, 1 Oct 2009 18:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 zK6rxgjpsVx3 for ; Thu, 1 Oct 2009 18:29:39 -0700 (PDT) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 57E503A699C for ; Thu, 1 Oct 2009 18:29:39 -0700 (PDT) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 02 Oct 2009 11:31:04 +1000 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 63037FF89 for ; Fri, 2 Oct 2009 11:31:04 +1000 (EST) Received: from WSMSG3705.srv.dir.telstra.com (wsmsg3705.in.telstra.com.au [172.49.40.203]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 230FB41E3F for ; Fri, 2 Oct 2009 11:30:49 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 2 Oct 2009 11:31:03 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 2 Oct 2009 11:31:01 +1000 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpC8Sw2Ny1WupCSSWSDuMgrgFIZNwABvj2g Message-ID: <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: 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 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 01:29:41 -0000 SSB0aGluayBPQXV0aCBuZWVkczoNCg0KMS4gQSBXV1ctQXV0aCBzY2hlbWUgaW5kaWNhdGluZyB0 aGF0IHJlcXVlc3RzIGNhbiBiZSBzaWduZWQgd2l0aCBhIHNoYXJlZC1zZWNyZXQga2V5Lg0KDQoy LiBBIFdXVy1BdXRoIHNjaGVtZSBpbmRpY2F0aW5nIHRoYXQgYSB3ZWIgZGVsZWdhdGlvbiBmbG93 IGNhbiBiZSB1c2VkIHRvIGdldCB1c2VyIGF1dGhvcml6YXRpb24uDQoNClRoZSB0d28gYXJlIHF1 aXRlIHNlcGFyYXRlLg0KVGhlIGZpcnN0IHdvdWxkIGJlIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1v YXV0aC1hdXRoZW50aWNhdGlvbiBhbmQgd291bGQgbWFrZSBubyByZWZlcmVuY2UgdG8gZGVsZWdh dGlvbiBhdCBhbGwuICJNQUMiIHdvdWxkIGJlIGEgZ29vZCBuYW1lLg0KDQo8LSAgV1dXLUF1dGhl bnRpY2F0ZTogTUFDIHJlYWxtPSJ3aGF0ZXZlciI7IGFsZ29yaXRobT0iSE1BQy1TSEExIEhNQUMt U0hBMjU2IENNQUMtQUVTIjsNCiAgICAgICAgICAgICAgICAgICAgIG1vZGU9IkhFQURFUiBVUkkg UE9TVCIgPHBlcmhhcHMgc29tZSBtb3JlIHBhcmFtZXRlcnM+DQoNCi0+ICBBdXRob3JpemF0aW9u OiBNQUMgcmVhbG09IndoYXRldmVyIjsgYWxnb3JpdGhtPSJITUFDLVNIQTI1NiI7IHNpZz0iNjVk Rk3igKYiOyBub25jZeKApg0KDQpUaGUgb3B0aW9uIHRvIGVuY29kZSB0aGUgc2lnbmF0dXJlIGlu IGEgVVJJIGlzIHdvcnRod2hpbGUgKGVnIGEgY2xpZW50IGNhbiBzaWduIGEgVVJJIHRoZW4gZ2l2 ZSBpdCB0byBhbm90aGVyIHBhcnR5IHRvIGFjY2VzcywgZWcgYW5vdGhlciBwYXJ0eSB0byBjbGlj ayBpbiBhIGJyb3dzZXIpLiBIZW5jZSwgdGhlICJtb2RlIiBwYXJhbWV0ZXIgYWJvdmUuIEkgYW0g bGVzcyBjb252aW5jZWQgYnkgUE9TVCwgYnV0IGl0IGlzIGEgc21hbGwgc3RlcCBmcm9tIFVSSSB0 byBQT1NUIHNvIGl0IGlzIHByb2JhYmx5IHdvcnRoIGhhdmluZy4NCltIRUFERVIgPSBjYW4gcHV0 IHNpZ25hdHVyZSBpbiBIVFRQIEF1dGhvcml6YXRpb24gcmVxdWVzdCBoZWFkZXI7DQogVVJJID0g Y2FuIHB1dCBzaWduYXR1cmUgaW4gVVJJIHF1ZXJ5IHN0cmluZzsNCiBQT1NUID0gY2FuIHB1dCBz aWduYXR1cmUgaW4gSFRNTCA8Zm9ybT4gUE9TVF0NCg0KDQo+CVdXVy1BdXRoZW50aWNhdGU6IFRv a2VuIFBsYWluIHJlYWxtPSIiDQo+CUF1dGhvcml6YXRpb246IFRva2VuIFBsYWluIDx0b2tlbj4g PHNlY3JldD4NCg0KVGhpcyBpc24ndCBuZWNlc3NhcnkuIEp1c3QgdXNlIEJBU0lDLg0KQSBzZXJ2 ZXIgbWF5IG5lZWQgdG8gZW5zdXJlIHVzZXJuYW1lcyBhbmQgdG9rZW5zIGNhbiBiZSBkaXN0aW5n dWlzaGVkLCBidXQgdGhhdCBpcyBlYXN5IGVub3VnaC4NCg0KDQpJZiBhbiBSU0EtYmFzZWQgbWVj aGFuaXNtIGlzIHJlcXVpcmVkIGEgc2VwYXJhdGUgV1dXLUF1dGggc2NoZW1lIHdvdWxkIGJlIHRo ZSBiZXN0IGFwcHJvYWNoLg0KDQoNCkEgV1dXLUF1dGggc2NoZW1lIHRvIHRyaWdnZXIgdGhlIGRl bGVnYXRpb24gZmxvdyBpcyBtb3JlIGludGVyZXN0aW5nLCBidXQgdGhhdCBpcyBmb3IgYSBzZXBh cmF0ZSB0aHJlYWQuDQoNCg0KDQpKYW1lcyBNYW5nZXINCkphbWVzLkguTWFuZ2VyQHRlYW0udGVs c3RyYS5jb20NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBUZWNobm9sb2d5 IE9mZmljZSDigJQgVGVsc3RyYQ0K From eran@hueniverse.com Thu Oct 1 18:33:40 2009 Return-Path: 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 B22423A6837 for ; Thu, 1 Oct 2009 18:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599] 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 FgCdbRmdwKVw for ; Thu, 1 Oct 2009 18:33:39 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4A6993A680C for ; Thu, 1 Oct 2009 18:33:39 -0700 (PDT) Received: (qmail 10920 invoked from network); 2 Oct 2009 01:35:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 01:35:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Oct 2009 18:35:05 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Thu, 1 Oct 2009 18:35:20 -0700 Thread-Topic: Proposal for a New 2617 Scheme: Token Thread-Index: AcpC7JT+nhGmdMmgRUK5lgEp+MvwxwAAsS2wAAQuCmA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF25B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D1880B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11231D1880B@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 01:33:40 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgTWFu Z2VyLCBKYW1lcyBIDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDAxLCAyMDA5IDU6MzMgUE0N Cg0KPiBJIHRoaW5rIHRoYXQgcmVhc29uaW5nIGlzIHdyb25nLiBEaWZmZXJlbnQgInJlYWxtIiB2 YWx1ZXMgY2FuIGluZGljYXRlDQo+IGRpZmZlcmVudCBjcmVkZW50aWFsIGdyb3VwcyBpZiBuZWNl c3NhcnkgKHVzZXJuYW1lIHZzIHRva2VuKSB3aGlsZQ0KPiB1c2luZyB0aGUgc2FtZSBzY2hlbWUu DQo+IA0KPiBSRkMgMjYxNyAiSFRUUCBBdXRoZW50aWNhdGlvbiIgZXhwbGljaXRseSBzdGF0ZXM6 DQo+ICAgIk5vdGUgdGhhdCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgY2hhbGxlbmdlcyB3aXRoIHRo ZSBzYW1lIGF1dGgtc2NoZW1lDQo+IGJ1dA0KPiAgICBkaWZmZXJlbnQgcmVhbG1zLiINCj4gDQo+ IEEgc2VydmVyIGNhbiBxdWl0ZSBsZWdpdGltYXRlbHkgcmV0dXJuOg0KPiAgIDQwMSBVbmF1dGhl bnRpY2F0ZWQNCj4gICBXV1ctQXV0aGVudGljYXRpb246IEJBU0lDIHJlYWxtPSJVc2VyIGFjY2Vz cyINCj4gICBXV1ctQXV0aGVudGljYXRpb246IEJBU0lDIHJlYWxtPSJEZWxlZ2F0ZWQgYXBwIGFj Y2VzcyINCg0KV2hpbGUgaXQgaXMgYW4gaW50ZXJlc3RpbmcgaWRlYSwgSSB0aGluayBpdCBpcyBi YWQgZGVzaWduLiBIb3cgaXMgYSBjbGllbnQgc3VwcG9zZWQgdG8ga25vdyB3aGF0IHRvIGRvIHdp dGggdGhpcz8gV2hhdCBpcyB0aGUgdmFsdWUgb2YgcmV1c2luZyBCYXNpYyBvciBEaWdlc3QgaGVy ZT8gRGlnZXN0IGhhcyBmYWlsZWQgYWRvcHRpb24gYW5kIEJhc2ljIHByb3ZpZGVzIHByYWN0aWNh bGx5IHplcm8gdmFsdWUuIEkgdGhpbmsgdGhpcyB3aWxsIGNhdXNlIGNvbmZ1c2lvbiBhbmQgcHJv YmxlbXMgd2l0aCBleGlzdGluZyBkZXBsb3ltZW50cyB3aXRoIG5vIHJlYWwgYmVuZWZpdHMuDQoN CkVITA0K From James.H.Manger@team.telstra.com Thu Oct 1 19:24:57 2009 Return-Path: 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 4E07B3A68EA for ; Thu, 1 Oct 2009 19:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 uXfcnoz+7lq7 for ; Thu, 1 Oct 2009 19:24:56 -0700 (PDT) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id E708A3A6959 for ; Thu, 1 Oct 2009 19:24:55 -0700 (PDT) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipbi.vtcif.telstra.com.au with ESMTP; 02 Oct 2009 12:26:21 +1000 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id B8C711DA85 for ; Fri, 2 Oct 2009 12:26:20 +1000 (EST) Received: from WSMSG3751.srv.dir.telstra.com (wsmsg3751.srv.dir.telstra.com [172.49.40.172]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 3CDDA41E3C for ; Fri, 2 Oct 2009 12:26:05 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Fri, 2 Oct 2009 12:26:20 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 2 Oct 2009 12:26:18 +1000 Thread-Topic: Proposal for a New 2617 Scheme: Token Thread-Index: AcpC7JT+nhGmdMmgRUK5lgEp+MvwxwAAsS2wAAQuCmAAANsHcA== Message-ID: <255B9BB34FB7D647A506DC292726F6E11231D18AE0@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D1880B@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF25B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 02:24:57 -0000 Pj4gICA0MDEgVW5hdXRoZW50aWNhdGVkDQo+PiAgIFdXVy1BdXRoZW50aWNhdGlvbjogQkFTSUMg cmVhbG09IlVzZXIgYWNjZXNzIg0KPj4gICBXV1ctQXV0aGVudGljYXRpb246IEJBU0lDIHJlYWxt PSJEZWxlZ2F0ZWQgYXBwIGFjY2VzcyINCj4gSG93IGlzIGEgY2xpZW50IHN1cHBvc2VkIHRvIGtu b3cgd2hhdCB0byBkbyB3aXRoIHRoaXM/DQoNClRoaXMgaXMgbm90IGVub3VnaCB0byB0cmlnZ2Vy IGEgd2ViLWRlbGVnYXRpb24gZmxvdyAtLSB3ZSBuZWVkIGFub3RoZXIgV1dXLUF1dGggaGVhZGVy IGZvciB0aGF0LiBPbmNlIGEgY2xpZW50IGhhcyBhbiBpZCBhbmQgc2hhcmVkLXNlY3JldCAod2hl dGhlciBmcm9tIGEgd2ViIGRlbGVnYXRpb24gZmxvdywgYSBjb25maWd1cmF0aW9uIGZpbGUsIHBy b21wdGluZyBhIHVzZXIgb3BlcmF0aW5nIHRoZSBjbGllbnQuLi4pIHRoZSBhYm92ZSBoZWFkZXIg dGVsbHMgaXQgdG8gcmV0cnkgdGhlIHJlcXVlc3Qgd2l0aCBhICJBdXRob3JpemF0aW9uOiBCQVNJ QyBabTl2T21KaGNnPT0iIGhlYWRlci4NCg0KSWYgdGhlIGNsaWVudCB3YXMgZ2l2ZW4gYSByZWFs bSB2YWx1ZSB3aGVuIGl0IGdvdCB0aGUgaWQgYW5kIHNoYXJlZC1zZWNyZXQsIHRoZW4gdGhlIHR3 byBoZWFkZXJzIGFib3ZlIGluZGljYXRlIGlmIHRob3NlIGNyZWRlbnRpYWxzIGNhbiBiZSB1c2Vk IGZvciB0aGlzIHByb3RlY3RlZCByZXNvdXJjZS4NCklmIHRoZSBjbGllbnQgaGFzIGl0cyBvd24g aWQvc2VjcmV0IGFuZCBhbm90aGVyIGlkL3NlY3JldCBhcyBhIGRlbGVnYXRlIGZvciBhbm90aGVy IHVzZXIsIHRoZW4gdGhlIG11bHRpcGxlIHJlYWxtcyBjYW4gdGVsbCBpdCB3aGljaCBzZXQgdGhl IHNlcnZlciBpcyBhc2tpbmcgZm9yLg0KDQoNCg0KPiBEaWdlc3QgaGFzIGZhaWxlZCBhZG9wdGlv bg0KDQpGaW5lLCBzbyB3ZSBzaG91bGQgYmUgd2FyeSBhYm91dCByZWludmVudGluZyBpdCB3aXRo ICJUb2tlbiBITUFDIiB1bmxlc3MgdGhhdCBvZmZlcnMgc29tZXRoaW5nIHNpZ25pZmljYW50bHkg ZGlmZmVyZW50LiBUaGUgYWJpbGl0eSB0byBwdXQgdGhlIHNpZ25hdHVyZSBpbiB0aGUgVVJJIG9y IGJvZHkgaXMgZGlmZmVyZW50IChidXQgeW91IHdhbnQgdG8gZHJvcCB0aGF0KTsgc2ltcGxpY2l0 eSBtYXkgYmUgZGlmZmVyZW50IGVub3VnaC4gR2V0dGluZyB0aGUgY3JlZGVudGlhbHMgZnJvbSBh IGRlbGVnYXRpb24gZmxvdyBpcyBub3QgYSBkaWZmZXJlbmNlIGFzIGl0IHNob3VsZCBiZSBvcnRo b2dvbmFsLg0KDQoNCj4gQmFzaWMgcHJvdmlkZXMgcHJhY3RpY2FsbHkgemVybyB2YWx1ZQ0KDQpJ IGRvbid0IHVuZGVyc3RhbmQgaG93ICJUb2tlbiBQbGFpbiIgY2FuIG9mZmVyIGFueSBtb3JlIHZh bHVlIHRoYW4gQkFTSUMuDQooUGVyc29uYWxseSBJIHRoaW5rIEJBU0lDIGlzIG1hc3NpdmVseSB1 c2VmdWwgb3ZlciBIVFRQUykNCg0KDQoNClRoZSAiVG9rZW4gUGxhaW4iIGFuZCAiVG9rZW4gSE1B QyIgV1dXLUF1dGggc2NoZW1lcyBsb29rIGxpa2UgYSBkZWxpYmVyYXRlIGF0dGVtcHQgdG8ga2Vl cCBhdXRoZW50aWNhdGlvbiBhbmQgd2ViLWRlbGVnYXRpb24gdGlnaHRseSBjb3VwbGVkLiBUaGlz IG11c3QgYmUgdW5uZWNlc3NhcnkuIEkgdGhvdWdoIHRoZSB3aG9sZSBpZGVhIG9mIHNwbGl0dGlu ZyBPQXV0aCBpbnRvIGF1dGhlbnRpY2F0aW9uIGFuZCB3ZWItZGVsZWdhdGlvbiBzcGVjcyB3YXMg dGhhdCB0aGVzZSBhcmUgc2VwYXJhdGUgY29uY2VybnMuIFRoZSBhdXRoZW50aWNhdGlvbiBwYXJ0 IGlzIHVzZWZ1bCBldmVuIGlmIHlvdSBkaWRuJ3QgZ2V0IHRoZSBjcmVkZW50aWFscyB2aWEgZGVs ZWdhdGlvbi4gVGhlIGRlbGVnYXRpb24gcGFydCBpcyB1c2VmdWwgd2hhdGV2ZXIgYXV0aGVudGlj YXRpb24gbWVjaGFuaXNtIGlzIHN1YnNlcXVlbnRseSB1c2VkLg0KDQpJdCBzZWVtcyBsaWtlIGJh ZCBkZXNpZ24gdG8ga2VlcCB0aGUgYXV0aGVudGljYXRpb24gc3BlYyBib3VuZCB0byB3ZWItZGVs ZWdhdGlvbiAodGhvdWdoIHRoZXJlIHdpbGwgbmVlZCB0byBiZSBzb21lIGxpbmtzIGluIHRoZSBv dGhlciBkaXJlY3Rpb24pLg0KDQoNCg0KSmFtZXMgTWFuZ2VyDQpKYW1lcy5ILk1hbmdlckB0ZWFt LnRlbHN0cmEuY29tDQpJZGVudGl0eSBhbmQgc2VjdXJpdHkgdGVhbSDigJQgQ2hpZWYgVGVjaG5v bG9neSBPZmZpY2Ug4oCUIFRlbHN0cmENCg0K From GFFletch@aol.com Thu Oct 1 19:51:15 2009 Return-Path: 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 01C123A6916 for ; Thu, 1 Oct 2009 19:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 oCsCTWndhbxV for ; Thu, 1 Oct 2009 19:51:13 -0700 (PDT) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by core3.amsl.com (Postfix) with ESMTP id AC3533A6878 for ; Thu, 1 Oct 2009 19:51:13 -0700 (PDT) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id n922qPSX003500; Thu, 1 Oct 2009 22:52:25 -0400 Received: from GFFletch@aol.com by imo-da04.mx.aol.com (mail_out_v42.5.) id l.bce.4f462ec8 (37092); Thu, 1 Oct 2009 22:52:19 -0400 (EDT) Received: from c0a8016c.tipt.aol.com ([10.172.2.21]) by cia-db07.mx.aol.com (v125.7) with ESMTP id MAILCIADB072-90e44ac56ae22a; Thu, 01 Oct 2009 22:52:19 -0400 Message-ID: <4AC56AE2.1030302@aol.com> Date: Thu, 01 Oct 2009 22:52:18 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.172.2.21 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 02:51:15 -0000 Eran Hammer-Lahav wrote: > * Many web platforms do not provide access to the wire HTTP request URI (either on the client or server side) > > requires more research but it also holds the key to much of the protocol design, namely: > > - The canonicalization of the HTTP request parameter and URI - this was done due to the fact that at the time, many popular web platforms did not provide easy access to the raw HTTP request URI and headers. If this is no longer the case, OAuth can be significantly simplified to remove the need to process the parameters and only treat the request URI. > > - The inclusion of multiple parameter transmission methods - this was done due to lack of access to the Authorization header in some clients and server environment. If this is no longer a requirement or if we come to the conclusion that HTTP caching requires that we use the header in all requests, the need to support parameters in places other than the header will also go away. > > One use case (I think I saw it mentioned somewhere else on the list) where we've used the URI parameters is when we want the server to sign a URL and then pass that signed value to the browser to load. This can be done with a simple 302 and the signed URL. Switching to just supporting the Authorization header will make this more difficult but probably not impossible. Thanks, George From eran@hueniverse.com Thu Oct 1 20:56:12 2009 Return-Path: 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 DB5A83A6837 for ; Thu, 1 Oct 2009 20:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.595 X-Spam-Level: X-Spam-Status: No, score=-3.595 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_00=-2.599] 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 K9vl43FB38Dm for ; Thu, 1 Oct 2009 20:56:11 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 833B93A6834 for ; Thu, 1 Oct 2009 20:56:11 -0700 (PDT) Received: (qmail 3813 invoked from network); 2 Oct 2009 03:57:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 03:57:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 1 Oct 2009 20:57:28 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Thu, 1 Oct 2009 20:57:44 -0700 Thread-Topic: Proposal for a New 2617 Scheme: Token Thread-Index: AcpC7JT+nhGmdMmgRUK5lgEp+MvwxwAAsS2wAAQuCmAAANsHcAAEBfsg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF25B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D1880B@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18AE0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11231D18AE0@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 03:56:12 -0000 VGhlIGlkZWEgb2YgdXNpbmcgdGhlIHJlYWxtIHZhbHVlIGFzIGEgZGlmZmVyZW50aWF0b3IgYmV0 d2VlbiB1c2VybmFtZS1iYXNlZCBhdXRoIGFuZCB0b2tlbi1iYXNlZCBhdXRoIGlzIHdyb25nLiBU aGlzIGlzIG5vdCB3aGF0IHRoZSByZWFsbSBpcyBmb3IgYW5kIGl0IGlzIGFscmVhZHkgYSBtaXN1 c2VkIGZlYXR1cmUuIFRoZSBjb25zZW5zdXMgaW4gdGhlIE9BdXRoIGNvbW11bml0eSBoYXMgYWx3 YXlzIGJlZW4gYWdhaW5zdCBldmVuIGhhdmluZyByZWFsbSBpbiB0aGUgZmlyc3QgcGxhY2UsIGFu ZCB3aGlsZSBJIGRpc2FncmVlIHdpdGggdGhhdCwgaXQgZG9lcyBpbmRpY2F0ZSB0aGF0IGJ1aWxk aW5nIG9uIHRvcCBvZiB0aGF0IGlzIGEgYmFkIGlkZWEuDQoNCkkgd291bGQgYWxzbyBhcmd1ZSB0 aGF0IGl0IHNob3VsZCBiZSBwZXJmZWN0bHkgdmFsaWQgdG8gdXNlIHRoZSBleGFjdCBzYW1lIHJl YWxtIChyZXNvdXJjZSBzZXQpIHdpdGggYm90aCB1c2VybmFtZS1iYXNlZCBhbmQgdG9rZW4tYmFz ZWQgY3JlZGVudGlhbHMuIFlvdXIgcHJvcG9zYWwgYnJlYWtzIHRoYXQgYW5kIGZvcmNlcyBzZXJ2 ZXJzIHRvIG1ha2UgdXAgbmV3IHJlYWxtcyB0aGF0IGFyZSBub3QgYmFzZWQgb24gdGhlaXIgc2Vy dmVyIGZpbGUgaGllcmFyY2h5IHdoaWNoIGlzIHRoZSBtb3N0IGNvbW1vbiBhcHByb2FjaC4NCg0K VGhlIHJlYWxpdHkgaXMgdGhhdCBCYXNpYyBhbmQgRGlnZXN0IGF1dGggYXJlIHdlbGwgZXN0YWJs aXNoZWQgYW5kIHVzZWQgZm9yIHVzZXJuYW1lL3Bhc3N3b3JkIGF1dGhlbnRpY2F0aW9uLiBUaGV5 IGFyZSB3aWRlbHkgZGVwbG95ZWQgYW5kIHRvIG92ZXJsb2FkIHRoZW0gd2l0aCBhIG5ldyBtZWFu aW5nIHdpbGwgbGlrZWx5IGNhdXNlIG1vcmUgaGFybSB0aGFuIGdvb2QuIEF0IHRoZSBzYW1lIHRp bWUsIHlvdSBhcmUgbm90IG9mZmVyaW5nIGFueSB2YWx1ZSBieSByZXVzaW5nIHRoZW0sIG90aGVy IHRoYW4gbWFraW5nIHRoZSBzcGVjIHNob3J0ZXIuIFllcyBCYXNpYyBpcyB2ZXJ5IHVzZWZ1bCBi dXQgd2hvIG5lZWRzIHRoZSBzdHVwaWQgYmFzZTY0IGVuY29kaW5nIG9yIGV2ZW4gdGhlICc6JyBz ZXBhcmF0b3IgYmV0d2VlbiB0aGUgdXNlcm5hbWUgYW5kIHBhc3N3b3JkPw0KDQpZZXMsIHdlIG5l ZWQgdG8gZmlndXJlIG91dCB0aGUgZGlzY292ZXJ5IG9mIGhvdyB0byBnZXQgYSB0b2tlbiBmcm9t IGEgNDAxIHJlc3BvbnNlLiBPbmUgdGhpbmcgYXQgYSB0aW1lLg0KDQpFSEwNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIE1hbmdlciwgSmFtZXMg SA0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAwMSwgMjAwOSA3OjI2IFBNDQo+IFRvOiBvYXV0 aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQcm9wb3NhbCBmb3IgYSBOZXcg MjYxNyBTY2hlbWU6IFRva2VuDQo+IA0KPiA+PiAgIDQwMSBVbmF1dGhlbnRpY2F0ZWQNCj4gPj4g ICBXV1ctQXV0aGVudGljYXRpb246IEJBU0lDIHJlYWxtPSJVc2VyIGFjY2VzcyINCj4gPj4gICBX V1ctQXV0aGVudGljYXRpb246IEJBU0lDIHJlYWxtPSJEZWxlZ2F0ZWQgYXBwIGFjY2VzcyINCj4g PiBIb3cgaXMgYSBjbGllbnQgc3VwcG9zZWQgdG8ga25vdyB3aGF0IHRvIGRvIHdpdGggdGhpcz8N Cj4gDQo+IFRoaXMgaXMgbm90IGVub3VnaCB0byB0cmlnZ2VyIGEgd2ViLWRlbGVnYXRpb24gZmxv dyAtLSB3ZSBuZWVkIGFub3RoZXINCj4gV1dXLUF1dGggaGVhZGVyIGZvciB0aGF0LiBPbmNlIGEg Y2xpZW50IGhhcyBhbiBpZCBhbmQgc2hhcmVkLXNlY3JldA0KPiAod2hldGhlciBmcm9tIGEgd2Vi IGRlbGVnYXRpb24gZmxvdywgYSBjb25maWd1cmF0aW9uIGZpbGUsIHByb21wdGluZyBhDQo+IHVz ZXIgb3BlcmF0aW5nIHRoZSBjbGllbnQuLi4pIHRoZSBhYm92ZSBoZWFkZXIgdGVsbHMgaXQgdG8g cmV0cnkgdGhlDQo+IHJlcXVlc3Qgd2l0aCBhICJBdXRob3JpemF0aW9uOiBCQVNJQyBabTl2T21K aGNnPT0iIGhlYWRlci4NCj4gDQo+IElmIHRoZSBjbGllbnQgd2FzIGdpdmVuIGEgcmVhbG0gdmFs dWUgd2hlbiBpdCBnb3QgdGhlIGlkIGFuZCBzaGFyZWQtDQo+IHNlY3JldCwgdGhlbiB0aGUgdHdv IGhlYWRlcnMgYWJvdmUgaW5kaWNhdGUgaWYgdGhvc2UgY3JlZGVudGlhbHMgY2FuIGJlDQo+IHVz ZWQgZm9yIHRoaXMgcHJvdGVjdGVkIHJlc291cmNlLg0KPiBJZiB0aGUgY2xpZW50IGhhcyBpdHMg b3duIGlkL3NlY3JldCBhbmQgYW5vdGhlciBpZC9zZWNyZXQgYXMgYSBkZWxlZ2F0ZQ0KPiBmb3Ig YW5vdGhlciB1c2VyLCB0aGVuIHRoZSBtdWx0aXBsZSByZWFsbXMgY2FuIHRlbGwgaXQgd2hpY2gg c2V0IHRoZQ0KPiBzZXJ2ZXIgaXMgYXNraW5nIGZvci4NCj4gDQo+IA0KPiANCj4gPiBEaWdlc3Qg aGFzIGZhaWxlZCBhZG9wdGlvbg0KPiANCj4gRmluZSwgc28gd2Ugc2hvdWxkIGJlIHdhcnkgYWJv dXQgcmVpbnZlbnRpbmcgaXQgd2l0aCAiVG9rZW4gSE1BQyINCj4gdW5sZXNzIHRoYXQgb2ZmZXJz IHNvbWV0aGluZyBzaWduaWZpY2FudGx5IGRpZmZlcmVudC4gVGhlIGFiaWxpdHkgdG8NCj4gcHV0 IHRoZSBzaWduYXR1cmUgaW4gdGhlIFVSSSBvciBib2R5IGlzIGRpZmZlcmVudCAoYnV0IHlvdSB3 YW50IHRvIGRyb3ANCj4gdGhhdCk7IHNpbXBsaWNpdHkgbWF5IGJlIGRpZmZlcmVudCBlbm91Z2gu IEdldHRpbmcgdGhlIGNyZWRlbnRpYWxzIGZyb20NCj4gYSBkZWxlZ2F0aW9uIGZsb3cgaXMgbm90 IGEgZGlmZmVyZW5jZSBhcyBpdCBzaG91bGQgYmUgb3J0aG9nb25hbC4NCj4gDQo+IA0KPiA+IEJh c2ljIHByb3ZpZGVzIHByYWN0aWNhbGx5IHplcm8gdmFsdWUNCj4gDQo+IEkgZG9uJ3QgdW5kZXJz dGFuZCBob3cgIlRva2VuIFBsYWluIiBjYW4gb2ZmZXIgYW55IG1vcmUgdmFsdWUgdGhhbg0KPiBC QVNJQy4NCj4gKFBlcnNvbmFsbHkgSSB0aGluayBCQVNJQyBpcyBtYXNzaXZlbHkgdXNlZnVsIG92 ZXIgSFRUUFMpDQo+IA0KPiANCj4gDQo+IFRoZSAiVG9rZW4gUGxhaW4iIGFuZCAiVG9rZW4gSE1B QyIgV1dXLUF1dGggc2NoZW1lcyBsb29rIGxpa2UgYQ0KPiBkZWxpYmVyYXRlIGF0dGVtcHQgdG8g a2VlcCBhdXRoZW50aWNhdGlvbiBhbmQgd2ViLWRlbGVnYXRpb24gdGlnaHRseQ0KPiBjb3VwbGVk LiBUaGlzIG11c3QgYmUgdW5uZWNlc3NhcnkuIEkgdGhvdWdoIHRoZSB3aG9sZSBpZGVhIG9mIHNw bGl0dGluZw0KPiBPQXV0aCBpbnRvIGF1dGhlbnRpY2F0aW9uIGFuZCB3ZWItZGVsZWdhdGlvbiBz cGVjcyB3YXMgdGhhdCB0aGVzZSBhcmUNCj4gc2VwYXJhdGUgY29uY2VybnMuIFRoZSBhdXRoZW50 aWNhdGlvbiBwYXJ0IGlzIHVzZWZ1bCBldmVuIGlmIHlvdSBkaWRuJ3QNCj4gZ2V0IHRoZSBjcmVk ZW50aWFscyB2aWEgZGVsZWdhdGlvbi4gVGhlIGRlbGVnYXRpb24gcGFydCBpcyB1c2VmdWwNCj4g d2hhdGV2ZXIgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGlzIHN1YnNlcXVlbnRseSB1c2VkLg0K PiANCj4gSXQgc2VlbXMgbGlrZSBiYWQgZGVzaWduIHRvIGtlZXAgdGhlIGF1dGhlbnRpY2F0aW9u IHNwZWMgYm91bmQgdG8gd2ViLQ0KPiBkZWxlZ2F0aW9uICh0aG91Z2ggdGhlcmUgd2lsbCBuZWVk IHRvIGJlIHNvbWUgbGlua3MgaW4gdGhlIG90aGVyDQo+IGRpcmVjdGlvbikuDQo+IA0KPiANCj4g DQo+IEphbWVzIE1hbmdlcg0KPiBKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tDQo+IElk ZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBUZWNobm9sb2d5IE9mZmljZSDigJQg VGVsc3RyYQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== From beaton@google.com Thu Oct 1 20:59:20 2009 Return-Path: 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 F030A3A672E for ; Thu, 1 Oct 2009 20:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hL7b7WvcKM7P for ; Thu, 1 Oct 2009 20:59:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 095963A6882 for ; Thu, 1 Oct 2009 20:59:18 -0700 (PDT) Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id n9240gaB011652 for ; Thu, 1 Oct 2009 21:00:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254456043; bh=VHvYxyvUWmj96HzXqEC4gNTDhSs=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=P XshvJJu+FseHmKWnHkSrAiY6z1cNxzYe2uvVwmB9yWpsoi/mS6FLtqn8FA4xBwR1IS6 QBbrRzQrycfwvRKIuw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=yCdc1Ja6FSvPVhqu0m21UptZGFZEebokiQsNt70lSaxExuKi+Ht6FSWIi2Y7iiF8S B6SV25Gdfw7sed545zHFA== Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by zps36.corp.google.com with ESMTP id n9240e0Y008492 for ; Thu, 1 Oct 2009 21:00:40 -0700 Received: by pxi11 with SMTP id 11so833915pxi.0 for ; Thu, 01 Oct 2009 21:00:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.154.2 with SMTP id g2mr293088wfo.18.1254456039952; Thu, 01 Oct 2009 21:00:39 -0700 (PDT) In-Reply-To: <4AC56AE2.1030302@aol.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> Date: Thu, 1 Oct 2009 21:00:39 -0700 Message-ID: From: Brian Eaton To: George Fletcher Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 03:59:20 -0000 On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher wrote: > One use case (I think I saw it mentioned somewhere else on the list) where > we've used the URI parameters is when we want the server to sign a URL and > then pass that signed value to the browser to load. This can be done with a > simple 302 and the signed URL. Switching to just supporting the > Authorization header will make this more difficult but probably not > impossible. Yep. I've seen that done multiple places. One more unexpected use of OAuth... From eran@hueniverse.com Thu Oct 1 22:48:59 2009 Return-Path: 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 39BF83A69EB for ; Thu, 1 Oct 2009 22:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599] 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 gSuKTn4sp7t0 for ; Thu, 1 Oct 2009 22:48:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 183C93A68C3 for ; Thu, 1 Oct 2009 22:48:57 -0700 (PDT) Received: (qmail 21091 invoked from network); 2 Oct 2009 05:50:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 05:50:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 1 Oct 2009 22:48:03 -0700 From: Eran Hammer-Lahav To: Brian Eaton , George Fletcher Date: Thu, 1 Oct 2009 22:50:38 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpDFO4FHlEBKI5rT6m0YtI1/swGwwAD1Ebw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 05:48:59 -0000 Can you describe the actual use case? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Thursday, October 01, 2009 9:01 PM > To: George Fletcher > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >=20 > On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher > wrote: > > One use case (I think I saw it mentioned somewhere else on the list) > where > > we've used the URI parameters is when we want the server to sign a > URL and > > then pass that signed value to the browser to load. This can be done > with a > > simple 302 and the signed URL. Switching to just supporting the > > Authorization header will make this more difficult but probably not > > impossible. >=20 > Yep. I've seen that done multiple places. >=20 > One more unexpected use of OAuth... > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Oct 1 23:10:29 2009 Return-Path: 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 7DF4C3A6993 for ; Thu, 1 Oct 2009 23:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 8F1VvrR+MP2c for ; Thu, 1 Oct 2009 23:10:27 -0700 (PDT) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id 745503A684A for ; Thu, 1 Oct 2009 23:10:26 -0700 (PDT) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipbi.vtcif.telstra.com.au with ESMTP; 02 Oct 2009 16:10:51 +1000 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id C26161DA81 for ; Fri, 2 Oct 2009 16:10:49 +1000 (EST) Received: from WSMSG3754.srv.dir.telstra.com (wsmsg3754.in.telstra.com.au [172.49.40.198]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 7CC1441D2A for ; Fri, 2 Oct 2009 16:10:34 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Fri, 2 Oct 2009 16:10:49 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 2 Oct 2009 16:10:48 +1000 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpDFO4FHlEBKI5rT6m0YtI1/swGwwAD1EbwAAANAoA= Message-ID: <255B9BB34FB7D647A506DC292726F6E11231D19029@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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 Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 06:10:29 -0000 Pj4+IE9uZSB1c2UgY2FzZSAoSSB0aGluayBJIHNhdyBpdCBtZW50aW9uZWQgc29tZXdoZXJlIGVs c2Ugb24gdGhlIGxpc3QpDQo+Pj4gd2hlcmUgd2UndmUgdXNlZCB0aGUgVVJJIHBhcmFtZXRlcnMg aXMgd2hlbiB3ZSB3YW50IHRoZSBzZXJ2ZXIgdG8gc2lnbiBhDQo+Pj4gVVJMIGFuZCB0aGVuIHBh c3MgdGhhdCBzaWduZWQgdmFsdWUgdG8gdGhlIGJyb3dzZXIgdG8gbG9hZC4NCj4+PiBUaGlzIGNh biBiZSBkb25lIHdpdGggYSBzaW1wbGUgMzAyIGFuZCB0aGUgc2lnbmVkIFVSTC4NCg0KPj4gWWVw LiAgSSd2ZSBzZWVuIHRoYXQgZG9uZSBtdWx0aXBsZSBwbGFjZXMuDQo+Pg0KPj4gT25lIG1vcmUg dW5leHBlY3RlZCB1c2Ugb2YgT0F1dGguLi4NCg0KPiBDYW4geW91IGRlc2NyaWJlIHRoZSBhY3R1 YWwgdXNlIGNhc2U/DQoNCkFtYXpvbiBTMyAoc2ltcGxlIHN0b3JhZ2Ugc2VydmljZSkgb2ZmZXIg dGhpcyBmZWF0dXJlLg0KWW91IGNhbiBzdG9yZSB5b3VyIHByaXZhdGUgZGF0YSBpbiBTMy4NClRv IGFjY2VzcyBpdCB5b3UgZGlnaXRhbGx5LXNpZ24geW91ciBIVFRQIHJlcXVlc3RzICh1c2luZyBI TUFDKSAtLSBwdXR0aW5nIHRoZSBzaWduYXR1cmUgaW4gYW4gSFRUUCBBdXRob3JpemF0aW9uIGhl YWRlci4NCklmIHlvdSB3YW50IHRvIGdpdmUgYW5vdGhlciB1c2VyICh0ZW1wb3JhcnkpIGFjY2Vz cyB0byBvbmUgcGllY2Ugb2YgeW91ciBkYXRhLCB5b3Ugc2VuZCB0aGVtIGEgc2lnbmVkIFVSSSBm b3IgdGhhdCBkYXRhLiBUaGV5IGNhbiBub3cgZG93bmxvYWQgdGhlIGRhdGEuIFRoZXkgbmV2ZXIg Z2V0IHlvdXIgUzMgY3JlZGVudGlhbHMuIFRoZXkgY2FuIGFjY2VzcyB0aGUgZGF0YSBmcm9tIGEg c3RhbmRhcmQgYnJvd3Nlci4gVGhlIGJ1bGsgZGF0YSB0cmFuc2ZlciBjYW4gZ28gc3RyYWlnaHQg ZnJvbSBTMyB0byB0aGVpciBicm93c2VyLCBub3QgdmlhIHlvdXIgY29tcHV0ZXIuDQoNCkkgYmVs aWV2ZSBpdCBpcyB1c2VmdWwgZm9yIGJ1eWluZyBjb250ZW50IChtb3ZpZXMsIHNvZnR3YXJlLi4u KS4gT25jZSB5b3UgaGF2ZSBwYWlkIHlvdSBnZXQgdGhlIHNpZ25lZCBVUkksIGl0IHRpbWVzLW91 dCBzaG9ydGx5IGFmdGVyd2FyZHMuDQoNCg0KSmFtZXMgTWFuZ2VyDQpKYW1lcy5ILk1hbmdlckB0 ZWFtLnRlbHN0cmEuY29tDQpJZGVudGl0eSBhbmQgc2VjdXJpdHkgdGVhbSDigJQgQ2hpZWYgVGVj aG5vbG9neSBPZmZpY2Ug4oCUIFRlbHN0cmENCg== From GFFletch@aol.com Fri Oct 2 05:02:45 2009 Return-Path: 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 4520328C0F9 for ; Fri, 2 Oct 2009 05:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 sC7+zd5Rj-ed for ; Fri, 2 Oct 2009 05:02:43 -0700 (PDT) Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by core3.amsl.com (Postfix) with ESMTP id 7916C28B797 for ; Fri, 2 Oct 2009 05:02:43 -0700 (PDT) Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id n92C3jxp029041; Fri, 2 Oct 2009 08:03:45 -0400 Received: from GFFletch@aol.com by imo-da01.mx.aol.com (mail_out_v42.5.) id l.bee.4f0f8bb7 (34955); Fri, 2 Oct 2009 08:03:43 -0400 (EDT) Received: from c0a8016c.tipt.aol.com ([10.172.2.21]) by cia-da06.mx.aol.com (v125.7) with ESMTP id MAILCIADA064-888b4ac5ec1e1ac; Fri, 02 Oct 2009 08:03:43 -0400 Message-ID: <4AC5EC1E.4010804@aol.com> Date: Fri, 02 Oct 2009 08:03:42 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.172.2.21 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 12:02:45 -0000 In addition to the use case James described, we use this to enable single sign on from a client/desktop app into a browser session. The client signs the URL and then opens the browser with that URL. The backend validates the signature and access token and then establishes an authentication session for the user. A variant of this case is where a partner uses a back-channel federation call to authenticate their user to the AOL authentication service. A successful response includes an access token and secret (the equivalent of) which the partner can then user to sign an URL when their user invokes an AOL service (again providing SSO). Thanks, George P.S. Documentation on this signed API call can be found here: http://dev.aol.com/authentication_for_clients#client2web P.P.S. While these APIs are not OAuth specifically, the patterns are needed for OAuth compliant APIs to be developed Eran Hammer-Lahav wrote: > Can you describe the actual use case? > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Eaton >> Sent: Thursday, October 01, 2009 9:01 PM >> To: George Fletcher >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >> >> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher >> wrote: >> >>> One use case (I think I saw it mentioned somewhere else on the list) >>> >> where >> >>> we've used the URI parameters is when we want the server to sign a >>> >> URL and >> >>> then pass that signed value to the browser to load. This can be done >>> >> with a >> >>> simple 302 and the signed URL. Switching to just supporting the >>> Authorization header will make this more difficult but probably not >>> impossible. >>> >> Yep. I've seen that done multiple places. >> >> One more unexpected use of OAuth... >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From eran@hueniverse.com Fri Oct 2 08:10:28 2009 Return-Path: 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 C91323A6A61 for ; Fri, 2 Oct 2009 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599] 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 Yg9VMyM5ts13 for ; Fri, 2 Oct 2009 08:10:27 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8260E3A6915 for ; Fri, 2 Oct 2009 08:10:27 -0700 (PDT) Received: (qmail 1255 invoked from network); 2 Oct 2009 15:11:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 15:11:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 2 Oct 2009 08:09:19 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Fri, 2 Oct 2009 08:12:05 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpDWHPbrHX3fKR+Q7ienrOrNVmUBwAGWKrA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> In-Reply-To: <4AC5EC1E.4010804@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 15:10:28 -0000 Thanks James, George. If we are going to support sending authentication credentials in the URI qu= ery, what are the requirements to make sure it works well with proxies and = caches? What headers do we need to require the server to return to make sur= e it doesn't get cached? Do we need to require a nonce value for all signat= ure methods to ensure making the request more unique and less likely to rep= eat? In these two use cases, is there a reason for the URI to be used more than = once? Can we simplify the credentials passed via the URI query to provide a= dequate security but without the need for a long and ugly URI with multiple= oauth_ prefixed parameters? These are valid use cases and something we need to worry about to get this = new protocol deployed where other proprietary ones are deployed. But I am n= ot that concerned about the use case mentioned earlier of 'just making it e= asier to send requests'. So if we support query parameters but after some p= rocessing of the parameters to make the URI simpler, that would be acceptab= le to me. EHL > -----Original Message----- > From: George Fletcher [mailto:gffletch@aol.com] > Sent: Friday, October 02, 2009 5:04 AM > To: oauth@ietf.org > Cc: Eran Hammer-Lahav; Brian Eaton > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >=20 > In addition to the use case James described, we use this to enable > single sign on from a client/desktop app into a browser session. The > client signs the URL and then opens the browser with that URL. The > backend validates the signature and access token and then establishes > an > authentication session for the user. >=20 > A variant of this case is where a partner uses a back-channel > federation > call to authenticate their user to the AOL authentication service. A > successful response includes an access token and secret (the equivalent > of) which the partner can then user to sign an URL when their user > invokes an AOL service (again providing SSO). >=20 > Thanks, > George >=20 > P.S. Documentation on this signed API call can be found here: > http://dev.aol.com/authentication_for_clients#client2web >=20 > P.P.S. While these APIs are not OAuth specifically, the patterns are > needed for OAuth compliant APIs to be developed >=20 > Eran Hammer-Lahav wrote: > > Can you describe the actual use case? > > > > EHL > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> Of Brian Eaton > >> Sent: Thursday, October 01, 2009 9:01 PM > >> To: George Fletcher > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >> > >> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher > >> wrote: > >> > >>> One use case (I think I saw it mentioned somewhere else on the > list) > >>> > >> where > >> > >>> we've used the URI parameters is when we want the server to sign a > >>> > >> URL and > >> > >>> then pass that signed value to the browser to load. This can be > done > >>> > >> with a > >> > >>> simple 302 and the signed URL. Switching to just supporting the > >>> Authorization header will make this more difficult but probably not > >>> impossible. > >>> > >> Yep. I've seen that done multiple places. > >> > >> One more unexpected use of OAuth... > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > From GFFletch@aol.com Fri Oct 2 09:15:12 2009 Return-Path: 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 1B2C53A691F for ; Fri, 2 Oct 2009 09:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9OYWkukHPQZx for ; Fri, 2 Oct 2009 09:15:10 -0700 (PDT) Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by core3.amsl.com (Postfix) with ESMTP id 276E628C142 for ; Fri, 2 Oct 2009 09:15:08 -0700 (PDT) Received: from imo-ma04.mx.aol.com (imo-ma04.mx.aol.com [64.12.78.139]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id n92GGKZR029055; Fri, 2 Oct 2009 12:16:20 -0400 Received: from GFFletch@aol.com by imo-ma04.mx.aol.com (mail_out_v42.5.) id l.c19.62f09ca3 (37224); Fri, 2 Oct 2009 12:16:18 -0400 (EDT) Received: from palantir-2.local ([10.181.87.216]) by cia-ma06.mx.aol.com (v125.7) with ESMTP id MAILCIAMA063-91684ac6274f79; Fri, 02 Oct 2009 12:16:15 -0400 Message-ID: <4AC6274F.4090505@aol.com> Date: Fri, 02 Oct 2009 12:16:15 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.87.216 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 16:15:12 -0000 I would expect that in the Amazon case being able to reuse the URL would be beneficial, but I'm not really familiar with that use case. For the SSO use cases, the desire is to prevent replay and make the URL one time use only. We do set cookies during the redirect process so a cache replaying those cookies could be problematic. There are a number of cache control directives that can be used for correctly implemented proxies. A couple reasonable links on the topic [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=-1 [3] http://code.google.com/speed/page-speed/docs/caching.html However, I think this issue is bigger than just requests with URL parameters. If I access a rest resource http://photos.example.com/alice/album/vacation along with it's Authorization header, if this request goes through a proxy, the proxy will mostly likely ignore the Authorization header. Hence the next time that static URL is requested, the contents is returned. The same cache control headers the server needs to send for these specific use cases will apply to the general case as well. I'm a little behind in the lists servs. Has this issue already been solved for the general case using the Authorization header? Thanks, George Eran Hammer-Lahav wrote: > Thanks James, George. > > If we are going to support sending authentication credentials in the URI query, what are the requirements to make sure it works well with proxies and caches? What headers do we need to require the server to return to make sure it doesn't get cached? Do we need to require a nonce value for all signature methods to ensure making the request more unique and less likely to repeat? > > In these two use cases, is there a reason for the URI to be used more than once? Can we simplify the credentials passed via the URI query to provide adequate security but without the need for a long and ugly URI with multiple oauth_ prefixed parameters? > > These are valid use cases and something we need to worry about to get this new protocol deployed where other proprietary ones are deployed. But I am not that concerned about the use case mentioned earlier of 'just making it easier to send requests'. So if we support query parameters but after some processing of the parameters to make the URI simpler, that would be acceptable to me. > > EHL > > >> -----Original Message----- >> From: George Fletcher [mailto:gffletch@aol.com] >> Sent: Friday, October 02, 2009 5:04 AM >> To: oauth@ietf.org >> Cc: Eran Hammer-Lahav; Brian Eaton >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >> >> In addition to the use case James described, we use this to enable >> single sign on from a client/desktop app into a browser session. The >> client signs the URL and then opens the browser with that URL. The >> backend validates the signature and access token and then establishes >> an >> authentication session for the user. >> >> A variant of this case is where a partner uses a back-channel >> federation >> call to authenticate their user to the AOL authentication service. A >> successful response includes an access token and secret (the equivalent >> of) which the partner can then user to sign an URL when their user >> invokes an AOL service (again providing SSO). >> >> Thanks, >> George >> >> P.S. Documentation on this signed API call can be found here: >> http://dev.aol.com/authentication_for_clients#client2web >> >> P.P.S. While these APIs are not OAuth specifically, the patterns are >> needed for OAuth compliant APIs to be developed >> >> Eran Hammer-Lahav wrote: >> >>> Can you describe the actual use case? >>> >>> EHL >>> >>> >>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> >> Behalf >> >>>> Of Brian Eaton >>>> Sent: Thursday, October 01, 2009 9:01 PM >>>> To: George Fletcher >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >>>> >>>> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher >>>> wrote: >>>> >>>> >>>>> One use case (I think I saw it mentioned somewhere else on the >>>>> >> list) >> >>>> where >>>> >>>> >>>>> we've used the URI parameters is when we want the server to sign a >>>>> >>>>> >>>> URL and >>>> >>>> >>>>> then pass that signed value to the browser to load. This can be >>>>> >> done >> >>>> with a >>>> >>>> >>>>> simple 302 and the signed URL. Switching to just supporting the >>>>> Authorization header will make this more difficult but probably not >>>>> impossible. >>>>> >>>>> >>>> Yep. I've seen that done multiple places. >>>> >>>> One more unexpected use of 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 > > From beaton@google.com Fri Oct 2 09:20:10 2009 Return-Path: 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 6BAA328C0F2 for ; Fri, 2 Oct 2009 09:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 n8E30cAhI4YW for ; Fri, 2 Oct 2009 09:20:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 9EB8D3A6A37 for ; Fri, 2 Oct 2009 09:20:08 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id n92GLXGA016222 for ; Fri, 2 Oct 2009 17:21:34 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254500495; bh=0MzKDMIqL65Y4fn4QALelykbabk=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=c cC9PjmZ+NsRPRW14j/GfMY6s/FIebdtcnuzUYyl6E4qx82P3RqFOs5IQdECXzZhoxBX qziklMzJTZLGdoz5rg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Nr91BxjsvEX+I8xDs394BAn69261OFf0L8Fp6bZrETjEe5ywcZQFHtygK+s9gi9aE /q6SMrFoapQtGPNp7uXFw== Received: from pzk36 (pzk36.prod.google.com [10.243.19.164]) by wpaz1.hot.corp.google.com with ESMTP id n92GJj4x027545 for ; Fri, 2 Oct 2009 09:21:31 -0700 Received: by pzk36 with SMTP id 36so1276376pzk.5 for ; Fri, 02 Oct 2009 09:21:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.119.7 with SMTP id r7mr330688wfc.261.1254500490099; Fri, 02 Oct 2009 09:21:30 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 2 Oct 2009 09:21:29 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 16:20:10 -0000 > If we are going to support sending authentication credentials in the URI query, what are the > requirements to make sure it works well with proxies and caches? What headers do we > need to require the server to return to make sure it doesn't get cached? AFAICT, cache control headers and OAuth are completely orthogonal questions. Any web server returning any type of personal/private data must return cache-control headers. That's true whether the authentication is based on secret URLs, or cookies, or basic auth headers, or OAuth. Cheers, Brian From beaton@google.com Fri Oct 2 09:37:52 2009 Return-Path: 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 ACC8A3A6A37 for ; Fri, 2 Oct 2009 09:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 X2ewv8WmCW41 for ; Fri, 2 Oct 2009 09:37:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 9BBAB3A6979 for ; Fri, 2 Oct 2009 09:37:51 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id n92GdGnW004541 for ; Fri, 2 Oct 2009 17:39:16 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254501556; bh=p1HGhbcrzd1zhttQNxXlVrQliiQ=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=xkrmvEAa+OBvz2xHFW eM/7t/vKqygB5GVPC/KaLaFL6ZKGdP1KvFy/yLs3Hdp37q3dMCGX7TYI7L3mZEaJ9/D w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=F1j+tSYWfsV0jO17agp8qC8WtXAeVR7YPzvdtBDGp+TuL8XWw0S491MOYQ/JF9F9K 0HTJ/Wa/5fGyhDAV1IGfg== Received: from pxi30 (pxi30.prod.google.com [10.243.27.30]) by wpaz1.hot.corp.google.com with ESMTP id n92GdDrV015578 for ; Fri, 2 Oct 2009 09:39:13 -0700 Received: by pxi30 with SMTP id 30so1875849pxi.7 for ; Fri, 02 Oct 2009 09:39:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.26.36 with SMTP id d36mr345423wfj.217.1254501553284; Fri, 02 Oct 2009 09:39:13 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF25B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF25B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 2 Oct 2009 09:39:13 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 16:37:52 -0000 On Thu, Oct 1, 2009 at 6:31 PM, Eran Hammer-Lahav wro= te: >> Should probably drop "realm" unless we can define the semantics. =A0(I >> can't.) > > I think 2617 defines realm pretty well. It is a URI string that identifie= s the > set of resources accessible with a given credential. If you feel we need = to > spell out the lessons (restrictions) learned from Basic, we can look into= that. Except that the mapping from "URI string" to "set of resources" bit doesn't actually work in practice. The mappings either tend to be trivial (in which case realm is unnecessary) or complex (in which case realm doesn't have a syntax rich enough to describe the problem.) I can't prove that realm is useless, but I'm pretty sure that if you give me a dozen examples of possible semantics for "realm" I can break all of them. =3D) >> I think that the ABNF should probably just be the prefix, followed by >> name-value pairs. =A0I don't see a reason to have a separate sub-scheme. > > Why define a parameter when it is clearly a sub-scheme? I makes client mu= ch > simpler by being able to look for the first two words in the header and k= nown what is going on. > Otherwise we need to define a certain order for parameters which is ugly. Or we can have clients that know to look at the "Token" scheme and then parse the rest of the header as name/value pairs. There is no need to define parameter ordering. >> WWW-Authenticate: Token > > That's crazy talk. OK. =3D) >> That said, RSA might only get used when requesting access tokens, not >> when using them. =A0There is no RSA private key associated with an >> access token, so it's kind of hard to use it. =3D) > > Then we need to define how it works in the context of authentication. Kee= p in mind that this is > ONLY for accessing protected resources once a token has been obtained. We= will deal > with obtaining tokens separately and there we can include PK support as p= art of the > client credentials package. OK, that makes sense. Cheers, Brian From jpanzer@google.com Fri Oct 2 09:49:37 2009 Return-Path: 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 63E113A68EC for ; Fri, 2 Oct 2009 09:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JxSoASbf-Y1S for ; Fri, 2 Oct 2009 09:49:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 2D9423A6405 for ; Fri, 2 Oct 2009 09:49:34 -0700 (PDT) Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id n92Gp1Gh018837 for ; Fri, 2 Oct 2009 17:51:01 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254502261; bh=FIPiz86sAb/mrrmKQt3tiGGhQlE=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=ExaCWH 5tcukoFMZS3XqZgShJD4aai5/oUgD5OzOT1jp0uhn3vFORkNWIGNOZQoBaVpNtS2vh6 07MbjydLKGLig== 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=A5J/6eD1FvMSOOMl1/2CUBnqMa6LmM54D2+7QiOBN3EE+Usqarkwd7CxTAQW7MtF4 FWP/e2mAWeqzth8/DGReg== Received: from qyk8 (qyk8.prod.google.com [10.241.83.136]) by spaceape14.eur.corp.google.com with ESMTP id n92GowKc022401 for ; Fri, 2 Oct 2009 09:50:58 -0700 Received: by qyk8 with SMTP id 8so1093927qyk.24 for ; Fri, 02 Oct 2009 09:50:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.38.206 with SMTP id c14mr3096420qce.89.1254502256486; Fri, 02 Oct 2009 09:50:56 -0700 (PDT) In-Reply-To: <4AC6274F.4090505@aol.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC6274F.4090505@aol.com> From: John Panzer Date: Fri, 2 Oct 2009 09:50:36 -0700 Message-ID: To: George Fletcher Content-Type: multipart/alternative; boundary=0016368342a45e2b5a0474f69166 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 16:49:37 -0000 --0016368342a45e2b5a0474f69166 Content-Type: text/plain; charset=ISO-8859-1 IANACI (I Am Not A Cache Implementor) but I believe that Authorization: headers cause most default-configured caches to bypass the cache. Aggressive caches can defeat this of course. Caches should pay attention to Vary: as well. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Fri, Oct 2, 2009 at 9:16 AM, George Fletcher wrote: > I would expect that in the Amazon case being able to reuse the URL would be > beneficial, but I'm not really familiar with that use case. > > For the SSO use cases, the desire is to prevent replay and make the URL one > time use only. We do set cookies during the redirect process so a cache > replaying those cookies could be problematic. There are a number of cache > control directives that can be used for correctly implemented proxies. > > A couple reasonable links on the topic > > [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html > [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=-1 > [3] http://code.google.com/speed/page-speed/docs/caching.html > > However, I think this issue is bigger than just requests with URL > parameters. If I access a rest resource > http://photos.example.com/alice/album/vacation along with it's > Authorization header, if this request goes through a proxy, the proxy will > mostly likely ignore the Authorization header. Hence the next time that > static URL is requested, the contents is returned. The same cache control > headers the server needs to send for these specific use cases will apply to > the general case as well. I'm a little behind in the lists servs. Has this > issue already been solved for the general case using the Authorization > header? > > Thanks, > George > > > > > Eran Hammer-Lahav wrote: > >> Thanks James, George. >> >> If we are going to support sending authentication credentials in the URI >> query, what are the requirements to make sure it works well with proxies and >> caches? What headers do we need to require the server to return to make sure >> it doesn't get cached? Do we need to require a nonce value for all signature >> methods to ensure making the request more unique and less likely to repeat? >> >> In these two use cases, is there a reason for the URI to be used more than >> once? Can we simplify the credentials passed via the URI query to provide >> adequate security but without the need for a long and ugly URI with multiple >> oauth_ prefixed parameters? >> >> These are valid use cases and something we need to worry about to get this >> new protocol deployed where other proprietary ones are deployed. But I am >> not that concerned about the use case mentioned earlier of 'just making it >> easier to send requests'. So if we support query parameters but after some >> processing of the parameters to make the URI simpler, that would be >> acceptable to me. >> >> EHL >> >> >> >>> -----Original Message----- >>> From: George Fletcher [mailto:gffletch@aol.com] >>> Sent: Friday, October 02, 2009 5:04 AM >>> To: oauth@ietf.org >>> Cc: Eran Hammer-Lahav; Brian Eaton >>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >>> >>> In addition to the use case James described, we use this to enable >>> single sign on from a client/desktop app into a browser session. The >>> client signs the URL and then opens the browser with that URL. The >>> backend validates the signature and access token and then establishes >>> an >>> authentication session for the user. >>> >>> A variant of this case is where a partner uses a back-channel >>> federation >>> call to authenticate their user to the AOL authentication service. A >>> successful response includes an access token and secret (the equivalent >>> of) which the partner can then user to sign an URL when their user >>> invokes an AOL service (again providing SSO). >>> >>> Thanks, >>> George >>> >>> P.S. Documentation on this signed API call can be found here: >>> http://dev.aol.com/authentication_for_clients#client2web >>> >>> P.P.S. While these APIs are not OAuth specifically, the patterns are >>> needed for OAuth compliant APIs to be developed >>> >>> Eran Hammer-Lahav wrote: >>> >>> >>>> Can you describe the actual use case? >>>> >>>> EHL >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> >>>>> >>>> Behalf >>> >>> >>>> Of Brian Eaton >>>>> Sent: Thursday, October 01, 2009 9:01 PM >>>>> To: George Fletcher >>>>> Cc: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >>>>> >>>>> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> One use case (I think I saw it mentioned somewhere else on the >>>>>> >>>>>> >>>>> list) >>> >>> >>>> where >>>>> >>>>> >>>>> >>>>>> we've used the URI parameters is when we want the server to sign a >>>>>> >>>>>> >>>>>> >>>>> URL and >>>>> >>>>> >>>>> >>>>>> then pass that signed value to the browser to load. This can be >>>>>> >>>>>> >>>>> done >>> >>> >>>> with a >>>>> >>>>> >>>>> >>>>>> simple 302 and the signed URL. Switching to just supporting the >>>>>> Authorization header will make this more difficult but probably not >>>>>> impossible. >>>>>> >>>>>> >>>>>> >>>>> Yep. I've seen that done multiple places. >>>>> >>>>> One more unexpected use of 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 > --0016368342a45e2b5a0474f69166 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IANACI (I Am Not A Cache Implementor) but I believe that Authorization: hea= ders cause most default-configured caches to bypass the cache. =A0Aggressiv= e caches can defeat this of course. =A0Caches should pay attention to Vary:= as well.
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer


On Fri, Oct 2, 2009 at 9:16 AM, George F= letcher <gffletch@= aol.com> wrote:
I would expect that in the Amazon case being able to reuse the URL would be= beneficial, but I'm not really familiar with that use case.

For the SSO use cases, the desire is to prevent replay and make the URL one= time use only. We do set cookies during the redirect process so a cache re= playing those cookies could be problematic. There are a number of cache con= trol directives that can be used for correctly implemented proxies.

A couple reasonable links on the topic

[1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.h= tml
[2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=3D-1 [3] http://code.google.com/speed/page-speed/docs/caching.html<= /a>

However, I think this issue is bigger than just requests with URL parameter= s. If I access a rest resource http://photos.example.com/alice/album/vaca= tion along with it's Authorization header, if this request goes thr= ough a proxy, the proxy will mostly likely ignore the Authorization header.= Hence the next time that static URL is requested, the contents is returned= . The same cache control headers the server needs to send for these specifi= c use cases will apply to the general case as well. I'm a little behind= in the lists servs. Has this issue already been solved for the general cas= e using the Authorization header?

Thanks,
George




Eran Hammer-Lahav wrote:
Thanks James, George.

If we are going to support sending authentication credentials in the URI qu= ery, what are the requirements to make sure it works well with proxies and = caches? What headers do we need to require the server to return to make sur= e it doesn't get cached? Do we need to require a nonce value for all si= gnature methods to ensure making the request more unique and less likely to= repeat?

In these two use cases, is there a reason for the URI to be used more than = once? Can we simplify the credentials passed via the URI query to provide a= dequate security but without the need for a long and ugly URI with multiple= oauth_ prefixed parameters?

These are valid use cases and something we need to worry about to get this = new protocol deployed where other proprietary ones are deployed. But I am n= ot that concerned about the use case mentioned earlier of 'just making = it easier to send requests'. So if we support query parameters but afte= r some processing of the parameters to make the URI simpler, that would be = acceptable to me.

EHL

=A0
-----Original Message-----
From: George Fletcher [mailto:gffletch@aol.com]
Sent: Friday, October 02, 2009 5:04 AM
To: oauth@ietf.org<= br> Cc: Eran Hammer-Lahav; Brian Eaton
Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!)

In addition to the use case James described, we use this to enable
single sign on from a client/desktop app into a browser session. The
client signs the URL and then opens the browser with that URL. The
backend validates the signature and access token and then establishes
an
authentication session for the user.

A variant of this case is where a partner uses a back-channel
federation
call to authenticate their user to the AOL authentication service. A
successful response includes an access token and secret (the equivalent
of) which the partner can then user to sign an URL when their user
invokes an AOL service (again providing SSO).

Thanks,
George

P.S. Documentation on this signed API call can be found here:
http://dev.aol.com/authentication_for_clients#client2web
P.P.S. While these APIs are not OAuth specifically, the patterns are
needed for OAuth compliant APIs to be developed

Eran Hammer-Lahav wrote:
=A0 =A0
Can you describe the actual use case?

EHL


=A0 =A0 =A0
-----Original Message-----
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On
=A0 =A0 =A0 =A0
Behalf
=A0 =A0
Of Brian Eaton
Sent: Thursday, October 01, 2009 9:01 PM
To: George Fletcher
Cc: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!)

On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher <gffletch@aol.com>
wrote:

=A0 =A0 =A0 =A0
One use case (I think I saw it mentioned somewhere else on the
=A0 =A0 =A0 =A0 =A0
list)
=A0 =A0
where

=A0 =A0 =A0 =A0
we've used the URI parameters is when we want the server to sign a

=A0 =A0 =A0 =A0 =A0
URL and

=A0 =A0 =A0 =A0
then pass that signed value to the browser to load. This can be
=A0 =A0 =A0 =A0 =A0
done
=A0 =A0
with a

=A0 =A0 =A0 =A0
simple 302 and the signed URL. Switching to just supporting the
Authorization header will make this more difficult but probably not
impossible.

=A0 =A0 =A0 =A0 =A0
Yep. =A0I've seen that done multiple places.

One more unexpected use of OAuth...
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0 =A0 =A0 =A0
=A0 =A0 =A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016368342a45e2b5a0474f69166-- From eran@hueniverse.com Fri Oct 2 10:11:08 2009 Return-Path: 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 5E58F3A67B0 for ; Fri, 2 Oct 2009 10:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_00=-2.599] 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 9D24d2lwvCSY for ; Fri, 2 Oct 2009 10:11:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 479353A6964 for ; Fri, 2 Oct 2009 10:11:07 -0700 (PDT) Received: (qmail 25249 invoked from network); 2 Oct 2009 17:12:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 17:12:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 2 Oct 2009 10:09:48 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 2 Oct 2009 10:12:34 -0700 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpDfuMiP6dOb0EATO+xOSPlL6Rv3wAA/qGA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2696@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF25B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:11:08 -0000 In the case of Basic, it is very useful for UI optimization and I think tha= t can translate to OAuth as well. The browser knows it already asked the us= er for credentials for a given realm and can simply reuse them without havi= ng to ask for it again. However, the browsers today look for other bits of = information to make sure an evil domain doesn't pretend to have the realm o= f a good domain, etc. Also, I think I skipped your comment about why we need a new scheme name (t= o replace 'OAuth'). I don't want to use the oauth_version parameter but sti= ll need a super simple way for clients to figure out that this is another v= ersion. It also means that old clients will not try to do something stupid = with the wrong OAuth challenge because they don't look at the version. The version parameter was poorly defined and does not provide enough clarit= y to reuse the same scheme name. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, October 02, 2009 9:39 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token >=20 > On Thu, Oct 1, 2009 at 6:31 PM, Eran Hammer-Lahav > wrote: > >> Should probably drop "realm" unless we can define the semantics. =A0(I > >> can't.) > > > > I think 2617 defines realm pretty well. It is a URI string that > identifies the > > set of resources accessible with a given credential. If you feel we > need to > > spell out the lessons (restrictions) learned from Basic, we can look > into that. >=20 > Except that the mapping from "URI string" to "set of resources" bit > doesn't actually work in practice. The mappings either tend to be > trivial (in which case realm is unnecessary) or complex (in which case > realm doesn't have a syntax rich enough to describe the problem.) >=20 > I can't prove that realm is useless, but I'm pretty sure that if you > give me a dozen examples of possible semantics for "realm" I can break > all of them. =3D) >=20 > >> I think that the ABNF should probably just be the prefix, followed > by > >> name-value pairs. =A0I don't see a reason to have a separate sub- > scheme. > > > > Why define a parameter when it is clearly a sub-scheme? I makes > client much > > simpler by being able to look for the first two words in the header > and known what is going on. > > Otherwise we need to define a certain order for parameters which is > ugly. >=20 > Or we can have clients that know to look at the "Token" scheme and > then parse the rest of the header as name/value pairs. There is no > need to define parameter ordering. >=20 > >> WWW-Authenticate: Token > > > > That's crazy talk. >=20 > OK. =3D) >=20 > >> That said, RSA might only get used when requesting access tokens, > not > >> when using them. =A0There is no RSA private key associated with an > >> access token, so it's kind of hard to use it. =3D) > > > > Then we need to define how it works in the context of authentication. > Keep in mind that this is > > ONLY for accessing protected resources once a token has been > obtained. We will deal > > with obtaining tokens separately and there we can include PK support > as part of the > > client credentials package. >=20 > OK, that makes sense. >=20 > Cheers, > Brian From GFFletch@aol.com Fri Oct 2 10:17:46 2009 Return-Path: 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 EE6BA3A67B0 for ; Fri, 2 Oct 2009 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rHSRZUR8v1vl for ; Fri, 2 Oct 2009 10:17:24 -0700 (PDT) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by core3.amsl.com (Postfix) with ESMTP id 5FAFD3A685F for ; Fri, 2 Oct 2009 10:17:24 -0700 (PDT) Received: from imo-ma04.mx.aol.com (imo-ma04.mx.aol.com [64.12.78.139]) by imr-ma01.mx.aol.com (8.14.1/8.14.1) with ESMTP id n92HIj4O003672; Fri, 2 Oct 2009 13:18:45 -0400 Received: from GFFletch@aol.com by imo-ma04.mx.aol.com (mail_out_v42.5.) id y.c6c.57ead1d4 (45475); Fri, 2 Oct 2009 13:18:41 -0400 (EDT) Received: from palantir-2.local ([10.181.87.216]) by cia-mc06.mx.aol.com (v125.7) with ESMTP id MAILCIAMC064-b1a34ac635ee2b1; Fri, 02 Oct 2009 13:18:39 -0400 Message-ID: <4AC635EE.5030105@aol.com> Date: Fri, 02 Oct 2009 13:18:38 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: John Panzer References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC6274F.4090505@aol.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.87.216 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:17:47 -0000 Agreed. I think the issue isn't "well behaved" caches because there are lots of ways to solve this (e.g. cache-control: private, expires: 0, vary (as you mentioned), etc). I believe the concern is the "aggressive caches". I agree with Brian that the issue of proxies and caching is orthogonal to the issue of URL parameters. Thanks, George P.S. It also used to be that the presence of a '?' in a URL caused most well-behaved caches to bypass the cache as well. We had that rule it our caches for a very long time:) John Panzer wrote: > IANACI (I Am Not A Cache Implementor) but I believe that > Authorization: headers cause most default-configured caches to bypass > the cache. Aggressive caches can defeat this of course. Caches > should pay attention to Vary: as well. > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org > / @jpanzer > > > > On Fri, Oct 2, 2009 at 9:16 AM, George Fletcher > wrote: > > I would expect that in the Amazon case being able to reuse the URL > would be beneficial, but I'm not really familiar with that use case. > > For the SSO use cases, the desire is to prevent replay and make > the URL one time use only. We do set cookies during the redirect > process so a cache replaying those cookies could be problematic. > There are a number of cache control directives that can be used > for correctly implemented proxies. > > A couple reasonable links on the topic > > [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html > [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=-1 > [3] http://code.google.com/speed/page-speed/docs/caching.html > > However, I think this issue is bigger than just requests with URL > parameters. If I access a rest resource > http://photos.example.com/alice/album/vacation along with it's > Authorization header, if this request goes through a proxy, the > proxy will mostly likely ignore the Authorization header. Hence > the next time that static URL is requested, the contents is > returned. The same cache control headers the server needs to send > for these specific use cases will apply to the general case as > well. I'm a little behind in the lists servs. Has this issue > already been solved for the general case using the Authorization > header? > > Thanks, > George > > > > > Eran Hammer-Lahav wrote: > > Thanks James, George. > > If we are going to support sending authentication credentials > in the URI query, what are the requirements to make sure it > works well with proxies and caches? What headers do we need to > require the server to return to make sure it doesn't get > cached? Do we need to require a nonce value for all signature > methods to ensure making the request more unique and less > likely to repeat? > > In these two use cases, is there a reason for the URI to be > used more than once? Can we simplify the credentials passed > via the URI query to provide adequate security but without the > need for a long and ugly URI with multiple oauth_ prefixed > parameters? > > These are valid use cases and something we need to worry about > to get this new protocol deployed where other proprietary ones > are deployed. But I am not that concerned about the use case > mentioned earlier of 'just making it easier to send requests'. > So if we support query parameters but after some processing of > the parameters to make the URI simpler, that would be > acceptable to me. > > EHL > > > > -----Original Message----- > From: George Fletcher [mailto:gffletch@aol.com > ] > Sent: Friday, October 02, 2009 5:04 AM > To: oauth@ietf.org > Cc: Eran Hammer-Lahav; Brian Eaton > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > > In addition to the use case James described, we use this > to enable > single sign on from a client/desktop app into a browser > session. The > client signs the URL and then opens the browser with that > URL. The > backend validates the signature and access token and then > establishes > an > authentication session for the user. > > A variant of this case is where a partner uses a back-channel > federation > call to authenticate their user to the AOL authentication > service. A > successful response includes an access token and secret > (the equivalent > of) which the partner can then user to sign an URL when > their user > invokes an AOL service (again providing SSO). > > Thanks, > George > > P.S. Documentation on this signed API call can be found here: > http://dev.aol.com/authentication_for_clients#client2web > > P.P.S. While these APIs are not OAuth specifically, the > patterns are > needed for OAuth compliant APIs to be developed > > Eran Hammer-Lahav wrote: > > > Can you describe the actual use case? > > EHL > > > > > -----Original Message----- > From: oauth-bounces@ietf.org > > [mailto:oauth-bounces@ietf.org > ] On > > > Behalf > > > Of Brian Eaton > Sent: Thursday, October 01, 2009 9:01 PM > To: George Fletcher > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Reevaluating Assumptions > (Important!) > > On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher > > > wrote: > > > > One use case (I think I saw it mentioned > somewhere else on the > > > list) > > > where > > > > we've used the URI parameters is when we want > the server to sign a > > > > URL and > > > > then pass that signed value to the browser to > load. This can be > > > done > > > with a > > > > simple 302 and the signed URL. Switching to > just supporting the > Authorization header will make this more > difficult but probably not > impossible. > > > > Yep. I've seen that done multiple places. > > One more unexpected use of 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 > > From eran@hueniverse.com Fri Oct 2 10:19:31 2009 Return-Path: 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 AED8628C0DB for ; Fri, 2 Oct 2009 10:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599] 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 ZE+bwfZnUGoF for ; Fri, 2 Oct 2009 10:19:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 81E0D3A6359 for ; Fri, 2 Oct 2009 10:19:30 -0700 (PDT) Received: (qmail 28958 invoked from network); 2 Oct 2009 17:20:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 17:20:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 2 Oct 2009 10:18:10 -0700 From: Eran Hammer-Lahav To: George Fletcher , "oauth@ietf.org" Date: Fri, 2 Oct 2009 10:20:46 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpDe7dO2XeDlB8BSd+qkFo5xmL99AACFVIA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2699@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC6274F.4090505@aol.com> In-Reply-To: <4AC6274F.4090505@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:19:31 -0000 Actually, I am going to take this back. This is not really a valid reason to support authentication parameters in t= he query. In this scenario, the resource owner is able to make an authentic= ated request using the auth headers. That request produces a special URI wh= ich can be shared, bypassing the access controls. Why does this needs to be= covered by OAuth? What prevents any server from issuing a time-limited/res= tricted/single-use/etc URI using long token such as: http://example.com/resource/share/1k2j3h1oi823h123hk1j23ho182h31j2h3o182h3o= 12hi3o182h3o182h3 I just don't see any reason why this is lesser than producing a URI that us= es OAuth parameters. Whatever the server needs can be either encoded into t= his long token or maintained in a database. So back to no real use case for query parameters support. EHL > -----Original Message----- > From: George Fletcher [mailto:gffletch@aol.com] > Sent: Friday, October 02, 2009 9:16 AM > To: oauth@ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >=20 > I would expect that in the Amazon case being able to reuse the URL > would > be beneficial, but I'm not really familiar with that use case. >=20 > For the SSO use cases, the desire is to prevent replay and make the URL > one time use only. We do set cookies during the redirect process so a > cache replaying those cookies could be problematic. There are a number > of cache control directives that can be used for correctly implemented > proxies. >=20 > A couple reasonable links on the topic >=20 > [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html > [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=3D-1 > [3] http://code.google.com/speed/page-speed/docs/caching.html >=20 > However, I think this issue is bigger than just requests with URL > parameters. If I access a rest resource > http://photos.example.com/alice/album/vacation along with it's > Authorization header, if this request goes through a proxy, the proxy > will mostly likely ignore the Authorization header. Hence the next time > that static URL is requested, the contents is returned. The same cache > control headers the server needs to send for these specific use cases > will apply to the general case as well. I'm a little behind in the > lists > servs. Has this issue already been solved for the general case using > the > Authorization header? >=20 > Thanks, > George >=20 >=20 >=20 > Eran Hammer-Lahav wrote: > > Thanks James, George. > > > > If we are going to support sending authentication credentials in the > URI query, what are the requirements to make sure it works well with > proxies and caches? What headers do we need to require the server to > return to make sure it doesn't get cached? Do we need to require a > nonce value for all signature methods to ensure making the request more > unique and less likely to repeat? > > > > In these two use cases, is there a reason for the URI to be used more > than once? Can we simplify the credentials passed via the URI query to > provide adequate security but without the need for a long and ugly URI > with multiple oauth_ prefixed parameters? >=20 > > > > These are valid use cases and something we need to worry about to get > this new protocol deployed where other proprietary ones are deployed. > But I am not that concerned about the use case mentioned earlier of > 'just making it easier to send requests'. So if we support query > parameters but after some processing of the parameters to make the URI > simpler, that would be acceptable to me. > > > > EHL > > > > > >> -----Original Message----- > >> From: George Fletcher [mailto:gffletch@aol.com] > >> Sent: Friday, October 02, 2009 5:04 AM > >> To: oauth@ietf.org > >> Cc: Eran Hammer-Lahav; Brian Eaton > >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >> > >> In addition to the use case James described, we use this to enable > >> single sign on from a client/desktop app into a browser session. The > >> client signs the URL and then opens the browser with that URL. The > >> backend validates the signature and access token and then > establishes > >> an > >> authentication session for the user. > >> > >> A variant of this case is where a partner uses a back-channel > >> federation > >> call to authenticate their user to the AOL authentication service. A > >> successful response includes an access token and secret (the > equivalent > >> of) which the partner can then user to sign an URL when their user > >> invokes an AOL service (again providing SSO). > >> > >> Thanks, > >> George > >> > >> P.S. Documentation on this signed API call can be found here: > >> http://dev.aol.com/authentication_for_clients#client2web > >> > >> P.P.S. While these APIs are not OAuth specifically, the patterns are > >> needed for OAuth compliant APIs to be developed > >> > >> Eran Hammer-Lahav wrote: > >> > >>> Can you describe the actual use case? > >>> > >>> EHL > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> > >> Behalf > >> > >>>> Of Brian Eaton > >>>> Sent: Thursday, October 01, 2009 9:01 PM > >>>> To: George Fletcher > >>>> Cc: oauth@ietf.org > >>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>> > >>>> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher > >>>> wrote: > >>>> > >>>> > >>>>> One use case (I think I saw it mentioned somewhere else on the > >>>>> > >> list) > >> > >>>> where > >>>> > >>>> > >>>>> we've used the URI parameters is when we want the server to sign > a > >>>>> > >>>>> > >>>> URL and > >>>> > >>>> > >>>>> then pass that signed value to the browser to load. This can be > >>>>> > >> done > >> > >>>> with a > >>>> > >>>> > >>>>> simple 302 and the signed URL. Switching to just supporting the > >>>>> Authorization header will make this more difficult but probably > not > >>>>> impossible. > >>>>> > >>>>> > >>>> Yep. I've seen that done multiple places. > >>>> > >>>> One more unexpected use of 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 > > > > From beaton@google.com Fri Oct 2 10:24:36 2009 Return-Path: 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 86CA13A687A for ; Fri, 2 Oct 2009 10:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 9XduCmXBnRwq for ; Fri, 2 Oct 2009 10:24:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id AB5053A6359 for ; Fri, 2 Oct 2009 10:24:35 -0700 (PDT) Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id n92HQ2NT004382 for ; Fri, 2 Oct 2009 10:26:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254504363; bh=I8CHtiPBf1GZ6TFyONvsWRND+68=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=G zuLHrIBjdvxidP0UOFlegejmRiyXwoLjapkZlj4H5RFRE++L5YxMwmn8QiAHaXUtMM7 6X8ICo+WgOgvLlHpbg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=rXFa8DJsmvH+s22QeDILCMUIPKxj0z6cTr4U5WDwjOz4mfD8bau/4ThMCgcO0M3jR ZDU4SxgjLe3AMz4jRChIg== Received: from pzk39 (pzk39.prod.google.com [10.243.19.167]) by spaceape12.eur.corp.google.com with ESMTP id n92HNS7b027716 for ; Fri, 2 Oct 2009 10:25:59 -0700 Received: by pzk39 with SMTP id 39so1250997pzk.15 for ; Fri, 02 Oct 2009 10:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.59.6 with SMTP id h6mr351040wfa.25.1254504359241; Fri, 02 Oct 2009 10:25:59 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2699@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC6274F.4090505@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2699@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 2 Oct 2009 10:25:59 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:24:36 -0000 On Fri, Oct 2, 2009 at 10:20 AM, Eran Hammer-Lahav wrote: > Why does this needs to be covered by OAuth? What prevents any server from issuing > a time-limited/restricted/single-use/etc URI using long token such as: > > http://example.com/resource/share/1k2j3h1oi823h123hk1j23ho182h31j2h3o182h3o12hi3o182h3o182h3 > > I just don't see any reason why this is lesser than producing a URI that uses OAuth parameters. > Whatever the server needs can be either encoded into this long token or maintained in a database. I'd bet that people will keep using the OAuth 1.0 URL signing scheme for this purpose. It works pretty well as-is. URL signing doesn't seem to apply to the core OAuth use cases around delegation and client-to-server authentication. Cheers, Brian From GFFletch@aol.com Fri Oct 2 10:29:53 2009 Return-Path: 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 CFAAE3A67F5 for ; Fri, 2 Oct 2009 10:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 0-6sUDuTWO74 for ; Fri, 2 Oct 2009 10:29:52 -0700 (PDT) Received: from imr-da05.mx.aol.com (imr-da05.mx.aol.com [205.188.105.147]) by core3.amsl.com (Postfix) with ESMTP id C07AF3A67B4 for ; Fri, 2 Oct 2009 10:29:51 -0700 (PDT) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-da05.mx.aol.com (8.14.1/8.14.1) with ESMTP id n92HV0dW015780; Fri, 2 Oct 2009 13:31:00 -0400 Received: from GFFletch@aol.com by imo-ma01.mx.aol.com (mail_out_v42.5.) id l.c6f.3d66c007 (45487); Fri, 2 Oct 2009 13:30:57 -0400 (EDT) Received: from palantir-2.local ([10.181.87.216]) by cia-mc07.mx.aol.com (v125.7) with ESMTP id MAILCIAMC072-b1af4ac638d0283; Fri, 02 Oct 2009 13:30:56 -0400 Message-ID: <4AC638D0.20401@aol.com> Date: Fri, 02 Oct 2009 13:30:56 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC6274F.4090505@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2699@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2699@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.87.216 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:29:53 -0000 This is possible but it gets complicated. If server A (the one issuing the long encrypted opaque token) is separate (meaning not from the same company) from server B (the server receiving and validating the token) then both server A and Server B have to agree on the format of the token and the mechanism for "encrypting" or "signing" it. Since OAuth provides a way to secure requests via signing, this becomes a very easy way to support servers A and B being from multiple companies (or whatever). For sure, the partners could agree to take the string that would be the value of the Authorization header, base64 it and add it to the URL. Maybe this could be the simplifying mechanism for adding OAuth to URLs. Just define an oauth_authz parameter that is optional and contains the base64 encoded version of the Authorization header. Simple to process and easy to implement. Thanks, George Eran Hammer-Lahav wrote: > Actually, I am going to take this back. > > This is not really a valid reason to support authentication parameters in the query. In this scenario, the resource owner is able to make an authenticated request using the auth headers. That request produces a special URI which can be shared, bypassing the access controls. Why does this needs to be covered by OAuth? What prevents any server from issuing a time-limited/restricted/single-use/etc URI using long token such as: > > http://example.com/resource/share/1k2j3h1oi823h123hk1j23ho182h31j2h3o182h3o12hi3o182h3o182h3 > > I just don't see any reason why this is lesser than producing a URI that uses OAuth parameters. Whatever the server needs can be either encoded into this long token or maintained in a database. > > So back to no real use case for query parameters support. > > EHL > > >> -----Original Message----- >> From: George Fletcher [mailto:gffletch@aol.com] >> Sent: Friday, October 02, 2009 9:16 AM >> To: oauth@ietf.org >> Cc: Eran Hammer-Lahav >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >> >> I would expect that in the Amazon case being able to reuse the URL >> would >> be beneficial, but I'm not really familiar with that use case. >> >> For the SSO use cases, the desire is to prevent replay and make the URL >> one time use only. We do set cookies during the redirect process so a >> cache replaying those cookies could be problematic. There are a number >> of cache control directives that can be used for correctly implemented >> proxies. >> >> A couple reasonable links on the topic >> >> [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html >> [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=-1 >> [3] http://code.google.com/speed/page-speed/docs/caching.html >> >> However, I think this issue is bigger than just requests with URL >> parameters. If I access a rest resource >> http://photos.example.com/alice/album/vacation along with it's >> Authorization header, if this request goes through a proxy, the proxy >> will mostly likely ignore the Authorization header. Hence the next time >> that static URL is requested, the contents is returned. The same cache >> control headers the server needs to send for these specific use cases >> will apply to the general case as well. I'm a little behind in the >> lists >> servs. Has this issue already been solved for the general case using >> the >> Authorization header? >> >> Thanks, >> George >> >> >> >> Eran Hammer-Lahav wrote: >> >>> Thanks James, George. >>> >>> If we are going to support sending authentication credentials in the >>> >> URI query, what are the requirements to make sure it works well with >> proxies and caches? What headers do we need to require the server to >> return to make sure it doesn't get cached? Do we need to require a >> nonce value for all signature methods to ensure making the request more >> unique and less likely to repeat? >> >>> In these two use cases, is there a reason for the URI to be used more >>> >> than once? Can we simplify the credentials passed via the URI query to >> provide adequate security but without the need for a long and ugly URI >> with multiple oauth_ prefixed parameters? >> >> >>> These are valid use cases and something we need to worry about to get >>> >> this new protocol deployed where other proprietary ones are deployed. >> But I am not that concerned about the use case mentioned earlier of >> 'just making it easier to send requests'. So if we support query >> parameters but after some processing of the parameters to make the URI >> simpler, that would be acceptable to me. >> >>> EHL >>> >>> >>> >>>> -----Original Message----- >>>> From: George Fletcher [mailto:gffletch@aol.com] >>>> Sent: Friday, October 02, 2009 5:04 AM >>>> To: oauth@ietf.org >>>> Cc: Eran Hammer-Lahav; Brian Eaton >>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >>>> >>>> In addition to the use case James described, we use this to enable >>>> single sign on from a client/desktop app into a browser session. The >>>> client signs the URL and then opens the browser with that URL. The >>>> backend validates the signature and access token and then >>>> >> establishes >> >>>> an >>>> authentication session for the user. >>>> >>>> A variant of this case is where a partner uses a back-channel >>>> federation >>>> call to authenticate their user to the AOL authentication service. A >>>> successful response includes an access token and secret (the >>>> >> equivalent >> >>>> of) which the partner can then user to sign an URL when their user >>>> invokes an AOL service (again providing SSO). >>>> >>>> Thanks, >>>> George >>>> >>>> P.S. Documentation on this signed API call can be found here: >>>> http://dev.aol.com/authentication_for_clients#client2web >>>> >>>> P.P.S. While these APIs are not OAuth specifically, the patterns are >>>> needed for OAuth compliant APIs to be developed >>>> >>>> Eran Hammer-Lahav wrote: >>>> >>>> >>>>> Can you describe the actual use case? >>>>> >>>>> EHL >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> >>>>>> >>>> Behalf >>>> >>>> >>>>>> Of Brian Eaton >>>>>> Sent: Thursday, October 01, 2009 9:01 PM >>>>>> To: George Fletcher >>>>>> Cc: oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >>>>>> >>>>>> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> One use case (I think I saw it mentioned somewhere else on the >>>>>>> >>>>>>> >>>> list) >>>> >>>> >>>>>> where >>>>>> >>>>>> >>>>>> >>>>>>> we've used the URI parameters is when we want the server to sign >>>>>>> >> a >> >>>>>>> >>>>>> URL and >>>>>> >>>>>> >>>>>> >>>>>>> then pass that signed value to the browser to load. This can be >>>>>>> >>>>>>> >>>> done >>>> >>>> >>>>>> with a >>>>>> >>>>>> >>>>>> >>>>>>> simple 302 and the signed URL. Switching to just supporting the >>>>>>> Authorization header will make this more difficult but probably >>>>>>> >> not >> >>>>>>> impossible. >>>>>>> >>>>>>> >>>>>>> >>>>>> Yep. I've seen that done multiple places. >>>>>> >>>>>> One more unexpected use of 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 >>> >>> >>> > > From eran@hueniverse.com Fri Oct 2 10:43:36 2009 Return-Path: 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 D0BBC3A6846 for ; Fri, 2 Oct 2009 10:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599] 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 WHYSpT++VDMC for ; Fri, 2 Oct 2009 10:43:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BEDB33A67B0 for ; Fri, 2 Oct 2009 10:43:28 -0700 (PDT) Received: (qmail 6751 invoked from network); 2 Oct 2009 17:44:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 17:44:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 2 Oct 2009 10:44:37 -0700 From: Eran Hammer-Lahav To: George Fletcher Date: Fri, 2 Oct 2009 10:44:54 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpDhic0VrdG1sBsTniBFrbOIFDdpwAAS88g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF26A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC6274F.4090505@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2699@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC638D0.20401@aol.com> In-Reply-To: <4AC638D0.20401@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:43:38 -0000 I can live with something like that. The problem will be that it will requi= re normalizing the request URI to remove the OAuth parameter before validat= ing the signature. But this is completely on the server so I don't mind it. I'll include something like this in the upcoming revision (pending more fee= dback). As for sending form-encoded auth parameters, no one has argued to keep that= so I think it is save to drop it completely. EHL > -----Original Message----- > From: George Fletcher [mailto:gffletch@aol.com] > Sent: Friday, October 02, 2009 10:31 AM > To: oauth@ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >=20 > This is possible but it gets complicated. If server A (the one issuing > the long encrypted opaque token) is separate (meaning not from the same > company) from server B (the server receiving and validating the token) > then both server A and Server B have to agree on the format of the > token > and the mechanism for "encrypting" or "signing" it. >=20 > Since OAuth provides a way to secure requests via signing, this becomes > a very easy way to support servers A and B being from multiple > companies > (or whatever). For sure, the partners could agree to take the string > that would be the value of the Authorization header, base64 it and add > it to the URL. >=20 > Maybe this could be the simplifying mechanism for adding OAuth to URLs. > Just define an oauth_authz parameter that is optional and contains the > base64 encoded version of the Authorization header. Simple to process > and easy to implement. >=20 > Thanks, > George >=20 > Eran Hammer-Lahav wrote: > > Actually, I am going to take this back. > > > > This is not really a valid reason to support authentication > parameters in the query. In this scenario, the resource owner is able > to make an authenticated request using the auth headers. That request > produces a special URI which can be shared, bypassing the access > controls. Why does this needs to be covered by OAuth? What prevents any > server from issuing a time-limited/restricted/single-use/etc URI using > long token such as: > > > > > http://example.com/resource/share/1k2j3h1oi823h123hk1j23ho182h31j2h3o18 > 2h3o12hi3o182h3o182h3 > > > > I just don't see any reason why this is lesser than producing a URI > that uses OAuth parameters. Whatever the server needs can be either > encoded into this long token or maintained in a database. > > > > So back to no real use case for query parameters support. > > > > EHL > > > > > >> -----Original Message----- > >> From: George Fletcher [mailto:gffletch@aol.com] > >> Sent: Friday, October 02, 2009 9:16 AM > >> To: oauth@ietf.org > >> Cc: Eran Hammer-Lahav > >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >> > >> I would expect that in the Amazon case being able to reuse the URL > >> would > >> be beneficial, but I'm not really familiar with that use case. > >> > >> For the SSO use cases, the desire is to prevent replay and make the > URL > >> one time use only. We do set cookies during the redirect process so > a > >> cache replaying those cookies could be problematic. There are a > number > >> of cache control directives that can be used for correctly > implemented > >> proxies. > >> > >> A couple reasonable links on the topic > >> > >> [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html > >> [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=3D-1 > >> [3] http://code.google.com/speed/page-speed/docs/caching.html > >> > >> However, I think this issue is bigger than just requests with URL > >> parameters. If I access a rest resource > >> http://photos.example.com/alice/album/vacation along with it's > >> Authorization header, if this request goes through a proxy, the > proxy > >> will mostly likely ignore the Authorization header. Hence the next > time > >> that static URL is requested, the contents is returned. The same > cache > >> control headers the server needs to send for these specific use > cases > >> will apply to the general case as well. I'm a little behind in the > >> lists > >> servs. Has this issue already been solved for the general case using > >> the > >> Authorization header? > >> > >> Thanks, > >> George > >> > >> > >> > >> Eran Hammer-Lahav wrote: > >> > >>> Thanks James, George. > >>> > >>> If we are going to support sending authentication credentials in > the > >>> > >> URI query, what are the requirements to make sure it works well with > >> proxies and caches? What headers do we need to require the server to > >> return to make sure it doesn't get cached? Do we need to require a > >> nonce value for all signature methods to ensure making the request > more > >> unique and less likely to repeat? > >> > >>> In these two use cases, is there a reason for the URI to be used > more > >>> > >> than once? Can we simplify the credentials passed via the URI query > to > >> provide adequate security but without the need for a long and ugly > URI > >> with multiple oauth_ prefixed parameters? > >> > >> > >>> These are valid use cases and something we need to worry about to > get > >>> > >> this new protocol deployed where other proprietary ones are > deployed. > >> But I am not that concerned about the use case mentioned earlier of > >> 'just making it easier to send requests'. So if we support query > >> parameters but after some processing of the parameters to make the > URI > >> simpler, that would be acceptable to me. > >> > >>> EHL > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: George Fletcher [mailto:gffletch@aol.com] > >>>> Sent: Friday, October 02, 2009 5:04 AM > >>>> To: oauth@ietf.org > >>>> Cc: Eran Hammer-Lahav; Brian Eaton > >>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>> > >>>> In addition to the use case James described, we use this to enable > >>>> single sign on from a client/desktop app into a browser session. > The > >>>> client signs the URL and then opens the browser with that URL. The > >>>> backend validates the signature and access token and then > >>>> > >> establishes > >> > >>>> an > >>>> authentication session for the user. > >>>> > >>>> A variant of this case is where a partner uses a back-channel > >>>> federation > >>>> call to authenticate their user to the AOL authentication service. > A > >>>> successful response includes an access token and secret (the > >>>> > >> equivalent > >> > >>>> of) which the partner can then user to sign an URL when their user > >>>> invokes an AOL service (again providing SSO). > >>>> > >>>> Thanks, > >>>> George > >>>> > >>>> P.S. Documentation on this signed API call can be found here: > >>>> http://dev.aol.com/authentication_for_clients#client2web > >>>> > >>>> P.P.S. While these APIs are not OAuth specifically, the patterns > are > >>>> needed for OAuth compliant APIs to be developed > >>>> > >>>> Eran Hammer-Lahav wrote: > >>>> > >>>> > >>>>> Can you describe the actual use case? > >>>>> > >>>>> EHL > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>>>> > >>>>>> > >>>> Behalf > >>>> > >>>> > >>>>>> Of Brian Eaton > >>>>>> Sent: Thursday, October 01, 2009 9:01 PM > >>>>>> To: George Fletcher > >>>>>> Cc: oauth@ietf.org > >>>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>>>> > >>>>>> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher > > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> One use case (I think I saw it mentioned somewhere else on the > >>>>>>> > >>>>>>> > >>>> list) > >>>> > >>>> > >>>>>> where > >>>>>> > >>>>>> > >>>>>> > >>>>>>> we've used the URI parameters is when we want the server to > sign > >>>>>>> > >> a > >> > >>>>>>> > >>>>>> URL and > >>>>>> > >>>>>> > >>>>>> > >>>>>>> then pass that signed value to the browser to load. This can be > >>>>>>> > >>>>>>> > >>>> done > >>>> > >>>> > >>>>>> with a > >>>>>> > >>>>>> > >>>>>> > >>>>>>> simple 302 and the signed URL. Switching to just supporting the > >>>>>>> Authorization header will make this more difficult but probably > >>>>>>> > >> not > >> > >>>>>>> impossible. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Yep. I've seen that done multiple places. > >>>>>> > >>>>>> One more unexpected use of 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 > >>> > >>> > >>> > > > > From GFFletch@aol.com Fri Oct 2 11:05:22 2009 Return-Path: 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 4AF6728C119 for ; Fri, 2 Oct 2009 11:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Ove3pZYGhRi5 for ; Fri, 2 Oct 2009 11:05:20 -0700 (PDT) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by core3.amsl.com (Postfix) with ESMTP id 8702C3A6811 for ; Fri, 2 Oct 2009 11:05:20 -0700 (PDT) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-ma01.mx.aol.com (8.14.1/8.14.1) with ESMTP id n92I6UCe003479; Fri, 2 Oct 2009 14:06:30 -0400 Received: from GFFletch@aol.com by imo-da03.mx.aol.com (mail_out_v42.5.) id l.ca3.5cd1649d (45490); Fri, 2 Oct 2009 14:06:26 -0400 (EDT) Received: from palantir-2.local ([10.181.87.216]) by cia-mc07.mx.aol.com (v125.7) with ESMTP id MAILCIAMC075-b1b24ac64120191; Fri, 02 Oct 2009 14:06:24 -0400 Message-ID: <4AC64120.60106@aol.com> Date: Fri, 02 Oct 2009 14:06:24 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC6274F.4090505@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2699@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC638D0.20401@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF26A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.87.216 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 18:05:22 -0000 Eran Hammer-Lahav wrote: > I can live with something like that. The problem will be that it will require normalizing the request URI to remove the OAuth parameter before validating the signature. But this is completely on the server so I don't mind it. > > I'll include something like this in the upcoming revision (pending more feedback). > > As for sending form-encoded auth parameters, no one has argued to keep that so I think it is save to drop it completely. > > I actually had a use case for this (as an idea) but it didn't go anywhere. Basically it was leveraging the signing mechanism as a binding for SAML messages. Logically it would be similar to SAML Simple Sign but for server-to-server calls. However, if we add the body-hash support then I think that covers POST'd content and it can be in any format. Thanks, George > EHL > > > > >> -----Original Message----- >> From: George Fletcher [mailto:gffletch@aol.com] >> Sent: Friday, October 02, 2009 10:31 AM >> To: oauth@ietf.org >> Cc: Eran Hammer-Lahav >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >> >> This is possible but it gets complicated. If server A (the one issuing >> the long encrypted opaque token) is separate (meaning not from the same >> company) from server B (the server receiving and validating the token) >> then both server A and Server B have to agree on the format of the >> token >> and the mechanism for "encrypting" or "signing" it. >> >> Since OAuth provides a way to secure requests via signing, this becomes >> a very easy way to support servers A and B being from multiple >> companies >> (or whatever). For sure, the partners could agree to take the string >> that would be the value of the Authorization header, base64 it and add >> it to the URL. >> >> Maybe this could be the simplifying mechanism for adding OAuth to URLs. >> Just define an oauth_authz parameter that is optional and contains the >> base64 encoded version of the Authorization header. Simple to process >> and easy to implement. >> >> Thanks, >> George >> >> Eran Hammer-Lahav wrote: >> >>> Actually, I am going to take this back. >>> >>> This is not really a valid reason to support authentication >>> >> parameters in the query. In this scenario, the resource owner is able >> to make an authenticated request using the auth headers. That request >> produces a special URI which can be shared, bypassing the access >> controls. Why does this needs to be covered by OAuth? What prevents any >> server from issuing a time-limited/restricted/single-use/etc URI using >> long token such as: >> >>> >> http://example.com/resource/share/1k2j3h1oi823h123hk1j23ho182h31j2h3o18 >> 2h3o12hi3o182h3o182h3 >> >>> I just don't see any reason why this is lesser than producing a URI >>> >> that uses OAuth parameters. Whatever the server needs can be either >> encoded into this long token or maintained in a database. >> >>> So back to no real use case for query parameters support. >>> >>> EHL >>> >>> >>> >>>> -----Original Message----- >>>> From: George Fletcher [mailto:gffletch@aol.com] >>>> Sent: Friday, October 02, 2009 9:16 AM >>>> To: oauth@ietf.org >>>> Cc: Eran Hammer-Lahav >>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >>>> >>>> I would expect that in the Amazon case being able to reuse the URL >>>> would >>>> be beneficial, but I'm not really familiar with that use case. >>>> >>>> For the SSO use cases, the desire is to prevent replay and make the >>>> >> URL >> >>>> one time use only. We do set cookies during the redirect process so >>>> >> a >> >>>> cache replaying those cookies could be problematic. There are a >>>> >> number >> >>>> of cache control directives that can be used for correctly >>>> >> implemented >> >>>> proxies. >>>> >>>> A couple reasonable links on the topic >>>> >>>> [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html >>>> [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=-1 >>>> [3] http://code.google.com/speed/page-speed/docs/caching.html >>>> >>>> However, I think this issue is bigger than just requests with URL >>>> parameters. If I access a rest resource >>>> http://photos.example.com/alice/album/vacation along with it's >>>> Authorization header, if this request goes through a proxy, the >>>> >> proxy >> >>>> will mostly likely ignore the Authorization header. Hence the next >>>> >> time >> >>>> that static URL is requested, the contents is returned. The same >>>> >> cache >> >>>> control headers the server needs to send for these specific use >>>> >> cases >> >>>> will apply to the general case as well. I'm a little behind in the >>>> lists >>>> servs. Has this issue already been solved for the general case using >>>> the >>>> Authorization header? >>>> >>>> Thanks, >>>> George >>>> >>>> >>>> >>>> Eran Hammer-Lahav wrote: >>>> >>>> >>>>> Thanks James, George. >>>>> >>>>> If we are going to support sending authentication credentials in >>>>> >> the >> >>>> URI query, what are the requirements to make sure it works well with >>>> proxies and caches? What headers do we need to require the server to >>>> return to make sure it doesn't get cached? Do we need to require a >>>> nonce value for all signature methods to ensure making the request >>>> >> more >> >>>> unique and less likely to repeat? >>>> >>>> >>>>> In these two use cases, is there a reason for the URI to be used >>>>> >> more >> >>>> than once? Can we simplify the credentials passed via the URI query >>>> >> to >> >>>> provide adequate security but without the need for a long and ugly >>>> >> URI >> >>>> with multiple oauth_ prefixed parameters? >>>> >>>> >>>> >>>>> These are valid use cases and something we need to worry about to >>>>> >> get >> >>>> this new protocol deployed where other proprietary ones are >>>> >> deployed. >> >>>> But I am not that concerned about the use case mentioned earlier of >>>> 'just making it easier to send requests'. So if we support query >>>> parameters but after some processing of the parameters to make the >>>> >> URI >> >>>> simpler, that would be acceptable to me. >>>> >>>> >>>>> EHL >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: George Fletcher [mailto:gffletch@aol.com] >>>>>> Sent: Friday, October 02, 2009 5:04 AM >>>>>> To: oauth@ietf.org >>>>>> Cc: Eran Hammer-Lahav; Brian Eaton >>>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >>>>>> >>>>>> In addition to the use case James described, we use this to enable >>>>>> single sign on from a client/desktop app into a browser session. >>>>>> >> The >> >>>>>> client signs the URL and then opens the browser with that URL. The >>>>>> backend validates the signature and access token and then >>>>>> >>>>>> >>>> establishes >>>> >>>> >>>>>> an >>>>>> authentication session for the user. >>>>>> >>>>>> A variant of this case is where a partner uses a back-channel >>>>>> federation >>>>>> call to authenticate their user to the AOL authentication service. >>>>>> >> A >> >>>>>> successful response includes an access token and secret (the >>>>>> >>>>>> >>>> equivalent >>>> >>>> >>>>>> of) which the partner can then user to sign an URL when their user >>>>>> invokes an AOL service (again providing SSO). >>>>>> >>>>>> Thanks, >>>>>> George >>>>>> >>>>>> P.S. Documentation on this signed API call can be found here: >>>>>> http://dev.aol.com/authentication_for_clients#client2web >>>>>> >>>>>> P.P.S. While these APIs are not OAuth specifically, the patterns >>>>>> >> are >> >>>>>> needed for OAuth compliant APIs to be developed >>>>>> >>>>>> Eran Hammer-Lahav wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Can you describe the actual use case? >>>>>>> >>>>>>> EHL >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> Behalf >>>>>> >>>>>> >>>>>> >>>>>>>> Of Brian Eaton >>>>>>>> Sent: Thursday, October 01, 2009 9:01 PM >>>>>>>> To: George Fletcher >>>>>>>> Cc: oauth@ietf.org >>>>>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >>>>>>>> >>>>>>>> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher >>>>>>>> >> >> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> One use case (I think I saw it mentioned somewhere else on the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> list) >>>>>> >>>>>> >>>>>> >>>>>>>> where >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> we've used the URI parameters is when we want the server to >>>>>>>>> >> sign >> >>>> a >>>> >>>> >>>>>>>> URL and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> then pass that signed value to the browser to load. This can be >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> done >>>>>> >>>>>> >>>>>> >>>>>>>> with a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> simple 302 and the signed URL. Switching to just supporting the >>>>>>>>> Authorization header will make this more difficult but probably >>>>>>>>> >>>>>>>>> >>>> not >>>> >>>> >>>>>>>>> impossible. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Yep. I've seen that done multiple places. >>>>>>>> >>>>>>>> One more unexpected use of 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 >>>>> >>>>> >>>>> >>>>> >>> > > From onyxraven@gmail.com Fri Oct 2 11:11:38 2009 Return-Path: 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 445B728C12F for ; Fri, 2 Oct 2009 11:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Pbj9joG57I1R for ; Fri, 2 Oct 2009 11:11:37 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id CA3483A6998 for ; Fri, 2 Oct 2009 11:11:36 -0700 (PDT) Received: by ywh13 with SMTP id 13so1029957ywh.31 for ; Fri, 02 Oct 2009 11:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bVtgnjqmVguDvnI55DsDIAgQCeYZsrh8aq1GhGxNZfo=; b=KpHMqlsmH+9C4kdy/pMA4gmLU853VrmxC9UN76z0poFTBG1pD6LCFiv4D388kp1GaD 0tT975vTrUd4rtpyTq5aZZLU7BKmkAXPrMYE/433BnCz39PckvvXpxx7AB0zqKJxA5ok 2eyUWxGN2XLqWSwTo2D2cKYXt1jZ3YhojH4ak= 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=RYEZBSnxXDp1Z4v5EI6qybkVDSgVeADOgDO/TpLyq/8FZ2pc5XtXLn1F0Aria9wenR 0jTtqileRe7n1yIIwZ5wLrnJXJxF0g/pGSXjzt7ggsnI/QvM3PR4Ua+6jOZnOnoaO5V1 2pPMdiVDHMADc14gY0VojEAq6/pxfeUhKnzLU= MIME-Version: 1.0 Received: by 10.150.130.31 with SMTP id c31mr4830536ybd.278.1254507179859; Fri, 02 Oct 2009 11:12:59 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2696@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF25B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2696@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 2 Oct 2009 12:12:59 -0600 Message-ID: From: Justin Hart To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd33080d2de400474f7b624 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 18:11:38 -0000 --000e0cd33080d2de400474f7b624 Content-Type: text/plain; charset=ISO-8859-1 In the discovery-sense, could realm define the URL to the discovery document, which would then define the complex validity-realm information as well as all the appropriate endpoints, etc? Seems like building that in could help solve any 'magic' url in the discovery phase. Seems like a reasonable use of the parameter. On Fri, Oct 2, 2009 at 11:12 AM, Eran Hammer-Lahav wrote: > In the case of Basic, it is very useful for UI optimization and I think > that can translate to OAuth as well. The browser knows it already asked the > user for credentials for a given realm and can simply reuse them without > having to ask for it again. However, the browsers today look for other bits > of information to make sure an evil domain doesn't pretend to have the realm > of a good domain, etc. > > Also, I think I skipped your comment about why we need a new scheme name > (to replace 'OAuth'). I don't want to use the oauth_version parameter but > still need a super simple way for clients to figure out that this is another > version. It also means that old clients will not try to do something stupid > with the wrong OAuth challenge because they don't look at the version. > > The version parameter was poorly defined and does not provide enough > clarity to reuse the same scheme name. > > EHL > > > -----Original Message----- > > From: Brian Eaton [mailto:beaton@google.com] > > Sent: Friday, October 02, 2009 9:39 AM > > To: Eran Hammer-Lahav > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token > > > > On Thu, Oct 1, 2009 at 6:31 PM, Eran Hammer-Lahav > > wrote: > > >> Should probably drop "realm" unless we can define the semantics. (I > > >> can't.) > > > > > > I think 2617 defines realm pretty well. It is a URI string that > > identifies the > > > set of resources accessible with a given credential. If you feel we > > need to > > > spell out the lessons (restrictions) learned from Basic, we can look > > into that. > > > > Except that the mapping from "URI string" to "set of resources" bit > > doesn't actually work in practice. The mappings either tend to be > > trivial (in which case realm is unnecessary) or complex (in which case > > realm doesn't have a syntax rich enough to describe the problem.) > > > > I can't prove that realm is useless, but I'm pretty sure that if you > > give me a dozen examples of possible semantics for "realm" I can break > > all of them. =) > > > > >> I think that the ABNF should probably just be the prefix, followed > > by > > >> name-value pairs. I don't see a reason to have a separate sub- > > scheme. > > > > > > Why define a parameter when it is clearly a sub-scheme? I makes > > client much > > > simpler by being able to look for the first two words in the header > > and known what is going on. > > > Otherwise we need to define a certain order for parameters which is > > ugly. > > > > Or we can have clients that know to look at the "Token" scheme and > > then parse the rest of the header as name/value pairs. There is no > > need to define parameter ordering. > > > > >> WWW-Authenticate: Token > > > > > > That's crazy talk. > > > > OK. =) > > > > >> That said, RSA might only get used when requesting access tokens, > > not > > >> when using them. There is no RSA private key associated with an > > >> access token, so it's kind of hard to use it. =) > > > > > > Then we need to define how it works in the context of authentication. > > Keep in mind that this is > > > ONLY for accessing protected resources once a token has been > > obtained. We will deal > > > with obtaining tokens separately and there we can include PK support > > as part of the > > > client credentials package. > > > > OK, that makes sense. > > > > Cheers, > > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd33080d2de400474f7b624 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the discovery-sense, could realm define the URL to the discovery documen= t, which would then define the complex validity-realm information as well a= s all the appropriate endpoints, etc?=A0 Seems like building that in could = help solve any 'magic' url in the discovery phase.=A0 Seems like a = reasonable use of the parameter.

On Fri, Oct 2, 2009 at 11:12 AM, Eran Hammer= -Lahav <eran@hu= eniverse.com> wrote:
In the case of Basic, it is very useful for UI optimization and I think tha= t can translate to OAuth as well. The browser knows it already asked the us= er for credentials for a given realm and can simply reuse them without havi= ng to ask for it again. However, the browsers today look for other bits of = information to make sure an evil domain doesn't pretend to have the rea= lm of a good domain, etc.

Also, I think I skipped your comment about why we need a new scheme name (t= o replace 'OAuth'). I don't want to use the oauth_version param= eter but still need a super simple way for clients to figure out that this = is another version. It also means that old clients will not try to do somet= hing stupid with the wrong OAuth challenge because they don't look at t= he version.

The version parameter was poorly defined and does not provide enough clarit= y to reuse the same scheme name.

EHL

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@= google.com]
> Sent: Friday, October 02, 2009 9:39 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token
>
> On Thu, Oct 1, 2009 at 6:31 PM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> >> Should probably drop "realm" unless we can define t= he semantics. =A0(I
> >> can't.)
> >
> > I think 2617 defines realm pretty well. It is a URI string that > identifies the
> > set of resources accessible with a given credential. If you feel = we
> need to
> > spell out the lessons (restrictions) learned from Basic, we can l= ook
> into that.
>
> Except that the mapping from "URI string" to "set of re= sources" bit
> doesn't actually work in practice. =A0The mappings either tend to = be
> trivial (in which case realm is unnecessary) or complex (in which case=
> realm doesn't have a syntax rich enough to describe the problem.)<= br> >
> I can't prove that realm is useless, but I'm pretty sure that = if you
> give me a dozen examples of possible semantics for "realm" I= can break
> all of them. =3D)
>
> >> I think that the ABNF should probably just be the prefix, fol= lowed
> by
> >> name-value pairs. =A0I don't see a reason to have a separ= ate sub-
> scheme.
> >
> > Why define a parameter when it is clearly a sub-scheme? I makes > client much
> > simpler by being able to look for the first two words in the head= er
> and known what is going on.
> > Otherwise we need to define a certain order for parameters which = is
> ugly.
>
> Or we can have clients that know to look at the "Token" sche= me and
> then parse the rest of the header as name/value pairs. =A0There is no<= br> > need to define parameter ordering.
>
> >> WWW-Authenticate: Token <json>
> >
> > That's crazy talk.
>
> OK. =3D)
>
> >> That said, RSA might only get used when requesting access tok= ens,
> not
> >> when using them. =A0There is no RSA private key associated wi= th an
> >> access token, so it's kind of hard to use it. =3D)
> >
> > Then we need to define how it works in the context of authenticat= ion.
> Keep in mind that this is
> > ONLY for accessing protected resources once a token has been
> obtained. We will deal
> > with obtaining tokens separately and there we can include PK supp= ort
> as part of the
> > client credentials package.
>
> OK, that makes sense.
>
> Cheers,
> Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--000e0cd33080d2de400474f7b624-- From eran@hueniverse.com Fri Oct 2 11:24:39 2009 Return-Path: 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 331E528C0E4 for ; Fri, 2 Oct 2009 11:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599] 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 szYGw98KAUdc for ; Fri, 2 Oct 2009 11:24:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9B5713A6970 for ; Fri, 2 Oct 2009 11:24:37 -0700 (PDT) Received: (qmail 15550 invoked from network); 2 Oct 2009 18:26:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 18:26:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 2 Oct 2009 11:26:03 -0700 From: Eran Hammer-Lahav To: George Fletcher , "oauth@ietf.org" Date: Fri, 2 Oct 2009 11:26:19 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpDixxb6e4gc6DzQ22BnO+60txmNgAAq+lQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF26BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC56AE2.1030302@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF25BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC5EC1E.4010804@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2636@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC6274F.4090505@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2699@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC638D0.20401@aol.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26A2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC64120.60106@aol.com> In-Reply-To: <4AC64120.60106@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 18:24:39 -0000 The key here the transmission of auth parameters, not singing bodies. EHL > -----Original Message----- > From: George Fletcher [mailto:gffletch@aol.com] > Sent: Friday, October 02, 2009 11:06 AM > To: oauth@ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >=20 > Eran Hammer-Lahav wrote: > > I can live with something like that. The problem will be that it will > require normalizing the request URI to remove the OAuth parameter > before validating the signature. But this is completely on the server > so I don't mind it. > > > > I'll include something like this in the upcoming revision (pending > more feedback). > > > > As for sending form-encoded auth parameters, no one has argued to > keep that so I think it is save to drop it completely. > > > > > I actually had a use case for this (as an idea) but it didn't go > anywhere. Basically it was leveraging the signing mechanism as a > binding > for SAML messages. Logically it would be similar to SAML Simple Sign > but > for server-to-server calls. >=20 > However, if we add the body-hash support then I think that covers > POST'd > content and it can be in any format. >=20 > Thanks, > George > > EHL > > > > > > > > > >> -----Original Message----- > >> From: George Fletcher [mailto:gffletch@aol.com] > >> Sent: Friday, October 02, 2009 10:31 AM > >> To: oauth@ietf.org > >> Cc: Eran Hammer-Lahav > >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >> > >> This is possible but it gets complicated. If server A (the one > issuing > >> the long encrypted opaque token) is separate (meaning not from the > same > >> company) from server B (the server receiving and validating the > token) > >> then both server A and Server B have to agree on the format of the > >> token > >> and the mechanism for "encrypting" or "signing" it. > >> > >> Since OAuth provides a way to secure requests via signing, this > becomes > >> a very easy way to support servers A and B being from multiple > >> companies > >> (or whatever). For sure, the partners could agree to take the string > >> that would be the value of the Authorization header, base64 it and > add > >> it to the URL. > >> > >> Maybe this could be the simplifying mechanism for adding OAuth to > URLs. > >> Just define an oauth_authz parameter that is optional and contains > the > >> base64 encoded version of the Authorization header. Simple to > process > >> and easy to implement. > >> > >> Thanks, > >> George > >> > >> Eran Hammer-Lahav wrote: > >> > >>> Actually, I am going to take this back. > >>> > >>> This is not really a valid reason to support authentication > >>> > >> parameters in the query. In this scenario, the resource owner is > able > >> to make an authenticated request using the auth headers. That > request > >> produces a special URI which can be shared, bypassing the access > >> controls. Why does this needs to be covered by OAuth? What prevents > any > >> server from issuing a time-limited/restricted/single-use/etc URI > using > >> long token such as: > >> > >>> > >> > http://example.com/resource/share/1k2j3h1oi823h123hk1j23ho182h31j2h3o18 > >> 2h3o12hi3o182h3o182h3 > >> > >>> I just don't see any reason why this is lesser than producing a URI > >>> > >> that uses OAuth parameters. Whatever the server needs can be either > >> encoded into this long token or maintained in a database. > >> > >>> So back to no real use case for query parameters support. > >>> > >>> EHL > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: George Fletcher [mailto:gffletch@aol.com] > >>>> Sent: Friday, October 02, 2009 9:16 AM > >>>> To: oauth@ietf.org > >>>> Cc: Eran Hammer-Lahav > >>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>> > >>>> I would expect that in the Amazon case being able to reuse the URL > >>>> would > >>>> be beneficial, but I'm not really familiar with that use case. > >>>> > >>>> For the SSO use cases, the desire is to prevent replay and make > the > >>>> > >> URL > >> > >>>> one time use only. We do set cookies during the redirect process > so > >>>> > >> a > >> > >>>> cache replaying those cookies could be problematic. There are a > >>>> > >> number > >> > >>>> of cache control directives that can be used for correctly > >>>> > >> implemented > >> > >>>> proxies. > >>>> > >>>> A couple reasonable links on the topic > >>>> > >>>> [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html > >>>> [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=3D-1 > >>>> [3] http://code.google.com/speed/page-speed/docs/caching.html > >>>> > >>>> However, I think this issue is bigger than just requests with URL > >>>> parameters. If I access a rest resource > >>>> http://photos.example.com/alice/album/vacation along with it's > >>>> Authorization header, if this request goes through a proxy, the > >>>> > >> proxy > >> > >>>> will mostly likely ignore the Authorization header. Hence the next > >>>> > >> time > >> > >>>> that static URL is requested, the contents is returned. The same > >>>> > >> cache > >> > >>>> control headers the server needs to send for these specific use > >>>> > >> cases > >> > >>>> will apply to the general case as well. I'm a little behind in the > >>>> lists > >>>> servs. Has this issue already been solved for the general case > using > >>>> the > >>>> Authorization header? > >>>> > >>>> Thanks, > >>>> George > >>>> > >>>> > >>>> > >>>> Eran Hammer-Lahav wrote: > >>>> > >>>> > >>>>> Thanks James, George. > >>>>> > >>>>> If we are going to support sending authentication credentials in > >>>>> > >> the > >> > >>>> URI query, what are the requirements to make sure it works well > with > >>>> proxies and caches? What headers do we need to require the server > to > >>>> return to make sure it doesn't get cached? Do we need to require a > >>>> nonce value for all signature methods to ensure making the request > >>>> > >> more > >> > >>>> unique and less likely to repeat? > >>>> > >>>> > >>>>> In these two use cases, is there a reason for the URI to be used > >>>>> > >> more > >> > >>>> than once? Can we simplify the credentials passed via the URI > query > >>>> > >> to > >> > >>>> provide adequate security but without the need for a long and ugly > >>>> > >> URI > >> > >>>> with multiple oauth_ prefixed parameters? > >>>> > >>>> > >>>> > >>>>> These are valid use cases and something we need to worry about to > >>>>> > >> get > >> > >>>> this new protocol deployed where other proprietary ones are > >>>> > >> deployed. > >> > >>>> But I am not that concerned about the use case mentioned earlier > of > >>>> 'just making it easier to send requests'. So if we support query > >>>> parameters but after some processing of the parameters to make the > >>>> > >> URI > >> > >>>> simpler, that would be acceptable to me. > >>>> > >>>> > >>>>> EHL > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: George Fletcher [mailto:gffletch@aol.com] > >>>>>> Sent: Friday, October 02, 2009 5:04 AM > >>>>>> To: oauth@ietf.org > >>>>>> Cc: Eran Hammer-Lahav; Brian Eaton > >>>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>>>> > >>>>>> In addition to the use case James described, we use this to > enable > >>>>>> single sign on from a client/desktop app into a browser session. > >>>>>> > >> The > >> > >>>>>> client signs the URL and then opens the browser with that URL. > The > >>>>>> backend validates the signature and access token and then > >>>>>> > >>>>>> > >>>> establishes > >>>> > >>>> > >>>>>> an > >>>>>> authentication session for the user. > >>>>>> > >>>>>> A variant of this case is where a partner uses a back-channel > >>>>>> federation > >>>>>> call to authenticate their user to the AOL authentication > service. > >>>>>> > >> A > >> > >>>>>> successful response includes an access token and secret (the > >>>>>> > >>>>>> > >>>> equivalent > >>>> > >>>> > >>>>>> of) which the partner can then user to sign an URL when their > user > >>>>>> invokes an AOL service (again providing SSO). > >>>>>> > >>>>>> Thanks, > >>>>>> George > >>>>>> > >>>>>> P.S. Documentation on this signed API call can be found here: > >>>>>> http://dev.aol.com/authentication_for_clients#client2web > >>>>>> > >>>>>> P.P.S. While these APIs are not OAuth specifically, the patterns > >>>>>> > >> are > >> > >>>>>> needed for OAuth compliant APIs to be developed > >>>>>> > >>>>>> Eran Hammer-Lahav wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Can you describe the actual use case? > >>>>>>> > >>>>>>> EHL > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > On > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> Behalf > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> Of Brian Eaton > >>>>>>>> Sent: Thursday, October 01, 2009 9:01 PM > >>>>>>>> To: George Fletcher > >>>>>>>> Cc: oauth@ietf.org > >>>>>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>>>>>> > >>>>>>>> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher > >>>>>>>> > >> > >> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> One use case (I think I saw it mentioned somewhere else on > the > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> list) > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> where > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> we've used the URI parameters is when we want the server to > >>>>>>>>> > >> sign > >> > >>>> a > >>>> > >>>> > >>>>>>>> URL and > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> then pass that signed value to the browser to load. This can > be > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> done > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> with a > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> simple 302 and the signed URL. Switching to just supporting > the > >>>>>>>>> Authorization header will make this more difficult but > probably > >>>>>>>>> > >>>>>>>>> > >>>> not > >>>> > >>>> > >>>>>>>>> impossible. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Yep. I've seen that done multiple places. > >>>>>>>> > >>>>>>>> One more unexpected use of 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>> > > > > From beaton@google.com Fri Oct 2 12:01:48 2009 Return-Path: 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 AD0993A6A47 for ; Fri, 2 Oct 2009 12:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FGGPsak48Do8 for ; Fri, 2 Oct 2009 12:01:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 12E7B3A69C2 for ; Fri, 2 Oct 2009 12:01:44 -0700 (PDT) Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id n92J3CWN016636 for ; Fri, 2 Oct 2009 12:03:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254510192; bh=TH6lnAHscTsr/pmY9wVbw5uInKk=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=E7gnLSyyPP378wPMlr mNlLuWuZusWbLhgEuQ5Gx37nRom2CsNfuvZfd961C1vb3O4PLbmmjk7tU8SGCLmW/ru Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=DffjI/GHWaBVJbK9iNWvErcSXBCiyELA3U0DDHTyf41e44Tv//DcLEJ29wApZ32aU 3R4cVSFia4acMN2hM54qA== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by zps35.corp.google.com with ESMTP id n92J2d6g025852 for ; Fri, 2 Oct 2009 12:03:10 -0700 Received: by pzk28 with SMTP id 28so3555826pzk.30 for ; Fri, 02 Oct 2009 12:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.26.40 with SMTP id d40mr380786wfj.232.1254510189679; Fri, 02 Oct 2009 12:03:09 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF25B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2696@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 2 Oct 2009 12:03:09 -0700 Message-ID: From: Brian Eaton To: Justin Hart Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:01:48 -0000 On Fri, Oct 2, 2009 at 11:12 AM, Justin Hart wrote: > In the discovery-sense, could realm define the URL to the discovery > document, which would then define the complex validity-realm information = as > well as all the appropriate endpoints, etc?=A0 Seems like building that i= n > could help solve any 'magic' url in the discovery phase.=A0 Seems like a > reasonable use of the parameter. That approach caused a fundamental security hole in the first OAuth discovery spec, where an evil resource could steal credentials from a good credential issuer. I'm not saying it's not a solvable problem, but it is complicated, and I just haven't seen a whole lot of use cases for a generic solution. (As an example of how completely useless current working definitions of "realm" really are, check out http://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication.) Cheers, Brian From eran@hueniverse.com Fri Oct 2 12:14:40 2009 Return-Path: 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 764763A6972 for ; Fri, 2 Oct 2009 12:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599] 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 p+cRXuki-rhx for ; Fri, 2 Oct 2009 12:14:36 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 92A3A3A6842 for ; Fri, 2 Oct 2009 12:14:36 -0700 (PDT) Received: (qmail 31095 invoked from network); 2 Oct 2009 19:16:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 19:16:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 2 Oct 2009 12:13:16 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Fri, 2 Oct 2009 12:16:02 -0700 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpC8Sw2Ny1WupCSSWSDuMgrgFIZNwABvj2gACbMNyA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:14:40 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBN YW5nZXIsIEphbWVzIEgNCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDEsIDIwMDkgNjozMSBQ TQ0KDQo+IEkgdGhpbmsgT0F1dGggbmVlZHM6DQo+IA0KPiAxLiBBIFdXVy1BdXRoIHNjaGVtZSBp bmRpY2F0aW5nIHRoYXQgcmVxdWVzdHMgY2FuIGJlIHNpZ25lZCB3aXRoIGENCj4gc2hhcmVkLXNl Y3JldCBrZXkuDQoNClRoaXMgaXMgdG9vIHNwZWNpZmljLiBXZSBuZWVkIGEgc2NoZW1lIHRoYXQg aW5kaWNhdGUgcmVxdWVzdHMgY2FuIGJlIG1hZGUgd2l0aCBhIHRva2VuICh2cy4gdXNlcm5hbWUp Lg0KDQo+IDIuIEEgV1dXLUF1dGggc2NoZW1lIGluZGljYXRpbmcgdGhhdCBhIHdlYiBkZWxlZ2F0 aW9uIGZsb3cgY2FuIGJlIHVzZWQNCj4gdG8gZ2V0IHVzZXIgYXV0aG9yaXphdGlvbi4NCg0KSSBh bSBub3Qgc3VyZSB0aGlzIGlzIHRoZSByaWdodCB3YXkgdG8gcHJvdmlkZSBkZWxlZ2F0aW9uIGRp c2NvdmVyeSAodmlhIHRoZSBhdXRoIGhlYWRlcikuIFVzaW5nIExpbms6IGhlYWRlcnMgaXMgbXVj aCBtb3JlIGFwcHJvcHJpYXRlLg0KIA0KPiBUaGUgdHdvIGFyZSBxdWl0ZSBzZXBhcmF0ZS4NCj4g VGhlIGZpcnN0IHdvdWxkIGJlIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1hdXRoZW50aWNh dGlvbiBhbmQgd291bGQNCj4gbWFrZSBubyByZWZlcmVuY2UgdG8gZGVsZWdhdGlvbiBhdCBhbGwu ICJNQUMiIHdvdWxkIGJlIGEgZ29vZCBuYW1lLg0KPiANCj4gPC0gIFdXVy1BdXRoZW50aWNhdGU6 IE1BQyByZWFsbT0id2hhdGV2ZXIiOyBhbGdvcml0aG09IkhNQUMtU0hBMSBITUFDLQ0KPiBTSEEy NTYgQ01BQy1BRVMiOw0KPiAgICAgICAgICAgICAgICAgICAgICBtb2RlPSJIRUFERVIgVVJJIFBP U1QiIDxwZXJoYXBzIHNvbWUgbW9yZQ0KPiBwYXJhbWV0ZXJzPg0KPiANCj4gLT4gIEF1dGhvcml6 YXRpb246IE1BQyByZWFsbT0id2hhdGV2ZXIiOyBhbGdvcml0aG09IkhNQUMtU0hBMjU2IjsNCj4g c2lnPSI2NWRGTeKApiI7IG5vbmNl4oCmDQoNClRoZSBzeW50YXggZGlmZmVyZW5jZXMgZnJvbSBt eSBwcm9wb3NhbCBhcmVuJ3Qgc2lnbmlmaWNhbnQuIEkgdGhpbmsgdGhlcmUgaXMgdmFsdWUgaW4g Y3JlYXRpbmcgYSBmYW1pbHkgb2YgYXV0aGVudGljYXRpb24gbWV0aG9kcyB1c2luZyBhIHNjaGVt ZSBhbmQgc3ViLXNjaGVtZS4gSXQgaXMgYmV0dGVyIHRvIHN1cHBvcnQgZXh0ZW5zaWJpbGl0eSBp biB0aGUgc2NoZW1lIHRoYW4gdG8gZm9yY2UgbmV3IG1ldGhvZHMgdG8gZGVmaW5lIG5ldyBzY2hl bWVzLiBUaGlzIHdpbGwgYWxsb3cgZWFzaWVyIGltcGxlbWVudGF0aW9uIG9mIG5ldyBzdWItc2No ZW1lcy4NCiANCj4gVGhlIG9wdGlvbiB0byBlbmNvZGUgdGhlIHNpZ25hdHVyZSBpbiBhIFVSSSBp cyB3b3J0aHdoaWxlIChlZyBhIGNsaWVudA0KPiBjYW4gc2lnbiBhIFVSSSB0aGVuIGdpdmUgaXQg dG8gYW5vdGhlciBwYXJ0eSB0byBhY2Nlc3MsIGVnIGFub3RoZXINCj4gcGFydHkgdG8gY2xpY2sg aW4gYSBicm93c2VyKS4gSGVuY2UsIHRoZSAibW9kZSIgcGFyYW1ldGVyIGFib3ZlLiBJIGFtDQo+ IGxlc3MgY29udmluY2VkIGJ5IFBPU1QsIGJ1dCBpdCBpcyBhIHNtYWxsIHN0ZXAgZnJvbSBVUkkg dG8gUE9TVCBzbyBpdA0KPiBpcyBwcm9iYWJseSB3b3J0aCBoYXZpbmcuDQo+IFtIRUFERVIgPSBj YW4gcHV0IHNpZ25hdHVyZSBpbiBIVFRQIEF1dGhvcml6YXRpb24gcmVxdWVzdCBoZWFkZXI7DQo+ ICBVUkkgPSBjYW4gcHV0IHNpZ25hdHVyZSBpbiBVUkkgcXVlcnkgc3RyaW5nOw0KPiAgUE9TVCA9 IGNhbiBwdXQgc2lnbmF0dXJlIGluIEhUTUwgPGZvcm0+IFBPU1RdDQoNCkhlYWRlciBzZXJ2ZXIg c3VwcG9ydCBzaG91bGQgbm90IGJlIG9wdGlvbmFsIGFuZCBoZW5jZSBkb2VzIG5vdCBuZWVkIGRp c2NvdmVyeS4NCg0KSXMgaXQgdG9vIG11Y2ggdG8gYXNrIGFsbCBzZXJ2ZXJzIHRvIHN1cHBvcnQg dGhlIFVSSSBtb2RlPyBXZSBhcmUgZ29pbmcgdG8gbWFrZSBzdXBwb3J0aW5nIHRoZSBhdXRoIGhl YWRlcnMgbWFuZGF0b3J5IGluIGFsbCBpbXBsZW1lbnRhdGlvbnMuIFNpbmNlIHdlIGFyZSBkcm9w cGluZyBQT1NUIChubyB1c2UgY2FzZXMsIG5vIG1hdHRlciBob3cgc2ltcGxlIGl0IGlzIHRvIGtl ZXApIGFuZCBoZWFkZXJzIGFyZSByZXF1aXJlZCwgd2h5IG5vdCByZXF1aXJlIHN1cHBvcnQgZm9y IGEgc2luZ2xlIFVSSSBoZWFkZXIgcGFyYW1ldGVyPw0KIA0KPiA+CVdXVy1BdXRoZW50aWNhdGU6 IFRva2VuIFBsYWluIHJlYWxtPSIiDQo+ID4JQXV0aG9yaXphdGlvbjogVG9rZW4gUGxhaW4gPHRv a2VuPiA8c2VjcmV0Pg0KPiANCj4gVGhpcyBpc24ndCBuZWNlc3NhcnkuIEp1c3QgdXNlIEJBU0lD Lg0KPiBBIHNlcnZlciBtYXkgbmVlZCB0byBlbnN1cmUgdXNlcm5hbWVzIGFuZCB0b2tlbnMgY2Fu IGJlIGRpc3Rpbmd1aXNoZWQsDQo+IGJ1dCB0aGF0IGlzIGVhc3kgZW5vdWdoLg0KDQpZZXMgaXQg aXMuIFRoZSBpZGVhIG9mIHJlcXVpcmluZyBzZXJ2ZXJzIHRvIG1ha2UgdGhpcyBkaXN0aW5jdGlv biBpcyBpbXByYWN0aWNhbC4gQmFzaWMgYXV0aCBpcyB3ZWxsIGRlZmluZWQgYW5kIGFueSBhdHRl bXB0IHRvIG92ZXJsb2FkIGl0IHdpdGggbmV3IG1lYW5pbmcgaXMgd3JvbmcuDQogDQo+IElmIGFu IFJTQS1iYXNlZCBtZWNoYW5pc20gaXMgcmVxdWlyZWQgYSBzZXBhcmF0ZSBXV1ctQXV0aCBzY2hl bWUgd291bGQNCj4gYmUgdGhlIGJlc3QgYXBwcm9hY2guDQoNCkl0IGlzIG5vdCBjbGVhciB3aGF0 IHRoZSBSU0EgcmVxdWlyZW1lbnRzIGFyZSBhbmQgaG93IHRoZXkgc2hvdWxkIGJlIG1hbmFnZWQg eWV0LiBJdCBzaG91bGQgYmUgYSBzdWItc2NoZW1lLg0KIA0KRUhMDQo= From eran@hueniverse.com Fri Oct 2 12:15:43 2009 Return-Path: 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 9E72C3A6980 for ; Fri, 2 Oct 2009 12:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, 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 i+W7yVPLF8GH for ; Fri, 2 Oct 2009 12:15:42 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EC1223A6842 for ; Fri, 2 Oct 2009 12:15:41 -0700 (PDT) Received: (qmail 32144 invoked from network); 2 Oct 2009 19:17:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 19:17:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 2 Oct 2009 12:16:55 -0700 From: Eran Hammer-Lahav To: Justin Hart Date: Fri, 2 Oct 2009 12:17:12 -0700 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpDjABeKjAeLRMcRTmzJCb+U9S1RgACMusA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF26E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF25B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2696@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343784DF26E5P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:15:43 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784DF26E5P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is no reason to overload the realm with new meanings. It is well defi= ned already in 2617. If we decide to support a discovery method using an external document (XRD,= etc.), it should be expressed using a Link header not inside the auth head= er. EHL From: Justin Hart [mailto:onyxraven@gmail.com] Sent: Friday, October 02, 2009 11:13 AM To: Eran Hammer-Lahav Cc: Brian Eaton; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token In the discovery-sense, could realm define the URL to the discovery documen= t, which would then define the complex validity-realm information as well a= s all the appropriate endpoints, etc? Seems like building that in could he= lp solve any 'magic' url in the discovery phase. Seems like a reasonable u= se of the parameter. On Fri, Oct 2, 2009 at 11:12 AM, Eran Hammer-Lahav > wrote: In the case of Basic, it is very useful for UI optimization and I think tha= t can translate to OAuth as well. The browser knows it already asked the us= er for credentials for a given realm and can simply reuse them without havi= ng to ask for it again. However, the browsers today look for other bits of = information to make sure an evil domain doesn't pretend to have the realm o= f a good domain, etc. Also, I think I skipped your comment about why we need a new scheme name (t= o replace 'OAuth'). I don't want to use the oauth_version parameter but sti= ll need a super simple way for clients to figure out that this is another v= ersion. It also means that old clients will not try to do something stupid = with the wrong OAuth challenge because they don't look at the version. The version parameter was poorly defined and does not provide enough clarit= y to reuse the same scheme name. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, October 02, 2009 9:39 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token > > On Thu, Oct 1, 2009 at 6:31 PM, Eran Hammer-Lahav > > wrote: > >> Should probably drop "realm" unless we can define the semantics. (I > >> can't.) > > > > I think 2617 defines realm pretty well. It is a URI string that > identifies the > > set of resources accessible with a given credential. If you feel we > need to > > spell out the lessons (restrictions) learned from Basic, we can look > into that. > > Except that the mapping from "URI string" to "set of resources" bit > doesn't actually work in practice. The mappings either tend to be > trivial (in which case realm is unnecessary) or complex (in which case > realm doesn't have a syntax rich enough to describe the problem.) > > I can't prove that realm is useless, but I'm pretty sure that if you > give me a dozen examples of possible semantics for "realm" I can break > all of them. =3D) > > >> I think that the ABNF should probably just be the prefix, followed > by > >> name-value pairs. I don't see a reason to have a separate sub- > scheme. > > > > Why define a parameter when it is clearly a sub-scheme? I makes > client much > > simpler by being able to look for the first two words in the header > and known what is going on. > > Otherwise we need to define a certain order for parameters which is > ugly. > > Or we can have clients that know to look at the "Token" scheme and > then parse the rest of the header as name/value pairs. There is no > need to define parameter ordering. > > >> WWW-Authenticate: Token > > > > That's crazy talk. > > OK. =3D) > > >> That said, RSA might only get used when requesting access tokens, > not > >> when using them. There is no RSA private key associated with an > >> access token, so it's kind of hard to use it. =3D) > > > > Then we need to define how it works in the context of authentication. > Keep in mind that this is > > ONLY for accessing protected resources once a token has been > obtained. We will deal > > with obtaining tokens separately and there we can include PK support > as part of the > > client credentials package. > > OK, that makes sense. > > Cheers, > Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343784DF26E5P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is no reason to overload the realm with new meanings. = It is well defined already in 2617.

 

If we decide to support a discovery method using an external document (XRD, etc.), it should be expressed using a Link header not inside= the auth header.

 

EHL

 

From: Justin Hart [mailto:onyxraven@gmail.com]
Sent: Friday, October 02, 2009 11:13 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token

 

In the discovery-sense,= could realm define the URL to the discovery document, which would then define the complex validity-realm information as well as all the appropriate endpoints= , etc?  Seems like building that in could help solve any 'magic' url in = the discovery phase.  Seems like a reasonable use of the parameter.

On Fri, Oct 2, 2009 at 11:12 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

In the case of Basic, it is very useful for UI optimiz= ation and I think that can translate to OAuth as well. The browser knows it alrea= dy asked the user for credentials for a given realm and can simply reuse them without having to ask for it again. However, the browsers today look for ot= her bits of information to make sure an evil domain doesn't pretend to have the realm of a good domain, etc.

Also, I think I skipped your comment about why we need a new scheme name (t= o replace 'OAuth'). I don't want to use the oauth_version parameter but still need a super simple way for clients to figure out that this is another vers= ion. It also means that old clients will not try to do something stupid with the wrong OAuth challenge because they don't look at the version.

The version parameter was poorly defined and does not provide enough clarit= y to reuse the same scheme name.

EHL


> -----Original Message-----
> From: Brian Eaton [mailto:beaton@= google.com]
> Sent: Friday, October 02, 2009 9:39 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token
>
> On Thu, Oct 1, 2009 at 6:31 PM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> >> Should probably drop "realm" unless we can define t= he semantics.  (I
> >> can't.)
> >
> > I think 2617 defines realm pretty well. It is a URI string that > identifies the
> > set of resources accessible with a given credential. If you feel = we
> need to
> > spell out the lessons (restrictions) learned from Basic, we can l= ook
> into that.
>
> Except that the mapping from "URI string" to "set of resources" bit
> doesn't actually work in practice.  The mappings either tend to b= e
> trivial (in which case realm is unnecessary) or complex (in which case=
> realm doesn't have a syntax rich enough to describe the problem.)
>
> I can't prove that realm is useless, but I'm pretty sure that if you > give me a dozen examples of possible semantics for "realm" I= can break
> all of them. =3D)
>
> >> I think that the ABNF should probably just be the prefix, followed
> by
> >> name-value pairs.  I don't see a reason to have a separa= te sub-
> scheme.
> >
> > Why define a parameter when it is clearly a sub-scheme? I makes > client much
> > simpler by being able to look for the first two words in the head= er
> and known what is going on.
> > Otherwise we need to define a certain order for parameters which = is
> ugly.
>
> Or we can have clients that know to look at the "Token" sche= me and
> then parse the rest of the header as name/value pairs.  There is = no
> need to define parameter ordering.
>
> >> WWW-Authenticate: Token <json>
> >
> > That's crazy talk.
>
> OK. =3D)
>
> >> That said, RSA might only get used when requesting access tok= ens,
> not
> >> when using them.  There is no RSA private key associated with an
> >> access token, so it's kind of hard to use it. =3D)
> >
> > Then we need to define how it works in the context of authenticat= ion.
> Keep in mind that this is
> > ONLY for accessing protected resources once a token has been
> obtained. We will deal
> > with obtaining tokens separately and there we can include PK supp= ort
> as part of the
> > client credentials package.
>
> OK, that makes sense.
>
> Cheers,
> Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

--_000_90C41DD21FB7C64BB94121FBBC2E72343784DF26E5P3PW5EX1MB01E_-- From eran@hueniverse.com Fri Oct 2 12:29:07 2009 Return-Path: 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 3C3BB3A6A37 for ; Fri, 2 Oct 2009 12:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599] 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 Z3VrXXsTSkAb for ; Fri, 2 Oct 2009 12:29:06 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 292C13A6972 for ; Fri, 2 Oct 2009 12:29:05 -0700 (PDT) Received: (qmail 11986 invoked from network); 2 Oct 2009 19:30:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 19:30:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 2 Oct 2009 12:28:02 -0700 From: Eran Hammer-Lahav To: Justin Richer Date: Fri, 2 Oct 2009 12:30:46 -0700 Thread-Topic: [OAUTH-WG] OAuth and HTTP caching Thread-Index: Aco+B4RiLQZBzDKKRcGk3lv1TcrSewFjviGw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF26ED@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1253900531.4748.18.camel@localhost.localdomain> In-Reply-To: <1253900531.4748.18.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:29:07 -0000 Can you give examples? Using curl it is as easy to include a header as it i= s to include a parameter. Can you give more details on the cases where all = you had was a GET request without access to headers? I am going to push back against the 'easier' arguments until I see use case= s that truly require it and are core to what we are tasked to do. EHL > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Friday, September 25, 2009 10:42 AM > To: Eran Hammer-Lahav > Cc: Ethan Jewett; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth and HTTP caching >=20 > It is significantly easier to script a client library like these using > HTTP parameters, and I have had a couple cases where all I had was a > "get" style request to work with on my client. Using URLparams I was > able to script this quite well, but if I needed to get into the > headers, > I wouldn't be able to do it. >=20 > I vote for having the auth headers be the recommended mode but for the > parameters to stay around. >=20 > -- justin >=20 > On Thu, 2009-09-24 at 14:24 -0400, Eran Hammer-Lahav wrote: > > No, we are simply sending a message to browser vendors that they > should add native support. It is one thing when a small community comes > out with a spec and a whole other thing when the IETF publishes a new > internet standard. > > > > Also, the fact that we will have the 1.0 spec published as an > information RFC will help because it will give an alternative to this > new work in cases where it is not possible to implement. > > > > EHL > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > > Of Ethan Jewett > > > Sent: Thursday, September 24, 2009 11:04 AM > > > To: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] OAuth and HTTP caching > > > > > > Thinking back ... wasn't one of the primary reasons for having a > way > > > to pass the authentication parameters that didn't involve the > headers > > > because in-browser javascript doesn't have access to the headers? > > > > > > Now, I don't think there are a lot of applications currently using > > > OAuth to authenticate an in-browser client application directly to > a > > > server, but with the advent of mechanisms for cross-domain requests > in > > > HTML5 and through hacks like iFrame proxies, this might become more > > > common. If we require authorization headers are we precluding the > use > > > of OAuth on the browser platform? > > > > > > Ethan > > > > > > On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav > > > wrote: > > > > This means that we really only have two options: > > > > > > > > 1. Use only the HTTP Authorization header to pass authentication > > > parameters from the client to the server. This means dropping > support > > > for URI query parameters and form-encoded body parameters. > > > > 2. Drop support for form-encoded parameters, recommend using HTTP > > > headers or require additional headers when using URI query > parameters. > > > > > > > > Of course, #2 defeats the purpose because the only reason to keep > URI > > > query parameters is to avoid the need to set headers... > > > > > > > > Are there any *documented* reasons why we should not just limit > OAuth > > > to transmit parameters over HTTP Authorization headers? > > > > > > > > EHL > > > > > > > >> -----Original Message----- > > > >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > > > >> Sent: Tuesday, September 22, 2009 10:48 AM > > > >> To: Eran Hammer-Lahav > > > >> Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group > > > >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching > > > >> > > > >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: > > > >> > > > >> >> -----Original Message----- > > > >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > > > >> >> Sent: Tuesday, September 22, 2009 10:09 AM > > > >> > > > > >> >> Just follow the HTTP spec. > > > >> > > > > >> > That what I am trying to figure out... > > > >> > > > > >> > Does the HTTP spec mandates that new authentication protocols > use > > > >> > the WWW-Authenticate and Authorization headers? > > > >> > > > >> HTTP is not aware of any other kinds of authentication. There > is no > > > >> reason > > > >> to specify anything else. > > > >> > > > >> > Are the headers required for existing caches and servers to > > > operate > > > >> > properly? > > > >> > > > >> Yes (and for user agents as well). Don't forget about Proxy- > Auth*. > > > >> > > > >> > If they are not included in authenticated requests, are there > > > other > > > >> > requirements to make sure it doesn't break existing > deployment? > > > >> > > > >> Cache-control: private > > > >> > > > >> is probably needed if the Auth headers are not being used but > the > > > >> response depends on something like cookies for authentication. > > > >> > > > >> ....Roy > > > > > > > > _______________________________________________ > > > > 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 From eran@hueniverse.com Fri Oct 2 12:33:48 2009 Return-Path: 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 54F323A68F5 for ; Fri, 2 Oct 2009 12:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599] 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 ErPOe2e6PFDq for ; Fri, 2 Oct 2009 12:33:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2D4E83A6972 for ; Fri, 2 Oct 2009 12:33:47 -0700 (PDT) Received: (qmail 25759 invoked from network); 2 Oct 2009 19:35:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2009 19:35:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 2 Oct 2009 12:34:53 -0700 From: Eran Hammer-Lahav To: Richard Barnes , Blaine Cook Date: Fri, 2 Oct 2009 12:35:07 -0700 Thread-Topic: [OAUTH-WG] Mandatory signature algorithms? Thread-Index: AcpBFD1w/bqrhshMR9SbiNKA/OcimQCgq0UA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF26F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC21EC4.7030608@bbn.com> In-Reply-To: <4AC21EC4.7030608@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:33:48 -0000 Either way you look at it, you are going to have some limitation. We should= not force servers to support an algorithm that they deem insecure (and the= final say will always go to the server, never the spec). This means defini= ng a default will allow the client to try (and most likely succeed) using a= well known method, and will allow the server to reject it with alternative= s. However, this approach means that the client will be sending something t= hat the server might consider harmful (exposing something about the credent= ials). Requiring making an unauthenticated request first to discover the su= pported algorithm will solve that but will add a roundtrip. So either way we are going to compromise. I think trying a default method is better than making a request for a 401 r= esponse. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Tuesday, September 29, 2009 7:51 AM > To: Blaine Cook > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Mandatory signature algorithms? >=20 > Hey Blaine, >=20 > You've got the general pattern right, but I'm not sure how well it maps > to the general use of OAuth signatures: One of the main benefits of > OAuth vs. Digest is that it can be done in a single HTTP round-trip -- > the server doesn't need to issue a challenge in order for the client to > construct the signature. That creates a problem for crypto agility > because by the same token, the server doesn't have a chance to specify > which cipher suites it supports. (Here I'm using client and server in > the HTTP sense, which I think map to your "consumer" and "service > provider" below.) >=20 > A couple of work-arounds occur to me: >=20 > 1. Allow the client to provide multiple signatures using different > cipher suites, and let the server choose which one to validate (MUST > use > only one to prevent bid-down attacks). If the client provides all the > signatures it knows how to do, then this is equivalent to a full > negotiation. >=20 > 2. Allow the server to reject signatures and specify which cipher > suites > it supports, so that the client can cache for future requests. >=20 > --Richard >=20 >=20 >=20 > Blaine Cook wrote: > > I'm not sure what the consensus is here, but it seems that at a > > minimum, we need a way to determine which algorithms are available, > to > > allow for negotiation of the cipher suite between a consumer and > > service provider. > > > > Ideally the following would be true: > > > > 1. A service provider must be able to specify a set of acceptable > > ciphers (please correct me if "cipher" is the wrong word to use > here). > > 2. A consumer must be able to specify a set of acceptable ciphers. > > 3. There must be some simple way to determine the strongest common > cipher. > > > > Any takers? Would an ordered list in the HTTP headers (e.g., > > X-OAuth-Supported-Ciphers) be sufficient? > > > > As to the question of a minimum set of supported ciphers, what about > > creating a separate RFC (or other document?) that (a) specifies > > required and optional ciphers, and (b) can be deprecated and point to > > a new document as needed, without needing to update the OAuth Core > > RFC? > > > > b. > > > > 2009/9/25 Breno : > >> This is another argument against trying to do better than TLS, since > OAuth > >> does not define its own encryption transport mechanism. > >> > >> Insecurity concerns about TLS are quite manageable by those who care > about > >> security. You can profile TLS at your will. For instance, to make > your FF > >> compliant with FIPS-140-2 TLS profile, follow the instructions here: > >> > >> http://support.mozilla.com/en- > US/kb/Configuring+Firefox+for+FIPS+140- > 2?style_mode=3Dinproduct&s=3Dcipher%20suites > >> > >> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav > > >> wrote: > >>> The one method I am sure we are going to support is a plaintext > method. > >>> > >> > >> -- > >> Breno de Medeiros > >> > >> > >> _______________________________________________ > >> 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 From James.H.Manger@team.telstra.com Sat Oct 3 09:25:24 2009 Return-Path: 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 462B43A6937 for ; Sat, 3 Oct 2009 09:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 RbykyhkLJpqo for ; Sat, 3 Oct 2009 09:25:23 -0700 (PDT) Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by core3.amsl.com (Postfix) with ESMTP id F3FF63A6853 for ; Sat, 3 Oct 2009 09:25:21 -0700 (PDT) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipai.ntcif.telstra.com.au with ESMTP; 04 Oct 2009 03:26:51 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 2999EFF81 for ; Sun, 4 Oct 2009 02:26:51 +1000 (EST) Received: from WSMSG3701.srv.dir.telstra.com (wsmsg3701.srv.dir.telstra.com [172.49.40.169]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id E31A141D3A for ; Sun, 4 Oct 2009 02:26:35 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.160]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sun, 4 Oct 2009 03:26:50 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Sun, 4 Oct 2009 03:26:27 +1100 Thread-Topic: realms Thread-Index: AcpERkHflHLMplkHRVWxLHZNJJrwXA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1124423C1E8@WSMSG3153V.srv.dir.telstra.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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1124423C1E8WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] realms X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 16:25:24 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1124423C1E8WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVhbG1zIGhhdmUgYmVlbiBkaXNjdXNzZWQgYSBsb3QgdGhpcyB3ZWVrLiBUaGVyZSBhcmUgZGlm ZmVyZW50IG9waW5pb25zIGFib3V0IHRoZWlyIHdvcnRoLCBidXQgdGhlcmUgYWxzbyBzZWVtIHRv IGJlIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5ncyBhYm91dCB0aGUgdGVjaG5pY2FsIGRldGFpbHMg YXMgd2VsbCB3aGljaCBpcyBoaW5kZXJpbmcgcHJvZ3Jlc3MuIEJlbG93IGlzIG15IHVuZGVyc3Rh bmRpbmcuDQoNCg0KDQpSRkMgMjYxNyDigJxIVFRQIEF1dGhlbnRpY2F0aW9u4oCdIGRlZmluZXMg YSByZWFsbSBwYXJhbWV0ZXIuDQoNCg0KDQpBIHJlYWxtIGlzIHJlcXVpcmVkIGluIGFueSBXV1ct QXV0aGVudGljYXRpb24gaGVhZGVyIHJldHVybmVkIGJ5IGEgc2VydmVyICh1c3VhbGx5IGluIGEg NDAxIHJlc3BvbnNlKS4NCg0KDQoNCkEgcmVhbG0gaXMgYSBzdHJpbmcuIEl0IGRvZXMgbm90IGhh dmUgdG8gYmUgYSBVUkksIGFuZCB1c3VhbGx5IGlzbuKAmXQgaW4gbXkgZXhwZXJpZW5jZS4NCg0K DQoNClRoZSBvbmx5IGRlZmluZWQgb3BlcmF0aW9uIHdpdGggYSByZWFsbSBpcyB0byBjb21wYXJl IHRoZSByZWFsbSB2YWx1ZXMgZnJvbSBkaWZmZXJlbnQgNDAxIHJlc3BvbnNlcyBmcm9tIHRoZSBz YW1lIG9yaWdpbiAoc2NoZW1lL2hvc3QvcG9ydCkuIElmIHRoZXkgbWF0Y2ggdGhlbiB0aGUgc2Ft ZSBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBzaG91bGQgd29yayBmb3IgYm90aCByZXNvdXJj ZXMuDQoNCg0KDQpBIHNwZWNpZmljIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lIGNhbiBhZGQg aXQgb3duIGFkZGl0aW9uYWwgc2VtYW50aWNzIHRvIHJlYWxtLg0KDQoNCg0KVGhlIHNhbWUgcmVh bG0gdmFsdWUgZnJvbSB0d28gZGlmZmVyZW50IHNlcnZlcnMgZG9lcyBub3QgaW1wbHkgYW55dGhp bmcuIEl0IGNlcnRhaW5seSBkb2VzIG5vdCBpbXBseSBjcmVkZW50aWFscyBzaG91bGQgYmUgc2hh cmVkIGFjcm9zcyB0aGUgZG9tYWlucy4NCg0KDQoNCk9uY2UgYSBjbGllbnQgaGFzIGxlYXJudCB0 aGUgcmVhbG0gZm9yIG9uZSByZXNvdXJjZSBpdCBpcyByZWFzb25hYmxlIHRvIGFzc3VtZSBhbnkg c3ViLXJlc291cmNlIGhhcyB0aGUgc2FtZSByZWFsbS4gWW91IHNob3VsZCBOT1QgYXNzdW1lIG5v bi1zdWItcmVzb3VyY2VzIGFyZSBpbiB0aGUgc2FtZSByZWFsbS4gQ29uc2VxdWVudGx5LCBpdCBp cyBzZW5zaWJsZSBmb3IgYSBjbGllbnQgdG8gcHJvYWN0aXZlbHkgYXV0aGVudGljYXRlIHJlcXVl c3RzIHRvIHN1Yi1yZXNvdXJjZXMgKHdpdGhvdXQgd2FpdGluZyBmb3IgYSA0MDEgdG8gYW4gdW5h dXRoZW50aWNhdGVkIHJlcXVlc3QpLg0KDQoNCg0KV2ViIGJyb3dzZXJzIHN1cHBvcnQgcmVhbG1z Lg0KDQoNCg0KSSB0ZXN0ZWQgSW50ZXJuZXQgRXhwbG9yZXIgOCBhbmQgRmlyZWZveCAzLjUgYnkg dmlzaXRpbmcgNCBVUklzIGluIHR1cm4gd2l0aGluIHRoZSBzYW1lIGJyb3dzZXIgc2Vzc2lvbi4g QWxsIGZvdXIgcmVxdWlyZWQgSFRUUCBCQVNJQyBhdXRoZW50aWNhdGlvbi4gVGhyZWUgc3BlY2lm aWVkIGEgcmVhbG0gb2Yg4oCcQUFBQeKAnSwgb25lIHNwZWNpZmllZCBhIHJlYWxtIG9mIOKAnEJC QkLigJ0uIElFOCBhbmQgRkYzLjUgYm90aCBiZWhhdmVkIHRoZSBzYW1lIHdheS4NCg0KMS4gIGh0 dHA6Ly9leGFtcGxlLm5ldC9yZWFsbUEvDQoNCjIuICBodHRwOi8vZXhhbXBsZS5uZXQgL2Fsc29S ZWFsbUEvDQoNCjMuICBodHRwOi8vZXhhbXBsZS5uZXQgL3JlYWxtQi8NCg0KNC4gIGh0dHA6Ly9k aWZmZXJlbnQubmV0L3JlYWxtQS8NCg0KDQoNCjEuIFZpc2l0aW5nIC9yZWFsbUEvIHJlc3VsdGVk IGluIGEgNDAxIHRoYXQgdHJpZ2dlcmVkIGEgYnJvd3NlciBwcm9tcHQgZm9yIGEgdXNlcm5hbWUv cGFzc3dvcmQsIHRoZW4gdGhlIGJyb3dzZXIgcmV0cmllZCB0aGUgcmVxdWVzdCBzdWNjZXNzZnVs bHkgd2l0aCBhbiBBdXRob3JpemF0aW9uIGhlYWRlci4NCg0KMi4gVGhlIEF1dGhvcml6YXRpb24g aGVhZGVyIHdhcyBOT1Qgc2VudCB3aGVuIHN1YnNlcXVlbnRseSB2aXN0aW5nIC9hbHNvUmVhbG1B Ly4gSG93ZXZlciwgdGhlcmUgd2FzIE5PIFBST01QVCBhcyB0aGUgNDAxIHJlc3BvbnNlIGhhZCB0 aGUgc2FtZSByZWFsbSBzbyB0aGUgYnJvd3NlciBhdXRvbWF0aWNhbGx5IHJldHJpZWQgdGhlIHJl cXVlc3Qgd2l0aCB0aGUgQXV0aG9yaXphdGlvbiBoZWFkZXIuDQoNCjMuIFNpbWlsYXJseSwgdGhl IEF1dGhvcml6YXRpb24gaGVhZGVyIHdhcyBOT1Qgc2VudCB3aGVuIHN1YnNlcXVlbnRseSB2aXN0 aW5nIC9yZWFsbUIvLiBBZnRlciB0aGlzIHJlcXVlc3QgdGhlcmUgd2FzIEFOT1RIRVIgUFJPTVBU IGZvciBhIHVzZXJuYW1lL3Bhc3N3b3JkIOKAlCBiZWNhdXNlIHRoZSByZWFsbSB3YXMgZGlmZmVy ZW50Lg0KDQo0LiBWaXNpdGluZyB0aGUgL3JlYWxtQS8gYXQgYSBkaWZmZXJlbnQgaG9zdCAoYWN0 dWFsbHkgdGhlIHNhbWUgd2ViIHNlcnZlciwgc2FtZSBJUCBhZGRyZXNzLCBqdXN0IGEgZGlmZmVy ZW50IGRvbWFpbiBuYW1lKSB0cmlnZ2VyZWQgQU5PVEhFUiBQUk9NUFQuIFRoZSBicm93c2VyIHJl Y29nbml6ZWQgdGhhdCB0aGUgc2FtZSByZWFsbSB2YWx1ZSBpcyBpcnJlbGV2YW50IGlmIHRoZSBv cmlnaW4gaXMgZGlmZmVyZW50Lg0KDQoNCg0KDQoNCg0KDQotPiBHRVQgL3JlYWxtQS8NCg0KPC0g NDAxIOKApiBXV1ctQXV0aGVudGljYXRlOiBCQVNJQyByZWFsbT3igJ1BQUFB4oCdDQoNCkJyb3dz ZXIgcHJvbXB0cyBmb3IgdXNlcm5hbWUvcGFzc3dvcmQNCg0KLT4gR0VUIC9yZWFsbUEvIOKApiBB dXRob3JpemF0aW9uOiBabTl2T21KaGNnPT0NCg0KPC0gMjAwDQoNCg0KDQotPiBHRVQgL2Fsc29S ZWFsbUEvDQoNCjwtIDQwMSDigKYgV1dXLUF1dGhlbnRpY2F0ZTogQkFTSUMgcmVhbG094oCdQUFB QeKAnQ0KDQpObyBicm93c2VyIHByb21wdA0KDQotPiBHRVQgL2Fsc29SZWFsbUEvIOKApiBBdXRo b3JpemF0aW9uOiBabTl2T21KaGNnPT0NCg0KPC0gMjAwDQoNCg0KDQotPiBHRVQgL3JlYWxtQi8N Cg0KPC0gNDAxIOKApiBXV1ctQXV0aGVudGljYXRlOiBCQVNJQyByZWFsbT3igJ1CQkJC4oCdDQoN CkJyb3dzZXIgcHJvbXB0cyBmb3IgdXNlcm5hbWUvcGFzc3dvcmQNCg0KLT4gR0VUIC9yZWFsbUIv IOKApiBBdXRob3JpemF0aW9uOiB6Mzl2T21KaHdRPT0NCg0KPC0gMjAwDQoNCg0KDQotPiBHRVQg L3JlYWxtQS8g4oCmIEhvc3Q6IGRpZmZlcmVudC5uZXQNCg0KPC0gNDAxIOKApiBXV1ctQXV0aGVu dGljYXRlOiBCQVNJQyByZWFsbT3igJ1BQUFB4oCdDQoNCkJyb3dzZXIgcHJvbXB0cyBmb3IgdXNl cm5hbWUvcGFzc3dvcmQNCg0KLT4gR0VUIC9yZWFsbUEvIOKApiBBdXRob3JpemF0aW9uOiBabTl2 T21KaGNnPT0NCg0KPC0gMjAwDQoNCg0KDQoNCg0KU2VsZWN0ZWQgdGV4dCBmcm9tIFJGQyAyNjE3 IOKAnEhUVFAgQXV0aGVudGljYXRpb27igJ06DQoNCg0KDQoNCg0KMS4yIEFjY2VzcyBBdXRoZW50 aWNhdGlvbiBGcmFtZXdvcmsNCuKApg0KICAgVGhlIGF1dGhlbnRpY2F0aW9uIHBhcmFtZXRlciBy ZWFsbSBpcyBkZWZpbmVkIGZvciBhbGwgYXV0aGVudGljYXRpb24NCiAgIHNjaGVtZXM6DQoNCiAg ICAgIHJlYWxtICAgICAgID0gInJlYWxtIiAiPSIgcmVhbG0tdmFsdWUNCiAgICAgIHJlYWxtLXZh bHVlID0gcXVvdGVkLXN0cmluZw0KDQogICBUaGUgcmVhbG0gZGlyZWN0aXZlIChjYXNlLWluc2Vu c2l0aXZlKSBpcyByZXF1aXJlZCBmb3IgYWxsDQogICBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHRo YXQgaXNzdWUgYSBjaGFsbGVuZ2UuIFRoZSByZWFsbSB2YWx1ZQ0KICAgKGNhc2Utc2Vuc2l0aXZl KSwgaW4gY29tYmluYXRpb24gd2l0aCB0aGUgY2Fub25pY2FsIHJvb3QgVVJMICh0aGUNCiAgIGFi c29sdXRlVVJJIGZvciB0aGUgc2VydmVyIHdob3NlIGFic19wYXRoIGlzIGVtcHR5OyBzZWUgc2Vj dGlvbiA1LjEuMjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjbWFya3VwP2RvYz0yNjE3I3NlY3Rp b24tNS4xLjI+DQogICBvZiBbMjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjbWFya3VwP2RvYz0y NjE3I3JlZi0yPl0pIG9mIHRoZSBzZXJ2ZXIgYmVpbmcgYWNjZXNzZWQsIGRlZmluZXMgdGhlIHBy b3RlY3Rpb24gc3BhY2UuDQogICBUaGVzZSByZWFsbXMgYWxsb3cgdGhlIHByb3RlY3RlZCByZXNv dXJjZXMgb24gYSBzZXJ2ZXIgdG8gYmUNCiAgIHBhcnRpdGlvbmVkIGludG8gYSBzZXQgb2YgcHJv dGVjdGlvbiBzcGFjZXMsIGVhY2ggd2l0aCBpdHMgb3duDQogICBhdXRoZW50aWNhdGlvbiBzY2hl bWUgYW5kL29yIGF1dGhvcml6YXRpb24gZGF0YWJhc2UuIFRoZSByZWFsbSB2YWx1ZQ0KICAgaXMg YSBzdHJpbmcsIGdlbmVyYWxseSBhc3NpZ25lZCBieSB0aGUgb3JpZ2luIHNlcnZlciwgd2hpY2gg bWF5IGhhdmUNCiAgIGFkZGl0aW9uYWwgc2VtYW50aWNzIHNwZWNpZmljIHRvIHRoZSBhdXRoZW50 aWNhdGlvbiBzY2hlbWUuIE5vdGUgdGhhdA0KICAgdGhlcmUgbWF5IGJlIG11bHRpcGxlIGNoYWxs ZW5nZXMgd2l0aCB0aGUgc2FtZSBhdXRoLXNjaGVtZSBidXQNCiAgIGRpZmZlcmVudCByZWFsbXMu DQoNCuKApg0KDQoNCg0KMiBCYXNpYyBBdXRoZW50aWNhdGlvbiBTY2hlbWUNCg0KDQoNCiAgIOKA plRoZSByZWFsbSB2YWx1ZSBzaG91bGQgYmUgY29uc2lkZXJlZCBhbiBvcGFxdWUgc3RyaW5nDQoN CiAgIHdoaWNoIGNhbiBvbmx5IGJlIGNvbXBhcmVkIGZvciBlcXVhbGl0eSB3aXRoIG90aGVyIHJl YWxtcyBvbiB0aGF0DQoNCiAgIHNlcnZlci4NCg0K4oCmDQoNCjMgRGlnZXN0IEFjY2VzcyBBdXRo ZW50aWNhdGlvbiBTY2hlbWUNCg0K4oCmDQoNCiAgICAgICBkaWdlc3QtY2hhbGxlbmdlICA9IDEj KCByZWFsbSB8IFsgZG9tYWluIF0gfCBub25jZSB84oCmDQoNCg0KDQogICByZWFsbQ0KICAgICBB IHN0cmluZyB0byBiZSBkaXNwbGF5ZWQgdG8gdXNlcnMgc28gdGhleSBrbm93IHdoaWNoIHVzZXJu YW1lIGFuZA0KICAgICBwYXNzd29yZCB0byB1c2UuDQrigKYNCiAgICAgICBkaWdlc3QtcmVzcG9u c2UgID0gMSMoIHVzZXJuYW1lIHwgcmVhbG0gfCBub25jZSB8IGRpZ2VzdC11cmnigKYNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpKYW1lcyBNYW5nZXINCkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3Ry YS5jb208bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+DQpJZGVudGl0eSBh bmQgc2VjdXJpdHkgdGVhbSDigJQgQ2hpZWYgVGVjaG5vbG9neSBPZmZpY2Ug4oCUIFRlbHN0cmEN Cg0K --_000_255B9BB34FB7D647A506DC292726F6E1124423C1E8WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHls ZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0Kc3Bhbi5ncmV5DQoJe21zby1zdHlsZS1uYW1lOmdyZXk7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIjsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu U2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBs aXN0IGwwDQoJe21zby1saXN0LWlkOjI1NTA5Mjc1MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzMzMTk2NTEyIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAx OTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEg MjAxOTE2NDQzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQot LT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVh bG1zIGhhdmUgYmVlbiBkaXNjdXNzZWQgYSBsb3QgdGhpcyB3ZWVrLiBUaGVyZSBhcmUgZGlmZmVy ZW50IG9waW5pb25zIGFib3V0IHRoZWlyIHdvcnRoLCBidXQgdGhlcmUgYWxzbyBzZWVtIHRvIGJl IGRpZmZlcmVudCB1bmRlcnN0YW5kaW5ncyBhYm91dCB0aGUgdGVjaG5pY2FsIGRldGFpbHMgYXMg d2VsbCB3aGljaCBpcyBoaW5kZXJpbmcgcHJvZ3Jlc3MuIEJlbG93IGlzIG15IHVuZGVyc3RhbmRp bmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQyAyNjE3IOKAnEhUVFAgQXV0aGVudGljYXRp b27igJ0gZGVmaW5lcyBhIHJlYWxtIHBhcmFtZXRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QSByZWFsbSBpcyByZXF1aXJlZCBpbiBhbnkgV1dXLUF1dGhlbnRpY2F0aW9uIGhlYWRlciByZXR1 cm5lZCBieSBhIHNlcnZlciAodXN1YWxseSBpbiBhIDQwMSByZXNwb25zZSkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkEgcmVhbG0gaXMgYSBzdHJpbmcuIEl0IGRvZXMgbm90IGhhdmUgdG8gYmUg YSBVUkksIGFuZCB1c3VhbGx5IGlzbuKAmXQgaW4gbXkgZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIG9ubHkgZGVmaW5lZCBvcGVyYXRpb24gd2l0aCBhIHJlYWxtIGlzIHRv IGNvbXBhcmUgdGhlIHJlYWxtIHZhbHVlcyBmcm9tIGRpZmZlcmVudCA0MDEgcmVzcG9uc2VzIGZy b20gdGhlIHNhbWUgb3JpZ2luIChzY2hlbWUvaG9zdC9wb3J0KS4gSWYgdGhleSBtYXRjaCB0aGVu IHRoZSBzYW1lIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIHNob3VsZCB3b3JrIGZvciBib3Ro IHJlc291cmNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBzcGVjaWZpYyBIVFRQIGF1dGhl bnRpY2F0aW9uIHNjaGVtZSBjYW4gYWRkIGl0IG93biBhZGRpdGlvbmFsIHNlbWFudGljcyB0byBy ZWFsbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNhbWUgcmVhbG0gdmFsdWUgZnJvbSB0 d28gZGlmZmVyZW50IHNlcnZlcnMgZG9lcyBub3QgaW1wbHkgYW55dGhpbmcuIEl0IGNlcnRhaW5s eSBkb2VzIG5vdCBpbXBseSBjcmVkZW50aWFscyBzaG91bGQgYmUgc2hhcmVkIGFjcm9zcyB0aGUg ZG9tYWlucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25jZSBhIGNsaWVudCBoYXMgbGVhcm50 IHRoZSByZWFsbSBmb3Igb25lIHJlc291cmNlIGl0IGlzIHJlYXNvbmFibGUgdG8gYXNzdW1lIGFu eSBzdWItcmVzb3VyY2UgaGFzIHRoZSBzYW1lIHJlYWxtLiBZb3Ugc2hvdWxkIE5PVCBhc3N1bWUg bm9uLXN1Yi1yZXNvdXJjZXMgYXJlIGluIHRoZSBzYW1lIHJlYWxtLiBDb25zZXF1ZW50bHksIGl0 IGlzIHNlbnNpYmxlIGZvciBhIGNsaWVudCB0byBwcm9hY3RpdmVseQ0KIGF1dGhlbnRpY2F0ZSBy ZXF1ZXN0cyB0byBzdWItcmVzb3VyY2VzICh3aXRob3V0IHdhaXRpbmcgZm9yIGEgNDAxIHRvIGFu IHVuYXV0aGVudGljYXRlZCByZXF1ZXN0KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViIGJy b3dzZXJzIHN1cHBvcnQgcmVhbG1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRlc3RlZCBJ bnRlcm5ldCBFeHBsb3JlciA4IGFuZCBGaXJlZm94IDMuNSBieSB2aXNpdGluZyA0IFVSSXMgaW4g dHVybiB3aXRoaW4gdGhlIHNhbWUgYnJvd3NlciBzZXNzaW9uLiBBbGwgZm91ciByZXF1aXJlZCBI VFRQIEJBU0lDIGF1dGhlbnRpY2F0aW9uLiBUaHJlZSBzcGVjaWZpZWQgYSByZWFsbSBvZiDigJxB QUFB4oCdLCBvbmUgc3BlY2lmaWVkIGEgcmVhbG0gb2Yg4oCcQkJCQuKAnS4gSUU4IGFuZCBGRjMu NSBib3RoDQogYmVoYXZlZCB0aGUgc2FtZSB3YXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4xLiZuYnNwOyBodHRwOi8vZXhhbXBsZS5uZXQvcmVhbG1BLzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gJm5ic3A7aHR0cDovL2V4YW1wbGUubmV0IC9h bHNvUmVhbG1BLzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4mbmJzcDsg aHR0cDovL2V4YW1wbGUubmV0IC9yZWFsbUIvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj40LiZuYnNwOyBodHRwOi8vZGlmZmVyZW50Lm5ldC9yZWFsbUEvPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjEuIFZpc2l0aW5nIC9yZWFsbUEvIHJlc3VsdGVkIGluIGEgNDAxIHRoYXQg dHJpZ2dlcmVkIGEgYnJvd3NlciBwcm9tcHQgZm9yIGEgdXNlcm5hbWUvcGFzc3dvcmQsIHRoZW4g dGhlIGJyb3dzZXIgcmV0cmllZCB0aGUgcmVxdWVzdCBzdWNjZXNzZnVsbHkgd2l0aCBhbiBBdXRo b3JpemF0aW9uIGhlYWRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIu IFRoZSBBdXRob3JpemF0aW9uIGhlYWRlciB3YXMgTk9UIHNlbnQgd2hlbiBzdWJzZXF1ZW50bHkg dmlzdGluZyAvYWxzb1JlYWxtQS8uIEhvd2V2ZXIsIHRoZXJlIHdhcyBOTyBQUk9NUFQgYXMgdGhl IDQwMSByZXNwb25zZSBoYWQgdGhlIHNhbWUgcmVhbG0gc28gdGhlIGJyb3dzZXIgYXV0b21hdGlj YWxseSByZXRyaWVkIHRoZSByZXF1ZXN0IHdpdGggdGhlIEF1dGhvcml6YXRpb24gaGVhZGVyLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gU2ltaWxhcmx5LCB0aGUgQXV0 aG9yaXphdGlvbiBoZWFkZXIgd2FzIE5PVCBzZW50IHdoZW4gc3Vic2VxdWVudGx5IHZpc3Rpbmcg L3JlYWxtQi8uIEFmdGVyIHRoaXMgcmVxdWVzdCB0aGVyZSB3YXMgQU5PVEhFUiBQUk9NUFQgZm9y IGEgdXNlcm5hbWUvcGFzc3dvcmQg4oCUIGJlY2F1c2UgdGhlIHJlYWxtIHdhcyBkaWZmZXJlbnQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBWaXNpdGluZyB0aGUgL3Jl YWxtQS8gYXQgYSBkaWZmZXJlbnQgaG9zdCAoYWN0dWFsbHkgdGhlIHNhbWUgd2ViIHNlcnZlciwg c2FtZSBJUCBhZGRyZXNzLCBqdXN0IGEgZGlmZmVyZW50IGRvbWFpbiBuYW1lKSB0cmlnZ2VyZWQg QU5PVEhFUiBQUk9NUFQuIFRoZSBicm93c2VyIHJlY29nbml6ZWQgdGhhdCB0aGUgc2FtZSByZWFs bSB2YWx1ZSBpcyBpcnJlbGV2YW50IGlmIHRoZSBvcmlnaW4gaXMgZGlmZmVyZW50LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgR0VU IC9yZWFsbUEvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7LSA0MDEg 4oCmIFdXVy1BdXRoZW50aWNhdGU6IEJBU0lDIHJlYWxtPeKAnUFBQUHigJ08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyb3dzZXIgcHJvbXB0cyBmb3IgdXNlcm5hbWUvcGFz c3dvcmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IEdFVCAvcmVh bG1BLyDigKYgQXV0aG9yaXphdGlvbjogWm05dk9tSmhjZz09PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbHQ7LSAyMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsg R0VUIC9hbHNvUmVhbG1BLzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0 Oy0gNDAxIOKApiBXV1ctQXV0aGVudGljYXRlOiBCQVNJQyByZWFsbT3igJ1BQUFB4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBicm93c2VyIHByb21wdDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgR0VUIC9hbHNvUmVhbG1BLyDigKYg QXV0aG9yaXphdGlvbjogWm05dk9tSmhjZz09PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbHQ7LSAyMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgR0VUIC9yZWFs bUIvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7LSA0MDEg4oCmIFdX Vy1BdXRoZW50aWNhdGU6IEJBU0lDIHJlYWxtPeKAnUJCQkLigJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJyb3dzZXIgcHJvbXB0cyBmb3IgdXNlcm5hbWUvcGFzc3dvcmQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IEdFVCAvcmVhbG1CLyDi gKYgQXV0aG9yaXphdGlvbjogejM5dk9tSmh3UT09PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbHQ7LSAyMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgR0VUIC9y ZWFsbUEvIOKApiBIb3N0OiBkaWZmZXJlbnQubmV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbHQ7LSA0MDEg4oCmIFdXVy1BdXRoZW50aWNhdGU6IEJBU0lDIHJlYWxtPeKA nUFBQUHigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyb3dzZXIgcHJv bXB0cyBmb3IgdXNlcm5hbWUvcGFzc3dvcmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0mZ3Q7IEdFVCAvcmVhbG1BLyDigKYgQXV0aG9yaXphdGlvbjogWm05dk9tSmhjZz09 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7LSAyMDA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TZWxlY3RlZCB0ZXh0IGZyb20gUkZDIDI2MTcg4oCcSFRUUCBBdXRoZW50aWNhdGlvbuKAnTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPjEuMiBB Y2Nlc3MgQXV0aGVudGljYXRpb24gRnJhbWV3b3JrPG86cD48L286cD48L3ByZT4NCjxwcmU+4oCm PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBhdXRoZW50aWNhdGlvbiBw YXJhbWV0ZXIgcmVhbG0gaXMgZGVmaW5lZCBmb3IgYWxsIGF1dGhlbnRpY2F0aW9uPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNjaGVtZXM6PG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlYWxtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gJnF1b3Q7 cmVhbG0mcXVvdDsgJnF1b3Q7PSZxdW90OyByZWFsbS12YWx1ZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWFsbS12YWx1ZSA9IHF1b3RlZC1z dHJpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgVGhlIHJlYWxtIGRpcmVjdGl2ZSAoY2FzZS1pbnNlbnNpdGl2ZSkgaXMg cmVxdWlyZWQgZm9yIGFsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhdXRo ZW50aWNhdGlvbiBzY2hlbWVzIHRoYXQgaXNzdWUgYSBjaGFsbGVuZ2UuIFRoZSByZWFsbSB2YWx1 ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAoY2FzZS1zZW5zaXRpdmUpLCBp biBjb21iaW5hdGlvbiB3aXRoIHRoZSBjYW5vbmljYWwgcm9vdCBVUkwgKHRoZTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhYnNvbHV0ZVVSSSBmb3IgdGhlIHNlcnZlciB3aG9z ZSBhYnNfcGF0aCBpcyBlbXB0eTsgc2VlIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9y ZmNtYXJrdXA/ZG9jPTI2MTcjc2VjdGlvbi01LjEuMiI+c2VjdGlvbiA1LjEuMjwvYT48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgb2YgWzxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9yZmNtYXJrdXA/ZG9jPTI2MTcjcmVmLTIiIHRpdGxlPSImcXVvdDtIeXBlcnRleHQg VHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEmcXVvdDsiPjI8L2E+XSkgb2YgdGhlIHNlcnZl ciBiZWluZyBhY2Nlc3NlZCwgZGVmaW5lcyB0aGUgcHJvdGVjdGlvbiBzcGFjZS48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhlc2UgcmVhbG1zIGFsbG93IHRoZSBwcm90ZWN0 ZWQgcmVzb3VyY2VzIG9uIGEgc2VydmVyIHRvIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IHBhcnRpdGlvbmVkIGludG8gYSBzZXQgb2YgcHJvdGVjdGlvbiBzcGFjZXMsIGVh Y2ggd2l0aCBpdHMgb3duPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGF1dGhl bnRpY2F0aW9uIHNjaGVtZSBhbmQvb3IgYXV0aG9yaXphdGlvbiBkYXRhYmFzZS4gVGhlIHJlYWxt IHZhbHVlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGlzIGEgc3RyaW5nLCBn ZW5lcmFsbHkgYXNzaWduZWQgYnkgdGhlIG9yaWdpbiBzZXJ2ZXIsIHdoaWNoIG1heSBoYXZlPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFkZGl0aW9uYWwgc2VtYW50aWNzIHNw ZWNpZmljIHRvIHRoZSBhdXRoZW50aWNhdGlvbiBzY2hlbWUuIE5vdGUgdGhhdDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgY2hhbGxlbmdl cyB3aXRoIHRoZSBzYW1lIGF1dGgtc2NoZW1lIGJ1dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBkaWZmZXJlbnQgcmVhbG1zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4yIEJhc2ljIEF1dGhlbnRpY2F0aW9uIFNjaGVtZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IOKAplRoZSByZWFsbSB2YWx1ZSBzaG91bGQgYmUgY29uc2lkZXJlZCBhbiBv cGFxdWUgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aGljaCBjYW4gb25seSBiZSBjb21wYXJlZCBmb3IgZXF1 YWxpdHkgd2l0aCBvdGhlciByZWFsbXMgb24gdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgc2VydmVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MyBEaWdlc3Qg QWNjZXNzIEF1dGhlbnRpY2F0aW9uIFNjaGVtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkaWdlc3QtY2hhbGxlbmdlJm5i c3A7ID0gMSMoIHJlYWxtIHwgWyBkb21haW4gXSB8IG5vbmNlIHzigKY8bzpwPjwvbzpwPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHJlYWxtPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgc3RyaW5nIHRvIGJlIGRpc3BsYXllZCB0byB1c2VycyBz byB0aGV5IGtub3cgd2hpY2ggdXNlcm5hbWUgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhc3N3b3JkIHRvIHVzZS48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT7igKY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7ZGlnZXN0LXJlc3BvbnNlJm5ic3A7ID0gMSMoIHVzZXJuYW1lIHwgcmVhbG0g fCBub25jZSB8IGRpZ2VzdC11cmnigKY8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SmFtZXMgTWFuZ2VyPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPg0KPGJyPg0KPGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0u dGVsc3RyYS5jb20iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L3NwYW4+PC9hPg0KPGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFt PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPuKAlDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g Q2hpZWYgVGVjaG5vbG9neSBPZmZpY2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCUPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWxzdHJhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E1124423C1E8WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Sat Oct 3 10:12:56 2009 Return-Path: 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 52F8428C0EC for ; Sat, 3 Oct 2009 10:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 0vBfhpqSYRJC for ; Sat, 3 Oct 2009 10:12:55 -0700 (PDT) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id 016103A6989 for ; Sat, 3 Oct 2009 10:12:54 -0700 (PDT) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipbi.vtcif.telstra.com.au with ESMTP; 04 Oct 2009 04:13:23 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 43ADD1DA83 for ; Sun, 4 Oct 2009 03:13:23 +1000 (EST) Received: from WSMSG3752.srv.dir.telstra.com (wsmsg3752.srv.dir.telstra.com [172.49.40.173]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id E4BD241D04 for ; Sun, 4 Oct 2009 03:13:07 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.160]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Sun, 4 Oct 2009 04:13:22 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Sun, 4 Oct 2009 04:13:21 +1100 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpC8Sw2Ny1WupCSSWSDuMgrgFIZNwABvj2gACbMNyAALML7UA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 17:12:56 -0000 Pj4gSSB0aGluayBPQXV0aCBuZWVkczoNCj4+IDEuIEEgV1dXLUF1dGggc2NoZW1lIGluZGljYXRp bmcgdGhhdCByZXF1ZXN0cyBjYW4gYmUgc2lnbmVkIHdpdGggYQ0KPj4gc2hhcmVkLXNlY3JldCBr ZXkuDQoNCj4gVGhpcyBpcyB0b28gc3BlY2lmaWMuIFdlIG5lZWQgYSBzY2hlbWUgdGhhdCBpbmRp Y2F0ZSByZXF1ZXN0cyBjYW4gYmUgbWFkZSB3aXRoIGEgdG9rZW4gKHZzLiB1c2VybmFtZSkuDQoN Cg0KRXJhbiwNCg0KSSB0aGluayBzb21lIG9mIHRoZSBkaXNjb25uZWN0IGJldHdlZW4gb3VyIGlk ZWFzIHJldm9sdmVzIGFyb3VuZCB3aGF0IGEgJ3Rva2VuJyBpcy4NCg0KSW4gT0F1dGgsIGEgKGFj Y2VzcykgdG9rZW4gaXMgYW4gaWRlbnRpZmllciBmb3IgYSBkZWxlZ2F0aW9uIG9mIHNvbWUgYXV0 aG9yaXR5IGZyb20gYSBzcGVjaWZpYyB1c2VyIHRvIGEgY2xpZW50LiBJdCBpcyBjaG9zZW4gYnkg dGhlIHNlcnZlci4gSXQgaXMgYW4gb3BhcXVlIGJsb2IgYXMgZmFyIGFzIHRoZSBjbGllbnQgaXMg Y29uY2VybmVkIOKAlCB0aGV5IGp1c3QgaGF2ZSB0byBpbmNsdWRlIGl0IGluIHN1YnNlcXVlbnQg cmVxdWVzdHMuDQoNCkZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGp1c3QgdGhlIGF1dGhlbnRpY2F0 aW9uIHBhcnQgb2YgT0F1dGggKGRyYWZ0LWlldGYtb2F1dGgtYXV0aGVudGljYXRpb24pLCBhIHRv a2VuIGlzIGp1c3QgYW4gaWQuIEkgZG9uJ3Qgc2VlIGEgdG9rZW4gYXMgYW55IGRpZmZlcmVudCBm cm9tIGEgdXNlcm5hbWUsIG9yIGFuIGFwcCBpZCwgb3IgYW4gZW1wbG95ZWUgbnVtYmVyLCBvciBh IGRldmljZSBpZCAtLSBhcyBmYXIgYXMgYW55IGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIGlzIGNv bmNlcm5lZC4NCg0KVGhlIHdlYiBoYXNuJ3QgbmVlZGVkIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBC QVNJQyBmb3IgdXNlcnMgKHdpdGggdXNlcm5hbWVzKSBhbmQgZm9yIGFwcGxpY2F0aW9ucyAoZ2Vu ZXJhbGx5IHdpdGggbG9uZyByYW5kb20gYXBwLWlkcykuDQoNCklmIHdlIG5lZWQgQkFTSUMgZm9y IHVzZXJuYW1lcyBhbmQgVE9LRU4gUExBSU4gZm9yIGRlbGVnYXRpb24gdG9rZW5zLCB3b250IHdl IGFsc28gbmVlZCBzb21ldGhpbmcgZWxzZSBmb3IgZGlyZWN0IGFjY2VzcyBieSBjbGllbnRzLiBN aWdodG4ndCB3ZSBuZWVkIGEgZGlmZmVyZW50IHNjaGVtZSBmb3IgdG9rZW5zIGlzc3VlZCBieSB0 aGUgT0F1dGggd2ViLWRlbGVnYXRpb24gZmxvdyB2cyB0b2tlbiBpc3N1ZWQgdmlhIHNvbWUgb3Ro ZXIgbWVjaGFuaXNtPw0KDQoNCg0KPj4gMi4gQSBXV1ctQXV0aCBzY2hlbWUgaW5kaWNhdGluZyB0 aGF0IGEgd2ViIGRlbGVnYXRpb24gZmxvdyBjYW4gYmUgdXNlZA0KPj4gdG8gZ2V0IHVzZXIgYXV0 aG9yaXphdGlvbi4NCg0KPiBJIGFtIG5vdCBzdXJlIHRoaXMgaXMgdGhlIHJpZ2h0IHdheSB0byBw cm92aWRlIGRlbGVnYXRpb24gZGlzY292ZXJ5ICh2aWEgdGhlIGF1dGggaGVhZGVyKS4gVXNpbmcg TGluazogaGVhZGVycyBpcyBtdWNoIG1vcmUgYXBwcm9wcmlhdGUuDQoNCkEgTGluayBoZWFkZXIg bWlnaHQgd29yay4gMSBvciAyIGV4dHJhIHJvdW5kLXRyaXBzIGNvdWxkIGJlIGF2b2lkIHdpdGgg YSBXV1ctQXV0aCBzY2hlbWUgY29tcGFyZWQgdG8gYSBMaW5rIHJlbGF0aW9uLCBhcyBhIFdXVy1B dXRoIHNjaGVtZSBjb3VsZCBiZSBtb3JlIGRlc2NyaXB0aXZlIChtb3JlIHNjaGVtZS1zcGVjaWZp YyBwYXJhbWV0ZXJzKSB0aGF0IHNlZW1zIHNlbnNpYmxlIHRvIGNyYW0gaW50byBhIExpbmsgcmVs YXRpb24uDQoNCg0KDQo+PiAtPiAgQXV0aG9yaXphdGlvbjogTUFDIHJlYWxtPSJ3aGF0ZXZlciI7 IGFsZ29yaXRobT0iSE1BQy1TSEEyNTYiOw0KDQo+IFRoZSBzeW50YXggZGlmZmVyZW5jZXMgZnJv bSBteSBwcm9wb3NhbCBhcmVuJ3Qgc2lnbmlmaWNhbnQuDQoNCkluZGVlZCwgSSB3YXNuJ3Qgc3Vn Z2VzdGluZyBhbnkgY2hhbmdlIGhlcmUgKG90aGVyIHRoYW4gIk1BQyIgYXMgYSBiZXR0ZXIgc2No ZW1lIG5hbWUpLg0KDQoNCj4+IEkgdGhpbmsgdGhlcmUgaXMgdmFsdWUgaW4gY3JlYXRpbmcgYSBm YW1pbHkgb2YgYXV0aGVudGljYXRpb24gbWV0aG9kcyB1c2luZyBhIHNjaGVtZSBhbmQgc3ViLXNj aGVtZS4gSXQgaXMgYmV0dGVyIHRvIHN1cHBvcnQgZXh0ZW5zaWJpbGl0eSBpbiB0aGUgc2NoZW1l IHRoYW4gdG8gZm9yY2UgbmV3IG1ldGhvZHMgdG8gZGVmaW5lIG5ldyBzY2hlbWVzLiBUaGlzIHdp bGwgYWxsb3cgZWFzaWVyIGltcGxlbWVudGF0aW9uIG9mIG5ldyBzdWItc2NoZW1lcy4NCg0KU28g eW91IHdhbnQgdGhlICJUT0tFTiIgc2NoZW1lIHRvIG1lYW4gImRlbGVnYXRpb24gY3JlZGVudGlh bHMiLCBhbmQgdGhlIHN1Yi1zY2hlbWUgdG8gYmUgdGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bS4NCkkgZG9u4oCZdCB0aGluayBhIHNwZWNpYWwgaW5kaWNhdG9yIGZvciAiZGVsZWdhdGlvbiBj cmVkZW50aWFscyIgaXMgbmVjZXNzYXJ5ICh1c2UgY2FzZT8pLiBJZiBhbiBpbmRpY2F0b3IgaXMg bmVjZXNzYXJ5IHdlIHNob3VsZCBtYWtlIGl0IGluZGVwZW5kZW50IG9mIHRoZSBhdXRoZW50aWNh dGlvbiBtZWNoYW5pc206IGFuIGV4dHJhIHBhcmFtZXRlciB0byBhZGQgdG8gZXhpc3RpbmcgV1dX LUF1dGggc2NoZW1lczsgYSBzcGVjaWFsIHN0cmluZyB0byBpbmNsdWRlIGluIHRoZSByZWFsbSB2 YWx1ZXMgb2YgZXhpc3RpbmcgV1dXLUF1dGggc2NoZW1lczsgYSBzZXBhcmF0ZSBIVFRQIHJlc3Bv bnNlIGhlYWRlciBpZGVudGlmeWluZyB3aGljaCBXV1ctQXV0aCBoZWFkZXJzIGFyZSBtZWFudCBm b3IgImRlbGVnYXRpb24gY3JlZGVudGlhbHMi4oCmDQoNCg0KPj4gVGhpcyBpc24ndCBuZWNlc3Nh cnkuIEp1c3QgdXNlIEJBU0lDLg0KPj4gQSBzZXJ2ZXIgbWF5IG5lZWQgdG8gZW5zdXJlIHVzZXJu YW1lcyBhbmQgdG9rZW5zIGNhbiBiZSBkaXN0aW5ndWlzaGVkLA0KPj4gYnV0IHRoYXQgaXMgZWFz eSBlbm91Z2guDQoNCj4gWWVzIGl0IGlzLiBUaGUgaWRlYSBvZiByZXF1aXJpbmcgc2VydmVycyB0 byBtYWtlIHRoaXMgZGlzdGluY3Rpb24gaXMgaW1wcmFjdGljYWwuIEJhc2ljIGF1dGggaXMgd2Vs bCBkZWZpbmVkIGFuZCBhbnkgYXR0ZW1wdCB0byBvdmVybG9hZCBpdCB3aXRoIG5ldyBtZWFuaW5n IGlzIHdyb25nLg0KDQpDb3VsZCB5b3UgZXhwbGFpbiB3aGF0IGlzIGltcHJhY3RpY2FsPw0KSWYg YSBzZXJ2ZXIgcmVhbGx5IGNhbm5vdCBkaXN0aW5ndWlzaCB0b2tlbnMgaXQgY2hvb3NlcyBmcm9t IHVzZXJuYW1lcyBpdCBjYW4gdXNlIHNlcGFyYXRlIFVSSXMgZm9yIHRoZSB0d28gZ3JvdXBzLg0K SSBkb24ndCB0aGluayB0cmVhdGluZyBhbiBPQXV0aCB0b2tlbiBhcyBhIHVzZXJuYW1lLCBvciBh IHNoYXJlZCBzZWNyZXQgYXMgYSBwYXNzd29yZCBpcyBhICJuZXcgbWVhbmluZyIuDQoNCg0KDQpK YW1lcyBNYW5nZXINCkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20NCklkZW50aXR5IGFu ZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBUZWNobm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0K DQo= From eran@hueniverse.com Sat Oct 3 10:21:19 2009 Return-Path: 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 782F13A683C for ; Sat, 3 Oct 2009 10:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, 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 i8uTQ5sQloz6 for ; Sat, 3 Oct 2009 10:21:17 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B37F13A67D3 for ; Sat, 3 Oct 2009 10:21:17 -0700 (PDT) Received: (qmail 10301 invoked from network); 3 Oct 2009 17:22:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Oct 2009 17:22:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 3 Oct 2009 10:22:46 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Sat, 3 Oct 2009 10:23:07 -0700 Thread-Topic: realms Thread-Index: AcpERkHflHLMplkHRVWxLHZNJJrwXAAB721g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2782@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E1124423C1E8@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124423C1E8@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343784DF2782P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: HTTP Working Group Subject: Re: [OAUTH-WG] realms X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 17:21:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784DF2782P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEphbWVzLiBUaGlzIGlzIHZlcnkgdXNlZnVsLg0KDQpJIHRoaW5rIHdlIHNob3VsZCBv cGVuIGFuIGlzc3VlICh1bmxlc3MgdGhlcmUgaXMgYWxyZWFkeSBvbmUpIHdpdGggSFRUUGJpcyBh Ym91dCB0aGlzIGdpdmVuIHRoZSBjdXJyZW50IHN0YXRlIG9mIFA3IGFuZCB0aGUgb3Bwb3J0dW5p dHkgdG8gY2xhcmlmeSB0aGlzLg0KDQpFSEwNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5nZXIsIEph bWVzIEgNClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDAzLCAyMDA5IDk6MjYgQU0NClRvOiBvYXV0 aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdHXSByZWFsbXMNCg0KUmVhbG1zIGhhdmUgYmVl biBkaXNjdXNzZWQgYSBsb3QgdGhpcyB3ZWVrLiBUaGVyZSBhcmUgZGlmZmVyZW50IG9waW5pb25z IGFib3V0IHRoZWlyIHdvcnRoLCBidXQgdGhlcmUgYWxzbyBzZWVtIHRvIGJlIGRpZmZlcmVudCB1 bmRlcnN0YW5kaW5ncyBhYm91dCB0aGUgdGVjaG5pY2FsIGRldGFpbHMgYXMgd2VsbCB3aGljaCBp cyBoaW5kZXJpbmcgcHJvZ3Jlc3MuIEJlbG93IGlzIG15IHVuZGVyc3RhbmRpbmcuDQoNClJGQyAy NjE3IOKAnEhUVFAgQXV0aGVudGljYXRpb27igJ0gZGVmaW5lcyBhIHJlYWxtIHBhcmFtZXRlci4N Cg0KQSByZWFsbSBpcyByZXF1aXJlZCBpbiBhbnkgV1dXLUF1dGhlbnRpY2F0aW9uIGhlYWRlciBy ZXR1cm5lZCBieSBhIHNlcnZlciAodXN1YWxseSBpbiBhIDQwMSByZXNwb25zZSkuDQoNCkEgcmVh bG0gaXMgYSBzdHJpbmcuIEl0IGRvZXMgbm90IGhhdmUgdG8gYmUgYSBVUkksIGFuZCB1c3VhbGx5 IGlzbuKAmXQgaW4gbXkgZXhwZXJpZW5jZS4NCg0KVGhlIG9ubHkgZGVmaW5lZCBvcGVyYXRpb24g d2l0aCBhIHJlYWxtIGlzIHRvIGNvbXBhcmUgdGhlIHJlYWxtIHZhbHVlcyBmcm9tIGRpZmZlcmVu dCA0MDEgcmVzcG9uc2VzIGZyb20gdGhlIHNhbWUgb3JpZ2luIChzY2hlbWUvaG9zdC9wb3J0KS4g SWYgdGhleSBtYXRjaCB0aGVuIHRoZSBzYW1lIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIHNo b3VsZCB3b3JrIGZvciBib3RoIHJlc291cmNlcy4NCg0KQSBzcGVjaWZpYyBIVFRQIGF1dGhlbnRp Y2F0aW9uIHNjaGVtZSBjYW4gYWRkIGl0IG93biBhZGRpdGlvbmFsIHNlbWFudGljcyB0byByZWFs bS4NCg0KVGhlIHNhbWUgcmVhbG0gdmFsdWUgZnJvbSB0d28gZGlmZmVyZW50IHNlcnZlcnMgZG9l cyBub3QgaW1wbHkgYW55dGhpbmcuIEl0IGNlcnRhaW5seSBkb2VzIG5vdCBpbXBseSBjcmVkZW50 aWFscyBzaG91bGQgYmUgc2hhcmVkIGFjcm9zcyB0aGUgZG9tYWlucy4NCg0KT25jZSBhIGNsaWVu dCBoYXMgbGVhcm50IHRoZSByZWFsbSBmb3Igb25lIHJlc291cmNlIGl0IGlzIHJlYXNvbmFibGUg dG8gYXNzdW1lIGFueSBzdWItcmVzb3VyY2UgaGFzIHRoZSBzYW1lIHJlYWxtLiBZb3Ugc2hvdWxk IE5PVCBhc3N1bWUgbm9uLXN1Yi1yZXNvdXJjZXMgYXJlIGluIHRoZSBzYW1lIHJlYWxtLiBDb25z ZXF1ZW50bHksIGl0IGlzIHNlbnNpYmxlIGZvciBhIGNsaWVudCB0byBwcm9hY3RpdmVseSBhdXRo ZW50aWNhdGUgcmVxdWVzdHMgdG8gc3ViLXJlc291cmNlcyAod2l0aG91dCB3YWl0aW5nIGZvciBh IDQwMSB0byBhbiB1bmF1dGhlbnRpY2F0ZWQgcmVxdWVzdCkuDQoNCldlYiBicm93c2VycyBzdXBw b3J0IHJlYWxtcy4NCg0KSSB0ZXN0ZWQgSW50ZXJuZXQgRXhwbG9yZXIgOCBhbmQgRmlyZWZveCAz LjUgYnkgdmlzaXRpbmcgNCBVUklzIGluIHR1cm4gd2l0aGluIHRoZSBzYW1lIGJyb3dzZXIgc2Vz c2lvbi4gQWxsIGZvdXIgcmVxdWlyZWQgSFRUUCBCQVNJQyBhdXRoZW50aWNhdGlvbi4gVGhyZWUg c3BlY2lmaWVkIGEgcmVhbG0gb2Yg4oCcQUFBQeKAnSwgb25lIHNwZWNpZmllZCBhIHJlYWxtIG9m IOKAnEJCQkLigJ0uIElFOCBhbmQgRkYzLjUgYm90aCBiZWhhdmVkIHRoZSBzYW1lIHdheS4NCjEu ICBodHRwOi8vZXhhbXBsZS5uZXQvcmVhbG1BLw0KMi4gIGh0dHA6Ly9leGFtcGxlLm5ldCAvYWxz b1JlYWxtQS8NCjMuICBodHRwOi8vZXhhbXBsZS5uZXQgL3JlYWxtQi8NCjQuICBodHRwOi8vZGlm ZmVyZW50Lm5ldC9yZWFsbUEvDQoNCjEuIFZpc2l0aW5nIC9yZWFsbUEvIHJlc3VsdGVkIGluIGEg NDAxIHRoYXQgdHJpZ2dlcmVkIGEgYnJvd3NlciBwcm9tcHQgZm9yIGEgdXNlcm5hbWUvcGFzc3dv cmQsIHRoZW4gdGhlIGJyb3dzZXIgcmV0cmllZCB0aGUgcmVxdWVzdCBzdWNjZXNzZnVsbHkgd2l0 aCBhbiBBdXRob3JpemF0aW9uIGhlYWRlci4NCjIuIFRoZSBBdXRob3JpemF0aW9uIGhlYWRlciB3 YXMgTk9UIHNlbnQgd2hlbiBzdWJzZXF1ZW50bHkgdmlzdGluZyAvYWxzb1JlYWxtQS8uIEhvd2V2 ZXIsIHRoZXJlIHdhcyBOTyBQUk9NUFQgYXMgdGhlIDQwMSByZXNwb25zZSBoYWQgdGhlIHNhbWUg cmVhbG0gc28gdGhlIGJyb3dzZXIgYXV0b21hdGljYWxseSByZXRyaWVkIHRoZSByZXF1ZXN0IHdp dGggdGhlIEF1dGhvcml6YXRpb24gaGVhZGVyLg0KMy4gU2ltaWxhcmx5LCB0aGUgQXV0aG9yaXph dGlvbiBoZWFkZXIgd2FzIE5PVCBzZW50IHdoZW4gc3Vic2VxdWVudGx5IHZpc3RpbmcgL3JlYWxt Qi8uIEFmdGVyIHRoaXMgcmVxdWVzdCB0aGVyZSB3YXMgQU5PVEhFUiBQUk9NUFQgZm9yIGEgdXNl cm5hbWUvcGFzc3dvcmQg4oCUIGJlY2F1c2UgdGhlIHJlYWxtIHdhcyBkaWZmZXJlbnQuDQo0LiBW aXNpdGluZyB0aGUgL3JlYWxtQS8gYXQgYSBkaWZmZXJlbnQgaG9zdCAoYWN0dWFsbHkgdGhlIHNh bWUgd2ViIHNlcnZlciwgc2FtZSBJUCBhZGRyZXNzLCBqdXN0IGEgZGlmZmVyZW50IGRvbWFpbiBu YW1lKSB0cmlnZ2VyZWQgQU5PVEhFUiBQUk9NUFQuIFRoZSBicm93c2VyIHJlY29nbml6ZWQgdGhh dCB0aGUgc2FtZSByZWFsbSB2YWx1ZSBpcyBpcnJlbGV2YW50IGlmIHRoZSBvcmlnaW4gaXMgZGlm ZmVyZW50Lg0KDQoNCg0KLT4gR0VUIC9yZWFsbUEvDQo8LSA0MDEg4oCmIFdXVy1BdXRoZW50aWNh dGU6IEJBU0lDIHJlYWxtPeKAnUFBQUHigJ0NCkJyb3dzZXIgcHJvbXB0cyBmb3IgdXNlcm5hbWUv cGFzc3dvcmQNCi0+IEdFVCAvcmVhbG1BLyDigKYgQXV0aG9yaXphdGlvbjogWm05dk9tSmhjZz09 DQo8LSAyMDANCg0KLT4gR0VUIC9hbHNvUmVhbG1BLw0KPC0gNDAxIOKApiBXV1ctQXV0aGVudGlj YXRlOiBCQVNJQyByZWFsbT3igJ1BQUFB4oCdDQpObyBicm93c2VyIHByb21wdA0KLT4gR0VUIC9h bHNvUmVhbG1BLyDigKYgQXV0aG9yaXphdGlvbjogWm05dk9tSmhjZz09DQo8LSAyMDANCg0KLT4g R0VUIC9yZWFsbUIvDQo8LSA0MDEg4oCmIFdXVy1BdXRoZW50aWNhdGU6IEJBU0lDIHJlYWxtPeKA nUJCQkLigJ0NCkJyb3dzZXIgcHJvbXB0cyBmb3IgdXNlcm5hbWUvcGFzc3dvcmQNCi0+IEdFVCAv cmVhbG1CLyDigKYgQXV0aG9yaXphdGlvbjogejM5dk9tSmh3UT09DQo8LSAyMDANCg0KLT4gR0VU IC9yZWFsbUEvIOKApiBIb3N0OiBkaWZmZXJlbnQubmV0DQo8LSA0MDEg4oCmIFdXVy1BdXRoZW50 aWNhdGU6IEJBU0lDIHJlYWxtPeKAnUFBQUHigJ0NCkJyb3dzZXIgcHJvbXB0cyBmb3IgdXNlcm5h bWUvcGFzc3dvcmQNCi0+IEdFVCAvcmVhbG1BLyDigKYgQXV0aG9yaXphdGlvbjogWm05dk9tSmhj Zz09DQo8LSAyMDANCg0KDQpTZWxlY3RlZCB0ZXh0IGZyb20gUkZDIDI2MTcg4oCcSFRUUCBBdXRo ZW50aWNhdGlvbuKAnToNCg0KDQoNCjEuMiBBY2Nlc3MgQXV0aGVudGljYXRpb24gRnJhbWV3b3Jr DQoNCuKApg0KDQogICBUaGUgYXV0aGVudGljYXRpb24gcGFyYW1ldGVyIHJlYWxtIGlzIGRlZmlu ZWQgZm9yIGFsbCBhdXRoZW50aWNhdGlvbg0KDQogICBzY2hlbWVzOg0KDQoNCg0KICAgICAgcmVh bG0gICAgICAgPSAicmVhbG0iICI9IiByZWFsbS12YWx1ZQ0KDQogICAgICByZWFsbS12YWx1ZSA9 IHF1b3RlZC1zdHJpbmcNCg0KDQoNCiAgIFRoZSByZWFsbSBkaXJlY3RpdmUgKGNhc2UtaW5zZW5z aXRpdmUpIGlzIHJlcXVpcmVkIGZvciBhbGwNCg0KICAgYXV0aGVudGljYXRpb24gc2NoZW1lcyB0 aGF0IGlzc3VlIGEgY2hhbGxlbmdlLiBUaGUgcmVhbG0gdmFsdWUNCg0KICAgKGNhc2Utc2Vuc2l0 aXZlKSwgaW4gY29tYmluYXRpb24gd2l0aCB0aGUgY2Fub25pY2FsIHJvb3QgVVJMICh0aGUNCg0K ICAgYWJzb2x1dGVVUkkgZm9yIHRoZSBzZXJ2ZXIgd2hvc2UgYWJzX3BhdGggaXMgZW1wdHk7IHNl ZSBzZWN0aW9uIDUuMS4yPGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNtYXJrdXA/ZG9jPTI2MTcj c2VjdGlvbi01LjEuMj4NCg0KICAgb2YgWzI8aHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY21hcmt1 cD9kb2M9MjYxNyNyZWYtMj5dKSBvZiB0aGUgc2VydmVyIGJlaW5nIGFjY2Vzc2VkLCBkZWZpbmVz IHRoZSBwcm90ZWN0aW9uIHNwYWNlLg0KDQogICBUaGVzZSByZWFsbXMgYWxsb3cgdGhlIHByb3Rl Y3RlZCByZXNvdXJjZXMgb24gYSBzZXJ2ZXIgdG8gYmUNCg0KICAgcGFydGl0aW9uZWQgaW50byBh IHNldCBvZiBwcm90ZWN0aW9uIHNwYWNlcywgZWFjaCB3aXRoIGl0cyBvd24NCg0KICAgYXV0aGVu dGljYXRpb24gc2NoZW1lIGFuZC9vciBhdXRob3JpemF0aW9uIGRhdGFiYXNlLiBUaGUgcmVhbG0g dmFsdWUNCg0KICAgaXMgYSBzdHJpbmcsIGdlbmVyYWxseSBhc3NpZ25lZCBieSB0aGUgb3JpZ2lu IHNlcnZlciwgd2hpY2ggbWF5IGhhdmUNCg0KICAgYWRkaXRpb25hbCBzZW1hbnRpY3Mgc3BlY2lm aWMgdG8gdGhlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZS4gTm90ZSB0aGF0DQoNCiAgIHRoZXJlIG1h eSBiZSBtdWx0aXBsZSBjaGFsbGVuZ2VzIHdpdGggdGhlIHNhbWUgYXV0aC1zY2hlbWUgYnV0DQoN CiAgIGRpZmZlcmVudCByZWFsbXMuDQrigKYNCg0KMiBCYXNpYyBBdXRoZW50aWNhdGlvbiBTY2hl bWUNCg0KICAg4oCmVGhlIHJlYWxtIHZhbHVlIHNob3VsZCBiZSBjb25zaWRlcmVkIGFuIG9wYXF1 ZSBzdHJpbmcNCiAgIHdoaWNoIGNhbiBvbmx5IGJlIGNvbXBhcmVkIGZvciBlcXVhbGl0eSB3aXRo IG90aGVyIHJlYWxtcyBvbiB0aGF0DQogICBzZXJ2ZXIuDQrigKYNCjMgRGlnZXN0IEFjY2VzcyBB dXRoZW50aWNhdGlvbiBTY2hlbWUNCuKApg0KDQogICAgICAgZGlnZXN0LWNoYWxsZW5nZSAgPSAx IyggcmVhbG0gfCBbIGRvbWFpbiBdIHwgbm9uY2UgfOKApg0KDQoNCiAgIHJlYWxtDQoNCiAgICAg QSBzdHJpbmcgdG8gYmUgZGlzcGxheWVkIHRvIHVzZXJzIHNvIHRoZXkga25vdyB3aGljaCB1c2Vy bmFtZSBhbmQNCg0KICAgICBwYXNzd29yZCB0byB1c2UuDQoNCuKApg0KDQogICAgICAgZGlnZXN0 LXJlc3BvbnNlICA9IDEjKCB1c2VybmFtZSB8IHJlYWxtIHwgbm9uY2UgfCBkaWdlc3QtdXJp4oCm DQoNCg0KDQoNCg0KSmFtZXMgTWFuZ2VyDQpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29t PG1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPg0KSWRlbnRpdHkgYW5kIHNl Y3VyaXR5IHRlYW0g4oCUIENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlIOKAlCBUZWxzdHJhDQo= --_000_90C41DD21FB7C64BB94121FBBC2E72343784DF2782P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpoMg0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUt bGluazoiSGVhZGluZyAyIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxOC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIjsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJv bGQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5ncmV5 DQoJe21zby1zdHlsZS1uYW1lOmdyZXk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0 aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K IDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFu Zz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyBK YW1lcy4gVGhpcyBpcyB2ZXJ5DQp1c2VmdWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz5JIHRoaW5rIHdlIHNob3VsZCBvcGVuIGFuIGlzc3VlICh1bmxlc3MNCnRoZXJlIGlz IGFscmVhZHkgb25lKSB3aXRoIEhUVFBiaXMgYWJvdXQgdGhpcyBnaXZlbiB0aGUgY3VycmVudCBz dGF0ZSBvZiBQNyBhbmQNCnRoZSBvcHBvcnR1bml0eSB0byBjbGFyaWZ5IHRoaXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPg0KDQo8ZGl2Pg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4NCm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hbmdlciwN CkphbWVzIEg8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE9jdG9iZXIgMDMsIDIwMDkgOToy NiBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W09BVVRILVdHXSByZWFsbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5SZWFsbXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBh IGxvdCB0aGlzIHdlZWsuDQpUaGVyZSBhcmUgZGlmZmVyZW50IG9waW5pb25zIGFib3V0IHRoZWly IHdvcnRoLCBidXQgdGhlcmUgYWxzbyBzZWVtIHRvIGJlDQpkaWZmZXJlbnQgdW5kZXJzdGFuZGlu Z3MgYWJvdXQgdGhlIHRlY2huaWNhbCBkZXRhaWxzIGFzIHdlbGwgd2hpY2ggaXMgaGluZGVyaW5n DQpwcm9ncmVzcy4gQmVsb3cgaXMgbXkgdW5kZXJzdGFuZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+UkZD IDI2MTcg4oCcSFRUUCBBdXRoZW50aWNhdGlvbuKAnSBkZWZpbmVzIGENCnJlYWxtIHBhcmFtZXRl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQVU+QSByZWFsbSBpcyByZXF1aXJlZCBpbiBhbnkNCldXVy1BdXRoZW50 aWNhdGlvbiBoZWFkZXIgcmV0dXJuZWQgYnkgYSBzZXJ2ZXIgKHVzdWFsbHkgaW4gYSA0MDEgcmVz cG9uc2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5BIHJlYWxtIGlzIGEgc3RyaW5nLiBJdCBkb2VzIG5vdCBo YXZlIHRvIGJlDQphIFVSSSwgYW5kIHVzdWFsbHkgaXNu4oCZdCBpbiBteSBleHBlcmllbmNlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t QVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1BVT5UaGUgb25seSBkZWZpbmVkIG9wZXJhdGlvbiB3aXRoIGEgcmVhbG0gaXMN CnRvIGNvbXBhcmUgdGhlIHJlYWxtIHZhbHVlcyBmcm9tIGRpZmZlcmVudCA0MDEgcmVzcG9uc2Vz IGZyb20gdGhlIHNhbWUgb3JpZ2luDQooc2NoZW1lL2hvc3QvcG9ydCkuIElmIHRoZXkgbWF0Y2gg dGhlbiB0aGUgc2FtZSBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscw0Kc2hvdWxkIHdvcmsgZm9y IGJvdGggcmVzb3VyY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5BIHNwZWNpZmljIEhUVFAgYXV0aGVudGlj YXRpb24gc2NoZW1lIGNhbg0KYWRkIGl0IG93biBhZGRpdGlvbmFsIHNlbWFudGljcyB0byByZWFs bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQVU+VGhlIHNhbWUgcmVhbG0gdmFsdWUgZnJvbSB0d28gZGlmZmVyZW50 DQpzZXJ2ZXJzIGRvZXMgbm90IGltcGx5IGFueXRoaW5nLiBJdCBjZXJ0YWlubHkgZG9lcyBub3Qg aW1wbHkgY3JlZGVudGlhbHMgc2hvdWxkDQpiZSBzaGFyZWQgYWNyb3NzIHRoZSBkb21haW5zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t QVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1BVT5PbmNlIGEgY2xpZW50IGhhcyBsZWFybnQgdGhlIHJlYWxtIGZvciBvbmUN CnJlc291cmNlIGl0IGlzIHJlYXNvbmFibGUgdG8gYXNzdW1lIGFueSBzdWItcmVzb3VyY2UgaGFz IHRoZSBzYW1lIHJlYWxtLiBZb3UNCnNob3VsZCBOT1QgYXNzdW1lIG5vbi1zdWItcmVzb3VyY2Vz IGFyZSBpbiB0aGUgc2FtZSByZWFsbS4gQ29uc2VxdWVudGx5LCBpdCBpcw0Kc2Vuc2libGUgZm9y IGEgY2xpZW50IHRvIHByb2FjdGl2ZWx5IGF1dGhlbnRpY2F0ZSByZXF1ZXN0cyB0byBzdWItcmVz b3VyY2VzICh3aXRob3V0DQp3YWl0aW5nIGZvciBhIDQwMSB0byBhbiB1bmF1dGhlbnRpY2F0ZWQg cmVxdWVzdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPldlYiBicm93c2VycyBzdXBwb3J0IHJlYWxtcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tQVU+SSB0ZXN0ZWQgSW50ZXJuZXQgRXhwbG9yZXIgOCBhbmQgRmlyZWZveA0KMy41 IGJ5IHZpc2l0aW5nIDQgVVJJcyBpbiB0dXJuIHdpdGhpbiB0aGUgc2FtZSBicm93c2VyIHNlc3Np b24uIEFsbCBmb3VyDQpyZXF1aXJlZCBIVFRQIEJBU0lDIGF1dGhlbnRpY2F0aW9uLiBUaHJlZSBz cGVjaWZpZWQgYSByZWFsbSBvZiDigJxBQUFB4oCdLCBvbmUNCnNwZWNpZmllZCBhIHJlYWxtIG9m IOKAnEJCQkLigJ0uIElFOCBhbmQgRkYzLjUgYm90aCBiZWhhdmVkIHRoZSBzYW1lIHdheS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV PjEuJm5ic3A7IGh0dHA6Ly9leGFtcGxlLm5ldC9yZWFsbUEvPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT4yLiAmbmJzcDtodHRwOi8v ZXhhbXBsZS5uZXQgL2Fsc29SZWFsbUEvPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT4zLiZuYnNwOyBodHRwOi8vZXhhbXBsZS5uZXQg L3JlYWxtQi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUFVPjQuJm5ic3A7IGh0dHA6Ly9kaWZmZXJlbnQubmV0L3JlYWxtQS88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tQVU+MS4gVmlzaXRpbmcgL3JlYWxtQS8gcmVzdWx0ZWQgaW4gYSA0MDEgdGhhdA0KdHJp Z2dlcmVkIGEgYnJvd3NlciBwcm9tcHQgZm9yIGEgdXNlcm5hbWUvcGFzc3dvcmQsIHRoZW4gdGhl IGJyb3dzZXIgcmV0cmllZA0KdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bGx5IHdpdGggYW4gQXV0aG9y aXphdGlvbiBoZWFkZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1BVT4yLiBUaGUgQXV0aG9yaXphdGlvbiBoZWFkZXIgd2FzIE5PVCBz ZW50DQp3aGVuIHN1YnNlcXVlbnRseSB2aXN0aW5nIC9hbHNvUmVhbG1BLy4gSG93ZXZlciwgdGhl cmUgd2FzIE5PIFBST01QVCBhcyB0aGUgNDAxDQpyZXNwb25zZSBoYWQgdGhlIHNhbWUgcmVhbG0g c28gdGhlIGJyb3dzZXIgYXV0b21hdGljYWxseSByZXRyaWVkIHRoZSByZXF1ZXN0DQp3aXRoIHRo ZSBBdXRob3JpemF0aW9uIGhlYWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjMuIFNpbWlsYXJseSwgdGhlIEF1dGhvcml6YXRp b24gaGVhZGVyIHdhcw0KTk9UIHNlbnQgd2hlbiBzdWJzZXF1ZW50bHkgdmlzdGluZyAvcmVhbG1C Ly4gQWZ0ZXIgdGhpcyByZXF1ZXN0IHRoZXJlIHdhcw0KQU5PVEhFUiBQUk9NUFQgZm9yIGEgdXNl cm5hbWUvcGFzc3dvcmQg4oCUIGJlY2F1c2UgdGhlIHJlYWxtIHdhcyBkaWZmZXJlbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT40 LiBWaXNpdGluZyB0aGUgL3JlYWxtQS8gYXQgYSBkaWZmZXJlbnQNCmhvc3QgKGFjdHVhbGx5IHRo ZSBzYW1lIHdlYiBzZXJ2ZXIsIHNhbWUgSVAgYWRkcmVzcywganVzdCBhIGRpZmZlcmVudCBkb21h aW4NCm5hbWUpIHRyaWdnZXJlZCBBTk9USEVSIFBST01QVC4gVGhlIGJyb3dzZXIgcmVjb2duaXpl ZCB0aGF0IHRoZSBzYW1lIHJlYWxtDQp2YWx1ZSBpcyBpcnJlbGV2YW50IGlmIHRoZSBvcmlnaW4g aXMgZGlmZmVyZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+LSZndDsg R0VUIC9yZWFsbUEvPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1BVT4mbHQ7LSA0MDEg4oCmIFdXVy1BdXRoZW50aWNhdGU6IEJBU0lDDQpy ZWFsbT3igJ1BQUFB4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1BVT5Ccm93c2VyIHByb21wdHMgZm9yIHVzZXJuYW1lL3Bhc3N3b3Jk PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1BVT4tJmd0OyBHRVQgL3JlYWxtQS8g4oCmIEF1dGhvcml6YXRpb246DQpabTl2T21KaGNnPT08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUFVPiZsdDstIDIwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT4tJmd0OyBHRVQgL2Fsc29SZWFsbUEvPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT4m bHQ7LSA0MDEg4oCmIFdXVy1BdXRoZW50aWNhdGU6IEJBU0lDDQpyZWFsbT3igJ1BQUFB4oCdPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1B VT5ObyBicm93c2VyIHByb21wdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+LSZndDsgR0VUIC9hbHNvUmVhbG1BLyDigKYgQXV0aG9y aXphdGlvbjoNClptOXZPbUpoY2c9PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+Jmx0Oy0gMjAwPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPi0mZ3Q7 IEdFVCAvcmVhbG1CLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQVU+Jmx0Oy0gNDAxIOKApiBXV1ctQXV0aGVudGljYXRlOiBCQVNJQw0K cmVhbG094oCdQkJCQuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tQVU+QnJvd3NlciBwcm9tcHRzIGZvciB1c2VybmFtZS9wYXNzd29y ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQVU+LSZndDsgR0VUIC9yZWFsbUIvIOKApiBBdXRob3JpemF0aW9uOiB6Mzl2T21KaHdRPT08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUFVPiZsdDstIDIwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT4tJmd0OyBHRVQgL3JlYWxtQS8g4oCmIEhvc3Q6 IGRpZmZlcmVudC5uZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUFVPiZsdDstIDQwMSDigKYgV1dXLUF1dGhlbnRpY2F0ZTogQkFTSUMN CnJlYWxtPeKAnUFBQUHigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUFVPkJyb3dzZXIgcHJvbXB0cyBmb3IgdXNlcm5hbWUvcGFzc3dv cmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUFVPi0mZ3Q7IEdFVCAvcmVhbG1BLyDigKYgQXV0aG9yaXphdGlvbjoNClptOXZPbUpoY2c9 PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQVU+Jmx0Oy0gMjAwPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+U2VsZWN0ZWQgdGV4dCBm cm9tIFJGQyAyNjE3IOKAnEhUVFANCkF1dGhlbnRpY2F0aW9u4oCdOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwcmU+PHNwYW4gbGFuZz1FTi1BVT4xLjIg QWNjZXNzIEF1dGhlbnRpY2F0aW9uIEZyYW1ld29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmU+PHNwYW4NCmxhbmc9RU4tQVU+4oCmPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3Bh biBsYW5nPUVOLUFVPiZuYnNwOyZuYnNwOyBUaGUgYXV0aGVudGljYXRpb24gcGFyYW1ldGVyIHJl YWxtIGlzIGRlZmluZWQgZm9yIGFsbCBhdXRoZW50aWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPjxwcmU+PHNwYW4NCmxhbmc9RU4tQVU+Jm5ic3A7Jm5ic3A7IHNjaGVtZXM6PG86cD48L286 cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPjxwcmU+PHNwYW4NCmxhbmc9RU4tQVU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlYWxtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gJnF1b3Q7 cmVhbG0mcXVvdDsgJnF1b3Q7PSZxdW90OyByZWFsbS12YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPjxwcmU+PHNwYW4NCmxhbmc9RU4tQVU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJlYWxtLXZhbHVlID0gcXVvdGVkLXN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+ PHNwYW4NCmxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+PHByZT48c3Bh biBsYW5nPUVOLUFVPiZuYnNwOyZuYnNwOyBUaGUgcmVhbG0gZGlyZWN0aXZlIChjYXNlLWluc2Vu c2l0aXZlKSBpcyByZXF1aXJlZCBmb3IgYWxsPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48 c3Bhbg0KbGFuZz1FTi1BVT4mbmJzcDsmbmJzcDsgYXV0aGVudGljYXRpb24gc2NoZW1lcyB0aGF0 IGlzc3VlIGEgY2hhbGxlbmdlLiBUaGUgcmVhbG0gdmFsdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT48cHJlPjxzcGFuDQpsYW5nPUVOLUFVPiZuYnNwOyZuYnNwOyAoY2FzZS1zZW5zaXRpdmUpLCBp biBjb21iaW5hdGlvbiB3aXRoIHRoZSBjYW5vbmljYWwgcm9vdCBVUkwgKHRoZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4NCmxhbmc9RU4tQVU+Jm5ic3A7Jm5ic3A7IGFic29sdXRl VVJJIGZvciB0aGUgc2VydmVyIHdob3NlIGFic19wYXRoIGlzIGVtcHR5OyBzZWUgPGENCmhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNtYXJrdXA/ZG9jPTI2MTcjc2VjdGlvbi01LjEuMiI+ c2VjdGlvbiA1LjEuMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuDQpsYW5n PUVOLUFVPiZuYnNwOyZuYnNwOyBvZiBbPGENCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9y ZmNtYXJrdXA/ZG9jPTI2MTcjcmVmLTIiDQp0aXRsZT0iJnF1b3Q7SHlwZXJ0ZXh0IFRyYW5zZmVy IFByb3RvY29sIC0tIEhUVFAvMS4xJnF1b3Q7Ij4yPC9hPl0pIG9mIHRoZSBzZXJ2ZXIgYmVpbmcg YWNjZXNzZWQsIGRlZmluZXMgdGhlIHByb3RlY3Rpb24gc3BhY2UuPG86cD48L286cD48L3NwYW4+ PC9wcmU+PHByZT48c3Bhbg0KbGFuZz1FTi1BVT4mbmJzcDsmbmJzcDsgVGhlc2UgcmVhbG1zIGFs bG93IHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzIG9uIGEgc2VydmVyIHRvIGJlPG86cD48L286cD48 L3NwYW4+PC9wcmU+PHByZT48c3Bhbg0KbGFuZz1FTi1BVT4mbmJzcDsmbmJzcDsgcGFydGl0aW9u ZWQgaW50byBhIHNldCBvZiBwcm90ZWN0aW9uIHNwYWNlcywgZWFjaCB3aXRoIGl0cyBvd248bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuDQpsYW5nPUVOLUFVPiZuYnNwOyZuYnNwOyBh dXRoZW50aWNhdGlvbiBzY2hlbWUgYW5kL29yIGF1dGhvcml6YXRpb24gZGF0YWJhc2UuIFRoZSBy ZWFsbSB2YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4NCmxhbmc9RU4tQVU+ Jm5ic3A7Jm5ic3A7IGlzIGEgc3RyaW5nLCBnZW5lcmFsbHkgYXNzaWduZWQgYnkgdGhlIG9yaWdp biBzZXJ2ZXIsIHdoaWNoIG1heSBoYXZlPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3Bh bg0KbGFuZz1FTi1BVT4mbmJzcDsmbmJzcDsgYWRkaXRpb25hbCBzZW1hbnRpY3Mgc3BlY2lmaWMg dG8gdGhlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZS4gTm90ZSB0aGF0PG86cD48L286cD48L3NwYW4+ PC9wcmU+PHByZT48c3Bhbg0KbGFuZz1FTi1BVT4mbmJzcDsmbmJzcDsgdGhlcmUgbWF5IGJlIG11 bHRpcGxlIGNoYWxsZW5nZXMgd2l0aCB0aGUgc2FtZSBhdXRoLXNjaGVtZSBidXQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuDQpsYW5nPUVOLUFVPiZuYnNwOyZuYnNwOyBkaWZmZXJl bnQgcmVhbG1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Mg0KQmFzaWMgQXV0aGVudGljYXRpb24gU2NoZW1lPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNw OyZuYnNwOw0K4oCmVGhlIHJlYWxtIHZhbHVlIHNob3VsZCBiZSBjb25zaWRlcmVkIGFuIG9wYXF1 ZSBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZuYnNwOyZuYnNwOw0Kd2hpY2ggY2FuIG9ubHkgYmUgY29tcGFyZWQgZm9yIGVxdWFs aXR5IHdpdGggb3RoZXIgcmVhbG1zIG9uIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOw0Kc2VydmVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+4oCmPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4zDQpEaWdl c3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uIFNjaGVtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8cHJlPjxzcGFuIGxhbmc9RU4tQVU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGRpZ2VzdC1jaGFsbGVuZ2UmbmJzcDsgPSAxIyggcmVhbG0gfCBbIGRvbWFpbiBdIHwgbm9u Y2UgfOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1BVSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwcmU+PHNwYW4gbGFuZz1F Ti1BVT4mbmJzcDsmbmJzcDsgcmVhbG08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFu DQpsYW5nPUVOLUFVPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIHN0cmluZyB0byBiZSBkaXNw bGF5ZWQgdG8gdXNlcnMgc28gdGhleSBrbm93IHdoaWNoIHVzZXJuYW1lIGFuZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4NCmxhbmc9RU4tQVU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHBhc3N3b3JkIHRvIHVzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuDQps YW5nPUVOLUFVPuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTi1B VT4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ZGlnZXN0LXJlc3BvbnNlJm5i c3A7ID0gMSMoIHVzZXJuYW1lIHwgcmVhbG0gfCBub25jZSB8IGRpZ2VzdC11cmnigKY8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1BVSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5KYW1lcw0KTWFuZ2Vy PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPg0KPGJyPg0KPGEgaHJlZj0ibWFpbHRv OkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iPjxzcGFuIGxhbmc9RlINCnN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5KYW1lcy5I Lk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9zcGFuPjwvYT4NCjxicj4NCjwvc3Bhbj48c3BhbiBs YW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz5JZGVudGl0eQ0KYW5kIHNlY3VyaXR5IHRlYW08L3NwYW4+PHNwYW4gbGFuZz1F Ti1BVSBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToNCiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiInPiA8L3NwYW4+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+4oCUPC9zcGFuPjxzcGFu IGxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+IENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlPC9zcGFuPjxzcGFuDQpsYW5n PUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiInPiA8L3NwYW4+PHNwYW4NCmxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7igJQ8L3NwYW4+PHNwYW4N Cmxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPiBUZWxzdHJhPC9zcGFuPjxzcGFuDQpsYW5nPUVOLUFVIHN0eWxlPSdmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPiA8L3Nw YW4+PHNwYW4NCmxhbmc9RU4tQVU+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0K PC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_90C41DD21FB7C64BB94121FBBC2E72343784DF2782P3PW5EX1MB01E_-- From eran@hueniverse.com Sat Oct 3 10:53:31 2009 Return-Path: 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 529AB3A69AB for ; Sat, 3 Oct 2009 10:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_00=-2.599] 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 vm+x6FnB76hw for ; Sat, 3 Oct 2009 10:53:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 260903A683C for ; Sat, 3 Oct 2009 10:53:30 -0700 (PDT) Received: (qmail 15233 invoked from network); 3 Oct 2009 17:54:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Oct 2009 17:54:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 3 Oct 2009 10:54:47 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Sat, 3 Oct 2009 10:55:07 -0700 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpC8Sw2Ny1WupCSSWSDuMgrgFIZNwABvj2gACbMNyAALML7UAAB85tQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 17:53:31 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgTWFu Z2VyLCBKYW1lcyBIDQo+IFNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDAzLCAyMDA5IDEwOjEzIEFN DQoNCj4gSSB0aGluayBzb21lIG9mIHRoZSBkaXNjb25uZWN0IGJldHdlZW4gb3VyIGlkZWFzIHJl dm9sdmVzIGFyb3VuZCB3aGF0IGENCj4gJ3Rva2VuJyBpcy4NCg0KT25seSBpbiB0aGUgc2Vuc2Ug dGhhdCB3aGlsZSB0ZWNobmljYWxseSBjb3JyZWN0LCB5b3VyIHByb3Bvc2FsIGJyZWFrcyBleGlz dGluZyBleHBlY3RhdGlvbnMgYW5kIGJyb3dzZXIgYmVoYXZpb3IuIEp1c3QgdGhlIGZhY3QgdGhh dCBzZXJ2ZXJzIHdpbGwgbmVlZCB0byB3b3JyeSBhYm91dCB0aGUgb3JkZXIgb2YgdGhlaXIgYXV0 aG9yaXphdGlvbiBoZWFkZXIgaW4gb3JkZXIgdG8gc3VwcG9ydCBib3RoIHVzZXJuYW1lcyBhbmQg dG9rZW5zIG9uIHRoZSBzYW1lIHJlc291cmNlIGlzIHRvIG1lIGEgbm9uLXN0YXJ0ZXIuDQoNCk15 IHBvaW50IGlzIG9ubHkgdGhhdCB0aGUgZXhpc3RpbmcgZGVwbG95bWVudCBvZiBCYXNpYyBwcmV2 ZW50cyBpdCBmcm9tIGJlaW5nIHVzZWQgaW4gdGhlIHdheSB5b3UgcHJvcG9zZWQgYmVjYXVzZSBp dCBpcyBtb3JlIGxpa2VseSB0byBicmVhayB0aGluZ3MgYW5kIGRvZXMgbm90IG9mZmVyIGFueSBy ZWFsIGJlbmVmaXQgKG90aGVyIHRoYW4gYSB0aGVvcmV0aWNhbCBjbGVhbmVyIGFyY2hpdGVjdHVy ZSksIGFuZCBsZXNzIHdvcmsgZm9yIHRoZSBzcGVjIGVkaXRvci4NCg0KPiBJZiB3ZSBuZWVkIEJB U0lDIGZvciB1c2VybmFtZXMgYW5kIFRPS0VOIFBMQUlOIGZvciBkZWxlZ2F0aW9uIHRva2VucywN Cj4gd29udCB3ZSBhbHNvIG5lZWQgc29tZXRoaW5nIGVsc2UgZm9yIGRpcmVjdCBhY2Nlc3MgYnkg Y2xpZW50cy4gTWlnaHRuJ3QNCj4gd2UgbmVlZCBhIGRpZmZlcmVudCBzY2hlbWUgZm9yIHRva2Vu cyBpc3N1ZWQgYnkgdGhlIE9BdXRoIHdlYi0NCj4gZGVsZWdhdGlvbiBmbG93IHZzIHRva2VuIGlz c3VlZCB2aWEgc29tZSBvdGhlciBtZWNoYW5pc20/DQoNCkkgYWdyZWUgdGhhdCB0aGUgc2NoZW1l IG5hbWUgKFRva2VuKSBpc24ndCBhY2N1cmF0ZSBhbmQgaGFwcHkgZm9yIG90aGVyIHN1Z2dlc3Rp b25zIChzdWNoIGFzICdEZWxlZ2F0ZScsIGV0Yy4pLiBUbyBtZSB0b2tlbiBpbXBsaWVzIHNvbWUg b3RoZXIgY3JlZGVudGlhbCBpbiBwbGFjZSBvZiBhIHVzZXJuYW1lIGJ1dCBJIGFncmVlIHRoYXQg dGhpcyBpcyBub3QgdGhlIGNvbW1vbiB1c2Ugb2YgdGhlIHdvcmQuDQoNCkRpcmVjdCBhY2Nlc3Mg YnkgY2xpZW50cyBkb2VzIHdvcmsgd2VsbCB3aXRoIGV4aXN0aW5nIHVzZXJuYW1lLWJhc2VkIHNj aGVtZXMgYmVjYXVzZSB0aGF0J3Mgd2hhdCBpdCBpcyAtIGRpcmVjdCBhY2Nlc3MuIFdlIGhhdmUg dHdvIGRpc3RpbmN0IGNhc2VzOiBkaXJlY3QgYWNjZXNzIGFuZCBkZWxlZ2F0ZWQgYWNjZXNzLiBU aGUgaXNzdWUgaXMgdG8gaGF2ZSBib3RoIGRpcmVjdCBhY2Nlc3MgYW5kIGRlbGVnYXRlZCBhY2Nl c3MgY29leGlzdCBvbiB0aGUgc2FtZSByZXNvdXJjZS4NCg0KPiA+PiAyLiBBIFdXVy1BdXRoIHNj aGVtZSBpbmRpY2F0aW5nIHRoYXQgYSB3ZWIgZGVsZWdhdGlvbiBmbG93IGNhbiBiZQ0KPiB1c2Vk DQo+ID4+IHRvIGdldCB1c2VyIGF1dGhvcml6YXRpb24uDQo+IA0KPiA+IEkgYW0gbm90IHN1cmUg dGhpcyBpcyB0aGUgcmlnaHQgd2F5IHRvIHByb3ZpZGUgZGVsZWdhdGlvbiBkaXNjb3ZlcnkNCj4g KHZpYSB0aGUgYXV0aCBoZWFkZXIpLiBVc2luZyBMaW5rOiBoZWFkZXJzIGlzIG11Y2ggbW9yZSBh cHByb3ByaWF0ZS4NCj4gDQo+IEEgTGluayBoZWFkZXIgbWlnaHQgd29yay4gMSBvciAyIGV4dHJh IHJvdW5kLXRyaXBzIGNvdWxkIGJlIGF2b2lkIHdpdGgNCj4gYSBXV1ctQXV0aCBzY2hlbWUgY29t cGFyZWQgdG8gYSBMaW5rIHJlbGF0aW9uLCBhcyBhIFdXVy1BdXRoIHNjaGVtZQ0KPiBjb3VsZCBi ZSBtb3JlIGRlc2NyaXB0aXZlIChtb3JlIHNjaGVtZS1zcGVjaWZpYyBwYXJhbWV0ZXJzKSB0aGF0 IHNlZW1zDQo+IHNlbnNpYmxlIHRvIGNyYW0gaW50byBhIExpbmsgcmVsYXRpb24uDQoNCkkgZGlz YWdyZWUgdGhhdCBhbiBhdXRoIHNjaGVtZSBpcyBtb3JlIGFwcHJvcHJpYXRlIHRoYW4gTGluay4g TGluayBjYW4gYmUgYXMgZWFzaWx5IGV4dGVuZGVkLiBJIGRvIG5vdCBjb25zaWRlciBwcm92aWRp bmcgZGlzY292ZXJ5IGluZm9ybWF0aW9uIGFib3V0IHdoZXJlIGNyZWRlbnRpYWxzIGNhbiBiZSBv YnRhaW5lZCBhcyBhIHZhbGlkIDQwMSBjaGFsbGVuZ2UuIFRoaXMgaXMgZXhhY3RseSB3aGF0IExp bmsgaXMgZm9yLg0KIA0KPiA+PiAtPiAgQXV0aG9yaXphdGlvbjogTUFDIHJlYWxtPSJ3aGF0ZXZl ciI7IGFsZ29yaXRobT0iSE1BQy1TSEEyNTYiOw0KPiANCj4gPiBUaGUgc3ludGF4IGRpZmZlcmVu Y2VzIGZyb20gbXkgcHJvcG9zYWwgYXJlbid0IHNpZ25pZmljYW50Lg0KPiANCj4gSW5kZWVkLCBJ IHdhc24ndCBzdWdnZXN0aW5nIGFueSBjaGFuZ2UgaGVyZSAob3RoZXIgdGhhbiAiTUFDIiBhcyBh DQo+IGJldHRlciBzY2hlbWUgbmFtZSkuDQoNCkkgdGhpbmsgdGhlIHNjaGVtZSBuYW1lIHNob3Vs ZCByZWZsZWN0IGl0cyBzcGVjaWZpYyBkZWxlZ2F0aW9uLXJlbGF0ZWQgcm9sZSwgc28gTUFDIHdv dWxkIGJlIGdvb2QgZ2VuZXJpYyBhcyB3ZWxsLg0KIA0KPiA+PiBJIHRoaW5rIHRoZXJlIGlzIHZh bHVlIGluIGNyZWF0aW5nIGEgZmFtaWx5IG9mIGF1dGhlbnRpY2F0aW9uDQo+IG1ldGhvZHMgdXNp bmcgYSBzY2hlbWUgYW5kIHN1Yi1zY2hlbWUuIEl0IGlzIGJldHRlciB0byBzdXBwb3J0DQo+IGV4 dGVuc2liaWxpdHkgaW4gdGhlIHNjaGVtZSB0aGFuIHRvIGZvcmNlIG5ldyBtZXRob2RzIHRvIGRl ZmluZSBuZXcNCj4gc2NoZW1lcy4gVGhpcyB3aWxsIGFsbG93IGVhc2llciBpbXBsZW1lbnRhdGlv biBvZiBuZXcgc3ViLXNjaGVtZXMuDQo+IA0KPiBTbyB5b3Ugd2FudCB0aGUgIlRPS0VOIiBzY2hl bWUgdG8gbWVhbiAiZGVsZWdhdGlvbiBjcmVkZW50aWFscyIsIGFuZA0KPiB0aGUgc3ViLXNjaGVt ZSB0byBiZSB0aGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLg0KPiBJIGRvbuKAmXQgdGhpbmsg YSBzcGVjaWFsIGluZGljYXRvciBmb3IgImRlbGVnYXRpb24gY3JlZGVudGlhbHMiIGlzDQo+IG5l Y2Vzc2FyeSAodXNlIGNhc2U/KS4gSWYgYW4gaW5kaWNhdG9yIGlzIG5lY2Vzc2FyeSB3ZSBzaG91 bGQgbWFrZSBpdA0KPiBpbmRlcGVuZGVudCBvZiB0aGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNt OiBhbiBleHRyYSBwYXJhbWV0ZXIgdG8gYWRkDQo+IHRvIGV4aXN0aW5nIFdXVy1BdXRoIHNjaGVt ZXM7IGEgc3BlY2lhbCBzdHJpbmcgdG8gaW5jbHVkZSBpbiB0aGUgcmVhbG0NCj4gdmFsdWVzIG9m IGV4aXN0aW5nIFdXVy1BdXRoIHNjaGVtZXM7IGEgc2VwYXJhdGUgSFRUUCByZXNwb25zZSBoZWFk ZXINCj4gaWRlbnRpZnlpbmcgd2hpY2ggV1dXLUF1dGggaGVhZGVycyBhcmUgbWVhbnQgZm9yICJk ZWxlZ2F0aW9uDQo+IGNyZWRlbnRpYWxzIuKApg0KDQpUaGlzIGlzIG5lZWRlZCB0byB3b3JrIHdp dGggZXhpc3RpbmcgZGVwbG95bWVudHMsIGFuZCB3aGlsZSBJIHJlYWxseSBsaWtlIHRoZSBpZGVh IG9mIGFkZGluZyBhIHBhcmFtZXRlciB0byBleGlzdGluZyBzY2hlbWVzLCBpdCB3aWxsIG5vdCBo ZWxwIHdpdGggZXhpc3RpbmcgY29kZSB3aGljaCB3aWxsIHNpbXBseSBpZ25vcmUgaXQgYW5kIGJy ZWFrLg0KDQo+ID4+IFRoaXMgaXNuJ3QgbmVjZXNzYXJ5LiBKdXN0IHVzZSBCQVNJQy4NCj4gPj4g QSBzZXJ2ZXIgbWF5IG5lZWQgdG8gZW5zdXJlIHVzZXJuYW1lcyBhbmQgdG9rZW5zIGNhbiBiZQ0K PiBkaXN0aW5ndWlzaGVkLA0KPiA+PiBidXQgdGhhdCBpcyBlYXN5IGVub3VnaC4NCj4gDQo+ID4g WWVzIGl0IGlzLiBUaGUgaWRlYSBvZiByZXF1aXJpbmcgc2VydmVycyB0byBtYWtlIHRoaXMgZGlz dGluY3Rpb24gaXMNCj4gaW1wcmFjdGljYWwuIEJhc2ljIGF1dGggaXMgd2VsbCBkZWZpbmVkIGFu ZCBhbnkgYXR0ZW1wdCB0byBvdmVybG9hZCBpdA0KPiB3aXRoIG5ldyBtZWFuaW5nIGlzIHdyb25n Lg0KPiANCj4gQ291bGQgeW91IGV4cGxhaW4gd2hhdCBpcyBpbXByYWN0aWNhbD8NCj4gSWYgYSBz ZXJ2ZXIgcmVhbGx5IGNhbm5vdCBkaXN0aW5ndWlzaCB0b2tlbnMgaXQgY2hvb3NlcyBmcm9tIHVz ZXJuYW1lcw0KPiBpdCBjYW4gdXNlIHNlcGFyYXRlIFVSSXMgZm9yIHRoZSB0d28gZ3JvdXBzLg0K PiBJIGRvbid0IHRoaW5rIHRyZWF0aW5nIGFuIE9BdXRoIHRva2VuIGFzIGEgdXNlcm5hbWUsIG9y IGEgc2hhcmVkIHNlY3JldA0KPiBhcyBhIHBhc3N3b3JkIGlzIGEgIm5ldyBtZWFuaW5nIi4NCg0K SXQgbWVhbnMgY2hhbmdpbmcgZXhpc3RpbmcgdXNlcm5hbWUgcGxhdGZvcm1zIChtYW55IHdpdGgg c3Ryb25nIGJhY2tlbmQgaW50ZWdyYXRpb24gd2l0aCBhIGxvZ2luIHN5c3RlbSkgdG8gZmlyc3Qg Y2hlY2sgZm9yIGEgcGF0dGVybi4gSXQgcHV0cyBsaW1pdGF0aW9ucyBvbiB0b2tlbiBkZXNpZ24g YmVjYXVzZSBvZiBleGlzdGluZyB1c2VybmFtZXMuIEJ1dCB0aGUgbWFpbiBpc3N1ZSBpcyB0aGF0 IGl0IGlzIHZlcnkgbGlrZWx5IHRvIGJyZWFrIGV4aXN0aW5nIGNsaWVudHMuDQoNCkkgZG9uJ3Qg dGhpbmsgeW91IGhhdmUgZGVtb25zdHJhdGVkIHRoZSB2YWx1ZSBvZiB5b3VyIHByb3Bvc2FsIG90 aGVyIHRoYW4gbWFraW5nIHRoZSBzcGVjIHNob3J0ZXIuIFRoZSBkZXBsb3ltZW50IHJlcXVpcmVt ZW50IHlvdSBhcmUgcHJvcG9zaW5nIChvcmRlciBvZiBhdXRoIGhlYWRlcnMsIHN0cnVjdHVyZSBv ZiB0b2tlbnMsIGR1cGxpY2F0aW9uIG9mIHJlc291cmNlIFVSSSBiYXNlZCBvbiBhY2Nlc3MgdHlw ZSkgd2hpbGUgcG9zc2libGUsIHRha2UgYXdheSBhbnkgdmFsdWUgaW4gcmV1c2UgYW5kIGFyZSBn ZW5lcmFsbHkgdW5hY2NlcHRhYmxlIHRvIG1lLg0KDQpFSEwNCg0KDQoNCg0KDQo= From James.H.Manger@team.telstra.com Sat Oct 3 17:54:21 2009 Return-Path: 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 A68C23A688C for ; Sat, 3 Oct 2009 17:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 uZlKeqkvk5NB for ; Sat, 3 Oct 2009 17:54:21 -0700 (PDT) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 5EF1E3A68B9 for ; Sat, 3 Oct 2009 17:54:20 -0700 (PDT) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 04 Oct 2009 11:55:50 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 6579FFF83 for ; Sun, 4 Oct 2009 10:55:50 +1000 (EST) Received: from WSMSG3701.srv.dir.telstra.com (wsmsg3701.srv.dir.telstra.com [172.49.40.169]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA20395 for ; Sun, 4 Oct 2009 10:55:50 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sun, 4 Oct 2009 11:55:49 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Sun, 4 Oct 2009 11:55:47 +1100 Thread-Topic: realms Thread-Index: AcpERkHflHLMplkHRVWxLHZNJJrwXAAB721gAA9ub8A= Message-ID: <255B9BB34FB7D647A506DC292726F6E11245733153@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1124423C1E8@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2782@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2782@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11245733153WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] realms X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 00:54:21 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11245733153WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIHRoaW5rIHdlIHNob3VsZCBvcGVuIGFuIGlzc3VlICh1bmxlc3MgdGhlcmUgaXMgYWxyZWFk eSBvbmUpIHdpdGggSFRUUGJpcyBhYm91dCB0aGlzDQoNCj4gZ2l2ZW4gdGhlIGN1cnJlbnQgc3Rh dGUgb2YgUDcgYW5kIHRoZSBvcHBvcnR1bml0eSB0byBjbGFyaWZ5IHRoaXMuDQoNCg0KDQpPcGVu aW5nIGFuIEhUVFBiaXMgaXNzdWUgc291bmRzIG9rIC0tIHRob3VnaCBJIGFtIG5vdCBzdXJlIHdo aWNoIHNwZWNpZmljIGFzcGVjdHMgbmVlZCBjbGFyaWZ5aW5nIGFzIEkgYW0gbm90IGNlcnRhaW4g dGhhdCB0aGUgUkZDIDI2MTcgc3BlYyB0ZXh0IHdhcyB0aGUgKHJlYXNvbmFibHkgZGlyZWN0KSBz b3VyY2Ugb2YgdGhlIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5ncy4NCg0KDQoNCkphbWVzIE1hbmdl cg0KSmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJA dGVhbS50ZWxzdHJhLmNvbT4NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBU ZWNobm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0KDQoNCg0K --_000_255B9BB34FB7D647A506DC292726F6E11245733153WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHls ZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCnNwYW4uSGVhZGluZzJDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDIg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcg MiI7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglmb250LXdlaWdo dDpib2xkO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u Z3JleQ0KCXttc28tc3R5bGUtbmFtZTpncmV5O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5TZWN0 aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZndDsgSSB0aGluayB3ZSBzaG91bGQgb3BlbiBhbiBpc3N1ZSAodW5sZXNzIHRoZXJl IGlzIGFscmVhZHkgb25lKSB3aXRoIEhUVFBiaXMgYWJvdXQgdGhpczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jmd0OyBnaXZlbiB0aGUgY3VycmVudCBzdGF0ZSBvZiBQNyBhbmQgdGhlIG9w cG9ydHVuaXR5IHRvIGNsYXJpZnkgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPk9wZW5pbmcgYW4gSFRUUGJpcyBpc3N1ZSBzb3VuZHMgb2sgLS0gdGhvdWdoIEkgYW0g bm90IHN1cmUgd2hpY2ggc3BlY2lmaWMgYXNwZWN0cyBuZWVkIGNsYXJpZnlpbmcgYXMgSSBhbSBu b3QgY2VydGFpbiB0aGF0IHRoZSBSRkMgMjYxNyBzcGVjIHRleHQgd2FzIHRoZSAocmVhc29uYWJs eSBkaXJlY3QpIHNvdXJjZSBvZiB0aGUgZGlmZmVyZW50IHVuZGVyc3RhbmRpbmdzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PkphbWVzIE1hbmdlcjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6DQomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+DQo8YnI+DQo8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbSI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkphbWVz LkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L3NwYW4+PC9hPg0KPGJyPg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JZGVudGl0eSBhbmQgc2VjdXJp dHkgdGVhbTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsNCmZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7i gJQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4gQ2hpZWYg VGVjaG5vbG9neSBPZmZpY2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj7igJQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPiBUZWxzdHJhPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E11245733153WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Sat Oct 3 20:11:46 2009 Return-Path: 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 B222B3A67E7 for ; Sat, 3 Oct 2009 20:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 01LvEXFgue+a for ; Sat, 3 Oct 2009 20:11:46 -0700 (PDT) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id AB6B83A67A7 for ; Sat, 3 Oct 2009 20:11:44 -0700 (PDT) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 04 Oct 2009 14:13:15 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 3BA26FF82 for ; Sun, 4 Oct 2009 13:13:15 +1000 (EST) Received: from WSMSG3703.srv.dir.telstra.com (wsmsg3703.srv.dir.telstra.com [172.49.40.171]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 030E441D40 for ; Sun, 4 Oct 2009 13:12:59 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Sun, 4 Oct 2009 14:13:14 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Sun, 4 Oct 2009 14:13:13 +1100 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpC8Sw2Ny1WupCSSWSDuMgrgFIZNwABvj2gACbMNyAALML7UAAB85tQAA/PLTA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 03:11:46 -0000 PiBNeSBwb2ludCBpcyBvbmx5IHRoYXQgdGhlIGV4aXN0aW5nIGRlcGxveW1lbnQgb2YgQmFzaWMN Cj4gcHJldmVudHMgaXQgZnJvbSBiZWluZyB1c2VkIGluIHRoZSB3YXkgeW91IHByb3Bvc2VkIGJl Y2F1c2UNCj4gaXQgaXMgbW9yZSBsaWtlbHkgdG8gYnJlYWsgdGhpbmdzIGFuZCBkb2VzIG5vdCBv ZmZlciBhbnkgcmVhbCBiZW5lZml0DQo+IChvdGhlciB0aGFuIGEgdGhlb3JldGljYWwgY2xlYW5l ciBhcmNoaXRlY3R1cmUpLA0KPiBhbmQgbGVzcyB3b3JrIGZvciB0aGUgc3BlYyBlZGl0b3IuDQoN Cg0KT25lIHZlcnkgcmVhbCBiZW5lZml0IGlzIHRoYXQgZXN0YWJsaXNoZWQgYXV0aGVudGljYXRp b24gc2NoZW1lcywgc3VjaCBhcyBCQVNJQywgYXJlIGFscmVhZHkgc3VwcG9ydGVkIGJ5IGZyYW1l d29ya3MvbGlicmFyaWVzL3N5c3RlbXMvaW5mcmFzdHJ1Y3R1cmUvcGx1bWJpbmcuIEkgdGhpbmsg RXJhbiBzdGF0ZWQgdGhhdCBvbmUgYWltIG9mIHRoZSBjdXJyZW50IE9BdXRoIHdvcmsgd2FzIHRv IGdldCBPQXV0aCBzdXBwb3J0ZWQgaW4gdGhvc2UgY29udGV4dHMsIG5vdCBqdXN0IGFzIGFwcC1s YXllciBsaWJyYXJpZXMuDQoNCg0KQ29uc2lkZXIgYSBuZXR3b3JraW5nIGxpYnJhcnkgKGVnIGph dmEubmV0LlVSTENvbm5lY3Rpb24pIHRoYXQgYWRkcyBzdXBwb3J0IGZvciBUT0tFTiBYWFggV1dX LUF1dGggc2NoZW1lcyAoaW4gYWRkaXRpb24gdG8gZXhpc3Rpbmcgc3VwcG9ydCBmb3IgQkFTSUMg ZXRjKS4gVGhlIGxpYnJhcnkgaGFzIG5vIHdheSBvZiBrbm93aW5nIGlmIGEgY2FsbGVyIGlzIG1h a2luZyBhIHJlcXVlc3QgaW4gYSAiZGlyZWN0IiBvciBhICJkZWxlZ2F0ZWQiIGNvbnRleHQgc28g aXQgaGFzIG5vIHdheSBvZiBrbm93aW5nIGlmIGl0IHNob3VsZCByZWFjdCB0byBCQVNJQyBvciBU T0tFTiBYWFguIEFsbCBpdCBjYW4gZG8gaXMgYXNrIHRoZSBjYWxsZXIgKGVnIHZpYSBhIGNhbGxl ci1zdXBwbGllZCBqYXZhLm5ldC5BdXRoZW50aWNhdG9yKSwgIkhhdmUgeW91IGdvdCBhIHVzZXJu YW1lL3Bhc3N3b3JkIGZvciB0aGlzIGFkZHJlc3MvcG9ydC9wcm90b2NvbC9yZWFsbS9zY2hlbWUi Pw0KDQpJZiBib3RoIGEgQkFTSUMgYW5kIGEgVE9LRU4gUExBSU4gV1dXLUF1dGggaGVhZGVyIGFy ZSBwcmVzZW50IGluIGEgNDAxIHJlc3BvbnNlLCBqYXZhLm5ldC5VUkxDb25uZWN0aW9uIHdpbGwg YXNrIGphdmEubmV0LkF1dGhlbnRpY2F0b3IgYWJvdXQgYm90aCBpbiB0dXJuIChwcm9iYWJseSBp biB0aGUgb3JkZXIgdGhleSBhcHBlYXIpIHVudGlsIGl0IGdldHMgc29tZSBjcmVkZW50aWFscy4g VGhlIHByb2Nlc3MgaXMgdGhlIHNhbWUgaWYgdHdvIEJBU0lDIGhlYWRlcnMgYXJlIHByZXNlbnQg LS0gaXQgYXNrcyBhYm91dCBib3RoIHVudGlsIGl0IGdldHMgYW4gYW5zd2VyLiBJZiBCQVNJQyBh bmQgTUFDIChUT0tFTiBITUFDKSBoZWFkZXJzIGFyZSBwcmVzZW50IGl0IG1pZ2h0IGFzayBhYm91 dCB0aGUgTUFDIGhlYWRlciBmaXJzdCBhcyBpdCBpcyB0aGUgc3Ryb25nZXIgYWxnb3JpdGhtLiAg W1AuUy4gSSBhc3N1bWUgdGhpcyBpcyBob3cgSmF2YSB3b3JrcywgYnV0IEkgaGF2ZW4ndCBjb25m aXJtZWQgYWxsIHRoZSBkZXRhaWxzIHlldF0NCg0KDQoNCj4gRGlyZWN0IGFjY2VzcyBieSBjbGll bnRzIGRvZXMgd29yayB3ZWxsIHdpdGggZXhpc3RpbmcgdXNlcm5hbWUtYmFzZWQgc2NoZW1lcw0K PiBiZWNhdXNlIHRoYXQncyB3aGF0IGl0IGlzIC0gZGlyZWN0IGFjY2Vzcy4NCj4gV2UgaGF2ZSB0 d28gZGlzdGluY3QgY2FzZXM6IGRpcmVjdCBhY2Nlc3MgYW5kIGRlbGVnYXRlZCBhY2Nlc3MuDQo+ IFRoZSBpc3N1ZSBpcyB0byBoYXZlIGJvdGggZGlyZWN0IGFjY2VzcyBhbmQgZGVsZWdhdGVkIGFj Y2VzcyBjb2V4aXN0IG9uIHRoZSBzYW1lIHJlc291cmNlLg0KDQpJIGRvbid0IHRoaW5rIHRoaXMg ZGl2aWRlIHdvcmtzLg0KUGVvcGxlIGhhdmUgbWFkZSBsb3RzIG9mIHVzZSBvZiB0aGUgT0F1dGgg MS4wIHJlcXVlc3Qgc2lnbmluZyBtZWNoYW5pc20gZm9yIGRlbGVnYXRlZCBhY2Nlc3MgYW5kIGZv ciAiMi1sZWdnZWQiIGRpcmVjdCBhY2Nlc3MuDQpJZiBUT0tFTiBITUFDIGlzIG5vdCB1c2FibGUg Zm9yICIyLWxlZ2dlZCIgZGlyZWN0IGFjY2VzcyB0aGVuIGl0IG1pc3NlcyBoYWxmIHRoZSBwcm92 ZW4gdXNlIGNhc2VzLg0KSXMgcmVtb3Zpbmcgc3VwcG9ydCBmb3IgIjItbGVnZ2VkIiByZXF1ZXN0 IHNpZ25pbmcgaW50ZW50aW9uYWw/DQoNCg0KDQpKYW1lcyBNYW5nZXINCkphbWVzLkguTWFuZ2Vy QHRlYW0udGVsc3RyYS5jb20NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBU ZWNobm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0KDQo= From eran@hueniverse.com Sat Oct 3 22:44:25 2009 Return-Path: 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 EC7713A67E2 for ; Sat, 3 Oct 2009 22:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599] 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 KZJYhWDvB0YD for ; Sat, 3 Oct 2009 22:44:24 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D69323A67AA for ; Sat, 3 Oct 2009 22:44:24 -0700 (PDT) Received: (qmail 1964 invoked from network); 4 Oct 2009 05:45:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Oct 2009 05:45:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 3 Oct 2009 22:45:55 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Sat, 3 Oct 2009 22:46:17 -0700 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpC8Sw2Ny1WupCSSWSDuMgrgFIZNwABvj2gACbMNyAALML7UAAB85tQAA/PLTAACU+JEA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 05:44:26 -0000 KioqIEl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgb3RoZXIgcGVvcGxlIGNoaW1lIGluIG9uIHRoaXMg dG9waWMuIFRoaXMgaXMgYSBjcml0aWNhbCBkZWNpc2lvbiB3ZSBuZWVkIHRvIG1ha2UgcmVnYXJk aW5nIG5ldyBzY2hlbWVzLiBPbmUgcHJvcG9zYWwgaXMgdG8gaGF2ZSBkaWZmZXJlbnQgc2NoZW1l IGZvciBkaWZmZXJlbnQgdHlwZSBvZiBhY2Nlc3MgKGRpcmVjdCB2cy4gZGVsZWdhdGVkKS4gQW5v dGhlciBpcyB0byByZXVzaW5nIGV4aXN0aW5nIHNjaGVtZSAod2l0aCBhIG5ldyBNQUMtYmFzZWQg b25lKSBmb3IgYm90aCB1c2VybmFtZXMgYW5kIHRva2VucywgYW5kIGRpZmZlcmVudGlhdGluZyB0 aGVtIG9uIHRoZSBzZXJ2ZXIgc2lkZSB1c2luZyB0aGUgY3JlZGVudGlhbCBzdHJ1Y3R1cmUgKHRv a2VuIG9yIHVzZXJuYW1lKSBhbmQgb24gdGhlIGNsaWVudCBzaWRlIHVzaW5nIHRoZSByZWFsbSBw YXJhbWV0ZXIgKGFuZCB0aGUgaGVhZGVyIG9yZGVyKS4gT2YgY291cnNlLCB0aGVyZSBhcmUgcHJv YmFibHkgb3RoZXIgcHJvcG9zYWxzIGNvbWluZy4gKioqDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBNYW5nZXIsIEphbWVzIEgNCj4gU2VudDog U2F0dXJkYXksIE9jdG9iZXIgMDMsIDIwMDkgODoxMyBQTQ0KPiBUbzogb2F1dGhAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUHJvcG9zYWwgZm9yIGEgTmV3IDI2MTcgU2NoZW1l OiBUb2tlbg0KPiANCj4gPiBNeSBwb2ludCBpcyBvbmx5IHRoYXQgdGhlIGV4aXN0aW5nIGRlcGxv eW1lbnQgb2YgQmFzaWMNCj4gPiBwcmV2ZW50cyBpdCBmcm9tIGJlaW5nIHVzZWQgaW4gdGhlIHdh eSB5b3UgcHJvcG9zZWQgYmVjYXVzZQ0KPiA+IGl0IGlzIG1vcmUgbGlrZWx5IHRvIGJyZWFrIHRo aW5ncyBhbmQgZG9lcyBub3Qgb2ZmZXIgYW55IHJlYWwgYmVuZWZpdA0KPiA+IChvdGhlciB0aGFu IGEgdGhlb3JldGljYWwgY2xlYW5lciBhcmNoaXRlY3R1cmUpLA0KPiA+IGFuZCBsZXNzIHdvcmsg Zm9yIHRoZSBzcGVjIGVkaXRvci4NCj4gDQo+IA0KPiBPbmUgdmVyeSByZWFsIGJlbmVmaXQgaXMg dGhhdCBlc3RhYmxpc2hlZCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzLCBzdWNoDQo+IGFzIEJBU0lD LCBhcmUgYWxyZWFkeSBzdXBwb3J0ZWQgYnkNCj4gZnJhbWV3b3Jrcy9saWJyYXJpZXMvc3lzdGVt cy9pbmZyYXN0cnVjdHVyZS9wbHVtYmluZy4gSSB0aGluayBFcmFuDQo+IHN0YXRlZCB0aGF0IG9u ZSBhaW0gb2YgdGhlIGN1cnJlbnQgT0F1dGggd29yayB3YXMgdG8gZ2V0IE9BdXRoDQo+IHN1cHBv cnRlZCBpbiB0aG9zZSBjb250ZXh0cywgbm90IGp1c3QgYXMgYXBwLWxheWVyIGxpYnJhcmllcy4N Cg0KKG5vdCBzdXJlIHdoeSB5b3UgYXJlIHRhbGtpbmcgcGFzdCBtZS4uLikNCg0KVGhlIGV4aXN0 aW5nIHN1cHBvcnQgZm9yIEJhc2ljIGlzIG5vdCBnb2luZyB0byBtYWtlIGEgYmlnIGRpZmZlcmVu Y2UgYmVjYXVzZSB0aGUgZ29hbCBpcyB0byBnZXQgdGhlIG5ldyBhdXRoZW50aWNhdGlvbiBzY2hl bWUgKHRoZSBvbmUgdGhhdCB3b3JrcyB3aXRob3V0IFNTTCkgZGVwbG95ZWQuIEFyZSB5b3Ugc3Vn Z2VzdGluZyB0aGF0IHJldXNpbmcgQmFzaWMgaXMgdGhlIHdheSB0byBnZXQgdHJhbnNwb3J0LWxh eWVyIHN1cHBvcnQ/IFRoYXQgZG9lc24ndCBnZXQgdXMgbXVjaC4NCg0KPiBDb25zaWRlciBhIG5l dHdvcmtpbmcgbGlicmFyeSAoZWcgamF2YS5uZXQuVVJMQ29ubmVjdGlvbikgdGhhdCBhZGRzDQo+ IHN1cHBvcnQgZm9yIFRPS0VOIFhYWCBXV1ctQXV0aCBzY2hlbWVzIChpbiBhZGRpdGlvbiB0byBl eGlzdGluZyBzdXBwb3J0DQo+IGZvciBCQVNJQyBldGMpLiBUaGUgbGlicmFyeSBoYXMgbm8gd2F5 IG9mIGtub3dpbmcgaWYgYSBjYWxsZXIgaXMgbWFraW5nDQo+IGEgcmVxdWVzdCBpbiBhICJkaXJl Y3QiIG9yIGEgImRlbGVnYXRlZCIgY29udGV4dCBzbyBpdCBoYXMgbm8gd2F5IG9mDQo+IGtub3dp bmcgaWYgaXQgc2hvdWxkIHJlYWN0IHRvIEJBU0lDIG9yIFRPS0VOIFhYWC4gQWxsIGl0IGNhbiBk byBpcyBhc2sNCj4gdGhlIGNhbGxlciAoZWcgdmlhIGEgY2FsbGVyLXN1cHBsaWVkIGphdmEubmV0 LkF1dGhlbnRpY2F0b3IpLCAiSGF2ZSB5b3UNCj4gZ290IGEgdXNlcm5hbWUvcGFzc3dvcmQgZm9y IHRoaXMgYWRkcmVzcy9wb3J0L3Byb3RvY29sL3JlYWxtL3NjaGVtZSI/DQo+IA0KPiBJZiBib3Ro IGEgQkFTSUMgYW5kIGEgVE9LRU4gUExBSU4gV1dXLUF1dGggaGVhZGVyIGFyZSBwcmVzZW50IGlu IGEgNDAxDQo+IHJlc3BvbnNlLCBqYXZhLm5ldC5VUkxDb25uZWN0aW9uIHdpbGwgYXNrIGphdmEu bmV0LkF1dGhlbnRpY2F0b3IgYWJvdXQNCj4gYm90aCBpbiB0dXJuIChwcm9iYWJseSBpbiB0aGUg b3JkZXIgdGhleSBhcHBlYXIpIHVudGlsIGl0IGdldHMgc29tZQ0KPiBjcmVkZW50aWFscy4gVGhl IHByb2Nlc3MgaXMgdGhlIHNhbWUgaWYgdHdvIEJBU0lDIGhlYWRlcnMgYXJlIHByZXNlbnQgLQ0K PiAtIGl0IGFza3MgYWJvdXQgYm90aCB1bnRpbCBpdCBnZXRzIGFuIGFuc3dlci4gSWYgQkFTSUMg YW5kIE1BQyAoVE9LRU4NCj4gSE1BQykgaGVhZGVycyBhcmUgcHJlc2VudCBpdCBtaWdodCBhc2sg YWJvdXQgdGhlIE1BQyBoZWFkZXIgZmlyc3QgYXMgaXQNCj4gaXMgdGhlIHN0cm9uZ2VyIGFsZ29y aXRobS4gIFtQLlMuIEkgYXNzdW1lIHRoaXMgaXMgaG93IEphdmEgd29ya3MsIGJ1dA0KPiBJIGhh dmVuJ3QgY29uZmlybWVkIGFsbCB0aGUgZGV0YWlscyB5ZXRdDQoNClRoZSBwcm9ibGVtIHdpdGgg dGhpcyBmbG93IGlzIHRoYXQgaXQgZG9lc24ndCBhY2NvdW50IGZvciBhIG5ldywgbm9uLXVzZXJu YW1lIGJhc2VkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4gVGhlIG9ubHkgd2F5IHRoaXMgY2FuIHdv cmsgd2l0aCB5b3VyIHByb3Bvc2FsIGlzIGJ5IHVzaW5nIHRoZSByZWFsbSBhcyB0aGUgb25seSBk aWZmZXJlbnRpYXRvciBiZXR3ZWVuIHVzZXJuYW1lcyBhbmQgdG9rZW5zLiBJIHRoaW5rIHRoaXMg aXMgYW4gYWJ1c2Ugb2YgdGhlIHJlYWxtIHBhcmFtZXRlciBhbmQgZ2l2ZW4gYWxsIHRoZSBvdGhl ciBwcm9ibGVtcyB3ZSBoYXZlIHdpdGggZGVmaW5pbmcgcmVhbG0sIGlzIGp1c3QgYXNraW5nIGZv ciBwcm9ibGVtcy4NCiANCj4gPiBEaXJlY3QgYWNjZXNzIGJ5IGNsaWVudHMgZG9lcyB3b3JrIHdl bGwgd2l0aCBleGlzdGluZyB1c2VybmFtZS1iYXNlZA0KPiBzY2hlbWVzDQo+ID4gYmVjYXVzZSB0 aGF0J3Mgd2hhdCBpdCBpcyAtIGRpcmVjdCBhY2Nlc3MuDQo+ID4gV2UgaGF2ZSB0d28gZGlzdGlu Y3QgY2FzZXM6IGRpcmVjdCBhY2Nlc3MgYW5kIGRlbGVnYXRlZCBhY2Nlc3MuDQo+ID4gVGhlIGlz c3VlIGlzIHRvIGhhdmUgYm90aCBkaXJlY3QgYWNjZXNzIGFuZCBkZWxlZ2F0ZWQgYWNjZXNzIGNv ZXhpc3QNCj4gb24gdGhlIHNhbWUgcmVzb3VyY2UuDQo+IA0KPiBJIGRvbid0IHRoaW5rIHRoaXMg ZGl2aWRlIHdvcmtzLg0KPiBQZW9wbGUgaGF2ZSBtYWRlIGxvdHMgb2YgdXNlIG9mIHRoZSBPQXV0 aCAxLjAgcmVxdWVzdCBzaWduaW5nIG1lY2hhbmlzbQ0KPiBmb3IgZGVsZWdhdGVkIGFjY2VzcyBh bmQgZm9yICIyLWxlZ2dlZCIgZGlyZWN0IGFjY2Vzcy4NCj4gSWYgVE9LRU4gSE1BQyBpcyBub3Qg dXNhYmxlIGZvciAiMi1sZWdnZWQiIGRpcmVjdCBhY2Nlc3MgdGhlbiBpdCBtaXNzZXMNCj4gaGFs ZiB0aGUgcHJvdmVuIHVzZSBjYXNlcy4NCj4gSXMgcmVtb3Zpbmcgc3VwcG9ydCBmb3IgIjItbGVn Z2VkIiByZXF1ZXN0IHNpZ25pbmcgaW50ZW50aW9uYWw/DQoNClJlbW92aW5nIHN1cHBvcnQgZm9y ICIyLWxlZ2dlZCIgd2FzIGludGVudGlvbmFsIGluIG15IHByb3Bvc2FsIG9ubHkgaW4gdGhlIHNl bnNlIHRoYXQgaXQgaXMgc29tZXRoaW5nIHdlIHNob3VsZCBmaWd1cmUgb3V0IHNlcGFyYXRlbHku IE91ciBjaGFydGVyIGFsbG93cyB1cyB0byBkZWZpbmUgYSBuZXcgYXV0aGVudGljYXRpb24gbWV0 aG9kIGZvciBIVFRQIHRoYXQgaXMgdXNlZnVsIGJleW9uZCB0aGUgZGVsZWdhdGlvbiB1c2UgY2Fz ZS4gSG93ZXZlciwgdGhlIGN1cnJlbnQgd2F5IHBlb3BsZSBhcmUgdXNpbmcgT0F1dGggMS4wIGZv ciBkaXJlY3QgYWNjZXNzIGlzIG1peGVkLiBTb21lIHVzZSB0aGUgY2xpZW50IGNyZWRlbnRpYWxz IGFzIHVzZXJuYW1lL3Bhc3N3b3JkLCBvbWl0dGluZyB0aGUgdG9rZW4uIE90aGVycyBnaXZlIGNs aWVudHMgc3BlY2lhbCB0b2tlbnMgdG8gdXNlIHdpdGggQVBJIGNhbGxzIHRoYXQgZG8gbm90IGhh dmUgYSB1c2VyIGNvbnRleHQuDQoNClRoZXJlIGFyZSBtYW55IHdheXMgdG8gdGFrZSB3aGF0ZXZl ciBuZXcgYXV0aCBzY2hlbWUgd2UgY29tZSB1cCB3aXRoIGFuZCBlbmFibGUgaXQgZm9yIHRoZSBu b24tZGVsZWdhdGVkIHVzZSBjYXNlLiBCdXQgZ2l2ZW4gdGhpcyBpcyBhIHNlY29uZGFyeSBnb2Fs LCBJIHdvdWxkIGxpa2UgdG8gZmlyc3QgY29tZSB1cCB3aXRoIHRoZSBiZXN0IGF1dGhlbnRpY2F0 aW9uIHNjaGVtZSB3ZSBjYW4gZm9yIGRlbGVnYXRpb24gYW5kIHRoZW4gcmV2aWV3IGl0IGZvciB0 aGUgMi1sZWdnZWQgdXNlIGNhc2VzLiBFaXRoZXIgd2F5LCB0aGVyZSBpcyBubyByZXF1aXJlbWVu dCBmb3IgdXMgdG8gZGVmaW5lIGEgc2luZ2xlIGF1dGggc2NoZW1lLiBXZSBjYW4gZGVmaW5lIHR3 byBzY2hlbWVzIHdpdGggaWRlbnRpY2FsIHN5bnRheCBidXQgZGlmZmVyZW50IG5hbWVzLCBvbmUg Zm9yIGRlbGVnYXRpb24gYW5kIGFub3RoZXIgZm9yIHVzZXJuYW1lcyAoanVzdCBvbmUgb2YgbWFu eSB3YXlzIHRvIGFkZHJlc3MgdGhpcykuDQoNCkJUVywgT0F1dGggaXMgYmVpbmcgdXNlZCBpbiBt YW55IHVuZXhwZWN0ZWQgd2F5cyBhbGwgb2Ygd2hpY2ggYXJlIG9mIGxpdHRsZSBpbnRlcmVzdCB0 byB1cy4gV2UgYXJlIG5vdCB0cnlpbmcgdG8gbWFpbnRhaW4gZXZlcnkgcG9zc2libGUgdXNlIGNh c2Ugc29tZW9uZSBmb3VuZCBmb3IgMS4wLg0KDQpFSEwNCg0KDQo= From dan.winship@gmail.com Sun Oct 4 07:10:26 2009 Return-Path: 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 892433A67FD for ; Sun, 4 Oct 2009 07:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 km73++JXHiyc for ; Sun, 4 Oct 2009 07:10:23 -0700 (PDT) Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id F16033A67F4 for ; Sun, 4 Oct 2009 07:10:22 -0700 (PDT) Received: from desktop.home.mysterion.org (c-76-97-71-164.hsd1.ga.comcast.net [76.97.71.164]) by mysterion.org (Postfix) with ESMTPA id EE008802AE; Sun, 4 Oct 2009 10:11:54 -0400 (EDT) Message-ID: <4AC8AD25.3010801@gmail.com> Date: Sun, 04 Oct 2009 10:11:49 -0400 From: Dan Winship User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E1124423C1E8@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124423C1E8@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] realms X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 14:10:26 -0000 On 10/03/2009 12:26 PM, Manger, James H wrote: > The only defined operation with a realm is to compare the realm values > from different 401 responses from the same origin (scheme/host/port). Although it's not really a "defined" operation, realms are also often used in the UI by web browsers when presenting the password dialog; "The web site has requested a password for '$realm'" or something. > Once a client has learnt the realm for one resource it is reasonable to > assume any sub-resource has the same realm. This is not generically true, it's just something Basic and Digest both explicitly add to the generic realm semantics. If it was convenient for OAuth, you could say that the 401 response applies only to the exact URI that it was returned from, and user agents should not attempt to reuse the same authentication for any other URIs. Or you could do something like Digest's "domain" parameter, giving an explicit list of other URIs where the same auth can be reused. -- Dan From beaton@google.com Sun Oct 4 12:51:14 2009 Return-Path: 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 ECD0428C0DC for ; Sun, 4 Oct 2009 12:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hOnhTuahmOD0 for ; Sun, 4 Oct 2009 12:51:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id A022C3A6782 for ; Sun, 4 Oct 2009 12:51:13 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id n94Jqjx1024666 for ; Sun, 4 Oct 2009 12:52:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254685966; bh=PG3aOmpVaEh+fD+NibMvia5iqPA=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=n WYQTjmLYTMuMDSiV1iUUzQo9mOhLgI1j3+3pwtgvy+XIADq6gLvQVsR4oesNNR2T5Mb CufgSAmZmcgOi8qlVA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=CcI1weCjxIltZg3Y31212Yhnls8K1U+gLkrb1W5JlRiXXklmh9S/EZ9j0UyTzn+yg +Csg0Xyo78rh5KMAVE3/w== Received: from pxi40 (pxi40.prod.google.com [10.243.27.40]) by wpaz9.hot.corp.google.com with ESMTP id n94JqhSR023865 for ; Sun, 4 Oct 2009 12:52:43 -0700 Received: by pxi40 with SMTP id 40so2643445pxi.24 for ; Sun, 04 Oct 2009 12:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.121.3 with SMTP id t3mr496379wfc.246.1254685962671; Sun, 04 Oct 2009 12:52:42 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 4 Oct 2009 12:52:42 -0700 Message-ID: From: Brian Eaton To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 19:51:15 -0000 On Sat, Oct 3, 2009 at 8:13 PM, Manger, James H wrote: > One very real benefit is that established authentication schemes, such as BASIC > are already supported by frameworks/libraries/systems/infrastructure/plumbing. > I think Eran stated that one aim of the current OAuth work was to get OAuth > supported in those contexts, not just as app-layer libraries. > > Consider a networking library (eg java.net.URLConnection) that adds support for > TOKEN XXX WWW-Auth schemes (in addition to existing support for BASIC etc). The > library has no way of knowing if a caller is making a request in a "direct" or a > "delegated" context so it has no way of knowing if it should react to BASIC or TOKEN XXX. > All it can do is ask the caller (eg via a caller-supplied java.net.Authenticator), > "Have you got a username/password for this address/port/protocol/realm/scheme"? Almost nobody writes code that actually works this way today. In general applications know exactly what kind of authentication they are going to provide for a particular resource, and add it in a priori. Automatically figuring out that a particular resource requires a particular credential from a particular authority is tantamount to magic. I don't think we should guide the spec based on the assumption that someone is going to figure out how to do it. I'd prefer to assume that OAuth authentication starts after application code has figured out it is necessary and provided the necessary bootstrapping. Cheers, Brian From beaton@google.com Sun Oct 4 13:23:27 2009 Return-Path: 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 448993A693B for ; Sun, 4 Oct 2009 13:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Fuv5Rfhh9Y1Q for ; Sun, 4 Oct 2009 13:23:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 0E89D28C0F0 for ; Sun, 4 Oct 2009 13:23:25 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id n94KOt9u029317 for ; Sun, 4 Oct 2009 21:24:56 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254687896; bh=qK3tusCkC77QqtFty0GtTaoQYio=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=O 0xTpJb5iFRe3/pfcmeF7Oqs2IJvNPh5W5P+NJMMWBUKt+Qix/m3w5V4LLnVe7IcW/o0 UQFI0bSR4VrqorRJpQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=GfIKmzODbL87/qYxqguszwkoUOvjewI6SIpI29ICC20yH6J5AgpauyZv7Ak88Q7Wf QBq5bGyhur1oF9RlWZwgg== Received: from pxi13 (pxi13.prod.google.com [10.243.27.13]) by wpaz37.hot.corp.google.com with ESMTP id n94KOqMW000715 for ; Sun, 4 Oct 2009 13:24:53 -0700 Received: by pxi13 with SMTP id 13so2531209pxi.6 for ; Sun, 04 Oct 2009 13:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.25.40 with SMTP id c40mr545436wfj.265.1254687891960; Sun, 04 Oct 2009 13:24:51 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 4 Oct 2009 13:24:51 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 20:23:27 -0000 On Sat, Oct 3, 2009 at 10:46 PM, Eran Hammer-Lahav wrote: > *** It would be helpful if other people chime in on this topic. This is a > critical decision we need to make regarding new schemes. One proposal > is to have different scheme for different type of access (direct vs. delegated). > Another is to reusing existing scheme (with a new MAC-based one) for both > usernames and tokens, and differentiating them on the server side using the > credential structure (token or username) and on the client side using the > realm parameter (and the header order). Of course, there are probably other > proposals coming. *** Here's how I'd divvy up the work. 1) Come up with some core set of mechanisms for authenticating a single data request. 2) Make sure that those mechanisms are extensible, so that we can add new cryptographic tools as necessary later. 3) Define protocol flows for combining them to cover things like two-legged OAuth to authenticate calling applications, three-legged OAuth, OAuth with assertions about both the identity of the calling application and the user, etc... For example, two-legged OAuth might look like this: - send consumer key and secret to token issuing endpoint - get back session token - send session token to data endpoint - session token expires periodically, needs to be renewed Three-legged OAuth might look like this: - send consumer key, consumer secret, and access token to token issuing endpoint - get back session token - send session token to data endpoint - session token expires periodically, needs to be renewed When someone invents something New and Complicated, the complexity would get pushed to the token issuing endpoint like so: - send New and Complicated stuff to token issuing endpoint - get back session token - send session token to data endpoint - session token expires periodically, needs to be renewed Cheers, Brian From richard.barnes@gmail.com Sun Oct 4 17:00:35 2009 Return-Path: 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 8D72F3A677D for ; Sun, 4 Oct 2009 17:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599] 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 jr7Sv125dxI0 for ; Sun, 4 Oct 2009 17:00:34 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 665383A6359 for ; Sun, 4 Oct 2009 17:00:34 -0700 (PDT) Received: by bwz6 with SMTP id 6so2146306bwz.37 for ; Sun, 04 Oct 2009 17:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q2sieYBLuhym4kP2t9zO68rxndDGUYy9oayMnblvxpU=; b=cPL3kqNbeG3rRi201WFVfF7bs9dUcEieiwdt5Oh16oQIcrAOKqNSqn0U3DINSU6DbK RnpcVfe2TDYO+UH3m0gtTL59I8y4wCmiTrA/GRyeQ9dj29WYb2GZ/L7c6hxXo8ISrpWK Xhw9eWjRMP3ZccgFXxBzoxubo1ExwKPFxbtNA= 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:content-transfer-encoding; b=StFv1Uj5w5RvWFwy+6Zv5xjdeFZDMK2dRpD9mGtIFpHyVSsKq1W+OFi/sdW1R1zZDX QKeENYQf+olT0a5SP8vrpZQ0ZzjtEHMCbBlfomROlVxOUn0mk/wLJdYEzICNMvnm9m0w LopBW6NuSizwP5rKooNLuo+NchL2qLFa6R6p8= MIME-Version: 1.0 Received: by 10.204.34.201 with SMTP id m9mr3445622bkd.77.1254700924566; Sun, 04 Oct 2009 17:02:04 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112457333CD@WSMSG3153V.srv.dir.telstra.com> References: <42cffdb0-7d37-45a8-ba35-f9e99dba20a9@31g2000vbf.googlegroups.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2694@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0e7ee937-e8e3-4349-b7e2-8c364f9cc3ed@e4g2000prn.googlegroups.com> <95FF2A24-7413-44AB-8F4B-D52E55A512AF@jkemp.net> <88ac5c710910041636v7fa8b198p9b81b706bcf44f72@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112457333CD@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 5 Oct 2009 01:02:04 +0100 Message-ID: <88ac5c710910041702j412b15aco4586378dffe5a3a9@mail.gmail.com> From: Richard Barnes To: oauth@googlegroups.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 04 Oct 2009 18:11:39 -0700 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] Re: Need for timestamp and nonce over HTTPS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 00:00:35 -0000 Hey James, [copying IETF list since we're starting to get into protocol design stuff] > Is there really a requirement to make sure a Consumer can't hand off the = access token? It's a question security requirements, i.e., what attacks the SP is worried about, i.e., how strongly they want to protect their users' data. If they allow Consumers to hand off access tokens, then they're opening themselves up to Consumers that hand off tokens to bad people. > Of course, neither the Service nor the User can prevent the Consumer hand= ing off the access token and Consumer credentials to another party. That's true; the best a security protocol can ever do is reduce a problem to the security of keys. Usually this is enough, especially if keys are hard for the Consumer to replace (e.g., if they're tied to an expensive certificate). > I am particularly interested as I believe request signing would be signif= icantly improved if it only used the access token (and not the Consumer cre= dentials). The Consumer is implied as they were authenticated when the acce= ss token was issued. Again, it's a question of the SP's security requirements. IMHO, authenticating access requests makes for a more secure protocol with not much more cost (the credentials are already there, since Consumer already has to authenticate to the SP to get the request token). But YMMV. Maybe we need an "OAuth Security Requirements" draft? Or just a rev/clarification to draft-barnes-oauth-model? --Richard > > > James Manger > James.H.Manger@team.telstra.com > Identity and security team =97 Chief Technology Office =97 Telstra > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups= "OAuth" group. > To post to this group, send email to oauth@googlegroups.com > To unsubscribe from this group, send email to oauth+unsubscribe@googlegro= ups.com > For more options, visit this group at http://groups.google.com/group/oaut= h?hl=3Den > -~----------~----~----~----~------~----~------~--~--- > > From James.H.Manger@team.telstra.com Sun Oct 4 18:19:30 2009 Return-Path: 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 7AC213A6831 for ; Sun, 4 Oct 2009 18:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 LxnZwGyUH0O7 for ; Sun, 4 Oct 2009 18:19:29 -0700 (PDT) Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by core3.amsl.com (Postfix) with ESMTP id 66F663A67DF for ; Sun, 4 Oct 2009 18:19:29 -0700 (PDT) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipai.ntcif.telstra.com.au with ESMTP; 05 Oct 2009 12:21:02 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id CB823FF81 for ; Mon, 5 Oct 2009 11:21:01 +1000 (EST) Received: from wsmsg3757.srv.dir.telstra.com (wsmsg3757.srv.dir.telstra.com [172.49.40.85]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 41E6441D60 for ; Mon, 5 Oct 2009 11:20:46 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Mon, 5 Oct 2009 12:21:00 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Mon, 5 Oct 2009 12:20:59 +1100 Thread-Topic: [oauth] Re: Need for timestamp and nonce over HTTPS Thread-Index: AcpFTyL2PZ06k1aQTwG32mPpGqehaQACKP5A Message-ID: <255B9BB34FB7D647A506DC292726F6E11245733519@WSMSG3153V.srv.dir.telstra.com> References: <42cffdb0-7d37-45a8-ba35-f9e99dba20a9@31g2000vbf.googlegroups.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2694@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0e7ee937-e8e3-4349-b7e2-8c364f9cc3ed@e4g2000prn.googlegroups.com> <95FF2A24-7413-44AB-8F4B-D52E55A512AF@jkemp.net> <88ac5c710910041636v7fa8b198p9b81b706bcf44f72@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112457333CD@WSMSG3153V.srv.dir.telstra.com> <88ac5c710910041702j412b15aco4586378dffe5a3a9@mail.gmail.com> In-Reply-To: <88ac5c710910041702j412b15aco4586378dffe5a3a9@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 Subject: Re: [OAUTH-WG] [oauth] Re: Need for timestamp and nonce over HTTPS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 01:19:30 -0000 UmljaGFyZCwNCg0KPiBJTUhPLCBhdXRoZW50aWNhdGluZyBhY2Nlc3MgcmVxdWVzdHMgbWFrZXMg Zm9yIGEgbW9yZSBzZWN1cmUgcHJvdG9jb2wgd2l0aA0KPiBub3QgbXVjaCBtb3JlIGNvc3QgKHRo ZSBjcmVkZW50aWFscyBhcmUgYWxyZWFkeSB0aGVyZSwgc2luY2UgQ29uc3VtZXINCj4gYWxyZWFk eSBoYXMgdG8gYXV0aGVudGljYXRlIHRvIHRoZSBTUCB0byBnZXQgdGhlIHJlcXVlc3QgdG9rZW4p LiAgQnV0IFlNTVYuDQoNCg0KSSB3b3VsZCBwcmVmZXIgdGhlIGF1dGhlbnRpY2F0aW9uIFBST1RP Q09MKFMpIG9ubHkgdXNlZCB0aGUgYWNjZXNzIHRva2VuIHNlY3JldCAoYWZ0ZXIgdGhlIGRlbGVn YXRpb24gZmxvdykuIElmIGEgcGFydGljdWxhciBTZXJ2aWNlIHdhbnRzIHRvIGRpc2NvdXJhZ2Ug Q2xpZW50cyBmcm9tIGhhbmRpbmcgb2ZmIGFjY2VzcyB0b2tlbnMsIHRoYXQgU2VydmljZSBjYW4g ZGVsaWJlcmF0ZWx5IGluY2x1ZGUgdGhlIENsaWVudCdzIHNoYXJlZCBzZWNyZXQgYXMgcGFydCBv ZiB0aGUgYWNjZXNzIHRva2VuIHNlY3JldCAtLSBhbmQgdGVsbCB0aGUgQ2xpZW50cyB0aGlzLiBD b25zZXF1ZW50bHksIHNoYXJpbmcgYWNjZXNzIHRva2VucyBpcyBlcXVpdmFsZW50IHRvIHNoYXJp bmcgQ2xpZW50IGNyZWRlbnRpYWxzIGZvciB0aGF0IFNlcnZpY2UsIGJ1dCBDbGllbnRzIG9mIG90 aGVyIFNlcnZpY2VzIGFyZSBub3QgcmVzdHJpY3RlZCAtLSBhbmQgd2UgZG9uJ3QgbmVlZCBhbnkg ZXhwbGljaXQgb3B0aW9ucyAoY29tcGxleGl0eSkgaW4gdGhlIHNwZWMgZm9yIHRoaXMgZmVhdHVy ZS4NCg0KW1NlcnZpY2UgZG9jdW1lbnRhdGlvbiBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgdGhp cyAobm8gZGlzY292ZXJ5IG5lY2Vzc2FyeSksIGFzIGl0IGlzIGhhcmQgdG8gaW1hZ2luZSBhIENs aWVudCBkeW5hbWljYWxseSBkZWNpZGluZyB3aGV0aGVyIG9yIG5vdCB0byBoYW5kIG9mZiBhbiBh Y2Nlc3MgdG9rZW4uXQ0KDQoNCg0KSmFtZXMgTWFuZ2VyDQpKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tDQpJZGVudGl0eSBhbmQgc2VjdXJpdHkgdGVhbSDigJQgQ2hpZWYgVGVjaG5vbG9n eSBPZmZpY2Ug4oCUIFRlbHN0cmENCg0K From benl@google.com Sun Oct 4 19:49:30 2009 Return-Path: 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 32FEF3A68FB for ; Sun, 4 Oct 2009 19:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Hd7mey0wcXBO for ; Sun, 4 Oct 2009 19:49:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 301863A6824 for ; Sun, 4 Oct 2009 19:49:29 -0700 (PDT) Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id n952p1Vi015592 for ; Sun, 4 Oct 2009 19:51:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254711063; bh=kgcB8bmsRpD2Vtov3QOK2ihF7VY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=tD+kSyHizXIeNB11KN s7BN1GqtlfszFtVdXo/Fdli3YSoIVza7KN+BQEImws64CoDKfTqXxEiaZ5tbvXlmLuv Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=hwKEtRjpf21JXj+oKwchgHLyiCvpmHMwpl77j45BY/NpTlj2GUVBENfDaN+6yH+Xe aFuWPdoPsDeH2+iPcaUFA== Received: from bwz27 (bwz27.prod.google.com [10.188.26.27]) by spaceape13.eur.corp.google.com with ESMTP id n952owhN022682 for ; Sun, 4 Oct 2009 19:50:59 -0700 Received: by bwz27 with SMTP id 27so2148884bwz.19 for ; Sun, 04 Oct 2009 19:50:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.168.131 with SMTP id k3mr453772hbe.101.1254711058173; Sun, 04 Oct 2009 19:50:58 -0700 (PDT) In-Reply-To: <88ac5c710910041702j412b15aco4586378dffe5a3a9@mail.gmail.com> References: <42cffdb0-7d37-45a8-ba35-f9e99dba20a9@31g2000vbf.googlegroups.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2694@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0e7ee937-e8e3-4349-b7e2-8c364f9cc3ed@e4g2000prn.googlegroups.com> <95FF2A24-7413-44AB-8F4B-D52E55A512AF@jkemp.net> <88ac5c710910041636v7fa8b198p9b81b706bcf44f72@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112457333CD@WSMSG3153V.srv.dir.telstra.com> <88ac5c710910041702j412b15aco4586378dffe5a3a9@mail.gmail.com> Date: Sun, 4 Oct 2009 19:50:58 -0700 Message-ID: <1b587cab0910041950se5c5f6dl10d407d1cffba1b2@mail.gmail.com> From: Ben Laurie To: oauth@googlegroups.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] Re: Need for timestamp and nonce over HTTPS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 02:49:30 -0000 On Sun, Oct 4, 2009 at 5:02 PM, Richard Barnes w= rote: > > Hey James, > > [copying IETF list since we're starting to get into protocol design stuff= ] > >> Is there really a requirement to make sure a Consumer can't hand off the= access token? > > It's a question security requirements, i.e., what attacks the SP is > worried about, i.e., how strongly they want to protect their users' > data. =A0If they allow Consumers to hand off access tokens, then they're > opening themselves up to Consumers that hand off tokens to bad people. Nothing can prevent a Consumer acting as a proxy for a third party. So, in practice, once you've given the access token to the Consumer, you've given him the ability to delegate - albeit painfully. Given that reality, it might make sense to formalise delegation, and allow a Consumer to generate a delegated token, perhaps with reduced authority, e.g. a read-only token from a read-write one, which he could then pass on to the third party. Presumably from the keeping-the-user-informed perspective, requiring the Consumer to go back to the SP would allow the SP to track (and revoke) delegations. > >> Of course, neither the Service nor the User can prevent the Consumer han= ding off the access token and Consumer credentials to another party. > > That's true; the best a security protocol can ever do is reduce a > problem to the security of keys. =A0Usually this is enough, especially > if keys are hard for the Consumer to replace (e.g., if they're tied to > an expensive certificate). Expensive certificates, I am told, are bought with stolen credit cards by the bad guys. So, they're free, pretty much, for the bad guys and expensive for the good guys. Which seems the wrong way round. >> I am particularly interested as I believe request signing would be signi= ficantly improved if it only used the access token (and not the Consumer cr= edentials). The Consumer is implied as they were authenticated when the acc= ess token was issued. > > Again, it's a question of the SP's security requirements. =A0IMHO, > authenticating access requests makes for a more secure protocol with > not much more cost (the credentials are already there, since Consumer > already has to authenticate to the SP to get the request token). =A0But > YMMV. =A0Maybe we need an "OAuth Security Requirements" draft? =A0Or just > a rev/clarification to draft-barnes-oauth-model? > > --Richard > > > >> >> >> James Manger >> James.H.Manger@team.telstra.com >> Identity and security team =97 Chief Technology Office =97 Telstra >> >> >> > >> > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups= "OAuth" group. > To post to this group, send email to oauth@googlegroups.com > To unsubscribe from this group, send email to oauth+unsubscribe@googlegro= ups.com > For more options, visit this group at http://groups.google.com/group/oaut= h?hl=3Den > -~----------~----~----~----~------~----~------~--~--- > > From eran@hueniverse.com Sun Oct 4 23:43:47 2009 Return-Path: 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 A36823A6839 for ; Sun, 4 Oct 2009 23:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599] 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 QVW-haXCuW45 for ; Sun, 4 Oct 2009 23:43:46 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B28663A67A7 for ; Sun, 4 Oct 2009 23:43:46 -0700 (PDT) Received: (qmail 4687 invoked from network); 5 Oct 2009 06:45:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Oct 2009 06:45:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 4 Oct 2009 23:45:18 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Sun, 4 Oct 2009 23:45:20 -0700 Thread-Topic: [oauth] Re: Need for timestamp and nonce over HTTPS Thread-Index: AcpFTyL2PZ06k1aQTwG32mPpGqehaQACKP5AAAuNG5A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF27D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <42cffdb0-7d37-45a8-ba35-f9e99dba20a9@31g2000vbf.googlegroups.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2694@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0e7ee937-e8e3-4349-b7e2-8c364f9cc3ed@e4g2000prn.googlegroups.com> <95FF2A24-7413-44AB-8F4B-D52E55A512AF@jkemp.net> <88ac5c710910041636v7fa8b198p9b81b706bcf44f72@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112457333CD@WSMSG3153V.srv.dir.telstra.com> <88ac5c710910041702j412b15aco4586378dffe5a3a9@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11245733519@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11245733519@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] [oauth] Re: Need for timestamp and nonce over HTTPS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 06:43:47 -0000 QXQgbGFzdCwgc29tZXRoaW5nIEphbWVzIGFuZCBJIGFncmVlIG9uIGNvbXBsZXRlbHkhDQoNClRo ZSBpZGVhIHRoYXQgdHdvIHNlY3JldHMgYXJlIGJldHRlciB0aGFuIG9uZSBpcyBzaWxseSBzaW5j ZSB0aGV5IGFyZSBib3RoIG5lZWRlZCBmb3IgZXZlcnkgc2lnbmVkIHJlcXVlc3QgYW5kIHRoZXJl Zm9yZSBtdXN0IGJlIHByZXNlbnQgaW4gYW55IGNsaWVudC9zZXJ2ZXIuIFRoZXJlIGlzIG5vdGhp bmcgdG8gc3RvcCBhIGNsaWVudCBmcm9tIHNoYXJpbmcgaXRzIGNyZWRlbnRpYWxzIHRvZ2V0aGVy IHdpdGggaXRzIHRva2VuL3NlY3JldCBwYWlyLg0KDQpVc2luZyBvbmx5IHRoZSB0b2tlbiBjcmVk ZW50aWFscyB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcyAoaS5lLiBubyBjbGllbnQgY3Jl ZGVudGlhbHMgd2hpY2ggYXJlIHVzZWQgb25seSB0byBnZXQgdGhlIHRva2VuIGluIHRoZSBmaXJz dCBwbGFjZSkgb2ZmZXJzIGEgdmFsdWFibGUgc2ltcGxpZmljYXRpb24gd2hpY2ggYnkgZGVmaW5p dGlvbiBpbXByb3ZlcyBzZWN1cml0eSAoY2xpZW50IGNyZWRlbnRpYWxzIGFyZSBubyBsb25nZXIg bmVlZGVkIGluIGV2ZXJ5IGNsaWVudCBhbmQgc2VydmVyIGFuZCBjYW4gYmUgc2FmZWd1YXJkIGp1 c3QgaW4gdGhlIHBhcnRzIHRoYXQgaXNzdWUgYW5kIHJlcXVlc3QgdG9rZW5zKS4NCg0KSSBhbSBn ZW5lcmFsbHkgc2tlcHRpY2FsIG9mIGFueSBwcm9wb3NhbCB0cnlpbmcgdG8gc29sdmUgcmUtZGVs ZWdhdGlvbiAoc28gY2FsbGVkIDR0aCBsZWdnZWQpIHRoYXQgaXMgb2ZmZXJpbmcgc2VjdXJpdHkg dXNpbmcgc29tZXRoaW5nIG90aGVyIHRoYW4gZXhwZW5zaXZlIGxhd3llcnMuIFdoZW4gYSB1c2Vy IGlzIGFza2VkIHRvIGFwcHJvdmUgYWNjZXNzIHRvIGEgdGhpcmQgcGFydHksIHRoZXkgc2hvdWxk IGJlIHByZXNlbnRlZCB3aXRoIGluZm9ybWF0aW9uIHRoYXQgd2lsbCBoZWxwIHRoZW0gbWFrZSBz bWFydCBkZWNpc2lvbnMuIFByb3ZpZGVycyBzaG91bGQgbWFrZSBzdXJlIHRoYXQgdGhlaXIgVE9T IHJlcXVpcmVzIGZ1bGwgZGlzY2xvc3VyZSBvZiBzdWNoIGFjdGl2aXRpZXMgb3IgZm9yYmlkIGl0 LiBUaGV5IHNob3VsZCB0aGVuIHVzZSB0aGVpciBsYXd5ZXJzIHRvIGdvIGFmdGVyIGNvbXBhbmll cyB0aGF0IG1lc3Mgd2l0aCB0aGVpciB1c2Vycy4NCg0KS2VlcCBpbiBtaW5kIHRoYXQgdGhlIHRo cmVhdHMgb2YgcmUtZGVsZWdhdGlvbiBhcmUgbm90IHNlY3VyaXR5IHJlbGF0ZWQgYnV0IHNpbXBs eSBhIG1hdHRlciBvZiB0cnVzdGluZyB0aGlyZCBwYXJ0aWVzIG5vdCB0byBiZSBzdHVwaWQgYWJv dXQgd2hhdCB0aGV5IGRvIHdpdGggb3VyIGRhdGEuIFRoZXJlIGlzIG5vIG5lZWQgZm9yIHJlLWRl bGVnYXRpb24gdG8gaHVydCBhIHVzZXIuLi4gYSBjbGllbnQgY2FuIGRvIGl0IGFsbCBvbiBpdHMg b3duLg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvYXV0 aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmDQo+IE9mIE1hbmdlciwgSmFtZXMgSA0KPiBTZW50OiBTdW5kYXksIE9jdG9iZXIgMDQsIDIw MDkgNjoyMSBQTQ0KPiBUbzogb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1X R10gW29hdXRoXSBSZTogTmVlZCBmb3IgdGltZXN0YW1wIGFuZCBub25jZSBvdmVyDQo+IEhUVFBT DQo+IA0KPiBSaWNoYXJkLA0KPiANCj4gPiBJTUhPLCBhdXRoZW50aWNhdGluZyBhY2Nlc3MgcmVx dWVzdHMgbWFrZXMgZm9yIGEgbW9yZSBzZWN1cmUgcHJvdG9jb2wNCj4gd2l0aA0KPiA+IG5vdCBt dWNoIG1vcmUgY29zdCAodGhlIGNyZWRlbnRpYWxzIGFyZSBhbHJlYWR5IHRoZXJlLCBzaW5jZSBD b25zdW1lcg0KPiA+IGFscmVhZHkgaGFzIHRvIGF1dGhlbnRpY2F0ZSB0byB0aGUgU1AgdG8gZ2V0 IHRoZSByZXF1ZXN0IHRva2VuKS4gIEJ1dA0KPiBZTU1WLg0KPiANCj4gDQo+IEkgd291bGQgcHJl ZmVyIHRoZSBhdXRoZW50aWNhdGlvbiBQUk9UT0NPTChTKSBvbmx5IHVzZWQgdGhlIGFjY2Vzcw0K PiB0b2tlbiBzZWNyZXQgKGFmdGVyIHRoZSBkZWxlZ2F0aW9uIGZsb3cpLiBJZiBhIHBhcnRpY3Vs YXIgU2VydmljZSB3YW50cw0KPiB0byBkaXNjb3VyYWdlIENsaWVudHMgZnJvbSBoYW5kaW5nIG9m ZiBhY2Nlc3MgdG9rZW5zLCB0aGF0IFNlcnZpY2UgY2FuDQo+IGRlbGliZXJhdGVseSBpbmNsdWRl IHRoZSBDbGllbnQncyBzaGFyZWQgc2VjcmV0IGFzIHBhcnQgb2YgdGhlIGFjY2Vzcw0KPiB0b2tl biBzZWNyZXQgLS0gYW5kIHRlbGwgdGhlIENsaWVudHMgdGhpcy4gQ29uc2VxdWVudGx5LCBzaGFy aW5nIGFjY2Vzcw0KPiB0b2tlbnMgaXMgZXF1aXZhbGVudCB0byBzaGFyaW5nIENsaWVudCBjcmVk ZW50aWFscyBmb3IgdGhhdCBTZXJ2aWNlLA0KPiBidXQgQ2xpZW50cyBvZiBvdGhlciBTZXJ2aWNl cyBhcmUgbm90IHJlc3RyaWN0ZWQgLS0gYW5kIHdlIGRvbid0IG5lZWQNCj4gYW55IGV4cGxpY2l0 IG9wdGlvbnMgKGNvbXBsZXhpdHkpIGluIHRoZSBzcGVjIGZvciB0aGlzIGZlYXR1cmUuDQo+IA0K PiBbU2VydmljZSBkb2N1bWVudGF0aW9uIHNob3VsZCBiZSBzdWZmaWNpZW50IGZvciB0aGlzIChu byBkaXNjb3ZlcnkNCj4gbmVjZXNzYXJ5KSwgYXMgaXQgaXMgaGFyZCB0byBpbWFnaW5lIGEgQ2xp ZW50IGR5bmFtaWNhbGx5IGRlY2lkaW5nDQo+IHdoZXRoZXIgb3Igbm90IHRvIGhhbmQgb2ZmIGFu IGFjY2VzcyB0b2tlbi5dDQo+IA0KPiANCj4gDQo+IEphbWVzIE1hbmdlcg0KPiBKYW1lcy5ILk1h bmdlckB0ZWFtLnRlbHN0cmEuY29tDQo+IElkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBD aGllZiBUZWNobm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg== From rbarnes@bbn.com Mon Oct 5 06:39:18 2009 Return-Path: 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 B06D328C1BE for ; Mon, 5 Oct 2009 06:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599] 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 9PAMR-pdcqUM for ; Mon, 5 Oct 2009 06:39:17 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B63E03A66B4 for ; Mon, 5 Oct 2009 06:39:17 -0700 (PDT) Received: from [128.89.253.232] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Mumrx-0006b0-EG; Mon, 05 Oct 2009 08:40:49 -0400 Message-ID: <4AC9F761.9060703@bbn.com> Date: Mon, 05 Oct 2009 14:40:49 +0100 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <42cffdb0-7d37-45a8-ba35-f9e99dba20a9@31g2000vbf.googlegroups.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2694@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0e7ee937-e8e3-4349-b7e2-8c364f9cc3ed@e4g2000prn.googlegroups.com> <95FF2A24-7413-44AB-8F4B-D52E55A512AF@jkemp.net> <88ac5c710910041636v7fa8b198p9b81b706bcf44f72@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112457333CD@WSMSG3153V.srv.dir.telstra.com> <88ac5c710910041702j412b15aco4586378dffe5a3a9@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11245733519@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF27D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF27D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [oauth] Re: Need for timestamp and nonce over HTTPS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 13:39:18 -0000 > The idea that two secrets are better than one is silly since they are > both needed for every signed request and therefore must be present in > any client/server. There is nothing to stop a client from sharing its > credentials together with its token/secret pair. No, there's nothing to stop it, but the incentives are way different for the two different types of credentials. The client credentials are supposed to be long-lived, and tightly bound to the Client's identity (switching to IETF terminology here). I think of identity certificates as the canonical example -- they last for O(years) and you use them to authenticated to multiple entities. If you give one of these away, you're giving up a lot; you're enabling the recipient to masquerade as you on a large scale. The token/secret pair is much, much lower-risk. You give up your token credentials and all you're allowing the recipient to do is access the delegated resources. > Using only the token credentials to access protected resources (i.e. > no client credentials which are used only to get the token in the > first place) offers a valuable simplification which by definition > improves security (client credentials are no longer needed in every > client and server and can be safeguard just in the parts that issue > and request tokens). This sounds like you're viewing Client hand-off of tokens as a requirement: Client's Delegation Agent does the OAuth dance to get the access token, then passes it off to the Client's Access Agent, who actually does the work. If there is a requirement to support that deployment pattern, then you're right that you can't require Client authentication on every access. But at the same time, you also can't prevent the Client from handing the token to some third party, so you'll have to document that risk. > Keep in mind that the threats of re-delegation are not security > related but simply a matter of trusting third parties not to be > stupid about what they do with our data. There is no need for > re-delegation to hurt a user... a client can do it all on its own. I agree, the question here is how much the third party Client is trusted. Authorizing someone to access to a resource and authorizing them to grant others authorization are two different things, though. So it comes down to what the scope is of an OAuth authorization: If the user only wants to allow the Client to access data, then the Server MUST authenticate the Client on access requests. If the user also allows re-delegation, then the Server MUST NOT authenticate the Client on access requests. It seems like what we need here is to say that Client authentication on access requests is a MUST implement / SHOULD use. Would that make sense? --Richard From beaton@google.com Mon Oct 5 11:47:26 2009 Return-Path: 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 137DF3A6A2B for ; Mon, 5 Oct 2009 11:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7P918sJIuvxp for ; Mon, 5 Oct 2009 11:47:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 9ACC13A6806 for ; Mon, 5 Oct 2009 11:47:24 -0700 (PDT) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n95Imvap013104 for ; Mon, 5 Oct 2009 19:48:58 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254768538; bh=C7f0rhT1hS8Yeij8/V4+dfXKgrY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=W L5LrJx/WDen8PPAd2NKo2FEXnF0Drg57GeAeiRS8m4+RKT9LdGWvQWV22Ut0vCWa76X 27wIfM8qLS23Zd0QXA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=DnQETeiEH6Vs4hgixiHXq2ClPMlLrD+PQ2oo5DoO5YIa0kXy/b9v0S/NfGAv6dp7q Cvk7WUVC5bMpN9hHlYS/g== Received: from pzk14 (pzk14.prod.google.com [10.243.19.142]) by zps19.corp.google.com with ESMTP id n95Ij666001859 for ; Mon, 5 Oct 2009 11:48:55 -0700 Received: by pzk14 with SMTP id 14so2203609pzk.23 for ; Mon, 05 Oct 2009 11:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.249.24 with SMTP id w24mr25512wfh.325.1254768535196; Mon, 05 Oct 2009 11:48:55 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 5 Oct 2009 11:48:55 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:47:26 -0000 On Sat, Oct 3, 2009 at 10:46 PM, Eran Hammer-Lahav wrote: > *** It would be helpful if other people chime in on this topic. This is a > critical decision we need to make regarding new schemes. One proposal > is to have different scheme for different type of access (direct vs. delegated). > Another is to reusing existing scheme (with a new MAC-based one) for both > usernames and tokens, and differentiating them on the server side using the > credential structure (token or username) and on the client side using the > realm parameter (and the header order). Of course, there are probably other > proposals coming. *** Eran points out that I've posted several times to this thread without actually answering the question he asked. =) I don't think we should use basic auth to send tokens. I'd rather see us use a new auth scheme. - basic auth has existing semantics for "realm". They aren't the same semantics we need for OAuth. - using the basic auth scheme would cripple our ability to add new signature methods. It is in theory possible to treat a token as a username and a token secret as a password, but I don't think it would be a particularly useful thing to do. If we want to use bearer tokens, we should just drop the token secret altogether. Cheers, Brian From eran@hueniverse.com Tue Oct 6 14:05:33 2009 Return-Path: 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 78C5C28C108 for ; Tue, 6 Oct 2009 14:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599] 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 Wvo+F-LPLjGf for ; Tue, 6 Oct 2009 14:05:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A6E7E28C104 for ; Tue, 6 Oct 2009 14:05:32 -0700 (PDT) Received: (qmail 13857 invoked from network); 6 Oct 2009 21:07:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Oct 2009 21:07:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Oct 2009 14:07:09 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Tue, 6 Oct 2009 14:07:17 -0700 Thread-Topic: Delegation (token) requests Thread-Index: AcpGyPx+nqStUl7LTPKk69K/zz9XdA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Delegation (token) requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 21:05:33 -0000 There are three well-defined methods for obtaining a token: 1. Web Delegation (2 steps) - user is redirected to the server, authorizes,= redirected back to client with token. 2. Web Delegation (3 steps) - client obtains temporary credentials, user au= thorizes at the server, client exchanges temporary credentials for token. 3. Direct Request - client uses the user's username and password to request= for a token. OAuth Core 1.0 supports the #2 option only. There is clear demand for the o= ther two methods. Many large providers I talked to would like to have #1 to get rid of the te= mporary credentials (request token). The vast majority of the temporary cre= dentials are never used and waste resources. The 3-steps flow was created t= o address clients which are unable to receive redirections and therefore ha= ve no way to get the token back from the server. Many developers have asked for #3 for cases where it is perfectly acceptabl= e for an application to have access to the user's credentials, but still pr= ovide a single OAuth-based API. This has been also raised in cases where op= ening a browser is poor or unacceptable user experience. When making a token request, the client may be required to authenticate its= elf (using its client credentials). The authentication method is either a s= hared secret or PK-based. When sending a token, the server should use a secure channel to ensure the = token credentials remain confidential. When using a shared-secret over a secure channel, there is no reason to sig= n the request and simply including the secret is enough. If a PK is used, t= he request has to be signed in some way even over a secure channel (because= there is nothing else to send with the request). Questions: - Are there use cases where the 3-step flow (#2) is needed? - Should we require use of HTTPS for token requests? - If it is ok for tokens to be sent unsecure, is it also ok to send client = secrets unsecure? - How should a PK option work? What should be signed? How should it work ov= er a secure channel? EHL From jpanzer@google.com Tue Oct 6 14:19:40 2009 Return-Path: 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 D63B428C12A for ; Tue, 6 Oct 2009 14:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 4067PotXpQC3 for ; Tue, 6 Oct 2009 14:19:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 7B56D3A681C for ; Tue, 6 Oct 2009 14:19:37 -0700 (PDT) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id n96LLDiR010743 for ; Tue, 6 Oct 2009 14:21:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254864073; bh=Oh28Umf+bkJLNBZCpJmDIzRlCvU=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=KXpVwo yRpI6Vnk+JNygx+cMbRhuJ4GyIwTcxnGAgN0M9xZy7AMDKJ8/TzM9g0Bpev1X0EBRZN TPjgW/+q0RvDw== 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=uXqiTnyfpqWODwz/QQSAmwWiSlmTiks+jWzqcvSVcDS/2dCKUyRqK6U5SWgwV2VzU ChIYVYfJ8RxKq2ddPoshQ== Received: from qw-out-2122.google.com (qwi5.prod.google.com [10.241.195.5]) by zps38.corp.google.com with ESMTP id n96LLAmV000869 for ; Tue, 6 Oct 2009 14:21:11 -0700 Received: by qw-out-2122.google.com with SMTP id 5so1412830qwi.5 for ; Tue, 06 Oct 2009 14:21:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.93.4 with SMTP id t4mr1214721qcm.93.1254864070505; Tue, 06 Oct 2009 14:21:10 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Tue, 6 Oct 2009 14:20:49 -0700 Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=000e0cd6b30a29f6b704754acf74 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 21:19:40 -0000 --000e0cd6b30a29f6b704754acf74 Content-Type: text/plain; charset=ISO-8859-1 I agree with beaton, but I have another argument against Basic auth. Unmodified client code and UIs will assume we're talking about regular username and password and use that terminology (and a separate realm would just confuse things). If they're modified to be OAuth aware this could be fixed, but if you assume OAuth aware code you can use a new auth scheme just as easily. And, it would be less confusing. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Oct 5, 2009 at 11:48 AM, Brian Eaton wrote: > On Sat, Oct 3, 2009 at 10:46 PM, Eran Hammer-Lahav > wrote: > > *** It would be helpful if other people chime in on this topic. This is a > > critical decision we need to make regarding new schemes. One proposal > > is to have different scheme for different type of access (direct vs. > delegated). > > Another is to reusing existing scheme (with a new MAC-based one) for both > > usernames and tokens, and differentiating them on the server side using > the > > credential structure (token or username) and on the client side using the > > realm parameter (and the header order). Of course, there are probably > other > > proposals coming. *** > > Eran points out that I've posted several times to this thread without > actually answering the question he asked. =) > > I don't think we should use basic auth to send tokens. I'd rather see > us use a new auth scheme. > > - basic auth has existing semantics for "realm". They aren't the same > semantics we need for OAuth. > - using the basic auth scheme would cripple our ability to add new > signature methods. > > It is in theory possible to treat a token as a username and a token > secret as a password, but I don't think it would be a particularly > useful thing to do. If we want to use bearer tokens, we should just > drop the token secret altogether. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd6b30a29f6b704754acf74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with beaton, but I have another argument against Basic auth.=A0 Unm= odified client code and UIs will assume we're talking about regular use= rname and password and use that terminology (and a separate realm would jus= t confuse things).=A0 If they're modified to be OAuth aware this could = be fixed, but if you assume OAuth aware code you can use a new auth scheme = just as easily.=A0 And, it would be less confusing.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org= / @jpanzer



On Mon, Oct 5, 2009 at 11:48 AM, Brian E= aton <beaton@goog= le.com> wrote:
On Sat, Oct 3, 2009 at 10:46 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> *** It would be helpful if other people chime in on this topic. This i= s a
> critical decision we need to make regarding new schemes. One proposal<= br> > is to have different scheme for different type of access (direct vs. d= elegated).
> Another is to reusing existing scheme (with a new MAC-based one) for b= oth
> usernames and tokens, and differentiating them on the server side usin= g the
> credential structure (token or username) and on the client side using = the
> realm parameter (and the header order). Of course, there are probably = other
> proposals coming. ***

Eran points out that I've posted several times to this thread wit= hout
actually answering the question he asked. =A0=3D)

I don't think we should use basic auth to send tokens. =A0I'd rathe= r see
us use a new auth scheme.

- basic auth has existing semantics for "realm". =A0They aren'= ;t the same
semantics we need for OAuth.
- using the basic auth scheme would cripple our ability to add new
signature methods.

It is in theory possible to treat a token as a username and a token
secret as a password, but I don't think it would be a particularly
useful thing to do. =A0If we want to use bearer tokens, we should just
drop the token secret altogether.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--000e0cd6b30a29f6b704754acf74-- From eran@hueniverse.com Tue Oct 6 14:35:01 2009 Return-Path: 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 A05BD3A6A0E for ; Tue, 6 Oct 2009 14:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, 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 H1rJMQ6aEfGs for ; Tue, 6 Oct 2009 14:35:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 30F493A6A10 for ; Tue, 6 Oct 2009 14:35:00 -0700 (PDT) Received: (qmail 21695 invoked from network); 6 Oct 2009 21:36:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Oct 2009 21:36:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Oct 2009 14:36:36 -0700 From: Eran Hammer-Lahav To: John Panzer , Brian Eaton Date: Tue, 6 Oct 2009 14:36:45 -0700 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpGyu+IMKYVD3MUTC6TWE1kI7XbdgAAcvmg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784ECD794@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343784ECD794P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 21:35:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784ECD794P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How do people feel about defining two (syntactically identical) schemes: De= legated and Direct. Both will use the same method(s) of making authenticated requests but Direc= t will mean use a username and password while Delegated will mean use a tok= en obtained from a delegation endpoint. Of course the other obvious option is to define a single scheme Token and a= dd a parameter but that is ugly. EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Tuesday, October 06, 2009 2:21 PM To: Brian Eaton Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token I agree with beaton, but I have another argument against Basic auth. Unmod= ified client code and UIs will assume we're talking about regular username = and password and use that terminology (and a separate realm would just conf= use things). If they're modified to be OAuth aware this could be fixed, bu= t if you assume OAuth aware code you can use a new auth scheme just as easi= ly. And, it would be less confusing. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Oct 5, 2009 at 11:48 AM, Brian Eaton > wrote: On Sat, Oct 3, 2009 at 10:46 PM, Eran Hammer-Lahav > wrote: > *** It would be helpful if other people chime in on this topic. This is a > critical decision we need to make regarding new schemes. One proposal > is to have different scheme for different type of access (direct vs. dele= gated). > Another is to reusing existing scheme (with a new MAC-based one) for both > usernames and tokens, and differentiating them on the server side using t= he > credential structure (token or username) and on the client side using the > realm parameter (and the header order). Of course, there are probably oth= er > proposals coming. *** Eran points out that I've posted several times to this thread without actually answering the question he asked. =3D) I don't think we should use basic auth to send tokens. I'd rather see us use a new auth scheme. - basic auth has existing semantics for "realm". They aren't the same semantics we need for OAuth. - using the basic auth scheme would cripple our ability to add new signature methods. It is in theory possible to treat a token as a username and a token secret as a password, but I don't think it would be a particularly useful thing to do. If we want to use bearer tokens, we should just drop the token secret altogether. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343784ECD794P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How do people feel about defining two (syntactically identic= al) schemes: Delegated and Direct.

 

Both will use the same method(s) of making authenticated requests but Direct will mean use a username and password while Delegated w= ill mean use a token obtained from a delegation endpoint.

 

Of course the other obvious option is to define a single sch= eme Token and add a parameter but that is ugly.

 

EHL

 

From: John Panzer [mailto:jpanzer@google.com]
Sent: Tuesday, October 06, 2009 2:21 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token

 

I agree with beaton, but I have another argument again= st Basic auth.  Unmodified client code and UIs will assume we're talking about regular username and password and use that terminology (and a separat= e realm would just confuse things).  If they're modified to be OAuth awa= re this could be fixed, but if you assume OAuth aware code you can use a new a= uth scheme just as easily.  And, it would be less confusing.

--
John Panzer / Google
jpanzer@google.com<= /a> / abstractioneer.or= g / @jpanzer



On Mon, Oct 5, 2009 at 11:48 AM, Brian Eaton <beaton@google.com> wrote:

On Sat, Oct 3, 2009 at = 10:46 PM, Eran Hammer-Lahav <eran@hueni= verse.com> wrote:
> *** It would be helpful if other people chime in on this topic. This i= s a
> critical decision we need to make regarding new schemes. One proposal<= br> > is to have different scheme for different type of access (direct vs. delegated).
> Another is to reusing existing scheme (with a new MAC-based one) for b= oth
> usernames and tokens, and differentiating them on the server side usin= g the
> credential structure (token or username) and on the client side using = the
> realm parameter (and the header order). Of course, there are probably other
> proposals coming. ***

Eran points out that I've posted several times to this thread without
actually answering the question he asked.  =3D)

I don't think we should use basic auth to send tokens.  I'd rather see=
us use a new auth scheme.

- basic auth has existing semantics for "realm".  They aren'= t the same
semantics we need for OAuth.
- using the basic auth scheme would cripple our ability to add new
signature methods.

It is in theory possible to treat a token as a username and a token
secret as a password, but I don't think it would be a particularly
useful thing to do.  If we want to use bearer tokens, we should just drop the token secret altogether.


Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

--_000_90C41DD21FB7C64BB94121FBBC2E72343784ECD794P3PW5EX1MB01E_-- From john@jkemp.net Tue Oct 6 18:14:15 2009 Return-Path: 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 A6FA83A68B3 for ; Tue, 6 Oct 2009 18:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 n1UuuWpCKfJz for ; Tue, 6 Oct 2009 18:14:14 -0700 (PDT) Received: from outbound-mail-111.bluehost.com (outbound-mail-111.bluehost.com [69.89.18.7]) by core3.amsl.com (Postfix) with SMTP id 8C81E28C18D for ; Tue, 6 Oct 2009 18:13:50 -0700 (PDT) Received: (qmail 5373 invoked by uid 0); 7 Oct 2009 01:15:29 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy3.bluehost.com with SMTP; 7 Oct 2009 01:15:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=zeZ2tbci2TVfJfYPZAGS5hqP60LUlPn/yb/sZYiIZvG1/Wb4pyafGIkcBYKfWr/t2u0j+kOnJsvUUkbx32l69vtYjXERGsOHBr71Vl6PLWVta24iF/Z2/78gSQQEUWrs; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MvL7o-0004mX-Hx; Tue, 06 Oct 2009 19:15:29 -0600 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: John Kemp In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784ECD794@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 6 Oct 2009 21:15:26 -0400 Content-Transfer-Encoding: 7bit Message-Id: <0099227B-7622-4925-A730-3317AA420ED7@jkemp.net> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784ECD794@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1076) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 01:14:15 -0000 On Oct 6, 2009, at 5:36 PM, Eran Hammer-Lahav wrote: > How do people feel about defining two (syntactically identical) What do you mean "syntactically identical"? > schemes: Delegated and Direct. I like this idea. > > Both will use the same method(s) of making authenticated requests As in the same set of signing mechanisms can be used in either case? > but Direct will mean use a username and password while Delegated > will mean use a token obtained from a delegation endpoint. This sounds good to me. - johnk > > Of course the other obvious option is to define a single scheme > Token and add a parameter but that is ugly. > > EHL > > From: John Panzer [mailto:jpanzer@google.com] > Sent: Tuesday, October 06, 2009 2:21 PM > To: Brian Eaton > Cc: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token > > I agree with beaton, but I have another argument against Basic > auth. Unmodified client code and UIs will assume we're talking > about regular username and password and use that terminology (and a > separate realm would just confuse things). If they're modified to > be OAuth aware this could be fixed, but if you assume OAuth aware > code you can use a new auth scheme just as easily. And, it would be > less confusing. > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > On Mon, Oct 5, 2009 at 11:48 AM, Brian Eaton > wrote: > On Sat, Oct 3, 2009 at 10:46 PM, Eran Hammer-Lahav > wrote: > > *** It would be helpful if other people chime in on this topic. > This is a > > critical decision we need to make regarding new schemes. One > proposal > > is to have different scheme for different type of access (direct > vs. delegated). > > Another is to reusing existing scheme (with a new MAC-based one) > for both > > usernames and tokens, and differentiating them on the server side > using the > > credential structure (token or username) and on the client side > using the > > realm parameter (and the header order). Of course, there are > probably other > > proposals coming. *** > > Eran points out that I've posted several times to this thread without > actually answering the question he asked. =) > > I don't think we should use basic auth to send tokens. I'd rather see > us use a new auth scheme. > > - basic auth has existing semantics for "realm". They aren't the same > semantics we need for OAuth. > - using the basic auth scheme would cripple our ability to add new > signature methods. > > It is in theory possible to treat a token as a username and a token > secret as a password, but I don't think it would be a particularly > useful thing to do. If we want to use bearer tokens, we should just > drop the token secret altogether. > > Cheers, > Brian > _______________________________________________ > 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 From eran@hueniverse.com Tue Oct 6 18:18:37 2009 Return-Path: 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 100F33A6931 for ; Tue, 6 Oct 2009 18:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_00=-2.599] 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 YyoFGu4T4K3j for ; Tue, 6 Oct 2009 18:18:36 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5AB5B3A6405 for ; Tue, 6 Oct 2009 18:18:36 -0700 (PDT) Received: (qmail 10755 invoked from network); 7 Oct 2009 01:20:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Oct 2009 01:20:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Oct 2009 18:20:13 -0700 From: Eran Hammer-Lahav To: John Kemp Date: Tue, 6 Oct 2009 18:20:20 -0700 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpG66lzoMtLjBzJSnmRyO+aNqVn+QAAH0wA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784ECD7E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784ECD794@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0099227B-7622-4925-A730-3317AA420ED7@jkemp.net> In-Reply-To: <0099227B-7622-4925-A730-3317AA420ED7@jkemp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 01:18:37 -0000 > -----Original Message----- > From: John Kemp [mailto:john@jkemp.net] > Sent: Tuesday, October 06, 2009 6:15 PM > On Oct 6, 2009, at 5:36 PM, Eran Hammer-Lahav wrote: >=20 > > How do people feel about defining two (syntactically identical) >=20 > What do you mean "syntactically identical"? Everything the same (signature flow, parameters, etc.) but use username in = one and token for another where credentials are expected (same with secret = and password). =20 > > schemes: Delegated and Direct. >=20 > I like this idea. >=20 > > > > Both will use the same method(s) of making authenticated requests >=20 > As in the same set of signing mechanisms can be used in either case? Yes. EHL From James.H.Manger@team.telstra.com Tue Oct 6 19:32:21 2009 Return-Path: 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 6AA0628C24C for ; Tue, 6 Oct 2009 19:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 LVL-6rEyWTKf for ; Tue, 6 Oct 2009 19:32:20 -0700 (PDT) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 1CBD028C24E for ; Tue, 6 Oct 2009 19:32:18 -0700 (PDT) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 07 Oct 2009 13:33:56 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 7223FFF81 for ; Wed, 7 Oct 2009 12:33:56 +1000 (EST) Received: from WSMSG3702.srv.dir.telstra.com (wsmsg3702.srv.dir.telstra.com [172.49.40.170]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA26949 for ; Wed, 7 Oct 2009 12:33:56 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 7 Oct 2009 13:33:55 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Wed, 7 Oct 2009 13:33:54 +1100 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpGyu+IMKYVD3MUTC6TWE1kI7XbdgAAcvmgAAc2fVA= Message-ID: <255B9BB34FB7D647A506DC292726F6E11245EE95A5@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784ECD794@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784ECD794@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11245EE95A5WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 02:32:21 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11245EE95A5WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdGlsbCBmZWVsIHRoYXQgaGF2aW5nIHR3byBwYXJhbGxlbCBncm91cHMgb2YgYXV0aGVudGlj YXRpb24gbWVjaGFuaXNtcyDigJQgb25lIGdyb3VwIGZvciDigJxkaXJlY3TigJ0gY3JlZGVudGlh bHMsIG9uZSBncm91cCBmb3Ig4oCcZGVsZWdhdGVk4oCdIGNyZWRlbnRpYWwg4oCUIGlzIGEgdmVy eSBwb29yIGFyY2hpdGVjdHVyYWwgY2hvaWNlLg0KDQoNCg0KSWYgaXQgaXMgcmVxdWlyZWQsIEkg c3VnZ2VzdCB0aGUgc2NoZW1lcyBmb3IgZGVsZWdhdGVkIGNyZWRlbnRpYWxzIHNob3VsZCBhZGQg 4oCcRGVsZWdhdGUt4oCcIHRvIHRoZSBkaXJlY3Qgc2NoZW1lIG5hbWUgYW5kIG90aGVyd2lzZSBi ZSBpZGVudGljYWwuIFNvIGEgcmVxdWVzdCBzaWduaW5nIHNwZWMgd291bGQgc3BlY2lmeSwgc2F5 LCBhIGRpcmVjdCDigJxNQUPigJ0gc2NoZW1lLiBBbm90aGVyIHNwZWMgd291bGQgZGVmaW5lIHRo ZSDigJxEZWxlZ2F0ZS3igJwgcHJlZml4IHRoYXQgY2FuIGFwcGx5IHRvIGFueSBzY2hlbWUuIFRo ZW4gd2UgY291bGQgdXNlOg0KDQogIEF1dGhvcml6YXRpb246IEJBU0lDIGFkZ2hhc2hqZGdhc2Rq ICAg4oCUIGZvciB1c2VycyB3aXRoIGJyb3dzZXJzDQoNCiAgQXV0aG9yaXphdGlvbjogRGVsZWdh dGUtQkFTSUMgYWRnaGFzaGpkZ2FzZGogIOKAlCBmb3IgY2xpZW50cyB3aXRoIGRlbGVnYXRpb24g dG9rZW4vc2VjcmV0cyBvdmVyIEhUVFBTDQoNCiAgQXV0aG9yaXphdGlvbjogRGVsZWdhdGUtTUFD IOKApnNpZ25hdHVyZT3igJ1kZmpnaGZh4oCdICDigJQgZm9yIGNsaWVudHMgd2l0aCBkZWxlZ2F0 aW9uIHRva2VuL3NlY3JldHMgb3ZlciBIVFRQDQoNCiAgQXV0aG9yaXphdGlvbjogTUFDIOKApnNp Z25hdHVyZT3igJ1kZmpnaGZh4oCdICDigJQgZm9yIGNsaWVudHMgd2l0aCBhcHAgY3JlZGVudGlh bHMgKGVnIDItbGVnZ2VkKSBvdmVyIEhUVFANCg0KICBBdXRob3JpemF0aW9uOiBEZWxlZ2F0ZS1J ZCA8dG9rZW4+ICDigJQgZm9yIGNsaWVudHMgYWN0aW5nIGFzIGEgZGVsZWdhdGUgb3ZlciBhIHNl cGFyYXRlbHktYXV0aGVudGljYXRlZCBjaGFubmVsIChIVFRQUyB3aXRoIGNsaWVudCAmIHNlcnZl ciBhdXRoOyBWUE7igKYpDQoNCg0KDQoNCg0KPiBCb3RoIHdpbGwgdXNlIHRoZSBzYW1lIG1ldGhv ZChzKQ0KDQoNCg0KRG9lcyB0aGlzIG1lYW5zIHRoZSDigJxEZWxlZ2F0ZWTigJ0gYW5kIOKAnERp cmVjdOKAnSBzY2hlbWVzIGFyZSBzdXBwb3NlZCB0byBpbmNsdWRlIFBMQUlOIGFuZCBITUFDIChh bmQgUlNBPykgbWV0aG9kcyAoZWcg4oCcRGVsZWdhdGVkIFBMQUlO4oCdIChsaWtlIHRoZSDigJxU T0tFTiBQTEFJTuKAnSBpZGVhKT8gSWYgc28sIHl1Y2shIEJ1cnlpbmcgdGhlIGFjdHVhbCBtZWNo YW5pc20gKFBMQUlOL0hNQUMv4oCmKSBhIGxheWVyIGRvd24gd2lsbCBub3Qgd29yayB3ZWxsIHdp dGggZXhpc3RpbmcgbGlicmFyaWVzIHdoZXJlIG9uZSBwYXJ0IGNob29zZXMgYSBtZWNoYW5pc20g YmFzZWQgc29sZWx5IG9uIHRoZSBzY2hlbWUuDQoNCg0KDQpJIGFsc28gZG9u4oCZdCB0aGluayBp dCBtYXRjaGVzIHRoZSBhbGxvd2VkIHN5bnRheCBmb3IgdGhlIFdXVy1BdXRoZW50aWNhdGUgaGVh ZGVyOiBldmVyeXRoaW5nIGFmdGVyIHRoZSBzY2hlbWUgaGFzIHRvIGJlIGluIG5hbWU9dmFsdWUg c3ludGF4LiBbUkZDIDI2MTcsIMKnMS4yXQ0KDQpjaGFsbGVuZ2UgICA9IGF1dGgtc2NoZW1lIDEq U1AgMSNhdXRoLXBhcmFtDQoNCmF1dGgtc2NoZW1lID0gdG9rZW4NCmF1dGgtcGFyYW0gID0gdG9r ZW4gIj0iICggdG9rZW4gfCBxdW90ZWQtc3RyaW5nICkNCg0KDQoNCg0KDQpbQXNpZGU6IHJlZ2Fy ZGxlc3Mgb2YgcHJlZml4LCBzdGljayB3aXRoIOKAnEJBU0lDIGJhc2U2NCh1dGY4KHRva2VuKSDi gJg64oCZIHV0Zjgoc2VjcmV0KSnigJ0gc3ludGF4IGluc3RlYWQgb2Yg4oCcUGxhaW4gPHRva2Vu PiA8c2VjcmV0PuKAnS4gVGhlIG9ubHkgcmVzdHJpY3Rpb24gdGhlIGZvcm1lciBpbXBvc2VzIGlz IHRoYXQgYSB0b2tlbiBjYW5ub3QgaW5jbHVkZSBhIGNvbG9uLiBUaGUgbGF0dGVyIGltcGxpZXMg YWxsIHNvcnQgb2YgcmVzdHJpY3Rpb25zIG9uIHRva2VuIGFuZCBzZWNyZXQ6IG9ubHkgQVNDSUks IG5vIGNvbW1hcywgbm8gbmV3bGluZXMsIG5vIHNwYWNlLCBxdW90ZXMgKG5vciBzdXJlKSwgb3Ro ZXIgcHVuY3R1YXRpb24gKG5vdCBzdXJlKS4gSXQgaXMgZmFyIGZyb20gY2xlYXIgd2hhdCBleGFj dGx5IHRoZSByZXN0cmljdGlvbnMgYXJlIGFzIEkgYmVsaWV2ZSB0aGUgSFRUUCBoZWFkZXIgcGFy c2luZyBydWxlcyBhcmUgcXVpdGUgbWVzc3kg4oCUIGF2b2lkIHRoaXMgaXNzdWUgKGFuZCB0aGUg d2hvbGUgZGViYXRlKSBieSBzdGlja2luZyB3aXRoIHRoZSBCQVNJQyBzeW50YXguXQ0KDQoNCg0K DQoNCkkgZGlkIGEgZmV3IHRlc3RzIHRvIHNlZSBob3cgSmF2YSAoU3Vu4oCZcyB2NikgaGFuZGxl ZCBtdWx0aXBsZSBXV1ctQXV0aCBoZWFkZXJzIGluIGEgcmVzcG9uc2UuIEkgaGFkIGhvcGVkIGl0 IHdvdWxkIHBhc3MgZWFjaCB0byB0aGUgY29uZmlndXJlZCBqYXZhLm5ldC5BdXRoZW50aWNhdG9y IHVudGlsIHNvbWUgbm9uLW51bGwgY3JlZGVudGlhbHMgd2VyZSBmb3VuZC4gSXQgZG9lcyBub3Qg ZG8gdGhpcy4gSXQgcGlja3Mgb25lIGhlYWRlciBiYXNlZCBvbiBhIChjb25maWd1cmFibGUpIHBy aW9yaXRpemVkIGxpc3Qgb2Ygc2NoZW1lcyAoYnkgZGVmYXVsdCBOZWdvdGlhdGUsIEtlcmJlcm9z LCBEaWdlc3QsIE5UTE0sIHRoZW4gQkFTSUMpLiBJZiBhIHNjaGVtZSBhcHBlYXJzIG11bHRpcGxl IHRpbWVzIGl0IHBpY2tzIHRoZSBsYXN0IG9jY3VycmVuY2UgKGluIGNvbnRyYXN0IHRvIGJyb3dz ZXJzIHRoYXQgcGljayB0aGUgZmlyc3QpLiBJIGJlbGlldmUgKEFwYWNoZSkgSHR0cENsaWVudCBk b2VzIGEgc2ltaWxhciB0aGluZzogbmV3IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgY2FuIGJl IGFkZGVkLCBidXQgb25seSB0aGUgc2NoZW1lIGlzIGNvbnN1bHRlZCB3aGVuIGNob29zaW5nIHRo ZW0uDQoNCg0KDQpUaGlzIG1lYW5zIHJldHVybmluZyBtdWx0aXBsZSDigJxXV1ctQXV0aC46IEJB U0lDIOKApuKAnSBoZWFkZXJzIHdpdGggZGlmZmVyZW50IHJlYWxtcyAob25lIGZvciB1c2Vycywg b25lIGZvciBhcHBzIHdpdGggZGVsZWdhdGlvbiB0b2tlbnMpIHdvdWxkIGJlIG1vcmUgYXdrd2Fy ZCB0aGFuIEkgaG9wZWQuIEkgd2lsbCBub3QgcHVyc3VlIHRoYXQgaWRlYS4NCg0KDQoNCkl0IGFs c28gbWVhbnMg4oCcVG9rZW4gPHN1Yi1zY2hlbWU+4oCdLCDigJxEZWxlZ2F0ZWQgPHN1Yi1zY2hl bWU+4oCdIG9yIOKAnERpcmVjdCA8c3ViLXNjaGVtZT7igJ0gd2lsbCBub3Qgd29yayB3ZWxsIHdp dGggZXhpc3RpbmcgY29kZSBiYXNlcy4gRXhpc3RpbmcgSmF2YSBIVFRQIGludGVybmFscyBjb3Vs ZCBwaWNrIHRoZSBsYXN0IOKAnERlbGVnYXRlZCDigJ0gaGVhZGVyLCBidXQgY291bGQgbm90IGJl IGNvbmZpZ3VyZWQgdG8gcGljaywgc2F5LCBITUFDIG92ZXIgUExBSU4sIG9yIFJTQSBvdmVyIEhN QUMuDQoNCg0KDQoNCg0KUGVyaGFwcyB3ZSBuZWVkIHNvbWUgY2xhcmlmaWNhdGlvbiBvdmVyIHRo ZSBwcm9ibGVtIHRoZSBEZWxlZ2F0ZWQvRGlyZWN0L1Rva2VuIGlkZWEgaXMgYWRkcmVzc2luZy4g RXJhbuKAmXMgb3JpZ2luYWwgc3RhdGVtZW50IHdhczoNCg0KPiDigJxJdCBpcyBpbXBvcnRhbnQg dG8gbWFrZSBzdXJlIGEgc2VydmVyIGNhbiByZXBseSB0byBhIHByb3RlY3RlZCByZXNvdXJjZSBy ZXF1ZXN0IHdpdGggbW9yZSB0aGFuIG9uZSBhdXRoIGhlYWRlciB0byBpbmRpY2F0ZSB0aGF0IGJv dGggdXNlcm5hbWVzIGFuZCB0b2tlbnMgYXJlIHdlbGNvbWVkLuKAnQ0KDQoNCg0KRXJhbiwgYXJl IHlvdSBtb3N0IGNvbmNlcm5lZCBhYm91dCBhbGxvd2luZyB1c2VycyB3aXRoIGJyb3dzZXJzIGFu ZCBhcHBzIHdpdGggZGVsZWdhdGVkIGNyZWRlbnRpYWxzIHRvIGFjY2VzcyB0aGUgc2FtZSBVUklz PyBPciBpcyBpdCBhcHBzIHdpdGggdGhlaXIgb3duIChkaXJlY3QpIGNyZWRlbnRpYWxzIGFuZCB3 aXRoIGRlbGVnYXRlZCBjcmVkZW50aWFscyBuZWVkaW5nIHRvIGNob29zZSBiZXR3ZWVuIHRoZXNl Pw0KDQoNCg0KU3VwcG9ydGluZyBlaXRoZXIgKG9yIGJvdGgpIHdvdWxkIGJlIG5pY2UsIGJ1dCBJ IGFtIG5vdCB5ZXQgY29udmluY2VkIHRoYXQgdGhpcyBwcm9ibGVtIGlzIHRoYXQgY3JpdGljYWwg KGllIHdvcnRoIGEgYXJjaGl0ZWN0dXJhbCBjb21wcm9taXNlKS4NCg0KRmV3IHNpdGVzIHVzZSBC QVNJQyBmb3IgdXNlcnMg4oCUIGl0IGp1c3QgZG9lc27igJl0IG9mZmVyIGVub3VnaCBmbGV4aWJp bGl0eSBpbiB0aGUgdXNlciBpbnRlcmZhY2UgKGZvcmdvdHRlbiBwYXNzd29yZCBsaW5rcyBldGMp Lg0KDQpGZXcgc2l0ZXMgdXNlIHRoZSBzYW1lIFVSSXMgZm9yIHVzZXJzIGFuZCBhcHBzIOKAlCBt YW55IHNlZW0gdG8gaGF2ZSBhIHd3dy5leGFtcGxlLm5ldDxodHRwOi8vd3d3LmV4YW1wbGUubmV0 PiBhbmQgYXBpLmV4YW1wbGUubmV0IHNwbGl0LCBmb3IgaW5zdGFuY2UuIFVzZXJzIHR5cGljYWxs eSB3YW50IEhUTUw7IGFwcHMgdHlwaWNhbGx5IHdhbnQgSlNPTiBvciBYTUzigKYuDQoNClRoZSBl eHRyZW1lbHkgY29tbW9uIEZPUk0tYmFzZWQgdXNlciBhdXRoIGRvZXMgbm90IHBsYXkgd2VsbCB3 aXRoIGFueSBXV1ctQXV0aCBoZWFkZXIgYXMgaXQgaXMgbmV2ZXIoPykgZGVsaXZlcmVkIHdpdGgg YSA0MDEgZXJyb3IgY29kZS4NCg0KDQoNCkZpbmFsbHksIHdlIGhhdmUgY29uY2VudHJhdGVkIG9u IFdXVy1BdXRoLWJhc2VkIGRpc2NvdmVyeSBmb3IgdGhlIGF1dGhlbnRpY2F0aW9uIHBhcnQsIGln bm9yaW5nIHRoZSBkZWxlZ2F0aW9uIGZsb3cgcGFydCBmb3Igbm93LiBJdCBzZWVtcyBxdWl0ZSBy ZWFzb25hYmxlL3NlbnNpYmxlL2xpa2VseS9wb3NzaWJsZSB0aGF0IHRoZSBkZWxlZ2F0aW9uIGZs b3cgc2hvdWxkIGluZGljYXRlIHdoaWNoIHByb3RlY3RlZCByZXNvdXJjZXMgdGhlIGRlbGVnYXRp b24gY2FuIGJlIHVzZWQgYXQuIEluIHdoaWNoIGNhc2UsIHRoZSBkZWxlZ2F0aW9uIGNyZWRlbnRp YWxzIGNhbiBiZSBzZW50IHByb2FjdGl2ZWx5IHdoZW4gcmVxdWVzdGluZyB0aG9zZSByZXNvdXJj ZXMsIHdpdGhvdXQgYW55IG5lZWQgZm9yIGEgV1dXLUF1dGggaGVhZGVyIChtYWtpbmcgdGhlIERl bGVnYXRlLXNwZWNpZmljIFdXVy1BdXRoIHNjaGVtZXMgdW5uZWNlc3NhcnkpLg0KDQoNCg0KDQoN CkphbWVzIE1hbmdlcg0KSmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFt ZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFt IOKAlCBDaGllZiBUZWNobm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E11245EE95A5WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQog PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JIHN0aWxsIGZlZWwgdGhhdCBoYXZpbmcgdHdvIHBhcmFs bGVsIGdyb3VwcyBvZiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIOKAlCBvbmUgZ3JvdXAgZm9y IOKAnGRpcmVjdOKAnSBjcmVkZW50aWFscywgb25lIGdyb3VwIGZvciDigJxkZWxlZ2F0ZWTigJ0g Y3JlZGVudGlhbCDigJQgaXMNCiBhIHZlcnkgcG9vciBhcmNoaXRlY3R1cmFsIGNob2ljZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj5JZiBpdCBpcyByZXF1aXJlZCwgSSBzdWdnZXN0IHRoZSBzY2hlbWVzIGZvciBk ZWxlZ2F0ZWQgY3JlZGVudGlhbHMgc2hvdWxkIGFkZCDigJxEZWxlZ2F0ZS3igJwgdG8gdGhlIGRp cmVjdCBzY2hlbWUgbmFtZSBhbmQgb3RoZXJ3aXNlIGJlIGlkZW50aWNhbC4gU28gYSByZXF1ZXN0 DQogc2lnbmluZyBzcGVjIHdvdWxkIHNwZWNpZnksIHNheSwgYSBkaXJlY3Qg4oCcTUFD4oCdIHNj aGVtZS4gQW5vdGhlciBzcGVjIHdvdWxkIGRlZmluZSB0aGUg4oCcRGVsZWdhdGUt4oCcIHByZWZp eCB0aGF0IGNhbiBhcHBseSB0byBhbnkgc2NoZW1lLiBUaGVuIHdlIGNvdWxkIHVzZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsgQXV0aG9yaXphdGlvbjogQkFTSUMgYWRn aGFzaGpkZ2FzZGombmJzcDsmbmJzcDsg4oCUIGZvciB1c2VycyB3aXRoIGJyb3dzZXJzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7IEF1dGhvcml6YXRpb246IERlbGVnYXRl LUJBU0lDIGFkZ2hhc2hqZGdhc2RqJm5ic3A7IOKAlCBmb3IgY2xpZW50cyB3aXRoIGRlbGVnYXRp b24gdG9rZW4vc2VjcmV0cyBvdmVyIEhUVFBTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3 RCI+Jm5ic3A7IEF1dGhvcml6YXRpb246IERlbGVnYXRlLU1BQyDigKZzaWduYXR1cmU94oCdZGZq Z2hmYeKAnSZuYnNwOyDigJQgZm9yIGNsaWVudHMgd2l0aCBkZWxlZ2F0aW9uIHRva2VuL3NlY3Jl dHMgb3ZlciBIVFRQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7IEF1dGhv cml6YXRpb246IE1BQyDigKZzaWduYXR1cmU94oCdZGZqZ2hmYeKAnSZuYnNwOyDigJQgZm9yIGNs aWVudHMgd2l0aCBhcHAgY3JlZGVudGlhbHMgKGVnIDItbGVnZ2VkKSBvdmVyIEhUVFA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsgQXV0aG9yaXphdGlvbjogRGVsZWdhdGUt SWQgJmx0O3Rva2VuJmd0OyZuYnNwOyDigJQgZm9yIGNsaWVudHMgYWN0aW5nIGFzIGEgZGVsZWdh dGUgb3ZlciBhIHNlcGFyYXRlbHktYXV0aGVudGljYXRlZCBjaGFubmVsIChIVFRQUyB3aXRoIGNs aWVudCAmYW1wOyBzZXJ2ZXIgYXV0aDsgVlBO4oCmKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mZ3Q7IEJvdGggd2lsbCB1 c2UgdGhlIHNhbWUgbWV0aG9kKHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj5Eb2VzIHRoaXMgbWVhbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6DQomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+IHRoZSDigJxEZWxlZ2F0ZWTigJ0gYW5kIOKAnERpcmVjdOKAnSBzY2hl bWVzDQogYXJlIHN1cHBvc2VkIHRvIGluY2x1ZGUgUExBSU4gYW5kIEhNQUMgKGFuZCBSU0E/KSBt ZXRob2RzIChlZyDigJxEZWxlZ2F0ZWQgUExBSU7igJ0gKGxpa2UgdGhlIOKAnFRPS0VOIFBMQUlO 4oCdIGlkZWEpPyBJZiBzbywgeXVjayEgQnVyeWluZyB0aGUgYWN0dWFsIG1lY2hhbmlzbSAoUExB SU4vSE1BQy/igKYpIGEgbGF5ZXIgZG93biB3aWxsIG5vdCB3b3JrIHdlbGwgd2l0aCBleGlzdGlu ZyBsaWJyYXJpZXMgd2hlcmUgb25lIHBhcnQgY2hvb3NlcyBhIG1lY2hhbmlzbQ0KIGJhc2VkIHNv bGVseSBvbiB0aGUgc2NoZW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkkgYWxzbyBkb27igJl0IHRoaW5rIGl0 IG1hdGNoZXMgdGhlIGFsbG93ZWQgc3ludGF4IGZvciB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBoZWFk ZXI6IGV2ZXJ5dGhpbmcgYWZ0ZXIgdGhlIHNjaGVtZSBoYXMgdG8gYmUgaW4gbmFtZT12YWx1ZSBz eW50YXguIFtSRkMgMjYxNywgwqcxLjJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPmNoYWxsZW5nZSZuYnNwOyZuYnNwOyA9IGF1dGgtc2NoZW1l IDEqU1AgMSNhdXRoLXBhcmFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT5hdXRoLXNjaGVt ZSA9IHRva2VuPG86cD48L286cD48L3ByZT4NCjxwcmU+YXV0aC1wYXJhbSZuYnNwOyA9IHRva2Vu ICZxdW90Oz0mcXVvdDsgKCB0b2tlbiB8IHF1b3RlZC1zdHJpbmcgKTxvOnA+PC9vOnA+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5bQXNpZGU6IHJlZ2FyZGxlc3Mgb2YgcHJl Zml4LCBzdGljayB3aXRoIOKAnEJBU0lDIGJhc2U2NCh1dGY4KHRva2VuKSDigJg64oCZIHV0Zjgo c2VjcmV0KSnigJ0gc3ludGF4IGluc3RlYWQgb2Yg4oCcUGxhaW4gJmx0O3Rva2VuJmd0OyAmbHQ7 c2VjcmV0Jmd0O+KAnS4gVGhlIG9ubHkgcmVzdHJpY3Rpb24gdGhlDQogZm9ybWVyIGltcG9zZXMg aXMgdGhhdCBhIHRva2VuIGNhbm5vdCBpbmNsdWRlIGEgY29sb24uIFRoZSBsYXR0ZXIgaW1wbGll cyBhbGwgc29ydCBvZiByZXN0cmljdGlvbnMgb24gdG9rZW4gYW5kIHNlY3JldDogb25seSBBU0NJ SSwgbm8gY29tbWFzLCBubyBuZXdsaW5lcywgbm8gc3BhY2UsIHF1b3RlcyAobm9yIHN1cmUpLCBv dGhlciBwdW5jdHVhdGlvbiAobm90IHN1cmUpLiBJdCBpcyBmYXIgZnJvbSBjbGVhciB3aGF0IGV4 YWN0bHkgdGhlIHJlc3RyaWN0aW9ucw0KIGFyZSBhcyBJIGJlbGlldmUgdGhlIEhUVFAgaGVhZGVy IHBhcnNpbmcgcnVsZXMgYXJlIHF1aXRlIG1lc3N5IOKAlCBhdm9pZCB0aGlzIGlzc3VlIChhbmQg dGhlIHdob2xlIGRlYmF0ZSkgYnkgc3RpY2tpbmcgd2l0aCB0aGUgQkFTSUMgc3ludGF4Ll08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JIGRpZCBh IGZldyB0ZXN0cyB0byBzZWUgaG93IEphdmEgKFN1buKAmXMgdjYpIGhhbmRsZWQgbXVsdGlwbGUg V1dXLUF1dGggaGVhZGVycyBpbiBhIHJlc3BvbnNlLiBJIGhhZCBob3BlZCBpdCB3b3VsZCBwYXNz IGVhY2ggdG8gdGhlIGNvbmZpZ3VyZWQgamF2YS5uZXQuQXV0aGVudGljYXRvcg0KIHVudGlsIHNv bWUgbm9uLW51bGwgY3JlZGVudGlhbHMgd2VyZSBmb3VuZC4gSXQgZG9lcyBub3QgZG8gdGhpcy4g SXQgcGlja3Mgb25lIGhlYWRlciBiYXNlZCBvbiBhIChjb25maWd1cmFibGUpIHByaW9yaXRpemVk IGxpc3Qgb2Ygc2NoZW1lcyAoYnkgZGVmYXVsdCBOZWdvdGlhdGUsIEtlcmJlcm9zLCBEaWdlc3Qs IE5UTE0sIHRoZW4gQkFTSUMpLiBJZiBhIHNjaGVtZSBhcHBlYXJzIG11bHRpcGxlIHRpbWVzIGl0 IHBpY2tzIHRoZSBsYXN0IG9jY3VycmVuY2UNCiAoaW4gY29udHJhc3QgdG8gYnJvd3NlcnMgdGhh dCBwaWNrIHRoZSBmaXJzdCkuIEkgYmVsaWV2ZSAoQXBhY2hlKSBIdHRwQ2xpZW50IGRvZXMgYSBz aW1pbGFyIHRoaW5nOiBuZXcgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBjYW4gYmUgYWRkZWQs IGJ1dCBvbmx5IHRoZSBzY2hlbWUgaXMgY29uc3VsdGVkIHdoZW4gY2hvb3NpbmcgdGhlbS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj5UaGlzIG1lYW5zIHJldHVybmluZyBtdWx0aXBsZSDigJxXV1ctQXV0aC46IEJB U0lDIOKApuKAnSBoZWFkZXJzIHdpdGggZGlmZmVyZW50IHJlYWxtcyAob25lIGZvciB1c2Vycywg b25lIGZvciBhcHBzIHdpdGggZGVsZWdhdGlvbiB0b2tlbnMpIHdvdWxkIGJlIG1vcmUgYXdrd2Fy ZA0KIHRoYW4gSSBob3BlZC4gSSB3aWxsIG5vdCBwdXJzdWUgdGhhdCBpZGVhLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPkl0IGFsc28gbWVhbnMg4oCcVG9rZW4gJmx0O3N1Yi1zY2hlbWUmZ3Q74oCdLCDigJxEZWxl Z2F0ZWQgJmx0O3N1Yi1zY2hlbWUmZ3Q74oCdIG9yIOKAnERpcmVjdCAmbHQ7c3ViLXNjaGVtZSZn dDvigJ0gd2lsbCBub3Qgd29yayB3ZWxsIHdpdGggZXhpc3RpbmcgY29kZSBiYXNlcy4gRXhpc3Rp bmcgSmF2YSBIVFRQIGludGVybmFscw0KIGNvdWxkIHBpY2sgdGhlIGxhc3Qg4oCcRGVsZWdhdGVk IOKAnSBoZWFkZXIsIGJ1dCBjb3VsZCBub3QgYmUgY29uZmlndXJlZCB0byBwaWNrLCBzYXksIEhN QUMgb3ZlciBQTEFJTiwgb3IgUlNBIG92ZXIgSE1BQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5QZXJoYXBzIHdlIG5lZWQgc29tZSBjbGFyaWZp Y2F0aW9uIG92ZXIgdGhlIHByb2JsZW0gdGhlIERlbGVnYXRlZC9EaXJlY3QvVG9rZW4gaWRlYSBp cyBhZGRyZXNzaW5nLiBFcmFu4oCZcyBvcmlnaW5hbCBzdGF0ZW1lbnQgd2FzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZndDsg4oCcSXQgaXMgaW1wb3J0YW50IHRvIG1ha2Ugc3Vy ZSBhIHNlcnZlciBjYW4gcmVwbHkgdG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdCB3aXRo IG1vcmUgdGhhbiBvbmUgYXV0aCBoZWFkZXIgdG8gaW5kaWNhdGUgdGhhdCBib3RoIHVzZXJuYW1l cyBhbmQgdG9rZW5zDQogYXJlIHdlbGNvbWVkLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkVyYW4sIGFyZSB5 b3UgbW9zdCBjb25jZXJuZWQgYWJvdXQgYWxsb3dpbmcgdXNlcnMgd2l0aCBicm93c2VycyBhbmQg YXBwcyB3aXRoIGRlbGVnYXRlZCBjcmVkZW50aWFscyB0byBhY2Nlc3MgdGhlIHNhbWUgVVJJcz8g T3IgaXMgaXQgYXBwcyB3aXRoIHRoZWlyIG93bg0KIChkaXJlY3QpIGNyZWRlbnRpYWxzIGFuZCB3 aXRoIGRlbGVnYXRlZCBjcmVkZW50aWFscyBuZWVkaW5nIHRvIGNob29zZSBiZXR3ZWVuIHRoZXNl PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPlN1cHBvcnRpbmcgZWl0aGVyIChvciBib3RoKSB3b3VsZCBiZSBuaWNl LCBidXQgSSBhbSBub3QgeWV0IGNvbnZpbmNlZCB0aGF0IHRoaXMgcHJvYmxlbSBpcyB0aGF0IGNy aXRpY2FsIChpZSB3b3J0aCBhIGFyY2hpdGVjdHVyYWwgY29tcHJvbWlzZSkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+RmV3IHNpdGVzIHVzZSBCQVNJQyBmb3IgdXNlcnMg4oCUIGl0 IGp1c3QgZG9lc27igJl0IG9mZmVyIGVub3VnaCBmbGV4aWJpbGl0eSBpbiB0aGUgdXNlciBpbnRl cmZhY2UgKGZvcmdvdHRlbiBwYXNzd29yZCBsaW5rcyBldGMpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPkZldyBzaXRlcyB1c2UgdGhlIHNhbWUgVVJJcyBmb3IgdXNlcnMgYW5kIGFw cHMg4oCUIG1hbnkgc2VlbSB0byBoYXZlIGENCjxhIGhyZWY9Imh0dHA6Ly93d3cuZXhhbXBsZS5u ZXQiPnd3dy5leGFtcGxlLm5ldDwvYT4gYW5kIGFwaS5leGFtcGxlLm5ldCBzcGxpdCwgZm9yIGlu c3RhbmNlLiBVc2VycyB0eXBpY2FsbHkgd2FudCBIVE1MOyBhcHBzIHR5cGljYWxseSB3YW50IEpT T04gb3IgWE1M4oCmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlRoZSBleHRyZW1l bHkgY29tbW9uIEZPUk0tYmFzZWQgdXNlciBhdXRoIGRvZXMgbm90IHBsYXkgd2VsbCB3aXRoIGFu eSBXV1ctQXV0aCBoZWFkZXIgYXMgaXQgaXMgbmV2ZXIoPykgZGVsaXZlcmVkIHdpdGggYSA0MDEg ZXJyb3IgY29kZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5GaW5hbGx5LCB3ZSBoYXZlIGNvbmNlbnRyYXRlZCBv biBXV1ctQXV0aC1iYXNlZCBkaXNjb3ZlcnkgZm9yIHRoZSBhdXRoZW50aWNhdGlvbiBwYXJ0LCBp Z25vcmluZyB0aGUgZGVsZWdhdGlvbiBmbG93IHBhcnQgZm9yIG5vdy4gSXQgc2VlbXMgcXVpdGUg cmVhc29uYWJsZS9zZW5zaWJsZS9saWtlbHkvcG9zc2libGUNCiB0aGF0IHRoZSBkZWxlZ2F0aW9u IGZsb3cgc2hvdWxkIGluZGljYXRlIHdoaWNoIHByb3RlY3RlZCByZXNvdXJjZXMgdGhlIGRlbGVn YXRpb24gY2FuIGJlIHVzZWQgYXQuIEluIHdoaWNoIGNhc2UsIHRoZSBkZWxlZ2F0aW9uIGNyZWRl bnRpYWxzIGNhbiBiZSBzZW50IHByb2FjdGl2ZWx5IHdoZW4gcmVxdWVzdGluZyB0aG9zZSByZXNv dXJjZXMsIHdpdGhvdXQgYW55IG5lZWQgZm9yIGEgV1dXLUF1dGggaGVhZGVyIChtYWtpbmcgdGhl IERlbGVnYXRlLXNwZWNpZmljDQogV1dXLUF1dGggc2NoZW1lcyB1bm5lY2Vzc2FyeSkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+DQo8YnI+DQo8YSBocmVmPSJtYWls dG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbSI+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L3NwYW4+PC9h Pg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij5JZGVudGl0eSBhbmQgc2VjdXJpdHkgdGVhbTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ 4oCUPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+IENoaWVm IFRlY2hub2xvZ3kgT2ZmaWNlPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJQ8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4gVGVsc3RyYTwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_255B9BB34FB7D647A506DC292726F6E11245EE95A5WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Tue Oct 6 20:46:24 2009 Return-Path: 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 B602228C17F for ; Tue, 6 Oct 2009 20:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 aR1hmT1Xm6rp for ; Tue, 6 Oct 2009 20:46:24 -0700 (PDT) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id B8FDE3A63C9 for ; Tue, 6 Oct 2009 20:46:21 -0700 (PDT) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipbi.vtcif.telstra.com.au with ESMTP; 07 Oct 2009 14:44:41 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 1752C1DA86 for ; Wed, 7 Oct 2009 13:44:41 +1000 (EST) Received: from WSMSG3705.srv.dir.telstra.com (wsmsg3705.in.telstra.com.au [172.49.40.203]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id CE8CC41D11 for ; Wed, 7 Oct 2009 13:44:25 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 7 Oct 2009 14:44:40 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Wed, 7 Oct 2009 14:44:38 +1100 Thread-Topic: [OAUTH-WG] Proposal for a New 2617 Scheme: Token Thread-Index: AcpF7Ihxm7hRKVfjSUCulYca6RwwSABEKZIA Message-ID: <255B9BB34FB7D647A506DC292726F6E11245EE976F@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784DF259F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11231D18995@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF26E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124423C1EA@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2783@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124573315A@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343784DF2794@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: 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 Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 03:46:24 -0000 QnJpYW4sDQoNCj4gLSBiYXNpYyBhdXRoIGhhcyBleGlzdGluZyBzZW1hbnRpY3MgZm9yICJyZWFs bSIuDQo+ICAgVGhleSBhcmVuJ3QgdGhlIHNhbWUgc2VtYW50aWNzIHdlIG5lZWQgZm9yIE9BdXRo LiINCg0KQ291bGQgeW91IGV4cGxhaW4gdGhpcyBhIGJpdCBtb3JlPyBXaGF0IHNlbWFudGljcyBk b2VzIE9BdXRoIG5lZWQ/DQpCQVNJQyBvbmx5IGFzc3VtZXMgYSByZWFsbSBpcyB1bmFtYmlndW91 cyBpbiB0aGUgY29udGV4dCBvZiBvbmUgc2l0ZS4gVGhhdCBpcyBwcm9iYWJseSBtb3JlIGxpbWl0 ZWQgdGhhbiBtYW55IE9BdXRoIHByb3ZpZGVycyB3YW50LiBIb3dldmVyLCBJIGNhbid0IHNlZSBh bnkgcHJvYmxlbXMgd2l0aCBhIGRlbGVnYXRpb24gZmxvdyBleHBhbmRpbmcgdGhhdDogZWcgc2F5 aW5nICJ0cmVhdCAqLmV4YW1wbGUubmV0IGFuZCBhcGkuZXhhbXBsZS5jb20gYXMgYSBzaW5nbGUg Y29udGV4dCBmb3IgcmVhbG0gdmFsdWVzIi4NCg0KDQo+IC0gdXNpbmcgdGhlIGJhc2ljIGF1dGgg c2NoZW1lIHdvdWxkIGNyaXBwbGUgb3VyIGFiaWxpdHkgdG8gYWRkIG5ldw0KPiAgIHNpZ25hdHVy ZSBtZXRob2RzLg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBvbmUuDQpIb3cgZG9lcyBpdCBw cmVjbHVkZSBkZWZpbmluZyBhIHNlcGFyYXRlIE1BQyBzY2hlbWUgb3IgUlNBIHNjaGVtZT8NCg0K DQoNCj4gSWYgd2Ugd2FudCB0byB1c2UgYmVhcmVyIHRva2Vucywgd2Ugc2hvdWxkIGp1c3QgZHJv cCB0aGUgdG9rZW4gc2VjcmV0IGFsdG9nZXRoZXIuDQoNCkkgdGhpbmsgSSBhZ3JlZSBoZXJlLiBJ dCB3b3VsZCBiZSBoZWxwZnVsIHRvIHN1cHBvcnQgYmVhcmVyIHRva2VucyBhcyBvbmUgT0F1dGgg b3B0aW9uIChtYWtpbmcgdGhlIHNlY3JldCBvcHRpb25hbCBpbiB0aGUgZGVsZWdhdGlvbiBmbG93 IGFuZCBkZWZpbmluZyBhICJBdXRob3JpemF0aW9uOiBJZCA8dG9rZW4+IiBzY2hlbWUgc3BlY2lm aWNhbGx5IGZvciB0aGlzIGNhc2UpLg0KDQpKYW1lcw0K From mnot@mnot.net Wed Oct 7 21:14:17 2009 Return-Path: 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 4D4E33A6823 for ; Wed, 7 Oct 2009 21:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=-3.711, BAYES_00=-2.599] 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 seE739QJ9ksb for ; Wed, 7 Oct 2009 21:14:16 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 38F643A688C for ; Wed, 7 Oct 2009 21:14:14 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.157.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AB50A509DA; Thu, 8 Oct 2009 00:15:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 8 Oct 2009 15:15:44 +1100 Content-Transfer-Encoding: 7bit Message-Id: <5BFD6F3E-4A66-4C7B-98FF-8D2C286977B3@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1076) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 04:14:17 -0000 Digging up some feedback I sent privately a long while back WRT problem reporting (so apologies if the drafts have move on since)... * Overall, I don't think that this is the right approach to solving these sorts of problems (or writing a protocol generally); while there is a place for error reporting, it's important to build more error avoidance into the protocol so that reporting isn't necessary. Instead of telling people what signature methods you accept after the fact, advertise it in the challenge. Instead of telling them that they need additional authentication in a parameter, use another challenge (or the first one). This is more declarative, avoids round-trips, and generally simplifies things. * version_rejected - What's with this? If you're talking about minor versions, changes should be backwards-compatible, so there's no need to barf. If you're talking about major versions, you should use a different scheme name, and let HTTP tell them that the auth scheme isn't supported. * parameter_absent - This is overkill; if your protocol is so complex that you need to do this, it's a very bad sign, and only serves to make the protocol *more* complex. Is there anything useful that a non- human recipient can do with this? * parameter_rejected - Unrecognised parameters should be ignored; see Postel. * token_revoked / token_rejected - What is the practical difference between these, if any? * user_refused - this seems very fuzzy. * oauth_acceptable_timestamps - this creates a race condition. If you really need to inform users of the window for timestamps (seems like a security risk to me, and in any case they often won't be able to do much about it, because any skew you see will be caused by network and processing on both ends), use a delta (e.g., '5' = +- five seconds). * Your parameter names are quite verbose (e.g., oauth_parameters_rejected); this, in combination with the fact that there are so many, may cause the header to be too large, and in any case is going to push some messages over packet boundaries. How about trimming them (e.g., params_rej)? Cheers, On 22/09/2009, at 6:40 AM, Eran Hammer-Lahav wrote: > http://tools.ietf.org/html/draft-ietf-oauth-authentication > http://tools.ietf.org/html/draft-ietf-oauth-web-delegation > > I plan to publish new revisions of the above drafts to include: > > * Error codes and optional debug information > * Cleanup of the authentication extensibility model > * Change the version / protocol extensibility model > > In addition to general feedback about the drafts, I am looking for > specific feedback on the following items which I plan to address in > the next drafts: > > * Drop core support for the RSA-SHA1 method > * Replace HMAC-SHA1 with HMAC-SHA256 > * Define the authentication parameters as method-specific (for > example, drop nonce and timestamp from PLAINTEXT) > * The proposed Problem Reporting extension [1], its richness and > complexity > * Making the HMAC signature method required for all server > implementations > * Changing the delegation flow to require HTTP POST instead of > recommending it > * Mandating server support for all three parameter transmission > methods > * Adding a token revocation endpoint > * Adding the ability for servers to declare their configuration > (methods, etc.) in the WWW-Authenticate header response > * The value of the client credentials (Consumer Key) and feedback > from actual implementation experience > > In order for your feedback to be included or considered for the next > revisions it must be received by 10/2 on the oauth@ietf.org list. > > EHL > > [1] http://wiki.oauth.net/ProblemReporting > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Mark Nottingham http://www.mnot.net/ From jpanzer@google.com Thu Oct 8 00:09:19 2009 Return-Path: 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 18E6E3A6A31 for ; Thu, 8 Oct 2009 00:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 iW6N4xjdPBKB for ; Thu, 8 Oct 2009 00:09:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C89F23A6A37 for ; Thu, 8 Oct 2009 00:09:17 -0700 (PDT) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n987AwBI013119 for ; Thu, 8 Oct 2009 00:10:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254985859; bh=sPcrkZrzKhjDJ8xKljuRafymLnU=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=WXB6i/ wPjqJ+uCtYWqw/MrbV5mQYCbz1omAd8E6bUozPEAEPzNdYkxzwjtx3IryAsCInSi3Nc GuxJDxQP7oKrQ== 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=pgyMcxJ8ibN/bs0mFgZU47fASZeP4TrjL2JVf9ezh9uFlSqgL7n2689II8MNZpdI/ GG9LzfTVzEVjN4VgbHCXA== Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by zps18.corp.google.com with ESMTP id n987AtU5021439 for ; Thu, 8 Oct 2009 00:10:56 -0700 Received: by qyk29 with SMTP id 29so5396222qyk.32 for ; Thu, 08 Oct 2009 00:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.83 with SMTP id w19mr470652qco.72.1254985855432; Thu, 08 Oct 2009 00:10:55 -0700 (PDT) In-Reply-To: <5BFD6F3E-4A66-4C7B-98FF-8D2C286977B3@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5BFD6F3E-4A66-4C7B-98FF-8D2C286977B3@mnot.net> From: John Panzer Date: Thu, 8 Oct 2009 00:10:35 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=0023544716dc1c77ee0475672a38 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 07:09:19 -0000 --0023544716dc1c77ee0475672a38 Content-Type: text/plain; charset=ISO-8859-1 One minor meta-comment: -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Oct 7, 2009 at 9:15 PM, Mark Nottingham wrote: > Digging up some feedback I sent privately a long while back WRT problem > reporting (so apologies if the drafts have move on since)... > ... > * parameter_rejected - Unrecognised parameters should be ignored; see > Postel. > You're probably not advocating this, but: Postel's Law applied blindly to security protocols can lead to disaster. --0023544716dc1c77ee0475672a38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One minor meta-comment:
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Wed, Oct 7, 2009 at 9:15 PM, Mark Not= tingham <mnot@mnot.ne= t> wrote:
Digging up some feedback I sent privately a long while back WRT problem rep= orting (so apologies if the drafts have move on since)...
...
* parameter_rejected - Unrecognised parameters should be ignored; see
Postel.

You're probably not advocating this, b= ut: Postel's Law applied blindly to security protocols can lead to disa= ster.

--0023544716dc1c77ee0475672a38-- From stpeter@stpeter.im Thu Oct 8 11:16:16 2009 Return-Path: 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 421433A692D for ; Thu, 8 Oct 2009 11:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599] 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 yH2jYJKOkqjL for ; Thu, 8 Oct 2009 11:16:15 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4B6FA3A69BC for ; Thu, 8 Oct 2009 11:16:15 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AECBD40D1F for ; Thu, 8 Oct 2009 12:17:57 -0600 (MDT) Message-ID: <4ACE2CD4.3050003@stpeter.im> Date: Thu, 08 Oct 2009 12:17:56 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Working Group Last Call for draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 18:16:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This message announces a Working Group Last Call regarding draft-hammer-oauth, to end on Friday, October 30, 2009. http://tools.ietf.org/html/draft-hammer-oauth-03 Please note that this Internet-Draft is not an official work item of the OAuth WG and that its intended status is Informational RFC. The specification documents the protocol known as "OAuth Core 1.0 Revision A" and should be conceptually the same as http://oauth.net/core/1.0a with some editorial reformatting and with some small changes that address several reported errata. Because this specification is informational, any requested changes will probably be limited to matters of technical accuracy and clarity; more substantive comments will be addressed through modifications to the standards-track documents draft-ietf-oauth-authentication and draft-ietf-oauth-web-delegation, which are official work items of the OAuth WG. Your review of this specification is appreciated so that we can provide a complete working group report to our Area Director. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrOLNQACgkQNL8k5A2w/vwaUwCdF5IAlntct1xRUH1lq90J04Hu csUAn24icgAzWAJWspkjz2EW+0b/jXVA =WdhN -----END PGP SIGNATURE----- From esjewett@gmail.com Fri Oct 9 15:58:09 2009 Return-Path: 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 6D2DD3A69BC for ; Fri, 9 Oct 2009 15:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 hOklPma2qXig for ; Fri, 9 Oct 2009 15:58:08 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 75DF33A69DB for ; Fri, 9 Oct 2009 15:58:08 -0700 (PDT) Received: by pxi6 with SMTP id 6so8226352pxi.32 for ; Fri, 09 Oct 2009 15:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p+SuxPgaRhksWuQrjQ1Oml+bDg/XTsVh8xWll/wJgFs=; b=f/qXsKpVzhX81EaZnadzPTY4mN0VA8A39SoGExNcbINqt6X6Lg9PXZ6CQ4EnwdJ7wn FqrO4Nq0uLBvVBbdfCXIPMJzUxf81iVYYfQ6A8FPv+ShcaLjI1QmNe/AZZ2iaXKUy+yK yJruMWK/g4v2pUiyu2A1K2hecpEwkbodN56XQ= 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:content-transfer-encoding; b=IbihdsBWwFc81406bx6zZJEUdYJHLQ8ZzQvtjRvlrEfgs7fIdstTEOfHUVM4Dj2g3n QOEk3fd27cmibSMkEiLFlxlmEqgb6/HT/T6v464eqJJx+KDRJRtqkR2gOoxgIRdG4kuN oFvx2XQKWR6u6MkJd9Tg2pPLL1oTM55WYRUec= MIME-Version: 1.0 Received: by 10.140.165.13 with SMTP id n13mr267773rve.92.1255129193214; Fri, 09 Oct 2009 15:59:53 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 9 Oct 2009 17:59:53 -0500 Message-ID: <68f4a0e80910091559t70a33f5cqab531d16c273c4c1@mail.gmail.com> From: Ethan Jewett To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Delegation (token) requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:58:09 -0000 Some thoughts on this: #1 vs. #2 Going with #1 as the standard and #2 as an optional extension makes sense t= o me. #3 With regards to #3, I'm skeptical of the existence of common use cases where it is acceptable for an app to have access to a user's credentials. I have seen a lot of these bandied about, but they usually amount to "The app/website is made by a trusted party, so it's ok for the user to provide his/her password." I think there are a couple of issues here: 1) Why should the party be trusted if the same thing can be accomplished without trusting the party with the credentials. Most of the Twitter account hijackings have been because people have trusted untrustworthy apps with their credentials. The fact seems to be that "trusted" =3D "everybody else is doing it". I don't think we should make this an option in this case. 2) This argument is often made in the case of official apps for websites. In this case the argument is incorrect in my opinion. The app (and by extension the trusted party) does not control the platform so the app cannot inherit the trust associated with the trusted party. Are these the use-cases that you had in mind? Am I being too methodologically pure here? Security in the transport layer for token exchange: It seems that in a client that can actually protect the consumer secret it is a nice bonus to be able to pass tokens in the clear and dispense with the overhead of SSL/TLS. For clients that can't protect the consumer secret (any installed application), then yes, I think it makes a lot of sense to require a secure connection for the token exchange. Should it also be made explicit that the consumer secret can be dispensed with in this situation? Ethan On Tue, Oct 6, 2009 at 4:07 PM, Eran Hammer-Lahav wro= te: > There are three well-defined methods for obtaining a token: > > 1. Web Delegation (2 steps) - user is redirected to the server, authorize= s, redirected back to client with token. > 2. Web Delegation (3 steps) - client obtains temporary credentials, user = authorizes at the server, client exchanges temporary credentials for token. > 3. Direct Request - client uses the user's username and password to reque= st for a token. > > OAuth Core 1.0 supports the #2 option only. There is clear demand for the= other two methods. > > Many large providers I talked to would like to have #1 to get rid of the = temporary credentials (request token). The vast majority of the temporary c= redentials are never used and waste resources. The 3-steps flow was created= to address clients which are unable to receive redirections and therefore = have no way to get the token back from the server. > > Many developers have asked for #3 for cases where it is perfectly accepta= ble for an application to have access to the user's credentials, but still = provide a single OAuth-based API. This has been also raised in cases where = opening a browser is poor or unacceptable user experience. > > When making a token request, the client may be required to authenticate i= tself (using its client credentials). The authentication method is either a= shared secret or PK-based. > > When sending a token, the server should use a secure channel to ensure th= e token credentials remain confidential. > > When using a shared-secret over a secure channel, there is no reason to s= ign the request and simply including the secret is enough. If a PK is used,= the request has to be signed in some way even over a secure channel (becau= se there is nothing else to send with the request). > > Questions: > > - Are there use cases where the 3-step flow (#2) is needed? > - Should we require use of HTTPS for token requests? > - If it is ok for tokens to be sent unsecure, is it also ok to send clien= t secrets unsecure? > - How should a PK option work? What should be signed? How should it work = over a secure channel? > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From romeda@gmail.com Sun Oct 11 02:04:22 2009 Return-Path: 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 C732E3A67C2 for ; Sun, 11 Oct 2009 02:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] 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 nDndsh4DkvbO for ; Sun, 11 Oct 2009 02:04:21 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 6901E3A67C0 for ; Sun, 11 Oct 2009 02:04:21 -0700 (PDT) Received: by bwz6 with SMTP id 6so2524272bwz.37 for ; Sun, 11 Oct 2009 02:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=TQbu2ur4GEeGSRIin6W/GIqGDL/ReMizY1P8NAp3BVw=; b=XpKM+lIov4yxTdhlenRbtpDyeUdAwaewx7O/dN/Zpap/8avEAI9XXCwb9QpWwZF4EL kRiWXX6O0aKhi+IeHN9KVdgL8arKHGrkIyKvOGA6cCoBZNY0r05pq81OjBtVOVZL16nQ 6JyeoTkzwptnBIsRb88AXrjeyd8sX1Ia0BL10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=qDxUxFZxPeTpYv0Zkc3P1bdiBV8WlG/9MAFl8yLRmYaFm96vutUpapnRsw2/ciYbfW /WM0kWN147N2kEVaJGvNJP2Qs+8wr+5LsUFA2ocM+BfgEKGPw1WWD25nHUyAfoX26opx 22dW0uFVHqCFDDzcs1MdNiyBiqOQGNkN6hJ1Y= MIME-Version: 1.0 Received: by 10.103.84.25 with SMTP id m25mr1895480mul.111.1255251967074; Sun, 11 Oct 2009 02:06:07 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Sun, 11 Oct 2009 10:05:47 +0100 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Delegation (token) requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 09:04:22 -0000 2009/10/6 Eran Hammer-Lahav : > There are three well-defined methods for obtaining a token: > > Many large providers I talked to would like to have #1 to get rid of the = temporary credentials (request token). The vast majority of the temporary c= redentials are never used and waste resources. The 3-steps flow was created= to address clients which are unable to receive redirections and therefore = have no way to get the token back from the server. The wasted resources argument is a red herring. I'd like to see some math supporting that argument, because frankly, in a world where Google can afford to scan and host 10 million books using 10 MP digital photos (that's ca. 1 billion 16 MB files), they (and Yahoo) can (easily) afford to store a few million tokens. These tokens can be safely expired within an hour. > Many developers have asked for #3 for cases where it is perfectly accepta= ble for an application to have access to the user's credentials, but still = provide a single OAuth-based API. This has been also raised in cases where = opening a browser is poor or unacceptable user experience. I have yet to see a study suggesting that opening a browser is actually a poor or unacceptable user experience. I've seen developers complain about it, but I have yet to see a credible report from an actual user that it's a difficult experience, or results in dropped conversion rates. I'd love to see Flickr's numbers on this, as they could have gone the username / password route, but chose to go with the browser redirect flow for their own iPhone app, and I've seen nothing but positive reviews there. I'm not saying that I'm 100% opposed to this flow. What I am saying is that the arguments being used for it are bunk, and I want those making them to provide real evidence for their claims. We're talking about changing the protocol here, and the burden is on those interested in changing it to support their arguments. > Questions: > > - Are there use cases where the 3-step flow (#2) is needed? Yes. There are a number of apps using it. YouTube, Flickr (the flow, not specifically OAuth), Netflix (see their XBox integration), and virtually all desktop-based Twitter applications. Desktop apps that do not want to take a password or *can't* take a password (e.g., digital picture frames, devices without keyboards or screens) require the 3-step flow. > - Should we require use of HTTPS for token requests? It should remain as-is, a SHOULD, but those sites that cannot / will not support HTTPS obviously need a way to use OAuth. > - If it is ok for tokens to be sent unsecure, is it also ok to send clien= t secrets unsecure? Client secrets distributed to devices or desktops must always be assumed to be compromised. They're inherently not protectable (see: DeCSS etc). Client secrets sent to 3rd party services where there is a reasonable assumption that those services can maintain secrecy *must* be sent over secure channels. > - How should a PK option work? What should be signed? How should it work = over a secure channel? As far as I'm concerned, the fact that the PK option doesn't involve signing the token secret was an oversight and should be corrected to be the same as the HMAC-SHA1 flow. b. From pelleb@gmail.com Tue Oct 13 13:00:25 2009 Return-Path: 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 2123628C33E for ; Tue, 13 Oct 2009 13:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 Qhywv11KVWGe for ; Tue, 13 Oct 2009 13:00:24 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id C1A203A67ED for ; Tue, 13 Oct 2009 12:59:47 -0700 (PDT) Received: by fxm28 with SMTP id 28so8857966fxm.42 for ; Tue, 13 Oct 2009 12:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=MCkD9vcFd0ZLr5NSmBiHF7MGrcpS2t7aRm5L2olrYVk=; b=jnmu1Yj5W0B4iSEQ9cjkQrcKBa8v5jn7YdGAY25QrcFGbdMiYIJ9Vgt/U7irCzm0L9 Qzw6FpQ69M5WEqnIBicdMrIkwGFNHwFY8ysPy61HGm9csYaPDZfiXkeh8c2F5b+9qz+M PaYAGWhL799YueZroFid9oyUiUDMmUq5vtlTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=AxJXJUbRF7KBdywJ90l+Xn/TdIhAkHbyEL2b5yoNpakgHgMg386RlArhDaBdZnDKAc ZhGKpuk4rQ6IfZj8YpokeoBPagh+iSbt1ZA2GVkRAVvaWs9woQIQ925x/LWxbcSC5HCi YC/iKK5hYn9HmelXw+5tSHa3Nz7shCQgjeW8Q= MIME-Version: 1.0 Sender: pelleb@gmail.com Received: by 10.223.4.137 with SMTP id 9mr233318far.95.1255463986150; Tue, 13 Oct 2009 12:59:46 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 13 Oct 2009 15:59:45 -0400 X-Google-Sender-Auth: ebf3a6c1126ebb34 Message-ID: From: Pelle Braendgaard To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Delegation (token) requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 20:14:21 -0000 On Sun, Oct 11, 2009 at 5:05 AM, Blaine Cook wrote: > 2009/10/6 Eran Hammer-Lahav : >> There are three well-defined methods for obtaining a token: >> >> Many large providers I talked to would like to have #1 to get rid of the= temporary credentials (request token). The vast majority of the temporary = credentials are never used and waste resources. The 3-steps flow was create= d to address clients which are unable to receive redirections and therefore= have no way to get the token back from the server. > > The wasted resources argument is a red herring. I'd like to see some > math supporting that argument, because frankly, in a world where > Google can afford to scan and host 10 million books using 10 MP > digital photos (that's ca. 1 billion 16 MB files), they (and Yahoo) > can (easily) afford to store a few million tokens. These tokens can be > safely expired within an hour. I have to agree with Blaine about the wasted resources issue. However anything that can be done to simplifying the process for developers without infringing on security is a step up. People are unfortunately still very confused about the 3 step process. So I would not mind this as the default implementation, but I'd probably still want the 3 step for when its a better fit. I am also completely against the username password approach. This goes completely against what OAuth is about. >> - Should we require use of HTTPS for token requests? > > It should remain as-is, a SHOULD, but those sites that cannot / will > not support HTTPS obviously need a way to use OAuth. I do prefer https, but as Blaine says we should leave it in. It would be a good idea to create an official list of best practices separate from the official standard. >> - How should a PK option work? What should be signed? How should it work= over a secure channel? > > As far as I'm concerned, the fact that the PK option doesn't involve > signing the token secret was an oversight and should be corrected to > be the same as the HMAC-SHA1 flow. Agreed. How though. Adding it to the SBS? Doing a hmac signature first (- consumer secret) and then signing that with the key? BTW. Here is an interesting thread on the Twitter Dev list showing some of the issues developers perceive rightly or wrongly about OAuth: http://groups.google.com/group/twitter-development-talk/browse_thread/threa= d/c4a8637359b25683 P --=20 http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Legal world http://stakeventures.com - Bootstrapping blog From mnot@mnot.net Tue Oct 13 20:19:03 2009 Return-Path: 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 3D9A528C0D6 for ; Tue, 13 Oct 2009 20:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.882 X-Spam-Level: X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599] 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 v58TrtJWtB5Y for ; Tue, 13 Oct 2009 20:19:02 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 54AC93A684F for ; Tue, 13 Oct 2009 20:19:02 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.5.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 31344509D9; Tue, 13 Oct 2009 23:18:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: Date: Wed, 14 Oct 2009 14:18:51 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5BFD6F3E-4A66-4C7B-98FF-8D2C286977B3@mnot.net> To: John Panzer X-Mailer: Apple Mail (2.1076) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 03:19:03 -0000 So, Postel aside, rejecting any request with unrecognised parameters in it will rule out any backwards-compatible extensions to the protocol (practically; although the client can re-submit the request without the parameter, it disincents the introduction of backwards- compatible features). Does the OAuth community really want to do this? And, what's the attack vector that is protected against here? Cheers, On 08/10/2009, at 6:10 PM, John Panzer wrote: > One minor meta-comment: > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > On Wed, Oct 7, 2009 at 9:15 PM, Mark Nottingham wrote: > Digging up some feedback I sent privately a long while back WRT > problem reporting (so apologies if the drafts have move on since)... > ... > * parameter_rejected - Unrecognised parameters should be ignored; see > Postel. > > You're probably not advocating this, but: Postel's Law applied > blindly to security protocols can lead to disaster. > -- Mark Nottingham http://www.mnot.net/ From faynberg@alcatel-lucent.com Tue Oct 13 22:03:49 2009 Return-Path: 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 8EFC03A684F for ; Tue, 13 Oct 2009 22:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 D6YA1owh+vpe for ; Tue, 13 Oct 2009 22:03:48 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 8DFB93A685D for ; Tue, 13 Oct 2009 22:03:48 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n9E53jBo011119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Oct 2009 00:03:46 -0500 (CDT) Received: from [135.244.0.107] (faynberg.lra.lucent.com [135.244.0.107]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n9E53iqO025284; Wed, 14 Oct 2009 00:03:45 -0500 (CDT) Message-ID: <4AD55BB1.90309@alcatel-lucent.com> Date: Wed, 14 Oct 2009 01:03:45 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Nottingham References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5BFD6F3E-4A66-4C7B-98FF-8D2C286977B3@mnot.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 05:03:49 -0000 I tend to agree with Mark in that I don't see a security threat that could explore an act of ignoring a parameter. Igor Mark Nottingham wrote: > So, Postel aside, rejecting any request with unrecognised parameters > in it will rule out any backwards-compatible extensions to the > protocol (practically; although the client can re-submit the request > without the parameter, it disincents the introduction of > backwards-compatible features). > > Does the OAuth community really want to do this? And, what's the > attack vector that is protected against here? > > Cheers, > > > On 08/10/2009, at 6:10 PM, John Panzer wrote: > >> One minor meta-comment: >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer >> >> >> >> On Wed, Oct 7, 2009 at 9:15 PM, Mark Nottingham wrote: >> Digging up some feedback I sent privately a long while back WRT >> problem reporting (so apologies if the drafts have move on since)... >> ... >> * parameter_rejected - Unrecognised parameters should be ignored; see >> Postel. >> >> You're probably not advocating this, but: Postel's Law applied >> blindly to security protocols can lead to disaster. >> > > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Oct 15 15:06:54 2009 Return-Path: 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 020223A68CD for ; Thu, 15 Oct 2009 15:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 CVYd4FWemEvi for ; Thu, 15 Oct 2009 15:06:53 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 135D03A682B for ; Thu, 15 Oct 2009 15:06:53 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A10984038E for ; Thu, 15 Oct 2009 16:06:56 -0600 (MDT) Message-ID: <4AD79CFF.7040803@stpeter.im> Date: Thu, 15 Oct 2009 16:06:55 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] IETF 76 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 22:06:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As Lisa Dusseault expressed it in her September activity report, we didn't have a critical mass of participation until quite recently in the OAuth WG, so the chairs did not request a session in Hiroshima (we didn't want to take up valuable time on the schedule if we could not hold a meeting that would attract a large number of active participants). Now that the WG has become more active, the chairs will definitely push to hold a meeting in Anaheim. However, I think it might also be productive to hold an informal meeting (Bar BoF) in Hiroshima. If you would like to participate in such a meeting, please post to the list so that the chairs can gauge the level of interest. Thanks, Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrXnP8ACgkQNL8k5A2w/vy6nACgtcIQ3CBfNuKhYlL7PW5nWAkH EGEAnikGKhFFrnmV7X9xe1NDnyrLOspK =1UhJ -----END PGP SIGNATURE----- From faynberg@alcatel-lucent.com Thu Oct 15 22:58:19 2009 Return-Path: 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 387A43A6783 for ; Thu, 15 Oct 2009 22:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 HSWKkStRoF8s for ; Thu, 15 Oct 2009 22:58:18 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 4391F3A67D1 for ; Thu, 15 Oct 2009 22:58:17 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n9G5wHbt011865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2009 00:58:17 -0500 (CDT) Received: from [135.244.32.233] (faynberg.lra.lucent.com [135.244.32.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n9G5wEwV015416; Fri, 16 Oct 2009 00:58:16 -0500 (CDT) Message-ID: <4AD80B76.6010700@alcatel-lucent.com> Date: Fri, 16 Oct 2009 01:58:14 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Saint-Andre References: <4AD79CFF.7040803@stpeter.im> In-Reply-To: <4AD79CFF.7040803@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: OAuth WG Subject: Re: [OAUTH-WG] IETF 76 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 05:58:19 -0000 Peter, I am posting to the list to move the gauge in the positive direction, but I am surprised with this "absence of critical mass" assessment. First, if there had not been critical mass, the group would not have been chartered. But once it was chartered, it had no meeting, so how could one determine what mass it actually has (and whether this mass is critical)? Second, there has been a substantial amount of discussion on the mailing list, and it is clear that the group already has a lot on its plate. Personally, I think that the real meeting ought to be scheduled so that people can plan for it and attend it, which is much harder to do with these bar BoFs that don't get scheduled until the last moment when it is very hard to find time. The whole idea of the IETF meetings is to, well... to have meetings of working groups to progress work. Igor Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > As Lisa Dusseault expressed it in her September activity report, we > didn't have a critical mass of participation until quite recently in the > OAuth WG, so the chairs did not request a session in Hiroshima (we > didn't want to take up valuable time on the schedule if we could not > hold a meeting that would attract a large number of active > participants). Now that the WG has become more active, the chairs will > definitely push to hold a meeting in Anaheim. However, I think it might > also be productive to hold an informal meeting (Bar BoF) in Hiroshima. > If you would like to participate in such a meeting, please post to the > list so that the chairs can gauge the level of interest. > > Thanks, > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrXnP8ACgkQNL8k5A2w/vy6nACgtcIQ3CBfNuKhYlL7PW5nWAkH > EGEAnikGKhFFrnmV7X9xe1NDnyrLOspK > =1UhJ > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hubertlvg@gmail.com Fri Oct 16 00:13:01 2009 Return-Path: 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 DC7C73A68A2 for ; Fri, 16 Oct 2009 00:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iyZWCNwvIhr3 for ; Fri, 16 Oct 2009 00:13:00 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 9D1783A689A for ; Fri, 16 Oct 2009 00:13:00 -0700 (PDT) Received: by ewy4 with SMTP id 4so1306956ewy.37 for ; Fri, 16 Oct 2009 00:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a47K2/HyvfDKv2n0aXVhTlNCDi+6l4OivGoJHhWv2JQ=; b=HXAEIfbOL0m7WB5h76jtG7MsagzqXXzctvQItVlWdueFrMXvvtWNbRZWqDG46tKWSm DflEt2SUmuXTOC0wKoDyOykOj06nrwSwGFPNGYTDhnKf/DV4sNFUzHSvuMkuVjZXwSX6 OPr042Xfdh7YG9jLtblFH47qnrFsCkazQHvzc= 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:content-transfer-encoding; b=V2faAlXDUwvR4CODupumjuCfP5z84eIFinlUqYZA0+Jm+GA37OpwPHq7meD7lvWYjw e9KIRcnshQQNGZGdJPg5irukYuWp9UKfAiOezK3aDzK7JX6NGVbZ23BiXDtvTJ4la52o 4ckOJUNgo9d9R/vXGK2AGEhAqi7A0pp6az8I0= MIME-Version: 1.0 Received: by 10.211.132.22 with SMTP id j22mr441560ebn.24.1255677182504; Fri, 16 Oct 2009 00:13:02 -0700 (PDT) In-Reply-To: <4AD80B76.6010700@alcatel-lucent.com> References: <4AD79CFF.7040803@stpeter.im> <4AD80B76.6010700@alcatel-lucent.com> Date: Fri, 16 Oct 2009 09:13:02 +0200 Message-ID: <6c0fd2bc0910160013h6120a4d4qafb3a7d68acea4dd@mail.gmail.com> From: Hubert Le Van Gong To: faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] IETF 76 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 07:13:01 -0000 +1 Also, could we please have the date & location of those meetings? Cheers, Hubert On Fri, Oct 16, 2009 at 7:58 AM, Igor Faynberg wrote: > Peter, > > I am posting to the list to move the gauge in the positive direction, but= I > am surprised with this "absence of critical mass" assessment. > > First, if there had not been critical mass, the group would not have been > chartered. But once it was chartered, it had no meeting, so how could one > determine what mass it actually has (and whether this mass is critical)? > Second, there has been a substantial amount of discussion on the mailing > list, and it is clear that the group already has a lot on its plate. > > Personally, I =A0think that the real meeting ought to be scheduled so tha= t > people can plan for it and attend it, which is much harder to do with the= se > bar BoFs that don't get scheduled until the last moment when it is very h= ard > to find time. The whole idea of the IETF meetings is to, well... to have > meetings of working groups to progress work. > > Igor > > Peter Saint-Andre wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> As Lisa Dusseault expressed it in her September activity report, we >> didn't have a critical mass of participation until quite recently in the >> OAuth WG, so the chairs did not request a session in Hiroshima (we >> didn't want to take up valuable time on the schedule if we could not >> hold a meeting that would attract a large number of active >> participants). Now that the WG has become more active, the chairs will >> definitely push to hold a meeting in Anaheim. However, I think it might >> also be productive to hold an informal meeting (Bar BoF) in Hiroshima. >> If you would like to participate in such a meeting, please post to the >> list so that the chairs can gauge the level of interest. >> >> Thanks, >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkrXnP8ACgkQNL8k5A2w/vy6nACgtcIQ3CBfNuKhYlL7PW5nWAkH >> EGEAnikGKhFFrnmV7X9xe1NDnyrLOspK >> =3D1UhJ >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 > From rbarnes@bbn.com Fri Oct 16 12:25:17 2009 Return-Path: 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 804283A67B8 for ; Fri, 16 Oct 2009 12:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599] 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 RJA3fQbL55RL for ; Fri, 16 Oct 2009 12:25:16 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6CB8E3A67B1 for ; Fri, 16 Oct 2009 12:25:16 -0700 (PDT) Received: from ros-dhcp192-1-51-71.bbn.com ([192.1.51.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MyrUM-0007xi-F3; Fri, 16 Oct 2009 14:25:18 -0400 Message-ID: <4AD8C89F.5040000@bbn.com> Date: Fri, 16 Oct 2009 15:25:19 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: faynberg@alcatel-lucent.com References: <4AD79CFF.7040803@stpeter.im> <4AD80B76.6010700@alcatel-lucent.com> In-Reply-To: <4AD80B76.6010700@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] IETF 76 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:25:17 -0000 +1 Peter: Maybe you could contact the secretariat to see if you might still be able to get a meeting slot? (After doing appropriate penance for being late ... :) ) --Richard Igor Faynberg wrote: > Peter, > > I am posting to the list to move the gauge in the positive direction, > but I am surprised with this "absence of critical mass" assessment. > > First, if there had not been critical mass, the group would not have > been chartered. But once it was chartered, it had no meeting, so how > could one determine what mass it actually has (and whether this mass is > critical)? Second, there has been a substantial amount of discussion > on the mailing list, and it is clear that the group already has a lot on > its plate. > > Personally, I think that the real meeting ought to be scheduled so that > people can plan for it and attend it, which is much harder to do with > these bar BoFs that don't get scheduled until the last moment when it is > very hard to find time. The whole idea of the IETF meetings is to, > well... to have meetings of working groups to progress work. > > Igor > > Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> As Lisa Dusseault expressed it in her September activity report, we >> didn't have a critical mass of participation until quite recently in the >> OAuth WG, so the chairs did not request a session in Hiroshima (we >> didn't want to take up valuable time on the schedule if we could not >> hold a meeting that would attract a large number of active >> participants). Now that the WG has become more active, the chairs will >> definitely push to hold a meeting in Anaheim. However, I think it might >> also be productive to hold an informal meeting (Bar BoF) in Hiroshima. >> If you would like to participate in such a meeting, please post to the >> list so that the chairs can gauge the level of interest. >> >> Thanks, >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkrXnP8ACgkQNL8k5A2w/vy6nACgtcIQ3CBfNuKhYlL7PW5nWAkH >> EGEAnikGKhFFrnmV7X9xe1NDnyrLOspK >> =1UhJ >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 > From llynch@civil-tongue.net Fri Oct 16 12:32:27 2009 Return-Path: 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 88DFE28C0E5 for ; Fri, 16 Oct 2009 12:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WvGPSZ10teIn for ; Fri, 16 Oct 2009 12:32:27 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id 0929D3A67B8 for ; Fri, 16 Oct 2009 12:32:26 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id n9GJWGlB076706; Fri, 16 Oct 2009 12:32:17 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id n9GJWGww076703; Fri, 16 Oct 2009 12:32:16 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Fri, 16 Oct 2009 12:32:16 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Richard Barnes In-Reply-To: <4AD8C89F.5040000@bbn.com> Message-ID: References: <4AD79CFF.7040803@stpeter.im> <4AD80B76.6010700@alcatel-lucent.com> <4AD8C89F.5040000@bbn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: OAuth WG Subject: Re: [OAUTH-WG] IETF 76 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:32:27 -0000 On Fri, 16 Oct 2009, Richard Barnes wrote: > +1 me too > Peter: Maybe you could contact the secretariat to see if you might still be > able to get a meeting slot? (After doing appropriate penance for being late > ... :) ) > > --Richard > > > > Igor Faynberg wrote: >> Peter, >> >> I am posting to the list to move the gauge in the positive direction, but I >> am surprised with this "absence of critical mass" assessment. >> >> First, if there had not been critical mass, the group would not have been >> chartered. But once it was chartered, it had no meeting, so how could one >> determine what mass it actually has (and whether this mass is critical)? >> Second, there has been a substantial amount of discussion on the mailing >> list, and it is clear that the group already has a lot on its plate. >> >> Personally, I think that the real meeting ought to be scheduled so that >> people can plan for it and attend it, which is much harder to do with these >> bar BoFs that don't get scheduled until the last moment when it is very >> hard to find time. The whole idea of the IETF meetings is to, well... to >> have meetings of working groups to progress work. >> >> Igor >> >> Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> >>> As Lisa Dusseault expressed it in her September activity report, we >>> didn't have a critical mass of participation until quite recently in the >>> OAuth WG, so the chairs did not request a session in Hiroshima (we >>> didn't want to take up valuable time on the schedule if we could not >>> hold a meeting that would attract a large number of active >>> participants). Now that the WG has become more active, the chairs will >>> definitely push to hold a meeting in Anaheim. However, I think it might >>> also be productive to hold an informal meeting (Bar BoF) in Hiroshima. >>> If you would like to participate in such a meeting, please post to the >>> list so that the chairs can gauge the level of interest. >>> >>> Thanks, >>> >>> Peter >>> >>> - -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.8 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAkrXnP8ACgkQNL8k5A2w/vy6nACgtcIQ3CBfNuKhYlL7PW5nWAkH >>> EGEAnikGKhFFrnmV7X9xe1NDnyrLOspK >>> =1UhJ >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> 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 > From lynch@isoc.org Fri Oct 16 12:30:44 2009 Return-Path: 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 B1BCF3A68B7 for ; Fri, 16 Oct 2009 12:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9imRQZVpoql9 for ; Fri, 16 Oct 2009 12:30:40 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id E3CE828C147 for ; Fri, 16 Oct 2009 12:30:38 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id n9GJUOAD076622; Fri, 16 Oct 2009 12:30:25 -0700 (PDT) (envelope-from lynch@isoc.org) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id n9GJUOQc076619; Fri, 16 Oct 2009 12:30:24 -0700 (PDT) (envelope-from lynch@isoc.org) Date: Fri, 16 Oct 2009 12:30:24 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Richard Barnes In-Reply-To: <4AD8C89F.5040000@bbn.com> Message-ID: References: <4AD79CFF.7040803@stpeter.im> <4AD80B76.6010700@alcatel-lucent.com> <4AD8C89F.5040000@bbn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 16 Oct 2009 12:33:50 -0700 Cc: OAuth WG Subject: Re: [OAUTH-WG] IETF 76 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lynch@isoc.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:30:44 -0000 On Fri, 16 Oct 2009, Richard Barnes wrote: > +1 me too > Peter: Maybe you could contact the secretariat to see if you might still be > able to get a meeting slot? (After doing appropriate penance for being late > ... :) ) > > --Richard > > > > Igor Faynberg wrote: >> Peter, >> >> I am posting to the list to move the gauge in the positive direction, but I >> am surprised with this "absence of critical mass" assessment. >> >> First, if there had not been critical mass, the group would not have been >> chartered. But once it was chartered, it had no meeting, so how could one >> determine what mass it actually has (and whether this mass is critical)? >> Second, there has been a substantial amount of discussion on the mailing >> list, and it is clear that the group already has a lot on its plate. >> >> Personally, I think that the real meeting ought to be scheduled so that >> people can plan for it and attend it, which is much harder to do with these >> bar BoFs that don't get scheduled until the last moment when it is very >> hard to find time. The whole idea of the IETF meetings is to, well... to >> have meetings of working groups to progress work. >> >> Igor >> >> Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> >>> As Lisa Dusseault expressed it in her September activity report, we >>> didn't have a critical mass of participation until quite recently in the >>> OAuth WG, so the chairs did not request a session in Hiroshima (we >>> didn't want to take up valuable time on the schedule if we could not >>> hold a meeting that would attract a large number of active >>> participants). Now that the WG has become more active, the chairs will >>> definitely push to hold a meeting in Anaheim. However, I think it might >>> also be productive to hold an informal meeting (Bar BoF) in Hiroshima. >>> If you would like to participate in such a meeting, please post to the >>> list so that the chairs can gauge the level of interest. >>> >>> Thanks, >>> >>> Peter >>> >>> - -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.8 (Darwin) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAkrXnP8ACgkQNL8k5A2w/vy6nACgtcIQ3CBfNuKhYlL7PW5nWAkH >>> EGEAnikGKhFFrnmV7X9xe1NDnyrLOspK >>> =1UhJ >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> 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 > From stpeter@stpeter.im Mon Oct 19 10:59:11 2009 Return-Path: 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 0FF983A6919 for ; Mon, 19 Oct 2009 10:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 65nwhwVbV00H for ; Mon, 19 Oct 2009 10:59:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 13F6428C0E9 for ; Mon, 19 Oct 2009 10:58:00 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C9ACE40D0B for ; Mon, 19 Oct 2009 11:58:06 -0600 (MDT) Message-ID: <4ADCA8AD.5000808@stpeter.im> Date: Mon, 19 Oct 2009 11:58:05 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: Internet-Drafts Submission Cutoff Dates for IETF 76 in Hiroshima, Japan] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 17:59:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI regarding submission dates... - -------- Original Message -------- Subject: Internet-Drafts Submission Cutoff Dates for IETF 76 in Hiroshima, Japan Date: Mon, 19 Oct 2009 10:41:50 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list There are two (2) Internet-Draft cutoff dates for IETF 76 in Hiroshima, Japan. * Monday, October 19, 2009 (17:00 PDT; 24:00 UTC/GMT): Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate working group chair before they can be processed or announced. * Monday, October 26 (17:00 PDT; 24:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, November 9, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. The Internet-Draft cutoff dates as well as other significant dates for IETF 76 can be found at: http://www.ietf.org/meeting/cutoff-dates.html#76 The Internet-Draft submission tool can be found at: https://datatracker.ietf.org/idst/upload.cgi Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrcqK0ACgkQNL8k5A2w/vzFFACg6i+UqMeLlkNXfnkgIJbAYG+R U7cAmwXP5Kz8l08aRpSpgVC+qMSEwjjA =1/9p -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Oct 19 11:01:02 2009 Return-Path: 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 985893A692D for ; Mon, 19 Oct 2009 11:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 GvGLXS3q1uRk for ; Mon, 19 Oct 2009 11:01:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 73EB83A68D0 for ; Mon, 19 Oct 2009 11:00:58 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 98AAF40D0B for ; Mon, 19 Oct 2009 12:01:05 -0600 (MDT) Message-ID: <4ADCA960.7080904@stpeter.im> Date: Mon, 19 Oct 2009 12:01:04 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: I-D Action:draft-beck-oauth-sip-eval-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 18:01:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Of interest, as seen on the I-D-announce list... /psa - -------- Original Message -------- Subject: I-D Action:draft-beck-oauth-sip-eval-00.txt Date: Mon, 19 Oct 2009 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluating OAUTH's suitability for SIP authentication Author(s) : W. Beck Filename : draft-beck-oauth-sip-eval-00.txt Pages : 12 Date : 2009-10-19 The Open Authentication Protocol (OAUTH) provides a method for clients to access server resources on behalf of another party. This document evaluates OAUTH's suitability as an authentication mechanism for the Session Initiation Protocol (SIP) for use cases where web applications want to interact with SIP servers without sharing user credentials. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-beck-oauth-sip-eval-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrcqWAACgkQNL8k5A2w/vy2SwCgz/pPAvDPJQUd90uTbhCmgWUN OeQAn0FrI+Ctui3UM0any6RioSJCcvBl =wKw1 -----END PGP SIGNATURE----- From BeckW@telekom.de Tue Oct 20 07:57:58 2009 Return-Path: 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 A3A5B3A6A1B for ; Tue, 20 Oct 2009 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 O+wl8yyyARTQ for ; Tue, 20 Oct 2009 07:57:57 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 497323A69FE for ; Tue, 20 Oct 2009 07:57:53 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 20 Oct 2009 16:57:56 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 16:57:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 16:57:55 +0200 Message-ID: <4A956CE47D1066408D5C7EB34368A51105303AE8@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: I-D Action:draft-beck-oauth-sip-eval-00.txt Thread-Index: AcpRlbPtRkyUDZX4SjOO261o+J3ZlA== From: To: X-OriginalArrivalTime: 20 Oct 2009 14:57:55.0982 (UTC) FILETIME=[B4DCB2E0:01CA5195] Subject: [OAUTH-WG] Fwd: I-D Action:draft-beck-oauth-sip-eval-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 14:57:58 -0000 Hi, When submitting a draft that combines two areas, it's always the = question which WG should deal with it. If there is enough interest, one = of the SIP WGs might provide requirements and OAUTH might do the = necessary definitions/additions to the protocol. If there aren't any unforeseen travel budget cuts, I'll be in Hiroshima = and visit the proposed OAUTH meeting, be it official or just informal. Looking forward to your feedback, Wolfgang -- Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Wolfgang Beck Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 +49 6151 6282832 (Tel.)=20 E-Mail: beckw@telekom.de=20 http://www.telekom.com=20 Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 From Pasi.Eronen@nokia.com Fri Oct 23 02:47:02 2009 Return-Path: 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 5D39C3A67EB; Fri, 23 Oct 2009 02:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 gyRK8RfTSfD5; Fri, 23 Oct 2009 02:47:01 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C6A663A6767; Fri, 23 Oct 2009 02:47:00 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9N9l3FZ007214; Fri, 23 Oct 2009 12:47:08 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 12:46:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 12:46:51 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 23 Oct 2009 11:46:50 +0200 From: To: , Date: Fri, 23 Oct 2009 11:46:49 +0200 Thread-Topic: Join the MashSSL Incubator Group (Call for Participation) Thread-Index: AcpTsEr7eU1574EtTp2SbCUO3PXKMgAFRENQ Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09B0BB76@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2009 09:46:51.0207 (UTC) FILETIME=[BF074D70:01CA53C5] X-Nokia-AV: Clean Subject: [OAUTH-WG] FW: Join the MashSSL Incubator Group (Call for Participation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 09:47:02 -0000 This is probably of interest to TLS and OAUTH WG members... Best regards, Pasi Begin forwarded message: > From: Ian Jacobs > Date: October 22, 2009 5:38:31 PM EDT > To: W3C Members > Subject: Join the MashSSL Incubator Group (Call for Participation) > Archived-At: E56D78D1-6160-4085-89E1-3EC465612C5B@w3.org> > > Dear Advisory Committee Representative, > > This is a Call for Participation in the MashSSL Incubator Group [1], > part of > the Incubator Activity [2]. > > The mission of this group is to create an open security protocol to > solve a fundamental Internet security problem. Specifically, when two > web applications communicate through a potentially untrusted user they > do not have any standard way of mutually authenticating each other and > establishing a trusted channel. The group seeks to create an open, > secure standard standard for solving this problem. > > If your organization wishes to join this group, please first > review the charter: > http://www.w3.org/2005/Incubator/MashSSL/charter > > Then use the following online form to join the group; > the form will also instruct you how to nominate participants: > > http://www.w3.org/2004/01/pp-impl/43924/join > > If you have any questions or need further information, please contact > the Incubator Group Chair, Siddharth Bajaj . > > Thank you, > > Mauro Nunez, Incubator Activity Lead, and > Ian Jacobs, Head of W3C Communications > > [1] http://www.w3.org/2005/Incubator/MashSSL/ > [2] http://www.w3.org/2005/Incubator/ > > -- > Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ > Tel: +1 718 260 9447 From eran@hueniverse.com Thu Oct 29 23:41:05 2009 Return-Path: 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 E6B323A688B for ; Thu, 29 Oct 2009 23:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] 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 a2BYs8cikVEz for ; Thu, 29 Oct 2009 23:41:03 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1FDDB3A66B4 for ; Thu, 29 Oct 2009 23:41:03 -0700 (PDT) Received: (qmail 32361 invoked from network); 30 Oct 2009 06:41:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Oct 2009 06:41:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 29 Oct 2009 23:41:09 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 29 Oct 2009 23:41:06 -0700 Thread-Topic: Reviewers Needed: draft-hammer-oauth-03 Thread-Index: AcpZKj5aPqE5IfGuQ3uD6HdW+xOaDQAAIh9QAAA6pEA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784FE95CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Reviewers Needed: draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 06:41:06 -0000 This just came up on the other list. I will fix this in the draft before pu= blication. I am looking for a couple of people to proof read the draft with Core 1.0a = (original copy http://oauth.net/core/1.0a) side by side and look for proble= ms. At this point I don't know of anyone (other than me) who actually check= ed the draft fully. Please help! EHL -----Original Message----- From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, October 29, 2009 11:39 PM To: oauth@googlegroups.com Subject: [oauth] Re: oauth_callback when using Authorization header? This is a good question. I assume you are reading the latest version (draft-hammer-oauth-03): http://tools.ietf.org/html/draft-hammer-oauth-03#section-4.1 It is more clear in the original version (http://oauth.net/core/1.0a) where= all the parameter are listed together. I will correct that before the RFC = publication. Thanks! EHL > -----Original Message----- > From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf > Of Stephen McKamey > Sent: Thursday, October 29, 2009 5:47 PM > To: OAuth > Subject: [oauth] oauth_callback when using Authorization header? >=20 >=20 > The OAuth 1.0a spec is a little unclear about this so I thought I'd > ask. When sending oauth params via the Authorization header, where > does oauth_callback go? With the rest of the OAuth params in the > header, or where the API params would go (i.e. query string or post > data)? >=20 > HTTP Auth header feels like the right choice (keep all "oauth_" > together) but there isn't a definitive answer in the spec. >=20 >=20 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "= OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscribe@googlegroup= s.com For more options, visit this group at http://groups.google.com/group/oauth?= hl=3Den -~----------~----~----~----~------~----~------~--~---