From eve@xmlgrrl.com Sat May 1 05:49:44 2010 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 9B26F28C1BA for ; Sat, 1 May 2010 05:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_50=0.001, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] 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 4zEtI7acPZGB for ; Sat, 1 May 2010 05:49:43 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 1AE3528C941 for ; Sat, 1 May 2010 05:36:47 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o41CaQWx019265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 May 2010 05:36:27 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <4BDBC389.2090709@lodderstedt.net> Date: Sat, 1 May 2010 05:36:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23B6AE40-3304-432C-9AB7-DD725C0A1B37@xmlgrrl.com> References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BDB24CA.4050407@lodderstedt.net> <4BDBC389.2090709@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus 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, 01 May 2010 12:49:44 -0000 On 30 Apr 2010, at 11:00 PM, Torsten Lodderstedt wrote: > Am 01.05.2010 03:07, schrieb Marius Scurtescu: >> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt >> wrote: >> =20 >>> In my opinion, automatic discovery on scope values is as valuable or = not >>> valuable as automatic discovery for a service API. I would like to = echo one >>> of my postings: >>>=20 >>> A scope defines the set of permissions a client asks for and that = becomes >>> associated with tokens. I don't see the need (and a way) for = automatic scope >>> discovery. In my opinion, scopes are part of the API documentation = of a >>> particular resource server. So if someone implements a client, it = needs to >>> consider the different scopes this client needs the end users = authorization >>> for. If the resource server implements a OAuth2-based standard API = (e.g. for >>> contact management or e-Mail), a client might be interoperable (in = terms of >>> scopes) among the resource servers implementing this standard. >>> =20 >> Not sure I understand, are you saying that for a standard API, like >> IMAP for example, there should be a standard scope (or set of = scopes)? >> =20 >=20 > Yes, that's what I said. >=20 > Scopes (~permissions) should be defined allong with the corresponding = API. So developers should know upfront > which scope is required to perform a particular action. For example, = "uploading documents requires scope 'upload'". > The same holds for IMAP. Depending on the IMAP feature set you want to = use there could be plenty of scopes, > ranging from "read users INBOX" to sharing scenarios, where users have = access to other users IMAP folders. This makes a ton of sense. It's one of the reasons that, in UMA, we = tried to specify a generic way of expressing scope that naturally and = closely matches a resource-oriented (RESTful) API: resource + HTTP = method is a reliable shorthand for an access feature. For read and = write and even delete permissions on (say) identity data accessed by = URL, it's pretty much all the expressiveness you need, and ideally the = same documentation easily covers both features and scopes. For any API = that's more "compressed" (e.g. one complex endpoint for many = operations), it doesn't really help. Eve Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog From sayrer@gmail.com Sat May 1 15:24:34 2010 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 1E1E33A6920 for ; Sat, 1 May 2010 15:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_20=-0.74, GB_I_LETTER=-2] 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 yUQ5adbwUMMi for ; Sat, 1 May 2010 15:24:33 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id DA06D3A682F for ; Sat, 1 May 2010 15:24:32 -0700 (PDT) Received: by qyk11 with SMTP id 11so1733689qyk.13 for ; Sat, 01 May 2010 15:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=f5IyLitPcZd++NhjKYvmMaMZu88Q/v7IxPBQFrNjTZE=; b=DaCRPcyWTUuURuqqlCUlVvkkDIUGhR0ThgJiDpWLNEXh9y1Qwcsm2QQbDZYdkYSPbt uhI53q921yGNWNGxXuZum0LI/Kf5pCfOeDhXD2HuB4qEkYU7hLdC4fwJQgH2nVgsE6o0 04EdJQlcGOGIJiyHK//pdFxk5WzjgBMhmRsmY= 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=v/D8x1fFjr4Zij7RQKFciIDQw4NvQtN+c+UPefAz2fRDwsR6xq6sdYMhiCJYUD1JK6 w0wn6dy5pQppwA6XPdQmK35UhcLTfc5aqpuBaRMWuRlz1SOePllYBwZ+GF7kNs1AtGti mVZbNXKLuELWRyfr4knv0HnfQ2UW9Va4nbBd8= MIME-Version: 1.0 Received: by 10.229.96.80 with SMTP id g16mr1016264qcn.85.1272752655803; Sat, 01 May 2010 15:24:15 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Sat, 1 May 2010 15:24:15 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D0533@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20100419134825.134951nuzvi35hk4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <50802E3D-2578-409C-92BC-B5C47EBE6C21@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723439323D0533@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 1 May 2010 18:24:15 -0400 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON 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, 01 May 2010 22:24:34 -0000 On Fri, Apr 30, 2010 at 10:33 PM, Eran Hammer-Lahav wrote: > If we end up with JSON as the only *core* format, we can still extend the > protocol in another spec to add a format request parameter with other > serializations. I think that's the right way to look at it. The fact that JSON is always Unicode and the character encoding is easily determined by examining the first few bytes should be enough to make the group jump for it.[1] You can skip all the inaccurate metadata in the HTTP headers for both requests and responses. And even kind of hobbled embedded implementations can do ASCII only and we'll pretend it's UTF-8. :) But maybe none of this is a problem for existing implementations? The spec seems strangely silent on internationalization. - Rob [1] noooooo: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#url-encoded-form-data -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From lshepard@facebook.com Sat May 1 15:49:06 2010 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 E10373A6813 for ; Sat, 1 May 2010 15:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 QSOyjG5BUPwG for ; Sat, 1 May 2010 15:49:06 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id F152D3A67FB for ; Sat, 1 May 2010 15:49:05 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o41MmRp5017810 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 May 2010 15:48:27 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Sat, 1 May 2010 15:48:44 -0700 From: Luke Shepard To: Marius Scurtescu Date: Sat, 1 May 2010 15:48:44 -0700 Thread-Topic: [OAUTH-WG] Scope - Coming to a Consensus Thread-Index: AcrpgHQhpAQhY7nLSTiQ2yYoSbzJKQ== Message-ID: <60C3123B-4FCF-425C-A808-AFB4745AECC6@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-01_02:2010-02-06, 2010-05-01, 2010-04-30 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus 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, 01 May 2010 22:49:07 -0000 I agree with approach #3. As for the delimiter, I'm fine if the spec wants to do space-delimited.=20 Just FYI Facebook will also continue to support and document commas in addi= tion to whatever the spec says, because spaces are typically URL-encoded wh= ile commas are considered reserved characters and so not encoded. It's easi= er to write "read,write" than "read%20write". On Apr 30, 2010, at 6:11 PM, Marius Scurtescu wrote: > +1 for #3. >=20 > If the delimiter becomes an issue then: > - for application/x-www-form-urlencoded and query parameters we can > allow multiple values for this parameter > - for json this parameter can be defined as an array >=20 > Marius >=20 >=20 >=20 > On Fri, Apr 30, 2010 at 12:08 PM, Allen Tom wrote: >> I vote for #3 >>=20 >> There are already plenty of implementations that use a scope parameter: >>=20 >> Facebook: >> http://developers.facebook.com/docs/authentication/ >>=20 >> Google: >> http://code.google.com/apis/accounts/docs/OAuth_ref.html#RequestToken >>=20 >> Flickr: (called "perm") >> http://www.flickr.com/services/api/auth.spec.html >>=20 >> Yahoo currently requires developers to tell us the scopes that they need >> when registering for a consumer key. We've received plenty of feedback t= hat >> developers would rather specify the scope(s) at authorization time, so w= e >> would support a multi-valued scope parameter. Space is a reasonable >> delimiter. >>=20 >> Allen >>=20 >>=20 >>=20 >> On 4/30/10 8:43 AM, "Eran Hammer-Lahav" wrote: >>=20 >>>=20 >>> 3. Space-Delimited Scope Parameter Value >>>=20 >>> Define a 'scope' parameter with value of space-delimited strings (which= can >>> include any character that is not a space - the entire parameter value = is >>> encoded per the transport rules regardless). Space allows using URIs or= simple >>> strings as values. >>>=20 >>> Pros: >>>=20 >>> - A separator-delimited list of values is the common format for scope >>> parameters in existing implementations and represents actual deployment >>> experience. >>> - Most vendors define a set of opaque strings used for requesting scope= . This >>> enables libraries to concatenate these in a standard way. >>> - Enables simple extensions in the future for discovering which scope i= s >>> required by each resource. >>>=20 >>> Cons: >>>=20 >>> - Defining a format without a discovery method for the values needs doe= sn't >>> offer much more than the other options. >>> - Doesn't go far enough to actually achieve interoperability. >>> - Adds complexity for little value. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lshepard@facebook.com Sat May 1 15:50:40 2010 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 087633A68AD for ; Sat, 1 May 2010 15:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.005 X-Spam-Level: X-Spam-Status: No, score=-3.005 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Q-1sR-x+ZiT6 for ; Sat, 1 May 2010 15:50:39 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 33D4F3A679C for ; Sat, 1 May 2010 15:50:37 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o41Mnvi7018669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 May 2010 15:49:57 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub02.TheFacebook.com (192.168.18.105) with Microsoft SMTP Server (TLS) id 8.2.213.0; Sat, 1 May 2010 15:50:15 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Sat, 1 May 2010 15:50:15 -0700 From: Luke Shepard To: Brian Eaton Date: Sat, 1 May 2010 15:50:13 -0700 Thread-Topic: [OAUTH-WG] 'Scope' parameter proposal Thread-Index: AcrpgKlMcO/7oXXaR4ytjHt4lNN7tg== Message-ID: <01DBC6A5-681A-4B14-87D7-A59D8F351A8E@facebook.com> References: <0D5497F5-75A7-4A42-9A5E-9C2310162B18@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F30A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723438E5C7FD26@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723438E5C7FD4A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1125793664B@WSMSG3153V.srv.dir.telstra.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-01_02:2010-02-06, 2010-05-01, 2010-04-30 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] 'Scope' parameter proposal 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, 01 May 2010 22:50:40 -0000 I'm intrigued by the idea of returning scopes in the 403 response to a reso= urce. I'll see if we can provide a working example of it. On Apr 23, 2010, at 5:05 PM, Brian Eaton wrote: > On Thu, Apr 22, 2010 at 6:11 PM, Manger, James H > wrote: >> We mustn't drop advertisements (details in 401 responses). >> We mustn't drop the goal of a standard for interoperability. >=20 > I share the goals, I just don't think that a specification is the way > to get there. I think working examples in the wild would help > enormously. >=20 >> Defining a scope field in a 401 response is the novel aspect that =93mig= ht not actually work=94. Allowing a 'scope' query parameter in authz URIs i= s be quite separate. >=20 > Yeah, I agree with that analysis. >=20 > Though I don't know of any providers that are returning authorization > URLs in 401 responses right now. That's novel, too. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Sat May 1 18:06:25 2010 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 078DE3A68C5 for ; Sat, 1 May 2010 18:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 cTSuXiCLcQI0 for ; Sat, 1 May 2010 18:06:24 -0700 (PDT) Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by core3.amsl.com (Postfix) with ESMTP id 298D13A68B5 for ; Sat, 1 May 2010 18:06:24 -0700 (PDT) Received: by pzk12 with SMTP id 12so849280pzk.32 for ; Sat, 01 May 2010 18:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ynNirRuYxxMPuRcoIMjdxIvIE/DGEsaUAFhm06dEg3Q=; b=H4IzqjwEUUF/LI49hCTf8IIRimyaMvUSO2zWl8aBkkeLbVZdf9xQBGD/jOLqND4+Hv 9WZTKdXiAlx0bE5J9RcmJw8mAzYC8GD8h/76/ujMCoti55W3/Ryhxqxi0JtizRf6BG8f Um7uzsKh71+0Is40xTeAhO9771j6YTTH75yJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MTvwfNfudDuuCygjxnH6AL7rAvz1itof4aeoIe5tw0+kVgt0gEn+T274Fa9zLfYLIN tpnhsdxiE/ppm/XT85khCgy1/wg37pV1LxatemUfLj3YNLTLuOt88iwtcHOcW9ZaI3ZE 3t1jF1Ydqg7Qi/CNvx1pt4GdgqeHJh+PzKgeU= Received: by 10.115.100.30 with SMTP id c30mr405415wam.213.1272762366988; Sat, 01 May 2010 18:06:06 -0700 (PDT) Received: from [10.0.1.8] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id c22sm16557122wam.6.2010.05.01.18.06.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 May 2010 18:06:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <60C3123B-4FCF-425C-A808-AFB4745AECC6@facebook.com> Date: Sat, 1 May 2010 18:06:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <60C3123B-4FCF-425C-A808-AFB4745AECC6@facebook.com> To: Luke Shepard X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus 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, 02 May 2010 01:06:25 -0000 On 2010-05-01, at 3:48 PM, Luke Shepard wrote: > I agree with approach #3. >=20 > As for the delimiter, I'm fine if the spec wants to do = space-delimited.=20 >=20 > Just FYI Facebook will also continue to support and document commas in = addition to whatever the spec says, because spaces are typically = URL-encoded while commas are considered reserved characters and so not = encoded. It's easier to write "read,write" than "read%20write". Just in case it was not evident: a comma is a valid URL character, it = would be legal for it to be contained in a URL scope, leading a library = parsing scopes to inadvertently split up a single scope into one or = more. Since the proposal says a scope can be a URI/URL, a space is a = better delimiter. -- Dick= From Doug_Foiles@intuit.com Sun May 2 08:42:00 2010 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 404383A6A34 for ; Sun, 2 May 2010 08:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] 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 KqYb9CEVTtYT for ; Sun, 2 May 2010 08:41:52 -0700 (PDT) Received: from mail2.intuit.com (mail2.intuit.com [12.149.175.12]) by core3.amsl.com (Postfix) with ESMTP id 378A53A6A1F for ; Sun, 2 May 2010 08:41:47 -0700 (PDT) DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type:Subject:Date: Message-ID:In-Reply-To:X-MS-Has-Attach: X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:References: From:To:Return-Path:X-OriginalArrivalTime; b=C8ojNym/R5iHl3L3nUkzBGPrnEClhWtypByqec/bU5fzRqo5Zfs815oJ RfMLrHLTcQxkmHxjoNMlICucP9cJbK6T+OXjbMadZlpoCruVe+/rqTpWk igkEYsDpqM+6nUY; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Doug_Foiles@intuit.com; q=dns/txt; s=default; t=1272814896; x=1304350896; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; z=MIME-Version:=201.0|Subject:=20RE:=20[OAUTH-WG]=20Autono mous=20clients=20and=20resource=20owners=20(editorial) |Date:=20Sun,=202=20May=202010=2008:41:28=20-0700 |Message-ID:=20|In-Reply-To:=20|References:=20<5DEB74B3E9FA57 4EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intuit.net>=20 |From:=20"Foiles ,=20Doug"=20|To:=20"OAuth=20WG" =20; bh=MhS5cFCJ/YiRLKJ7pRj3sVF+i8GoSgXOYZBEw0tZ5Ko=; b=vrjnl4a2vTFoTWz3PKKEZ51YC4iT2cvA9f7x28ihalJOOjOEYXHGrqKo BYvvvEbBA+eX4miCr7Jwi7+3hI91JEBgiEFg4c49XeTk9ggkYa+vt+zWB FsZCcUB7o3S1B1U; X-SBRS: None X-IronPort-AV: E=Sophos;i="4.52,314,1270450800"; d="scan'208,217";a="181846677" Received: from sdgexbh03.corp.intuit.net ([172.17.135.77]) by mail2.sdg.ie.intuit.com with ESMTP; 02 May 2010 08:41:30 -0700 Received: from SDGEXEVS07.corp.intuit.net ([172.17.135.182]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 May 2010 08:41:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAEA0D.EEB9FDF4" Date: Sun, 2 May 2010 08:41:28 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Autonomous clients and resource owners (editorial) Thread-Index: AcrmIscm/BOC6W7iSh+JMT0dgGCAkgAALcx1AAY05pAAC/rNUADksrvw References: <5DEB74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intuit.net> From: "Foiles, Doug" To: "OAuth WG" X-OriginalArrivalTime: 02 May 2010 15:41:30.0012 (UTC) FILETIME=[EF1585C0:01CAEA0D] Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) 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, 02 May 2010 15:42:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAEA0D.EEB9FDF4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wanted to poke on the idea of not allowing Refresh Tokens for the assertion flow. I personally like the idea discussed here where the Refresh Token is used across all flows unless it doesn't make sense. The argument I heard for not including the Refresh Token for the assertion flow is that the use of Refresh Tokens break the trust relationship. It seems the "duration of access" is the key trust element in question. The identity of the client and resource owner (assuming the assertion flow would be made to support this) does not seem affected. =20 =20 For the case where a Refresh Token would NOT be used, a timeframe of "X" would be granted to the generated Access Token. That Access Token would only be usable for that "X" period of time. For the case where a Refresh Token were supported, the same "X" timeframe would be granted to the Refresh Token and the timeframe for the actual Access Token would be less than that. So in both cases the client would only be able to access the protected resource for the same "X" timeframe. Thoughts??? =20 And I am wondering if the assertion flow where the client is acting on behalf of a user is on the list of things to be added??? It was suggested that this had been discussed previously and might be going to be added. And sounds like this would NOT be an autonomous flow from what I understand, as autonomous flows are strictly for cases where the client is the same as the resource owner. =20 And I still don't see the corresponding flow in OAuth 2.0 for an OAuth 1.0 - 2 Legged use case where clients are acting on behalf of a resource owner that is not themselves. Will there be a flow to support this??? I can actually see how another type of "end user credentials flow" would work where the credential is something different than the username and password.=20 =20 Thanks. =20 Doug =20 =20 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore Sent: Tuesday, April 27, 2010 5:46 PM To: Keenan, Bill; OAuth WG Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) =20 Refresh token was explicitly removed from the suggestion I made for assertion flow. I'd be curious if others on the list see a need for it...? Eran - do you expect to make edits to the assertion flow before pushing the working group draft? -cmort On 4/27/10 12:14 PM, "Keenan, Bill" wrote: With Doug in an all day mtg, we have not sync'd on this...so one of us may respond again on this topic. I think I am +1 w/ Brian E. In the flow from SAML gateway to STS to protected resource, I don't see caching both an access and refresh token as getting me any efficiency. Certainly, it adds complexity to regression testing. I appreciate the desire for symmetry on the set of flows...refresh token seems like a place for asymmetry. BillK -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore Sent: Tuesday, April 27, 2010 9:06 AM To: Torsten Lodderstedt; Brian Eaton Cc: Foiles, Doug; OAuth WG Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) Same here - we don't intend to issue refresh tokens for either of these flows, and we'll only be accepting 1 time use assertions. -cmort ________________________________________ From: Torsten Lodderstedt [torsten@lodderstedt.net] Sent: Tuesday, April 27, 2010 9:00 AM To: Brian Eaton Cc: Chuck Mortimore; Foiles, Doug; OAuth WG Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) returning access token would suffice in this flow, from my point of view. regards, Torsten. Am 27.04.2010 um 08:33 schrieb Brian Eaton : > From my perspective, the main thing is that the assertion flow can be > used to connect existing authentication systems with APIs that are > using OAuth2 for authorization. > > This will let us leverage existing trust relationships across systems. > > Note that this breaks, however, if the flow returns a refresh token. > Refresh tokens are a new trust relationship, and they require > additional user/administrator involvement to manage. > > Cheers, > Brian > > On Mon, Apr 26, 2010 at 10:23 PM, Torsten Lodderstedt > wrote: >> +1 >> >> we need the assertion flow for the same purpose. Can we add a >> variant of the >> flow to section "End User Credentials Flows"? >> >> regards, >> Torsten. >> >> Am 26.04.2010 23:17, schrieb Chuck Mortimore: >> >> +1. >> >> Our primary use-cases for the assertion flow are for clients acting >> on >> behalf of users, and not autonomously. I believe Eran already has >> this on >> his list of feedback when the assertion flow gets edited. >> >> We also have need for a 2 legged Oauth model, and are looking at >> the client >> credentials flow for exactly that purpose. >> >> -cmort >> >> >> On 4/25/10 10:34 AM, "Foiles, Doug" wrote: >> >> I have a bit of confusion on the Autonomous Client Flows ... and spe >> cifically >> related to Eve's comment below that suggests to me that the autono >> mous >> client is NOT ALWAYS the resource owner. >> >> Can the Autonomous Client Flows support clients that ARE NOT the >> actual >> resource owner? For example for an Assertion Flow where the >> Subject of the >> SAML assertion is a user identity (and the resource owner) and not >> that of >> the client. >> >> Is the intent of the Client Credentials Flow to support something >> like >> Google's "OAuth for Google Apps domains" 2 Legged OAuth use ca >> se? >> http://code.google.com/apis/accounts/docs/OAuth.html. >> >> If the Autonomous Client Flows support clients that can act on >> behalf a >> resource owner that is not themselves ... it then seems the resourc >> e owner >> must provide some level of consent outside the OAuth specific flow. >> >> Thanks. >> >> Doug >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf Of >> Eve Maler >> Sent: Friday, April 23, 2010 7:21 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Autonomous clients and resource owners >> (editorial) >> >> >> Regarding the second comment I made below: I realized last night that >> Sections 3.7.1 and 3.7.2 get this more correct, by saying that an >> autonomous >> client represents a "separate resource owner". So Section 2.2 >> definitely >> needs a slight change, from: >> >> >> >> "...and autonomous flows where the client is acting for itself (the >> client >> is also the resource owner)." >> >> >> >> to something like: >> >> >> >> "...and autonomous flows where the client is acting on behalf of a >> different >> resource owner." >> >> >> >> Thanks, >> >> >> >> Eve >> >> >> >> On 21 Apr 2010, at 4:43 PM, Eve Maler wrote: >> >> >> Tacking this response to the end of the thread for lack of a better >> place to >> do it: The name "username" seems not quite apt in the case of an >> autonomous >> client that isn't representing an end-user. Would "identifier" be >> better? >> (Actually, it sort of reminds me of SAML's "SessionIndex"...) Or >> would the >> parameter be reserved for user-delegation flows? >> >> >> >> Speaking of autonomous clients, Section 2.2 -- among possibly other >> places >> -- states that an autonomous client is also the resource owner, but >> that's >> not always the case, is it? The client might be seeking access on >> behalf of >> itself. (FWIW, I made roughly this same comment on David's first >> draft on >> March 21, and he agreed with my suggested fix at the time.) >> >> >> >> Eve >> >> >> >> Eve Maler >> >> eve@xmlgrrl.com >> >> http://www.xmlgrrl.com/blog >> >> >> >> _______________________________________________ >> 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 ------_=_NextPart_001_01CAEA0D.EEB9FDF4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Autonomous clients and resource owners = (editorial)

I wanted to poke on the idea of not allowing Refresh = Tokens for the assertion flow.  I personally like the idea discussed here = where the Refresh Token is used across all flows unless it doesn’t make sense.  = The argument I heard for not including the Refresh Token for the assertion = flow is that the use of Refresh Tokens break the trust relationship.  It seems = the “duration of access” is the key trust element in question.  The = identity of the client and resource owner (assuming the assertion flow would be made = to support this) does not seem affected. 

 

For the case where a Refresh Token would NOT be used, a timeframe of “X” would be granted to the generated Access Token.  That Access Token would only be usable for that = “X” period of time.  For the case where a Refresh Token were supported, = the same “X” timeframe would be granted to the Refresh Token and the = timeframe for the actual Access Token would be less than that.  So in both = cases the client would only be able to access the protected resource for the same = “X” timeframe.  Thoughts???

 

And I am wondering if the assertion flow where the client = is acting on behalf of a user is on the list of things to be added???  = It was suggested that this had been discussed previously and might be going to = be added.  And sounds like this would NOT be an autonomous flow from = what I understand, as autonomous flows are strictly for cases where the client = is the same as the resource owner.

 

And I still don’t see the corresponding flow in = OAuth 2.0 for an OAuth 1.0 - 2 Legged use case where clients are acting on = behalf of a resource owner that is not themselves.  Will there be a flow to = support this???  I can actually see how another type of “end user credentials flow” would work where the credential is something = different than the username and password.

 

Thanks.

 

Doug

 

 

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Chuck Mortimore
Sent: Tuesday, April 27, 2010 5:46 PM
To: Keenan, Bill; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)

 

Refresh token was explicitly = removed from the suggestion I made for assertion flow.   I’d be = curious if others on the list see a need for it...?

Eran – do you expect to make edits to the assertion flow before = pushing the working group draft?

-cmort



On 4/27/10 12:14 PM, "Keenan, Bill" <Bill_Keenan@intuit.com> = wrote:

With Doug in an all day mtg, we = have not sync'd on this...so one of us
may respond again on this topic.

I think I am +1 w/ Brian E.

In the flow from SAML gateway to STS to protected resource, I don't = see
caching both an access and refresh token as getting me any = efficiency.
Certainly, it adds complexity to regression testing.

I appreciate the desire for symmetry on the set of flows...refresh = token
seems like a place for asymmetry.

BillK

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf
Of Chuck Mortimore
Sent: Tuesday, April 27, 2010 9:06 AM
To: Torsten Lodderstedt; Brian Eaton
Cc: Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)

Same here - we don't intend to issue refresh tokens for either of = these
flows, and we'll only be accepting 1 time use assertions.

-cmort
________________________________________
From: Torsten Lodderstedt [torsten@lodderstedt.net]
Sent: Tuesday, April 27, 2010 9:00 AM
To: Brian Eaton
Cc: Chuck Mortimore; Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)

returning access token would suffice in this flow, from my point of
view.

regards,
Torsten.


Am 27.04.2010 um 08:33 schrieb Brian Eaton <beaton@google.com>:

> From my perspective, the main thing is that the assertion flow can = be
> used to connect existing authentication systems with APIs that = are
> using OAuth2 for authorization.
>
> This will let us leverage existing trust relationships across = systems.
>
> Note that this breaks, however, if the flow returns a refresh = token.
> Refresh tokens are a new trust relationship, and they require
> additional user/administrator involvement to manage.
>
> Cheers,
> Brian
>
> On Mon, Apr 26, 2010 at 10:23 PM, Torsten Lodderstedt
> <torsten@lodderstedt.net> wrote:
>> +1
>>
>> we need the assertion flow for the same purpose. Can we add = a
>> variant of the
>> flow to section "End User Credentials Flows"?
>>
>> regards,
>> Torsten.
>>
>> Am 26.04.2010 23:17, schrieb Chuck Mortimore:
>>
>> +1.
>>
>> Our primary use-cases for the assertion flow are for clients = acting
>> on
>> behalf of users, and not autonomously.   I believe = Eran already has
>> this on
>> his list of feedback when the assertion flow gets edited.
>>
>> We also have need for a 2 legged Oauth model, and are looking = at
>> the client
>> credentials flow for exactly that purpose.
>>
>> -cmort
>>
>>
>> On 4/25/10 10:34 AM, "Foiles, Doug" <Doug_Foiles@intuit.com> = wrote:
>>
>> I have a bit of confusion on the Autonomous Client Flows ... = and spe
>> cifically
>> related to Eve's comment below that suggests to me that the = autono
>> mous
>> client is NOT ALWAYS the resource owner.
>>
>> Can the Autonomous Client Flows support clients that ARE NOT = the
>> actual
>> resource owner?  For example for an Assertion Flow where = the
>> Subject of the
>> SAML assertion is a user identity (and the resource owner) and = not
>> that of
>> the client.
>>
>> Is the intent of the Client Credentials Flow to support = something
>> like
>> Google's "OAuth for Google Apps domains" 2 Legged = OAuth use ca
>> se?
>>  http://code= .google.com/apis/accounts/docs/OAuth.html.
>>
>> If the Autonomous Client Flows support clients that can act = on
>> behalf a
>> resource owner that is not themselves  ... it then seems = the resourc
>> e owner
>> must provide some level of consent outside the OAuth specific = flow.
>>
>> Thanks.
>>
>> Doug
>>
>>
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On
>> Behalf Of
>> Eve Maler
>> Sent: Friday, April 23, 2010 7:21 AM
>> To: OAuth WG
>> Subject: [OAUTH-WG] Autonomous clients and resource owners
>> (editorial)
>>
>>
>> Regarding the second comment I made below: I realized last = night that
>> Sections 3.7.1 and 3.7.2 get this more correct, by saying that = an
>> autonomous
>> client represents a "separate resource owner". So = Section 2.2
>> definitely
>> needs a slight change, from:
>>
>>
>>
>> "...and autonomous flows where the client is acting for = itself (the
>> client
>> is also the resource owner)."
>>
>>
>>
>> to something like:
>>
>>
>>
>> "...and autonomous flows where the client is acting on = behalf of a
>> different
>> resource owner."
>>
>>
>>
>> Thanks,
>>
>>
>>
>>             E= ve
>>
>>
>>
>> On 21 Apr 2010, at 4:43 PM, Eve Maler wrote:
>>
>>
>> Tacking this response to the end of the thread for lack of a = better
>> place to
>> do it: The name "username" seems not quite apt in the = case of an
>> autonomous
>> client that isn't representing an end-user. Would "identifier" be
>> better?
>> (Actually, it sort of reminds me of SAML's "SessionIndex"...) Or
>> would the
>> parameter be reserved for user-delegation flows?
>>
>>
>>
>> Speaking of autonomous clients, Section 2.2 -- among possibly = other
>> places
>> -- states that an autonomous client is also the resource owner, = but
>> that's
>> not always the case, is it? The client might be seeking access = on
>> behalf of
>> itself. (FWIW, I made roughly this same comment on David's = first
>> draft on
>> March 21, and he agreed with my suggested fix at the time.)
>>
>>
>>
>>             E= ve
>>
>>
>>
>> Eve Maler
>>
>> eve@xmlgrrl.com
>>
>> http://www.xmlgrrl.com/blog
>>
>>
>>
>> _______________________________________________
>> 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

------_=_NextPart_001_01CAEA0D.EEB9FDF4-- From torsten@lodderstedt.net Sun May 2 10:49:29 2010 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 61C9F3A6AE2 for ; Sun, 2 May 2010 10:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.423 X-Spam-Level: X-Spam-Status: No, score=0.423 tagged_above=-999 required=5 tests=[AWL=-1.927, BAYES_80=2, HELO_EQ_DE=0.35] 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 gXwYpmshD0Oj for ; Sun, 2 May 2010 10:49:28 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id B149A3A6AF1 for ; Sun, 2 May 2010 10:48:57 -0700 (PDT) Received: from p4fff3848.dip.t-dialin.net ([79.255.56.72] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1O8dHV-0002Lb-MW for oauth@ietf.org; Sun, 02 May 2010 19:48:41 +0200 Message-ID: <4BDDBAF8.8060807@lodderstedt.net> Date: Sun, 02 May 2010 19:48:40 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] Refresh tokens security enhancement 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, 02 May 2010 17:49:29 -0000 Hi all, I discussed OAuth with some of the security experts here at Deutsche Telekom. We came up w/ an idea for enhancing refresh token handling I would like to discuss in the WG. Assumption: refresh tokens have a very long duration (month to unlimited) and are stored at the client in a persistent storage (e.g. database or filesystem) Question: How can token theft automatically be detected/prevented? Let me detail the problem using three scenarios: 1) Client is a web site Let's assume an attacker breaks into the server and gets access all tokens stored there along with the client's secret. Abuse could be prevented by changing the client secret, but this requires to _detect_ the theft first! 2) Mobile application/malware on same device Let's assume an application on a mobile device, which stores refresh token(s) in the device's file system. A malware on the same device could read the token(s) from long-term storage and send it to a server under the attackers control. One could prevent such an attack by using a client secret (probably burned into the application), but that's not a very reliable measure. Filesystem security could be used to prevent eavesdropping, but its quality varies very much among mobile operating systems. The token could be invalidated by the user, after he/she realized the theft using some user self care function. But again, the theft has to be detected. 3) Mobile application/cloning device software and configuration Someone could clone a device (operating system, configuration, applications and refresh tokens/client secrets) e.g. using a debug API when the user has left the device unattended. According to our experts, this does not take that much time and is typically not detectable afterwards. The clone could be run on another device identical in construction and could be used to access all applications on behalf of the legitimate end user. As a possible countermeasure, one could bind a refresh token to a device specific properties, e.g. the IMEI - International Mobile Station Equipment Identity. But not every device has a 3G module and access to this data might not be possible on some platforms. The impact of all attacks illustrated above strongly depends on the power associated with a token. As soon as the attacker is able to spend the end user's money or gets access to medical records it's getting serious! All countermeasures mentioned on the scenarios are either out of reach of the Oauth spec, platform specific, or not very effective. What we would like to achive is an automatic detection and at best prevention of such attacks. We came up with the following idea: The authorization server automatically creates a new refresh token with every "refresh" request (section 4) and invalidated the previous refresh token. The client must use this new token for the next "refresh" request. All attempts to obtain access tokens with an invalidated refresh token are refused. Additionally, the authorization server should hold a history of when the refresh token has been used. The client application behavior depends on who uses the refresh token first after it has been stolen. a) If the end user uses the refresh token first, the stolen token is invalidated automatically, any attempts of the attacker to obtain an access token are refused by the authorization server. b) Attacker uses the token first: The end users application attempts to obtain an access token using the (already invalidated) refresh token are refused. The client should notify the user of the problem and recomend him/her to check its application authorizations (refresh tokens) in a user self care portal. There, the user should have acces to information on when the token has been used the last time and therewith detect any odd behavior. The user could then revoke the token and/or alarm its providers helpdesk. We think the proposed change to the API would significantly contribute to the overall security level of OAuth. Thoughts? regards, Torsten. From James.H.Manger@team.telstra.com Mon May 3 06:25:39 2010 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 212643A6CBE for ; Mon, 3 May 2010 06:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.02 X-Spam-Level: ** X-Spam-Status: No, score=2.02 tagged_above=-999 required=5 tests=[AWL=-1.503, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9qdbWq7y-En for ; Mon, 3 May 2010 06:25:38 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id DB23328C1A8 for ; Mon, 3 May 2010 06:24:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,319,1270389600"; d="scan'208";a="1919930" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 03 May 2010 23:23:52 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5970"; a="1425410" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 03 May 2010 23:23:52 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 3 May 2010 23:23:51 +1000 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Mon, 3 May 2010 23:23:50 +1000 Thread-Topic: [OAUTH-WG] Scope - Coming to a Consensus Thread-Index: Acrpk6vOPnVOdWKjSzqddhqyA+nnWgBJrrYw Message-ID: <255B9BB34FB7D647A506DC292726F6E1126277CFE7@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <60C3123B-4FCF-425C-A808-AFB4745AECC6@facebook.com> 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] Scope - Coming to a Consensus 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, 03 May 2010 13:25:39 -0000 QSBjb21tYSBpcyBhIGJldHRlciBzZXBhcmF0b3IgaGVyZS4NCkFsbG93IFVSSXMgYXMgc2NvcGVz IC0tIGFzIGxvbmcgYXMgdGhlIGNob3NlbiBVUklzIGRvbid0IGhhdmUgY29tbWFzLiBUaGlzIGlz bid0IGEgYmlnIHJlc3RyaWN0aW9uIG9uIHNlcnZpY2VzLg0KDQpbSWYgYSBzZXJ2aWNlIHByb3Zp ZGVyIHJlYWxseSBuZWVkcyB0byBpbmNsdWRlIGFyYml0cmFyeSBVUklzIGluIGFuIGF1dGhvcml6 YXRpb24gVVJJIHRoZXkgY2FuIHN0aWxsIGRvIHNvIGJ5IGRlZmluaW5nIGFub3RoZXIgcGFyYW1l dGVyLCBzYXkgInVybHMiLiBXZSBhcmUgYmFyZWx5IGRlZmluaW5nIGFueSBzZW1hbnRpY3MgZm9y ICJzY29wZSIgLS0gYXQgbGVhc3Qgbm9uZSB0aGF0IGxpYnJhcmllcyBjYW4gdXNlIC0tIHNvIG5v dCBtdWNoIGlzIGxvc3QgaW4gdXNpbmcgYSBkaWZmZXJlbnQgcGFyYW1ldGVyIG5hbWUuXQ0KDQoN CkEgc3BhY2Utc2VwYXJhdGVkIGxpc3QgKGVuY29kZWQgYXMgcGVyIHRoZSB0cmFuc3BvcnQpIHNv dW5kcyBuaWNlIGF0IGEgbG9naWNhbCBsZXZlbCwgYnV0IGlzIGp1c3QgYSBiaXQgdW5uZWNlc3Nh cmlseSBhd2t3YXJkLiBUaGUgb25seSBwbGFjZSBzY29wZSB2YWx1ZXMgYXBwZWFyIGlzIGluIGFu IGF1dGh6IFVSSSBzbyB0aGUgb25seSBlbmNvZGluZyBpcyBVUkktZW5jb2RpbmcuIEFyZSB0aGUg c3BhY2VzIGVzY2FwZWQgYXMgIiUyMCIgb3IgIisiPyBFdmVuIGlmIHdlIHRyeSB0byBwaWNrIG9u ZSBhbnN3ZXIgSSBzdXNwZWN0IGJvdGggd2lsbCBvY2N1ciAoaXQgZGVwZW5kcyBvbiB3aGljaCBw YXJ0IG9mIHRoZSBzb2Z0d2FyZSBidWlsZHMgdGhlIGF1dGh6IFVSSSAtLSBpZSBwcmVwYXJlIGZv ciBpbnRlcm9wIGdsaXRjaGVzKS4NCkFueSBzcGFjZXMgaW4gYSBVUkkgdXNlZCBhcyBhIHNjb3Bl IHZhbHVlIG5lZWRzIHRvIGJlICUtZXNjYXBlZCB0d2ljZS4gSXQgc2VlbXMgdW5uZWNlc3Nhcnkg dG8gZXZlbiBhbGxvdyB0aGlzLg0KDQoNCkZhY2Vib29rIGRlZmluZSB2YWx1ZXMgbGlrZSBzY29w ZT1yZWFkLHdyaXRlLg0KSG93ZXZlciwgaWYgeW91IGJ1aWxkIGFuIGF1dGh6IFVSSSBmcm9tIGFu IEhUTUwgZm9ybSB3aXRoIGFuIGlucHV0IHZhbHVlIG9mICJyZWFkLHdyaXRlIiB5b3UgZ2V0IHNj b3BlPXJlYWQlMkN3cml0ZSAtLSBhcyBjb21tYSBpcyBub3QgYW4gdW5yZXNlcnZlZCBjaGFyYWN0 ZXIuDQogIDxpbnB1dCBuYW1lPSJzY29wZSIgdmFsdWU9InJlYWQsd3JpdGUiLz4NCkkgc3VzcGVj dCBhdXRoeiBzZXJ2aWNlcyBtaWdodCBuZWVkIHRvIGFjY2VwdCAicmVhZCUyQ3dyaXRlIiBhcyBl cXVpdmFsZW50IHRvICJyZWFkLHdyaXRlIiBbSSB3b25kZXIgaWYgRmFjZWJvb2sgZG9lcz9dLiBX aGljaCBnZXRzIHByb2R1Y2VkIHdpbGwgZGVwZW5kIG9uIGhvdyB0aGUgY2xpZW50IGFwcCAob3Ig Y2xpZW50IE9BdXRoIGxpYnJhcnkpIGlzIGRlc2lnbmVkLCBhbmQgd2lsbCB2YXJ5IGJldHdlZW4g YXBwcy4gVGhlIHNwZWMgcHJvYmFibHkgbmVlZCB0byBzYXkgc2VydmljZXMgTVVTVCBhY2NlcHQg IiwiIGFuZCAiJTJDIiBhcyBzZXBhcmF0b3JzIC0tIGFuZCBjb25zZXF1ZW50bHkgaW5kaXZpZHVh bCBzY29wZSB2YWx1ZXMgTVVTVCBOT1QgY29udGFpbiAiLCIgb3IgIiUyQyIuDQoNCg0KSSB0aGlu ayB0aGUgYmVzdCBkZWZpbml0aW9uIChsZWFzdCBwb3RlbnRpYWwgZm9yIGFueSBkZXZlbG9wZXIg b3IgaW50ZXJvcCBncmllZikgd291bGQgcmVzdHJpY3QgaW5kaXZpZHVhbCBzY29wZSB2YWx1ZXMg dG8gY2hhcnMgdGhhdCBjYW4gYmUgcGxhY2VkIGluIGEgcXVlcnkgcGFyYW1ldGVyIHZhbHVlIHdp dGhvdXQgYW55IHNwZWNpYWwgdHJlYXRtZW50Lg0KQWxsb3cgYW55IGNoYXJzIGFsbG93ZWQgaW4g VVJJcywgZXhjZXB0ICImIiwgIiMiLCAiJSIsIG9yICIsIi4NClRoaXMgZG9lc24ndCBhbGxvdyBh cmJpdHJhcnkgVVJJcywgYnV0IEkgc3VzcGVjdCBpdCBhbGxvd3MgYW55IFVSSXMgYmVpbmcgdXNl ZCBhcyBzY29wZXMgYXQgcHJlc2VudC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From James.H.Manger@team.telstra.com Mon May 3 06:57:28 2010 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 7C61028C1C3 for ; Mon, 3 May 2010 06:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.17 X-Spam-Level: * X-Spam-Status: No, score=1.17 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZG6K6+0gOGJ for ; Mon, 3 May 2010 06:57:27 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 5B49F28C1A0 for ; Mon, 3 May 2010 06:57:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,319,1270389600"; d="scan'208";a="2476283" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 03 May 2010 23:57:06 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5970"; a="1754130" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcani.tcif.telstra.com.au with ESMTP; 03 May 2010 23:57:06 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Mon, 3 May 2010 23:57:06 +1000 From: "Manger, James H" To: Torsten Lodderstedt , Marius Scurtescu Date: Mon, 3 May 2010 23:57:05 +1000 Thread-Topic: [OAUTH-WG] Permissions (Scope - Coming to a Consensus) Thread-Index: Acro86qHE6Am1el/QFGbeFEM5WkUtAB0TZ9Q Message-ID: <255B9BB34FB7D647A506DC292726F6E1126277CFE8@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BDB24CA.4050407@lodderstedt.net> <4BDBC389.2090709@lodderstedt.net> In-Reply-To: <4BDBC389.2090709@lodderstedt.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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Permissions (Scope - Coming to a Consensus) 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, 03 May 2010 13:57:28 -0000 VG9yc3RlbiwNCg0KPiBTY29wZXMgKH5wZXJtaXNzaW9ucykgc2hvdWxkIGJlIGRlZmluZWQgYWxs b25nIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgQVBJLg0KDQpCdXQgdGhleSBhcmVuJ3QuDQpMb3Rz IG9mICJBUElzIiAtLSBwYXJ0aWN1bGFybHkgdGhlIG1vc3QgaW1wb3J0YW50L3N0YW5kYXJkIG9u ZXMsIGxpa2UgQXRvbVB1YiwgSFRNTCBpdHNlbGYsIElNQVAgKD8pLi4uIGFyZSBhbHJlYWR5IGRl ZmluZWQsIG9yIGFyZSBkZWZpbmVkIHNlcGFyYXRlbHkgZnJvbSBhbnkgcGVybWlzc2lvbnMgdGhh dCBvbmUgc2VydmljZSBjaG9vc2VzIGZvciB0aGVpciBpbXBsZW1lbnRhdGlvbi4NClBlcm1pc3Np b25zIGNhbiBiZSBjb2Fyc2UgZ3JhaW5lZCAoZWcgaGF2ZSBhY2Nlc3MgLyBkb24ndCBoYXZlIGFj Y2VzcyksIG9yIGZpbmUgZ3JhaW5lZCAoZWcgY2FuIHJlYWQgZ3JlZW4gaXRlbXMgb24gRnJpZGF5 cyksIG9yIGFueXdoZXJlIGluIGJldHdlZW4uIElmIGV2ZXJ5IGNsaWVudCBhcHAgYWx3YXlzIG5l ZWRzIHNlcnZpY2Utc3BlY2lmaWMga25vd2xlZGdlIGFib3V0IGhvdyBwZXJtaXNzaW9uIGFyZSBh cnJhbmdlZCBJIGRvbid0IHRoaW5rIHdlIGNhbiBnZXQgbXVjaCBpbnRlcm9wLg0KDQoNCj4gRGVw ZW5kaW5nIG9uIHRoZSBJTUFQIGZlYXR1cmUgc2V0IHlvdSB3YW50IHRvIHVzZSB0aGVyZSBjb3Vs ZCBiZSBwbGVudHkgb2Ygc2NvcGVzLA0KcmFuZ2luZyBmcm9tICJyZWFkIHVzZXJzIElOQk9YIiB0 byBzaGFyaW5nIHNjZW5hcmlvcywgd2hlcmUgdXNlcnMgaGF2ZSANCmFjY2VzcyB0byBvdGhlciB1 c2VycyBJTUFQIGZvbGRlcnMuDQoNCltJIGFtIG5vdCBzdXJlIHRoYXQgSU1BUCBpcyBhIGdyZWF0 IGV4YW1wbGUgYXMgSSBhc3N1bWUgaXQgaXNuJ3QgYW4gSFRUUCBwcm90b2NvbCwgYnV0IGlnbm9y aW5nIHRoYXRdDQpJIGhvcGUgdGhhdCBpZiBhbiBJTUFQIHNlcnZpY2Ugc2F5cyAiSSBzdXBwb3J0 IE9BdXRoMiIsIGFuZCBhIGNsaWVudCBhcHAgc2F5cyAiSSB1bmRlcnN0YW5kIElNQVAgYW5kIE9B dXRoMiIgdGhlbiB0aGV5IGNhbiBpbnRlcm9wZXJhdGUgd2l0aCBtaW5pbWFsIGNvbmZpZy4gVGhl IGFwcCBtYXkgbmVlZCBhbiBhcHAtaWQvc2VjcmV0LCBpdCBtYXkgbmVlZCBhbiBVUkkgdG8gc3Rh cnQgYXQgKHBlcmhhcHMgZXZlbiBhIGNvbXBsaWNhdGVkIG9uZSksIGJ1dCBJIGhvcGUgaXQgZG9l c24ndCBhbHNvIG5lZWQgYSB0YWJsZSBvZiBzZXJ2aWNlLXNwZWNpZmljIHBlcm1pc3Npb24gbGFi ZWxzIGFnYWluc3QgZXZlcnkgcG9zc2libGUgSU1BUCBvcGVyYXRpb24uDQoNCi0tDQpKYW1lcyBN YW5nZXINCg0K From atom@yahoo-inc.com Mon May 3 09:56:42 2010 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 B73A43A6A1F for ; Mon, 3 May 2010 09:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.982 X-Spam-Level: X-Spam-Status: No, score=-14.982 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_50=0.001, USER_IN_DEF_WHITELIST=-15] 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 qKP8WdKenyYQ for ; Mon, 3 May 2010 09:56:42 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id F151C3A695C for ; Mon, 3 May 2010 09:56:41 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o43GtoJG058125; Mon, 3 May 2010 09:55:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:x-originalarrivaltime; b=1Jf5bqESAA6sS9bU0YdCp1Hgn7kdwvSXSvkADziHyvBhwOAEOoX3QEqAag4UHMe4 Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 May 2010 09:55:50 -0700 Received: from 10.72.76.149 ([10.72.76.149]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Mon, 3 May 2010 16:55:50 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 03 May 2010 09:55:48 -0700 From: Allen Tom To: Torsten Lodderstedt , "OAuth WG (oauth@ietf.org)" Message-ID: Thread-Topic: [OAUTH-WG] Refresh tokens security enhancement Thread-Index: Acrq4XqqY1ZPjObFVEKT0/pP5SXSiA== In-Reply-To: <4BDDBAF8.8060807@lodderstedt.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 May 2010 16:55:50.0215 (UTC) FILETIME=[7BFC3D70:01CAEAE1] Subject: Re: [OAUTH-WG] Refresh tokens security enhancement 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, 03 May 2010 16:56:42 -0000 Hi Torsten, Thanks for posting this idea - I think that issuing a new Refresh Token (and invalidating the old one) on every refresh request would help detect token theft. HOWEVER - in practice, this mechanism could make implementations very tricky. For example, some applications are highly distributed, with each instance (or component) having its own copy of the Refresh Token. Keeping the Refresh Token in sync would not really be feasible for these types of apps. Invalidating the Refresh Token (and presumably also invalidating any outstanding Access Tokens) would make sense as an option for applications that require a high level of security. However, I do not think that invalidating the Refresh Token on every Refresh request should be required in the spec - it should be an implementation specific detail. At Yahoo, we've used the Refresh Flow for all of our proprietary authorization APIs for many years, and I know of several applications which would break if the Refresh Token (and Access Token) were invalidated on every refresh request. Off the top of my head, I know of server based apps, mobile apps, and desktop apps which are composed of several components which asynchronously and independently keep their own copies of the user's credentials. Thanks Allen On 5/2/10 10:48 AM, "Torsten Lodderstedt" wrote: > We came up with the following idea: > > The authorization server automatically creates a new refresh token with > every "refresh" request (section 4) and invalidated the previous refresh > token. The client must use this new token for the next "refresh" > request. All attempts to obtain access tokens with an invalidated > refresh token are refused. Additionally, the authorization server should > hold a history of when the refresh token has been used. The client > application behavior depends on who uses the refresh token first after > it has been stolen. From atom@yahoo-inc.com Mon May 3 10:03:34 2010 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 8223F28C251 for ; Mon, 3 May 2010 10:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.076 X-Spam-Level: X-Spam-Status: No, score=-15.076 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_40=-0.185, USER_IN_DEF_WHITELIST=-15] 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 y8czliLAzezB for ; Mon, 3 May 2010 10:03:33 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 65AE93A6A43 for ; Mon, 3 May 2010 10:03:29 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o43H2mIL030491; Mon, 3 May 2010 10:02:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:x-originalarrivaltime; b=O+2ZGckFFCFXVsQNpFv8IzEdJxlKpG93tgqY89YAU+I/oG8ND8bJYtaoEdyzXO6R Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 May 2010 10:02:38 -0700 Received: from 10.72.76.149 ([10.72.76.149]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.60]) with Microsoft Exchange Server HTTP-DAV ; Mon, 3 May 2010 17:02:38 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 03 May 2010 10:02:35 -0700 From: Allen Tom To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Message-ID: Thread-Topic: [OAUTH-WG] Permissions (Scope - Coming to a Consensus) Thread-Index: Acro86qHE6Am1el/QFGbeFEM5WkUtAB0TZ9QAAdjDx4= In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126277CFE8@WSMSG3153V.srv.dir.telstra.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 May 2010 17:02:38.0190 (UTC) FILETIME=[6F2848E0:01CAEAE2] Subject: Re: [OAUTH-WG] Permissions (Scope - Coming to a Consensus) 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, 03 May 2010 17:03:34 -0000 On a related note, there's a group working on an OAuth2 binding for IMAP (and other SASL based protocols) here: http://tech.groups.yahoo.com/group/sasl_oauth/ Currently, we're trying to figure out how Mail clients are supposed to discover what scopes they need. Also, most Mail clients would probably want more than just "IMAP" scope, they probably also want to access other related services, including SMTP, CalDAV, LDAP, Portable Contacts, etc. Allen On 5/3/10 6:57 AM, "Manger, James H" wrote: > > [I am not sure that IMAP is a great example as I assume it isn't an HTTP > protocol, but ignoring that] > I hope that if an IMAP service says "I support OAuth2", and a client app says > "I understand IMAP and OAuth2" then they can interoperate with minimal config. > The app may need an app-id/secret, it may need an URI to start at (perhaps > even a complicated one), but I hope it doesn't also need a table of > service-specific permission labels against every possible IMAP operation. > From uidude@google.com Mon May 3 10:16:36 2010 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 B9FEB3A6A64 for ; Mon, 3 May 2010 10:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.228 X-Spam-Level: X-Spam-Status: No, score=-100.228 tagged_above=-999 required=5 tests=[AWL=-1.452, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, 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 vQZ8RK64t-vv for ; Mon, 3 May 2010 10:16:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 476A03A6A5B for ; Mon, 3 May 2010 10:16:35 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [10.3.21.3]) by smtp-out.google.com with ESMTP id o43HGJ1U021839 for ; Mon, 3 May 2010 10:16:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272906980; bh=M1dHLFCUHcDbvY+9O+uONc/8H1E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WVgOgugC0KY7jywssLIkDycO59+0ve+WLi1zV3napIt9GNtQdplbxcyLiN6cdhOWl MMweTypYPxU/JJGVtBZmA== 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=QmhxPCEHkMYnxfwpqsmEyIdqYbx9ItNXJoqjcjPlQAJaB6E/d9PrRNETmoBrgDFva tM4xQGmaCDEbGezvB8cxA== Received: from ywh41 (ywh41.prod.google.com [10.192.8.41]) by hpaq3.eem.corp.google.com with ESMTP id o43HGHkV003824 for ; Mon, 3 May 2010 10:16:18 -0700 Received: by ywh41 with SMTP id 41so1155394ywh.9 for ; Mon, 03 May 2010 10:16:17 -0700 (PDT) Received: by 10.151.16.4 with SMTP id t4mr9962470ybi.107.1272906976728; Mon, 03 May 2010 10:16:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.94.18 with HTTP; Mon, 3 May 2010 10:15:56 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126277CFE7@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <60C3123B-4FCF-425C-A808-AFB4745AECC6@facebook.com> <255B9BB34FB7D647A506DC292726F6E1126277CFE7@WSMSG3153V.srv.dir.telstra.com> From: Evan Gilbert Date: Mon, 3 May 2010 10:15:56 -0700 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=000e0cd5c66e2e35a40485b3c024 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus 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, 03 May 2010 17:16:36 -0000 --000e0cd5c66e2e35a40485b3c024 Content-Type: text/plain; charset=ISO-8859-1 +1 on option 3. Commas seem slightly cleaner, but can go either way. We should also consider naming this parameter "scopes" if we go with option 3 Evan On Mon, May 3, 2010 at 6:23 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > A comma is a better separator here. > Allow URIs as scopes -- as long as the chosen URIs don't have commas. This > isn't a big restriction on services. > > [If a service provider really needs to include arbitrary URIs in an > authorization URI they can still do so by defining another parameter, say > "urls". We are barely defining any semantics for "scope" -- at least none > that libraries can use -- so not much is lost in using a different parameter > name.] > > > A space-separated list (encoded as per the transport) sounds nice at a > logical level, but is just a bit unnecessarily awkward. The only place scope > values appear is in an authz URI so the only encoding is URI-encoding. Are > the spaces escaped as "%20" or "+"? Even if we try to pick one answer I > suspect both will occur (it depends on which part of the software builds the > authz URI -- ie prepare for interop glitches). > Any spaces in a URI used as a scope value needs to be %-escaped twice. It > seems unnecessary to even allow this. > > > Facebook define values like scope=read,write. > However, if you build an authz URI from an HTML form with an input value of > "read,write" you get scope=read%2Cwrite -- as comma is not an unreserved > character. > > I suspect authz services might need to accept "read%2Cwrite" as equivalent > to "read,write" [I wonder if Facebook does?]. Which gets produced will > depend on how the client app (or client OAuth library) is designed, and will > vary between apps. The spec probably need to say services MUST accept "," > and "%2C" as separators -- and consequently individual scope values MUST NOT > contain "," or "%2C". > > > I think the best definition (least potential for any developer or interop > grief) would restrict individual scope values to chars that can be placed in > a query parameter value without any special treatment. > Allow any chars allowed in URIs, except "&", "#", "%", or ",". > This doesn't allow arbitrary URIs, but I suspect it allows any URIs being > used as scopes at present. > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd5c66e2e35a40485b3c024 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 on option 3.

Commas seem slightly cleaner, but can go= either way.

We should also consider naming this p= arameter "scopes" if we go with option 3

Evan

On Mon, May 3, 2010 at 6:23 AM,= Manger, James H <James.H.Manger@team.telstra.com> wrote:
A comma is a better separator here.
Allow URIs as scopes -- as long as the chosen URIs don't have commas. T= his isn't a big restriction on services.

[If a service provider really needs to include arbitrary URIs in an authori= zation URI they can still do so by defining another parameter, say "ur= ls". We are barely defining any semantics for "scope" -- at = least none that libraries can use -- so not much is lost in using a differe= nt parameter name.]


A space-separated list (encoded as per the transport) sounds nice at a logi= cal level, but is just a bit unnecessarily awkward. The only place scope va= lues appear is in an authz URI so the only encoding is URI-encoding. Are th= e spaces escaped as "%20" or "+"? Even if we try to pic= k one answer I suspect both will occur (it depends on which part of the sof= tware builds the authz URI -- ie prepare for interop glitches).
Any spaces in a URI used as a scope value needs to be %-escaped twice. It s= eems unnecessary to even allow this.


Facebook define values like scope=3Dread,write.
However, if you build an authz URI from an HTML form with an input value of= "read,write" you get scope=3Dread%2Cwrite -- as comma is not an = unreserved character.
=A0<input name=3D"scope" value=3D"read,write"/><= br> I suspect authz services might need to accept "read%2Cwrite" as e= quivalent to "read,write" [I wonder if Facebook does?]. Which get= s produced will depend on how the client app (or client OAuth library) is d= esigned, and will vary between apps. The spec probably need to say services= MUST accept "," and "%2C" as separators -- and consequ= ently individual scope values MUST NOT contain "," or "%2C&q= uot;.


I think the best definition (least potential for any developer or interop g= rief) would restrict individual scope values to chars that can be placed in= a query parameter value without any special treatment.
Allow any chars allowed in URIs, except "&", "#", &= quot;%", or ",".
This doesn't allow arbitrary URIs, but I suspect it allows any URIs bei= ng used as scopes at present.

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

--000e0cd5c66e2e35a40485b3c024-- From eran@hueniverse.com Mon May 3 15:24:05 2010 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 0671528C325 for ; Mon, 3 May 2010 15:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 KpDh+Wb4B7dK for ; Mon, 3 May 2010 15:24:03 -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 6911E28C1CB for ; Mon, 3 May 2010 15:23:36 -0700 (PDT) Received: (qmail 2582 invoked from network); 3 May 2010 22:23:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 May 2010 22:23:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 3 May 2010 15:23:20 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 3 May 2010 15:23:24 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-01.txt Thread-Index: AcrokdZvyrUPvuojQCusv9hg5ugF/gCfUvhQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723439323D08BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100429211502.40FA33A69F2@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E7234393217711F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20100430092844.19246e5a70ad1ew4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439321772F5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BDB1F66.2010700@lodderstedt.net> In-Reply-To: <4BDB1F66.2010700@lodderstedt.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] I-D Action:draft-ietf-oauth-v2-01.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, 03 May 2010 22:24:05 -0000 Feature complete means the protocol main features (flows, signature methods= , extension policy) are all in there in some shape. We can continue to deba= te details, but all the parts are there. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Friday, April 30, 2010 11:20 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-01.txt >=20 > Am 30.04.2010 17:46, schrieb Eran Hammer-Lahav: > > I'd like to add scope and credentials response format in the next draft= . > Doesn't have to be perfect but something we can work with. I am also > planning to complete the missing sections at the end. > > > > My goal is to have a feature-complete spec before the interim meeting > 5/20. > > > > >=20 > what do you mean with "feature-complete"? >=20 > regards, > Torsten. > > EHL > > > > > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >> Sent: Friday, April 30, 2010 12:29 AM > >> To: Eran Hammer-Lahav > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-01.txt > >> > >> Hi Eran, > >> > >> would you please give an overview of what aspects you are going to > >> change in the next draft and what issue you consider as still open? > >> > >> thanks in advance, > >> Torsten. > >> > >> Zitat von Eran Hammer-Lahav: > >> > >> > >>> Draft -01 submitted today shortly after the -00 (this will make it > >>> easier to do a diff for those who read the -00 draft). > >>> > >>> I plan to publish -02 next week based on feedback received on the lis= t. > >>> > >>> EHL > >>> > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf Of Internet-Drafts@ietf.org > >>>> Sent: Thursday, April 29, 2010 2:15 PM > >>>> To: i-d-announce@ietf.org > >>>> Cc: oauth@ietf.org > >>>> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-01.txt > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>> directories. > >>>> This draft is a work item of the Open Authentication Protocol > >>>> Working Group of the IETF. > >>>> > >>>> > >>>> Title : The OAuth 2.0 Protocol > >>>> Author(s) : E. Hammer-Lahav, et al. > >>>> Filename : draft-ietf-oauth-v2-01.txt > >>>> Pages : 49 > >>>> Date : 2010-04-29 > >>>> > >>>> This specification describes the OAuth 2.0 protocol. OAuth > >>>> provides a method for making authenticated HTTP requests using a > >>>> token - an identifier used to denote an access grant with specific > >>>> scope, duration, and other attributes. Tokens are issued to > >>>> third-party clients by an authorization server with the approval of > >>>> the resource owner. OAuth defines multiple flows for obtaining a > >>>> token to support a wide range of client types and user experience. > >>>> > >>>> A URL for this Internet-Draft is: > >>>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-01.txt > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> Below is the data which will enable a MIME compliant mail reader > >>>> implementation to automatically retrieve the ASCII version of the > >>>> Internet- Draft. > >>>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >> > >> > >> > > >=20 From mark.mcgloin@ie.ibm.com Tue May 4 02:08:26 2010 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 3A0843A69CC; Tue, 4 May 2010 02:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_50=0.001, 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 PAnHgrROl3O8; Tue, 4 May 2010 02:08:25 -0700 (PDT) Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [194.196.100.162]) by core3.amsl.com (Postfix) with ESMTP id DAC0E3A69C1; Tue, 4 May 2010 02:08:24 -0700 (PDT) Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o44989qJ000922; Tue, 4 May 2010 09:08:09 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o44989jp1441948; Tue, 4 May 2010 10:08:09 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o44989op009892; Tue, 4 May 2010 10:08:09 +0100 Received: from d06ml901.portsmouth.uk.ibm.com (d06ml901.portsmouth.uk.ibm.com [9.149.39.138]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o449893T009883; Tue, 4 May 2010 10:08:09 +0100 In-Reply-To: <23B6AE40-3304-432C-9AB7-DD725C0A1B37@xmlgrrl.com> To: , oauth-bounces@ietf.org X-Mailer: Lotus Notes Release 7.0 HF400 February 20, 2008 Message-ID: From: Mark Mcgloin Date: Tue, 4 May 2010 10:08:07 +0100 X-MIMETrack: Serialize by Router on D06ML901/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 04/05/2010 10:08:08 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus 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, 04 May 2010 09:08:26 -0000 +1 to option 3 I think the suggestion below from Torsten makes great sense, especially in relation to standardized apis such as mail Mark On 01 May 2010, at 13:36 PM, Eve Maier wrote: > Am 01.05.2010 03:07, schrieb Marius Scurtescu: >> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt >> wrote: >> >>> In my opinion, automatic discovery on scope values is as valuable or not >>> valuable as automatic discovery for a service API. I would like to echo one >>> of my postings: >>> >>> A scope defines the set of permissions a client asks for and that becomes >>> associated with tokens. I don't see the need (and a way) for automatic scope >>> discovery. In my opinion, scopes are part of the API documentation of a >>> particular resource server. So if someone implements a client, it needs to >>> consider the different scopes this client needs the end users authorization >>> for. If the resource server implements a OAuth2-based standard API (e.g. for >>> contact management or e-Mail), a client might be interoperable (in terms of >>> scopes) among the resource servers implementing this standard. >>> >> Not sure I understand, are you saying that for a standard API, like >> IMAP for example, there should be a standard scope (or set of scopes)? >> > > Yes, that's what I said. > > Scopes (~permissions) should be defined allong with the corresponding API. So developers should know upfront > which scope is required to perform a particular action. For example, "uploading documents requires scope 'upload'". > The same holds for IMAP. Depending on the IMAP feature set you want to use there could be plenty of scopes, > ranging from "read users INBOX" to sharing scenarios, where users have access to other users IMAP folders. This makes a ton of sense. It's one of the reasons that, in UMA, we tried to specify a generic way of expressing scope that naturally and closely matches a resource-oriented (RESTful) API: resource + HTTP method is a reliable shorthand for an access feature. For read and write and even delete permissions on (say) identity data accessed by URL, it's pretty much all the expressiveness you need, and ideally the same documentation easily covers both features and scopes. For any API that's more "compressed" (e.g. one complex endpoint for many operations), it doesn't really help. Eve From mscurtescu@google.com Tue May 4 10:29:01 2010 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 D26D63A6A43 for ; Tue, 4 May 2010 10:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.417 X-Spam-Level: X-Spam-Status: No, score=-100.417 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 GtmfL4A73slI for ; Tue, 4 May 2010 10:28:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9DBD13A6A6A for ; Tue, 4 May 2010 10:27:24 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [10.3.21.11]) by smtp-out.google.com with ESMTP id o44HR9Hg008152 for ; Tue, 4 May 2010 10:27:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272994029; bh=WX4FUt81AWwniF+LYoU6ZB2jqo4=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=n01LGAeL7Ip7Rx34C7W+mi6jAGGqvq0sPy2s0qmpe+GZ7Ti2zE3DRZQa/JgQNnoEu QmxkHcOAKujtfll0jSNiw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=sbpO6tGmQIGz76NzqT5KT+cXJA5Qx2L+67HrYtvnp4TZ1PJsJ5Lw4kYv2sKb+TwSE e9sNj3WYCVs32oHF1XM0Q== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by hpaq11.eem.corp.google.com with ESMTP id o44HQk0p026390 for ; Tue, 4 May 2010 10:27:07 -0700 Received: by pwi6 with SMTP id 6so1730033pwi.32 for ; Tue, 04 May 2010 10:27:06 -0700 (PDT) Received: by 10.141.89.14 with SMTP id r14mr4777969rvl.33.1272994025959; Tue, 04 May 2010 10:27:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Tue, 4 May 2010 10:26:44 -0700 (PDT) From: Marius Scurtescu Date: Tue, 4 May 2010 10:26:44 -0700 Message-ID: To: OAuth WG Content-Type: multipart/mixed; boundary=000e0cd13abab7f3250485c804be X-System-Of-Record: true Subject: [OAUTH-WG] OAuth 1 Bridge Flow 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, 04 May 2010 17:29:01 -0000 --000e0cd13abab7f3250485c804be Content-Type: text/plain; charset=ISO-8859-1 Hi, I would like to suggest a flow, or endpoint, that is bridging OAuth 1 and OAuth 2. See the attachment. The OAuth 1 Bridge Flow basically defines an endpoint where you can place a signed OAuth 1 request and in response you receive a short lived OAuth 2.0 access token. This flow can be used by clients that have a long lived OAuth 1.0 access token and want to use a short lived OAuth 2.0 access token to access protected resources. Do you have a use case for a flow like this? If not exactly but close, how can the flow be improved to cover your use case as well? Feedback more than welcome. Thanks, Marius --000e0cd13abab7f3250485c804be Content-Type: application/pdf; name="OAuth_1_Bridge.pdf" Content-Disposition: attachment; filename="OAuth_1_Bridge.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g8szgdst0 JVBERi0xLjQKJeLjz9MKCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZwovUGFnZXMgMiAwIFIKL1Zp ZXdlclByZWZlcmVuY2VzIDw8L1ByaW50U2NhbGluZyAvTm9uZT4+Ci9PdXRsaW5lcyA1IDAgUj4+ CmVuZG9iagoKNyAwIG9iago8PC9UaXRsZSAoMS4gUHJvdmlzaW9uaW5nLikKL1BhcmVudCA2IDAg UgovRGVzdCBbMyAwIFIgL1hZWiAwIDQzMSAwXQovTmV4dCA4IDAgUj4+CmVuZG9iagoKOCAwIG9i ago8PC9UaXRsZSAoMi4gQ2xpZW50IGNhbGxzIHRoZSBicmlkZ2UgZW5kcG9pbnQuKQovUGFyZW50 IDYgMCBSCi9EZXN0IFszIDAgUiAvWFlaIDAgMzU2IDBdCi9QcmV2IDcgMCBSPj4KZW5kb2JqCgo2 IDAgb2JqCjw8L1RpdGxlIChPQXV0aCAxIEJyaWRnZSkKL1BhcmVudCA1IDAgUgovRGVzdCBbMyAw IFIgL1hZWiAwIDcwNCAwXQovRmlyc3QgNyAwIFIKL0xhc3QgOCAwIFIKL0NvdW50IDI+PgplbmRv YmoKCjUgMCBvYmoKPDwvVHlwZSAvT3V0bGluZXMKL0ZpcnN0IDYgMCBSCi9MYXN0IDYgMCBSPj4K ZW5kb2JqCgoyIDAgb2JqCjw8L1R5cGUgL1BhZ2VzCi9LaWRzIFszIDAgUiA0IDAgUl0KL0NvdW50 IDI+PgplbmRvYmoKCjE1IDAgb2JqCjw8L0xlbmd0aCAxNiAwIFIKL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJyVVtty2zYQfddX7KPdiWmBd3Y6nXEce+ppWjsKPX2IMxmKhCw0FKEQoGX3 f/qfXYCkCFKQPfULZXIvZ3fPWYA4c/yDx1nktr/6px/G7Y/Q737UdLb6afY+nZnmYUwcN0oiSIvZ +TUB12/fp6vZye1FI9dA4H3Nikd6Cunfs6tUBdg7+4njum7SOntA5oNzumYCViXfQUFXrKICsgq6 iM4cJO/+wVCw1AnQoAAmAf3YZlvSDa0kLSDTnrQqtpxV0obCi/YoTvKsLB1I17QPqiFgSNEwmS1L Crs1rUCiwWXJMAOsswm0LM+pEIjwOxp2mHZZJYUttxsMubGmRlCjLnzRBdvWXNJclVNTwZsaX45Q 9uUBwuc7YeKT3JaXeENe+pyvswqjKK8jdax4DZkBzfzo9Al+zLx5N8LxI4qdKDDIFbhzx1cv8s3s /IbABz77ZMLzk7D9ruAdDKMsGyHrTA93yZ8osCovm4K2Za+4agGrHkFIuhU/G9UnsRP4QQJ+7A/h /zUMCOkBmBYPJxcPp7rbedvSTfZ9ykfBHis9nR8NFdKxJcXi3khqWjycvO+STkf8lJWswOrbcruM LdGEaFAGINa8llCyJ0S0H5k1YzgfMlpHag6F+I4Xh3EvdRIPaiUO3NX8iQnGK2y9zd3DlsZdrkOx U1A4ec3+ySTGgM+0fqI1bHDSUPC82WgqW7pxv7ixZvOQckfAuk6vDaV2YQtrDTnHbfVKAZdvkePL 4voSgthP3oFAMasyva/wW5rewd3t53Q/SpQ9QrIgcJNoj+BkitgkaM4rVEiTyzFHli+QFYWSxlgo 26zONlTS2qoWNw6GrFbimhbn1/6oMyLnW7MW4gcOyj+YOI3beQa3d+nN7Z8XHx1YtOCxfzqU3kTD onLHm0g3QWxpzlaMFlasEXESzye6mjaiJtlSC6dZCiqBr15bhdrJRhDXj4bQNuX+cY9T7uU7SaGo aIq4OrJsbXm9YMirQhRUab/uiNSTgrXHluYbniJb5AhC5MULnjodJ4zgXuw5oT8PR9Gnw82225Ll WrHnz2e73e4Mp7M5s2F0XSechy2JmrqkVc6L8YQ8RYzAH5lOiYHElnoTvODc8OBt7waFYvaXv7xL Z3F1qUOeXwem3y/4JL+2H8YB13JT+vP/50OSJJ77rv8VdgwnlIGLH4TMZGM74l21NpJOPqpoeDi5 /f3h1MYgojTR2x5lUMsQQwMHDG3yNX7PpLp6PNbq7jEY2NJG3pBWxRW4Dmx3DtVy9R0PXL5RnLFL xIGblbl4bClDMqTsBYvxTUK4kRMTJIRp++Z6QVvPw601dhoPUO87XHfvFMjKeqy0UqU1W720nZTq Ptrui7ajtqLUAoh6IfYNOdgrtsbqHDmqXu0h7Ymf97oc+mzLqgR6kPXIIU4IGYxTPaJuEyhpZaya XqJePxuSZIhmPRoMg4PloaF+m241Eke4ByJv7Do9HxZXn+5vFlcf2o3/xr3UAByHThjE7nHAhsEU MH3eMmzXNzaCG3Vra+R4/DhTcIumbm85uJLxJsCrQvTcGOm4ZCsq2WY4bP4DjFPMPQplbmRzdHJl YW0KZW5kb2JqCgoxNiAwIG9iagoxMTc3CmVuZG9iagoKMyAwIG9iago8PC9UeXBlIC9QYWdlCi9Q YXJlbnQgMiAwIFIKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL0NvbnRlbnRzIDE1IDAgUgovUmVz b3VyY2VzIDw8L0ZvbnQgPDwvRjEgOSAwIFIKL0YzIDExIDAgUgovRjQgMTIgMCBSCi9GNSAxMyAw IFI+PgovWE9iamVjdCA8PC9JMSAxNCAwIFI+PgovUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VD XT4+Ci9Hcm91cCA8PC9TIC9UcmFuc3BhcmVuY3kKL0NTIC9EZXZpY2VSR0I+Pj4+CmVuZG9iagoK MTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nJVUXW/TMBR9z6+42lOH1jQfjptMCIlNq5gEbBpBPFBUuclNa5TaxXZWxv/hf+Kka3Giaoi82LLv uffce44T+oH9YOVNo/3usBKa7jeUPG8UetUr7yr33HCa2dsoyiAvvckshjDYn+eVN7qtwKzR4n40 qA1wDVw8spqXF905a8xaKv6LGS4FaFSPqGywaZTQwEQJqJRUsEGt2QottkO9y/P7c8i/ezd5y+XI I6VHHiOFeiuFRljK8gkazcWqxTqw0NJOA0p7uMmM9Piz7bbmRUdv8nO82+3GlVSbcaNqFIUssXQS kiDw44Qkg4T9gRRSGBQGzNPWtq+hxIoLLGH5dKoju6EZSbuOvn6Jr/2Hm+subjJL3LSv7Rq+2V/0 663NpibB/2HCLEsDEpFvsONmDQxsZ6ANM42GtmmYj65YCQ97Uefn/inq1jJH6nlngWdB2gkwbvVt paxkXctdK86WKbZBg+rSyWYlsgPNgMb0b7bfrojhoZ4TMRSxM5ELIomfREEyAPWHMIa7+/z27uPb 9z60/I/8wPq3Qfjw+VMOS7SmtWJKkAJBVpcnqUWxH0/TvS/PehHUT9Is7UUMyXPrM6WwMItCYWmt w1mtnSQRsR4JAzJI0m/m7ALcwlGS+hmJh5hh4e6hLnQht+67ie3QsoSGLxcE+2zdkjGN/SSIsxdL NuLwQ8ByUdTcduu+r+nUyhYl/yg8HxVM40kh2kAaB50QGoXmhj+i498/Bd9HeQplbmRzdHJlYW0K ZW5kb2JqCgoxOCAwIG9iago1NjAKZW5kb2JqCgo0IDAgb2JqCjw8L1R5cGUgL1BhZ2UKL1BhcmVu dCAyIDAgUgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovQ29udGVudHMgMTcgMCBSCi9SZXNvdXJj ZXMgPDwvRm9udCA8PC9GMyAxMSAwIFIKL0Y0IDEyIDAgUgovRjUgMTMgMCBSPj4KL1Byb2NTZXQg Wy9QREYgL1RleHRdPj4KL0dyb3VwIDw8L1MgL1RyYW5zcGFyZW5jeQovQ1MgL0RldmljZVJHQj4+ Pj4KZW5kb2JqCgoxOSAwIG9iago8PC9MZW5ndGggMjAgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovV2lkdGggNDAwCi9IZWlnaHQgMTA1Ci9C aXRzUGVyQ29tcG9uZW50IDgKL0NvbG9yU3BhY2UgL0RldmljZUdyYXk+PgpzdHJlYW0KeJztnX9Q VFUUxw+ywIK/QPAX4kgz9o9pWk6T9sNxQm2ySYcUHHUyR0xRJ7HIGrNf0z8206ilNuWPotBKJLOf g4o/KGcax5pMUsRBpxlRUETMYAoW6HXvO/e+9xbYZR/B7mXf+Q5793rOefftvR/evl2953hSC45K oCuK7tJRXZev87nLg7RMhUE6j6aZk5u3D2CBNp/1CjOl7dHSpjOP8A46pMrYw3LkoCuiM+FC068P WBdMA5/y42qnMh/21KAtU9BkzC324nCALw/sZ93hFbFou+/qDPdj1+4G6bCupXlkys+yvyfX/ebn Aa6xHR6+YsOZR/Y2gL51I27Fsf57y9G2/ynWrPzMdCAJ/TBtfq0nXY+6tlyOUp4Eo8Tvcrqn+beH WXji8docHv3SZR6dcLDxUDxA0tHbWXiM9spZaRxacvlJzWAtjPow1pfpGB6H2PtSxvdQNJf10w6i 7foQ1oyoMh1itfT2rbh0jx6VbPz+1rsg5m/selZEzq1gjg/Wxm7nq7ypL4/ePi4qYyvAriz3+4LH 4n7SmD83Ns/kIYxyGOfxqEkE2Lscsvn7TVIN2pojWePymA4rj0Hm+4h8bgWIaMXu4QPT47jjSgKk 8FVO0KOqXRBZCVDVXzfyIwcaxuuxcIfJQxjlMM7j0RIJ7npm+MsNENmMtmuMEQytNh1WHtCeR4ML ouuxO/iHpoaJzNEcAZHmKrewcVpAGsWRwsh+2kfKYZzH42YizD7Kno/NAkisRVvBItZkFZgOvjJJ vnmcHw4p5+WA7qXVzFGdAMnmKt+I0l1X4mGYyUMYr/bTjXgGaZTDOI/HkRmwex57XpAPMOMw2sZX ToueVnWP6QBPetxmDVqSOuaRt77vG3uwey7TxW4Y7P6R695q8vhkvCvrJ/Z54dmYd0wewrhlUcy7 mjyDNOIw/HxO47FsR/RF/r3LfSkadi4RxrTS5jNpYDrY5526bA2+buyAB2smVXguTEDT5LJW9oGK fb4qubW23ogeXOwpvQtgYNH1Z0wewtj/m4Z1mjyDNOIw/HxO4+G+lCy7yRXd+QU8aumxgGPtfCmB 8OYBGQWyVzDH3rL4U35d04nRAUcHwmNszjDZDWsevUVTteaihW69SzwU0FT+shvy0iAseUztdVrD X/a/mla5YWwY8ujVOhfqF9D9yut1KtJfN7tAKtY/FOLF6wGF+m5gX/r9Q6vdOiks7x+hXl37Yjwa C2e7eJd4KKCpJ7LiRZd4qCXioZaIR3sFe6+JVcSjvSx7P4J+sRGP9tI67AZHDuJx/y9NVYsB7jxb N0u21i0fotU3mwAkFTcVJ+o81m2UYWJHCQqjcRgRrWX++eMQY1DiIeRrqmVz3EvqAPavfvCibL22 fGALeFHkLYta8RHvvrA3QoaJHSUojMZhRLS2K3bFh8agxEPIz2yj+D9jD+I9bL22fGAreFwfAANr WDfn9xgjTOwoQWE0DiOitVEwsNqIJh5CvqY6+LUvLvFtHhH8D6LVLFs+sBU8mLVPK+t+WplihHnt YcRoHEZEa32gj8eIJh5CvqZ66tWZY5izTn9vx9Zry4ds9TWviYP4G7y76mMjzHtPqR6Nw4hobSgk XLYMSjx0+Zpqw8R4voXw26zJF2XrteUDWya+9yM/Myo7ny9/ZOl4GebFA6NxGBGtbYpZtcUYlHgI +ZpqRvmN55hzTEXt47L12vKBLRPf+zHkeONB3AI0/ZAMM3fOgTwGhxHR2vP1Xw0wBiUeQl1digC1 zaenO85MPOxqg08P8ehQ3bAqoRPxUEvEQy0RD7VEPNQS8VBLxEMtEQ+1RDzUEvFQS8RDLREPtUQ8 1BLxUEvEQy0RD7VEPNQS8VBLxEMtEQ+1RDzUEvFQS8RDLREPtUQ81BLx6FAhS+l0Eo95+3guWtOp e+2WD59y1nMad0i3Kx/e3XIQD14+nDljV5fZLR/+xxOx607pPTvlw7skB/Hg5cO5M+a2n/LhIqfA u3w4UxwmDprlwy1lwUUhcczmlImgmPuJLhsZng7iwcuHM2fMyhf9lA8XF4b+ZJQPZxpZqj+Z5cMt ZcFFBXDM5pSJoJj7iS4bGZ4O4sHLh+sBa/yUD7fysJQPh5fxSjHLh1vKgosK4JjNKRNBMfcTXTYy PB3EoyVSX6LomVf9lA+38gCTx7iN+GyWD9eTPjVrBXCRzSkSQTFEZH1qAWd4OojHTczvh6hGP+XD Nazt3YbHyJ0x2DHLh3OPdwVwzOY0EkHFwdxlI8PTQTyOzMDrI+eon/Lhora3d/nwKd/FiTHM8uHc 45UOKrI5jURQ/YEuGxmeDuKxbId+//jn+GjwXT5c1Pb2Lh9eicNq1vLh3OOVDiqyOc1EUP5Al40M Twfx6LHy4aju+XuacOYx4e1hXnPtmfLhUsTDh3BiKbmnNS21W9YomApPHv0WFjfzbmqol9e2wpCH K213g+jmPt3blBvSpesRVYb6BZC8lLq+Qi++zbT59d6mzSFevB4QexeetLVWR5Ia6tuBbYXh/UOf l2t2YSPxUEJyavFZJ1JDuLJdUxjz6JUiHmqJeFgUykLhQsTDIrNQeMguMuJhkdZBL8hyAI9A64Tr u0o6rRNOPOyq7RQDrhPOKXRaJ5x42FUHswysTjjn0WmdcOJhV22nGHCdcP0/je+sTjjxsKu2Uwy4 Tjhf9ADqhPeoHMAj4DrhfFdJp3XCiYddtZ1iwHXC+a4S33XCiUcXFaSV6xkRD7VEPNQS8VBLxEMt EQ+1RDzUEvFQS8RDLREPtUQ81BLxUEvEQy0Fj8fJIJ2nJNRL+r/kLg/SMhX+B7/sL0wKZW5kc3Ry ZWFtCmVuZG9iagoKMjAgMCBvYmoKMjEwOAplbmRvYmoKCjE0IDAgb2JqCjw8L0xlbmd0aCAyMSAw IFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKL1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdlCi9X aWR0aCA0MDAKL0hlaWdodCAxMDUKL0JpdHNQZXJDb21wb25lbnQgOAovQ29sb3JTcGFjZSAvRGV2 aWNlUkdCCi9TTWFzayAxOSAwIFI+PgpzdHJlYW0KeJztXfuPFdUdv8Lu3bs81WUfPFxRXGQppNiy uxdUsvahptLUaE2MaQ29uyTGJibal49SUAG3CoKFRZaHIgqLoiKKYBEEfFRQZLVqtFqhan+w9qGx f8Dtd10chzlzvnPuOTNzZm4/n5yQM+d9Pnw/n5w7zAy5fEdVG1LJKZfvLCYbmUzG9hLKCmHxmWmf k7MdvalNBfpz+HnXjJ/9KyT1NGTmXOItMLydCM98Bd9aWV+xl+9QzCC++cDVqi9GZepQkATvDWsN ufwciE5bdJRmFO7o++i/SOqJ2OP9yqNumV/5SiDjB5WO4ji++cDV8usJnDcKlJ9fQXR6ogN12tTx sS2ala/z8H0VhyoK7iQzTN9JVfwqcMHuQdztVVaiXui75pLGFBlT6S5bhgbgVyaiA3Xa1DExKUZ+ kTUiWV/FoYp+ShQHYbTvae+7Hn7B7sEzZedXDD+lAn5lIjpQp00dE5Ni5BcT4FdiS9kIvuX8gsUp fFfruxK+pe+8gS1lhcy+xO4qvJUK+JWJ6ECdNnVMTHok4IGnjayv+lBFPyXytb7zquxF1sC9JE97 RceQ8eM7r0iRzF5MZhc3ZQ74lYnoQJ02dUxMyrTmq0dZX/WhipLTglhblOuOKWd8w9PMPbVvR37N 6vMyVDDdZSbG7x1+lYQEvzKkjolJc7/ygB9K7CXO5W4pWzOzF/fIgQ3cC/B09F2JrCUzL7/3KApl 2y8V8CsT0YE6beqYmJRpTTH+ZWKRDcV0cWrdHWWT+l7K9sKvVtbRdyWylsy8vlQEdjcplG2/VMCv TEQH6rSpY2JSpjL1BmWDJOw0UTzDr0xEB+q0qePDUsWvwpZCssAfkGJeSWxzZaf3a2poyxxZA/iV iehAnTZ1sUkASBFy+c7jL7u1dmTzhUy717jgVyaiA3Xa1FmRA5BwfO1Xx12rkG3ryLV0uBrAr/RF B+q0qaPIRELypOoZJ/qVK+XaCvRrEX5lIjpQZ0IdElLpqf+jKBCdtuhAnR51WSQkIVWxH5TL0gEM fmUgOlCnTZ3FmyRAYpHLe38PZsmg8h3VbZ1fNcDvQX3RgTpt6uzqAkgmcq5/H6Sfftm2zkz7ghMb wK/0RQfqtKmzpQggyRjwq1xrITPN/xEs+JWJ6ECdNnUxCwEoD8CvTEQH6rSpsx34QCoBvzIRHajT ps524IeAsn8nKIGAX5mIDtRpU2c78ENAoF/B0EIH/MpEdKBOmzrbgR8C4FfxA35lIjpQp01dWAEc +P0llZLADzeJ30lQHM1dqz6p4k75hYUyadIAvzIRHajTpi6sAA4Uo0oJU8jomncJp0FY1sGvTbFZ qZMmDfArE9GBOm3qQo9kUYyyWk+JTMWyEvcIeqMxq2WsgxmN3xc/Kfzq/yHBrwypCyuAfc8J6n7F uFNGfjhxGot5Fb8SC33HDNypr9UwjhS4kuQDfmUiOlCnTV1YAczYjtiMLxHHZEqKaucrsYRxmCLr V+JKZKPJbCpwJckH/MpEdKBOm7qwApjxK/USptC3mbsxP1rRz2F8m4n5wJ36LkxxC8y+kgz4lYno QJ02dWEFcKAYVUqYQkbXKqN5WvLNii6LU9mp78IUt8DsK8mAX5mIDtRpU2c78BONcA0kRXYUCPiV iehAnTZ1tgM/0YBfyQC/MhEdqNOmznbgA6kE/MpEdKBOmzrbgQ+kEvArE9GBOm3qbAc+kErAr0xE B+q0qbMd+EAqEZ1fef7BNFuVmzCx+YZ5i/ku2rVWRAe/0qbOduADqUSkfuXkj3z4xUvvfLL56edb Zs7q2bLDfEDrCX5lSJ3twAdSiXj8ykm7Dr7TPGVaiAPaFR38Sps624EPpBIx+9Wzh98fe9rpToOb Fy2rrR9dUVHZem672GXtwzubp55DtdTlpoV3u2tXPfTExMlTqWpc4/j5d3Z7OnZvfLypeUo2W3Vm 06R77t8anejgV9rU2Q58IJWIza8Ovvfpg0/up9+Dzi0sajD1Wy07X3573+t/27TjgKdL764XR49t XL/1mUN//dfKBx4befIpTu3mnS+Qy/X0PkVVZEfDho9wd9y4fV/NqLruB7dR7bpHdtU1jHlg296I RAe/0qbOduADqURs99sHMLiiYuuzh5wGZEeeLk7+ez+4tGvl/c6l+xB18Y+uWLh8jVM1r2uFu+MF F82+fVmPc9nVvYFKIhId/EqbOtuBD6QSsZ2v6LTzxP6+K37a+ZvbljgNXnrnE1mXmtr6/W986FzS D0mnlg5XdCRzqvYc+cDd8ZSaUQfe/Ni5pPypNbURiQ5+pU2d7cAHUomY71/t//NH7RdeImvgLqmo qHzt2OfOJeWdWjqkuasOH/3M3XHQ4MGeQ92gQYMiEh38Sps624EPpBIx+9WrR/+Tqx4ia+AuGVXX sLfvqHNJRufU0nnpub5jThU1c3ccMfLk59/6ezyii8evNu04cOHsy2jXZNR1DWMuv+pnu199z5e0 UP4JdfblV8VAne3AB1KJmP1q4/Z93/x2m6yBu+SSy65csORe57Kre4NTe9EPL79jxX1O1cLla90d Z7Z/f/Ef1juXD2zb29Q8JSLRxeBX8+/sbhh72q1LV5Mt06mSjHpe14rRYxt3vPQWw3Pof3GhU2c7 8IFUIs77V2u2PD1+wsQVGx6V6cJdsm3fkYYx47o3Pv7KB/9e+/BOOm45tY/sPjhmXCMVUlXPlh01 o+pOOukkpyOV0FGEZqEZe3e9eGbTpEX3rItIdFH71dZnD9GB6plD73rKr/3lvFnfvVhGY7h/cRFR ZzvwgVQinn8fJD8ZNnzE9Bnnu5+G4v2q78vD2NRzpldUVNJx4ne/X+muJVNqnjKtsjJLxnXL4uVD hg51d1y2bkvTpG9QRzqZ3Hj70uhEF7VfXXrl1dffslAsP/Dmx87hk/k9KHsOjZrd99juc1pmZKty lCeilq7ZLP6tRbQp+BWgjTJ433nny29PnDw15knj8Sty48f2vsq3kfkV8xwaNTvr7MmrNz9JVXRJ ZkWW5TtIdNTZDnwglUijX5EMb160jM4Yrx37/PHnDrfMnDWva0XMa4jHr8hGDr73Kd9G5lfMc2jU jBxMZZDoqLMd+EAqkUa/2rBtD3kU/QakXzr0u2/+XaviX0M8fkUb/NO7/+DbyKyGeQ6Nmh16/58q g0RHne3AB1KJNPpVElI8fjV+QtOje17h28ishnkOjb9zCL8CEgv4lYnooqbuxz/puOG3i8TyIx9+ 4TyzIbMa5jk0+BWQUsCvTEQXNXWP7D5YP3qs+7nZgURmVfj5LwbyMqthnkPj/cr9cEh01NkOfCCV gF+ZiC4G6q676bZxjeO7Vt5Ph6XDRz978vk3rrn+5mnT8y//5fh9LZlfMc+h8X5FBzP6Ebr9wOuR Umc78IFUwtCvMnJoD2goB/URTF48ifN9nOXrH54+4/yhw4YPrqgYd/oZc6/7tfsmPPNTTvYcGu9X N8xbPHTYsKpcdUTbgV8B2jD3q3CDOeqbJ2HNhfedDamzHfhAKgG/MhEd/EqbOtuBHyYyZfQfKCcc UfsV8+rHQJJ99Jgy1LLxjAlUNXHy1J7epzwj3722d8LE5srKLP0pe80nuhdP4FfaKXS/GvhLdDJu uGuZvu72YpXKAnzzJU0XWAsUY/Er5tUP5qPHlBk2fMSS1Q9RFXUfVdeweecLTkdyuZra+oFPIt+7 aXvNqLr1j/5RXBI/O85XVlK4fuWxJt9CmfxFf/M4D/wqaYjofru7AfPqB/PRY8o4XyKldPuyHmrs XJ57wYULl691Lm+7ezWViOPzs8OvrKQo/MrJy8oZv2K6+JqYJ+9po+g5jF/xtZ5J+akVmxkOGCdi OF8xr34wHz2mjPurdM/1HaNDlHM58pRT3Z/sozydzcTx+dkDFx8oOviVNnVhBbBHX+7CjLFf+bYR 8+IggYr2rZVNKm7KxF5MChV3Fx1i8CumhPnoMWU8VZWVWedy0ODBnloqEcfnZw9cfKDo4Ffa1IUV wIy+Mvb8SiznpxYH9K3ll8dsXL1QXIYKLbHBrl8xHz2mDF06VXuOfNAwZpxzSacp9/mKakeMPFkc H36VwJT881XGD54pinK/8s0z88oWINZ6Wvpu010osyZxGbJ9+Q7omTdO2PUr5qPHlKFLp2r+Xasu vfJq5/LL+1df/5dety5dnT//O+L4/OwmL57ArwypCyuAGdH5ClPWtyi3Cz2xFyV+xYhdtgB+d8z4 Mr9iTExctu+AtmDXr5iPHlOmprZ+4KPH1GD02MYn9vc5Hfs/g1xbT3/2fxK596lTa2rXbHlaHJ+f 3eTFE/iVdkra+coDsb04FDM+71eMWckG9x2NWYa4kcBmsmUrDhgnon4fJ8M6Rp/8o8eUue7GW2vr R1dWZltmzurd9aJnnCU9m84462zqeGbTpGXrtviOz89u8uIJ/Eo7Jef+ldil6GcpgYINFD4zXZH1 B0/fwHFke+GbyZatOGCcSOz7zpkYH3TXFl0yqUt4iu75K70GZYzy2zX8ykR0yaQu4SnQrypb5lKD oS1zFGNYxa9KU0W5oPw2Dr8yEV0yqUt4kvlVdVtnVX/qGEgUmfHLAUg4EutXCU/wK0PqnAjMtF+b zRfcTgW/AmSAX5mIDtRpU5dpX5Br6cgSh60Fj1MNpOq2Qq61AwnJnapbOiE6bdGBOhPqkJD0EkSn LTpQp0cdHeyzee9vwBNTIduKhHRCoqiA6LRFB+q0qXPuSPTfZs/TD0PnV+HxDO5fASJw/8pEdKBO mzpPHGbaF2T7b7kXqlo74FeADPArE9GBOm3qZAGZmTYn9+UdePgVIAJ+ZSI6UKdNne3AB1IJ+JWJ 6ECdNnW2Ax9IJeBXJqIDddrU2Q780lB+L7akFPArE9GBOm3qbAd+aeD9Cm4WG+BXJqIDddrU2Q78 0gC/SgjgVyaiA3Xa1JUaqIGfclIp0fuyU2Azz7DqkwKlAn5lIjpQp01dqYFq0a+KQZ/U84ygPilQ KuBXJqIDddrUaUes6ACyWk9JqUbnGURjNGa18Cs9wK9MRAfqtKkrNVCZE4vYTLGju9C3mXsQMaPo fr4eBb/SA/zKRHSgTpu6UgPV0K/4MZkSp9wzmmhE/MKK8KswAL8yER2o06au1EBl/ErvqOMp9G3m mZ0ZrXii1zHNxDygDviViehAnTZ1pQZq8v1KvVkRfqUL+JWJ6ECdNnW2Ax9IJeBXJqIDddrU2Q58 IJWAX5mIDtRpU2c78IFUAn5lIjpQp02d7cAHUgn4lYnoQJ02dbYDH0gl4FcmogN12tTZDnwglYBf mYgO1GlTZzvwgVQCfmUiOlCnTZ3twAdSCfiViehAnTZ1tgMfSCXgVyaiA3Xa1NkOfCCVgF+ZiA7U aVNnO/CBVAJ+ZSI6UKdNne3AB1IJ+JWJ6CgNP+8ayiOppyEz58KvAD0M+BVEpye6XP74f56OVFLK 5TttBz6QSmTa5+RsR29qU+F/1syJ/AplbmRzdHJlYW0KZW5kb2JqCgoyMSAwIG9iago0MDk2CmVu ZG9iagoKOSAwIG9iago8PC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UcnVlVHlwZQovQmFzZUZvbnQg L1BYQUFBQStBcmlhbCxCb2xkCi9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwovRmlyc3RDaGFy IDMyCi9MYXN0Q2hhciAyNTUKL1dpZHRocyBbMjc3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg Mjc3IDAgMCA1NTYgNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3MjIgNzIyIDcyMiAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgNzc3IDY2NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDU1NiA2MTAgNTU2IDYxMCA1NTYgMCA2MTAgNjEwIDI3NyAwIDAgMjc3IDAgNjEwIDYxMCA2 MTAgMCAzODkgNTU2IDMzMyA2MTAgNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMF0KL0ZvbnREZXNjcmlwdG9yIDIyIDAgUj4+CmVuZG9iagoKMjIgMCBvYmoK PDwvVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnROYW1lIC9BcmlhbCxCb2xkCi9Bc2NlbnQgOTA1 Ci9EZXNjZW50IC0yMTEKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDAKL0NhcEhlaWdodCAwCi9GbGFn cyAzMgovRm9udEJCb3ggWy02MjcgLTM3NiAyMDMzIDEwNDddCi9Gb250RmlsZTIgMjMgMCBSPj4K ZW5kb2JqCgoyMyAwIG9iago8PC9MZW5ndGggMjQgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9M ZW5ndGgxIDIzMjg0Pj4Kc3RyZWFtCnicvXwJXFzV1fi9b5l9Y5gdyLxhYCAM+xJCguERlphgAmYT ohgGGMIYlgkMwWhNUpcsxCXue4O2ahq1mYALxKRSrUtt/YzV2tRu+bexLjWf+frFpRpm/ufe99jU tv9v+f2Z3HfPvfece84959xzz31MQBghpEM7ERu/sa07EN6wflMz9PwCIWxu2xoR/v3kHQQ+hZBy YUd4U/fD7L9bEFI7EOKXbera1tF/sv1qhAwtCKW0dAYD7a/dol2AkH8C5ljQCR3mF3XPQfsLaKd1 dkeuHPyF5hOEspOh3dXV2xZAePAKaO+Bdrg7cGVYEUs4B22CL/QEuoM/D8V+h1AO8EupD/f2R+JZ 6NcIregk4+G+YPj7tmut0AZ6Uxf0YUTWQ1aEsAL9yx88p8UgxHJzEXiFclZLpf76BBqtTm9ARlMC QmaUaLEim93hdP1rxv/ffvijKJmWx1Ay50Og9/jpqRILxU+TMVIzH4E2UqQi/4ygJ9CvcSYW0Cj+ EtnRF9iJC9ByxKHPEYsOo0l0J7KgtegubEZpyIbWoeWYAxw/uhHfH98a/xBdgG5DD8efxdfGD8H4 Lehl9AVI8AcOo1K0CvDXoSD6kH0PNcXvQyq0G2nRYrQa21AAvQOfT0GG29Ed6Mf4O/EvgKsFXQvz laNKVBn/Sfw8ykI3cvv5k+qn0a3oOayIt8VDaB5KRUOMP/5O/I/Ih5rQ99ETIJMfT3AXIg/ajG5A 92An+zJAd6IfoBjWMc1sFf88cFqO1qMeNIiG0CH0GjbjBv4kfzZ+dfx9pECJKBNkCqEPcQleyTzC 6eJL4u+iS9E4ehXWSz4T3KXcY/ylsYr4g/EXkBU9izX4GP4JX8jfPPnd+EPxH4FH+lABaGQV8GlF 16GfoJ+h/0B/Y3bEd6AL0Rrg/BJOwQL2gcbfYZzMdmY7+xbKhdU2g7QD6ACKgkWOoufQcdDNb9Ep 9B624CS8ArfiW/HfGB3TzrzB3s8+xb7NYe6HoG8vSgcdRdAj6BnYz6+jNzAP8+fjBnwF7sV34wfx KSbKfMx8zqm467ivuEneFzsV+yq+Kv4pciAXughdhXaAbr+PRtFT6N/Qr9Df0H+iz7AJL8Sd+CEc xafwx4yaSWXqmTBzF/MI8yS7ir2V/QlXwi3lNnOvc+/yu/h9yoAydv7R2O2xJ2Nvxp+Nvwm+Y4D5 fagWNPpd8IpH0PPoLZj9N+j36E/Ef2D+xXgDvhy49OM9+A78JH4Jv4k/glUi+kllFjPVwLWX6QM9 XcvcztwB3N+AzwnmXeb3zF+ZT1meTWUXsFvYh9goO8aeYP/CmTgfl8sVcPXcBi4Olinkl/Fr+IP8 4/wL/FlFuaJdEVZ8oLxWeb3qF5NZk3+IoVhnLBobBd9VgSddBZr4HnoY/P4psMFroNF/A4lPoXNg BRf24AyQuwzX4jq8El+CL8NBfC3ejW/D9+D78cP4R7ACWAOjBNn9TCWzhgkwQeZ6ZjdzE/MUfI4y P2PeYU4yZ0ByO+tl/WwBu5zdwF7K9sAaIux29nrQ7K3sIfYN9i32ffYD9gxYzc7N4wa4q7h7uce4 p7g3+Yv4bvg8zD/PT/Bv8uf58wpG4VIkK/IUVygOKv6kVCgXKBuUe5VvK/9TFcbJOAskF2ZHC8YJ e3Aec4ixcDvwGehIwRwywsr9YIc1sCv+E1WwMbCLgYyDbFbGySUSSoXIRYE+gp9DJfgltEPBsBBc uVNoBP+OOcW9yFyAfoVbsJN7jO3hX2M86HGIRvuZY8xzeCl6iiln1jMPsAi/hw+i98Dfr0R34M24 Hz2Oz+BF+BpcinegtxkbuwZfj8rjDzMcVuPl+CwCCdB3uXZ0+T+PgrgM/Q59GPsep+e+A/FpDN0F Fn0C/RH/EH2J+fjHEN1YiEYBiDI3gr/fgEjUa4Z9tgP2oxMiSJfiDfQUOVGUpYol3FXoLPo7+pA/ Ch61FCLp+7EQ9z3uz/HSeA7sMNhl6CDsu060DHbMe+Alx6FNWpfBTtdALCmEXd2ANqB2dA1EvVvj 0fgD8evi2+K96OdA+yXOxl/iYdgRY0BRjl6Fzy3oN3gf7MNl/71TINaOJtBH2IHTcSHshzP8Vn4/ f4h/iv8x/7qiALR9PbofPPpP4M0aWEEbehN9hD7HKrCNE2WjYpB3IcjeiLqYJvY4qsIuFIY9mwlx fKm8kn6Y5VrQ3gOwn4/D3jgLceIy9GN0EjPYDitqA/4qmKcO9LwRsB8FC16HR6GnHaJ2FvorrNuA FzIR4CfCTHdB1JoAmX6H/gLajlO5siEuVOP1MNfn6BLUDhwWoAZ8BNXGn4FItQpVs78AfadhE1qK U/EPgK4FdqgBpaAy/s+YQdmxVfGFTIg9DmdMHPqH4fRKQhfgLSCFEdYxiay4HpXEVqNsURQrllxQ vnhR2cLSkuKiwoL8vNycbH/W/MwMX3qaN9UjuOelJCe5nA67zWpJNCeYjAa9TqtRq5QKnmMZjLJr vLUtQtTXEuV83gsvzCFtbwA6ArM6WqICdNXOxYkKLRRNmIspAmbH1zBFCVOcxsQmoRyV52QLNV4h +nq1VxjDGy5uBPimam+TED1D4ZUU3k9hPcAeDxAINY7OaiGKW4SaaO3WzqGalmqY7ohWU+WtCmpy stERjRZALUBRuzd8BNuXYAow9ppFRxik0oNQUZe3uibq9FYTCaJsek2gPdpwcWNNdZLH05STHcVV bd7WKPIujRr9FAVVUTZRRVVUSdkIIbIatE84kj0xdOOYCbW2+HXt3vbAZY1RNtBEeCT4gW911H7V acdMEyY3VzXunj2axA7VOEICaQ4N7RaiExc3zh71kGdTE8wBtEx6bctQLbC+EZRYt0YAbswNTY1R fAOwFMhKyKqk9QW9NaSn5QohqvYu9XYOXdECpnENRdHqbZ4Rl0scj59CrhphaG2j1xOtSPI2BaqT j1jQ0Opto05RcM4dyck+YkqQFHvEYJQBnX42EJweoxBFJ1Dd6mnNYiKRdzk4RFRoE0CSRi+saSF5 BBeiobaFgAY/TRioou1gkVBUXdUyZFpE+gl9lE83eYWhTxF4gPfMx3N7AnKPIt30KSIg8ZNpV4Px KTjq90ezsoiLKKvApiDjEtouycneOsYs8IZNAlSgPtQAug00LcoD9Xs8xMD7xkTUCo3ozosbpbaA WpNGkJjnb4oyLWRkYmrEuo6M7JwamSZv8YInP0XTemtU5Zv+ZzTZEms6F0Wx7Z8MB6XxujXeuos3 NAo1Qy2ybuvWzmlJ4wunx2QomljVyCYxMsQksXQUnPKyaWTSaNRFuXT4p6BO3R5lwSlpBxZqo6aW C6Vnk8bj+Yc0Y0rVLKKx+FlCRasZMlnK6CL/3PbiOe050umGWJCX8zF1azcMDWnmjNVCABoaqvUK tUMtQ4Gx+M5Wr2DyDo0zjzGPDYVrWqYMOhY/ui8pWntjEyyiEy/KgZSAaJuHD5ywSrT0KQbHFMox pkJMRDwXY5FGycUwcqoUfIxhj2EfUkNi6UAOv+mz8snyVaZz5Ssny1EFwKbz8CjI9yR4EtLhgeGw Pi+wE+dFHn2FBG6CXOduh8cT2Am80kQrsxBpGJ8RuZGA8gHbyW3a6vDDlM0rJ1HFyjMF+UUw1+0k gY+9T6gfBiF9/ARSo/WiejNzNbOPYRluDM8f3chjfoy5/FmVmsdIp4b7RiMkophpFvU84tycwEU5 jnNqjuLH4OSWmJSvJCsA0SvKzzWfKSvIR80eT4JCWbIgrbSI9cXev+/NHszkn+a8+2viaT/bRSQo gpxJBxKkYK+48WnHM67xpNe4VxwnHCecJ1yqqqSq5KqU9c77uTsdh7hHk1UKl4AyFaWuC7kqR5Wz yqVKc6Q501yszcet5/Y4Hkh6IPmBlEPJh1JUZpRiShFSClK2plyfsj/lnRRVylh8QrRZrMUpjEln TDGBkhiiJxGUB0OjZlsxGmMeGmWwzjiG14tety5Px+hE6Nc9msirT9pscFhi5HIbT5oGGee8t16g 61557swq02dbystXms6gikn/ltNgPH/zlvIEcxlOKPI3gz+Po5T4xEhCGZFhxEgr0WAq41SmMl6V AHVCmZ/+NBXk4+a6ixuPoySIqclQUuKnFi5c2IS3NDc34wTPAnPpgtIFJcU+b6pCmb4gragQjmOF UsEplJzufIZp+OMf+xcFmxo7VbEPnFj18m++WLayKPbZMhvmY1/dgdW/PVJxybrLg1dcnfzBax/9 qG20tfJcg4++CgCvfR5ux0qkwYXjSBk/KapLy4oVmfBQEnnVmSXFChEe0DopNngyYAwe81EWl8Vn avJ0C1EpX6G7Al3BBNkOvlO1SfMBa1yhwIxKjVmNWs0p1RjSPaUFskqFmuMEXmHheYVKI7pSlmgI C60rpViTzrCsglOP4WOiQaFkeA6uzyqd3e4C6wRErRvTS91OzOIxJk1Uu9U4X71TzaiPMmmIAwy1 AL7r1F7eNuX6zs+at5xr3uKYXFUTrP4L+Ge5CVx05RmwTx5Yyl++m8/1777mp7tzHaRSmsrLd//0 p2CIuqh2TV10HoSRccTGYyMqTnM0HgPVnD+i4BYulM0iGc7jYeGDPYksyz8f+/HOyWe2xV5mFuOy rNdexitjo/zR80OMMHkKnO0u0HQraDoRPDAbnRQrBrNwp+HKrL9wn3Gc2mNVKzKzPek2s9tab2Xy rYetjNVq8aammxNVgiUdIyYpI6zYCVedusyMwzqsI86r1hbrxpgbRU9+rpjbkNuSG87dmbs/dzhX JeTm5zK5llQBCYn5iUziGLNvNKdgzdSWnQS3bd7ymX/LyjOwaWncISWhLK95C3Vca3znSEqZlTiu i1Q7jyQSX20CJAwaRFCmVWUEVR3RCKCWZtSc6CmcxxDftBEPBRflPbAdCksXEO/N8HnZBI/c8Hnv Ylb86PHdG3o37trf/NDWFbH3Ynqc+cKTWRddUrci+81D2DzsX7pG3PYafzTlsns3bnrCn3FsR/vx LXoVw70ce5JXX7Ksep2anxyPXanWNa9aelkWiS2B+Pv85fxbcLN/W1y5S73Xstd2AN2jeEX9Nvu2 9lNWna7O1GXq51vm2wb4AfUuXqVMVNrtiXb7fCaLTeeVmXwFrsf38nerf8a+pFXi1SbyXvAs7BWi 8QRHMa01eqjxBtHuyOFUBtFgLjbUbTTieiM2ilZHMYSSTDHVnKNhjZ8Y1qNPEEzJYFd+Mk62Zgwr sVHpVuYrWTghbhxN2i6bBYyxytT8WTPYhISUcxBNTvtJTQASVzEJBryC8woowYQ8gt1m530kJCSY bEWFC7gK7F4ae/3j2O9ie/BVuBjrD7YXxn7remTr93/+6vDWQ0zSpWc/xLfgDbgH33ng8mht3/Uf xb6MffTxXSQSNIHe3ge9GeGu8LC47m7+btU9unsMnAorDSqj0pHhuFI9aFYOJlxp3cXtVe3V7TLc YN5r2WPdY9/j2OXSKc0qi9JlNbssLofVpUzM0audOUrWlnFYg5HGpBE0rIb4qpCfIqa0pIRTdqYM pyiElLMpTIopYxhhcoLlk6gMOkne/uK0TqinEgBVnKk4QyJl8xbws2LwotIFRbIqELaYQQVShGyq Knxy095RuETdENseOx4bj23HBX85cuTPv3/22VPM26fuCY/4F8V6YvfFHoz1gkI6/x6Lx+Pnv/iK 6OFOOJu+gH1K9DAopiv4ccu4g13G4038OzxjTkjXGwwoyZTOYMaIVLA8JVbKe5GYU7S5U/Ll9fEp JqOAyWkDzgMbMHnuBpT2Hz05J8tpVConVt6Cm+HABuPKG8jrdTKwNHn/3Il/iw2rtx9qvXvVFT/7 ycOHt1ZdfmHJMH/U5vn94d1joQTr5K+5F2Itua2VDZ16DTBeHv+Ay+WWIC8qxKvETqVLlcyn2Fwr ki5MXp7+W9MfE9QLnLXOS3wdzk2+Xb7bnLe7HoXj+BXXq0k6hUJvtSmctgzFfGuTc5DZxTyqeFrx skL3fPFvTExKWmFBQrY+TfTnFqeJqZnwcKYU96adT2PSaulZl28wFl+QgsmZHE35ewqXkpKNi5AI vcTWDFrnEZMTKjxikgkeDlexZ4yJPM0pdXpNNtEojNEahmkNGNmAIYoW7bwCn2q+OlPf5NYd0DFu HY5DRBQNcGa76otxcQvEgZvzMcZF8z0b7fiPdlxv32jvtbN2Z1GoUvasPthnW840ky3nl1qnSR5z BsIcmAROCP+5Zv9pMwmJ/jMk3kPMYw1wTICV4AAghspYsABOYpuVtdjsHrBOhkLhTfWVFBPPLJV8 ERMTWi02EgLhBMfBuP+Xbxwbq2OT0mMfaU1K9sIfNP/g+Pr7b3vpoobeurX48gUfpZU2Vl9UU2TS Mn/Kve+Opr3PxsZuvOGi5FKnqrZ2ZM+Gm+qS04Xki2sWx35pLnRklC9eX+grTQsS390Ntr6D+m4y enAcmeNfiAXastKkZUmMeb1ivWa9bb2jKflzpaKEW6xfnFiSVMPV6esSa5LuUN6r1ugMEKOQC1Q8 wistRNOJWq0RaewelSs8D88zzWdYH0S2+aIOh9FO4OdMqZC0uQUO1snyv6wCn5Y8GnZqBfHmLRC0 qhpFbYeiQ9Nh63CEkvnmJtTsJykp6M4Mmxc0lmFNtNht0/t3N3ZeO/JCLDY5fukR0Vy8fFvzdddv Cu7ij06evSP2fuzvsbOxdy9teoDJeqQ+fODxZx56kMT9dbD2CvBzJ/o/4sWNxiZzk63TGDKHbNc4 tjnvZu7WvWx62fFr0zuODxUfqj5M/ND6hSJxYeJC6wrzCluto0kX0ikXmUttpQ52kB807uZ3Gfc6 D5ofs42bn7GpDdT/kopJ/bTZUmwo0pMe57xiWhsTivVHMQd5eEQ0J2iRCKhIBDxUtB+88CiGLB6G BLsSk17sQXl6Aug99QZscCUpPRanq1FSJTkEyBngP3fGT06B5tN+6RCAWgoPoFMp7FO3WlDKE68j YRB8kSuI/dXQVh+6Zsfmhg4rtvjPvf5h7K/YduaF95iPC9esvfXQ8Qcu7c378QvYhzmsxOmPEb9Z C7oLyH6zX8wxNymaNE1myVvuAdf4Qq0Oz9s5j1nEFusWWYudK9hq3QprtfNetdpC3UVLvEY0aJUG I5hCY59v0Psw8RSjEbluIb7jUTlTGsunV7jlM8ljaPST4jqcb1uIr+hDipAmZJa8RdHc5PGUyAuE CG+HG9FsV+ECsa8qj2x4NvZV7IWRa7Fz0pxXfVVgz/Wb2nc/cGkTzsAqbMDOOxjT+fChi3oe+cGz Dx2A9VbCejPAVywoGX9/HJlgn9Rqy+5V36e/y3SQf0zznPo5/ZhLpbLgC5llilpN/byD+mcUz7he 0byqe0dzUveF8nO9PtmYbBWTUoqtoiGh2Gh93vqGlbVSb5hXQWuDHWrmJlFnNJgbDC0GxuAwYxh4 xplUjIvMNI9IEaR8InW+VPtzpNqRTGvRCMFymFzlTSD2RrMZ1DzKac0Oou40rRJ5cJ5VcqK8eRvn 9c47MI+bZ/SoRL2xGBQuxzr/nMTiDCR4osUhZloqHOI8IzwgwDpIJKZXkYpJmgCaQQjAMBNhAMks B2JSj0yhQhClWTAlQDAAiSEZt5MqOqrWLKHNSk+FHxH80ySENlP2BhG0ZCBMDYQ9ZFD2CkQnpcl5 H+TnkDaSwx7Oej8mLi5k+EqIjyPWYyMOkEj2gFJhZ77EjgUfHo799YYQtrx1BpsVkyJ7bWDphgz2 yvWXlZdjvDrvvoeevvX34Av+2Cux49fsuxB3XbWjqqqf+n7sYq6Fno95uFBsGUzZncKYdfpwwS79 zgJOwF7Gy+bjIqaIFXEVU8U2GZssTenr568HUb9I+CIxYbG+yLY4syi7Tl9tq8uszj6rm7Rrbobz SKvTa7N0+gyDzW7N0evsNs6RRuz/NLU/NbMhgapoVKuT6swsyfzedKkuKJbcQG1NoofaRp5sN7cx g1QGTQ5xA61V6XAqsuZrfS4H2XJqp9PluqUAF8AGHBM1qCjNY3bmT++9c/LuM50xTZ6eCtWT5/qk C81pP6T3dprfl5GiVJmmwvgWujeNIUsofdP8Dn8oT0EiuZ232acOtxLYprKR7CWeBIuB8QpwGiZa ZvbrNlypSslc31OanqjfPvHONa0YP//STqxcEn7ultjf/nT+upZNN+/pDF5Xm7HQOs9jK/Befv8T T9/yK6zFrifvPL/s2NErysdvNjDX/fDBh773yPCDoJLbIF9rgthlQyOi34jduIwYy7QUL034A/47 Vit5G5/GNCZ0JvAYM4mWBHMia2GwkaguhVWqNRqLVWNDSKvxqdSikFZ8WI3jaqwGZZI3B6lpxfsd ww4m7DjrYD5xYAey+GxWujUBd9iKz1qx1WmvkNS7pc9PcjvYbQB9JrdojCO3zzOgUzvNIVQkh4AU ApNDEO5LcBoW05CuICB+fM/xwAP1KbH3hYsvqO0pir0PR997By4M77ll8lam4LENJdV7d01+DIsG /6XvggAk750Gx5EaJKtI0FSI6gY1s1MdVU+oT6g/UfNudYt6h3oYOnhWoUQ8x0KkFtEJRO6mzXDu K3iFktMwSjgXqMd50oo5p0pe18w6IFdt3lLO8iayIikT6vMnEqGll0yx97GTewZzsfNfreB8X707 9baKSrhmHPEw93wiH9/AMzv5KD/Bn+A/4Xk338Lv4IehgwdhWDhKWR9GU5IgJ/cNSWTe8sst/uiX tcDrVuINsJtt6IDoUCbaEzeoOlXcGIeLVcWmalW18UMTr6CmT1Aa9AqdVgvHFYN9NkRNj3CcvOv5 B6bXaH06A2yxEb1eN+0BOnwW9vpcDyB765tOQF9ATJ90njkm91glR+CaYu+nXVy2POIHRfL73mq+ r97NzHsiuLDh+pGYm/M98FRV5/VXE7uvhjPsPlipHjKeu8ULP8Dvqz5P/NzKvcJ8ANcUJ+9UM02m 9YnrbU2Ou5l7FPeo7taNqX/F/Jb/nfpXOrjqKT7Qmx5T/Zz5heJF1cs6fkC1V3G9ik0ggUWjtRMV WTilpUzpakkKJzFJBg+ak6JIiZ50cE9FB3XI1AHndsjBYRIaMFzSzLAsZLVAkpfmS58VB1YPTT7w H7g49rOPb4t9PoSFu3p67ryzp+cuJvVGrBiKvfLJf8RevD5+8HsHDw4/cPAgWe++WBd3N6zXBDnK fWLuwsQLExlzMVumL0ssTqpml+uXJ1Yn/T1JTfLcqdzlM+Xfk1Tg2rNzWptWazIapnLahPkGg9Fn MtFkRfv1rHblmXIwpOn0N/JaundJPCR57axchbz/sJJLAZITW5KuzKx6H1YU/eiKcczEzo833lIP Jrbd3NF67a62TXvAtA3tsT/EJmOfxX5Tu27yQ3Z89PEHRx97+AA45G6E2FK69oNi5t08VhvwGr6D H+DZPHOjodMQNnMatVHn1jG36OI6pkJXr2N0Y8ygOF+pBP9mGYUmE6lN6nx1WM2pXTvMB8zMRvMO 82HzCTNnNiEfZun6GWYnHoZLgDOhYhwno6nUftqdP2t2rjyNHFLOBt5dViipYguqi9rX1EVL6Jug woVN9B2wpAm7kjp5Ah4mHl21ubql6ZJlFyxencf57t5cXfJpbuWh2H/AGvPBn02wxiymR/yeIkHh VWXYE+zee8z3WO7OuDNLrbTUWhjzc/pxwyue97xf6D9LVczXr9MH9Xdq7zY/ljquU1Z6xbRq36bU dt9u827LrtTr0tSlvhpFrXaFvt5Y61maqkxNy/CV6ko8Jakl3pI0pULDJ6g9Dn2GLjU11atMSxWz +3VXWrZZt84fyNpjvT7rPuudWU+lPuXV78S32G903Jv1w6xotiJ1LP5zclJ75Brap0bnpZH2qVF3 mtR2umhbTAJgsx4vSK1NvUd/R+pPU99OVXhSdXqOcyE5F0BFJCsYtedUYDltou3U9GJSiykuyAVx PhZxA+Za8E58FrMIm6DVAik8wUy0ASbGYhhxeCN3lmO42kytTYSpbUV2Eea1izCpXSwpLbaT27pd TJ8PD5jXaHfTizFnX+cSId4ZXbjBFXcxrtpEpd1jEz3eYpuY7C522/AfbdhWpPI0pN+SzqSLjpTi dBe5lYt2COYN2Tg/G+dl4+x5nnwTNhXBDYdmwuoK6a2ZpkIK5Wo9hHL/lWPEs85DukGv4HKgpC8j AfCTl1+QWZ5rnkpJSJO8DeuTmiRBkTNPv3QV3wI/zdIb97T4z0S11lxhzIQHWODjZ/RlOouujIAj ujKwzUdHtGU01cSQbULsSky30QSmpBgu8OAgcH2Hi5T0Zo1c3SFvI7/8Jjf7fOwy97R1l6ZbrMtj T1y6/d333n07M/Z5wsbG3nwh2Yd/0tR47pPfTOI8/+p1mcl5gtWSULdk/b1Dx27eV7BkqdvmnWdN 7lhRt+u2X0bB493xD5hb+Qchfr8uzhcQpJqa+cZFhhWGJqPSaUUO1mZFdnOiBdvNjAU7WLVSo9Q5 iKGNyD5sj9rZFqgm7Kx9DHMjcNkjlwNkJb93gruYTqvO0+QhyGo3wo4GDDHTwfrs5nXWCssBy2EL 22LZadlvOWE5a+GRxWQRLPkWDq6hVw5PvR+pi5bCnl5MX4Rb4hMLm8pXkt9NnWsuN51zkjBwhv6+ ClBPQ6qYUGSEHxIPsNWbYKE6tROl+UClCd6SopL0BOaqCW1GcsYKR+t3LrqqTKv+7nexi/Odiq29 1p+c9G5W0cU1BXfiN0699YPYXtDPTRAR1nA+OMsfEO2XJGxKuItn1QqnopwpT6hj6hLeZ5Q0i0vg tDaksVosGrUi0eKzWhEJZgYbPdFtOA6O+09OdLVq+ihX4bMqrPrHyZx0HHztJG+Wrqc+WKRHWvaC BQRkVy06Htp86CLsdK+uuLAvCzsPrGu9/NBdzHDMcSq4uH7gNJ6A9AjWqYWcZQOsU4v+XbTyma68 YiV5KMhDRR7sWPzkKNQ0MRNci4rv47CC1apUGp0Wsk/GzLrULk0qytG+otXBRjsrZsK9UoN4rQU5 tekoS1uMFml3I7UWaTitRq1mGKwAWF1G3l6IjuTMYq3erc/Xi3pOb7e7TJoKTT19XZsvajmmTMtV cPUcyx1l8iFB2ikadSUICxCQWOzU/RT8xUkcxu9YeaYZTopmJ/2NC23TRM0EH3MZhtsE2a3+ZnKh k357gj2JdvKqLNGD8bOxtTjj1UV2hcH0GvbEQCGTf3q6xpaTw8yjWSTkAG9+3PmXm9/ZaCz/VOVU 0W/8PPzncvpNzqcvGHnjyy/PT5pqVK2Aq57+hiw8lUtiq1CVCX35ZexiU83XvgyLUJICupgyRMrt XD96GEoR/wpCUO6CElCUoSZ+PboT+pdzf0a7oV4H9VqoK2n9Z3QboaX0f0a3QlkNZR+bQnHzmUPI De2bANbKPLvkcggEzAbOz4AHCMBxD0KKCZD4VYRU9yCkuR6uJTsR0h1DSP8EQsYxhBKuRMgMJdEF ZRdCljBC1haEbJchZBcRchXCklYjlLyIfFeZrjYJ/Q2VozbEQ25jQnmoErisNHVBkk1+/7eRuwqR 31rTL1DRJ0v1psFLZJhBKv4PMsyiRn5Chjlk4X8pwzxy8B/IsAI5FA4ZVqKfKvJlWIV8yp0yrEZD +oMyrOFeoJwJrEWthkIZ1qEOwx0yrFc8pTgnwwZ0meHLaTvuMK6ftjVv/FSGGcSZp2zNomzzAhnm kMZcIcM80plXyLAC4FYZVqJWc48Mq1Biok2G1ajGliXDGiZg/JUMa1GBrXf6G9lFtmEZ1rMbzCdk 2IBybW+BJJgjWjfY9TLMIZcdU5hYR2PPkGEO2exJFFZAv8J+gQxzyGwvoLCS2MVeL8NgC3sVhVXQ r7O3yTCHHPZLKKyW7SvBkn0lWLKvBEv2lWDJvhIs2VeCJftKsGRfCZbsK8GSfSVYsq8ES/aVYMm+ EizZV4Il+xJYQ3V1tQwTXfVSWAv9ZvudMsyhefa9FNZRnYzKMNHJYxQ2EM+3vynDHEq2v0RhE51n VIbJPBJ+ItX5GRkmOv8/FLZQeeIyTOT5Twpbod/icMowhwSHZF8bwXeUyTDgO3Io7KT4a2SY4C+j cBLxAUe/DIMPODZROIXKUy/DRB7J1m6Kv1eGCf41FE4jPuA4IMPgA47bKZxF9ON4VoZBP47HKZxD 5/m5DJN5niewapb+VbP0r5q1LtWsdelm4etm4etm2UU3ZZe1aBsKoyDqQAGITUEkoB9CWYs6KbwS 9aIeKBEZS0BV0OoDmDwD0B+iGAL0dAF9LkDVtD/wP5wpb1oyAa2BkS40MI3TD33LoZb4FaAy+OSj HBkqpL2VQNEF9Wqg2QQyRCjVapivH0of2grPdipDD4wFUfe0JH3AVwCsgMxJwg+BhgSgIPRkxh6U TbmQkQDl1CbPRb67L1F20xnJCjpB+m46YwhGIhS7k/IiWo/IHPrpCtsobYSO99BZSE1k6qUyhOS1 hOncRKI2KlU/5UZGCH47rSX5Byg3gXKYLVWIzh+B8R7aHqRzd8rcgzJuL51L4j3V30XnjsgaaYOW pJmv40VgziDVSghqae42uWeAaprYasZLeqld+qhGuyg9kZR4R7dMNcWhjdJvlbmG5JWSMUmbM1ro AEwym9Q7o9eQrN1eeSUhij9AWzNW7ace20Wl+3afmNo5/dNrIWPddL6ZOfqAz2ZZ2oCs/zbq04Ls 91M6a6e8N9FeiX4QRkKyDQlOF9he8pFeeG6Csa2ytqUZZvZygNpK8g6B6rBNXn+IWq2L4oTpPpO8 sYdSSiuZ7d2hac8SYPxK2TLdVBrim5Ld+uWd3DUtRzdtzXhv5Gvxpv9r62uTebTSGQaoptvn+GYQ bYH+Kc0S326bXmEH9W2B+sCVVLf91O8i1Bqbpq1OZJf2O9lL2dO7qV/2spl4JI12U4sE0FWUXpKa zNtGR2c8TeLeTrUVprtk2/QqpngT+kE6HqCa6JN5kD0kaTFC6acknpo9TH2om8bQKdlyvxFXF82x 2lIaOduhd73MaSrKkii5EJ4CyoQ5iPb76E6QdtD8WbPkTM+yEnx7pv9H1Nf75L3fTf1n87Sd/7tx X7LNJjkaBuUYNxOrpFnXwZkgoAZKLyAf5bcSnvXAu4N675TWiH/2U413yrPlolWAtxZOkFooVbAi AtdDL6GvhedFtL8GetbAk+yDZXBy1MBnJe1di/RIQ8ta6rn93+LXwnS/JLFkvbBs35n98E39SOde L+igj3pIJ8WeWs9U9J/yqVY6ug3wB6Z5tk3HUUl3A5R2Jv4F5R1CotRMzJZiRUiOz/1y/NhEZwlO x1+i2yaZG4kkW+W43Tp98kk8I/9EM1NeNjgdCYPy7g5O758+GqsicuzokH3/2/Q1teOJxoKzZpmJ GN/k1y77F/HlVhqFJalbZcv0yDN/m4Uy6KrmakqK/t/0im9ynoqjJGIGaFYTAK5dsrb75Xj1j3jn Ut/vmRXTt33DFkE5o5m9c6STIkAlClPNkrMrRPfbv7a5IPtiz6w4OsWX7P52qunQrBOrb1bWlT2N 3TfLb2fyhH+uKSJdN51/yq9658w3SO2/mVpzdjSZisUzmL2AK8WZAapxMn/n9HokuWZ7d7ccvSX9 S7sqLPvHTJSf60P/bEUz/rGcrv2blpvK88j5FpSzQWk1Um7ZRq3a8zUb9H1N3zMzk/X10uynXY6r W2keNohmZ3L/2vpT80l7MijnG3NP5an5vmlHSVsz2XEbnfOb+3jKYoGv6brjvyTtjJa/yWFubjFX oqCcMUfgrJyagZwyldCbg8gpuRAVo1I4GQV4FkArB+4cxVDyEblnr0N1MmY+jBbASLEMl6IiKIRq ASqB+wkpZPZOmpeEgV8efAbpJ5ee73N3fBuNfP/onCBQNd2dg9N+IZ2CITnaEplW0wgtnaGr5Fyr V87iyf6UTtI+OhKiFlgDz5lzg3gVuV2RjOG/Jncexe8GXnnwjNAIQWyVR8+ejdRLpHwidxrzf5fD IM0BJNzg/wqXqbG8r/nj9Nxrt4WDHYG2oPBDYW1nUFjZ29MbgS6hqrcv3NsXiIR6e4RwV1uuUB2I BP4FUh6ZTFjT2zVAevqF5T1AV1BWlp8Dj8JcobKrS1gd2tQZ6RdWB/uDfVuD7VW9PZFgN5mkb5vQ HwAi6A91CO3B/tCmnmyhsi8U6BLaACsQgsHu3r6g0DnQHegJ9UeEts5AX6AtAgT9kVBbvxDpDPQI MLZN6O0QQsAl3BdsD7YF+/t7+/qFQE+7EID5B9o6hZA8VahHiAz0BIXBUKQTyIPQ29tOqAncFQAe QB8AYab6IoPBnkgoCNhtAAz0bcsVqEp6twb7ArC8SF8wEOmGIULQNgBL7CfM+ns7QEwqQsdAVxeA VFZg390LTEI97QP9EbrU/si2ruBsTRDj9BMuwb7uUA/F6OvdDNMGQP62AWDUQyVrDwU29ZLxwc4Q rLAz2BUGjfQKm0JbgxSBWjkgdIE6hO4g6K4n1AbogXA4CGrsaQsCE0ndIaIsIXglLKY72LVNgLX1 g5G7yBzdoS6q3ojsN/0yvzagaA0KA/3BdkmbwS0DRNiBNqJ/oaMXlgwzwqIikVDPJrL0viDYPdKf TczUDyqjfgTN7sCmwFWhHpg6GGnLlpQG5O2h/nBXYBthQah7goP94UAYRAOUdhAxEuonExP0cF9v dy+dLXfKVxdJS1va29W+aD0QEZctzF1YKGSuDLX19RIDzacoOQRl5VoKHxTW9oH1uwN9m8ma/5nv w2o2gRsGweOoVwHqujVCQyAi+IS1K4X6jo5cKlqwqz842Alouavq1y6vXV5VuXZ5/Sqhvla4aHlV zao1NULlstU1NStrVq3Va/SatZ1gjCldE8OQiWF5sO4ItcO0PLD3ejf1BcKd2ygf4v5EU63bhG29 A4SyjfgoSDfQ0079D7wCXIp6NnhFCPwZ0AOb+oJB4r+5QhOQdQbAeXpbyeYDysgcYYjKBokTBsHc QWKfvmBbBLyjA7Q/IxcxfO+mIEWhjjFNBwYFn28diMDUIGYv7MNZC8ronxIK3H9aFdPExEeFrYGu gUAr+GWgH/xqNnWusK6Hevq2qVXAmmTjwKYICP3hYFuoI9T2zZULoMUe6qOENtDeHiI2Bt/po6Er m3T3Ud3SmPA1obpC3SGyIGBC8QZ7+zb3S65NvZh29g6Czwy0doX6OwkfmEtSdze4N8gPpgpvEySX lzU0lxHVx/KOmcWRmLdlINhP2UC0bAv29cgr6JPlpsj9nb0DXe3gq1tDwUEpyH1j+QQPLBmEuNE+ Exin1whi0XDcFpmxMVlYQJa649unpSJPE8jRQp4I+AQiiwjCujWVQo6QubC4dL5QWrAwJ784P1+t XlcHnfkFBcXF8CwtKhVKF5SUlZTpNZ2RSHhRXt7g4GBu95Th23q7Z++JoFDdFxgkuoAtCELBTKt7 W2GHroKo1QshPpts0r5QWyggrAnQvdEPZ9bCwn8wd15npLsrrztC/gZPXnf/xgCJE7mk8/+RYDDY Bb3Bf01CWnmyHin2nNclq+irhz56BQvMGYmgAayHY/7DOb0dNG2c3VMrv26a1cfuYY+zP2Wfh+eR b+UW+ga3iwCSrgW9dHRgzugymu5NXRXJhWiuBB9CvRl9BtQfQv/ssfWUYnbPhbTeSlcyd6RBfgUx QBPHXno1+UfSz5GAc3NLuMVcFbeAW8iJ3AVcHVc2h3Ltt+qyjtS4APrn9kqv6jbP5YET0J9YL6Ra c7XWK788lX+PiuIZ5O83ffPnOHsfMmLy1Y8J9p5Rk6VQHGPvHTUmFoqVJvZO1ACFQVF2JZqAwqBe 9la0AwoD6HUjOQWF4wQY1RgKTYC/D0y8D+2EwqJheGLaFqEQ/H2jiTYy/XUjxgRKd/VIfrEEjJoc hQ2VFvZKhNkg24O8yM1uh3oe1G1Qp0DdyrbDZYHIKY4aTYU7gV8FoFewVriJuNlK1gYZuZutZl0o iaINjBgkPgMjmVmFlRq2inVQFCOrhyuJm1WxypFCt/AcK4KkIrtnVK0l8u0ZMVkLj7M3sEpkAayd gGV3G4+zGpQHhaxk7ahaX7i/UseuhWWuBbW4WfLr2QP0KbI9IzAR8Kthk5ENxjazKcgKdS07b8Tq nniOvZ2i3UZmAX5LRlRFpBrVGwonKtXsEhiNsjeDxm+m3PaP+hYWokofm4nyoTCg1B0A7SC/QmSH ABoCMw2BaYbANEMgxRBSgN33wshewMljr0JhdhDth3IAYA6mtI6ABscpkJZZOM46WQdowvQc6A5D r2tUbSCSOUbMiRTNMaozFFYcZ/tRPRQGhI+M2h2Fvc+xWXQp2aOOJEIQHlHrQHV2yRZAaCM2OM4m s/OoJlKoBqKVbmhjZGTdCDOvMSeIdpi3mF8R+5I/JkTrn8v163L9b1Idn2BOjAIXcYz5JalPVSYz 75EvojO/RwcAYpjnmBfhtulm3mXGiBTMb5hxVAH1SWi3Qz0OdRHUR0c8r7rHmLFRqED2+0f0NrJY 5sURf54MuNNlwJ4kA2ZbYWU68wLzE5QMU/wa6jSof8JMoFSon4faAfUEE0GvQv00U4IWQ/2UXP+U OUZ8mnmWeQYukG5mdMRARIiOKEl1eERBqh+NIKnVkOc+xvyIeRy5APXJEZ8Leg+O+tLcxudgPsw8 wkRGUtzmSg3zEG7E5wBpGJ0kNTIzD4+Ukkn2jxwT3OPMfma/6CgV08Uc8VE2Pz0/J/9RVkiHs6pU eFSoNDE3Ix6UBxuW2QdPuKIz4D1QRCj7mb0jXGm0chLWRNbFoJ3wHKZQCzzDFELwNE2PnqVQBXMD qofCwBzboeyAshPKdxEHz6ugXA3lO1CuoT0RKANQBiF8hIEiDBRhoAhTijBQhIEiDBRhShGm3Aeg EIoWoGgBihagaKEULUDRAhQtQNFCKYi8LUDRQikagKIBKBqAooFSNABFA1A0AEUDpWgAigagaKAU IlCIQCEChUgpRKAQgUIECpFSiEAhAoVIKfKBIh8o8oEin1LkA0U+UOQDRT6lyAeKfKDIpxQCUAhA IQCFQCkEoBCAQgAKgVIIQCEAhUApTEBhAgoTUJgohQkoTEBhAgoTpTBR+wxAIRSngOIUUJwCilOU 4hRQnAKKU0BxilKcAopTQHGKGTzCnqh8CUhOAMkJIDlBSU4AyQkgOQEkJyjJCSA5ASQn5KVHqDIY cJvtUHZA2QmF0E4A7QTQTgDtBKWdoO41AIXQRoEiChRRoIhSiihQRIEiChRRShEFiihQRCnFMFAM A8UwUAxTimGgGAaKYaAYphTD1HEHoBCK/7pT/pdNw3wXN6rgcGV24vm03oE+pvV2dJLW16AjtP4O epTWV6NraX0VKqX1IPLRGuajdQS5VXjEXWqstEEIqIeyEUovlANQDkN5HoqSQm9A+SOUOFMipnJG Zb3ygPKw8nklf1h5SskYFfWKA4rDiucV/GHFKQUjVCYxehpHIbSgW+hzBzw/gQKHCDwrKFTBFAPf YoizJfApZorFhDPCJ1n4jSz8fBY+nIVvycKVamYZ5mikE1ApA4LjRlHnW+I+CaXUl7EEItPNz3xs d4/4FrjH8DGpmi/6of4YyhEoj0K5FkoplEIoOVDSobhpXxbgN4qp8pTHoGRA8UARCAtks0FuY05Q ieOMHj86+pIekT/kMJKRCXTPjWTkQzU2klEP1bMjGa3uSjV+BmWQNAg/DZZ7HOrDI+7TMPykVD0x 4n4OqoMj7mKomkcycqG6dCTjdXelHq9Dbo6QrpXrNbBuUq8eca8HtItH3POh8o9k+Ah2FjBKh9H5 uBGdhjpdpkqTOHlH3IuhSh1xlxFsFcoghscKlEPF46GQmh0FgT4Zx40cFrXuM+7b3R8D+V9BseAe vxHGOKjeSCd/P0TjPpbzPUCudI9Uagg+nA9H5DpK6qfdj6bvdd8Pc+H0Z9z3unPdN+eMqaD7JpB7 L2Ux4r5WGGMeFxPdO9357kjOaXe/e4U74F7tbk6H/hH3Ze5jREzUhBuZx59xN8CEy2EV6SPuZelj VMRa9za36M5wlwnHiH7RQmne0pxjRAOoUOKeDfrNSh8jPr6udAwniFnKs8r9ykuVS5WLlV5lqnKe MkVpUZlVJpVBpVNpVCqVQsWpGBVSWciX2/3kS3cWhYlUCo48OQqbGPJk6HfyEINVDFqBoolsHVO3 Zimui060obpWIfrZGu8Y1ly8Icp7l+KouQ7VrV0aXeivG1PGV0dL/XVRZcOljUcwvrkJeqPMnjGM 1jaO4TjpuiGJ/B2sIxjdcFPSOMLYecNNTU3IYdta4agwL0koq63+lkeL/PTP/DhmgynRu+rWNEYP pTRFCwkQT2mqi36X/JWsccbI6GuqxxkDqZoax7kwY6xZTfq5cHUToJ2maODNBkBDGaQCNNVSJBA0 iCdLCRrYSMLzATngeUgFeBo98lE8n0ZP8ThM8I6cFGqqjwgCxUlH6CTFOZmOZuGAxwBt9RGfj2J5 BdxIsHCjV6CCzacTud2AkuOmKHAHctOJ3Jgyi+bNoKTLKCXTKCWUF4tncNwSjiVzCseSCTj+/+FP cKkfjxYMbH+R/OGxFm9NEEpLdN/WTkd0Z6sgHNk+IP9FMl9La1snqQPB6IA3WB3d7q0WjhS8+C3D L5LhAm/1EfRizdrGIy+KweqRArGgxhuobhqtKG+snMNr7zSvxvJvmaycTNZIeFVUfstwJRmuILwq Ca9KwqtCrKC8akLE7xsaj6jQ0qaqy6R6lNFqwIdbkjxNS22m8BLi0OOLPY7tSUc5hA8irb8pqvMu jeqhkKGcypxKMgT7jAwZyF+Xk4cc2xd7ko7ig/KQCboTvEvRlGoRQSL/O6cu6lmzoZG4SlQMfLvN +skPHXagmlA1/IN2hBb4zMZE/d/6E/m2n4GBgX7yGPD3I1QXzVpTF11A/q+QUgmsWqqboC93qo9l ad8RtbpmLD4Bg34QAkcIOwL5Mfn/xqIGbl1KZlgxrGTIVSEy6kop7D0OJ/gOKHCPYwZH8uh9mRkc TU0n95fIaF6JVMP9lNQjLk8h+d8ppUBK6nSpFhNyANifvj9nf+lw+nDOcKmC/KftR6HT/Sg5Skfy HmVRxN8/pQgAI01I+m/QwO+hkeQUyniYAH5/k7+fft0dfV3Vfvlr8KD0acX2y7P20+kjUwaR+vuR hCwN+gemiAZkEjo4QEkA/L97vQNxCmVuZHN0cmVhbQplbmRvYmoKCjI0IDAgb2JqCjE0MzYzCmVu ZG9iagoKMTAgMCBvYmoKPDwvVHlwZSAvRm9udAovU3VidHlwZSAvVHJ1ZVR5cGUKL0Jhc2VGb250 IC9QWEFBQUIrVmVyZGFuYSxCb2xkCi9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwovRmlyc3RD aGFyIDMyCi9MYXN0Q2hhciAyNTUKL1dpZHRocyBbMzQxIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDBdCi9Gb250RGVzY3JpcHRvciAyNSAwIFI+PgplbmRvYmoK CjI1IDAgb2JqCjw8L1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvVmVyZGFuYSxCb2xk Ci9Bc2NlbnQgMTAwNQovRGVzY2VudCAtMjA5Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAwCi9DYXBI ZWlnaHQgMAovRmxhZ3MgMzIKL0ZvbnRCQm94IFstNzMgLTIwNyAxNzA3IDEwMDBdCi9Gb250Rmls ZTIgMjYgMCBSPj4KZW5kb2JqCgoyNiAwIG9iago8PC9MZW5ndGggMjcgMCBSCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlCi9MZW5ndGgxIDU2ODg+PgpzdHJlYW0KeJzVWH10k9UZf+77vvlomzZJ05aWUN43 vK2WpqV8aNfWD0LTpGJFa6kuQY5LaFLS2pKcJkVwHy0TEVKcs7qNyebBPzhDPJtvwM3qQNiOf2xT pkzdzrbjmU78wKHHKUwc55A99+amXyly+HNv+tz7ez7vc5/7JLkpEAAwwSiI6d09g8EYEMGGklcA SHHP5oRyp6O3GPHbSJ/1xjYO6pe+9wiA+AaArmHjwNbeJ166uBQgT0KfGyPhYOiVBdsuIt+GfGME BaWK4Uvkv4V8VWQwsSX/CF0wbx8OxoFoTxBkfEHeAeT1g8EtMZEIPchryCubgoPhxt1/DCD/GtIN sWg8kd4CrwPYLFQfGwrHVlnizchjDqIeZQRoeLojIHq47EMub/J//uhLIB/P6iStcmac/kg9oNI5 /Q4b38rii6H0ucvHTs/xzNbhMUOGriQaOSksniv6lTzkYbKDjJJuci8ZJMOkj7hID/HjeD9yUfgF W3Q/nCYKqSBFhBCVWIkBLpBqUklsRIJ85M+gzVlm+VM2niUt8LnwDtvZGPLH4A04BR/DRVIEL+Jr I74OwpPgAx9ZSK4mzeQm+ASjL0DbxyEFz6PN79Dn7/A+fEqMZB3ZTJLkMaFQaBfWoV05cZNdwhrh glQFBnKvUEw2ii+Qs0RPSkkVvIDvy7+JWvpDsg/eFuuFw7AFboHXyTXEJe4Xa0VZOCnsB3A1N32t 8dprVixftrRhSX2ds3ZxzdVXVVepixyKvLBygX1+Rfm8stISW7HVYi4qNBXk5xkNep0kCgTqiFbu 9qUqDE67w+Hw13N+/kxeE6stnzk0KJ5hZJ/ltGAWXzmLXzjJ36pBieZV3W00cAq872tg00iJBnQV YluDK3EnT6hf9fRpFe5QIIAebapF0byfNvBUWOxUQb5bdYfz6+sglV+AsAAR2sZSxHsjYUDwelpS AhgL6+u0YqcmVHso9WuusQACtQ0jocY2pZlIH989XQXolkW2DCKa3q0Z2LpKn+YKajCmpOqOJ3dP WGBDwGkKqaHgeqxcEHNMgVjtiXTTOnooBSKKJmFwNthRongiSlKl5fBEAjiqbeg1pxzFeW7fg47j dq0YZ49mdWrtaNF+3ym7mPSU9ymUTSYfVLR9t/umax109Pv95Zhw0qNiQAzm6W/FrZQ31Ndl9sQL EAr00zX7gzRPT7+SHAuzXHezHJipJ4IHE7ycVTLpCameUDDUmonu1lzdbILudT62QSxdm5+LuAFq JKYJtPkdmWJ3dPncNDE12GbPHPukJMAlKPBklQrNYDUG0JQeRYMun4qmTXQIN0Gyp4k1j8NP0Ktz ykvTVVtUJXkONBJQPz4zUxLkEn215RxQ6FW9gWTSqyreZCAZnEiPblAVi5pMdXQkY54ArtrpQ6+J 9Atjds27269ZAhHSgrWnHeDt8q20O6z+LNuZZQFbChurgG0Hq4B/q/mEVYZun0PBQt3h89uxTj6K uxFnZtpI2LhNeMa8bLRG4abJ8rg5dDhod45NuGADMtro7b4Mr8AG+yFwNTjxPAJUczyrKb2Dakaz mkn3gIqrPMu+Vks141WTf2ZLmc0TadFI2Veowxm9ZnP7RLvgzyDBLlKU78R3+vXaPCfiGmcSD+E1 VbM4NZ3vuP16v2Kx4icAPb21asft63yKJznZBRkJ3yntA2x1NRhJ8rcSNj2AQDMyAF4YRJxKntML ElBqOPHWCTYsW+qwOqzVOBC0+u+oDi7QGRDQh2TovPCPX33DfP05sGe+734+sPY8nQ8N/lNL91/8 euEBI72f5IHAv/LQx1hwsQugqCndf2Gg8EDOhUQwokg4wjC7KTELAe7GPCOgQySAC/AGJDxL1mH2 VOvCm1A2jhuylxyCHm6OBZDgZo5FqINbOZbw3nQfxzrEOzjWIx7n2AAN8ARdSRIxThGc4FiChfit RjHNKh++5FiC+URkWI9yPankWIIyojJsQLmRNHMsQTlZxbAR5Sbi51iCBSTMcB5msYNs45hAkWDg GOMIpRyL4BMqOcaYwjDHOsQPcaxHvJ9jA9wtHGU4n+5LtHOM+xIXM1yA8mKxnWMJFomZ3Ex0XfGb HONa4v0MF6HcIu7lWAJFfJphC4vzMsc0zlsM22h9xDTHWB+sHsUlNB/JzjHmI2XyKUV5idTOsQRV 0l0MlzH7EY6pfWa/Fcz+aY6p/TGG7fS8pHc5xvOSPma4kuajM3CM+egKGZapvU7lGO119QxX0fPS tXOM56Vby3A9s49yTO23UmxkddY9yjHmqXuSYZa/7hjHVM56zJSx/xfHVM56zMTqr5/HMdZfL3dv jYV7gz1hJbgppISCiaDylLKsublRWdPXMxSNR3sTijs6FIsOBRN90U1LlFUDA0pX38ZIIq50hePh oc3h0J3hoVBwU7A1OhCadGrhQoVKKRNHb2WZUjNpsXi6RdZg+ZIV13J5PZczm764ElQSQ8FQeDA4 dI8S7Z07PXx7hvFaOYRjAoJwJ85DEEK0CUmZpU3AMClEzekcuylNL2pCOfqM1MviJHK0XC7uFI+K L4nHcEzNtpmh64atEEN9L2p6cFaYVQjnEMuSxnwKaRl+eDVDI6I10IeWQxCFOFIv2ij4gRVFSYyN 1KsP0SZYgppVMIAvBbpQthE/ChPoRbkwzjSrzXPssRW9B5DLXaklZ79Z26wmztemGStQM0eMxZeM MTvCctzBCrh2ln39LPupOH1sb5kzpHUIoX4Q5yG4B2V09SupXrZf+r6ymzLaW3CO4LwZPalkOMc+ 16KdrRbPsczKvdiBA5j5f9DnNMpyO22mPusX550ZvWTkmRa5PZyR3oR4AGP3zmkzU9uJsWg1hmED r97WHI+5bKZXMTffGVpJlm6UrpPcUqPUJLmkG6QOqXm2x5w23Zd8p09pvHPuMSPtoDsly1A2Wz+l 6WCfKzE8jdxdTNfdghTC/eT205TmSvruCup3RXEv15vsPpT5b8Qw/T9T7vPchx9UyR+8b5XxZu0K /dlkaXT9lfxl3CqfQHoF6WWkPyD9Huk3SE/trZJ/gvT4XkX+8d4aee+4Xf73nlL5Z3sq5B/tqZV/ uKda/gFi1x6yB83Nn5HHxivkR8ed8iPjDhnGCV1o/XiBpdF8RD7ScERs+DWB5y3PC+YJAr8kyvmR 84LlC+UL1xfiyDliOaucFZRPOj8RGs6sPHPbGXHpm7E3hcOHauRDh61yw+GVhwNaTIu9oXvvVJX8 LlLDKbrA4d/iRuhC6WcR/GlkiXwS6bURRX51xCofRzqG9PCL6RcF81GSPkpSz1jl2DPEckA5IIzt WiondzXIu0ZWyDu3l8sPIu3Yvlp+YLtVvn97i7wdw0QP7juoHfz0oOR6kljWK+td68XPMeJ3R8rl bSM3y6M4fwdX/DZS50hgJDYiWswOuay0VjboHXJFea0siQ7ZVlwr19Wba51FNYvNV11dVFVtXqQW KQ7zQrnIvqCysLxifmFp2bzCYltJodliNZkKi0x5+QUmvcFoEiWdCYhgsphHzYJLP6oXXOKoKJhh JdwGIyCZ8V67ElyVUWSOwauQBqP9OqNsbjHKYrNRhiaj3LmCaMUd0NHdqtkIzmtbtRXOjgkjdGnL nR1aXuddvhQh3/OjVBN24vF0a9LOCQGnYve6u3wTpIKqH2C/1BFNkNEHHnrIPon8fmelFupY69Ni lX5tOQXfr/SDE594Ih6POy/xpPLo6qGu1tRpif6OD2qn1bbUR6fZb3rtI7WNcNfpMRBi0Eku8zft AecwkydylqNOAP8DWSPXhwplbmRzdHJlYW0KZW5kb2JqCgoyNyAwIG9iagoyODMzCmVuZG9iagoK MTEgMCBvYmoKPDwvVHlwZSAvRm9udAovU3VidHlwZSAvVHJ1ZVR5cGUKL0Jhc2VGb250IC9QWEFB QUMrVmVyZGFuYQovRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcKL0ZpcnN0Q2hhciAzMgovTGFz dENoYXIgMjU1Ci9XaWR0aHMgWzM1MSAwIDQ1OCAwIDAgMCAwIDAgNDU0IDQ1NCAwIDAgMzYzIDQ1 NCAzNjMgMCA2MzUgNjM1IDYzNSA2MzUgNjM1IDYzNSAwIDAgNjM1IDYzNSA0NTQgMCAwIDAgMCAw IDAgNjgzIDY4NSA2OTggNzcwIDYzMiA1NzQgMCA3NTEgNDIwIDAgNjkyIDU1NiA4NDIgNzQ4IDc4 NyA2MDMgNzg3IDY5NSA2ODMgNjE2IDczMSAwIDk4OCAwIDAgMCA0NTQgMCA0NTQgMCAwIDAgNjAw IDYyMyA1MjAgNjIzIDU5NSAzNTEgNjIzIDYzMiAyNzQgMCA1OTEgMjc0IDk3MiA2MzIgNjA2IDYy MyA2MjMgNDI2IDUyMCAzOTQgNjMyIDU5MSA4MTggNTkxIDU5MSA1MjUgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgNTQ1IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwXQovRm9udERlc2NyaXB0b3IgMjggMCBSPj4KZW5kb2Jq CgoyOCAwIG9iago8PC9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL1ZlcmRhbmEKL0Fz Y2VudCAxMDA1Ci9EZXNjZW50IC0yMDkKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDAKL0NhcEhlaWdo dCAwCi9GbGFncyAzMgovRm9udEJCb3ggWy00OSAtMjA2IDE0NDYgMTAwMF0KL0ZvbnRGaWxlMiAy OSAwIFI+PgplbmRvYmoKCjI5IDAgb2JqCjw8L0xlbmd0aCAzMCAwIFIKL0ZpbHRlciAvRmxhdGVE ZWNvZGUKL0xlbmd0aDEgMTQ3NDg+PgpzdHJlYW0KeJydewl8FOXZ+HvN7MzeZ44Nye5mcx9syO4m hCTskoMcCyQEEkhgSQIJhHAkJAFDoIaqHKICiiLirdR6tBJBETQWChZRq5Va23pr61G/itrWqgV2 839mdsNh7a/f95/sO/PMO+/xXO9zvDNBGCGkRpsQHbtxyar23uNffLofan6NEDYuWTdgn/FT/58B /gDK3qW9y1Z9UWiZgxAdhPvJy1auX3rqmW/NCLERhLLaujrbO16o7stByKWHMQq6oMJUzN8K99Vw n9K1amBw8ntp0+B+JfRnK3uWtM+cMG8xQnm98Py6Ve2DvdxEMhXuv4Z7++r2VZ2PFN/Wh9AkmIPb 2tvTPzBWh2Dugruk5719nb1G/3EX3I8iRABHhJFEj0QRwjz6rwdGRL5SBuPzCiSISpVag5BWp480 MBhNZksMio1D8daECYlJNrsj2YlS4EkqSoNzekZmVnZO7kQXypuU7/Z4CwonF00pLimd6vvvk48f /v990//7wSfxZu4r7gzbyIL0XQRkjX069mF4MNwRbqa3ItvYGNqDHkVH0Sn06lj0QKPohHxdhw6i 4+jlscsO9GN0K3oI9OMt9OXFur3oHvQYGrmi3S65dj96BD2ODqFn0Emo24ZuhtqfoJ9d1q4HbUU7 0Z3oPvQ6TozWnSRmHMHgM6QmZ3A/3oGsKAdVoIWoH12NtgBep/EMqCuFunqo7QOtuAVqj6LTY/92 QKsmFETdaDV6Alr8Uq7Lgtq5qANqoS7abg0aQtej+9FP0bOA1xBgdjPa9wPj/Zg4iAMNoI9htJfw beQU+hn02cybkRL06AyywYoISmfg9ocIhTvG/gk6tph8TR4gN6MDpBvN8KsLC9JSbSajRs0xkmMf oamVzkpne9d2e2WXfbuzoq0iNyfQML+yIsHhaM7NsUN1hX0Et9krR6av64rbXik1GDFmj5DUSql0 j/hvaAPAWeFwOOCJ6dKTI2PHb7zs0RMI5uqaO1+aUiptXfYRBg/lUwLURDGQnnW1wdlZAQj8YP0V KE53Tm/bvn260z59e9v29iNjmxY77Xrn9icCge29lW32EVQ/fwRD/TM3JIxMv7F5RN/WhacAZRIS 0xvm+xIcBhglMMcZmN0y3165vS06brRmsnyHiLTAFQgWN4WL+WmeMCQV1yvvviKfJuU5DA5DKpww tDq3iUPnpSsCAIwEepieoQwkJfVO81sIz1MF1ol+kdAcWIoYsRyF66w76DobRL4St6tkUh6mTvmP suzrsh+GwptDz5FyqUgm5KlwB9XBiBZU7S8UsaiIx/GKDJrB1eFqWs3VKVpxq6IH9yiG8SAZ5IcV RgXG6iGGhTzJWulsbFuM/uuzblewBKb0wXxB7EwjBr2x0G3RYgVPLGZjbBKOpbqPn3j++Sc+nr3b VxKomVqyb2a442X8Ac6Fvw9eVtYcG94Q/uP+x8IfbdrwQqWE2e5wBzkrYzbLX8pT3mShFlMaTqNp pjRLFfZTv6nKUk/rTW20zbQerSO9tNe0zmwxYqZeCw7AxzBjKhu6JVb/zZX46YnC6Z2KCwuMXg9J n4jTve4YIzkLyM28s3hqTW2pb/dsQJaUhF8P219WVr6wYROe8Nh+nLFh+FiN8uWwXcZuB/HhRJCE 159mxVk4m3hREalE1aQRNZMOWGC/ompCaBNYZ0ashBBX0O1C+q/zXRISInaaiC/8yS2P48TQGrJT ovgOMomK5BMY0+434zIdwUTH1aE6rhW1cqAAxAVkIFfwLAzg8DqoGNpFesmkp6S+ITh9LuMT41eT JiygXBf2YYKhOfJBD4fT4Maff/kltCHo+rEP2U7uS6RCTjTNn1eAi1QedbGxOM6TVIlrVBXqgDEQ V5GkttSIxFFDlToHuidVl2pLJQkOfm8KMDQIBcaVRpYY6rBLInfYjXgq9nrSgKnOZF6hxRZzDAjf nV/Adp4Pfxf++ttzWMTqb8P/csbHpzjXty7akJIcH5PiWN+xaCP5LNwTvh5vxNvxTXhDePjCU7Pf 3rf3g1kzZ82qq/1ix12/nTOrYRaQiWOAoyXc75EOTfE7uek8r6ZaWo0FncFmIByx6bBOp9baiY/2 0F5KKTD+bFG+K+hygwqE8n1uF2Cdib2wyrz5BYWgCW6Dg5VceAsXhF/y7Uqd6GV34ry99JNtFnP8 zGnnTgB/74c5b+a+QnZ0u39Dva3NRjjKG2KoxZBiKOYma7xaX6IvqcgW4Ko1ldq6xLqkGlsrDbIg t0BsMrTGL0oITmhNbE3qph18p2GxpSeplwwYhq3DE4aTUpFOr8sVXBPydH4dr9Opak2E2GqxYCOC IybGfk+yLtmWTPR6codD/w0QIp3OGotkYiTVlmQQBIKAEpn9Eu8lDXfnM4tZEoP0c7CbL+iXv77g +I47rl/wu05l1dmejzHLzkpfHljx0RLqONPyZPMzbw8PXOsv+61zyrvPNe4umzpYs/xXc4H6n4K+ bATqS9Ft/l6VinNZVRZXpirNlVlSovKaJyV7XLWqSnN5crmrCTdzzapGV7dqqau7ZFC1zjXg3VBi 9UypmEKKpwBXcK4hl+TmZtbaxElEp7FpiEZjqBWVTkdh0sQYB52YNKWQqel9Pp3P5iPqfVP1nwT1 nxhii/RnXS6XpHRAsc9YJF1coaIimfokHCHUmZwGq1nWuMJxTczGXri9pJURzkh6KfWxJGGmzZta Wx54ef3Gr2bqGj9Z4duRMzHXnZu7qbZl+t6nJmZmL57a+vtWiWGrHiqvrj1wVd5G8kr2NcuWPuqb Xl7sPDO5Niszp3t2/fIkW+xDw0MFs61Wc8XUM87ijJy8bQs2Ho3TCm7Jes8EHToEHlaJNKjLP41p zJoUjUdToenV8GpNNc8r1LxC1NRgjqMKSgWfsk5JlDqdTUcUamZXihq+jscY63gb7wOLKBmUoLHI DdpdFHRJ5s1Y5CoJ5RuLisBCbNWH2HHJGhucoOfYbXA7DJgdevd4qJCcOfJueEnoGH4wHMQPfkKr L/SR+0Jtkh15FiS9GXDMQr3+WUrBKmQLpYLXUBoTECoMLcLczG5hSFAnJlprJHPgT6WpjtpUPono lDbAVamt5ZX2ZHtdIk40O5A9UUT35uhybDlEvDM7IsciSY7Bs65LcnQFQ5JNDOL/KEFJagaHxWEY FxzbPKOs+oVrh/40S9vwTnfVZk9OrtfluW3h/AeL6abQtOwWx/rDM+rn4ze7fjFtesCd8rqnJiM/ e7BuZrc9zRanJmMHwgOMZXoKH5c88dDYe+wu7h8oHmWgQnSrvzc322NxJ3vSPe4Ky7TkivRKd71l QXxLQottbnJrdnNO66S57rmFbcJi7WLj4vg2Z1v6Ou0644acLcbER9IecpG0GKWL0cQqPfFWU6XV jkzYZEIupSbTgWLS7OjuIl2RrYjYHRpNvoO/fbLsoMCkfiRzB04Gt2tNxLwaYyMKbkbO5BSvp6DQ OxGYkhJd2aC8VF7uETsbOxWbZIaly5ZXMrt3hV//6O/hD3ddO9iPzW+8j5VXD91469mfbLr6/tkN qTeULZlhm73O1RtsWfXMzlsO4Ht/OYbOndz4YjHv39v38Ae//0nnyUK+ZITUrRgeXFq9PNM4xVS2 I9S/sGdyTFrypIe7t47sAb1eM/Zn2ZskA/c6/JUCi2eZrCS1JNs7cUbqjOzyifNZa2wwriGhF29I 1RkS82vMmTVmPjGqL16D6HQg0YruibAlx2HdM1l2MaAtoCxFsqFzyaoCVk/mBlHw7JKmGAsjeiOx BkkaEmNUjCvORQ8E2sR2NrcsCH9x1LMwRZnYPe3d8+bg/vaFtwXmN+OcP648Utm48CX/ZNdK366f FvhzV5bNum86prTsZPhEb99GlfqYLgGLn03OS/GUjl77EU4qL58TPr//zlFPbvqTD7YO5tosWRmW TIjxWmCx10AMLUVpSX49biIc38QJCpTLg/cCj1wSKon6TlidblifblLzJRzUjxPPPyh7aCvE4otg HSrAWuz1L/eLuJavVBBRVApkKwxihieikm6FIMfMcfxGvl9BqCdP6Vf2KqlSVPIUD3GYE3RqDDaF cmrI+4pQGWqBnGEA+qLVanik5LK5Am4m18h1chs4BdehgkUK7gXMCugd8gVLfEVFkYAjCPYkePz4 8chFAMuCgg4ndVAndphEzC16/ZbQxlteJElY2Bg+Hz6H7w23c2cuDJK3Q6nAidNATzbQYwE83KjB 7+bUFnW6upE0WYbjeaMhx5OUpEj0CDTXoxBiLMYcnU6RakFrvDqv30uScsyKlR79N6F8Ke4AKwe6 EFkeRa6zsrUbtx7g0y837TjqAaBWUoDI6pAbSbdc9tyquS/eGfoKH33wgdqG2pUttz8ePpSS4dqy 5HOMgqtdrvThgqq86xeHX8T8NQ95J3vwSz2PFpZN5s7EpWVvXdR9W65ge5mwgtrYBE24wZSU1Bra 19KdGq8L/T4hJb0D7Gn/2MfcdO5zsKft/loOa0TeHIMTRLMl1VJgKTcvEOYr52sX6BdktNF2cy9Z p+s1m2JirB4jycpK8/DKGLQGDCiWbKgrx5fTk8PZLequbGl5ACtKZCsqFYkFqbKjBzuRnka8HmNh QYq0FizOfwvGCt3c9MLm6tKdTQ+Ev13ctrJrcSvW7B/88hbdhr9vX/NUVeXMxvLpz3btPLdKuzIu K9aUsKC9FaeeOIKTO9qXTqn567JFNTMDH++5+09VtVWLF4O2StI9CNLVokSIydKLjDXG5aRLw2JA oLEg0HUI6yxowKazuWx+CJ5YLMgzKRpGBsfXgryuozJkF9cwCC+yermDT+xeev6V8DY88BbGzXsf /c3Q+vmntj/zzM43mnt6yKcvhw8v8IFofIWt4ed/f+Cryvz089dmFVX9RfJrgCG7GzBUoWK/U/Qi Xs9D9oQ5L6FKLxYYEiBk7tfoNJgXzXilOqprJcGScT1bIweNshuSC7v7QjZ948LfqE4q3JmRcNdI 6A/jcw3DXCLy+JNgBqLAXoEqBETrVIRS1KHSqTDhgAXKyDSQE0jeW9ZmKbaXJwCvzYZDOrI1tP4U fZpzhBeOhNwwqjw+VyzTAvEv9SJBLxBB4JQKCgteJGY0CHT4NfUaKlAzd5GWUD7khL6SKCmQD0hz QORrcHPFp0Lxp06RT0+RN0Pp3JnQEVIN81wPduwNeZ6J/niR5fNUSfOxoFmlFFQtSjPlSAtdBaN/ na8PQflEjkdD+XJsDVbN67BIlu2N0JMnT5IZJ0/uZffv3Xu+VeLQK0DBWnnkn/rXxotNeCGYKDFD nCzWil3idvGPokKHlWISjieQWYlFuEj0qmpwjVipWog7VX1ovaCH3GobPg0ZziEYRhAPERUYvuuU WCBRTgCvlUqdxo7yIDVm9TDtauAKvoInwWA+2JKiKGOKInbu+PGhUBzETlv1Q6FgnGTq1vRlYqyQ 2YXdmFsbHgsduhUY9vpXoWXk9nvCCrB030I+VhGV/jqgjYMszkAoA+2CnF+nAEONV/KSvoN3l5RK Vicp81h3oeEU+Qt35tz7Ue3hvoH+arTe39ykxJPJZK5A2UPaaA/XphyGNHeY61WqGsUmZYuKdtAB uhaYpyRUREzPPKyCzWXdjGdMoRIpVki7giApUAqtTmvT1mspZ1Ks1ETXHoTV40ohmXyJ/j4U7APl wE4sqaCIHdw3p8KL14U7j2ItJGabsImjF26ny8+FgOiTtHQc58myxq/wz1IrbAqPolIxW9GuWKNQ rOOxDhPehi28h6/g5/ArcBs/jHt5lRoznrTgRl5aIQJ4LCbwmChMaBAWiF9FiIlJK0RCNGS4Qkh9 a4Ky+5FRBCZyk/8ZmnoUu8l1RznPuV9zZ8772XGwS/1jH3JvQd4SC3luk7+MIQazqoyxKJaPV8cb 5+F53BxFq2q+Zr6h1TQnVr9OXG8hCR4LcXhEZZyF9kPSi6VA15dKkyy6rpSo3Y04n6Bss2KMlojZ utLumvQQsSGDHuIRxCUtaF/SvPD8/XeHx1pa2tsWzsfcvvvGqsIXPvxzOISF997DCi6tI/zekSPh d9s7l3YtWYLtRw9jx7LFXctD7TgZF4d/FX4v/Db4oUIUsbdsD/Bbj2xAV+kUc2liwBxIrNfO1XXq FPEepNAriEIhxnmUVBR0DpuDGCyRhdCLGOpx6Bw+B4lXmMWV9qgJCp4dN0HBs5f8abbMYdmjfs8a sz2VU2f+9r5Tp/CtW56pbgy+WlCYt2HR8z8d3ANek+mWPDJ15swQWI/cvKJHt87sS7ElhH6e7crr lqQSvor7DqSSiiahLf52SSIsjiVKErHExSQuVDVrmg0LQR7z4uclDtj1jbZO29rEgVyWmurwUlWm J4kXZUlZiAvklGTikbs/zZKARD6R6hL63To31rltbp+b5oDQ8iNCk1LIfP3ZTyI5pA8Sp6Kzvmjm EcSRAPLfvSdIV08UUa9JL5fpdyVrSx9/XYzLtVwp1eYF7e+Pso7rMtfEJXx+uYTDu3WaYwcZvUK6 7ZLUw1+Gtwf6ro5X0nt/UNbc3qish/xzBZyIc/EUXJRYqas2Vye24CZds7kHLydtyk7V1XityiCZ RD3SK6weP8GEcHEe2R5KauB3UIMFnJxGo5d2seKpGXGSCuQDI4JyqCdtHEbVwBhJI8EYHpe2F7Dj oi5I0ZXpe955b3gsrA1/dgrfv/XJ6tkLHtjRnuvJXlf/2elFN07KzSb1oRHujDPXfedV979ZiB/0 L0lOjA296sjNWgV4bIEoiUCUlIf2+deD2bIhZ4JgtmUKGXEpthRXkVCgn2zy2gqyaoVKfY2p0lab XpE1nzQmNNoac1fEL03otC3NbnNtiOm19doHsgZytxidol+rLxSkEzJYM1gi73CkeuScA8IqR4bF arAgh1VEA/m6/N58InZPuixBjeanUjHIdjE7+2J+miLtF7KLWwrp4wkZRFppKZdysSTMkdk19W/s uT88tlm7Bmdcc+SV9iWBA4tPHcMl/7gb853axvBfb773l23r/Z83PPQwfmTeo8X+6pLi7xYt3d6/ ZJHVbDVnvfzgs1+W5PxPdet1XcHuCdoMS85BFHlLxL6Qs4N0fxxmXp5SQSfaxDqRogXYzBbUQezv Cn4d+kha1JJLjgjP62BfhD4/FfocejvOvc85RqTRDoKVzITRpNgt02l0xpXSUnEGnSFeZboqVpig oRbgWIIZrYP4zQbxG9WZ1SuSLtsELLkiewd+gFu7LO2CWy6zavbMV6+/8bWq2VWnHOk5t3ev2JOb 7jhFmh74W/2M6bXVDX95hG64sGH9jUXTyqaVFe1eRbcDZgvBc94k+8Jn/fdU0WV0PaUarCKMEY4T 1KpYHE/juHghXpVJM4VMVTEpovnMI5SIbuUUVYBUsAphhliuDKgacQtpZC3cPEWz2KjsxN2kk3Vz 3WKn5FFZv7BR7FNuVE1Um2FWhZnngKMY0haRQBxBRTUEi5QIxcjDB1AFP4TW8jzqA3fq07Zqh7WM X6bRfwHKI+/BQOYUjOy/wE9Kk0TshB92i9JPcVP4R++HXwi/+lZ43cu4CHtgmeNCcP4u9rvzOeC5 stjvzyexPwEeX4YHybe8lOlN8Gu5BoL5BqyiCIEvdYFiXswhowEp+Tb0HRHCD+GW8KDirp3/ukaS 7WMwxqHxMViDAlNpDBvYFOwqcbvOXhxD3g11kEOh76D/QzDO4E7+6p1gf7rGPmSJbBClQd4G9ket ZM54pcXJmrWzkxbmLNe2JfbkblAOmXsTN+QoiZBRmmeAuMdgsAt1E/CECXE+O5s0TYC4TJeIEw3p xIoSVehmyOtsXp+XTkxQbfZcTPZD+dFIWN4cMly0QmChHU5vNL1Jk7ZBClIKf3BHjxrkVtHdj8Rn 4xszXEMNt/92VedSnLQ/Nyujt7T2cLuy8LXOdQf8vrJnmz6rmN0xcNWS/VcZSo2xttN3Dt+dm2sX Ev1z42L16anHdCnprom3rAwngozMptj2xrb2mZJVPgpc2QV8NSE7mu0v8hCvrtiSZ68glbqAxW+f Z1xmHBY2TFBrRT62zMDUOMnPK1WCOQHtSrYl+5KJNkG0qrc5JO8rud+zMtWS4S26YjEppJhTos4Y 2ehRGCLb6bvqyqseXdq6o1I9Mlp3sOfUxyeu293wcHV9f81dT5DCGz+YUVeXC/mjOfS7aXPCr4U/ Of2bqsmhTSkTXgGdWD72Kf0Huwo50Dz/NJ2zzkmycbI2KyYlbgr2aqfEeONqcJ2yQlsXMy2uGTdq l+NO7RDu15r0erNPzRwOq4+KOnSTMzZB3JwMwrsyEQ3KmWjUEujRZTloRCryhjv9x6JHWte/VF1T j3O/bTs6U9n09Lz7jj61v2idK7Paopyem19VXf3ObmzEkwvSz5RX/+G1l95MirO4DMD7lcD78ijv A353iTVvwmR7nbVsQrV9Pt/F9+pFIyYGLm6almEhqYxTGsygdbdE+J6QIGx2RIPK/Hw0znSIxiMq 5kwmBo+Eo4S3wU0Nl2HOykdnjyw7/dfZlRVPtc/fFhgdnTFYdc/Itj31+9dOn4U92LDjvVkz6lPT 8UfnxsiPk63vvPTCb6oA4+6xT1gb24jiwIe3+P1pLFuTx4o1JUnlLKAJJLVo6mO6NW2xg5qhJC0u sdl0E0otTKVS+HSiWh1vRTsdkvP2OagNJxg3j4dsZ93jXiqSOAax41KGbwFS7JFYxWiJrhPWduHF qQWenU19n05Stp5aFf6f8Gmc/fWf/vk03r3n9kNqkrDsjkl5eQtyXskogCDDAtwvC3/3j6xbHzh4 HehNBULUyCcBFQF/rmAuMq/lwBoxnwWptFMFA6cRkPQqUtSJWiSorDoD0vo1+kLt9fH6b7Lz86UY AxCVF7hbzhRdkdeFMnKJOJL0Or1uWN8S86lRaetIW78KzwkfGh0ePvWsrzOLWySaVtyYds+FafTY PakvvKEWJH0IN7Ny4K4T4ofV/lmlpqlZ+TlT8irEgGlGVllOIG8BDnItMd14Jdcds5HrtRuSOaPD kuFPYgqFyk81E6dZFDoe844UoxXxceiWfFu+L59kJ8RtngRsljdmx23T2XGOyyqTqkeOKzasS/H3 VKjw+yoUDoe/bn6kQTnxdEfb1U5nUuOdg6BR06c9s7D92hpYzYEf++88eN0dDT8ZDn8U/iY+9rjR OzEzfXXF0opy7MCKXWdmVNWlZ+Rd+D1pT0587dToCZ9k54+CIFphTcSgQn8ytcRY1lqoXiOUmZgW Y40A+n9znC2uLY7oVVbNttjxrTQp2PNFTCzkfJc228etToyFtY4a4+IXBWY+PHN0dP7okqd+QTbO 3JqWlTmj+MIvwL68UtPw1iuSRTwAaFzLvS3veub5k3AF8as0hYTy4KmHRSzegtqYFbcNQ2SyTYDM +6PQR7K/9GXL+6BeN5XeUF77u9+pR0e5uJPnUlkQ6Pol0HUA6FKhH/lnZ5A/4rdFKmKdxoYTiU2T i12aPEgV56qWkyEsvW7FVnk34El5N0DaCuAUWN4LaFP2Si8oENLYNX4NEaiVuz6yCwDpuFsKfmVe jL87OX586J+RPYCQvAEAuebF/J8d+C7sHxodJbazoX/hzwbCN/DmC1biCl2Q36DA6Sr5HX0S+EGM BYniW5B1GGO8jQHhoU8ib6LlN7JXjY7y5oj8FLGgw9mo219NU2imKcWUWWGvSHs6S3E4FafaEicI sWUZySyRw/oJgj8X23Lzcv259bm9uRyy4nZ9qmqCzqq3Wa0T2m16v36TnuqlCDBfL+XOkhZLkT1Q WBLKB8cqv1W4XOTgOw3f0wBLRIMjeqCIHdVYYptm191TR1kEnHmnpBIHlvTdm943uuLIAbKxektG dk5daWxpUshLNtZuzsjOltSEBTfWNLQ1tjW+f/qirgKtP6Cr3P+frlr+F7oqIwGqKlnjD9kamF+F YtFUf06x1qP3mItjAtoKfYU5ECPofCKz+KhSDc46Xhdvi/fF98QzYwK/Oe7KN9/StwSXMsKLb2Kk Zb4m/Je/ng1/hmPP/hXHnXj09jseeXTvnsfIREj1nscl2AB/peGT4S/ffP31N3/75h+kiCLcwXYB VpJXm+n35pMiS769nNRYyuxNEE1cLWycoByPJjiIJkSV+v8cTVzk1fejiVlVZYc65t1UMzoaeLb7 pQ9PbN85e38Agom7R0jJtg9n1c5OywjncP9a62sM/yb8+UunpxeFtqZYf4dk69shW9+oNy6mpeCP p9hn0IB1+oRau+SNOWJgcRB+YjV4Y/GHvfHX3/fG2Gn4b6Z0dN7POl44O6ei7OCSlhuqwXbOGpz+ 4KPX727YH+4g1kANrFXtrncDNfUZ6XkXjpFB54R3Tzz/elVUB2kfWBgjmux3II0erAJVQ1CDWLlS x4kCQma/uddM1AqruM00bieQvHwgJZTZ6vy3pUL7lFl1BfMegMig97HmSTk5dJdSnFl64VMW/ElL gFNIM68e+5j+AeJpN9rtX8MTMcFC4hPSxKyUfLEkpUyckbKIC8bMcTS55ub3cCtj2uwdrs588xA3 bBiwr88YyN6Ot2k2W7dm3Ir3JaiQNi6TJdFNyTg5OW2q7M+mUtGRmRCnTUCOOAXaEQ20W73DXk6x xfPDOW4wkuQG5W2fy97Aej3pF1PccSlcjOVi5TQ3JjaG/iH09sbfTFc2v9Wx8ca0tJUZP/bu3lA0 ZfLPV3S8UqGsfnXJsh3ZWYs8P86+tqoKl93xfLHz9fK6+qay5OQ4MU6bfvvqyqE8V+Ek54vemrpZ lU5njDpOmVRTC7yaOvY/JMTdgxJQtT9HzVm5bI6q9IqpGpWSS0iIhTC0LnE4kWjRjYmCRm9VCgop 4FBsmyAHHCAp/Tf5wcjbQ7c7stcTCU29Upwhbb5CzHEpZiIh748mPXZweHgUXxfeKMTFzKyb2BGj VGqNR14mDffgaeFj94Tp/CXZGakJoiTLJ8CSzAMtki2Zio9XDCko4SwiZ4CoEwuyokdMmcoqbI0d Dzvl1VkStWTeKEKXpcwGN5s32vr48pHnR/XWhKaGmp8HRjcG6v/wGnkjdF3j+uycjBnFtAzmL5Xe NMD8PNrin5bGMvkCVsRPZzU8n8kVcX5uNtfGcbxV+jDMSgnNQOl0MiqktaiKrsVDREAcWUsx5YhA MEVHxo77k0R9oRpNQN1oCDF0k6ATMKUm2knXUkavUcivB78OZsvbsfIeWvTVIPxQUP6sSUpy2XC4 5Lmw79e4BQN7zj/Ighe20vUSx5ogfS0AjNVom3+VhibSHJxFMmkqS+NShGyVBxdzFTjAzcPzWTM3 T7WKLGYdQrfYoVyhWo9/RPrYgLBB7FcOqZLUElkKK6TqSNRflqcDMdIHEi6eoh1aPWToPVqK+Gs1 kipcytAvS9DH03MTmAsTXxB+9/Hwh+E//zz81vOv4Ng7cdIJiQIavCBRcS9tl4pESQnwfhNQokJv +W8UVQnYTM2KBDGdpitKUDH2UA/z8B5FsViqnIECuIJWsAq+QhEQZypbcCNt4RoVLWKjqge30eVc m6JHXKpy6ggSfCRPqCN+4UekVxBEq1KllImUAxtqZRzDhFMJIs+G2FqJXAYw5okGA+EqxpSyGCeA GHlA8ibpjZb0kY1f06phPGGYXQNRTzBf2sUOZucbYqNfjkR3/7fqz178ITnrlrkjbV1gtukseKxf vo2fDNefxcW45J1wDf55eA7JJXnhFvxQ6C1JI8EbSBqpQDf6pzF5x7+eb+N7eV6kCi6exnLTcQ2d j+bh9VQkCkmGnJVRVoOmM4IoYRxRky4IlQilTCYlOaqRtbJOcugmyC8wZSZWyTrZWuDHNYL+owg5 MjVoPIiLquXx6BaMKaKYoYEXXwuX/xrPwy0seE6Bf8vSLzxPSySJBsEn/BlwF1GTf4pFmEK9Qi2t FBbSuUKbMEx7BaVCQaeCghFhKhaYQIlCwYi4Q2VT+VStqh7VsIoj1yklEyt9ySG9WHJFjE801cnE XmmjxYId9M8XhsgNoWvpslAfufcG6r17y4VIbATP9jMVyNr0NKVgZPhtaulzL+SS3/HK1jmSH9H9 7+zb9/bb+/a9Q/bI17fflncGoXy94+SaVl3JP1GCIH9H/ejVFZnS9eCqPz02ti/crNotSC3F6Afk ch9BFW5ASJ0ztu/871S7o1+iXzqmCdL35q8Bh36GHqYPoKeg7Cafod1wvQOuIS4GXc/F4Bi43g/l p1BmQnkWyhCUNfQB3MINIiu3EZ3m9qB+PguuOnSa3YFOw1I9TRdB/xvQK2wA7n8Bzy7AdQbqZ69H rtwuqBtEW9gXCEGWcVDxGVoIc38J5TH2KupiF9BRlo2Ww3Ulex51A64VEszp0VGSjw6wUfRLuD6r OI2OSnXsbdQt94E2tFvuu5qmo6nw7AloW8rfiJrgWiLBzIOCoBcQM0D+bkPV6Db0EeR5ObgcP4Df IQtImNbTl1g3+ztn5jZy3/Er+FH+74pkRZPiWsXfBIOwQnhadIrXKOOVN6icqlrV7eoY9WR1s/oj TZnmAc157SLto7oc3SrdXt3f9Gr9NfoTBo1hueF5IzbebvzUlG7aZPoYgpFXLXqL/NUtmoYWwwpb AauBID1yoclgi27DPsg5pKcZ+JOL8itH0f1iyVjCXQQmANdGYQr9Z0dhBvWbojAHNnprFOahflwn FNB+nzQTozCOGr0owxFM3pBhXq7/WIYVcv3fZFjK1fUYyzBoNtqCDVEYIy2+PQoTgH8ShSlahA9F YYa0ZLw9h+KILQrzUF8YhRVoEamUYaWEA3lQhlXSvOSADKvl+mMyrJXhl2VYL81L/iDDJoCNJIK/ WW7zrQxbpHEoleEYqZ6aZDhe6ksj+CTIbXJlOFFuUyrDNhmukeEUuX2jDOfK8BIJFmSc6RoZjoz/ IwlWR+qvl2EZf3rb3PW9nUvbl3Ta21d32DvaB9rtj9gnFRUV2GcuX9LX09+zdMBe3tPX29PXPrC8 Z/VE+7SVK+0Ny5d1DfTbGzr7O/vWdXY0dfZ1tK9ub+hctnZle9/FflOi9fboA+m+H8awT7JnXGyU GW00/ix/ott7qUruvrzf3m4f6Gvv6FzV3rfC3rP0h1FDs1AP6kOrUDtaCdBitB5rUKf87w6fQbn0 bA4agOtq1AHnPtRB99En6HP0GJSj9BkwSnPRetQLPZfC8yVwtUdb2+UeUl87egTKJFQEfwVSkoWW Q8s+mKMfylJoY4cFIs3YK5+lXssBWo0mwpNpgMNKuDZA3TLUBc/65btOuHZC63Vw7oDwRoI75Lnb 5afL0FroJ+H87/NN+V57+/d6jD/vj+IhYW9HGT8wUub3Rvp+v3ygwY28P9jq0uzLZZokaECmvwOe r5IxWQF10kz/F65dLtlLsHS3/AeffXhFu5Uw9+Uyl6X+H8ZcCW3WX37PktgkFmBVrBTORVfMsBrG /U+jzILzOpluSfOmQX0fyGK1jMV/7vPDMKxW+RibIf3P178fcrB9MDO/QH/QftB/sP5g78FNB+87 OHLwtYMfHFQeP/jVQSI16X0qNq7AVoF1TbYmUtfY2kh65uJ75x6YS2bPiWUNc2LYnAYLq61pYNNr CllVTT6rhlLjLWIlvnxW6itlU30OVu5LZGW+BjYNih+Kz5vP8t0dzO31MK9nLvN4k9hrng88X3no kbEvDj2ZWl1wZOyDQ0/qnXD9wq95UtQVPGmtZusObTkEaH116JDc4px/7JCYUnDIXM2u32ZivSt7 B4nurvfvIf67Y+IL/HfFJBT4b48FaE9sQsGWzSab7jrdZt0O3U7dLtt1th22na4dmzZv2rbz5l2b d23dtU3nv0bUF+j6bH3Ev0ZUF+hWYftpbH8B+059eYrYf+X/FUGLMVqsX0z87fe1E90CnGs2sBxz Kss2F7Ess4llmi3MZk5iDns5s5tL2IvWSmZNqGIJ1hJmNUsfzRYxE6BrNFuZAUqvGfvN08oLdNos G+Kx5mTApj4RsCmPB2wiFG40YGPPBWz0aMBGngnY8OGADT0dsJ08kWU7fizL9py/adRhe+aow/b0 YYftxMnnNceO/1Iz+twv1EefeVZ9+Okjav3oplHiP7rpKNEd9h2uOzx8mOkOuwDsAfDY4d8cHjss KMVCptYQjhFKCERZ9Rw+gsc233RT4sieQMP8kU2JzUcEFJg7fwSP4B3NI0JgThRE2dLRP9Dfn/0D xwitHOEru9pHeGdFv3SjlW60zgoARnQSrHNWZOMRc2XXiBmgfxukf/zI7o8+jEwkn9DaH5pTwmUA ztn/D+KyAvMKZW5kc3RyZWFtCmVuZG9iagoKMzAgMCBvYmoKMTA2OTQKZW5kb2JqCgoxMiAwIG9i ago8PC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UcnVlVHlwZQovQmFzZUZvbnQgL1BYQUFBRCtDb3Vy aWVyTmV3Ci9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwovRmlyc3RDaGFyIDMyCi9MYXN0Q2hh ciAyNTUKL1dpZHRocyBbMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2MDAgMCA2MDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMCAwIDYwMCAwIDYwMCA2MDAgNjAwIDYw MCAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCAwIDYwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwXQov Rm9udERlc2NyaXB0b3IgMzEgMCBSPj4KZW5kb2JqCgozMSAwIG9iago8PC9UeXBlIC9Gb250RGVz Y3JpcHRvcgovRm9udE5hbWUgL0NvdXJpZXJOZXcKL0FzY2VudCA4MzIKL0Rlc2NlbnQgLTMwMAov SXRhbGljQW5nbGUgMAovU3RlbVYgMAovQ2FwSGVpZ2h0IDAKL0ZsYWdzIDMzCi9Gb250QkJveCBb LTIxIC0zMDAgNjM3IDk1MV0KL0ZvbnRGaWxlMiAzMiAwIFI+PgplbmRvYmoKCjMyIDAgb2JqCjw8 L0xlbmd0aCAzMyAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMjI0MzI+PgpzdHJl YW0KeJy1vAlglEW2KHyqvq/37vS+Zumvu7N3NrJAQoekQxZQZBUkQSLZGggmJGQBcSPOXAcFFVxn EOfJG8eZUVSaBDWADoyD23XBGRlcxjswPtSZ0YzOPPT6jyb9TlV/2UB93v/+f3+pqlNV56s6dbY6 VZ0ECADoYQCE2G2tnc3dyxdecSm2vApALK2b+6SHH27+B8JnAVQ/WNu9rvOgZWYhgKYNQPH2uo6t ax3HV80FMJYDZM1dH2lue31bL75fOoBjzFyPDbrr6DKsD2M9dX1n3zXXKAwJWH8P620dXa3NQA6/ AFAWxvr6zuZrusUuVTLWf4V1aWNzZ6RafSCA9ZcArGJ3V2/fWDqsALjsVdbf3RPpfmbfLi/WPwHQ HsQ2Amw9bEVAlPBf+xCg/8U3BBBBoVSpQaMFnd6QYDSB2WK12R1OcP0Xh/r/6yN+hOkuSMQyRWiB FIDYGTm9P3ZjvH9sNBajbyHycjnFP8vxuZfny8nCeAltcAo64U74MbYVkdfhEQiDEdtPgYCsr4dy uBu2wB9gRewf2OqDh+BTyIEyWB8bAzNsgzFyAzxEKHLaCKXwJkRgNy0XguLHyP1sUiDsJz+AXBxl OdwHTjiJI2bHtFgfosm0HN9aDq8Ia9Q5sYLYP8lx8eVYC/yMlNPT4hOosSPEL8LYD2M7Y3tjD0AC nBeSR38bmxHrxLdWQBP0w/VIwQD8D3iNNNA59FjsVqSpHmnYBk/DKyQogtgEFliG2P8GP4HD8Gs4 CW/DB4QQI8kkA+RNckoBoyfGTsQuibXEuqAWFsESGMDeZJJGqugqYZXwuPDW6P8aOxtLwbGXw2a4 Bq6DXbAb9sNb8A78kQhUS5fTFcLjkAhzYBW0IDfvRpoegZfhDFGTYjKbhMmPyGN0syiMnuA6ZkcO zufcvxP2Ik8fhgNwAt6A3+GY/0CeCsRNgmQFWU1uIDeTO8g95GHyGHmCfEwV9G1BEG4SXxA/Hjsd 08bujz2C8yZCEkiQhZIphctQnq/B33B92SSHVJLf0yDNEYioHx0bK4rNi22LPR97CwKQgbhzoAbX vBBWItVb4YdwFF7Ad1+D1+FD+E/kkkC0xIK8kEiALCOXk36k4nHyKRmlDpRfKe2gg/SUEBReE1eK T4weGrOPDY59OhaL7Y9FY7+NvcrlOxPnqUYJNEI39HKJPYnzPA/n4K/wOc6hJF6kdT5ZgOv9CY5/ hnyN6qSmN9LHaEyYI+wWXhbd4k/GFo11jv1kbChWHFuIuiWAAtxQjM9s1KYV0IBj/wC5+RA8ipIZ Qu05DX8nLpJCCsgl5ApST5rIetJFuskmch25Hrn6CDlEjpLT5I/k71SkSmpHPgVpK/0BvZseoifo aXpOAOFyoV7YJFwn3C0cEt4Q/iKaxByxQFwoNolbxWsVoBCUDvWrXzu/7hxtGb1/9LdjeWM1Y1eP 7Rz7zdjpsfdjutix2AeghAKksQHWIY034Pp/BHfAg6gfjyKNf4aP4GOU+T+RFwLREA9S7OVyq0a6 FyLlK0kDWYvPerIB+T9A9pNB8gw5Tn5DXiavkN+T98inlCD1efiE0ApW0LW4hvvpfhql7+DzOf1/ hHQhRygUioQKoQlXs124BdfzY+E94QORinZxhni5uE18USEo2hT3KfYqTiheUvxNaVJeKfuI5VP9 j/Aq/Y1YIXTAPlhCBeFv9Pe0nNxAvyK/pMnkNzhbsrBEWEKraQgoOYpa3gk21V6lT+mjNjCpmtgY dA/NFVaK6YIe+tDegK6iP6JN8AvyDHxF56OmbRZeo/voGmGveJdYQd6CbTgnUAP5AqqgilSg7N6E TSihXOGA+DobUaEWvlZ0UkNsu/iRggq/Rz84h1Dh38kqMkKWUAdyK0TvgADWTWQEy0vQAt9BzT9M VkKpeFa4jV5K/4htHXA3+Q2u8Sh00KPkZyiXUrTHHrKEPCDMgBvJJuRGGWyg94CfdlM/6vMK+N/k B8SOlvsVyiaVrgVRMNBWOEUbUOpvEAvNIzeinnbCTrIDcsgoOQ6v0jthJokIv/7aPZpJydcj5KAw Hw6Sr8SXxZepiCP9BrlZgN4jjBryEPqIFWiZPiEdtaYUFDQH9b8RPeBlYKafk+tpB7STnwh/JQ/T KlgMEaGX1pH7xj4Xq4Qi5NgR9CbVyjI1KMoVyWIxSvwjqEBtXAegXC+eUfyAwcKbwvlYQ8w3tkaR MPYeXIvcmY/ebSfa0nx4lzjIVWSpGKMLxFjsCthPD4jvxZxET3zwuxha2NiTpJykxiSyKaYjS1HD r1I+MrpH3CneLPaL1+Pe9BV6zR/BXXA/PIe7yc9x38pAPl6G3FyNvqcd94gCKIQSXF0FzEWvdAn2 LYEr0J82oZdcCxthE3ren8JjcBB3qAXIj6vwvbWwAdt7cYe6Dm5E+98Ot6EPuA9+Ab+jj9IHBR+9 hT5PN9N2eBfeFV4UwuQKOCXeKm6DyyEVlhIrzjwLpeTF926LvYmzZUEiev9itFLU+9jHsdOxX42e xPF+gbTfpZwLHyurAcJVy8OVFXPKQ7PLSmeVFBcVzijIz8vNCWZnZWakp6UG/D7Jm5KclOhxu5wO u81qMZuMCQa9TqtRq5QKUaAEcmoDdU1SNL0pKqYH5s/PZfVAMzY0T2loikrYVDcdJyo1cTRpOmYY MddegBmOY4YnMIlJKofy3BypNiBFX6sJSMNk1dJ6hG+vCTRI0REOL+Twbg4bEPb58AWp1rW+RoqS Jqk2Wrd5/Y7aphoc7qBOWx2ojmhzc+CgVoegDqGoM9B9kDgrCAeos3b2QQpqAxIV9QRqaqPuQA2j ICqk1Ta3RZcsra+tSfT5GnJzoqS6NdAShcDcqDHIUaCaTxNVVkdVfBqpna0GdkoHc47vuG3YBC1N QX1boK15dX1UaG5gc5iDOG9N1HntOddkFQe3VNdvn9qbKOyodbVLrLpjx3Ypum9p/dReH8sbGnAM fJem1TXtqMOpb0MmLrhcwtnozQ31UXIzTimxlbBVxdcXCdSylqYNUlQTmBtYv2NDE4rGsyMKy7b6 Bj2e8OHYWfDUSjuW1wd80crEQENzTdJBG+xYtnXIHZbc03tycw6azHHGHkwwyoDeMBWITPRxiKMz aMGyCc4SRlHgElSIqNQqISX1AVxTKcsipbCjtRTR8NNA8K1oG0qkPaqpbtphms3a2ftRRZopIO34 HFADAiOfTG9plluUaabPgYFMTyZUDfvH4WgwGM3OZiqiqkaZIo0VvF6Sm7N5mLYHuk0SFsg+WIK8 bW6YnY/s9/mYgHcOh6EFK9GBpfXxugQtiYMQzg82RGkT6zk+3mNfwXoGxnsmXm8KoCYf4gcKe1Sd PvFjNDmstetnR4njO7oj8f4FlwcWLF1VL9XuaJJ5u2D5tFq8v3SiT4ai1up6IZHKEE0UeC8q5eoJ ZFap10fFNPxRcqVuG1apUSt5C5Hqoqam+fG8Qevzfc+XhmOfsbd4MfmaTGZ0dnB6PTStPo08/Q4B CRbT6YLlq3bs0E7rq0MPtGNHXUCq29G0o3k4NtASkEyBHYcx8Ejf0V3bNC7R4diRnYnRutsacBHr yWzUVgpzDwbILUsPhsktl6+qP2zCY+Aty+sHMaSpbprbcDAV++oPS+hzeSudaGU1idVgAUFNH8SI kXUlHg4DDPBekTfweuswAd6mHm8j0DpM420m3oafXIxYWCyBD+6vKqg7qFQNE/0hbFWIDBBAq1Qg 8JQgUI9GxdqeIuBWL77OFVxkOl++cLR8kemL8oWm0XKoLB8tZ2lGgc/sM6dhRjDw/1oSjn8dVsBX IInH2Qn1CFWJVroN5/OE9XCcgkdB3WLrfjbgOdOHkL9wZEYBsftKROvXv6TbrrkG3/kwtlL4m6IT TNAZnq3ROIhbI5RCmaaOXKK5UnO1ZjO5RnOr+lbNfWSP5mHyiOYpeIq8SF7WnCYfkr9qviBfapw6 DdENk5eeFHQVcKVmmAyGteRK9bP5AhHeMg+TowefcQVN5xtHR86PnIN8RsKmxkaM1QP+9JLiWWTm zKJC3NiEs6OrzYlmt5Y+pLMlmN2K1H/Vp7mNerviV84Et1GHtC4cPanwjAXAAIZDqiuJTszPj4/n YyPNLPKxcZTi+189lOLxpIiNXrd79KTTanWyhOeH3bEz4hXCAGRivNQSXvqo6ufeR/OEdFWaNyT2 Wbd4NicO2G723GW717Nftc/2c88T+U+qnkk4aDvkOZzySsL5GXYtBj/ZRLjffI+HXpe3I29v3qMJ +/Oen/GHGR/MUGf6h+kTYU9avi8tze/zZ1qSrc6smT6YmUWEIr0mZ+YwORteRW7JBG2RT9BpfJBj yunOEXKyQnp9pu0Bky9ZxToMIEm+sMFRafSRfF+lb7Fvje9B3wHfMd8Zn9rnKXXuKvApWX+X8kHl MeUZpah0z8o+6homOTczzWkkwYWjH6LuNG4iQaZGUDlSOTJiKcsfyW9EqLL8/IjZUmZxlhEsyixl 5jIwjc7BfhcxfX7+xIwCWBB1X74gmopGfAxUsS+hOPYZlGByx84PWdR56lL+aYDGTYiqQ1Qboh6F FESxxo6znk2NpNFXEhcxk6+zpDg94FfJMp85i8vczAWvDAjpvM9ucxQVzpwl1D/9xo8fPfvW7FsW Dwy0HJQ0Jqc2ofWBJQ8Odns9Hu/zoX+75Ol1i7b0dB5t3Xr/nq5rnzKabqldW6Z1Wcxaoyf7p62j p5xWi4v8zGxaHFp22fqVa5ht7EfZL0DZZ8NnT/q0OmOlfTj2RTgHgRft76W9k3HWe9b3cdrfMlSp 9gxHjbQwbWHGCqkxbVXGBuMGd3varW69Yzj2z3Cv1dZgvcJ+ddrajC88CqXHbbJ7skxZljTPDtNe 032uez0P2x9G3EC6xWx02xLxcKlOcCc5jQYQzDq4xezLUumGRGXSz5y+gC4hpG7Y5yW7vce91OvJ sfnSw0ZN5b50Ykz3pu9Gf+cOnrhjUrAoz4UjXLALz4+gVJkwR86ZUZIoSMJKlKeZVVCGmxpLS9HQ SDBI4iKw25WM/RmM2eO8jpseEwuUFENRofC8y2J1EafV7KTKA/ccfe70oy2vLLObzM7IQy+9MvYV 0b3yG8GQxOTwa6/HmThv4G8/fujU/CU2pzk492oivPgK0eMRDG5Ebu9nt0rI7z8/dUn2+mz0lsw8 EkBBFPlEoaDEr05xsSZTYr4zMdHl9KdoHf5MTaN2mLQOZfqQ36Q1LPl9thTQ62wqdKbE6dVIA+y+ hRBPTppvwERMw+S2oWD2QJxJpi82yfwZLS83oeJXVprKTSPn8Oc80/Wpaj5F5xuZ0i+IOmSdH0pQ W9RMiRdE9XLTYciOfTIo2TKOoDWkxz4aCqhT3RNWQMYVOcA1nqk8MtZplrXfWjzJcZHGlfiuP/f8 buvW3/W+dx+vd799731vv33fvW+LH33VybT3ly9tPbvlmjPXvkTedWH165f2vffevgf/4z+QtwPI 23zUZDdI8Ea4XevYY6eFdC5dRlvpC/QF67+737W8634v8X+5PvD+y2FwJ2UnFdPSlEsTL/OuTlzl 7Urs8N6YeFvinqQ9KU8rjP2OI0knhBOWl5NeTlGqnzd7JAkIMSf7nCrRZ9bpl3tC+4B0owUNkw/C Tr8UIqF9NtJlO2Y7aTtjE21uX/ZjU1R04cgIEwB6eqacyGDctkwj3KeMM3PQYVNiCHEo0eZNocOx TyacCcEfn2OaYk5oJqi43qrE3K9/5fjgkater7ImmFymgs9venvsDDG+9DrRrnT/4e67T3nITx96 saLI6DabTYUrSeLLTxPl2P++aecTj93O/MBbeJpfhZpZDK+E08L6JYoBxQ/1N83Ypx/UHwo+FzwV 1DrVRo3+JZPJrynOgxlkxjAVnwLw51E1btfhsIeg5qZm+iGtMcuXDGCR3Hm5LqVGrfWjLoa1M/FY LnlOctW8N2zIt4ft3fY37KLdXdJ/mLwKfHdvXHi+sZzp6Ie4t1eWl7P9ffQc98dgGkGVPFUeLxvH gVO4+VdvDSdkBxNRoDleCCZmeQkESfCmmwhqYHzvC8g7YdG47hVx23c6eKc/gyuiXcal+WQT2yhH u1j+ylMsf+qxO7ZsL7K7bGrrj9dv3EJuZY2CYXQeU0r0DU56mOnjtg0PONQOi8UpODtqt7EWxtsV yNtO5G0p6Qnn7vF8JVGR2Embsl+5m9xD95Gf0ygZotqHlb9QHVI8qXpB9bbqjEflUZud3A8YbV4b ta122WxOl9+clc8adTmrC3Jy8gv8WSZt3H8YiGG1xmDQavym+I6rS1st77ilhaweKMmfUVJSOMNf SqSsJJ+YlZmJqlAKosqkVWsk9xkXQb/zUFg3G3zSjGMFJwtowTD5eKhsXvO4F2GyMXEJyS6EPSPm b3UgF3qT7+g6qKTVy9GfkNjxocTUYjIcOzto9hRDMNjABWzyJCpUyrREhdtLPKqkuIhRxmg/lgln pIydf1LSe20pDm46pJHtt2YeSE3uqhOqEN95VRe1yypCli25+8qWW1dfheGSd+xT5o6u+mH/6qr8 jjVM+GN/Z/kariniR6NfrZxXu2vx6H9O6INw5bW50pbRT8YbxAquDhSeRW1wKMwYjSbBtnC2313o DruXuVvdfe5/c6usBlO9zeY3KPWaeoXCr3ckue+12/1JwvN0mNzzVJLSoNcCOUrW4PsUA6cEUVRI 9sU2YnMnL90WNyIW3GB4zAPkyi9GphnOVLtB+7AHSqwX2IhvnAF09/XbyKVs3aMutkpy6ecpiR6v wvzOO2NLv/7nFM3HvZHp+TFc2d2o5yV0+DBkoSAdhsqsYSxtel6GF1t0leusv7DSE8Uk25adlpeV XZxZUpZamTYnq7J4g21DQLfWSgLWmVYatC3OeiftneJP0j4p/irtq2L17LTZxRtSN5Tst+0PKFNL AgGgaq7minyNQqHW+GkSU/tD4CVeL5tUb6pkZdiEsYx3dcDr9Qf8SQHILeL2UlBQV1xQUFTszy0u Mev4QAn52oQEndZvTrSzutXo8rqoy7XH5nLZbf5EmzUnnbXPy8panZaVlZ7mz0lLTUtNlUqKbSUl xQGb1WKVIGADCIC1JNWmCBB/KCnJHkpUpodyikK5uTk5VBeymEEdIlRrY2GvpitAAvenpa4oOUL2 QRq2GLqLB4qpVFxQ3FQsFDN7TJ5lRW9KJG23ZkBDTRpJU4DAPk1Uo9S4Zx4lP4UBcJE2eZ8pj2/x DMRzBRYYEJVjbDsSt1UTbj5Y8KBou5gXxIPtYYxNTw2llFdah7FMmhUv3YXx0pnLy0FbZiXaIn4a yHbFDSe2J+S5goobTCdcoJ6w43/ko1VPrV5k8t+Oi8Z8EboqwVRePu4YrLGzQ57UYhs6hiGjudjK HASWjCj0EGRqTBLAmMSmTjsS+ydG6F/EXcGmRraRIgZiLZGxvhxKcxdLcU+xCVhIGCQTG8QkQAJT j1GBACEXeAxCnnmeGcgm7gyeJ5EgNxcDM53msWHyYDODxj5jraGxH5PNYzsmPcLX/yI5zIAYPPb3 sYZxsyK9aFFH0aJsaFEuaAwXt9h77T+0C7gL17NdGPfderbnWlz2e81mvwtwqwUimU2mxaZjJsHk dk/1B8wVfIcf+FYfcOd0D/BP5gHGg7Epbg1ptSOtxzD+qqPZ4XLjLGNpQplxtrHcOMcYNlYbazWW dP1M/aHEwRwxg8wkdEVSi6olqU/Vl6SYqSpMqlXVJq1QKQrUs+Zw+zwzm8yuq5g9e06Ff5bdyJpS JAtZYnnDctbymUUEi8kStgiWugSLxZjgt6d5+VYJfpOf+utS/H5vij9tZkG8schURIvq8ouKCvL9 M+vCrDFypppU11VWV4cr/bn5ypT0vNzM5CQlUWXPCoegTpntEzw+jUZQzZo5My3NrjUkSE5H2FtS 4BhwUMfX6ckpUkY6q6cPpNP0rysgX6qsYIdPqDhWcbJCqHDPy37cJR87uT8+3xgsnyhQGsweK+MW WT5ilk+dljL4lv3yO2uNm75tO1UyL8y30wu3VXlflTKzXG6tXlTo0rLEDC9RKN1ap5dkKrK9xKX3 sH0WN1pTOdtrcbdtbMQNN1G2tCotaGN/BxGTKvYuzvUubt9vymHrJrKJOxcVo8BToRyOl4ySQSw5 BaTRauenYH4umNyiA3xvntyaAxfu1Rca6V+u7qhq8ZX2zr5y5rx5TFP3LirKW1tVx8HFM3Jz5lTz 5vdZFscQWlb01tbV1YYuWzX6JNNm+uPw8trI6JscvrN6ZXJWW7wyGd6hlneglq9ELS8l28Oz/qD8 g5qeUJ5Q04fUg8pBtbBJNaCirao2dVuisDfxYSW9zjtEDlEhybvBS4GIlKagvcajOrvXTu11brvd 5fZbLozq4ltSAiSQhDp5V4pHdSZIM6XRC0I7Q0ldPLQrDJUqyRFyFiQ8I1qTfaIKozyLxazVaCXP GTdxsw3FxAO83QX7MMBzs+huMmiQY7u4co6ex83i+8Ry/73IzpaYpFCr1Eo1VSYpUOES1cnx6C6b R3fjyjboteGrfzqYaIur1yYM7TA1YgwzUw7lL9KO6Vp0UYC3sv6OhqbFpVdyffgzc3N1P+i8/NpN U+M7WVe2NdRkpey8ZPTTyfiu4brqm0f/cYGCYHx3J55Dy1FDdOAk88OlFofosDkdwsvkZd0f6B8V /6H6g055tardTCM0Irar27UbDB3miHWtU233CUafRtBpVHofMHsxuit5meDkZdhgL4kCMUEBNGH4 N0y3h10WnzKMaMow4nQpjylPKs8qP1MqlMPk/SEXuqDxyB03t5HRxk0saMaIoJL5HX741MnsPQqO 2Hmwxc4fMtkSbM4jsfdxx31/yJBiTiktnTzR4zbKzDqsc9hMiZU2lpnZhZHVmFKps2Gm1mKmYhm2 fxJOxohPZdNZsBMzh83srLCxzGoz2hjGibAFAa0WgzU1y6hg9JaTYDzUmPw0EBtMnnin3huUj408 d2Ls78Ry4jliXfHnffv+zBI5cHzsM2I+dpyYxz77zf/405mfPnD2DMomd+xGbr1peIDNDVfO0BrL MjCV5C4lK2ijoY2gTJRXG/rIddk9ebrfKo9r31G9o3k3450ZHyo/0KrdQo5wneo2YY/wmKB0JHGT decnu91JyX5HfJfSWV6atiVV+fPl3YgYsvKNIXtSCDU1Id+n02b5yN2iCryhNGW6z6gmak9RDiRI KcbkxclrkruSxWR34VVTrrl4aMeucRayS67yynP80pJJ8jvucC6oTL9wyNQXHEGp56LUg3qDRJjU Z8T+42BGYELmXOLssswuH6OYIDK+1aSmiIZkL3is//rf946NPvvn217lJtU1GSUJP33zJ3tOndrz 41NCy54rV/ed7HlyLPb0mJLZE7uWFkM8IGq/8+Qbu+984yS7qWQ3FMIW9Az2sO36BJKjWazdYNlq udVyn/KnVlVS/NDrfUmO9BPtR+gTGBiHwxo5gA+mMYzFmYtSMzPTUv1BXYKNf12sUBmIFWwJJm1q WgiCSm2lCR0nxu0sfE/UGlWfqajKkws2KdUYWBIYCOwO7At8FlAG3Dmjd0w6z0WmDxvRdS6MB9kj 7HsJlAsTTXx3Lyv7drFMq3ynw0TxmWXxPWm1JTgsSeO7rSwhfqEh32aqvu36g9KfP1S74Ca3VZtg DRS7Z+09Rvp4mNeZ4nF7X9nLcqHl1D0rIh4rnkkDnvr9Y8VcNBazkz4j74UnY2eEMbSmGvKP8C22 yqQqarkMGqC95jHpsVn/s/RV68tz/2Q97Thd8ce5H1vPFf9l7tfW88VfzrXorEqHokIz12u1O+wV iXN3+u8tPmrUrbSuKm0v3RC6tvTG0K2lt4Yetg3atHeEnvTSpepgViB9RnhOebHHZUxQ2fVlUFxY EBDzZhoT9IIWBLM7NGeOz+yr1g6TkkOClEfyhsl94aT0mT4fhFQrynyLU9akdKUIKZ66GcsDoSy7 L8w8qgN9Z7ihK4tkuWurVYIyXevTXSXfmrI7jkoSv5UiwRHT6DlufKOjI8Bk3IjZqLksX/7SYCKE 47fOZeyuGTe30llzLVJSmjXNWWH3QiixzEtmSZhZ5mLVUenygtNVMWd2cjnue55Qeal3phdsVWYe drFNOJ6RuBfk++G49A+FbMXapGdiH4Ez9gnU4JGnwjYLXe6Q31GeVDppv3iy2dTII7FS9McaDFFD NsxKmXd2mexYw6yGueMaGzrgGhsel5PYOMgZhvQ024RsLJvijnEnkO/OZW3LkL+pcDrYI9+q2fjF eol8zY59zC2UFGekp6bHv/4Qro+ffNiteumy7bcvCtUV/OhATfOa1198cZvabmCuwOJ2BvZ0/Xzf 0mVjL95y2am7nxCCyaipu1M8Dnd5RmlZsKQ8M8lodQWun3/1LyN+W4In5XFUX3uet6Dy2ppF+flS 8fryjm3shHIX7swh8S7IgZfDqV8lEkOiJ5H+XPuk9jntm9pzWsXmhB8l3Jvwi4QXdKd1SqeaqJgH EUlP2K4WRZXaT0w2jd1sNJktNoVbnzVMHgqbU0KpqaoQIaDU+9w62y3iMHkkbMvJUWukdN8LkGRK kpK6k44lKXC3+GAolx0KUInO8UvO8/wyGD14uWl0JP41BdOgCxw2u930JGp1Oo/GC9pEvRfit5vs bgt/xi3cbLvwgji9ZPptp8OOoeFL3BGX9m9a8cIsm8HkMkj/uenuJ/byQJkJQ2hhxj36u0taiiSD 22w0+Bbu6Kf5rPFLhsT4eCXysUFogQz0xHqt+KSDZjqIR23UcA+sz1fr9Rq13xj/GkOXuEj+GiPD x+q5kEpS66TUVJ/kzyAOo03yhSBD63SFvCkpRrUmZDIqbT5BJ0kATgeLVzVZJrOkPqkiKnYdmXnh dSQycoTzcZSHrfFvhKfviN8RoI6727CWhJmzlaZdOlqsolKRZhXNXrAobXHOx83QKpvhs2BH83Pg xmmJvS/f1/Mv+DKmsJ/LZtZkdfz7vR899tJ14cvjtwbrF722n4vhUx5yXvdAdX0/TeHCuH3Zhmfi YPzWjckgxH5DGWUQIGvCM/aT/ZbHrIKklXSSXjJICZJRwig/REots61r6Tpzu609cACRHrVawl6i NTFB2A1gMBnyDYJhkdlgMJn9WrMlvoniar1kypWZRuCHEaVyNVUqBerXUBK/Iqt0xe/IFk1ckZkp IZLFbMMzhy0AIFltNqvVZrUQ0MqXYYmmkFYIaTXKQMg2TDaEdVYayjdXmg+YBfMRsgGsRBM2hC2k wNJl2YfHfdHyLDmAOpNGfPFrLna19eH5xhHTeX61xayH/VSW5+dvV+QFt99wYnueixXTrqYaL7yb ml69sJvV+Rfy0OgLXHQBVHRhC43eMfbLK/gVSYjlO0lxGsm7jTeUs/vjFYKByY+Lc178rDB+b1Ia i4n3oCQzhZzww5mODOePhEcdDzuH6WHHIacaqIluc+xyHHD82nHGMeZQ76NRepIKalFtd4kueybN EjPtGc5SsdQ+X5xvXymutNXb6931mWvJ1eJ6+zrnOve6zOvEa+w/cdzn/AXdL/7Kvs/5JD0qDtuj zqfdT2e+7HjR+UfHKedfHeecQZ0j0RGkQUfQud29PfMxx1HHC4oXbO85/kL+4vySfuX40mk2WLk2 mEz5NpPJavMbbHZfBmvK6U4lkCqlhlOFzxi0L/WNVKE7dSCVmlKXpNLU1D2ZqakZmX5fJuiV7IWs NZptml0awajxahZrhE815IDmmOYMayAazR6FRqNU+PUKUfJwrUxOzncnJ3vcfsntupc6nNJw7NJw oV0UJJtCFCW7zYbbUSYqncuN+uimhApEcjkRxtMaJYJkdyCGgx7D87GT9KE2nWXXVuRsOCDCckKE 5aI2I+TzhCRryKAM6X2SZDDolV0u4vqtm7AvsdLhbne4oMQdzgwWu8NpGZglp2Dm9mBmNBe7Q+Gm TJJ5lPwSzxpOsjPsdKyg4RllxZThUYZHwyZzMR0mvwwbFFKTndh/axPvtoUU7FqkoIQVQ6Vlxbwa jFdxGl7iCLzE93mJg7EybHE4ixVhe8k2xS4FBcViBVU8S96HrCkW80Vj48TePXLObTrX6DGNssqo 60O3abTR4xqJd57/kHWCq7J8/LqYR7Pny03nGDA6wixMfYPpBJauSYCVcZsLBr/7QrixcdOmi9su buTWN3k6fTJT7VaLpsmAhvT4VIKQIYy7VNkOrdYiq/WCNuGW9YeH1z+RxYzxI5Zdfe9Q2/CuDewm 80MW9GYSmjR6jkyx0LXUNvoJvX+qlUbQ325AK62md4Xv9Zq9FmopNa8000R2Hvf6m0inpcvXFWiq /i35rel1y+u+VwOvFj5X/Fy1UQ0u+IlfgEJiqTZbqgMmf8DkKy4qJL7iwoDJYpJIoY2QwuJqi8Ui +YptPl8xDZGQMYSO0hqyhHwhKeSZESoMpYYCoey5oepQSag4FApXV1eWllYGAhl5eRmVDYriYZJ3 SKq+v9LEvlhIJESh9/kcer0CHMThSCb3GxVdqBqe2kLsHwrcn2HheL77MxqMyfnykVOR7K7Raj3a bGVI+eERokL9mR4In3Ofd424TZixWNi98JwLJdaIUbAbk5lJD3vPeUZcpnOskTXIpQdcphH8XJAp tstfQlhi/86+dLDIXzpg+diQLZOVXwxZAqx8n92DYPmnwcTyCjkQlb09u5IImGbi+6YcfNkUxjdN WnzNlILvmFIw4DX5J97irxnxE9/6nzS7DMbiouHYXwaxjG/+8e8LOGFFsffDGouu0pyis1Qi1vvh SxEwax3OCjNumRXVVSmWSsKy6llJ5krCsupZiSaEMKu2uY2VhGU+bbJUUWzErNDmTqwwsbi7kAXa WFrksno4dmLIZGO3pCfCBgQC5Zj5WEaCF31gIhgnhY4LvpGYdkDHgzmJ//7FhFUQMs1MlAG6j9yU bjN6vGP/ZEaxc+zw2FG+gY19muIxWtPJTWOPplqx/wO2n7WRRJLcxkzoA9abSp4f26VyGOSvLsrG XozfixkcKjyYzlfzHnae/5SY41ald6jRqkYAhL+jVTnhr2FtArsAIuoELX029gUYYl+CFkQWQary BZVKFPxaBw9caqz5RqvVZPQ7Egi1UMmQYDMYEgx6mkAcBqonCUYJnBinSDq9ljSKIaO2UtulFbQe t6OxS0/0blf/wOStysL4qY79YoYcO8q/NcTOcKichCsBjX8lRpnjRQXjJeoYlm8PooaNKxX6rrgP AxZZTqugTrEDGQkSO/HJ8bjKV0J88SNUSYlwenQnLXVarS4yCrRn9It4OL5gdE4fE8NLC+hzPQx4 kf3GD/sDjw/X3vHDh55dYyz/XK1R878beShtaTMrjy38x+LYqdE9Co/qAaxqJv7CD3P2NwPoy16L nYr9XvxKbp/8uMXXYB2mI5g+xISYsBvTfkw3YhrA9BamFZiexXQM01FMdkwdmO7ElCvjn8R0F6Yr MYUwlWKKYBqR5+rG9HMkagmm3agJt+Fs/0IKrwBQ3QOg/gxAOwagexvAmI3pNIDlGQDbnwAc1wK4 ZiK5LwEkXQOQfBzAWwPgSwBIPQSQqWV/W8lX5yZ+uAQ2gQL3ZBPks9/GEB5UrGTfn2PvLHr/BA+u ljnLch3W4jAFFWyWYQEccIMMi1NwFKCHu2VYiWr7oAyrYCU8IsNqsJHx8TWQQGwyrCVGpDAO6yCJ zpj4a8w8ulCGDTSBXifDCZAh3oqUEJGtQC9GOcxXJz7DYSVvf5XDKt7+NofVHP4LhzU40mnxSxkm 4FC8LsMUEhTnZFiAHMU/ZVicgqMAlzJFhpVgU86UYRU8obxUhtWQqRwfXwNJKkmGtTRFVS7DOijV rJJhPazW3CXDBsXPNH+X4QSoM+7msHbKenVsLagRDNZPaU9gsPFDDpvYWoxx+q0IW0zAYdsUfDsb x2ThsGNKu5u9a/JzOJHjFHA4eQqOdwqcyvHDHM7m8CIO53J4NYPVU+hXT5lLP6VdL69l+dbuyNrm 1oj0iLR8fURa2LWxqw+bpOqunu6unua+9q6NUndHa55U09zX/H9BkmaUlRXkYlacJ1V1dEjL2tet 7+uVlkV6Iz2bI23VXf097ZEeaVFky7LIuv6O5p6q3tbIxjZsypWmdF4R6ellIxbmlRXIzdg6jtDe KzVLfT3NbZHO5p6rpa61301ST2Rde29fpCfSJrVvlFojPX3NrOzq39iHw/XmTZAw5cX5XVuae9qk BZG+vo5IT02kt33dRny/mc+Mk2zpaccRJc62tV090iVzF+ZMLGALovVEpLae5i0bpZatUlVbT3vz Rqmup7+vfR17K/6CdHmkI9KKNLRKyB1GiSRVsdHbW5s7pLXt1+CE3e19reulNj5/jtTJlti1McLW sSXCWCs1b2yTejuaW/gQa/kCuza2Rrr7cLAVvThCX5cU6URO90WmEt7V39fd38cp6Yngovt6c6S+ 5hYmEWlLFzKVjdsXaV2/kRPT1tXa3xnZ2Md5k7e+r697dn7+li1b8ppl3rUi6/Jauzrzv6uPzR9f CooXR+nsuKwdUXojEjK4tae9m40+G4WJAl7btbFP6u1a24dyiDCJ96GINzd39De3dESk7p6ubpTj Vib7bxIfIz8f19aOutfb393dgWLp5WtiLf04I4pla1c/G7i1azPXjX4+CJsGGdTZy4ZuljpkApvX 9UQijAN530KejMj5zQZmYv8mwhjHsb9HQvp7uzYib7Ghpb+3fWOkN04ZIvV3s2HWtm+OTKIhA1Fi jHFSA47f2bxVQmXgb/RdTBEO0tnVw7pQ8b5lIFxxB5uUkbu+GVG6WphlMDWfWPfanq7OyYUgUW1d OEmeVHsN0zFmD73dkdb2tUxLOraySTrb+/pwCFw/Y6U8Tg6fZJzm1q7urd9A9HfqVQRVc0YBVxpY BF3QA53QDB0ItcBWYsAz0wbYCH/FNNl3OfRhuRHaMO+BNuF+4aDwrHAM02HhiPAYLIetGBdEYC32 t2Ip4f4pYet6Di/EkdhofTKWBNV87G6eN2N7O8eQsKUD389DqIa3N/83R5JgBpThUwC5MlTMR6/C 3g4slyH+Ohy7D3p5LYJlBEfajHkbH7sfa+28TUJuRWALx1qH7R2cF1X4Blsx400cK1em6uI3r+C1 3gkaC5EWRtt07DjuhSO0cwoZP/r4StlsnZyCq7GtCzn/3+FSD18Tm6OPz8dWz+ZkOK28hclivM4o 28jpaOccy/sGLnzzjPMx3xLXIcRZgLh9+HTwd2r4WEweG+X5m6esOb6SLXzOPnmOSW1by+eRMGKc i6vP+QYJbJFH6+H4bZyqLXw97O/7mUa0cexm3laHcD+net3EXFNnkNAiIpzuVpkPjItx3RnnicRH HaedYTRznVuL8DXyCrv5alpRbhLn3Pj62Qo6J6TYxTkyLo8tCI9rrSRbJZub6WPLFCrWTpEgG4Fx qhvfiVO2guO1cfq6MGfaFNfpPj7XN3O8i3Olm+eTPOnhI3dxLenltPdxWsZthNHcJWvqOL19nHfr sTbJmTbEasW3Orkm9U3Rmzy+WjbzbDwL5ON47MnjMp2qd62y1uVxqBMx/9++N77+tmla2cMly8bs RIqZvcXtci2nso9zn9lin6zlkQnL7ZNtczNfaz/nTwdv6Ua8Lj5XD5913Jq/r02N8zRflka77M16 cZZubuHtMuWT3B/H6edaMG4DW7l8xylmnNg8xRv0T6FkfDVxvejk+HGqmbV2cJkyyuOjNyP32CiR Ccnmyd7q+3Jv+oiTWjtO8bgNf1+OjWvuVtlLSDL/e3l/XBvjGC2cR+1c+r3TeBYfifF4nBpm2Ztl mV44Wlyv4pYzrkcSNMj0M0/OVhC398k5+r4Xj+KUdHKKx99qltf5X6EoLuOOiZWOc5eNtlmeqWVi Jxj30RfLey3X6M5vlEicU208Z9QwLtSiPxz3TuNev5dT3Mr92LiH6OA86pZ1rp1bdpyKuPzHtXI6 PTlTVnIhn1u55W39npzOAy0+l3A9v5g3jONspE3YHuE7aVzb4h6xm/O1WeYQG20zt8st30r3N9nN 5Lw9nDsRWb5t3Me285G+31pyLvIbrTJuM9/Tvr81MQkyvlRf8P4lWFs7EUOOY89GzO87shZWYn8L 5/L/F97//44fkfesGRiVTfr5ySi5mctovP5nmB5BR6bFyfEoZ2o/6oeYIs4QF4jzxDmYl00biVnU Iq5NLLqLa+h6EiX/UwCsrUOu9fCoJM5jIX75NRbg/4OGXHAfCEdgeey4cHxwRVF4GIvZvBhKSC0c YKXOwMtBTVFlVb5wHLoxHcB0EpMIazDfJrcI4MW8EhNr3cX79wlHIYrpOKY3MLGWI9hyBFuOYMsR bKkUhoEITwtPDaZ6cepDQ+7Uwk+rPMIQxDBR4U5hJ/hw7Kvkco1c7sIyG8vdcnm7sHMw5DVWabBO 4FPMY5goru2BwXmLCw9zYFY5B/aOt+wdwhZvlVt4AKl6AKl6AKl6AKn6FHOCo+7F9r3Yvhfb9/L2 vez3tnAoX5Y8lAw8MGh0yC0IVGmFBuEKjNu9Qr1crhSuGCz0HqtqElbg0Ad4vk9Yjvkunq/h+WKe b+O92zjcxeEuDldyuFKGWZ4/Jffy3MhyYZlwOWRhy1LhUl4uEWohDcvFWGflIuESXi4U5vHyMmx3 YbkA8SxYXirU8folWK/Bcj7WWTlPqBus8RZUdWN9DfZRnI+11yANNUhTDTKJtezCtA/TGd6yBvNt mE5iEjgmEWrwqcanSqjCN8I4Rhh7wiAIYXwq8akQKrBnDuLOwTwslPM1liNWOc5Ujrwqx5HLUTzl KJ5yUAnlmEtCCRRgCmNagqkJkwLHycH3cpCuHJwhR8iFVBzLR28DG5aSXHrpTkjBMoXuHEzxhqs0 9BAswdSEqRvTAD00qLAYq2yIx3DzMS3GtAbTNkwPYjqASQ2V8Z6wjlbSSmExXSyIqN1ZQ+Xlhbws mhkvk5Ljpd5TaKzqEbKQTVnwICYBSc5CkrNwqeM1LyaKqpMBxzCdxHQGE2N4BjIjA5mRgQvMwPcz OJaS432KKYZJQCXKwPGn4yj4215M+VNGYa2Z2JKJtUx8JxNxM7H1DOaEv8H6l2DahemY3Ofnyuzn yunHsfxIbT7mlRwyYu4V/INUYxxG/pLZxqpZyPfFmLCT3o7cvB35djvTEMqMOB97KmWMXZgOYFII h/HJwicDn0x8/Pj48JHwQQkKKSi93fjswucOfG7H5zZ8dqI0bAeCx4J0TUlXybaSXSUPlhwoOVai Okqb8WmiTWEtOBzoEi1mtafKREVYDQbyL54/zvMenod57gx7VhvOrTa8tNqwZ7Xh3tWG+tWGRasN dasN+asNw6Ql7Awa/hg07A4arggaZgYNJUFDUdCQFTRUmUkDWQkG+DXP5/K8kOd+nieTlYMG0DxD rgSfGjWeZBzy3eT9wDcskkHvD33Daix+EK9dGS9CrPEpb4FvnTcn3pIeL1J9z4o4Aqwgj4GKBMM5 qpdVa1RhVZkqT5WrylRlqAIqr8qmtqhN6gS1Xq1Vq9VKtaimalCzv8QKB9mOYVOaWKEUWS5y2ETH /zUkbiiUqClcClGrsIAuuHwuWRA93goLWqToF5cHhol26aqoIjCXRC0LYMHyua7orOCCYVVsWbQ0 uCCqWXJl/UFC7mjAWpTeMkxgef0wibGmmxPZvxs6DITk3Hx7olw2NLB36g+K5PbbG8CxudJVaakw l9XVfEPWJOdTvlF1Tf16lVGSHL1vweX10UeTG6KFDIglNyxAzrH/TnSYltKZtTWH6SxWNNQf1g7Q 0tplrF07UNMwiQcSttccBh8rOB5IDA+kC/BS6CyGl8aKOF4Kx0uZhndwjq+25qDPN44zh+PMmY6z bjrOOo6zTsYR4ji+KTiqs+DjOD7V2YtwUr4HTto34kzhZmTuxV9gT37IYbiUnD5YfS37105NgdoI pqbozs3rXdGBFkk6DNXktPxfn9KbWlrXs7I5MkxOByI10epAjXTw0msv7o9ey7ovDdQchGtrl9cf vDYcqRm8NHxpbaC5pmFoXnP249Omu3V8uoPZzd8wWDMbLJvNNe/xb+h+nHXPY3M9zuZ6nM01LzyP z8W1HtVSDXMbqlfHyyGq06ICNyX6GuY6TN0VXJtDPteNiUdEIL8CXbAhqg/MjRowsa7cqtwq1oVW xroS2H/wkrtcN4Z8iUfIr+QuEzabA3PBVdtegz+9vTLwPX96e3v7ruq9qpeV/Ke3rx8T/40DPM71 Aa6gSs/3Ny96Y+abd2K6jftoobe3oS/+iwm9/cBG62PZ5OATUD+OTHqn/T5D74UfphlBiCccrref 8N96QEBWm16CnTgMMCLlUQD+D9LzKxQKZW5kc3RyZWFtCmVuZG9iagoKMzMgMCBvYmoKMTM3NTcK ZW5kb2JqCgoxMyAwIG9iago8PC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQg L1BYQUFBRStBcmlhbFVuaWNvZGVNUwovRGVzY2VuZGFudEZvbnRzIFszNCAwIFJdCi9FbmNvZGlu ZyAvSWRlbnRpdHktSAovVG9Vbmljb2RlIDM2IDAgUj4+CmVuZG9iagoKMzQgMCBvYmoKPDwvVHlw ZSAvRm9udAovU3VidHlwZSAvQ0lERm9udFR5cGUyCi9CYXNlRm9udCAvUFhBQUFFK0FyaWFsVW5p Y29kZU1TCi9DSURTeXN0ZW1JbmZvIDw8L1JlZ2lzdHJ5IChBZG9iZSkKL09yZGVyaW5nIChJZGVu dGl0eSkKL1N1cHBsZW1lbnQgMD4+Ci9XIFsxIFszMzNdXQovRm9udERlc2NyaXB0b3IgMzUgMCBS Pj4KZW5kb2JqCgozNSAwIG9iago8PC9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL0Fy aWFsVW5pY29kZU1TCi9Bc2NlbnQgMTA2OAovRGVzY2VudCAtMjcwCi9JdGFsaWNBbmdsZSAwCi9T dGVtViAwCi9DYXBIZWlnaHQgMAovRmxhZ3MgMzIKL0ZvbnRCQm94IFstMTAxMSAtMzI5IDIyNjAg MTA3OF0KL0ZvbnRGaWxlMiAzNyAwIFI+PgplbmRvYmoKCjM2IDAgb2JqCjw8L0xlbmd0aCAzOCAw IFIKL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdkEFqxDAMRfc+hZYzi8Fx1iFQphSy aDs07QEcW8kYGtkoziK3r+KGKVRgg/z/E9/S1+65o5BB3zi6HjOMgTzjEld2CANOgZSpwQeXj67c brZJaYH7bck4dzRG1TSgP0RcMm9wevJxwLPS7+yRA01w+rr20vdrSt84I2WoVNuCx1EGvdr0ZmcE XbBL50UPebsI8+f43BJCXXrzG8ZFj0uyDtnShKqppFpoXqRaheT/6Qc1jO5uubiNuOvKmOI+3ndu /94jlFuZJU/ZQQmyRwiEjzWlmHaqnB90am8jCmVuZHN0cmVhbQplbmRvYmoKCjM4IDAgb2JqCjIy MgplbmRvYmoKCjM3IDAgb2JqCjw8L0xlbmd0aCAzOSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUK L0xlbmd0aDEgMjEwOTY+PgpzdHJlYW0KeJzVewl8lNXV97nPMtmTyQYJA8kzGcI2kISwDqDMkEUk ApHNRNRkyAwkQBYzExDQEhWKBkUQtAq0oqJVcZk8Q30TkKVWra3S2tauWouK7WtdSt2rwnz/e59n shHftu/36/f7ffNw7jn33HPvPfecc8+9z0wgRkQJ1E5yZHvduqB20aJh5eA8Q5R43cqWVY2HJjcd JEqaTBSzetXaDSt3jH/hOFHGAci01/u9vheSczWiTABNrQcjbUd8EupVqI+sbwxel7SEbUH9etQT 1zbXeYlYFuq3oG5t9F7XYv1pHG+/B3Wtydvov3LFiudR7yIa+uuW5kAwMpVWEk3YydtbWv0t7769 twb1EIb/AYmPeoSyUT7My74fJd/gRP7Sn3++nnN4+WU5ZSt/oSTph5GPMUoS/dufWBP+rz+30lwa Flkf6Yr8mQ5SLSVFroociHzMfiy5+oopASVAV0UO0k/oBD1LXXSYHkNJwESP0t196NuIpPVoPUBP or6bHhZtuwFP0kPGaOwatpp9jzWzZcwzQJ92wCk89XQZsw+i7yN4DtAGULfRjXQ9npdZNtXguYNO SC20SY7FXF2m9BWRRwVupEUA/lkGuDZyByRO0ct4iG6C9m0spt8s2+ga2oqZ7uAxYH7G0uPSE9JG qYntoGukdtrPjtHL0uP0pfQYNUkLaZ8hpjZStrSVYuHfw7SLvkW3Y+Z7KD9ylo6gPpF+RCPIze5C 6yOYZxnNE9T3DJq9RvspnobQMPJF9lNx5Ge0QDx78OiwILf9A3g202b5gFQlb5bKz/1azod/lkVi lf0k4bn7/ARqoCAtUxop3pJhORj57Hyt3Mic8IURuw9Dpw8ogPXfS3uphXaI2qmetV4E7l6UK2kt zZPT6RH2e8HfR48LLy8ln6g347kVXu1WDih6H76XbkD5W0BNDzWU7DSBXFRJK2gT7US09f/MoHK6 EhZ/cBCv76On4fWnEVUPwFZ34xn88ya9QbfJK6lS/pqmsJnQbYz0GLsR1lgql1ILe5gq6DquH9tA n7Ah5KRf9ZljF3TdEHkz8qF0nNLw/AyR1ETPA/p+9kP73XSnWEszvFeMVQ/2WYFnLs1lyXjGsrGw TLF8UN6N56DaRitYLr0hP6dkY801vA1ri1LEfs9+Luvyo+wV9gd2hqZQIeJmhnRcekF6Br76Emu4 THoR3rmRWiy6RWc71essfI+tRHsbLaeNGOmgcg11S9fQzch7T7IaU6seSumiCrmFHZH/qJySVjFj xxTTLFjIh1jgXjvwDbw31BNUrgynd2md/BIs8BP4dB2bKrRvEnLbYMt99NBgPBMfAPUUdWM3nKL1 g/DWURl9yuLYtB58CvE4A8/XWPcUPP+pzxZkl2W0kK4alFeOHWF8WqgOcdV3ZU8NyiuHda6EFaJ4 KWwyUIav+UIb0KC8wfoOxtsnh5XtynY5jKgYRy/StYiGRbDf7Xh09hy5abqyTFn2L9tlI55mqoI3 K7CSWsx3E+wxj6oGyF09iDYDOfzjQ9/VVMn8iO0m4lmbn2jfpR3KG5TGwpRPt7BMuoUYfYf9iUKQ mRMzht7CufoGXQL+t1g8nmGI7lXI1ufQsxo78gHsozZ46nZo+C36Dt1MV8AndwIKEFOXkZXuw0gP YxfNxIy/pd9K5aAH+VietuyhDEuauoKsyn3Kbnk1Zv4q8vfIe+c+7CfI90fUtzzSr4ddbkOGOgBN DiOXJ7Fd7DE6foHcdf3k/sqWQqtHMF7XYNr8Lz9TIz/Fyq+MPEzn1UvJAQ9Mw8wPk4+VYV8dOPdr KmZ3YO5a6Ydf7zr/e9iMyAbt1uAEulqKk0n5ofw+tDsgNH2dHaEOSiaVZsuJ8hvIb920Wp3JdtFv LEfYKvRbQHlsvxwDG8TT57BvFZUoSaA/pvXSE6RKWWw94qOdttOb8gEawq7A+fMzab4ckG+S3+xV G3HQiRy+DFosomPY7z+h/6JF8jmMdxAWDKnf41KRv+KWsA1+Xw4uv3Fcz1Ss6DapSCpF1j5O86S5 0nWIiCVSFeLgZzy2sAsOGSdPTLI5017YZRMy6V04De6k8/DRd9gq5Y/Qmlgqcu0mzPQZRNdj953H +MbnGljiRnEabafRwKuRF2ajfzPOhzN4jJvKYt67/0edYs57NzSeh6xyM6AB1DXIb+Plp2FdYjXM jbOLIj2RZs57P3tIGkoB9gj9EhF+HXxJFgUnER8vA7txJG6eS6FZBsbbD21WK6/An/xzNU2mFyPv gDoKi+44/13BvQh7eZ1URg+w8ewZ2HIE/RmZQY3MiXyFUffivByCde/FypYhcirgDT/GHkXTwd1y YbgpVhondKmC3eYhkl9FtB8EfQ3OwWz5J4QbOHtQniVtxNr+Gx0q0bLKXNs++Y84604hhm7EGm5C 7wDrkh9nP44ZTj9kTw16L/g3P5ZT/HSN5bfMKfDtGKyrhSXjtlJO+9hM5XXiN851yBAzTNuX9rH9 Huh0EFZ/HBKLpOHUCR9dBwveA7vtoO9jz8znYjELTP+2YO0rkYc3oWeHoI9J49RnuA3o+2wocpRp A7lYyjHnmI6x9zAL7gZboFUA2fFO+VPMsoTaJdxf3e5Fl869aOYM1/RpU6dMnlQ8saiwYMJ457ix Y0aPyh/pyLNruTkjhtuGZWcNHZKZkZ6Wak1JTkpMiI+LjbGoiiwxGs+yQlklVWWrQ9kltaFyR6nD qoXKF5ydXxiiNJvdkapNKqyeYEqFVGeI0itCGZVVneSeXh2yOAeKLAjJ+daP7Og836aVhZR8/HPM 8/pCYxZV2R3W39h62qvRJzSspMput4WkfPy7FE34N8+r+ULWSvDtNoNzaYgqqzh0Rd6aDiZNt1ej XFQVyolWq6sHU7IbFj3Zo+YkiCxgHdbO8uyS0hBldFL5WyHK5EJnp+M8mRUa44QaVlBiLCoMsYyP Qiw9xDLnQ+H+E/Bup6cPYoEy32pHma8B9vTV9lr0rGFPu9ahdSyqSp0EUqhcEXrx8qrOhPgSR4k/ HgwSDOqMTwAngTMwREsnK7+YCUIqL5vRKVFsEoyXxtUt47A65N5eC8JRCquhJb23pSty8ra+TYRu USrdoAwlQpaSUIyhhNYQcntDtF3rHH+y47YuK62odSb6HD7vVVUh2QuBTpLzy+qXhIZXVF4JFqYC 1NZr3NmlouCu08rqtQ7UuWwtSkcpd3k/vq/eX8uDhNU6StEWV1K1zX7SFkoDLgulOkOXQOySjWds ckdZVoPGqx0d27TQAajbp9XOS4RAFlTvKHNgNgxWtnoOd0lhj9tELF7qE85xb/dqofYVq43I894W jX57hzVU/pkd3oF/0FN0NE3pq13NVV7t5cssW611bPeLpd4mloZo1cpWl3LgHRH7tBS9r6wqq3eU 9U6IhYOQ8wf2tdtD2U7esaOjjKvo9UF7Q2U09OrPd4TNyaBPSci9RCBaInyAGd3e0mqTZQpcybvx ltrS6mq74XeIhmLyt6kFDq2DjxiTH8pwWu3Poe3khPEVi6rKSm1i9SGppOqiD7JsH4CuqOxhsyzI dBR+YDNsVLHYUXG5EQX10aJ2ibF9pR7PQ9SUF6OeyrKdAl3uKK/t6Ch3aOUdtR3erkj7CodmdXR0 VlR0tJTVamLfM/CPbLeFym+rDllr69kMOJnHW/ki7plyrd5rZInZDvt0mz21Otpc+U3N5hZDsCPk +RbrsL4PtRKRimxaOc8rXUgItpB1Ot+hUGJpFbZAnQhXUWBrLMbgNr5J5Or8sobFpm0QiGas8IR3 ucnFIHY73z7bu9y0ApVQ++VVRl2jFTad3IVOuK2Wt5yMtmQu5S3t0Zae7rUOuCmrYvE/Cee+odyR 6kjTXIXC9CLP+kInl2CNX0wPxU43PZ1eUiXbJJOSbDKn4p3IXLNCQ52iI7cJEmSH1aG94ghZnSG1 pOqkbVa1Zk1FZmM9cWCOyCPU+orjJ4znT8qwhtisEBvC+YR8KpK6PHQ6Gns6amUdtWaE8eXBd8KQ oXeQTDrfodJq+4CVm4eDr/7C5Sdi+ZCxOkKJn9kM+dQ0BzfCy2ILDAyMgdpXLOmhFlXdYNtYjRsV SfwLyhjCe7UMZHMnxDCFkSrHKRRrfeMU/lHhpFOFpyYW2VPtqfkoGIS/bFfpK44JRCRCc1iXVC81 SkNIwnAsWseYqU+zfeCpUmHqpEIq/GBiEbNPsUv15/4gjWJdPyAm5OmZsY+MrUmZ9SnZjO/7Hnh7 xLMcd59/uu7zd89dnZYZe0BcOJjoIfrE3s7vE2npn7/7pT0t0+T3fmQuLD1GcziYPH7TWUL8ZsSl ZXYtbrW/o0RobaVC3GPJ6oyJw92UtxbhnSk65hFjRlFaUTNoCRb7qUnLuIH+wqQVyLxv0ipG/9qk LZTMYk06hurYEJOO4J1jA0ZgiowxE6Wlgla5VpJX0BbBv1bQMYJ/g6BjBX27oOOgXFD6rkkz0pRU k5YoWZlo0jJNVWabtAKZNpNWKUu5y6QtNFx5wqRj6AXlJyYdS8XqHSYdRx+qPzTpePrQ8pRJJ9DU mKgOidQS8yuTTkr479gSk06mlRlOQcfzdWXsEnQCX0uG0TdR8A0dkgXdLWgrX0vG84JOB52WYYyf IWTeEXSmGOfvgubxmJjJBJ3N+2YmCdrGZTJtgh4hZAx9cgU9TdAjhbyh8wRBX87pWKFzZo2gjfHX cDrR4K8XtNA/8+bShlUNwYaNfp/m8wa9Wl1zy4bWhlX1QW1MyVhtoss1aUJxUVGR5lm10qvNb25q Dm5o8Wslza0tza3eYENzU4HmWbtWE10CWqs/4G9d5/eB2drgXfuI1hDQvFqw1evzN3pb12jNK7Ul 9f5Bx9HW1zfU1WuN3g3aCj8GWtUQCPpboVZDk1bnbw16gVe3tTYEfA11XD5QIKbQljY11DX7MObi Rf5VbWu9rT2DT9AGSgysL/O3BvjUEwuKJoo2s8mU/M+qv6Qeo69saPJrLa3Nvra6oLaitbmNWz7Y rG1obtNWbNCC9TCo1uhvXAFN+fTRqUeja3NTMNqVKxD0extnaHOgeBN3ib8Jx/E6zKzNWdvsbww0 esdr8/zga3OaReUSiPhw5fdrl7RtbPRCfF5zoL7Nq831+tb6N4zXrvCuXeut82tzm8drFd5GWG6+ tynQ3NY6Xlsc9K+DHbzBoD/QjJ5L6psbvQFtUUPdmiZ/a0ESXh2bqZUa8eq0FtQK2sCS8MK6mpro XUBv22IKAjeRD2Ur+eS9cqd8TD4B6JaPyI8jGTbQKvEVegNtxAg+0oQs76VRHUZqoQ3oyaXqwdXw KllCY4EnkgvPJLw8F1OReDTyQGql6DkfPbkeQfRuwbgaenGtWkTpFfNxiQLRay0erc8sAVHzA/uB 1wm9DEkuw9f1JGoNQo7PFhRj+iDXKNa5BrxmaKIh0deL2f9VfTS87teDrkOpidE2AK8QPbhGq8Ss QaGXYa0G0atOcLjVjPpqahO6BiDDR4uOH8A6eleh4fW/SbQ3C+25novFVw+r0H+tWMuFmk/oZ4nB x/hn7cuEvoGeVU+EXkUoe/v179V/zP+/rf/vxuhCMzL52IZFfSI2Oa+JZqC+SOxBY+4Fpv7Nwn8B Gg9epRitVbQ0iLkXo2wT+9LwA4/uMrpOrM3g8tWtwhhct3pIzBhU4yU9VKnQeb3QYhXqC7HKlWJG v9Dhm/o2Q5r35LNsgB5LhAe4b/0X6LNuQNQYXh448mjRu28E1gmJqH8CA1amYRRucU1IR+WNWOX6 NYi+AREdPFPVm5aORtfA+B6Q88TqB8Z7MVbKY55nmyBmmYGrXyHG508B+hkx0jhgZQVilsb/Za9C 0a8RKyzsF0FcsyinRqzNJ2xf0CPPv1heAI8uoUupHFAC63J6Ibjc0+UoLxP8MnAWo+T2vwRxyb/8 ni+4S8QoHHo9HNWQa10nbBfl15vWbxUngLG7NnyjxwePJc30gia8xsdtExmd72jeugHybT1zchut 67Oze3dHrz7Gzm8U8oYmfC+tNaO8yRzdK7Twi3zkF7HDd1e1OVs92tcJOb5nozFpzBn8HywTEDMG 4WmvGJ3vjwZTs1aRExoEn2ebtWJ9K4X1Gge1V7O5Lm4xf59RohE+2Hw+M/vxfbUCawmaWq8wPdNk jjyIh7Rssar+lvKLvHNhVFw4c2+uXyf2aBvKFcCGtQNitOA3RkeBuUfXihkDfTzf6wvDT/3zOreO MWtAjMNzp5HR/hWfa2YsNok8buTE6Lz8tPKZt57mnqze9/4xvke6tU/cGusL/lNLce0axfjRuGru N9564f81wpt9T79oHuyVbIZsk9iJbcLifPz6nvUYevWN7uiZadi/9wYXjbjBYuh/WlFvfFwq1n6h 57iF+fjXgu8XY0dXY2R942xuGuCDVhp434uOHBBnJ7/9+Mg49ddBzg+NevPAv+L96HjGnuR7dZ3p jd49Fh3vQj8a1uo9t+rEmBfu496Tq7+tV/5b2vZa+cIZ6oSFo7eg/hoZ6+ERNKNnhKXipqbRdJpM 03BXnIZzbjpwEerGLd14llIFysl4xoA7FlLTcJufBt40mkpTcLfnEB213FznwLX0zcjRbM+j0ivy 2oV7qkVkAa/Ze52IugYzd0T3hh9r1Uy+v9/6oiftv3LCRtsKB+jc/1TlcJn57tOEcoWwqRGrbaL0 C+u3mWtbIPbMRrMtYEZXvanpyp7Tm/dZLOJWEze9leYYATPH8ZVeIVYaMM8R/390jZU99m0R+Tsg csFooe/KnvfF3nvywN3rNXeVkcN531ZxMwv2jNQmehsZqm9O8/frNzBL9M5kvEXwqOYSa80e48m4 dbaJsTlvY0+PgMgSQZNn2KrV3M//LyzqFRpH7xF+8yanDbApP7U+FpbwmtasE718Zm5oNu8b7wr5 BqFhoE97VIvom8OGPr18ZjQZ7xu9vdpERhvfb4f5hY2i1m8VJ1Kg5wzUzJj1i5PwCnMP+sX7zX/S hn4zq/TmNp/YjUZ0NAyIjqCIDq8YV+u5KUTvXg2ivaEnHi+0gde0Q4NYpWHp/rZo7pOBjLeR0eae NmYw/jToP2WT/+m9YtW/+Gbxz2fq+91RL21YdbC2Nwf08fd7wzLesQYfc624G/SpKznKRKVCuUS5 CKWr3wx893zTKAvEbcMr/pyoWbxZtopsyrX45j6D0+J7euMr90l9/ua1z8cdz4jlsHJGcewZJUyk PEtutjWcZnO5u9hW9+LYONefTg8ZOvzVX6PYdP0QW82m5k2bN8mzNy3cJG26PvsXvwR/3XoUjS0o 1jajWNM0xLawqaapuem+JoXWbF7Tvia0Rvn5GramaXPrsIUem1TAfwlAaQVogNOAswAVNSe5ARIV sclQZTJVAmQ2mU3RMzKHd7NiNsk9FVSwDcWq1ShWNqDw12fYNtffUf/z+j/VK0V+lutn/vqt1w7L DgzZWJJt3wCQuiOnLXnhpBRXUZfFHk5Nd031FFiGQ5Xllhn0KkCiBNSTLHZAIY0AHgE8AeC0TKXt lvF0D+B5yMSTy1KEnuMtY+ghy2g6hNph4KPALwEslumWbF1yurssNj0xxXXMYrNkwt5OywRLmi47 tS7LED0jC/xplqGY12nJsgzVFecSTxzqjG5Fea9o0SxDwwVFLnQYGh6hGTgtw+WE4BSaCZAgnE7M koGBJecyT7YlDbURlhxLLiVaki0pFivwWMs4ixPLclhGWvKxAUstMhTmv79o6od6WrbLk2aR1POk QJU49V3EjVP9m4m/NPFX6juYQetS3wkPsbkuPaq+w392USP60GzXMfWsekZIfaKeMaTO6BOKXJ4h Fot6WqwwFphbIAaYC54DxnTq10Z75LT6VjgxGStUT4cdow2cNtSV4MlR/0pbABItVP9INQBJfU99 X/2AEtXX1T+qb1AiFaqvE1M/V79Q/0FJ6t/Vj9SPgZ9WD+uq8zlPunqYXgVINE49QCPVx2kyoFK9 j2oBLQALudXucOYwl80Tr+6l2er36LB6iD4FKFSk7g1nZiNs1IP6NDdMpYbUu7jO6kET32vie0x8 l7oTXkaH3XqmzYXAU3eHUzP4CN8JWzNcpcfV78B2G9THoPRj6t0wWIUnQb2blgPWAGTah5JFXlH3 hFNSEagJqo4O3+al+qS6UxjwITEJ7LQzPM3lEljL43Ps0jEHn3QXj/YEzzCV//C4nJfqPnW/+l0Y 7jb1dnUHDJeg7gP3++oj6qMw2P3qA+qDlBQ5qd4UHu10qZ5E9SZ0/VSU8SqOFICkNqiX6jl2m2eo 2kBXA9YANgG2A1Qapa6imWojVQD8oO8CqLBvbTgh07XpqLoaE7aplUaUVIeLp3Ldq3VE9zF1rVop DFipzjMMWKMnp4Jfo16DMZzqQnURtsm+Y+oiOgTg4bsmbM/nI6wJpw3h2KcXFLu6Vb+6ACN8+yg6 8ii9Rh8xCtx56nzMm9UFVLzJ5ZmuNqnNlKy2qNdSCqFG9wIeFdACz/OyCzWJrkcZRG078F5TRkVA NiEgm2AA3FpEjxRQuQAnYCaAcy6hh9V6jOFWL9Gho2e+ulRdpl4BL5Srl6hz4QWLuhRaKmo5+nFY irmW0kMAlV5C+Rtw31P5D6UpKKMyFYDloGuBNwEfErCU4lSvukKtgz+Xq1epV2O729TlCP3l5ALM BSjYDm7MWKpehK11Ee0ByLBSiY4471ZnqQ7sG9hyXDhHc8FazrBmd809oY6B68aqI4UrRqv5hlCx ruWj00jURTjmh10zuSPydc3hwnaaqNqpmOxqUQ+eCB8mHFMnwm4TEU55Yrpqz0TVQQ0ASZ2gFqiF sE+OmqtqwC51hjoT65mkTlan8PuDOgHaxylnaaPyCXUA/qzG0Wcq/2F3CmplgL2ARyHxNLj/UDOw xTXl0/Cw4S71uPIZepcpn4rIyAwXTHTFeWao6ZSt8l9Z16kpdKvKf1edoXwAJ6bA0ClwfDr2XyYC JB6bM51i1GTlfRGrSSZOBOb7MtbEFhOrwDzRyYac8jeDr7yv/BkGW+fJVK1Cna9pKUBSrcqfUXeq CjDvJwFz+b9CnmCmUaL9VlHuRfkYQFL+rnykfEyJylvK28oZhNSlyltUDZCUc8p5JUJJyufKF8o/ uPGUn9PTysskRU4rL+sj83mqADF8hEkkWl2eccrryms8XSuvKS8I/AflFwL/VvmBwL9UOrl2yi9M /GNFF6s7pjwv8H8pPGM5lRfRzrXXlR/osc54z3Dld8SU30GHGHB/rzwnWn+j/FSM8lNII7iUF8xe z2A2jo+L3loXEHa7J1k5AQELGp42p+82cZfSieCa7klFnSlh5TAlUwpuNrmAuQBZeVb5Efa6VYkL O0a5FE+6cj9lAF4CvAZ4D/AVwEIKyiUAKXJSuT+cluWyejKVB6gS0A7YB1DoJMpXAJ8AZOWAch9l Y6775K/05NzNnmHK9+gOwH2ApwAnAD8HWCCzH1z+X3tGKt+lLYBXAXLkFeWecFyyazm63gP2PdDn HjoLUChB2Us2AJKecje5AbWAFkA7QFXuUmL0CnuGx6HcQXkAn8L/esGKUgMUmZxWQDtgJ+AAIASI w2J20yGARA8re2C4nUqePi43wZOr3Ik574Rh76SZgH2AQwBLP+5RgALOreDcijGWKx0YY7uSrI/I /eSocpv484zbw0NHuJLguh2Q3AHJHei7g24AbAdYYOVbwvFpLvKkKPw/CCjKNioFLAHsAZwBqMqj yiP6yNwWT5ryCGR2inKychOkbqIgYA/gMEDFgm/Q517uOqbcoORRFgx+g1Knj831eazK9RC9Hnpu QblHUHuUG2GNG4Vtt+hZw9Fti5Isut2MZYzNTfGMVtah2zrMuQ4eX0enASpiqw1atqGlDf5/WFkv /P+QiTcB5wBvNPEGE1+nrNdzcksRfOuh+Xqhynqs5D2lGWUCShvACZCxJVvCcUmuNZ4qpZU2ASSq UAKwWYA+AHwFUBDBAQwUwDoC8PlyZS2tAUiI6iZENT/ASFmDWFgDyqesQriuAvUqyjOCWq6sRI+V 4K9E/xqlgV8YlHo6ovCDa6HybWoG3AfAEYSyELATcALwJ4AKA9Shzz6UhwA8t6wIpwxzXeQZo9TA Q7VQugaWqgV4MVUNllKDRdSgSw0CUFGuwiKuwm64ig4qV8OHV0P5q6D8VbDKVRSLQL9SxFF1OC7R te+EUo2JqhF61bDRSWWMPmasC6kxB87Og4VzgXOBNeBCYDtwADgfeBywA3gs8CjgRODRwNxjYwwM 9fN03D6PKXkIg0owTioZ5hTx4PApEoD5FInARcBJJk4B/j6wFXgGcCownyoNmE+VDsynykBgZeYm HEWVYb4Cfq9HhkvWkWq65X/IXyBEUjxN8seUIn8O+IJyQRcK+AzwOeALGOr78OH38UqiyV8Skz+V P6FM+Qu0ZlIC2hndIfOTYjbKhYAaQDNgH+AQAKlI7kL7ELmTggCJvo3yJUHdK5/CiG/L/C+TnPJb 8h8EftOsv2HiX8tP8owvv2rin5v4iPyswD8w6y/IzwncbdQjp+Un9bR01zH5SQxkEYwz+hQXP4VA 5I0G8bp8JpySDqvIfwgXzOH4pfDwPJfPEy+/A23fIUl+Xv4R1wJ9fqTbckTn53TnBBCvgJOYisNC fs3U9HfAXINfmfgX8hPiFgoERY7LT8khYbWniElL9ZJRdk+ctECq5AeLVCEtEHhuuCTH7vYkSHP5 /QnlEsAeAKIQjXEJrvc8ifxv6aRKqZSfcRihlJ9pkVekUj0rmysmefQ4LFzySDP5WQqGW88fLVrc +pARri6gktH2Lml2GEjjGCnpKLSZjUkPSxfTcwAJ4hfrQ7JEv4t17Ipj0gxpGraKU3JJ03BeFnVJ 08LFLrzLy/5wTo6BsVKBExJcRceksVQLwN2UvaPHpbq62Dvhp2Sn2xPH3uKhw3ajrOGl9KxYeJd0 JByf7Eo5KvF3Crd0WMeKuyMn2YRwdo6r0JPKJlA74DQgAlBIQxkCnAXIKJl7FHNHWO35A+dfOX/6 /NnzatG52nM7z508p9DXRV/Xfr3za+XrOWPsCVjuFWQDHAQcBijSonDJBLvTkyYt4vkJ5RqJvwQc li5BfYm0mIKAQwBZms9FYYD54ZQ0V4VnqDSfX0ekeShHCvGjKN8DSNLlUhmPP2khsCLcUcYddUya Kk0W1pwiTYY1E+DXyVBoMmaejJknY6bJpEoXSbNwL/vqqDQLVpokFesjnTZPgVSMOU6KcjLKCkAQ 0A4IAVQ6YFJnAF8BkMRRagAfoEVwvpImor8PZRBwWOJ/1uiWfaYvfaYvfTp82SUvDx+XoKRdGgEl +Z/5aVIWIBteygJkUyVwJXAtcC1wC3ALcDx9ws5gnvvY28TY2+xNPS33vqPsTVSeYE/ijnrHcXaP iAOUcPU94dgEzCsdDcdZeSR0i0jocs9AKLg/yhvl+uguyUlvMfePrWmuhw4qzvYH2YMHZWf7A+yB +1Xn/Zw8wA4A0UHrwdqDLQcVz1TpvPSl8NA5YGxW6WtgvuG+MvGX0lmBz0t/E5t3ljyVy8szgXl9 BjDaZZeJpwPDq/I0E08x8WR5KpYkeYbJw+URQtImjxAjpMupIk2kAXO+1cQpJj9ZTkW6kDw5Ukh6 SujylPSkiJwnpSdE/QnpkMCPA3P+YyZ+1MSPSIfCmJs8SdJWsgI0QBHADagEWKRt4d2Kkzxu6Saa DZDIKi+mIkAtQEaM5NAWwEGAjJJ/f5WBshTgA2wBKOx99gFPOfLl8nyxskpgvoKFJl5g4stMXCHP Eyu91KzPlflrstTFjui7FGcX69J3c3Rcv1kCOqZv5eiovlkF6tZvUJ2eeHY7uxGR5GS3sXaBb2Hb cBOvOcq2IY62sRswYM1xxi8Ws3mJOFqt20bgBZGtZPV8m7F6dhXXli1ks/A+mHuM8c3qZmXof5G+ tTiXp5mZ+og8l0GkZQhiuj6nTBDTosTUMAj3CelpdBzLRvMVsTFsNLRxd7HR4eJJ/MvN0XpOHtLd aHcWgvX55yTnS1jiHoD7znHjXXfulp1dkZPhXb4Gl8DVVxt4/lKO/2uX51LXrt3xXMZdsHvKVNfu u5hzx12qc/+9qtO9b0Suy30vin3g3Av4DuAewN0A3iX7roJCl/uugiIUWh4KrGXhbrbwXoaT7bvy fuGEfcDcKXvl/SJgk+W75N3CnXuAecudJt4l7+buOiZ9ZO6Rv0tnsVocHGd1O97B86QPsWl4w8PS /XwE6SFgXj9o4geBETDSAyY+YOL7TPnvSffzwMWI9+vTXC5PjlwsjxfbbyIw16kImOtSaOICE08A 5qHoNPE4eTxfTXfkLIhUfvxnydlCcqicbZzG2eFhOS7JkybHyTHCErHAXMJiYtXkK3KMCFPp5vDW eDhX8vPzt/m45KM7ACGALNfqxxCtco2BFoWP8S8p2B91xxh+cLLfhFMyXSNPsN/QEsAZgMx+IeUj o4/0DJfysanysc3yxdYbKQ6PPBz3eeLU0XAOa/xrY5QjAVsAMntNsovvrtjr4fhEV4LHyn7FTyd2 inwAiV5jL+OgIHaeplEue4/9FcHe/gz7K+0ESKhid3ny5EvkcmGwcrlELLbMxKXA3AhzgLnhPSZ2 m3i2iS+WS3SGsIlnNzLxhSFrB+YXr5Pset0+UmyV6/X0Ia5utovxrxJPQnYnVG3hJfsWu4HPw24I b1WdJV0soBfZgVoNdC1Hz7AW3HjtkdPs2nDGEBcdY9eSFYDbP2vRU/nIbawOWmDjrxAbf4XY+HVh bHzswdrwGKerxpPMasXpg5L5kAP4rFebueAqfavILpezRfwyxS5ms8jHr+Nshn5ZpVjDDN1TYhIT iwUxS5+/2CRKLjWI8LiJfMY5+tChguHRXTNMYqzTJLKHmQSuUpyYrc+ebRKumSaB5GEQEwpNQssz CW5JToTj4l3u45KO1eQxB/chc4S3WpwnjsoP8zcY+UE9KUlcVB/krzK1nkL5AWoBtAN2Ag4AQoCT gFcAsTgDHkK/h3AOPEQnAH8DRAAWtBzk/0lDfpCPi/YHcT94ECdANhtBL3I7YbbiKUIxW7h4mmsn wpGfGcRscJUNtzMb4s4Gm59FyZ1j04ePNOVTs/A2Pt2UxCskSweVjvtdOvqk0wFACHASEINEnU6V gFpAywCpGHg3i54CnADItBBlDaAZsBlwByACsGCUrPDYQu6qLL14ltAjXq+sNIniUqTs+PC2eKfV k8LixDrEf/5gMShPMAvKXKbC8oq+GdmZSe6KrbLzqzdl530fs1c2V+Y+heqb2GCR59izP5Kdp3/E 3gbn3a3M+QKw+5j7uPuEfOJYvPM44Biyyu3b4523ArZvjREnQvvsUnEStMOqHN+EdChwSTnH7pab xhS4brpRcd4IBdoB3wLcAHBvXrzUtRmj3ILptyEetmxVnDfzvLUVQdW+ldmmZWZNzcyckpk2OTNl UmZicWbcxExLUaZcmEkFmaNGJ48ZnTLOmTzemZLnSB7pSMnJTdZyU1I8Sew0Fs1/RJFRZrJbWQeN FFukIzwk2+X2jAejFtAO2AkIAVR2JVtOyWwJW8q/IZNOwHK8zER5HINYWSr4hcwKX1nhKyusa0Vc JbMULs94W/JhSf4yUz7OPkKHs+zvYH/I/vaDZHf6WMMm1rFjhU0KlbETXCnW1MTEpOTEuPiEREtM bKKsqInIg4nNI5mW90qe5M6rzDuZdzrvbJ7K+4zKw5k4Sh7ttABmp7AU+W+yZGMjkrJihiVlWocm pSkZSZWTWCitgiqWzAmlM+DFc0KTnBVdsrYoVOysCMVWLq/qZGxHNbgh6ZYuZOGQckuXBJRWcuXy qi6WzZu32nCDZRSqqN16e3WnRHNC7JaQY3EVR+7Lq0LaLV1WWlLVKbE5tpBye3V1dWhaRWUVl6x2 jgj5+P9nax9RHSrmxM4R1eTEJxDgRZCXvZ+AU3CdUcQ/nWNGlYXGlXlD48tqS/sKs/59ez/BviNh okAgaPAxHTjBtjZU2gQX1bZvGEU0B3vUQDeBSqq6sZ1u5D+94SguCeeNdH27G0cK1wZ20sBKE2/k JbqmuZzO6n56BbgCXKOAOW7AHFGOCU+ZxrvFhEeNNXDmMNe+bpzkYp02QyZtiOvXghc0By6psnlG yWPlPHHZGGPi0XK+OONGmTjf5DtMPNLEdhNrJs6V8zpZHxtUR1dslceHCye6rF3AWLHAWCbHemyc i4vZjtA2fucJ9q64pOoZvL7dzxMQ7kdjCl38fhS2OQTmP/UgyYOwpooB2vgaudx4Qy4n15RLdzn7 2VGohONht15Q6DIIze4ybbRbT8t09SiOxv3i9y5OhLWR3LL79cwsPqLNY6U9uEMeBBwWd0pePgd4 VdQ0SOLMguP5aBQMfkOgmB8zjkRc88DpFS+pOibPk8X7NdSYr+fYhT7zdWeBQYTxNv3to5C4m7+P iAFsnjiy4K2DiZ6S2RMuMHqK6wknMrIN2/Wax4yukqoTsP0h8SXMIeGBQ+E8YflDUcsf4pbnRKc+ xOYyYtwm6uFhwvaHwuPGG9jwxSHTF73O4CY+i9c+cYRywpHvEqHwKt4Je0PBEJtqLJgTORqI90Fk 2UxOaoYRRXxZU/VCw2VT+fXcIFKzLogCvnuCfFsFo3ue2z0gLBC1RBDbtmevBY3dx1nMsJO5wUUe 6kknfZNSwGkkDwo4WR+mYPVXhQWC3fJhubOsvkt+oqzBWypQl6wb/zM+5K7tksOOUkxJIhE4WZeS DGEl2VHaPwv1GxgTY2heIn2xAChO8H8MipqZzcymJKqcyUSCCZJTLDHIlXN2K3crd/MJC8pWe/nc 0JEPB+Ggabog5g44+wV6oK82zGQI8TbDpr3twrB87mC38pVylk/1Z2EIjrqUv/QaQvnSUUrCisEe s5PhRK46tZluMqM5aM5s2qPH4nzZAaG06XtTDSeJRff1IjeIKdbv2KCo4Zmx0DYYjQsEo3xh9KBI tAi+UFaoCKco2G2BqOXFXD01gTrj+PFauWgOzthF4pwNDXOg8iIqU1FJ5BXfopDqEAcy+FWdFjan M4bmdMYDJ9AcG+skGmLtLKeWTiq/uEs5UkZdytGyUIIzFI9uCY45NHt2ltM6i60rnJ5lSQxZwI1x zKkmov8DxqZLgQplbmRzdHJlYW0KZW5kb2JqCgozOSAwIG9iagoxMTMyOQplbmRvYmoKCjQwIDAg b2JqCjw8L1Byb2R1Y2VyIChQcmluY2UgNy4wIFwod3d3LnByaW5jZXhtbC5jb21cKSkKL1RpdGxl IChPQXV0aCAxIEJyaWRnZSk+PgplbmRvYmoKCnhyZWYKMCA0MQowMDAwMDAwMDAwIDY1NTM1IGYg CjAwMDAwMDAwMTYgMDAwMDAgbiAKMDAwMDAwMDUyMSAwMDAwMCBuIAowMDAwMDAxODU3IDAwMDAw IG4gCjAwMDAwMDI3NjUgMDAwMDAgbiAKMDAwMDAwMDQ2MCAwMDAwMCBuIAowMDAwMDAwMzQxIDAw MDAwIG4gCjAwMDAwMDAxMjMgMDAwMDAgbiAKMDAwMDAwMDIyMiAwMDAwMCBuIAowMDAwMDA5NTgy IDAwMDAwIG4gCjAwMDAwMjQ5MTUgMDAwMDAgbiAKMDAwMDAyODY3MSAwMDAwMCBuIAowMDAwMDQw NDA2IDAwMDAwIG4gCjAwMDAwNTUxMjcgMDAwMDAgbiAKMDAwMDAwNTI3OCAwMDAwMCBuIAowMDAw MDAwNTgzIDAwMDAwIG4gCjAwMDAwMDE4MzUgMDAwMDAgbiAKMDAwMDAwMjEwOSAwMDAwMCBuIAow MDAwMDAyNzQ0IDAwMDAwIG4gCjAwMDAwMDI5NzUgMDAwMDAgbiAKMDAwMDAwNTI1NiAwMDAwMCBu IAowMDAwMDA5NTYwIDAwMDAwIG4gCjAwMDAwMTAyNTEgMDAwMDAgbiAKMDAwMDAxMDQzOSAwMDAw MCBuIAowMDAwMDI0ODkyIDAwMDAwIG4gCjAwMDAwMjU1MzcgMDAwMDAgbiAKMDAwMDAyNTcyNyAw MDAwMCBuIAowMDAwMDI4NjQ5IDAwMDAwIG4gCjAwMDAwMjk0MTQgMDAwMDAgbiAKMDAwMDAyOTU5 OSAwMDAwMCBuIAowMDAwMDQwMzgzIDAwMDAwIG4gCjAwMDAwNDEwNzIgMDAwMDAgbiAKMDAwMDA0 MTI1NyAwMDAwMCBuIAowMDAwMDU1MTA0IDAwMDAwIG4gCjAwMDAwNTUyNzUgMDAwMDAgbiAKMDAw MDA1NTQ3MiAwMDAwMCBuIAowMDAwMDU1NjY2IDAwMDAwIG4gCjAwMDAwNTU5ODQgMDAwMDAgbiAK MDAwMDA1NTk2MyAwMDAwMCBuIAowMDAwMDY3NDAzIDAwMDAwIG4gCjAwMDAwNjc0MjYgMDAwMDAg biAKCnRyYWlsZXIKPDwvSW5mbyA0MCAwIFIKL1NpemUgNDEKL1Jvb3QgMSAwIFI+PgpzdGFydHhy ZWYKNjc1MTYKJSVFT0YK --000e0cd13abab7f3250485c804be-- From eran@hueniverse.com Tue May 4 10:49:13 2010 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 13D133A69FA for ; Tue, 4 May 2010 10:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_40=-0.185] 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 XPe998y7aNFX for ; Tue, 4 May 2010 10:49:12 -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 1337B3A695C for ; Tue, 4 May 2010 10:49:11 -0700 (PDT) Received: (qmail 776 invoked from network); 4 May 2010 17:48:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 May 2010 17:48:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 4 May 2010 10:48:44 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , OAuth WG Date: Tue, 4 May 2010 10:48:51 -0700 Thread-Topic: [OAUTH-WG] OAuth 1 Bridge Flow Thread-Index: Acrrr0nZXtEdS8gMSXSO3Rg1yJaqywAArESQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723439323D0AC6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 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 Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 04 May 2010 17:49:13 -0000 Why a short lived 2.0 token? Why not provide an endpoint to exchange a 1.0 = token with a 2.0 token with a refresh token? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Tuesday, May 04, 2010 10:27 AM > To: OAuth WG > Subject: [OAUTH-WG] OAuth 1 Bridge Flow >=20 > Hi, >=20 > I would like to suggest a flow, or endpoint, that is bridging OAuth 1 and > OAuth 2. See the attachment. >=20 > The OAuth 1 Bridge Flow basically defines an endpoint where you can place= a > signed OAuth 1 request and in response you receive a short lived OAuth 2.= 0 > access token. This flow can be used by clients that have a long lived OAu= th > 1.0 access token and want to use a short lived OAuth 2.0 access token to > access protected resources. >=20 > Do you have a use case for a flow like this? If not exactly but close, ho= w can > the flow be improved to cover your use case as well? >=20 > Feedback more than welcome. >=20 > Thanks, > Marius From lshepard@facebook.com Tue May 4 11:05:28 2010 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 D2B063A697C for ; Tue, 4 May 2010 11:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, 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 Z6eWuC0nbV60 for ; Tue, 4 May 2010 11:05:27 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id BE5AD3A67AF for ; Tue, 4 May 2010 11:05:27 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o44I3WPQ008896 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 May 2010 11:03:43 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Tue, 4 May 2010 11:03:14 -0700 From: Luke Shepard To: Eran Hammer-Lahav Date: Tue, 4 May 2010 11:03:12 -0700 Thread-Topic: [OAUTH-WG] OAuth 1 Bridge Flow Thread-Index: AcrrtBB0w/60YWjYS+ms+0tkfmlr0w== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723439323D0AC6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D0AC6@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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-04_05:2010-02-06, 2010-05-04, 2010-05-03 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 04 May 2010 18:05:28 -0000 That's a good idea. FWIW we created a custom endpoint for this purpose - allows you to exchange= Facebook sessions for OAuth 2.0 tokens. Documented here: http://developers= .facebook.com/docs/guides/upgrade On May 4, 2010, at 10:48 AM, Eran Hammer-Lahav wrote: > Why a short lived 2.0 token? Why not provide an endpoint to exchange a 1.= 0 token with a 2.0 token with a refresh token? >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Tuesday, May 04, 2010 10:27 AM >> To: OAuth WG >> Subject: [OAUTH-WG] OAuth 1 Bridge Flow >>=20 >> Hi, >>=20 >> I would like to suggest a flow, or endpoint, that is bridging OAuth 1 an= d >> OAuth 2. See the attachment. >>=20 >> The OAuth 1 Bridge Flow basically defines an endpoint where you can plac= e a >> signed OAuth 1 request and in response you receive a short lived OAuth 2= .0 >> access token. This flow can be used by clients that have a long lived OA= uth >> 1.0 access token and want to use a short lived OAuth 2.0 access token to >> access protected resources. >>=20 >> Do you have a use case for a flow like this? If not exactly but close, h= ow can >> the flow be improved to cover your use case as well? >>=20 >> Feedback more than welcome. >>=20 >> Thanks, >> Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue May 4 11:25:35 2010 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 6B89028C15D for ; Tue, 4 May 2010 11:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.475 X-Spam-Level: X-Spam-Status: No, score=-100.475 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 uwjIkQA4ZRq8 for ; Tue, 4 May 2010 11:25:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id B6CAB3A659A for ; Tue, 4 May 2010 11:22:06 -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 o44ILoDx004930 for ; Tue, 4 May 2010 11:21:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272997311; bh=VuXb2HN1bfWeDw8HkGBZtN07Jjc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wthQLkMBH0q8ovhVfOGmdxvIhWgELXsCqu9Z4iuuUYee3/hzmDe9aWj3fCnMKaq1z aJfXOdVKJ2eoTdT/RyKqw== 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=c3jUMNudAAsv5gU95bIJIjouSIutHjZLf/0dTbywoDuZXL7K8MBCm7OanVSr8Wur4 nHc1VqrBlxSdHFt/D1kKg== Received: from pvc30 (pvc30.prod.google.com [10.241.209.158]) by wpaz37.hot.corp.google.com with ESMTP id o44ILngS019539 for ; Tue, 4 May 2010 11:21:49 -0700 Received: by pvc30 with SMTP id 30so412352pvc.41 for ; Tue, 04 May 2010 11:21:49 -0700 (PDT) Received: by 10.140.251.19 with SMTP id y19mr4943651rvh.161.1272997309196; Tue, 04 May 2010 11:21:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Tue, 4 May 2010 11:21:29 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D0AC6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723439323D0AC6@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 4 May 2010 11:21:29 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 04 May 2010 18:25:35 -0000 On Tue, May 4, 2010 at 10:48 AM, Eran Hammer-Lahav wrote: > Why a short lived 2.0 token? Why not provide an endpoint to exchange a 1.0 token with a 2.0 token with a refresh token? Yes, we thought about this use case but wasn't sure about the right implementation. If an OAuth 2.0 refresh token is issued, then most likely the OAuth 1.0 access token should be revoked. This would be more like a migration. Also, the OAuth 2.0 refresh token may need a corresponding client secret, how would the client get that: - assume this was provisioned offline - assume OAuth 2.0 client secret = OAuth 1.0 consumer secret - generate and send OAuth 2.0 client secret with the refresh token The first approach seems the right one, and the second could be a special case. I think a flag parameter is needed on the request to signal that a migration should be performed (issue OAuth 2.0 refresh token and revoke OAuth 1.0 access token) as opposed to just a short lived OAuth 2.0 access token request. Thoughts? Marius > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Tuesday, May 04, 2010 10:27 AM >> To: OAuth WG >> Subject: [OAUTH-WG] OAuth 1 Bridge Flow >> >> Hi, >> >> I would like to suggest a flow, or endpoint, that is bridging OAuth 1 and >> OAuth 2. See the attachment. >> >> The OAuth 1 Bridge Flow basically defines an endpoint where you can place a >> signed OAuth 1 request and in response you receive a short lived OAuth 2.0 >> access token. This flow can be used by clients that have a long lived OAuth >> 1.0 access token and want to use a short lived OAuth 2.0 access token to >> access protected resources. >> >> Do you have a use case for a flow like this? If not exactly but close, how can >> the flow be improved to cover your use case as well? >> >> Feedback more than welcome. >> >> Thanks, >> Marius > From mscurtescu@google.com Tue May 4 11:36:22 2010 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 1E9B328C19E for ; Tue, 4 May 2010 11:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.653 X-Spam-Level: X-Spam-Status: No, score=-101.653 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 dOS-zD8rqy7s for ; Tue, 4 May 2010 11:36:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C3A193A6CD4 for ; Tue, 4 May 2010 11:31:51 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [10.3.21.5]) by smtp-out.google.com with ESMTP id o44IVa9t015210 for ; Tue, 4 May 2010 11:31:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272997897; bh=9tS2RXGlP29S70NePQm96bFqBKA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Sj9rzfGub2HZkpZuryzkYAu/TJKBPe6m7fxtVm7u3coHSlm28CaRIwjM3Q/Cf7Htg 7WcgMezyycJR3u5XwQTRA== 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=QXGwToMu3nKhS0WY7N0ufFCDSMzFB2vKF0fbibQlJmLaN+DuoLOaXm9mCb8glOw7z QFfv3ntcNtx0chKK2lw0Q== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by hpaq5.eem.corp.google.com with ESMTP id o44IVY3h008924 for ; Tue, 4 May 2010 11:31:35 -0700 Received: by pzk27 with SMTP id 27so2684461pzk.2 for ; Tue, 04 May 2010 11:31:34 -0700 (PDT) Received: by 10.140.83.31 with SMTP id g31mr4932171rvb.3.1272997894152; Tue, 04 May 2010 11:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Tue, 4 May 2010 11:31:14 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723439323D0AC6@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 4 May 2010 11:31:14 -0700 Message-ID: To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 04 May 2010 18:36:22 -0000 On Tue, May 4, 2010 at 11:03 AM, Luke Shepard wrote: > That's a good idea. > > FWIW we created a custom endpoint for this purpose - allows you to exchange Facebook sessions for OAuth 2.0 tokens. Documented here: http://developers.facebook.com/docs/guides/upgrade Thanks for the pointer. Are the issued OAuth 2.0 access tokens short lived? Is "expires" a delta or an absolute time? Marius > > On May 4, 2010, at 10:48 AM, Eran Hammer-Lahav wrote: > >> Why a short lived 2.0 token? Why not provide an endpoint to exchange a 1.0 token with a 2.0 token with a refresh token? >> >> EHL >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Marius Scurtescu >>> Sent: Tuesday, May 04, 2010 10:27 AM >>> To: OAuth WG >>> Subject: [OAUTH-WG] OAuth 1 Bridge Flow >>> >>> Hi, >>> >>> I would like to suggest a flow, or endpoint, that is bridging OAuth 1 and >>> OAuth 2. See the attachment. >>> >>> The OAuth 1 Bridge Flow basically defines an endpoint where you can place a >>> signed OAuth 1 request and in response you receive a short lived OAuth 2.0 >>> access token. This flow can be used by clients that have a long lived OAuth >>> 1.0 access token and want to use a short lived OAuth 2.0 access token to >>> access protected resources. >>> >>> Do you have a use case for a flow like this? If not exactly but close, how can >>> the flow be improved to cover your use case as well? >>> >>> Feedback more than welcome. >>> >>> Thanks, >>> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > From torsten@lodderstedt.net Tue May 4 11:36:57 2010 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 D09283A6CCA for ; Tue, 4 May 2010 11:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 fJQcUUKC8gcx for ; Tue, 4 May 2010 11:36:53 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 3753B3A6D00 for ; Tue, 4 May 2010 11:32:34 -0700 (PDT) Received: from p4fff391d.dip.t-dialin.net ([79.255.57.29] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1O9Mup-0000Fy-IN; Tue, 04 May 2010 20:32:19 +0200 Message-ID: <4BE06831.60105@lodderstedt.net> Date: Tue, 04 May 2010 20:32:17 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Allen Tom References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh tokens security enhancement 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, 04 May 2010 18:36:57 -0000 Hi Allen, Am 03.05.2010 18:55, schrieb Allen Tom: > Hi Torsten, > > Thanks for posting this idea - I think that issuing a new Refresh Token (and > invalidating the old one) on every refresh request would help detect token > theft. > > HOWEVER - in practice, this mechanism could make implementations very > tricky. For example, some applications are highly distributed, with each > instance (or component) having its own copy of the Refresh Token. Keeping > the Refresh Token in sync would not really be feasible for these types of > apps. > You are right, this approach might make implementing a client more difficult, especially clustered web applications. That's not the case for autonomous devices (gaming consoles, mobile phones e.t.c) where the application architecture will typically be much simpler. On the other hand, these are exactly the clients where the current version of the specification does not contain any countermeasure against token theft. > Invalidating the Refresh Token (and presumably also invalidating any > outstanding Access Tokens) would make sense as an option for applications > that require a high level of security. However, I do not think that > invalidating the Refresh Token on every Refresh request should be required > in the spec - it should be an implementation specific detail. > It could be an optional feature of the spec (as many other features). An authorization server could decide when to use it based on its policy. For example, the authorization server could make this decision depend on client type (mobile vs. web application), client id, or target service (security level). The definition could be as follows refresh_token OPTIONAL. A new refresh token replacing the refresh_token used as input parameter. If set, the client must use this token for the next "refresh" request. The former refresh token has been invalidated by the authorization server. The benefit of making it an (optional) spec feature is support by libraries, standard service and applications. From my point of view, OAuth2 has the potential to become THE standard for securing standard protocols like IMAP, SyncML, SIP, WebDav and many others. Every feature defined by the standard is most likely supported by standard clients and servers. So depending on the authorization servers policy, all of this clients could be secured with the proposed countermeasure. > At Yahoo, we've used the Refresh Flow for all of our proprietary > authorization APIs for many years, and I know of several applications which > would break if the Refresh Token (and Access Token) were invalidated on > every refresh request. Off the top of my head, I know of server based apps, > mobile apps, and desktop apps which are composed of several components which > asynchronously and independently keep their own copies of the user's > credentials. > As I said, it could be an optional feature, which offers out of the box token theft prevention. Every deployment can decide to use it or not. The proposed change is small in terms of specification but we could demonstrate that OAuth is also suited for applications with a higher level of security. regards, Torsten. > Thanks > Allen > > > > > > > On 5/2/10 10:48 AM, "Torsten Lodderstedt" wrote: > > >> We came up with the following idea: >> >> The authorization server automatically creates a new refresh token with >> every "refresh" request (section 4) and invalidated the previous refresh >> token. The client must use this new token for the next "refresh" >> request. All attempts to obtain access tokens with an invalidated >> refresh token are refused. Additionally, the authorization server should >> hold a history of when the refresh token has been used. The client >> application behavior depends on who uses the refresh token first after >> it has been stolen. >> > From mscurtescu@google.com Tue May 4 11:49:28 2010 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 8382528C1E1 for ; Tue, 4 May 2010 11:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.363 X-Spam-Level: X-Spam-Status: No, score=-100.363 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 EdnEOgxMfHU8 for ; Tue, 4 May 2010 11:49:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 33D7528C1E7 for ; Tue, 4 May 2010 11:41:50 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [10.3.21.3]) by smtp-out.google.com with ESMTP id o44IfYRw003502 for ; Tue, 4 May 2010 11:41:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272998495; bh=pgexjv0uBe36Shx9L/QCMOcvbBk=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=ZFjNlvhuR9WIRedHmfKSp9y5vi3YQJGM43WMZf3X285U7ObPHYE8rGLxajkFCiWEN fu4RTTGT2O6r20KUXLqgw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=NNNaQlANIeeTARxRyQ1/5n9pb/1S04giUTqkchacspc/BdvQJYt52UKcU0vX4SX1V X0awthJh+0dAvh2lLslRg== Received: from pzk34 (pzk34.prod.google.com [10.243.19.162]) by hpaq3.eem.corp.google.com with ESMTP id o44IfWgX031000 for ; Tue, 4 May 2010 11:41:33 -0700 Received: by pzk34 with SMTP id 34so2142971pzk.33 for ; Tue, 04 May 2010 11:41:32 -0700 (PDT) Received: by 10.141.91.13 with SMTP id t13mr4857695rvl.266.1272998492083; Tue, 04 May 2010 11:41:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Tue, 4 May 2010 11:41:12 -0700 (PDT) From: Marius Scurtescu Date: Tue, 4 May 2010 11:41:12 -0700 Message-ID: To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] explicit request for refresh 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, 04 May 2010 18:49:28 -0000 Currently all flows return an optional refresh token and I think it was mentioned that the Autonomous Client flows should never return a refresh token. While a refresh token will probably be used in most cases by the other flows, in some cases the refresh token will be just ignored by the client. Ideally in these cases the refresh token is not issued at all. Also, Torsten suggested that when a new access token is requested then also a new refresh token is issued, this would allow the authorization server to detected if a refresh token was leaked and used by an attacker. However, this will not work in all cases. I suggest we add a parameter to the requests that normally issues the refresh token as a hint to the authorization server that the client wants a multi-use, single-use or no refresh token at all. This will be just a hint, the authorization server can decide how to proceed. For example, this parameter could look something like: - refresh_token_type = [none | multi | single] The default would be "none". "multi" is the normal refresh token and "single" is the refresh token suggested by Torsten. If the server does not support "single" type refresh tokens then it will issue a regular token and when the access token is renewed then it will not send a new refresh token. If for a certain flow or client the authz server does not want to issue refresh tokens at all then it can ignore the refresh_token_type request and just not issue one. If "multi" is requested then either "multi" or "none" should be issued. This refresh token type request parameter could be implemented as an extension as well. Thoughts? Marius From jricher@mitre.org Tue May 4 11:56:17 2010 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 A9E2128C184 for ; Tue, 4 May 2010 11:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.138 X-Spam-Level: X-Spam-Status: No, score=-4.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_50=0.001, 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 m9LrpqsuUl8B for ; Tue, 4 May 2010 11:56:16 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D8BC528C1D3 for ; Tue, 4 May 2010 11:46:51 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o44IkbmX027787 for ; Tue, 4 May 2010 14:46:37 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o44Ikbs5027784; Tue, 4 May 2010 14:46:37 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.213.0; Tue, 4 May 2010 14:46:37 -0400 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 4 May 2010 14:46:36 -0400 Message-ID: <1272998796.6288.55.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 04 May 2010 18:56:17 -0000 Interesting work. So as each app upgrades its support from OAuth1 to OAuth2, it exchanges its old tokens for new ones once for each user, right? Then the app in question is effectively going to have to speak both flavors of OAuth to do this one-time upgrade. I always assumed that apps would just have to get new OAuth2 access tokens by going back to the user (since tokens are cheap), but I can definitely see value in there being a clean upgrade path, especially for wide deployments. Because the other side of things, what would it take an implementor to have a backwards-compatible system? Since the OAuth2 protocol is by design not backwards compatible (though the signature-based web flows are all the same spirit as 1.0a, all the parameter names are different), I'm thinking that one would need either parallel endpoints or a proxy of some kind that works almost like that which was proposed here, but on an ongoing basis. -- Justin On Tue, 2010-05-04 at 13:26 -0400, Marius Scurtescu wrote: > Hi, > > I would like to suggest a flow, or endpoint, that is bridging OAuth 1 > and OAuth 2. See the attachment. > > The OAuth 1 Bridge Flow basically defines an endpoint where you can > place a signed OAuth 1 request and in response you receive a short > lived OAuth 2.0 access token. This flow can be used by clients that > have a long lived OAuth 1.0 access token and want to use a short lived > OAuth 2.0 access token to access protected resources. > > Do you have a use case for a flow like this? If not exactly but close, > how can the flow be improved to cover your use case as well? > > Feedback more than welcome. > > Thanks, > Marius From mscurtescu@google.com Tue May 4 13:30:02 2010 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 C103A3A6A34 for ; Tue, 4 May 2010 13:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.704 X-Spam-Level: X-Spam-Status: No, score=-100.704 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 PlwylWgM8mOl for ; Tue, 4 May 2010 13:29:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 70E1A3A6AC0 for ; Tue, 4 May 2010 12:45:16 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o44JixrA026917 for ; Tue, 4 May 2010 12:45:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273002300; bh=j07DCt7CcNAqOjj1pwBJN87Q1rw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=EM7KKs/lP9//op4CqQgoHseta+cRLijyMuLcYNGa20fdZYezZ7wzx3TCk/vBfPdhQ L3imV+aLWHTbs4MrlGefQ== 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=ZvJQpubCCs/T2wegwNYKOccXBCDItQLbRkwMaaVUWqvU0FeJ1hZV/uuyw/7jlIh+2 KzQumPHdTXtO35DtbcH9g== Received: from pxi15 (pxi15.prod.google.com [10.243.27.15]) by kpbe17.cbf.corp.google.com with ESMTP id o44JiwLi012562 for ; Tue, 4 May 2010 12:44:58 -0700 Received: by pxi15 with SMTP id 15so2134132pxi.28 for ; Tue, 04 May 2010 12:44:58 -0700 (PDT) Received: by 10.141.13.11 with SMTP id q11mr4974454rvi.75.1273002298155; Tue, 04 May 2010 12:44:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Tue, 4 May 2010 12:44:38 -0700 (PDT) In-Reply-To: <4BE06831.60105@lodderstedt.net> References: <4BE06831.60105@lodderstedt.net> From: Marius Scurtescu Date: Tue, 4 May 2010 12:44:38 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh tokens security enhancement 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, 04 May 2010 20:30:02 -0000 On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt wrote: > Am 03.05.2010 18:55, schrieb Allen Tom: >> Invalidating the Refresh Token (and presumably also invalidating any >> outstanding Access Tokens) would make sense as an option for applications >> that require a high level of security. However, I do not think that >> invalidating the Refresh Token on every Refresh request should be required >> in the spec - it should be an implementation specific detail. >> > > It could be an optional feature of the spec (as many other features). Torsten, can you please have a look a the "explicit request for refresh token" thread? Would a "refresh_token_type=single" parameter solve the above? Marius From atom@yahoo-inc.com Tue May 4 16:29:44 2010 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 C3EAD3A6857 for ; Tue, 4 May 2010 16:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.822 X-Spam-Level: X-Spam-Status: No, score=-14.822 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] 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 CDL-72PT9rNg for ; Tue, 4 May 2010 16:29:42 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 77C9228C332 for ; Tue, 4 May 2010 16:05:59 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o44N50On075498; Tue, 4 May 2010 16:05:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:x-originalarrivaltime; b=fCMxfdd2r2knsh5uJoKCXaoGlAYk+ydaMY9AUoWrLujfCLFa9Ox0W1giztsugLHg Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 May 2010 16:05:01 -0700 Received: from 10.72.244.69 ([10.72.244.69]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 May 2010 23:04:01 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 04 May 2010 16:03:58 -0700 From: Allen Tom To: Justin Richer , Marius Scurtescu , OAuth WG Message-ID: Thread-Topic: [OAUTH-WG] OAuth 1 Bridge Flow Thread-Index: Acrr3hO+SSKG8b2vd0mSA3+8duqBbg== In-Reply-To: <1272998796.6288.55.camel@localhost.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 May 2010 23:05:01.0652 (UTC) FILETIME=[39AF0940:01CAEBDE] Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 04 May 2010 23:29:44 -0000 Although we have not formally announced any plans to support OAuth2 yet, I would expect that Yahoo would be able to simultaneously support both Oauth 1.0a and OAuth2 without requiring clients to upgrade their existing Oauth 1.0a credentials for OAuth2. Note: Yahoo currently requires the Session Extension, so all of our Access Tokens are valid for one hour. The OAuth2 Refresh Token is equivalent to the Session Extension's "Auth Session Handle" Allen On 5/4/10 11:46 AM, "Justin Richer" wrote: > Interesting work. So as each app upgrades its support from OAuth1 to > OAuth2, it exchanges its old tokens for new ones once for each user, > right? Then the app in question is effectively going to have to speak > both flavors of OAuth to do this one-time upgrade. I always assumed that > apps would just have to get new OAuth2 access tokens by going back to > the user (since tokens are cheap), but I can definitely see value in > there being a clean upgrade path, especially for wide deployments. > > Because the other side of things, what would it take an implementor to > have a backwards-compatible system? Since the OAuth2 protocol is by > design not backwards compatible (though the signature-based web flows > are all the same spirit as 1.0a, all the parameter names are different), > I'm thinking that one would need either parallel endpoints or a proxy of > some kind that works almost like that which was proposed here, but on an > ongoing basis. > > -- Justin > > On Tue, 2010-05-04 at 13:26 -0400, Marius Scurtescu wrote: >> Hi, >> >> I would like to suggest a flow, or endpoint, that is bridging OAuth 1 >> and OAuth 2. See the attachment. >> >> The OAuth 1 Bridge Flow basically defines an endpoint where you can >> place a signed OAuth 1 request and in response you receive a short >> lived OAuth 2.0 access token. This flow can be used by clients that >> have a long lived OAuth 1.0 access token and want to use a short lived >> OAuth 2.0 access token to access protected resources. >> >> Do you have a use case for a flow like this? If not exactly but close, >> how can the flow be improved to cover your use case as well? >> >> Feedback more than welcome. >> >> Thanks, >> Marius > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Doug_Foiles@intuit.com Wed May 5 07:14:32 2010 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 0C4BD3A68F0 for ; Wed, 5 May 2010 07:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.596 X-Spam-Level: X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_50=0.001, 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 EYHwjQ7fgBXD for ; Wed, 5 May 2010 07:14:30 -0700 (PDT) Received: from mail4.intuit.com (mail4.intuit.com [12.149.175.56]) by core3.amsl.com (Postfix) with ESMTP id EAF543A69A2 for ; Wed, 5 May 2010 07:09:40 -0700 (PDT) DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Return-Path: X-OriginalArrivalTime; b=CFUDp8W4ZBUTuZtCYjjJ8L7fBujYwZ7wYKtbWYtskXcRARGay0FOcxte e+tF7tPCzH1dAe+VSVIjjBE5Sc1oNgEW+Dg6OUp+78JNuLqtdvXBr33lO 95In7FHTprBPHyj; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Doug_Foiles@intuit.com; q=dns/txt; s=default; t=1273068568; x=1304604568; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; z=MIME-Version:=201.0|Content-Transfer-Encoding:=20base64 |Subject:=20RE:=20[OAUTH-WG]=20OAuth=201=20Bridge=20Flow |Date:=20Wed,=205=20May=202010=2007:09:24=20-0700 |Message-ID:=20|In-Reply-To:=20|References:=20<1272998796.6288.55.c amel@localhost.localdomain>=20|From:=20"Foiles,=20Doug"=20|To:=20"Allen=20Tom"=20,=0D=0A=09" Justin=20Richer"=20,=0D=0A=09"Marius =20Scurtescu"=20,=0D=0A=09"OAuth =20WG"=20; bh=jZscqtgBuQs+xunQGCfjtn5F0K/l5Q3D3bYRDw9pg5Y=; b=XMQF9Dd3sfF6LKLOw0AE1Wlf+cDds5+cP0pHV7njQiOOwhKzCfgl3mdM zBtpT4ujBIOYo2yQiQnjifeR3hXVUuovgmX44rYhAWB95qMZRAV0lM3D3 61qO0XE7DlxdEEK; X-SBRS: None X-IronPort-AV: E=Sophos;i="4.52,333,1270450800"; d="scan'208";a="181441356" Received: from sdgexbh03.corp.intuit.net ([172.17.135.77]) by mail4.sdg.ie.intuit.com with ESMTP; 05 May 2010 07:09:25 -0700 Received: from SDGEXEVS07.corp.intuit.net ([172.17.135.182]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 May 2010 07:09:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 5 May 2010 07:09:24 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth 1 Bridge Flow Thread-Index: Acrr3hO+SSKG8b2vd0mSA3+8duqBbgAfCUpw References: <1272998796.6288.55.camel@localhost.localdomain> From: "Foiles, Doug" To: "Allen Tom" , "Justin Richer" , "Marius Scurtescu" , "OAuth WG" X-OriginalArrivalTime: 05 May 2010 14:09:25.0215 (UTC) FILETIME=[9149A6F0:01CAEC5C] Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 05 May 2010 14:14:32 -0000 SSB3b3VsZCBleHBlY3Qgb3VyIE9BdXRoIDEuMCBzZXJ2aWNlcyB0byBoYXZlIHN1cHBvcnQgZm9y IE9BdXRoIDEuMCBhbmQgMi4wIGZvciBzb21lIHBlcmlvZC4gIEkgZG9uJ3QgdGhpbmsgd2UgY291 bGQgZXhwZWN0IGFsbCBvdXIgY2xpZW50cyB0byBtb3ZlIHRvIE9BdXRoIDIuMCBhdCBvbmNlLiAg VGhpcyBpcyBhbiBpbnRlcmVzdGluZyBpZGVhIHRoYXQgYWxsb3dzIGNsaWVudHMgdG8gYmUgYWJs ZSB0byBjdXQgb3ZlciB0byBPQXV0aCAyLjAgd2l0aG91dCB1c2VycyBoYXZpbmcgdG8gcmUtYXV0 aGVudGljYXRlL2F1dGhvcml6ZS4NCg0KV2h5IG5vdCBqdXN0IHRyYW5zZmVyIHRoZSByZW1haW5p bmcgc2Vzc2lvbiBsaWZldGltZSB0byB0aGUgbmV3IGFjY2VzcyB0b2tlbiAob3IgcmVmcmVzaCB0 b2tlbiBpZiByZXF1ZXN0ZWQpLiAgSSB3b3VsZCBleHBlY3QgdGhlIHNjb3BlIHRvIGJlIHRyYW5z ZmVycmVkIGFzIHdlbGwuICBJIHdvdWxkIHdhbnQgb3VyIHVzZXJzIHRvIGF1dGhvcml6ZSBhbnkg ZXh0ZW5kZWQgcGVyaW9kLg0KDQpDb3VsZCB0aGUgbmVlZCB0byByZXBsYWNlIHRoZSBjbGllbnQg c2VjcmV0IGp1c3QgYmUgbGVmdCB1cCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2aWNlPw0KDQpS ZXZva2luZyB0aGUgT0F1dGggMS4wIHRva2VuIHNlZW1zIHRvIGZpdCB0aGUgc3Bpcml0IG9mIHRo ZSB1c2UgY2FzZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWxsZW4gVG9tDQpTZW50OiBUdWVzZGF5LCBNYXkgMDQsIDIwMTAgNDowNCBQTQ0KVG86IEp1 c3RpbiBSaWNoZXI7IE1hcml1cyBTY3VydGVzY3U7IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBPQXV0aCAxIEJyaWRnZSBGbG93DQoNCkFsdGhvdWdoIHdlIGhhdmUgbm90IGZvcm1h bGx5IGFubm91bmNlZCBhbnkgcGxhbnMgdG8gc3VwcG9ydCBPQXV0aDIgeWV0LCBJDQp3b3VsZCBl eHBlY3QgdGhhdCBZYWhvbyB3b3VsZCBiZSBhYmxlIHRvIHNpbXVsdGFuZW91c2x5IHN1cHBvcnQg Ym90aCBPYXV0aA0KMS4wYSBhbmQgT0F1dGgyIHdpdGhvdXQgcmVxdWlyaW5nIGNsaWVudHMgdG8g dXBncmFkZSB0aGVpciBleGlzdGluZyBPYXV0aA0KMS4wYSBjcmVkZW50aWFscyBmb3IgT0F1dGgy Lg0KDQpOb3RlOiBZYWhvbyBjdXJyZW50bHkgcmVxdWlyZXMgdGhlIFNlc3Npb24gRXh0ZW5zaW9u LCBzbyBhbGwgb2Ygb3VyIEFjY2Vzcw0KVG9rZW5zIGFyZSB2YWxpZCBmb3Igb25lIGhvdXIuIFRo ZSBPQXV0aDIgUmVmcmVzaCBUb2tlbiBpcyBlcXVpdmFsZW50IHRvIHRoZQ0KU2Vzc2lvbiBFeHRl bnNpb24ncyAiQXV0aCBTZXNzaW9uIEhhbmRsZSINCg0KQWxsZW4NCg0KDQpPbiA1LzQvMTAgMTE6 NDYgQU0sICJKdXN0aW4gUmljaGVyIiA8anJpY2hlckBtaXRyZS5vcmc+IHdyb3RlOg0KDQo+IElu dGVyZXN0aW5nIHdvcmsuIFNvIGFzIGVhY2ggYXBwIHVwZ3JhZGVzIGl0cyBzdXBwb3J0IGZyb20g T0F1dGgxIHRvDQo+IE9BdXRoMiwgaXQgZXhjaGFuZ2VzIGl0cyBvbGQgdG9rZW5zIGZvciBuZXcg b25lcyBvbmNlIGZvciBlYWNoIHVzZXIsDQo+IHJpZ2h0PyBUaGVuIHRoZSBhcHAgaW4gcXVlc3Rp b24gaXMgZWZmZWN0aXZlbHkgZ29pbmcgdG8gaGF2ZSB0byBzcGVhaw0KPiBib3RoIGZsYXZvcnMg b2YgT0F1dGggdG8gZG8gdGhpcyBvbmUtdGltZSB1cGdyYWRlLiBJIGFsd2F5cyBhc3N1bWVkIHRo YXQNCj4gYXBwcyB3b3VsZCBqdXN0IGhhdmUgdG8gZ2V0IG5ldyBPQXV0aDIgYWNjZXNzIHRva2Vu cyBieSBnb2luZyBiYWNrIHRvDQo+IHRoZSB1c2VyIChzaW5jZSB0b2tlbnMgYXJlIGNoZWFwKSwg YnV0IEkgY2FuIGRlZmluaXRlbHkgc2VlIHZhbHVlIGluDQo+IHRoZXJlIGJlaW5nIGEgY2xlYW4g dXBncmFkZSBwYXRoLCBlc3BlY2lhbGx5IGZvciB3aWRlIGRlcGxveW1lbnRzLg0KPiANCj4gQmVj YXVzZSB0aGUgb3RoZXIgc2lkZSBvZiB0aGluZ3MsIHdoYXQgd291bGQgaXQgdGFrZSBhbiBpbXBs ZW1lbnRvciB0bw0KPiBoYXZlIGEgYmFja3dhcmRzLWNvbXBhdGlibGUgc3lzdGVtPyBTaW5jZSB0 aGUgT0F1dGgyIHByb3RvY29sIGlzIGJ5DQo+IGRlc2lnbiBub3QgYmFja3dhcmRzIGNvbXBhdGli bGUgKHRob3VnaCB0aGUgc2lnbmF0dXJlLWJhc2VkIHdlYiBmbG93cw0KPiBhcmUgYWxsIHRoZSBz YW1lIHNwaXJpdCBhcyAxLjBhLCBhbGwgdGhlIHBhcmFtZXRlciBuYW1lcyBhcmUgZGlmZmVyZW50 KSwNCj4gSSdtIHRoaW5raW5nIHRoYXQgb25lIHdvdWxkIG5lZWQgZWl0aGVyIHBhcmFsbGVsIGVu ZHBvaW50cyBvciBhIHByb3h5IG9mDQo+IHNvbWUga2luZCB0aGF0IHdvcmtzIGFsbW9zdCBsaWtl IHRoYXQgd2hpY2ggd2FzIHByb3Bvc2VkIGhlcmUsIGJ1dCBvbiBhbg0KPiBvbmdvaW5nIGJhc2lz LiANCj4gDQo+ICAtLSBKdXN0aW4NCj4gDQo+IE9uIFR1ZSwgMjAxMC0wNS0wNCBhdCAxMzoyNiAt MDQwMCwgTWFyaXVzIFNjdXJ0ZXNjdSB3cm90ZToNCj4+IEhpLA0KPj4gDQo+PiBJIHdvdWxkIGxp a2UgdG8gc3VnZ2VzdCBhIGZsb3csIG9yIGVuZHBvaW50LCB0aGF0IGlzIGJyaWRnaW5nIE9BdXRo IDENCj4+IGFuZCBPQXV0aCAyLiBTZWUgdGhlIGF0dGFjaG1lbnQuDQo+PiANCj4+IFRoZSBPQXV0 aCAxIEJyaWRnZSBGbG93IGJhc2ljYWxseSBkZWZpbmVzIGFuIGVuZHBvaW50IHdoZXJlIHlvdSBj YW4NCj4+IHBsYWNlIGEgc2lnbmVkIE9BdXRoIDEgcmVxdWVzdCBhbmQgaW4gcmVzcG9uc2UgeW91 IHJlY2VpdmUgYSBzaG9ydA0KPj4gbGl2ZWQgT0F1dGggMi4wIGFjY2VzcyB0b2tlbi4gVGhpcyBm bG93IGNhbiBiZSB1c2VkIGJ5IGNsaWVudHMgdGhhdA0KPj4gaGF2ZSBhIGxvbmcgbGl2ZWQgT0F1 dGggMS4wIGFjY2VzcyB0b2tlbiBhbmQgd2FudCB0byB1c2UgYSBzaG9ydCBsaXZlZA0KPj4gT0F1 dGggMi4wIGFjY2VzcyB0b2tlbiB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcy4NCj4+IA0K Pj4gRG8geW91IGhhdmUgYSB1c2UgY2FzZSBmb3IgYSBmbG93IGxpa2UgdGhpcz8gSWYgbm90IGV4 YWN0bHkgYnV0IGNsb3NlLA0KPj4gaG93IGNhbiB0aGUgZmxvdyBiZSBpbXByb3ZlZCB0byBjb3Zl ciB5b3VyIHVzZSBjYXNlIGFzIHdlbGw/DQo+PiANCj4+IEZlZWRiYWNrIG1vcmUgdGhhbiB3ZWxj b21lLg0KPj4gDQo+PiBUaGFua3MsDQo+PiBNYXJpdXMNCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QN Cj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From eran@hueniverse.com Wed May 5 08:36:18 2010 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 2CC2F28C2CC for ; Wed, 5 May 2010 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-1.218, BAYES_50=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 BbbFiY+OrtST for ; Wed, 5 May 2010 08:36:17 -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 7235F28C33E for ; Wed, 5 May 2010 08:28:14 -0700 (PDT) Received: (qmail 10207 invoked from network); 5 May 2010 15:28:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 May 2010 15:28:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 5 May 2010 08:27:54 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 5 May 2010 08:28:05 -0700 Thread-Topic: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) Thread-Index: AcroRA9/JY7CF4g7T96FYknqd1dmPAEIklnQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100419134825.134951nuzvi35hk4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BD2A172.2070401@lodderstedt.net> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> In-Reply-To: <20100430105935.20255m8kdythy6sc@webmail.df.eu> 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] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 15:36:18 -0000 I'll add something to the draft and we'll discuss it. There is enough conse= nsus on a single JSON response format. EHL =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Friday, April 30, 2010 2:00 AM > To: Brian Eaton > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > (Proposal) >=20 >=20 > Zitat von Brian Eaton : >=20 > > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore > wrote: > >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland > wrote: > >>> > >>> Can we please just have one format, not 3? The more choices we give > >>> the more interoperability suffers. > > > > Yes. The number of parsers needed to make a working system is > > important. The spec has too many already. > > > > I'd like to see authorization servers returning JSON or XML, since > > that's what the resource servers are doing. > > > > ...and given a choice between JSON and XML, I'd pick JSON. > > >=20 > I agree. At Deutsche Telekom, we try to align our authorization APIs with= the > APIs provided by the resource servers. Authorization is "just" a small, b= ut > important, portion of the overall process and aligning it with the rest > increases acceptance and decreases error rate. >=20 > None of the APIs we provide uses form encoding, most of them use JSON, > some XML. > Based on that observation I would like to see at least JSON support in OA= uth. > So JSON as the only would be fine with me. >=20 > My proposal is based on the observation that the WG did not come to a > consensus about the one and only format. >=20 > I have collected the following opinions from the thread: >=20 > pro additional support for JSON and XML - Marius Scurtescu, John Jawed, > Richard Barnes, Brian Eaton, Torsten Lodderstedt pro additional support f= or > JSON - Dick Hardt (initiated the thread), Joseph Smarr still support > application/x-www-form-urlencoded (unclear whether > exclusively) - David Recordon, Gaurav Rastogi one format only (preference > unclear) - Yaron Goland JSON as the only format (if forced to decide for = a > single format) - Brian Eaton, Torsten Lodderstedt JSON as the only format= - > James Manger, Robert Sayre application/x-www-form-urlencoded as the > only format - Mike Moore JSON for responses as well - Marius Scurtescu >=20 > Here are some representative comments from the thread: >=20 > Joseph Smarr - "JSON is already widely supported (presumably including by > most APIs that you're building OAuth support to be able to access!" >=20 > David Recordon - "it's drastically more complex for environments (like > embedded hardware) which doesn't support JSON." >=20 > Paul C. Bryan - "I'm struggling to imagine hardware that on the one hand > would support OAuth, but on the other would be incapable of supporting > JSON..." >=20 > Gaurav Rastogi - "There are enough number of small embedded software > stack where JSON is not an option." >=20 > So we have at least 9 votes pro JSON, but also 1 vote for application/x-w= ww- > form-urlencoded only. >=20 > How shall we proceed? Can we come to a consensus? >=20 > regards, > Torsten. >=20 > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Wed May 5 08:50:05 2010 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 0F21F3A686D for ; Wed, 5 May 2010 08:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.409 X-Spam-Level: X-Spam-Status: No, score=-100.409 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 ZDH3jT9rEp9C for ; Wed, 5 May 2010 08:50:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 12AAA28C38A for ; Wed, 5 May 2010 08:43:08 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o45FgrOH025358 for ; Wed, 5 May 2010 08:42:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273074174; bh=UfN4/PEL/GDKBssWnKNKfSdUpe8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=N9XlJz0YLsA54YtY3eEsMAuKpUAipqJDCMNqCMUKrAsbx6Hyc8MpcaVTvjaPv9Lhc 5iCujWStL+yfDmGTBSoGQ== 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=BLG9gUjsuuVN5En52p6R+2hT6s7iZ/DA26FGhikdddMN6xN3QvcyePK/qPejHp4QA K3HmBLFpdaD+N3MGHvyHA== Received: from pxi10 (pxi10.prod.google.com [10.243.27.10]) by kpbe13.cbf.corp.google.com with ESMTP id o45FgpIT014236 for ; Wed, 5 May 2010 08:42:52 -0700 Received: by pxi10 with SMTP id 10so2735476pxi.7 for ; Wed, 05 May 2010 08:42:51 -0700 (PDT) Received: by 10.140.88.33 with SMTP id l33mr5684194rvb.4.1273074171133; Wed, 05 May 2010 08:42:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Wed, 5 May 2010 08:42:31 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 5 May 2010 08:42:31 -0700 Message-ID: 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] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 15:50:05 -0000 On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav wrote: > I'll add something to the draft and we'll discuss it. There is enough consensus on a single JSON response format. Yesterday I got the following feedback: On Tue, May 4, 2010 at 5:43 PM, Greg Robbins wrote: > Using JSON on the iPhone requires developers to drag in source code for a > third-party library. > > If their app isn't already relying on JSON for some other purpose, then > adding a third-party library is a somewhat substantial annoyance, > particularly for a mobile app where code size is important. > > If OAuth 2 is only intended for use with JSON APIs, then returning all > responses as JSON is reasonable. Otherwise, it's not so reasonable. A full > JSON parser is non-trivial, and seems like overkill for simple responses. > > The iPhone OS does have libxml2 and an event-style XML parser, but no really > easy way to extract data from XML, either. > > Form-style responses are much more straightforward to worth with given > simple string-manipulation utilities. If the above is true, then I am not so sure about JSON anymore. Lots of phones and devices will have problems with it. Marius From recordond@gmail.com Wed May 5 09:21:07 2010 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 64FE53A6ADA for ; Wed, 5 May 2010 09:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=-1.320, BAYES_20=-0.74, HTML_FONT_FACE_BAD=0.884, 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 RQ1x3WJRubdV for ; Wed, 5 May 2010 09:21:06 -0700 (PDT) Received: from mail-iw0-f196.google.com (mail-iw0-f196.google.com [209.85.223.196]) by core3.amsl.com (Postfix) with ESMTP id 95EF23A6858 for ; Wed, 5 May 2010 09:17:07 -0700 (PDT) Received: by iwn34 with SMTP id 34so6710563iwn.23 for ; Wed, 05 May 2010 09:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gsyTDW36f/O+wfWv4kkJGvlbh6AM+7Q7lT43RKBajy8=; b=krBYyTM7k60sXEe97FNdQ1wbIp/UtaVWfgRCsLEi7kd4IG4Qy/krYnZ5TFyilj9gWz n3gCcEL431HttG21FDTeA43yk5ukfFi/xWYz5N0F/aaBAlLj1wVI8sBGUZtNLf6DtaLX cPnAeKi/cbvofWNp4hRGuxvRc2pq4mAIg8M20= 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=BgeOKjfbDf9wTyC3XJBHC6yHQ7t9Yfh4qiSDFJzwlPkcx8AfLFc9hRRPOMvTtp1w4a iNJEqU24glGmv0lh2GM4cT1dTyE5eDF/f4bs3QkbkGZUyj/Br0n3pnviiHcrwZk8b72G ir2foRNseP3k7bqap7uJ3yJ5R0lWAfHYVTKHQ= MIME-Version: 1.0 Received: by 10.231.173.129 with SMTP id p1mr191981ibz.85.1273076211564; Wed, 05 May 2010 09:16:51 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Wed, 5 May 2010 09:16:51 -0700 (PDT) In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 5 May 2010 09:16:51 -0700 Message-ID: From: David Recordon To: Marius Scurtescu Content-Type: multipart/alternative; boundary=001485eba2cc5cc2100485db27a1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 16:21:07 -0000 --001485eba2cc5cc2100485db27a1 Content-Type: text/plain; charset=ISO-8859-1 As long as we spec that the response can only contain one parameter (either "error" or "access_token") then the code to parse it in PHP is as follows: list($param, $value) = explode('=', $response, 2); if ($param == 'access_token') { } elseif ($param == 'error') { } If it can contain more than one value, then parsing becomes more difficult and JSON starts to make sense. --David On Wed, May 5, 2010 at 8:42 AM, Marius Scurtescu wrote: > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav > wrote: > > I'll add something to the draft and we'll discuss it. There is enough > consensus on a single JSON response format. > > Yesterday I got the following feedback: > > On Tue, May 4, 2010 at 5:43 PM, Greg Robbins wrote: > > Using JSON on the iPhone requires developers to drag in source code for a > > third-party library. > > > > If their app isn't already relying on JSON for some other purpose, then > > adding a third-party library is a somewhat substantial annoyance, > > particularly for a mobile app where code size is important. > > > > If OAuth 2 is only intended for use with JSON APIs, then returning all > > responses as JSON is reasonable. Otherwise, it's not so reasonable. A > full > > JSON parser is non-trivial, and seems like overkill for simple responses. > > > > The iPhone OS does have libxml2 and an event-style XML parser, but no > really > > easy way to extract data from XML, either. > > > > Form-style responses are much more straightforward to worth with given > > simple string-manipulation utilities. > > If the above is true, then I am not so sure about JSON anymore. Lots > of phones and devices will have problems with it. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001485eba2cc5cc2100485db27a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As long as we spec that the response can only contain one parameter (either= "error" or "access_token") then the code to parse it i= n PHP is as follows:

list($param, $value) =3D explode('=3D', $response, 2);<= /div>
if ($param =3D=3D 'access_token') {
} elseif ($param =3D=3D 'error') {
}

If it can contain more than one value, then parsing bec= omes more difficult and JSON starts to make sense.

--David


On Wed, May 5, 2010 at 8:42 AM, Marius Scurtescu <mscurtescu@google.com> w= rote:
On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I'll add something to the draft and we'll discuss it. There is= enough consensus on a single JSON response format.

Yesterday I got the following feedback:

On Tue, May 4, 2010 at 5:43 PM, Greg Robbins <grobbins@google.com> wrote:
> Using JSON on the iPhone requires developers to drag in source code fo= r a
> third-party library.
>
> If their app isn't already relying on JSON for some other purpose,= then
> adding a third-party library is a somewhat substantial annoyance,
> particularly for a mobile app where code size is important.
>
> If OAuth 2 is only intended for use with JSON APIs, then returning all=
> responses as JSON is reasonable. Otherwise, it's not so reasonable= . A full
> JSON parser is non-trivial, and seems like overkill for simple respons= es.
>
> The iPhone OS does have libxml2 and an event-style XML parser, but no = really
> easy way to extract data from XML, either.
>
> Form-style responses are much more straightforward to worth with given=
> simple string-manipulation utilities.

If the above is true, then I am not so sure about JSON anymore. Lots
of phones and devices will have problems with it.

Marius
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001485eba2cc5cc2100485db27a1-- From sayrer@gmail.com Wed May 5 09:43:31 2010 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 DDB193A699C for ; Wed, 5 May 2010 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_50=0.001, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6] 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 ASo1W-gjTWS9 for ; Wed, 5 May 2010 09:43:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1481A28C0F4 for ; Wed, 5 May 2010 09:43:24 -0700 (PDT) Received: by vws9 with SMTP id 9so253694vws.31 for ; Wed, 05 May 2010 09:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Yclg4hCvnHycYc1e1BaEXmjcOD3vgzHQ1aWY/fQixw4=; b=gRqT3m06p4hvYZ4meQUr+Dh0ItkU+GuG9OSQm9GUflZN0XABLcTRE9m38fNOKDjRYi D/z+PgcDzGvUfavkH+w9u1YL0hDnm6GxheYRa1pF+5LyAZsruJuprmDkIusnOnhTP6Bu RSAeea8scruM9TUo6d5VB+AFPpEO1zKPL4/1o= 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=axUvklRS9BKGbBPxcwd6E3MjJpZyKf+h0hHordwzjguvR/0NR+9QmkBwCEPBGjAA+b ItxIh5jgRbwApxkd3FWEXl5cpgepTH5cn2/yorvCkElYnpLJd0oID9tZEodGExiKCkvF /1OMkzuKvewCYJkFOol3fVGCSED0rh7B4mm4w= MIME-Version: 1.0 Received: by 10.229.245.68 with SMTP id lt4mr4507330qcb.71.1273077783795; Wed, 05 May 2010 09:43:03 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Wed, 5 May 2010 09:43:03 -0700 (PDT) In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 5 May 2010 12:43:03 -0400 Message-ID: From: Robert Sayre To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 16:43:32 -0000 On Wed, May 5, 2010 at 11:42 AM, Marius Scurtescu wrote: > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav wrote: >> I'll add something to the draft and we'll discuss it. There is enough consensus on a single JSON response format. > > Yesterday I got the following feedback: > > On Tue, May 4, 2010 at 5:43 PM, Greg Robbins wrote: >> Using JSON on the iPhone requires developers to drag in source code for a >> third-party library ... > > If the above is true, then I am not so sure about JSON anymore. Lots > of phones and devices will have problems with it. It is true that some devices do not ship with JSON libraries, but I think the concern is overblown. A JSON library is going to be something like 1000 lines of code, and orders of magnitude faster and smaller than an XML parser. For instance, a Blackberry developer would need to include the org.json packages that come bundled with Android, but they are tiny: http://www.json.org/java/index.html Besides that, the group should skate to where the puck will be, as it were. Every platform that can handle Unicode can and will have a JSON library in short order. I once saw a WG waste tons of time debating the capabilities of J2ME handsets that are now basically irrelevant in terms of Internet traffic share. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From uidude@google.com Wed May 5 10:07:22 2010 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 1644D3A6B96 for ; Wed, 5 May 2010 10:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.72 X-Spam-Level: X-Spam-Status: No, score=-105.72 tagged_above=-999 required=5 tests=[AWL=0.256, 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 nOuaTAUfk6pn for ; Wed, 5 May 2010 10:07:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 10C8D3A6BCE for ; Wed, 5 May 2010 10:07:11 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o45H6t0f003526 for ; Wed, 5 May 2010 10:06:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273079216; bh=ivch+cVho4NqxE91Pddk/QNR28s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=KrmyOSB1pJUp7IqnhEXJjTP5MgtGFnZ70yKPGQO2urYAgVEkTkmKA46ScvBc42v38 lFBszp2ETEa+rUURtBT2A== 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=QY0Mgpwpb7fNQ1c+7S/ttS8F0Qgrw/vnR2AzzXDM6XA7pqQW/KVOanUa9q/tqBxDG uLK0uvTYp2Tm97fg83omA== Received: from qyk34 (qyk34.prod.google.com [10.241.83.162]) by kpbe17.cbf.corp.google.com with ESMTP id o45H64i4026689 for ; Wed, 5 May 2010 10:06:54 -0700 Received: by qyk34 with SMTP id 34so6389698qyk.10 for ; Wed, 05 May 2010 10:06:54 -0700 (PDT) Received: by 10.224.27.161 with SMTP id i33mr1093765qac.207.1273079213789; Wed, 05 May 2010 10:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Wed, 5 May 2010 10:06:33 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Wed, 5 May 2010 10:06:33 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00c09ffb50c54f139e0485dbdae8 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 17:07:22 -0000 --00c09ffb50c54f139e0485dbdae8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav wrote: > I'll add something to the draft and we'll discuss it. There is enough > consensus on a single JSON response format. Responses that are returned via a browser URL should be application/x-www-form-urlencoded. These parameters are standard to parse in any HTTP handling library and JSON only adds complexity and external library requirements. I'm not positive we need to support JSON at all. But if we support both JSON and application/x-www-form-urlencoded, I think the pattern should be: - application/x-www-form-urlencoded for requests/responses in a browser - JSON otherwise (including requests) > > EHL > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Torsten Lodderstedt > > Sent: Friday, April 30, 2010 2:00 AM > > To: Brian Eaton > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > > (Proposal) > > > > > > Zitat von Brian Eaton : > > > > > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore > > wrote: > > >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland > > wrote: > > >>> > > >>> Can we please just have one format, not 3? The more choices we give > > >>> the more interoperability suffers. > > > > > > Yes. The number of parsers needed to make a working system is > > > important. The spec has too many already. > > > > > > I'd like to see authorization servers returning JSON or XML, since > > > that's what the resource servers are doing. > > > > > > ...and given a choice between JSON and XML, I'd pick JSON. > > > > > > > I agree. At Deutsche Telekom, we try to align our authorization APIs with > the > > APIs provided by the resource servers. Authorization is "just" a small, > but > > important, portion of the overall process and aligning it with the rest > > increases acceptance and decreases error rate. > > > > None of the APIs we provide uses form encoding, most of them use JSON, > > some XML. > > Based on that observation I would like to see at least JSON support in > OAuth. > > So JSON as the only would be fine with me. > > > > My proposal is based on the observation that the WG did not come to a > > consensus about the one and only format. > > > > I have collected the following opinions from the thread: > > > > pro additional support for JSON and XML - Marius Scurtescu, John Jawed, > > Richard Barnes, Brian Eaton, Torsten Lodderstedt pro additional support > for > > JSON - Dick Hardt (initiated the thread), Joseph Smarr still support > > application/x-www-form-urlencoded (unclear whether > > exclusively) - David Recordon, Gaurav Rastogi one format only (preference > > unclear) - Yaron Goland JSON as the only format (if forced to decide for > a > > single format) - Brian Eaton, Torsten Lodderstedt JSON as the only format > - > > James Manger, Robert Sayre application/x-www-form-urlencoded as the > > only format - Mike Moore JSON for responses as well - Marius Scurtescu > > > > Here are some representative comments from the thread: > > > > Joseph Smarr - "JSON is already widely supported (presumably including by > > most APIs that you're building OAuth support to be able to access!" > > > > David Recordon - "it's drastically more complex for environments (like > > embedded hardware) which doesn't support JSON." > > > > Paul C. Bryan - "I'm struggling to imagine hardware that on the one hand > > would support OAuth, but on the other would be incapable of supporting > > JSON..." > > > > Gaurav Rastogi - "There are enough number of small embedded software > > stack where JSON is not an option." > > > > So we have at least 9 votes pro JSON, but also 1 vote for > application/x-www- > > form-urlencoded only. > > > > How shall we proceed? Can we come to a consensus? > > > > regards, > > Torsten. > > > > > 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00c09ffb50c54f139e0485dbdae8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 5, 2010 at 8:28 AM, Eran Ham= mer-Lahav <eran@hueniverse.com> wrote:
I'll add something to the draft and we'll discuss it. There is enou= gh consensus on a single JSON response format.

<= div>Responses that are returned via a browser URL should be=A0application/x= -www-form-urlencoded. These parameters are standard to parse in any HTTP ha= ndling library and JSON only adds complexity and external library requireme= nts.

I'm not positive we need to support JSON at all.

=A0But if we=A0support both JSON and=A0application/x= -www-form-urlencoded, I think the pattern should be:
-=A0applicat= ion/x-www-form-urlencoded for requests/responses in a browser
- JSON otherwise (including requests)

=A0

EHL


> -----Original Message-----
> From: oaut= h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Friday, April 30, 2010 2:00 AM
> To: Brian Eaton
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
> (Proposal)
>
>
> Zitat von Brian Eaton <beaton@google.com>:
>
> > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore <blowmage@gmail.com>
> wrote:
> >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland <yarong@microsoft.com>=
> wrote:
> >>>
> >>> Can we please just have one format, not 3? The more choic= es we give
> >>> the more interoperability suffers.
> >
> > Yes. =A0The number of parsers needed to make a working system is<= br> > > important. =A0The spec has too many already.
> >
> > I'd like to see authorization servers returning JSON or XML, = since
> > that's what the resource servers are doing.
> >
> > ...and given a choice between JSON and XML, I'd pick JSON. > >
>
> I agree. At Deutsche Telekom, we try to align our authorization APIs w= ith the
> APIs provided by the resource servers. Authorization is "just&quo= t; a small, but
> important, portion of the overall process and aligning it with the res= t
> increases acceptance and decreases error rate.
>
> None of the APIs we provide uses form encoding, most of them use JSON,=
> some XML.
> Based on that observation I would like to see at least JSON support in= OAuth.
> So JSON as the only would be fine with me.
>
> My proposal is based on the observation that the WG did not come to a<= br> > consensus about the one and only format.
>
> I have collected the following opinions from the thread:
>
> pro additional support for JSON and XML - Marius Scurtescu, John Jawed= ,
> Richard Barnes, Brian Eaton, Torsten Lodderstedt pro additional suppor= t for
> JSON - Dick Hardt (initiated the thread), Joseph Smarr still support > application/x-www-form-urlencoded (unclear whether
> exclusively) - David Recordon, Gaurav Rastogi one format only (prefere= nce
> unclear) - Yaron Goland JSON as the only format (if forced to decide f= or a
> single format) - Brian Eaton, Torsten Lodderstedt JSON as the only for= mat -
> James Manger, Robert Sayre application/x-www-form-urlencoded as the > only format - Mike Moore JSON for responses as well - Marius Scurtescu=
>
> Here are some representative comments from the thread:
>
> Joseph Smarr - "JSON is already widely supported (presumably incl= uding by
> most APIs that you're building OAuth support to be able to access!= "
>
> David Recordon - "it's drastically more complex for environme= nts (like
> embedded hardware) which doesn't support JSON."
>
> Paul C. Bryan - "I'm struggling to imagine hardware that on t= he one hand
> would support OAuth, but on the other would be incapable of supporting=
> JSON..."
>
> Gaurav Rastogi - "There are enough number of small embedded softw= are
> stack where JSON is not an option."
>
> So we have at least 9 votes pro JSON, but also 1 vote for application/= x-www-
> form-urlencoded only.
>
> How shall we proceed? Can we come to a consensus?
>
> regards,
> Torsten.
>
> > Cheers,
> > Brian
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > 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
h= ttps://www.ietf.org/mailman/listinfo/oauth

--00c09ffb50c54f139e0485dbdae8-- From sayrer@gmail.com Wed May 5 10:27:41 2010 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 0F9033A6C1E for ; Wed, 5 May 2010 10:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.05 X-Spam-Level: X-Spam-Status: No, score=-4.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, GB_I_LETTER=-2] 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 tstIHTIhj5Sx for ; Wed, 5 May 2010 10:27:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A9B1F28C175 for ; Wed, 5 May 2010 10:25:42 -0700 (PDT) Received: by vws9 with SMTP id 9so299303vws.31 for ; Wed, 05 May 2010 10:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nhSPCuhoXPE+Ci2Aqm0dzWvgTyyJecREMPHnecqIjw4=; b=AAGz9G1tyIbumsSiTh5l0syfV4xKCuL0j75QCc+ft3jN5ibNFwlI2A/9isB75vUbNK jJXPIQk6RCPlhRCQlAbt8QFFp8EVj0OGiRA0v236B04EzYrhR7/SrzaxHoMJGCcX5FA/ ExaNeX/aEhBsEU+fskMBnru3H8mTVyLI/RuOA= 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=psRma9uybiG7/zmpZO8SmGJ+u/CPoFfHGfVvhpdyzFDi8TAWXcVDpIOd7gG7A4aQfh 3fKTQnRhyulfq5HpbXI9K3+VbinrZW1UwZbbKPQTUmJ1A51fu3xkKOzUJjfb6wTQTHCR wV52LJranCCIP1udRAk3EVRRWfi315lCy1HEw= MIME-Version: 1.0 Received: by 10.229.185.1 with SMTP id cm1mr3239057qcb.57.1273080329246; Wed, 05 May 2010 10:25:29 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Wed, 5 May 2010 10:24:59 -0700 (PDT) In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 5 May 2010 13:24:59 -0400 Message-ID: From: Robert Sayre To: Evan Gilbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 17:27:41 -0000 On Wed, May 5, 2010 at 1:06 PM, Evan Gilbert wrote: > > > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav > wrote: >> >> I'll add something to the draft and we'll discuss it. There is enough >> consensus on a single JSON response format. > > Responses that are returned via a browser URL should > be=A0application/x-www-form-urlencoded. I'm not sure I understand here, could you explain in more detail? > These parameters are standard to parse > in any HTTP handling library Any HTTP handling library will claim to support it, but I doubt very many non-browser libraries match the HTML5 spec. Don't you find the requirements there to be complex relative to JSON? > and JSON only adds complexity and external > library requirements. Anything in a browser won't care either way. And won't other HTTP clients likely end up talking to a JSON API anyway? > > =A0But if we=A0support both JSON and=A0application/x-www-form-urlencoded That is design-by-committee. Let's not do that. --=20 Robert Sayre "I would have written a shorter letter, but I did not have the time." From torsten@lodderstedt.net Wed May 5 10:47:34 2010 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 E838F3A68CD for ; Wed, 5 May 2010 10:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 WDr-niXXC9Dn for ; Wed, 5 May 2010 10:47:34 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by core3.amsl.com (Postfix) with ESMTP id D78723A6830 for ; Wed, 5 May 2010 10:47:33 -0700 (PDT) Received: from p4fff1ebc.dip.t-dialin.net ([79.255.30.188] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1O9igp-0002a3-4t; Wed, 05 May 2010 19:47:19 +0200 Message-ID: <4BE1AF25.7000308@lodderstedt.net> Date: Wed, 05 May 2010 19:47:17 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 17:47:35 -0000 Even if not supported directly by the platform there are many JSON libraries available these days. http://www.json.org/ lists 3 libraries for Objective-C alone. Moreover, the JSON documents we are discussing now are simple, something like { "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": "8xLOxBtZp8" } Parsing such a document is not a challenge even without library support. Regarding code size: What really matters on mobile devices from my point of view is the size of data to be transmitted. Here, JSON is much more compact than XML. regards, Torsten. Am 05.05.2010 17:42, schrieb Marius Scurtescu: > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav wrote: > >> I'll add something to the draft and we'll discuss it. There is enough consensus on a single JSON response format. >> > Yesterday I got the following feedback: > > On Tue, May 4, 2010 at 5:43 PM, Greg Robbins wrote: > >> Using JSON on the iPhone requires developers to drag in source code for a >> third-party library. >> >> If their app isn't already relying on JSON for some other purpose, then >> adding a third-party library is a somewhat substantial annoyance, >> particularly for a mobile app where code size is important. >> >> If OAuth 2 is only intended for use with JSON APIs, then returning all >> responses as JSON is reasonable. Otherwise, it's not so reasonable. A full >> JSON parser is non-trivial, and seems like overkill for simple responses. >> >> The iPhone OS does have libxml2 and an event-style XML parser, but no really >> easy way to extract data from XML, either. >> >> Form-style responses are much more straightforward to worth with given >> simple string-manipulation utilities. >> > If the above is true, then I am not so sure about JSON anymore. Lots > of phones and devices will have problems with it. > > Marius > From uidude@google.com Wed May 5 10:58:00 2010 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 57E9828C0ED for ; Wed, 5 May 2010 10:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 dZBVooZPJKSw for ; Wed, 5 May 2010 10:57:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C4B6D3A6A4D for ; Wed, 5 May 2010 10:57:57 -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 o45HvgqN010264 for ; Wed, 5 May 2010 10:57:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273082263; bh=xVTqBMsgJ3u+jqp0WVUNXZARV8g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bxr8UDuAbStB/2wwiIMY9YDvMNCr24IZ3HPASdpyHQhLKvJC7759ir0MRcPHcU8YS sbqn/SNlmBue/7zwQgGLA== 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=m6SdN0iVZ0wNC8NUzMK2PoRi4Uj6289ntiGrjdbvEScXX3DHDwg/lg3NnAHNfFEyJ 53aP43WZcr14eDjY8aD2Q== Received: from qyk31 (qyk31.prod.google.com [10.241.83.159]) by wpaz1.hot.corp.google.com with ESMTP id o45HuvLc009365 for ; Wed, 5 May 2010 10:57:41 -0700 Received: by qyk31 with SMTP id 31so7960603qyk.25 for ; Wed, 05 May 2010 10:57:41 -0700 (PDT) Received: by 10.224.66.23 with SMTP id l23mr5911495qai.346.1273082260806; Wed, 05 May 2010 10:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Wed, 5 May 2010 10:57:20 -0700 (PDT) In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Wed, 5 May 2010 10:57:20 -0700 Message-ID: To: Robert Sayre Content-Type: multipart/alternative; boundary=00c09f89962cecf25c0485dc8f48 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 17:58:00 -0000 --00c09f89962cecf25c0485dc8f48 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 5, 2010 at 10:24 AM, Robert Sayre wrote: > On Wed, May 5, 2010 at 1:06 PM, Evan Gilbert wrote: > > > > > > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav > > wrote: > >> > >> I'll add something to the draft and we'll discuss it. There is enough > >> consensus on a single JSON response format. > > > > Responses that are returned via a browser URL should > > be application/x-www-form-urlencoded. > > I'm not sure I understand here, could you explain in more detail? > Sorry, should have been clearer here. Think that any response sent to a redirect_uri should be form encoded. The "via a browser" comment was to clarify the goal - it's because this is sent via HTTP GET to a web server (or other client - JS, installed app - reading the browser path). JSON only adds complexity for these cases - the client needs to understand how to parse URL parameters anyway to get the JSON content, so you're adding a separate encoding layer. Non-redirect responses and HTTP POST requests are more interesting. > > > These parameters are standard to parse > > in any HTTP handling library > > Any HTTP handling library will claim to support it, but I doubt very > many non-browser libraries match the HTML5 spec. Don't you find the > requirements there to be complex relative to JSON? > See notes above - all clients need to know how to parse URL parameters anyway. So we just have to decide on whether we want an additional JSON requirement. > > and JSON only adds complexity and external > > library requirements. > > Anything in a browser won't care either way. And won't other HTTP > clients likely end up talking to a JSON API anyway? > > > > > But if we support both JSON and application/x-www-form-urlencoded > > That is design-by-committee. Let's not do that. > All requests and HTTP redirect responses probably need to be HTTP GET (unless we change the spec significantly) - think this means that we are supporting form encoding. For responses, think that sending JSON would be OK. Web serving is often asymmetrical this way (url params in, HTML out) > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > --00c09f89962cecf25c0485dc8f48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 5, 2010 at 10:24 AM, Robert = Sayre <sayrer@gmai= l.com> wrote:
On Wed, May 5, 2010 at 1:06 PM, Evan Gilbert <uidude@google.com> wrote:
>
>
> On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>>
>> I'll add something to the draft and we'll discuss it. Ther= e is enough
>> consensus on a single JSON response format.
>
> Responses that are returned via a browser URL should
> be=A0application/x-www-form-urlencoded.

I'm not sure I understand here, could you explain in more detail?=

Sorry, should have been clearer here. = Think that any response sent to a redirect_uri should be form encoded.

The "via a browser" comment was to clarify the goal - it= 's because this is sent via HTTP GET to a web server (or other client -= JS, installed app - reading the browser path).

JSON only adds complexity for these cases - the client needs to understand = how to parse URL parameters anyway to get the JSON content, so you're a= dding a separate encoding layer.

Non-redirect responses and H= TTP POST requests are more interesting.
=A0

> These parameters are standard to parse
> in any HTTP handling library

Any HTTP handling library will claim to support it, but I doubt very<= br> many non-browser libraries match the HTML5 spec. Don't you find the
requirements there to be complex relative to JSON?
See notes above - all clients need to know how to parse URL par= ameters anyway. So we just have to decide on whether we want an additional = JSON requirement.


> and JSON only adds complexity and external
> library requirements.

Anything in a browser won't care either way. And won't other = HTTP
clients likely end up talking to a JSON API anyway?

>
> =A0But if we=A0support both JSON and=A0application/x-www-form-urlencod= ed

That is design-by-committee. Let's not do that.
<= div>
All requests and HTTP redirect responses probably need t= o be HTTP GET (unless we change the spec significantly) - think this means = that we are supporting form encoding.

For responses, think that sending JSON would be OK. Web= serving is often asymmetrical this way (url params in, HTML out)


--

Robert Sayre

"I would have written a shorter letter, but I did not have the time.&q= uot;

--00c09f89962cecf25c0485dc8f48-- From uidude@google.com Wed May 5 11:00:08 2010 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 C50673A6A37 for ; Wed, 5 May 2010 11:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.526 X-Spam-Level: X-Spam-Status: No, score=-104.526 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_40=-0.185, 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 b+sEoNQ1dvKB for ; Wed, 5 May 2010 11:00:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5B3153A68CD for ; Wed, 5 May 2010 11:00:07 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o45HxqC2017602 for ; Wed, 5 May 2010 10:59:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273082393; bh=w7yX7i6u/VOUmE4FVYG9TNZWvOI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=a9IvSZluLrQtFSTS3WRJqpaxNgx0OvWo12zRVbMqcT8xSbzvHFyDP4IjxvVVvMACM iLzfNpnud0ZXtR8I9QENw== 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=NxrDnBkl0dVF4RNMk7QEnB+lwoclm9zohBe+a+SbwwEUtuusIFodQzekpG/TPVMYK M+nbgsQK9+UOnlfeA2Bgg== Received: from vws10 (vws10.prod.google.com [10.241.21.138]) by kpbe12.cbf.corp.google.com with ESMTP id o45Hxp9j032112 for ; Wed, 5 May 2010 10:59:51 -0700 Received: by vws10 with SMTP id 10so2695262vws.23 for ; Wed, 05 May 2010 10:59:50 -0700 (PDT) Received: by 10.229.245.68 with SMTP id lt4mr4622548qcb.71.1273082388607; Wed, 05 May 2010 10:59:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Wed, 5 May 2010 10:59:26 -0700 (PDT) In-Reply-To: <4BE1AF25.7000308@lodderstedt.net> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> From: Evan Gilbert Date: Wed, 5 May 2010 10:59:26 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001485f9a73e8bf8610485dc974c X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:00:08 -0000 --001485f9a73e8bf8610485dc974c Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Even if not supported directly by the platform there are many JSON > libraries available these days. > It's not hard to add JSON support, but it's a factor in the choice. > > http://www.json.org/ lists 3 libraries for Objective-C alone. > > Moreover, the JSON documents we are discussing now are simple, something > like > > > { "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": > "8xLOxBtZp8" } > > Parsing such a document is not a challenge even without library support. > Per notes above - the client needs to do understand form encoding anyway. The client needs to parse the redirect_uri and also needs to generate form encoded requests. > > Regarding code size: What really matters on mobile devices from my point of > view is the size of data to be transmitted. Here, JSON is much more compact > than XML. > > regards, > Torsten. > > Am 05.05.2010 17:42, schrieb Marius Scurtescu: > > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav >> wrote: >> >> >>> I'll add something to the draft and we'll discuss it. There is enough >>> consensus on a single JSON response format. >>> >>> >> Yesterday I got the following feedback: >> >> On Tue, May 4, 2010 at 5:43 PM, Greg Robbins wrote: >> >> >>> Using JSON on the iPhone requires developers to drag in source code for a >>> third-party library. >>> >>> If their app isn't already relying on JSON for some other purpose, then >>> adding a third-party library is a somewhat substantial annoyance, >>> particularly for a mobile app where code size is important. >>> >>> If OAuth 2 is only intended for use with JSON APIs, then returning all >>> responses as JSON is reasonable. Otherwise, it's not so reasonable. A >>> full >>> JSON parser is non-trivial, and seems like overkill for simple responses. >>> >>> The iPhone OS does have libxml2 and an event-style XML parser, but no >>> really >>> easy way to extract data from XML, either. >>> >>> Form-style responses are much more straightforward to worth with given >>> simple string-manipulation utilities. >>> >>> >> If the above is true, then I am not so sure about JSON anymore. Lots >> of phones and devices will have problems with it. >> >> Marius >> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001485f9a73e8bf8610485dc974c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 5, 2010 at 10:47 AM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
Even if not supported directly by the platform there are many JSON librarie= s available these days.

It's not ha= rd to add JSON support, but it's a factor in the choice.
=A0

http://www.json.org/= lists 3 libraries for Objective-C alone.

Moreover, the JSON documents we are discussing now are simple, something li= ke


{ "access_token": "SlAV32hkKG", "expires_in":= "3600", "refresh_token": "8xLOxBtZp8" }

Parsing such a document is not a challenge even without library support.

Per notes above - the client needs to do understand = form encoding anyway. The client needs to parse the redirect_uri and also n= eeds to generate form encoded requests.
=A0

Regarding code size: What really matters on mobile devices from my point of= view is the size of data to be transmitted. Here, JSON is much more compac= t than XML.

regards,
Torsten.

Am 05.05.2010 17:42, schrieb Marius Scurtescu:

On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav<eran@hueniverse.com> =A0wrote: =A0
I'll add something to the draft and we'll discuss it. There is enou= gh consensus on a single JSON response format.
=A0 =A0
Yesterday I got the following feedback:

On Tue, May 4, 2010 at 5:43 PM, Greg Robbins<grobbins@google.com> =A0wrote:
=A0
Using JSON on the iPhone requires developers to drag in source code for a third-party library.

If their app isn't already relying on JSON for some other purpose, then=
adding a third-party library is a somewhat substantial annoyance,
particularly for a mobile app where code size is important.

If OAuth 2 is only intended for use with JSON APIs, then returning all
responses as JSON is reasonable. Otherwise, it's not so reasonable. A f= ull
JSON parser is non-trivial, and seems like overkill for simple responses.
The iPhone OS does have libxml2 and an event-style XML parser, but no reall= y
easy way to extract data from XML, either.

Form-style responses are much more straightforward to worth with given
simple string-manipulation utilities.
=A0 =A0
If the above is true, then I am not so sure about JSON anymore. Lots
of phones and devices will have problems with it.

Marius
=A0


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

--001485f9a73e8bf8610485dc974c-- From uidude@google.com Wed May 5 11:02:14 2010 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 336E63A6A50 for ; Wed, 5 May 2010 11:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.772 X-Spam-Level: X-Spam-Status: No, score=-101.772 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 0qhFJmDm52yW for ; Wed, 5 May 2010 11:02:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id AD9CA3A6A43 for ; Wed, 5 May 2010 11:02:12 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o45I1vSc025800 for ; Wed, 5 May 2010 11:01:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273082518; bh=UWJeWAcuN31++O/+w0hq0NJZ24s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jna6tHVFOymYplUqHz7nJ+DODPR5jDKVnycCEknmdm6LfZ9VIyDcmqz8VVAI8/UHA dwubMBloc97PoSQob07Pg== 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=INReENYecrghSpUAiMDRGuS0cQaTV5Q2uCNQLjaiWoU4Q5hKUdmpIbARzHOSLg64i CYF7oN1mPyT0EAV2PZBKQ== Received: from qyk34 (qyk34.prod.google.com [10.241.83.162]) by kpbe17.cbf.corp.google.com with ESMTP id o45I1R3W007447 for ; Wed, 5 May 2010 11:01:56 -0700 Received: by qyk34 with SMTP id 34so6485015qyk.10 for ; Wed, 05 May 2010 11:01:56 -0700 (PDT) Received: by 10.224.116.137 with SMTP id m9mr5872685qaq.162.1273082504176; Wed, 05 May 2010 11:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Wed, 5 May 2010 11:01:23 -0700 (PDT) In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> From: Evan Gilbert Date: Wed, 5 May 2010 11:01:23 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=00c09f9db11b6f4c690485dc9eec X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:02:14 -0000 --00c09f9db11b6f4c690485dc9eec Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert wrote: > > > On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Even if not supported directly by the platform there are many JSON >> libraries available these days. >> > > It's not hard to add JSON support, but it's a factor in the choice. > > >> >> http://www.json.org/ lists 3 libraries for Objective-C alone. >> >> Moreover, the JSON documents we are discussing now are simple, something >> like >> >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": >> "8xLOxBtZp8" } >> >> Parsing such a document is not a challenge even without library support. >> > > Per notes above - the client needs to do understand form encoding anyway. > The client needs to parse the redirect_uri and also needs to generate form > encoded requests. > Also, for the User-Agent flow, parsing potentially untrusted JSON in JavaScript is difficult. The normal path of using eval() is unsafe and leads to XSS holes - you need to run regex matcher to verify that the JSON content has no executable code. > > >> >> Regarding code size: What really matters on mobile devices from my point >> of view is the size of data to be transmitted. Here, JSON is much more >> compact than XML. >> >> regards, >> Torsten. >> >> Am 05.05.2010 17:42, schrieb Marius Scurtescu: >> >> On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav >>> wrote: >>> >>> >>>> I'll add something to the draft and we'll discuss it. There is enough >>>> consensus on a single JSON response format. >>>> >>>> >>> Yesterday I got the following feedback: >>> >>> On Tue, May 4, 2010 at 5:43 PM, Greg Robbins >>> wrote: >>> >>> >>>> Using JSON on the iPhone requires developers to drag in source code for >>>> a >>>> third-party library. >>>> >>>> If their app isn't already relying on JSON for some other purpose, then >>>> adding a third-party library is a somewhat substantial annoyance, >>>> particularly for a mobile app where code size is important. >>>> >>>> If OAuth 2 is only intended for use with JSON APIs, then returning all >>>> responses as JSON is reasonable. Otherwise, it's not so reasonable. A >>>> full >>>> JSON parser is non-trivial, and seems like overkill for simple >>>> responses. >>>> >>>> The iPhone OS does have libxml2 and an event-style XML parser, but no >>>> really >>>> easy way to extract data from XML, either. >>>> >>>> Form-style responses are much more straightforward to worth with given >>>> simple string-manipulation utilities. >>>> >>>> >>> If the above is true, then I am not so sure about JSON anymore. Lots >>> of phones and devices will have problems with it. >>> >>> Marius >>> >>> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --00c09f9db11b6f4c690485dc9eec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 5, 2010 at 10:59 AM, Evan Gi= lbert <uidude@goo= gle.com> wrote:


On Wed, May 5, 2010 at= 10:47 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Even if not supported directly by the platform there are many JSON librarie= s available these days.

It's = not hard to add JSON support, but it's a factor in the choice.
=A0

http://www.json.org/= lists 3 libraries for Objective-C alone.

Moreover, the JSON documents we are discussing now are simple, something li= ke


{ "access_token": "SlAV32hkKG", "expires_in":= "3600", "refresh_token": "8xLOxBtZp8" }

Parsing such a document is not a challenge even without library support.

Per notes above - the client needs to do under= stand form encoding anyway. The client needs to parse the redirect_uri and = also needs to generate form encoded requests.

Also, for the User-Agent flow, parsi= ng potentially untrusted JSON in JavaScript is difficult. The normal path o= f using eval() is unsafe and leads to XSS holes - you need to run regex mat= cher to verify that the JSON content has no executable code.
=A0
=A0

Regarding code size: What really matters on mobile devices from my point of= view is the size of data to be transmitted. Here, JSON is much more compac= t than XML.

regards,
Torsten.

Am 05.05.2010 17:42, schrieb Marius Scurtescu:

On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav<eran@hueniverse.com> =A0wrote: =A0
I'll add something to the draft and we'll discuss it. There is enou= gh consensus on a single JSON response format.
=A0 =A0
Yesterday I got the following feedback:

On Tue, May 4, 2010 at 5:43 PM, Greg Robbins<grobbins@google.com> =A0wrote:
=A0
Using JSON on the iPhone requires developers to drag in source code for a third-party library.

If their app isn't already relying on JSON for some other purpose, then=
adding a third-party library is a somewhat substantial annoyance,
particularly for a mobile app where code size is important.

If OAuth 2 is only intended for use with JSON APIs, then returning all
responses as JSON is reasonable. Otherwise, it's not so reasonable. A f= ull
JSON parser is non-trivial, and seems like overkill for simple responses.
The iPhone OS does have libxml2 and an event-style XML parser, but no reall= y
easy way to extract data from XML, either.

Form-style responses are much more straightforward to worth with given
simple string-manipulation utilities.
=A0 =A0
If the above is true, then I am not so sure about JSON anymore. Lots
of phones and devices will have problems with it.

Marius
=A0


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


--00c09f9db11b6f4c690485dc9eec-- From eran@hueniverse.com Wed May 5 11:09:57 2010 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 85F853A68D7 for ; Wed, 5 May 2010 11:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, 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 S4LMb6hhmMeA for ; Wed, 5 May 2010 11:09:55 -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 8DCDB3A6C54 for ; Wed, 5 May 2010 11:09:20 -0700 (PDT) Received: (qmail 10334 invoked from network); 5 May 2010 18:09:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 May 2010 18:09:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 5 May 2010 11:09:01 -0700 From: Eran Hammer-Lahav To: Evan Gilbert Date: Wed, 5 May 2010 11:09:11 -0700 Thread-Topic: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) Thread-Index: AcrsdWC1YhFGzjiGTZW4rp5ReJromwACJOSA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723439323D0EAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@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_90C41DD21FB7C64BB94121FBBC2E723439323D0EABP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:09:57 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723439323D0EABP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consensus is that JSON is the right format for token responses in the messa= ge body. As for the User Agent flow, that should remain form-encoded in the= fragment (I think). EHL From: Evan Gilbert [mailto:uidude@google.com] Sent: Wednesday, May 05, 2010 10:07 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal= ) On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav > wrote: I'll add something to the draft and we'll discuss it. There is enough conse= nsus on a single JSON response format. Responses that are returned via a browser URL should be application/x-www-f= orm-urlencoded. These parameters are standard to parse in any HTTP handling= library and JSON only adds complexity and external library requirements. I'm not positive we need to support JSON at all. But if we support both JSON and application/x-www-form-urlencoded, I think= the pattern should be: - application/x-www-form-urlencoded for requests/responses in a browser - JSON otherwise (including requests) EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Friday, April 30, 2010 2:00 AM > To: Brian Eaton > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > (Proposal) > > > Zitat von Brian Eaton >: > > > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore > > wrote: > >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland > > wrote: > >>> > >>> Can we please just have one format, not 3? The more choices we give > >>> the more interoperability suffers. > > > > Yes. The number of parsers needed to make a working system is > > important. The spec has too many already. > > > > I'd like to see authorization servers returning JSON or XML, since > > that's what the resource servers are doing. > > > > ...and given a choice between JSON and XML, I'd pick JSON. > > > > I agree. At Deutsche Telekom, we try to align our authorization APIs with= the > APIs provided by the resource servers. Authorization is "just" a small, b= ut > important, portion of the overall process and aligning it with the rest > increases acceptance and decreases error rate. > > None of the APIs we provide uses form encoding, most of them use JSON, > some XML. > Based on that observation I would like to see at least JSON support in OA= uth. > So JSON as the only would be fine with me. > > My proposal is based on the observation that the WG did not come to a > consensus about the one and only format. > > I have collected the following opinions from the thread: > > pro additional support for JSON and XML - Marius Scurtescu, John Jawed, > Richard Barnes, Brian Eaton, Torsten Lodderstedt pro additional support f= or > JSON - Dick Hardt (initiated the thread), Joseph Smarr still support > application/x-www-form-urlencoded (unclear whether > exclusively) - David Recordon, Gaurav Rastogi one format only (preference > unclear) - Yaron Goland JSON as the only format (if forced to decide for = a > single format) - Brian Eaton, Torsten Lodderstedt JSON as the only format= - > James Manger, Robert Sayre application/x-www-form-urlencoded as the > only format - Mike Moore JSON for responses as well - Marius Scurtescu > > Here are some representative comments from the thread: > > Joseph Smarr - "JSON is already widely supported (presumably including by > most APIs that you're building OAuth support to be able to access!" > > David Recordon - "it's drastically more complex for environments (like > embedded hardware) which doesn't support JSON." > > Paul C. Bryan - "I'm struggling to imagine hardware that on the one hand > would support OAuth, but on the other would be incapable of supporting > JSON..." > > Gaurav Rastogi - "There are enough number of small embedded software > stack where JSON is not an option." > > So we have at least 9 votes pro JSON, but also 1 vote for application/x-w= ww- > form-urlencoded only. > > How shall we proceed? Can we come to a consensus? > > regards, > Torsten. > > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723439323D0EABP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Consensus= is that JSON is the right format for token responses in the message body. = As for the User Agent flow, that should remain form-encoded in the fragment= (I think).

 

EHL

 

From: Evan Gilbert [mailto:uidude@google.com]
Sent:= Wednesday, May 05, 2010 10:07 AM
To: Eran Hammer-Lahav
Cc:= Torsten Lodderstedt; oauth@ietf.org
Subject: Re: [OAUTH-WG] = application/x-www-form-urlencoded vs JSON (Proposal)

<= /div>

 

 

On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I'll add something to the draft and we'll = discuss it. There is enough consensus on a single JSON response format.

 

Responses that are returned via a browser URL should be = ;application/x-www-form-urlencoded. These parameters are standard to parse = in any HTTP handling library and JSON only adds complexity and external lib= rary requirements.

 = ;

I'm not positive we need to supp= ort JSON at all.

 <= /o:p>

 But if we support both = JSON and application/x-www-form-urlencoded, I think the pattern should= be:

- application/x-www= -form-urlencoded for requests/responses in a browser

- JSON otherwise (including requests)

 

 


EHL=



> -----Original = Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
&g= t; Of Torsten Lodderstedt

>= ; Sent: Friday, April 30, 2010 2:00 AM
> To: Brian Eaton

> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG]= application/x-www-form-urlencoded vs JSON
> (Proposal)
>
&g= t;
> Zitat von Brian Eaton <beaton@google.com>:
>
> > On Thu, Ap= r 29, 2010 at 2:40 PM, Mike Moore <blowmage@gmail.com>
> wrote:
> >&g= t; On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland <yarong@microsoft.com>
> wr= ote:
> >>>
> >>> Can we please just have one = format, not 3? The more choices we give
> >>> the more inter= operability suffers.
> >
> > Yes.  The number of par= sers needed to make a working system is
> > important.  The s= pec has too many already.
> >
> > I'd like to see authori= zation servers returning JSON or XML, since
> > that's what the re= source servers are doing.
> >
> > ...and given a choice b= etween JSON and XML, I'd pick JSON.
> >
>
> I agree. A= t Deutsche Telekom, we try to align our authorization APIs with the
>= APIs provided by the resource servers. Authorization is "just" a= small, but
> important, portion of the overall process and aligning = it with the rest
> increases acceptance and decreases error rate.
= >
> None of the APIs we provide uses form encoding, most of them u= se JSON,
> some XML.
> Based on that observation I would like t= o see at least JSON support in OAuth.
> So JSON as the only would be = fine with me.
>
> My proposal is based on the observation that = the WG did not come to a
> consensus about the one and only format.>
> I have collected the following opinions from the thread:
= >
> pro additional support for JSON and XML - Marius Scurtescu, Jo= hn Jawed,
> Richard Barnes, Brian Eaton, Torsten Lodderstedt pro addi= tional support for
> JSON - Dick Hardt (initiated the thread), Joseph= Smarr still support
> application/x-www-form-urlencoded (unclear whe= ther
> exclusively) - David Recordon, Gaurav Rastogi one format only = (preference
> unclear) - Yaron Goland JSON as the only format (if for= ced to decide for a
> single format) - Brian Eaton, Torsten Lodderste= dt JSON as the only format -
> James Manger, Robert Sayre application= /x-www-form-urlencoded as the
> only format - Mike Moore JSON for res= ponses as well - Marius Scurtescu
>
> Here are some representat= ive comments from the thread:
>
> Joseph Smarr - "JSON is = already widely supported (presumably including by
> most APIs that yo= u're building OAuth support to be able to access!"
>
> Dav= id Recordon - "it's drastically more complex for environments (like> embedded hardware) which doesn't support JSON."
>
> = Paul C. Bryan - "I'm struggling to imagine hardware that on the one ha= nd
> would support OAuth, but on the other would be incapable of supp= orting
> JSON..."
>
> Gaurav Rastogi - "There a= re enough number of small embedded software
> stack where JSON is not= an option."
>
> So we have at least 9 votes pro JSON, but= also 1 vote for application/x-www-
> form-urlencoded only.
>> How shall we proceed? Can we come to a consensus?
>
> re= gards,
> Torsten.
>
> > Cheers,
> > Brian
= > > _______________________________________________
> > OAut= h mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/o= auth
> >
>
>
>
>
> _____________= __________________________________
> OAuth mailing list
> OAuth@ietf.org
> <= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth
__________________________= _____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723439323D0EABP3PW5EX1MB01E_-- From mscurtescu@google.com Wed May 5 11:11:43 2010 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 476163A6C33 for ; Wed, 5 May 2010 11:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.592 X-Spam-Level: X-Spam-Status: No, score=-101.592 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 BaqTn+g9e7u2 for ; Wed, 5 May 2010 11:11:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 2EBAF3A6A22 for ; Wed, 5 May 2010 11:10:41 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o45IAP8b005054 for ; Wed, 5 May 2010 11:10:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273083026; bh=EWGm4ejJ+4qh+UKwUqtNgxCVE8g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hqFMz9sgrYf74wJM0QU0A2ZQ/zxEjbgBC5MJR5LHxyUahGyGIge3z0cI3BXUe/E1U tD5w4SYev0OZwrPZoZmIg== 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=m6tAc2Anyn0NfkYrasTLqbbst7kA37NBTyTCDnFnLDplL5t3xoy/KXn98J9lLQNe4 qkNVg+2yWdm+PwuqoTmFA== Received: from pxi19 (pxi19.prod.google.com [10.243.27.19]) by kpbe18.cbf.corp.google.com with ESMTP id o45I9ZlX026816 for ; Wed, 5 May 2010 11:10:24 -0700 Received: by pxi19 with SMTP id 19so2304662pxi.17 for ; Wed, 05 May 2010 11:10:24 -0700 (PDT) Received: by 10.141.91.19 with SMTP id t19mr6050757rvl.104.1273083023392; Wed, 05 May 2010 11:10:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Wed, 5 May 2010 11:10:03 -0700 (PDT) In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 5 May 2010 11:10:03 -0700 Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:11:43 -0000 On Wed, May 5, 2010 at 9:16 AM, David Recordon wrote: > As long as we spec that the response can only contain one parameter (either > "error" or "access_token") then the code to parse it in PHP is as follows: > > list($param, $value) = explode('=', $response, 2); > if ($param == 'access_token') { > } elseif ($param == 'error') { > } > > If it can contain more than one value, then parsing becomes more difficult > and JSON starts to make sense. I's not that hard to convert the whole name/value pairs string to a hash. Parsing JSON by hand is much harder. Marius From mscurtescu@google.com Wed May 5 11:14:47 2010 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 908C428C114 for ; Wed, 5 May 2010 11:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.603 X-Spam-Level: X-Spam-Status: No, score=-101.603 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Aq--L1MqkY-5 for ; Wed, 5 May 2010 11:14:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id ED37A3A67FA for ; Wed, 5 May 2010 11:14:39 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o45IEO0J001960 for ; Wed, 5 May 2010 11:14:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273083265; bh=JLdTiQNYGUrlzanL61aoE/+qFkY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cnl6fnevO5zxbsxs1CqJlT2gAELXno+GpybuHh6hefLY8XwvfsDlb4ze/K5tnnexu nKNAw/xXhB2x+kK2i3TWg== 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=yjlrgtWOQJbwiHIT2NtrRJrIKHF3wH+nNEaH17x5Yg/KXFD9Sikni6P22Pqy5f/0P jwQ/2qQkcjKZ/NvC1zPSQ== Received: from pzk17 (pzk17.prod.google.com [10.243.19.145]) by kpbe16.cbf.corp.google.com with ESMTP id o45IEMEC012239 for ; Wed, 5 May 2010 11:14:23 -0700 Received: by pzk17 with SMTP id 17so2442742pzk.5 for ; Wed, 05 May 2010 11:14:22 -0700 (PDT) Received: by 10.140.247.19 with SMTP id u19mr5961563rvh.226.1273083262200; Wed, 05 May 2010 11:14:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Wed, 5 May 2010 11:14:02 -0700 (PDT) In-Reply-To: <4BE1AF25.7000308@lodderstedt.net> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> From: Marius Scurtescu Date: Wed, 5 May 2010 11:14:02 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:14:47 -0000 On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt wrote: > Even if not supported directly by the platform there are many JSON libraries > available these days. > > http://www.json.org/ lists 3 libraries for Objective-C alone. > > Moreover, the JSON documents we are discussing now are simple, something > like > > { "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": > "8xLOxBtZp8" } > > Parsing such a document is not a challenge even without library support. I never written such code, but I imagine it would be quite complicated and error prone. You have to deal with escaping, white spaces and nested data structures. Marius From uidude@google.com Wed May 5 11:15:51 2010 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 A2F3B3A68A0 for ; Wed, 5 May 2010 11:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.781 X-Spam-Level: X-Spam-Status: No, score=-101.781 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 41-tT3J-KBRt for ; Wed, 5 May 2010 11:15:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9A5683A683A for ; Wed, 5 May 2010 11:15:49 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o45IFYG8003487 for ; Wed, 5 May 2010 11:15:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273083335; bh=ynS7zKsw14Q7sg5dEv+f9pH9lnA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=H4kSJ+BQMaTp9NLo7g38UHHkYmcDqALUXRupzZjMGhD47TXJhNLlyV7Vz2qkFSIf+ zrOsDIgErlCpgfa8D19qw== 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=Z+S0uzAGHv1e4dhErKgPf5r6VFtE12tdgVZN2TfMtbBds+74SHF2DZUbnSliOGQxX wRZ6QsRGHxXqO3b2QaBOA== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by kpbe14.cbf.corp.google.com with ESMTP id o45IFGKD014619 for ; Wed, 5 May 2010 11:15:19 -0700 Received: by qyk30 with SMTP id 30so7652724qyk.16 for ; Wed, 05 May 2010 11:15:16 -0700 (PDT) Received: by 10.224.53.91 with SMTP id l27mr5943286qag.352.1273083312622; Wed, 05 May 2010 11:15:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Wed, 5 May 2010 11:14:52 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D0EAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723439323D0EAB@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Wed, 5 May 2010 11:14:52 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00c09f9db18aa006480485dccef2 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:15:51 -0000 --00c09f9db18aa006480485dccef2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 5, 2010 at 11:09 AM, Eran Hammer-Lahav wrote: > Consensus is that JSON is the right format for token responses in the > message body. As for the User Agent flow, that should remain form-encoded in > the fragment (I think). > I'm fine with JSON in the message body. I assume we would also use URL parameters for the Web App flow when redirecting with the verification code. > > > EHL > > > > *From:* Evan Gilbert [mailto:uidude@google.com] > *Sent:* Wednesday, May 05, 2010 10:07 AM > *To:* Eran Hammer-Lahav > *Cc:* Torsten Lodderstedt; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > (Proposal) > > > > > > On Wed, May 5, 2010 at 8:28 AM, Eran Hammer-Lahav > wrote: > > I'll add something to the draft and we'll discuss it. There is enough > consensus on a single JSON response format. > > > > Responses that are returned via a browser URL should > be application/x-www-form-urlencoded. These parameters are standard to parse > in any HTTP handling library and JSON only adds complexity and external > library requirements. > > > > I'm not positive we need to support JSON at all. > > > > But if we support both JSON and application/x-www-form-urlencoded, I think > the pattern should be: > > - application/x-www-form-urlencoded for requests/responses in a browser > > - JSON otherwise (including requests) > > > > > > > EHL > > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Torsten Lodderstedt > > > Sent: Friday, April 30, 2010 2:00 AM > > To: Brian Eaton > > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > > (Proposal) > > > > > > Zitat von Brian Eaton : > > > > > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore > > wrote: > > >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Goland > > wrote: > > >>> > > >>> Can we please just have one format, not 3? The more choices we give > > >>> the more interoperability suffers. > > > > > > Yes. The number of parsers needed to make a working system is > > > important. The spec has too many already. > > > > > > I'd like to see authorization servers returning JSON or XML, since > > > that's what the resource servers are doing. > > > > > > ...and given a choice between JSON and XML, I'd pick JSON. > > > > > > > I agree. At Deutsche Telekom, we try to align our authorization APIs with > the > > APIs provided by the resource servers. Authorization is "just" a small, > but > > important, portion of the overall process and aligning it with the rest > > increases acceptance and decreases error rate. > > > > None of the APIs we provide uses form encoding, most of them use JSON, > > some XML. > > Based on that observation I would like to see at least JSON support in > OAuth. > > So JSON as the only would be fine with me. > > > > My proposal is based on the observation that the WG did not come to a > > consensus about the one and only format. > > > > I have collected the following opinions from the thread: > > > > pro additional support for JSON and XML - Marius Scurtescu, John Jawed, > > Richard Barnes, Brian Eaton, Torsten Lodderstedt pro additional support > for > > JSON - Dick Hardt (initiated the thread), Joseph Smarr still support > > application/x-www-form-urlencoded (unclear whether > > exclusively) - David Recordon, Gaurav Rastogi one format only (preference > > unclear) - Yaron Goland JSON as the only format (if forced to decide for > a > > single format) - Brian Eaton, Torsten Lodderstedt JSON as the only format > - > > James Manger, Robert Sayre application/x-www-form-urlencoded as the > > only format - Mike Moore JSON for responses as well - Marius Scurtescu > > > > Here are some representative comments from the thread: > > > > Joseph Smarr - "JSON is already widely supported (presumably including by > > most APIs that you're building OAuth support to be able to access!" > > > > David Recordon - "it's drastically more complex for environments (like > > embedded hardware) which doesn't support JSON." > > > > Paul C. Bryan - "I'm struggling to imagine hardware that on the one hand > > would support OAuth, but on the other would be incapable of supporting > > JSON..." > > > > Gaurav Rastogi - "There are enough number of small embedded software > > stack where JSON is not an option." > > > > So we have at least 9 votes pro JSON, but also 1 vote for > application/x-www- > > form-urlencoded only. > > > > How shall we proceed? Can we come to a consensus? > > > > regards, > > Torsten. > > > > > 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --00c09f9db18aa006480485dccef2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 5, 2010 at 11:09 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

Consensus is that JSON i= s the right format for token responses in the message body. As for the User= Agent flow, that should remain form-encoded in the fragment (I think).


I'm fine with JSON in the = message body.

I assume we would also use URL parameters for t= he Web App flow when redirecting with the verification code.
=A0

=A0

EHL

=A0

Fr= om: Evan Gilbert [mailto:uidude@google.com] Sent: Wednesday, May 05, 2010 10:07 AM
To: Eran Hammer-Lah= av
Cc: Torsten Lodderstedt; oauth@ietf.org


Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSO= N (Proposal)

=A0

=A0

On Wed, May 5, 2010 at 8:28 AM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:

I'll add somet= hing to the draft and we'll discuss it. There is enough consensus on a = single JSON response format.

=A0

Respon= ses that are returned via a browser URL should be=A0application/x-www-form-= urlencoded. These parameters are standard to parse in any HTTP handling lib= rary and JSON only adds complexity and external library requirements.

=A0

= I'm not positive we need to support JSON at all.

=A0

=A0But if we=A0supp= ort both JSON and=A0application/x-www-form-urlencoded, I think the pattern = should be:

-=A0application/x-www-form-urlencoded for= requests/responses in a browser

- JSO= N otherwise (including requests)

=A0

=A0


= EHL



> -----Original Message-----
>= From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Torsten Lodderstedt

> Sent:= Friday, April 30, 2010 2:00 AM
> To: Brian Eaton

=

> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
&= gt; (Proposal)
>
>
> Zitat von Brian Eaton <beaton@google.com>:
>
> > On Thu, Apr 29, 2010 at 2:40 PM, Mike Moore <blowmage@gmail.com>=
> wrote:
> >> On Thu, Apr 29, 2010 at 2:49 PM, Yaron Gol= and <yarong@mi= crosoft.com>
> wrote:
> >>>
> >>> Can we please just ha= ve one format, not 3? The more choices we give
> >>> the mor= e interoperability suffers.
> >
> > Yes. =A0The number of= parsers needed to make a working system is
> > important. =A0The spec has too many already.
> >
>= > I'd like to see authorization servers returning JSON or XML, sinc= e
> > that's what the resource servers are doing.
> >=
> > ...and given a choice between JSON and XML, I'd pick JSON.> >
>
> I agree. At Deutsche Telekom, we try to align ou= r authorization APIs with the
> APIs provided by the resource servers= . Authorization is "just" a small, but
> important, portion of the overall process and aligning it with the res= t
> increases acceptance and decreases error rate.
>
> No= ne of the APIs we provide uses form encoding, most of them use JSON,
> some XML.
> Based on that observation I would like to see at lea= st JSON support in OAuth.
> So JSON as the only would be fine with me= .
>
> My proposal is based on the observation that the WG did n= ot come to a
> consensus about the one and only format.
>
> I have collec= ted the following opinions from the thread:
>
> pro additional = support for JSON and XML - Marius Scurtescu, John Jawed,
> Richard Ba= rnes, Brian Eaton, Torsten Lodderstedt pro additional support for
> JSON - Dick Hardt (initiated the thread), Joseph Smarr still support> application/x-www-form-urlencoded (unclear whether
> exclusive= ly) - David Recordon, Gaurav Rastogi one format only (preference
> un= clear) - Yaron Goland JSON as the only format (if forced to decide for a > single format) - Brian Eaton, Torsten Lodderstedt JSON as the only for= mat -
> James Manger, Robert Sayre application/x-www-form-urlencoded = as the
> only format - Mike Moore JSON for responses as well - Marius= Scurtescu
>
> Here are some representative comments from the thread:
>=
> Joseph Smarr - "JSON is already widely supported (presumably = including by
> most APIs that you're building OAuth support to be= able to access!"
>
> David Recordon - "it's drastically more complex for e= nvironments (like
> embedded hardware) which doesn't support JSON= ."
>
> Paul C. Bryan - "I'm struggling to imagine= hardware that on the one hand
> would support OAuth, but on the other would be incapable of supporting=
> JSON..."
>
> Gaurav Rastogi - "There are eno= ugh number of small embedded software
> stack where JSON is not an op= tion."
>
> So we have at least 9 votes pro JSON, but also 1 vote for appl= ication/x-www-
> form-urlencoded only.
>
> How shall we p= roceed? Can we come to a consensus?
>
> regards,
> Torste= n.
>
> > Cheers,
> > Brian
> > _________________= ______________________________
> > OAuth mailing list
> >= OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
&g= t;
>
>
>
> ________________________________________= _______
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oa= uth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

=A0


--00c09f9db18aa006480485dccef2-- From mscurtescu@google.com Wed May 5 11:18:22 2010 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 B1F483A6A46 for ; Wed, 5 May 2010 11:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.923 X-Spam-Level: X-Spam-Status: No, score=-105.923 tagged_above=-999 required=5 tests=[AWL=0.054, 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 vGhACQQZKYUa for ; Wed, 5 May 2010 11:18:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 775233A6A51 for ; Wed, 5 May 2010 11:18:20 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o45II6uh010798 for ; Wed, 5 May 2010 11:18:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273083487; bh=0U4b0BiDhdFo6K92AlkSus3uJeo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CFRq30xZYZ69E/wgcOdXkx74FgKM4UOUAUeEnbiX65gnuf+O510O3zYYiiQG+evar 0jEYke3cB7iQFaX0RWnmA== 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=QhX52XwY7BYPs+yl7wCTvru+nCi11KGSxx29hJC/29NTM2UEg5r6gFz4S0ywKklqG y+LcFGKB3Bi3v3uxFAUUA== Received: from pvg2 (pvg2.prod.google.com [10.241.210.130]) by wpaz29.hot.corp.google.com with ESMTP id o45II3L0008103 for ; Wed, 5 May 2010 11:18:05 -0700 Received: by pvg2 with SMTP id 2so611806pvg.10 for ; Wed, 05 May 2010 11:18:01 -0700 (PDT) Received: by 10.140.83.9 with SMTP id g9mr5867166rvb.6.1273083480436; Wed, 05 May 2010 11:18:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Wed, 5 May 2010 11:17:40 -0700 (PDT) In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 5 May 2010 11:17:40 -0700 Message-ID: To: Evan Gilbert Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:18:22 -0000 On Wed, May 5, 2010 at 10:06 AM, Evan Gilbert wrote: > > ... and JSON only adds complexity and external > library requirements. > > I'm not positive we need to support JSON at all. Tend to agree. Other than being nice, what other advantages does JSON provide? Keep in mind that most people voted for one format only, and that is clearly not possible, at a minimum we have to support both application/x-www-form-urlencoded and JSON. Marius From torsten@lodderstedt.net Wed May 5 11:20:41 2010 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 1AC153A6C33 for ; Wed, 5 May 2010 11:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_05=-1.11, HELO_EQ_DE=0.35] 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 hBMt-dYwLa7B for ; Wed, 5 May 2010 11:20:40 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id CAE553A6A4A for ; Wed, 5 May 2010 11:19:35 -0700 (PDT) Received: from p4fff1ebc.dip.t-dialin.net ([79.255.30.188] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1O9jBp-00053I-Hz; Wed, 05 May 2010 20:19:21 +0200 Message-ID: <4BE1B6A8.6050706@lodderstedt.net> Date: Wed, 05 May 2010 20:19:20 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:20:41 -0000 Am 05.05.2010 20:14, schrieb Marius Scurtescu: > On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt > wrote: > >> Even if not supported directly by the platform there are many JSON libraries >> available these days. >> >> http://www.json.org/ lists 3 libraries for Objective-C alone. >> >> Moreover, the JSON documents we are discussing now are simple, something >> like >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": >> "8xLOxBtZp8" } >> >> Parsing such a document is not a challenge even without library support. >> > I never written such code, but I imagine it would be quite complicated > and error prone. You have to deal with escaping, white spaces and > nested data structures. > > Marius > we don't need nested data structure (at least currently). Where do you see a need for escaping? regards, Torsten. From mscurtescu@google.com Wed May 5 11:28:08 2010 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 231CB28C142 for ; Wed, 5 May 2010 11:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.925 X-Spam-Level: X-Spam-Status: No, score=-105.925 tagged_above=-999 required=5 tests=[AWL=0.052, 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 huDVodxvFXaa for ; Wed, 5 May 2010 11:28:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8DE8C28C132 for ; Wed, 5 May 2010 11:26:06 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o45IPqVA006413 for ; Wed, 5 May 2010 11:25:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273083952; bh=TXwENLL1895kVimcDRWDMBJwjZw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Sqx5+QnhhVqVcXjlksQX7rnmgdd8kLNuNEcNL5FeeABmrwUHGwoamL1SngP+Gzz1v CVtW0QdYVsOoL8zyfj5Ww== 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:content-transfer-encoding:x-system-of-record; b=lgcnYAeu8kVxgsHT7NFyPsyTZMJ46MUSRLjYazUUaIO6Aeq3LRHndklSqETBaWhKs 6uNXtS1m203Y6+EraTgfw== Received: from pvg7 (pvg7.prod.google.com [10.241.210.135]) by kpbe11.cbf.corp.google.com with ESMTP id o45IPpYR000479 for ; Wed, 5 May 2010 11:25:51 -0700 Received: by pvg7 with SMTP id 7so437264pvg.8 for ; Wed, 05 May 2010 11:25:51 -0700 (PDT) Received: by 10.141.90.1 with SMTP id s1mr5848368rvl.57.1273083951036; Wed, 05 May 2010 11:25:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Wed, 5 May 2010 11:25:29 -0700 (PDT) In-Reply-To: <4BE1B6A8.6050706@lodderstedt.net> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1B6A8.6050706@lodderstedt.net> From: Marius Scurtescu Date: Wed, 5 May 2010 11:25:29 -0700 Message-ID: To: Torsten Lodderstedt 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] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:28:08 -0000 On Wed, May 5, 2010 at 11:19 AM, Torsten Lodderstedt wrote: > Am 05.05.2010 20:14, schrieb Marius Scurtescu: >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt >> =A0wrote: >> >>> >>> Even if not supported directly by the platform there are many JSON >>> libraries >>> available these days. >>> >>> http://www.json.org/ lists 3 libraries for Objective-C alone. >>> >>> Moreover, the JSON documents we are discussing now are simple, somethin= g >>> like >>> >>> { "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": >>> "8xLOxBtZp8" } >>> >>> Parsing such a document is not a challenge even without library support= . >>> >> >> I never written such code, but I imagine it would be quite complicated >> and error prone. You have to deal with escaping, white spaces and >> nested data structures. >> >> Marius >> > > we don't need nested data structure (at least currently). Where do you se= e a > need for escaping? How do you represent " { } , and : inside names and values? You probably need full blown lexer and parser for JSON. Marius From mscurtescu@google.com Wed May 5 11:36:33 2010 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 946583A6A58 for ; Wed, 5 May 2010 11:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.927 X-Spam-Level: X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=0.050, 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 39HbYAwOqyMr for ; Wed, 5 May 2010 11:36:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5EF943A697C for ; Wed, 5 May 2010 11:36:28 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o45IaD3P011061 for ; Wed, 5 May 2010 11:36:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273084573; bh=zFOz0vqYYRnoK1GztFElv26XP1M=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AGfQh2JiCcKd3lCRdC93FYLEjT5TobER3TAUbu2RCDG3P825VuBwEeBvZGnZ+TiSE 6LkQF2gF//meIf+80j1Lw== 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=PpgmPv0SXLvidm6bHC6Sy2ZatXsJAUrDuhuDbo6mn/bbuA9A3p0w2J8P+Qq3tJe6Q nP2Wv8gXZ85fZ9OLvg7IA== Received: from pxi2 (pxi2.prod.google.com [10.243.27.2]) by wpaz21.hot.corp.google.com with ESMTP id o45IZraS010838 for ; Wed, 5 May 2010 11:36:12 -0700 Received: by pxi2 with SMTP id 2so2650961pxi.25 for ; Wed, 05 May 2010 11:36:12 -0700 (PDT) Received: by 10.140.88.33 with SMTP id l33mr5817298rvb.4.1273084572274; Wed, 05 May 2010 11:36:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.14.15 with HTTP; Wed, 5 May 2010 11:35:52 -0700 (PDT) In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 5 May 2010 11:35:52 -0700 Message-ID: To: John Jawed Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:36:33 -0000 On Wed, May 5, 2010 at 11:29 AM, John Jawed wrote: > JSON markup is lighter than XML markup. Yes, but I don't think XML was an option anymore. The question is between: 1. application/x-www-form-urlencoded 2. application/x-www-form-urlencoded and JSON Marius > > On Wed, May 5, 2010 at 11:17 AM, Marius Scurtescu wrote: >> On Wed, May 5, 2010 at 10:06 AM, Evan Gilbert wrote: >>> >>> ... and JSON only adds complexity and external >>> library requirements. >>> >>> I'm not positive we need to support JSON at all. >> >> Tend to agree. >> >> Other than being nice, what other advantages does JSON provide? >> >> Keep in mind that most people voted for one format only, and that is >> clearly not possible, at a minimum we have to support both >> application/x-www-form-urlencoded and JSON. >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From torsten@lodderstedt.net Wed May 5 11:38:28 2010 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 EFC2D3A6989 for ; Wed, 5 May 2010 11:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_40=-0.185, HELO_EQ_DE=0.35, 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 sGCtjpmnJH0x for ; Wed, 5 May 2010 11:38:27 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by core3.amsl.com (Postfix) with ESMTP id AD61328C12F for ; Wed, 5 May 2010 11:38:24 -0700 (PDT) Received: from p4fff1ebc.dip.t-dialin.net ([79.255.30.188] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1O9jU2-0007Ng-Bg; Wed, 05 May 2010 20:38:10 +0200 Message-ID: <4BE1BB10.7060009@lodderstedt.net> Date: Wed, 05 May 2010 20:38:08 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Evan Gilbert References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BD9E1E3.7060107@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A3EF0B0@TK5EX14MBXC115.redmond.corp.microsoft.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030404090108000804000100" X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:38:29 -0000 This is a multi-part message in MIME format. --------------030404090108000804000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 05.05.2010 20:01, schrieb Evan Gilbert: > > > On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert > wrote: > > > > On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt > > wrote: > > Even if not supported directly by the platform there are many > JSON libraries available these days. > > > It's not hard to add JSON support, but it's a factor in the choice. > > > http://www.json.org/ lists 3 libraries for Objective-C alone. > > Moreover, the JSON documents we are discussing now are simple, > something like > > > { "access_token": "SlAV32hkKG", "expires_in": "3600", > "refresh_token": "8xLOxBtZp8" } > > Parsing such a document is not a challenge even without > library support. > > > Per notes above - the client needs to do understand form encoding > anyway. The client needs to parse the redirect_uri and also needs > to generate form encoded requests. > > > Also, for the User-Agent flow, parsing potentially untrusted JSON in > JavaScript is difficult. The normal path of using eval() is unsafe and > leads to XSS holes - you need to run regex matcher to verify that the > JSON content has no executable code. You are right, using eval to parse JSON is dangerous and thus as far as I understand, the recommended way is to use a JSON parser (aka native JSON support)? regards, Torsten. --------------030404090108000804000100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am 05.05.2010 20:01, schrieb Evan Gilbert:


On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert <uidude@google.com> wrote:


On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Even if not supported directly by the platform there are many JSON libraries available these days.

It's not hard to add JSON support, but it's a factor in the choice.
 

http://www.json.org/ lists 3 libraries for Objective-C alone.

Moreover, the JSON documents we are discussing now are simple, something like


{ "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": "8xLOxBtZp8" }

Parsing such a document is not a challenge even without library support.

Per notes above - the client needs to do understand form encoding anyway. The client needs to parse the redirect_uri and also needs to generate form encoded requests.

Also, for the User-Agent flow, parsing potentially untrusted JSON in JavaScript is difficult. The normal path of using eval() is unsafe and leads to XSS holes - you need to run regex matcher to verify that the JSON content has no executable code.

You are right, using eval to parse JSON is dangerous and thus as far as I understand, the recommended way is to use a JSON parser (aka native JSON support)?

regards,
Torsten.
--------------030404090108000804000100-- From dewitt@unto.net Wed May 5 11:50:35 2010 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 26E743A6C45 for ; Wed, 5 May 2010 11:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ybfxU2renZV0 for ; Wed, 5 May 2010 11:50:33 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with SMTP id 6F0EA3A6C3D for ; Wed, 5 May 2010 11:50:32 -0700 (PDT) Received: from source ([209.85.161.42]) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKS+G962dHIvxlLCj8niIni18dZ19jizOQ@postini.com; Wed, 05 May 2010 11:50:19 PDT Received: by fxm15 with SMTP id 15so4162750fxm.1 for ; Wed, 05 May 2010 11:50:18 -0700 (PDT) Received: by 10.239.188.194 with SMTP id q2mr1504323hbh.36.1273085418194; Wed, 05 May 2010 11:50:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.162.68 with HTTP; Wed, 5 May 2010 11:49:58 -0700 (PDT) In-Reply-To: <4BE1BB10.7060009@lodderstedt.net> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> From: DeWitt Clinton Date: Wed, 5 May 2010 11:49:58 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001485f4507a1ec94e0485dd4cd5 Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 05 May 2010 18:50:35 -0000 --001485f4507a1ec94e0485dd4cd5 Content-Type: text/plain; charset=ISO-8859-1 Having written more than one compliant JSON parser myself, it is most certainly not "trivial", and not something that can be safely done with a regular expression or other hacks. That said, it's not *hard*, and that alone is no reason not to mandate JSON, but I do want people to be clear about what mandating JSON means. Clients will need a fully compliant parser. Period. If the OAuth spec requires JSON, then it should require it by reference to RFC 4627, not just by giving some examples that demonstrate the curly braces. -DeWitt On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Am 05.05.2010 20:01, schrieb Evan Gilbert: > > > > On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert wrote: > >> >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Even if not supported directly by the platform there are many JSON >>> libraries available these days. >>> >> >> It's not hard to add JSON support, but it's a factor in the choice. >> >> >>> >>> http://www.json.org/ lists 3 libraries for Objective-C alone. >>> >>> Moreover, the JSON documents we are discussing now are simple, something >>> like >>> >>> >>> { "access_token": "SlAV32hkKG", "expires_in": "3600", "refresh_token": >>> "8xLOxBtZp8" } >>> >>> Parsing such a document is not a challenge even without library support. >>> >> >> Per notes above - the client needs to do understand form encoding anyway. >> The client needs to parse the redirect_uri and also needs to generate form >> encoded requests. >> > > Also, for the User-Agent flow, parsing potentially untrusted JSON in > JavaScript is difficult. The normal path of using eval() is unsafe and leads > to XSS holes - you need to run regex matcher to verify that the JSON content > has no executable code. > > > You are right, using eval to parse JSON is dangerous and thus as far as I > understand, the recommended way is to use a JSON parser (aka native JSON > support)? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001485f4507a1ec94e0485dd4cd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Having written more than one compliant JSON parser myself, it is most certa= inly not "trivial", and not something that can be safely done wit= h a regular expression or other hacks.

That said, it'= ;s not hard, and that alone is no reason not to mandate JSON, but I = do want people to be clear about what mandating JSON means. =A0Clients will= need a fully compliant parser. =A0Period. =A0If the OAuth spec requires JS= ON, then it should require it by reference to RFC=A04627, not just by givin= g some examples that demonstrate the curly braces.

-DeWitt


On = Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20
Am 05.05.2010 20:01, schrieb Evan Gilbert:


On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert <uidude@google.com> wrote:


On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Even if not supported directly by the platform there are many JSON libraries available these days.

It's not hard to add JSON support, but it's a factor in th= e choice.
=A0

http://www.json.or= g/ lists 3 libraries for Objective-C alone.

Moreover, the JSON documents we are discussing now are simple, something like


{ "access_token": "SlAV32hkKG", "expires_in":= "3600", "refresh_token": "8xLOxBtZp8" }

Parsing such a document is not a challenge even without library support.

Per notes above - the client needs to do understand form encoding anyway. The client needs to parse the redirect_uri and also needs to generate form encoded requests.

Also, for the User-Agent flow, parsing potentially untrusted JSON in JavaScript is difficult. The normal path of using eval() is unsafe and leads to XSS holes - you need to run regex matcher to verify that the JSON content has no executable code.

You are right, using eval to parse JSON is dangerous and thus as far as I understand, the recommended way is to use a JSON parser (aka native JSON support)?

regards,
Torsten.

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


--001485f4507a1ec94e0485dd4cd5-- From torsten@lodderstedt.net Wed May 5 12:28:33 2010 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 492E128C17D for ; Wed, 5 May 2010 12:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_40=-0.185, HELO_EQ_DE=0.35] 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 d-1ohs1EPPRD for ; Wed, 5 May 2010 12:28:32 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id 5826028C12F for ; Wed, 5 May 2010 12:28:32 -0700 (PDT) Received: from p4fff1ebc.dip.t-dialin.net ([79.255.30.188] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1O9kGX-0006nW-4m; Wed, 05 May 2010 21:28:17 +0200 Message-ID: <4BE1C6D0.6010600@lodderstedt.net> Date: Wed, 05 May 2010 21:28:16 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: <4BE06831.60105@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh tokens security enhancement 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, 05 May 2010 19:28:33 -0000 Am 04.05.2010 21:44, schrieb Marius Scurtescu: > On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt > wrote: > >> Am 03.05.2010 18:55, schrieb Allen Tom: >> >>> Invalidating the Refresh Token (and presumably also invalidating any >>> outstanding Access Tokens) would make sense as an option for applications >>> that require a high level of security. However, I do not think that >>> invalidating the Refresh Token on every Refresh request should be required >>> in the spec - it should be an implementation specific detail. >>> >>> >> It could be an optional feature of the spec (as many other features). >> > Torsten, can you please have a look a the "explicit request for > refresh token" thread? > > Would a "refresh_token_type=single" parameter solve the above? > > > Marius > Hi Marius, I expected the authorization server to decide which kind of token to use. Your proposal makes sense as well. So the client can act according to its security requirements. If the authorization server would like to enforce its own policy, it can detect any mismatch during token issuance. Nevertheless, support for the optional "refresh_token" response parameter of the "refresh" request is the prerequisite. regards, Torsten. From pid@pidster.com Wed May 5 15:35:43 2010 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 E44FA3A6D3B for ; Wed, 5 May 2010 15:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 tKfAoin1ijFU for ; Wed, 5 May 2010 15:35:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 52DA73A6AAD for ; Wed, 5 May 2010 15:35:41 -0700 (PDT) Received: by wyb32 with SMTP id 32so1944580wyb.31 for ; Wed, 05 May 2010 15:35:25 -0700 (PDT) Received: by 10.227.137.135 with SMTP id w7mr3272913wbt.10.1273098923641; Wed, 05 May 2010 15:35:23 -0700 (PDT) Received: from Phoenix.local (cpc2-lewi13-2-0-cust269.2-4.cable.virginmedia.com [86.14.119.14]) by mx.google.com with ESMTPS id z33sm2071322wbd.19.2010.05.05.15.35.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 May 2010 15:35:22 -0700 (PDT) Message-ID: <4BE1F2A1.9040707@pidster.com> Date: Wed, 05 May 2010 23:35:13 +0100 From: Pid Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "oauth@ietf.org" References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCBBADDB7E2976075E9676727" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pid@pidster.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 22:35:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBBADDB7E2976075E9676727 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/05/2010 19:49, DeWitt Clinton wrote: > Having written more than one compliant JSON parser myself, it is most > certainly not "trivial", and not something that can be safely done with= > a regular expression or other hacks. >=20 > That said, it's not /hard/, and that alone is no reason not to mandate > JSON, but I do want people to be clear about what mandating JSON means.= > Clients will need a fully compliant parser. Period. If the OAuth spe= c > requires JSON, then it should require it by reference to RFC 4627, not > just by giving some examples that demonstrate the curly braces. >=20 > -DeWitt I know it's late, but can I add my 2 cents - as a developer who'll be implementing this? In the original post, Dick suggested that developers were having trouble with the URL encoding format - but I respectfully suggest that JSON is going to be more problematic. There's no guarantee that an external JSON parser will be available for a given platform/language/business, (perhaps because of licensing, if not other more technical reasons). So that means writing one. Writing a JSON parser just to cover the simple usage proposed won't be too tricky, but if the JSON response is so simple why bother adding this dependency at all? I'm slightly baffled... URL encoding is required for at least one flow, so IMHO it might as well stay for the rest. Simplicity is important. Can someone from the pro-JSON side offer a clearer explanation as to the benefits, so I can stop scratching my head about it all, please? Respectfully, Pid > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt > > wrote: >=20 > Am 05.05.2010 20:01, schrieb Evan Gilbert: >> >> >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert > > wrote: >> >> >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt >> > wro= te: >> >> Even if not supported directly by the platform there are >> many JSON libraries available these days. >> >> >> It's not hard to add JSON support, but it's a factor in the >> choice. >> =20 >> >> >> http://www.json.org/ lists 3 libraries for Objective-C alo= ne. >> >> Moreover, the JSON documents we are discussing now are >> simple, something like >> >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600", >> "refresh_token": "8xLOxBtZp8" } >> >> Parsing such a document is not a challenge even without >> library support. >> >> >> Per notes above - the client needs to do understand form >> encoding anyway. The client needs to parse the redirect_uri >> and also needs to generate form encoded requests. >> >> >> Also, for the User-Agent flow, parsing potentially untrusted JSON >> in JavaScript is difficult. The normal path of using eval() is >> unsafe and leads to XSS holes - you need to run regex matcher to >> verify that the JSON content has no executable code. >=20 > You are right, using eval to parse JSON is dangerous and thus as fa= r > as I understand, the recommended way is to use a JSON parser (aka > native JSON support)? >=20 > regards, > Torsten. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------enigCBBADDB7E2976075E9676727 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQIVAwUBS+HyqGoM2OGpOvr9AQrzrA//byuaxvQ3AMfiy5Q6SiXvm/4H+u1CVuFK NAx7i+BwPaJEAz63Yk7UJuyftWVo6bti8kAZ/NRMDIb5+uUlGA/c62mTUh+j3pQP 093lK+bdPr1Th/wyEOmiwXdwnP2zRjiR6dEKew+5/DNmAXPgJ4LLnnQbiaTfH/t+ IQa6ytgdJM6VkZVJrlZGuQvNN6iFiMMrHi3ZjbV4Q2eQf3dirrRpeHxaWkeF2ziB to7aGTXjHKCQ5uXxsKG1TH2jMpfI4/AKV1+TFWt8x7ttlY4ZrxVV633pXujbIB3L Dz1x93ONNA95xZ5WBDcaR8jlSi5NfzPYmjMIVYAzBpBLyhqExPKgcIKBzmvE7Z4r WedVIiUaK09FtU/tIA6v++2Bqt0rO0puEw5rDxeCu6mXELoLhflV5H06m/qUGAuu aPuB9nLc6v/2SbEt03xUH/wo+NVYUdnK1AMwb1+FZkU8CgtUgJYzzEmI2H1zjRUv XiJPRIry8qzF6TTiaBPeGhGtnvUHoJVNVaXXtbw1PEkIcRTtiaFATr+fqV2PTQHO EwIo5r0eF2PyGXf3rTbtjgzuUk6giu/ZMWu8eWdYiDLkHvKYvbhh2WmOcf+Yt4i4 +u17iy0XTduhM0+o/cGwsWh95E0RsgZNY3ZvwwT9kBocA5IIVaFPVwLvccLJUp2+ nipd87EER+0= =go1A -----END PGP SIGNATURE----- --------------enigCBBADDB7E2976075E9676727-- From recordond@gmail.com Wed May 5 22:14:19 2010 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 C896D3A69B2 for ; Wed, 5 May 2010 22:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[AWL=-1.479, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] 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 HEER0-KhyL2m for ; Wed, 5 May 2010 22:14:06 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 6C6783A6A1E for ; Wed, 5 May 2010 22:14:05 -0700 (PDT) Received: by iwn27 with SMTP id 27so7373021iwn.5 for ; Wed, 05 May 2010 22:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=wLJHi2Juhush+VyD10YDqUxTjWHfB6Y/xhrLEFW5Ook=; b=n1xA6hmNMy1LqH15ursK610dm0RPvsDPv8Lc8x2dUueK2jF8DdahwJ0Qdq85hdRh1T NVnX4aJqiWbcDm1c92mpIB4TqaDFuSW4m19Eb8IYz6k7FqputijCP0snjyQtZpWKNuj6 HjfUvaOj+IfWZ7eEH4Cy5ub6lmYGp6Fx4V62U= 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 :content-type; b=aL8kwHJBpXTdA5TyRa+OB6vQebeYrZhzayLZkskYxz8kIsShzOhVpEzU9yT6oURrVP 38OSi4pBhjDBqE0LckUX3kRQbBWNSGSKVxSvxva1QizfO054YcgVefUlcCGYbB+HnEl4 S62bREFMBizZ4U5ByTILBHKuNrjdUiw1HupjE= MIME-Version: 1.0 Received: by 10.231.166.85 with SMTP id l21mr607546iby.14.1273122831984; Wed, 05 May 2010 22:13:51 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Wed, 5 May 2010 22:13:51 -0700 (PDT) In-Reply-To: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> References: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> Date: Wed, 5 May 2010 22:13:51 -0700 Message-ID: From: David Recordon To: OAuth WG , Blaine Cook Content-Type: multipart/alternative; boundary=001636d33ad327e9940485e60222 Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI 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, 06 May 2010 05:14:20 -0000 --001636d33ad327e9940485e60222 Content-Type: text/plain; charset=ISO-8859-1 +OAuth IETF list -WRAP list to BCC Hi Kevin, OAuth 2.0 should be pretty simple for you to implement and any feedback your team has would be really appreciated! There are already implementations in Cocoa, Python, and Ruby list on the wiki at http://wiki.oauth.net/OAuth-2.0and you find find the spec at http://tools.ietf.org/html/draft-hammer-oauth2-00. You may also be interested in the mobile web implementation we've built at Facebook. http://developers.facebook.com/docs/guides/mobile/ I'm also cc'ing Blaine Cook who lives in Ireland and might be able to present. Cheers, --David On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone < mrkrcsmith@googlemail.com> wrote: > Dear OAUTH WRAP group, > > My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile > operator project called OneAPI ('Open Network Enablers') [1]. The aim > is to provide a RESTful API to expose network functions such as > location, messaging, payments and more to developers; with the > reckoning that this will make it far easier to mash-up Web > applications with network capabilities and reduce the time to reach > all mobile subscribers in a territory. Thus far we have a live pilot > implementation across the 3 major Canadian operators [2] and a non- > commercial test site connected to > 12 European operators [3], and will be releasing v1.0 specifications > backed by the OMA this month. > > For the first release we did not attempt to prescribe an AAA model to > operators, instead leaving them to reuse their own SDP AAA > implementation for OneAPI. For our second phase now underway we would > like to provide a recommended reference implementation AAA model for > operators who are unsure how to allow secure API access whilst > allowing user consent and privacy to be respected. Therefore we have > discussed OAUTH as an ideal candidate that will be well-known to Web > developers. > > My question regards the suitability of WRAP for such a reference > implementation: the decoupling of authentication is good sense and > would be welcome by operators, however it appears that WRAP is > deprecated and is intended to be replaced by OAUTH 2.0 - is that > right? Please could you provide any details on the plans for if/how > the two will interoperate? If it's at all possible, we would very much > welcome a member of the group to present on WRAP at one of our face-to- > face meetings in London - if that is of interest please let me know > and I can make arrangements. > > Thanks for your time and look forward to your advice. > > Kind regards, > Kevin > > [1] http://www.gsmworld.com/oneapi > [2] http://canada.oneapi.gsmworld.com/ > [3] http://oneapi.aepona.com/ > > Kevin Smith > Senior Technology Strategist, R&D > Vodafone Technology > > E-mail: kevin.smith@vodafone.com > > -- > You received this message because you are subscribed to the Google Groups > "OAuth WRAP WG" group. > To post to this group, send email to oauth-wrap-wg@googlegroups.com. > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscribe@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > --001636d33ad327e9940485e60222 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+OAuth IETF list
-WRAP list to BCC

Hi Ke= vin,
OAuth 2.0 should be pretty simple for you to implement and any fee= dback your team has would be really appreciated! There are already implemen= tations in Cocoa, Python, and Ruby list on the wiki at=A0http://wiki.oauth.net/OAuth-2.0 and you find = find the spec at=A0http://tools.ietf.org/html/draft-hammer-oauth2-00.

You may also be interested in the mobile web implementa= tion we've built at Facebook.=A0http://developers.facebook.com/docs/guides/mobile/<= /a>

I'm also cc'ing Blaine Cook who lives in Irelan= d and might be able to present.

Cheers,
= --David


On Tue, May 4, 2010 at= 4:20 AM, Kevin Smith, Vodafone <mrkrcsmith@googlemail.com> wrote:
Dear OAUTH WRAP group,

My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile
operator project called OneAPI ('Open Network Enablers') [1]. The a= im
is to provide a RESTful API to expose network functions such as
location, messaging, payments and more to developers; with the
reckoning that this will make it far easier to mash-up Web
applications with network capabilities and reduce the time to reach
all mobile subscribers in a territory. Thus far we have a live pilot
implementation across the 3 major Canadian operators [2] and a non-
commercial test site connected to
12 European operators [3], and will be releasing v1.0 specifications
backed by the OMA this month.

For the first release we did not attempt to prescribe an AAA model to
operators, instead leaving them to reuse their own SDP AAA
implementation for OneAPI. For our second phase now underway we would
like to provide a recommended reference implementation AAA model for
operators who are unsure how to allow secure API access whilst
allowing user consent and privacy to be respected. Therefore we have
discussed OAUTH as an ideal candidate that will be well-known to Web
developers.

My question regards the suitability of WRAP for such a reference
implementation: the decoupling of authentication is good sense and
would be welcome by operators, however it appears that WRAP is
deprecated and is intended to be replaced by OAUTH 2.0 - is that
right? =A0Please could you provide any details on the plans for if/how
the two will interoperate? If it's at all possible, we would very much<= br> welcome a member of the group to present on WRAP at one of our face-to-
face meetings in London - if that is of interest please let me know
and I can make arrangements.

Thanks for your time and look forward to your advice.

Kind regards,
Kevin

[1] http://www= .gsmworld.com/oneapi
[2] http:/= /canada.oneapi.gsmworld.com/
[3] http://oneapi.a= epona.com/

Kevin Smith
Senior Technology Strategist, R&D
Vodafone Technology

E-mail: kevin.smith@vodafone.co= m

--
You received this message because you are subscribed to the Google Groups &= quot;OAuth WRAP WG" group.
To post to this group, send email to oauth-wrap-wg@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-wg+unsubscribe@googlegroups.c= om.
For more options, visit this group at http://groups.google.com/grou= p/oauth-wrap-wg?hl=3Den.


--001636d33ad327e9940485e60222-- From James.H.Manger@team.telstra.com Wed May 5 23:48:30 2010 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 A23F33A6A79 for ; Wed, 5 May 2010 23:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.492 X-Spam-Level: * X-Spam-Status: No, score=1.492 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EX8vMAyAUiUd for ; Wed, 5 May 2010 23:48:28 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id CCECD3A6AD8 for ; Wed, 5 May 2010 23:48:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,339,1270389600"; d="scan'208,217";a="2446643" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 06 May 2010 16:48:14 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5973"; a="1598746" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccvi.tcif.telstra.com.au with ESMTP; 06 May 2010 16:48:14 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 6 May 2010 16:48:13 +1000 From: "Manger, James H" To: David Recordon , OAuth WG , "oauth-wrap-wg@googlegroups.com" Date: Thu, 6 May 2010 16:48:12 +1000 Thread-Topic: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI Thread-Index: Acrs2ve6UI+wx5v9Seu89IHJ0dbpIQAC/rMg Message-ID: <255B9BB34FB7D647A506DC292726F6E112630738DB@WSMSG3153V.srv.dir.telstra.com> References: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112630738DBWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI 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, 06 May 2010 06:48:30 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112630738DBWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZHJhZnQtaWV0Zi1vYXV0aC12MiBpcyB0aGUgY3VycmVudCBkb2N1bWVudC4NCg0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mg0KDQoNCg0KVGhlIElFVEYgc3Rh dHVzIHBhZ2UgZm9yIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIGlzIGEgZ29vZCBwbGFjZSB0byBw b2ludCB0bzoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL29hdXRoLw0KDQpJdCBsaW5rcyB0 byB0aGUgbGF0ZXN0IGRyYWZ0cywgbWFpbGluZyBsaXN0LCBldGMuDQoNCg0KDQooRXJhbuKAmXMg aW5kaXZpZHVhbCBzdWJtaXNzaW9uIGRyYWZ0LWhhbW1lci1vYXV0aDIgYmVjYW1lIHRoZSBJRVRG IHdvcmtpbmcgZ3JvdXAgZHJhZnQgZHJhZnQtaWV0Zi1vYXV0aC12MikNCg0KDQoNCkRhdmlkLCB3 b3VsZCB5b3UgbGlrZSB0byB1cGRhdGUgaHR0cDovL3dpa2kub2F1dGgubmV0L09BdXRoLTIuMD8N Cg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQoNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBS ZWNvcmRvbg0KU2VudDogVGh1cnNkYXksIDYgTWF5IDIwMTAgMzoxNCBQTQ0KVG86IE9BdXRoIFdH OyBCbGFpbmUgQ29vaw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gW1dSQVBdIFdSQVAgaW4gR1NN QSBPbmVBUEkNCg0KDQoNCitPQXV0aCBJRVRGIGxpc3QNCg0KLVdSQVAgbGlzdCB0byBCQ0MNCg0K DQoNCkhpIEtldmluLA0KDQpPQXV0aCAyLjAgc2hvdWxkIGJlIHByZXR0eSBzaW1wbGUgZm9yIHlv dSB0byBpbXBsZW1lbnQgYW5kIGFueSBmZWVkYmFjayB5b3VyIHRlYW0gaGFzIHdvdWxkIGJlIHJl YWxseSBhcHByZWNpYXRlZCEgVGhlcmUgYXJlIGFscmVhZHkgaW1wbGVtZW50YXRpb25zIGluIENv Y29hLCBQeXRob24sIGFuZCBSdWJ5IGxpc3Qgb24gdGhlIHdpa2kgYXQgaHR0cDovL3dpa2kub2F1 dGgubmV0L09BdXRoLTIuMCBhbmQgeW91IGZpbmQgZmluZCB0aGUgc3BlYyBhdCBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYW1tZXItb2F1dGgyLTAwLg0KDQoNCg0KWW91IG1heSBh bHNvIGJlIGludGVyZXN0ZWQgaW4gdGhlIG1vYmlsZSB3ZWIgaW1wbGVtZW50YXRpb24gd2UndmUg YnVpbHQgYXQgRmFjZWJvb2suIGh0dHA6Ly9kZXZlbG9wZXJzLmZhY2Vib29rLmNvbS9kb2NzL2d1 aWRlcy9tb2JpbGUvDQoNCg0KDQpJJ20gYWxzbyBjYydpbmcgQmxhaW5lIENvb2sgd2hvIGxpdmVz IGluIElyZWxhbmQgYW5kIG1pZ2h0IGJlIGFibGUgdG8gcHJlc2VudC4NCg0KDQoNCkNoZWVycywN Cg0KLS1EYXZpZA0KDQoNCg0KT24gVHVlLCBNYXkgNCwgMjAxMCBhdCA0OjIwIEFNLCBLZXZpbiBT bWl0aCwgVm9kYWZvbmUgPG1ya3Jjc21pdGhAZ29vZ2xlbWFpbC5jb208bWFpbHRvOm1ya3Jjc21p dGhAZ29vZ2xlbWFpbC5jb20+PiB3cm90ZToNCg0KRGVhciBPQVVUSCBXUkFQIGdyb3VwLA0KDQpN eSBuYW1lIGlzIEtldmluIFNtaXRoIG9mIFZvZGFmb25lIFImRCwgYW5kIEkgbGVhZCBhIGNyb3Nz LW1vYmlsZQ0Kb3BlcmF0b3IgcHJvamVjdCBjYWxsZWQgT25lQVBJICgnT3BlbiBOZXR3b3JrIEVu YWJsZXJzJykgWzFdLiBUaGUgYWltDQppcyB0byBwcm92aWRlIGEgUkVTVGZ1bCBBUEkgdG8gZXhw b3NlIG5ldHdvcmsgZnVuY3Rpb25zIHN1Y2ggYXMNCmxvY2F0aW9uLCBtZXNzYWdpbmcsIHBheW1l bnRzIGFuZCBtb3JlIHRvIGRldmVsb3BlcnM7IHdpdGggdGhlDQpyZWNrb25pbmcgdGhhdCB0aGlz IHdpbGwgbWFrZSBpdCBmYXIgZWFzaWVyIHRvIG1hc2gtdXAgV2ViDQphcHBsaWNhdGlvbnMgd2l0 aCBuZXR3b3JrIGNhcGFiaWxpdGllcyBhbmQgcmVkdWNlIHRoZSB0aW1lIHRvIHJlYWNoDQphbGwg bW9iaWxlIHN1YnNjcmliZXJzIGluIGEgdGVycml0b3J5LiBUaHVzIGZhciB3ZSBoYXZlIGEgbGl2 ZSBwaWxvdA0KaW1wbGVtZW50YXRpb24gYWNyb3NzIHRoZSAzIG1ham9yIENhbmFkaWFuIG9wZXJh dG9ycyBbMl0gYW5kIGEgbm9uLQ0KY29tbWVyY2lhbCB0ZXN0IHNpdGUgY29ubmVjdGVkIHRvDQox MiBFdXJvcGVhbiBvcGVyYXRvcnMgWzNdLCBhbmQgd2lsbCBiZSByZWxlYXNpbmcgdjEuMCBzcGVj aWZpY2F0aW9ucw0KYmFja2VkIGJ5IHRoZSBPTUEgdGhpcyBtb250aC4NCg0KRm9yIHRoZSBmaXJz dCByZWxlYXNlIHdlIGRpZCBub3QgYXR0ZW1wdCB0byBwcmVzY3JpYmUgYW4gQUFBIG1vZGVsIHRv DQpvcGVyYXRvcnMsIGluc3RlYWQgbGVhdmluZyB0aGVtIHRvIHJldXNlIHRoZWlyIG93biBTRFAg QUFBDQppbXBsZW1lbnRhdGlvbiBmb3IgT25lQVBJLiBGb3Igb3VyIHNlY29uZCBwaGFzZSBub3cg dW5kZXJ3YXkgd2Ugd291bGQNCmxpa2UgdG8gcHJvdmlkZSBhIHJlY29tbWVuZGVkIHJlZmVyZW5j ZSBpbXBsZW1lbnRhdGlvbiBBQUEgbW9kZWwgZm9yDQpvcGVyYXRvcnMgd2hvIGFyZSB1bnN1cmUg aG93IHRvIGFsbG93IHNlY3VyZSBBUEkgYWNjZXNzIHdoaWxzdA0KYWxsb3dpbmcgdXNlciBjb25z ZW50IGFuZCBwcml2YWN5IHRvIGJlIHJlc3BlY3RlZC4gVGhlcmVmb3JlIHdlIGhhdmUNCmRpc2N1 c3NlZCBPQVVUSCBhcyBhbiBpZGVhbCBjYW5kaWRhdGUgdGhhdCB3aWxsIGJlIHdlbGwta25vd24g dG8gV2ViDQpkZXZlbG9wZXJzLg0KDQpNeSBxdWVzdGlvbiByZWdhcmRzIHRoZSBzdWl0YWJpbGl0 eSBvZiBXUkFQIGZvciBzdWNoIGEgcmVmZXJlbmNlDQppbXBsZW1lbnRhdGlvbjogdGhlIGRlY291 cGxpbmcgb2YgYXV0aGVudGljYXRpb24gaXMgZ29vZCBzZW5zZSBhbmQNCndvdWxkIGJlIHdlbGNv bWUgYnkgb3BlcmF0b3JzLCBob3dldmVyIGl0IGFwcGVhcnMgdGhhdCBXUkFQIGlzDQpkZXByZWNh dGVkIGFuZCBpcyBpbnRlbmRlZCB0byBiZSByZXBsYWNlZCBieSBPQVVUSCAyLjAgLSBpcyB0aGF0 DQpyaWdodD8gIFBsZWFzZSBjb3VsZCB5b3UgcHJvdmlkZSBhbnkgZGV0YWlscyBvbiB0aGUgcGxh bnMgZm9yIGlmL2hvdw0KdGhlIHR3byB3aWxsIGludGVyb3BlcmF0ZT8gSWYgaXQncyBhdCBhbGwg cG9zc2libGUsIHdlIHdvdWxkIHZlcnkgbXVjaA0Kd2VsY29tZSBhIG1lbWJlciBvZiB0aGUgZ3Jv dXAgdG8gcHJlc2VudCBvbiBXUkFQIGF0IG9uZSBvZiBvdXIgZmFjZS10by0NCmZhY2UgbWVldGlu Z3MgaW4gTG9uZG9uIC0gaWYgdGhhdCBpcyBvZiBpbnRlcmVzdCBwbGVhc2UgbGV0IG1lIGtub3cN CmFuZCBJIGNhbiBtYWtlIGFycmFuZ2VtZW50cy4NCg0KVGhhbmtzIGZvciB5b3VyIHRpbWUgYW5k IGxvb2sgZm9yd2FyZCB0byB5b3VyIGFkdmljZS4NCg0KS2luZCByZWdhcmRzLA0KS2V2aW4NCg0K WzFdIGh0dHA6Ly93d3cuZ3Ntd29ybGQuY29tL29uZWFwaQ0KWzJdIGh0dHA6Ly9jYW5hZGEub25l YXBpLmdzbXdvcmxkLmNvbS8NClszXSBodHRwOi8vb25lYXBpLmFlcG9uYS5jb20vDQoNCktldmlu IFNtaXRoDQpTZW5pb3IgVGVjaG5vbG9neSBTdHJhdGVnaXN0LCBSJkQNClZvZGFmb25lIFRlY2hu b2xvZ3kNCg0KRS1tYWlsOiBrZXZpbi5zbWl0aEB2b2RhZm9uZS5jb208bWFpbHRvOmtldmluLnNt aXRoQHZvZGFmb25lLmNvbT4NCg0KLS0NCllvdSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgYmVjYXVz ZSB5b3UgYXJlIHN1YnNjcmliZWQgdG8gdGhlIEdvb2dsZSBHcm91cHMgIk9BdXRoIFdSQVAgV0ci IGdyb3VwLg0KVG8gcG9zdCB0byB0aGlzIGdyb3VwLCBzZW5kIGVtYWlsIHRvIG9hdXRoLXdyYXAt d2dAZ29vZ2xlZ3JvdXBzLmNvbTxtYWlsdG86b2F1dGgtd3JhcC13Z0Bnb29nbGVncm91cHMuY29t Pi4NClRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBncm91cCwgc2VuZCBlbWFpbCB0byBvYXV0aC13 cmFwLXdnK3Vuc3Vic2NyaWJlQGdvb2dsZWdyb3Vwcy5jb208bWFpbHRvOm9hdXRoLXdyYXAtd2cl MkJ1bnN1YnNjcmliZUBnb29nbGVncm91cHMuY29tPi4NCkZvciBtb3JlIG9wdGlvbnMsIHZpc2l0 IHRoaXMgZ3JvdXAgYXQgaHR0cDovL2dyb3Vwcy5nb29nbGUuY29tL2dyb3VwL29hdXRoLXdyYXAt d2c/aGw9ZW4uDQoNCg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E112630738DBWSMSG3153Vsrv_ 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 CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5kcmFmdC1pZXRmLW9hdXRoLXYyIGlzIHRoZSBj dXJyZW50IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjIiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjI8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ VGhlIElFVEYgc3RhdHVzIHBhZ2UgZm9yIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIGlzIGEgZ29v ZCBwbGFjZSB0byBwb2ludCB0bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvb2F1dGgvIj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvd2cvb2F1dGgvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkl0IGxpbmtz IHRvIHRoZSBsYXRlc3QgZHJhZnRzLCBtYWlsaW5nIGxpc3QsIGV0Yy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4o RXJhbuKAmXMgaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGRyYWZ0LWhhbW1lci1vYXV0aDIgYmVjYW1l IHRoZSBJRVRGIHdvcmtpbmcgZ3JvdXAgZHJhZnQgZHJhZnQtaWV0Zi1vYXV0aC12Mik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj5EYXZpZCwgd291bGQgeW91IGxpa2UgdG8gdXBkYXRlPC9zcGFuPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToNCjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+DQpodHRwOi8vd2lraS5vYXV0aC5u ZXQvT0F1dGgtMi4wPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhdmlk IFJlY29yZG9uPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCA2IE1heSAyMDEwIDM6MTQgUE08 YnI+DQo8Yj5Ubzo8L2I+IE9BdXRoIFdHOyBCbGFpbmUgQ29vazxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW09BVVRILVdHXSBbV1JBUF0gV1JBUCBpbiBHU01BIE9uZUFQSTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+JiM0MztPQXV0aCBJRVRGIGxpc3Q8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPi1XUkFQIGxpc3QgdG8gQkNDPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGkgS2V2aW4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T0F1dGggMi4wIHNo b3VsZCBiZSBwcmV0dHkgc2ltcGxlIGZvciB5b3UgdG8gaW1wbGVtZW50IGFuZCBhbnkgZmVlZGJh Y2sgeW91ciB0ZWFtIGhhcyB3b3VsZCBiZSByZWFsbHkgYXBwcmVjaWF0ZWQhIFRoZXJlIGFyZSBh bHJlYWR5IGltcGxlbWVudGF0aW9ucyBpbiBDb2NvYSwgUHl0aG9uLCBhbmQgUnVieSBsaXN0IG9u IHRoZSB3aWtpIGF0Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3dpa2kub2F1dGgubmV0L09BdXRoLTIu MCI+aHR0cDovL3dpa2kub2F1dGgubmV0L09BdXRoLTIuMDwvYT4NCiBhbmQgeW91IGZpbmQgZmlu ZCB0aGUgc3BlYyBhdCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWhhbW1lci1vYXV0aDItMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhh bW1lci1vYXV0aDItMDA8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5Zb3UgbWF5IGFsc28gYmUgaW50ZXJlc3RlZCBpbiB0aGUgbW9iaWxlIHdl YiBpbXBsZW1lbnRhdGlvbiB3ZSd2ZSBidWlsdCBhdCBGYWNlYm9vay4mbmJzcDs8YSBocmVmPSJo dHRwOi8vZGV2ZWxvcGVycy5mYWNlYm9vay5jb20vZG9jcy9ndWlkZXMvbW9iaWxlLyI+aHR0cDov L2RldmVsb3BlcnMuZmFjZWJvb2suY29tL2RvY3MvZ3VpZGVzL21vYmlsZS88L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkknbSBhbHNvIGNjJ2lu ZyBCbGFpbmUgQ29vayB3aG8gbGl2ZXMgaW4gSXJlbGFuZCBhbmQgbWlnaHQgYmUgYWJsZSB0byBw cmVzZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tLURhdmlkPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206DQoxMi4wcHQ7bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFR1ZSwgTWF5IDQsIDIwMTAgYXQg NDoyMCBBTSwgS2V2aW4gU21pdGgsIFZvZGFmb25lICZsdDs8YSBocmVmPSJtYWlsdG86bXJrcmNz bWl0aEBnb29nbGVtYWlsLmNvbSI+bXJrcmNzbWl0aEBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOg0KMTIuMHB0O21h cmdpbi1sZWZ0OjM2LjBwdCI+DQpEZWFyIE9BVVRIIFdSQVAgZ3JvdXAsPGJyPg0KPGJyPg0KTXkg bmFtZSBpcyBLZXZpbiBTbWl0aCBvZiBWb2RhZm9uZSBSJmFtcDtELCBhbmQgSSBsZWFkIGEgY3Jv c3MtbW9iaWxlPGJyPg0Kb3BlcmF0b3IgcHJvamVjdCBjYWxsZWQgT25lQVBJICgnT3BlbiBOZXR3 b3JrIEVuYWJsZXJzJykgWzFdLiBUaGUgYWltPGJyPg0KaXMgdG8gcHJvdmlkZSBhIFJFU1RmdWwg QVBJIHRvIGV4cG9zZSBuZXR3b3JrIGZ1bmN0aW9ucyBzdWNoIGFzPGJyPg0KbG9jYXRpb24sIG1l c3NhZ2luZywgcGF5bWVudHMgYW5kIG1vcmUgdG8gZGV2ZWxvcGVyczsgd2l0aCB0aGU8YnI+DQpy ZWNrb25pbmcgdGhhdCB0aGlzIHdpbGwgbWFrZSBpdCBmYXIgZWFzaWVyIHRvIG1hc2gtdXAgV2Vi PGJyPg0KYXBwbGljYXRpb25zIHdpdGggbmV0d29yayBjYXBhYmlsaXRpZXMgYW5kIHJlZHVjZSB0 aGUgdGltZSB0byByZWFjaDxicj4NCmFsbCBtb2JpbGUgc3Vic2NyaWJlcnMgaW4gYSB0ZXJyaXRv cnkuIFRodXMgZmFyIHdlIGhhdmUgYSBsaXZlIHBpbG90PGJyPg0KaW1wbGVtZW50YXRpb24gYWNy b3NzIHRoZSAzIG1ham9yIENhbmFkaWFuIG9wZXJhdG9ycyBbMl0gYW5kIGEgbm9uLTxicj4NCmNv bW1lcmNpYWwgdGVzdCBzaXRlIGNvbm5lY3RlZCB0bzxicj4NCjEyIEV1cm9wZWFuIG9wZXJhdG9y cyBbM10sIGFuZCB3aWxsIGJlIHJlbGVhc2luZyB2MS4wIHNwZWNpZmljYXRpb25zPGJyPg0KYmFj a2VkIGJ5IHRoZSBPTUEgdGhpcyBtb250aC48YnI+DQo8YnI+DQpGb3IgdGhlIGZpcnN0IHJlbGVh c2Ugd2UgZGlkIG5vdCBhdHRlbXB0IHRvIHByZXNjcmliZSBhbiBBQUEgbW9kZWwgdG88YnI+DQpv cGVyYXRvcnMsIGluc3RlYWQgbGVhdmluZyB0aGVtIHRvIHJldXNlIHRoZWlyIG93biBTRFAgQUFB PGJyPg0KaW1wbGVtZW50YXRpb24gZm9yIE9uZUFQSS4gRm9yIG91ciBzZWNvbmQgcGhhc2Ugbm93 IHVuZGVyd2F5IHdlIHdvdWxkPGJyPg0KbGlrZSB0byBwcm92aWRlIGEgcmVjb21tZW5kZWQgcmVm ZXJlbmNlIGltcGxlbWVudGF0aW9uIEFBQSBtb2RlbCBmb3I8YnI+DQpvcGVyYXRvcnMgd2hvIGFy ZSB1bnN1cmUgaG93IHRvIGFsbG93IHNlY3VyZSBBUEkgYWNjZXNzIHdoaWxzdDxicj4NCmFsbG93 aW5nIHVzZXIgY29uc2VudCBhbmQgcHJpdmFjeSB0byBiZSByZXNwZWN0ZWQuIFRoZXJlZm9yZSB3 ZSBoYXZlPGJyPg0KZGlzY3Vzc2VkIE9BVVRIIGFzIGFuIGlkZWFsIGNhbmRpZGF0ZSB0aGF0IHdp bGwgYmUgd2VsbC1rbm93biB0byBXZWI8YnI+DQpkZXZlbG9wZXJzLjxicj4NCjxicj4NCk15IHF1 ZXN0aW9uIHJlZ2FyZHMgdGhlIHN1aXRhYmlsaXR5IG9mIFdSQVAgZm9yIHN1Y2ggYSByZWZlcmVu Y2U8YnI+DQppbXBsZW1lbnRhdGlvbjogdGhlIGRlY291cGxpbmcgb2YgYXV0aGVudGljYXRpb24g aXMgZ29vZCBzZW5zZSBhbmQ8YnI+DQp3b3VsZCBiZSB3ZWxjb21lIGJ5IG9wZXJhdG9ycywgaG93 ZXZlciBpdCBhcHBlYXJzIHRoYXQgV1JBUCBpczxicj4NCmRlcHJlY2F0ZWQgYW5kIGlzIGludGVu ZGVkIHRvIGJlIHJlcGxhY2VkIGJ5IE9BVVRIIDIuMCAtIGlzIHRoYXQ8YnI+DQpyaWdodD8gJm5i c3A7UGxlYXNlIGNvdWxkIHlvdSBwcm92aWRlIGFueSBkZXRhaWxzIG9uIHRoZSBwbGFucyBmb3Ig aWYvaG93PGJyPg0KdGhlIHR3byB3aWxsIGludGVyb3BlcmF0ZT8gSWYgaXQncyBhdCBhbGwgcG9z c2libGUsIHdlIHdvdWxkIHZlcnkgbXVjaDxicj4NCndlbGNvbWUgYSBtZW1iZXIgb2YgdGhlIGdy b3VwIHRvIHByZXNlbnQgb24gV1JBUCBhdCBvbmUgb2Ygb3VyIGZhY2UtdG8tPGJyPg0KZmFjZSBt ZWV0aW5ncyBpbiBMb25kb24gLSBpZiB0aGF0IGlzIG9mIGludGVyZXN0IHBsZWFzZSBsZXQgbWUg a25vdzxicj4NCmFuZCBJIGNhbiBtYWtlIGFycmFuZ2VtZW50cy48YnI+DQo8YnI+DQpUaGFua3Mg Zm9yIHlvdXIgdGltZSBhbmQgbG9vayBmb3J3YXJkIHRvIHlvdXIgYWR2aWNlLjxicj4NCjxicj4N CktpbmQgcmVnYXJkcyw8YnI+DQpLZXZpbjxicj4NCjxicj4NClsxXSA8YSBocmVmPSJodHRwOi8v d3d3LmdzbXdvcmxkLmNvbS9vbmVhcGkiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmdzbXdv cmxkLmNvbS9vbmVhcGk8L2E+PGJyPg0KWzJdIDxhIGhyZWY9Imh0dHA6Ly9jYW5hZGEub25lYXBp LmdzbXdvcmxkLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vY2FuYWRhLm9uZWFwaS5nc213 b3JsZC5jb20vPC9hPjxicj4NClszXSA8YSBocmVmPSJodHRwOi8vb25lYXBpLmFlcG9uYS5jb20v IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL29uZWFwaS5hZXBvbmEuY29tLzwvYT48YnI+DQo8YnI+ DQpLZXZpbiBTbWl0aDxicj4NClNlbmlvciBUZWNobm9sb2d5IFN0cmF0ZWdpc3QsIFImYW1wO0Q8 YnI+DQpWb2RhZm9uZSBUZWNobm9sb2d5PGJyPg0KPGJyPg0KRS1tYWlsOiA8YSBocmVmPSJtYWls dG86a2V2aW4uc21pdGhAdm9kYWZvbmUuY29tIj5rZXZpbi5zbWl0aEB2b2RhZm9uZS5jb208L2E+ PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCi0tPGJyPg0KWW91IHJlY2Vp dmVkIHRoaXMgbWVzc2FnZSBiZWNhdXNlIHlvdSBhcmUgc3Vic2NyaWJlZCB0byB0aGUgR29vZ2xl IEdyb3VwcyAmcXVvdDtPQXV0aCBXUkFQIFdHJnF1b3Q7IGdyb3VwLjxicj4NClRvIHBvc3QgdG8g dGhpcyBncm91cCwgc2VuZCBlbWFpbCB0byA8YSBocmVmPSJtYWlsdG86b2F1dGgtd3JhcC13Z0Bn b29nbGVncm91cHMuY29tIj4NCm9hdXRoLXdyYXAtd2dAZ29vZ2xlZ3JvdXBzLmNvbTwvYT4uPGJy Pg0KVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGdyb3VwLCBzZW5kIGVtYWlsIHRvIDxhIGhyZWY9 Im1haWx0bzpvYXV0aC13cmFwLXdnJTJCdW5zdWJzY3JpYmVAZ29vZ2xlZ3JvdXBzLmNvbSI+DQpv YXV0aC13cmFwLXdnJiM0Mzt1bnN1YnNjcmliZUBnb29nbGVncm91cHMuY29tPC9hPi48YnI+DQpG b3IgbW9yZSBvcHRpb25zLCB2aXNpdCB0aGlzIGdyb3VwIGF0IDxhIGhyZWY9Imh0dHA6Ly9ncm91 cHMuZ29vZ2xlLmNvbS9ncm91cC9vYXV0aC13cmFwLXdnP2hsPWVuIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwOi8vZ3JvdXBzLmdvb2dsZS5jb20vZ3JvdXAvb2F1dGgtd3JhcC13Zz9obD1lbjwvYT4u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_255B9BB34FB7D647A506DC292726F6E112630738DBWSMSG3153Vsrv_-- From recordond@gmail.com Wed May 5 23:50:46 2010 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 270A53A6A79 for ; Wed, 5 May 2010 23:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-1.405, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] 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 bRHxvRbdjjqP for ; Wed, 5 May 2010 23:50:44 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id B4C073A69E2 for ; Wed, 5 May 2010 23:50:44 -0700 (PDT) Received: by iwn27 with SMTP id 27so7445641iwn.5 for ; Wed, 05 May 2010 23:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=rG8j4Ji0YHT6ECQece+iX+rErscRyN8enbc1LCAzkdc=; b=UhHNCChLK48scPmV9mvAhqfb2izXpO75RxHSjhtI90uWsYn42XjnLTv4tWNn0/mnIe ozrtNPiztHaxroqFa5/vty4ods1FJWJh9vopTKLaz8VSw/kfgfsJ6+fmqzDkubm+JDa9 +C4UL7gC8tUSL3L96OUZMzJT0XJIVd5Os1f3M= 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=YGlGlmMmqrPBvDiXj7F3XMawZkBWRWhIfqzN7dHCJ8Fbu4GCs6Xex88hrjEV1b5ovp EFtn6o5VBi86P6rcoIbUO6xC4WLsnNwbgyTaQVetxPfRFvonjawIWDgOqrSufNiRtxQW hQ1FJqZM8jj3kEq7YcQWoHHf+O0Ji8zKO26Ks= MIME-Version: 1.0 Received: by 10.231.147.199 with SMTP id m7mr1030234ibv.87.1273128628775; Wed, 05 May 2010 23:50:28 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Wed, 5 May 2010 23:50:28 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112630738DB@WSMSG3153V.srv.dir.telstra.com> References: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> <255B9BB34FB7D647A506DC292726F6E112630738DB@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 5 May 2010 23:50:28 -0700 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016e647ecc4abebfb0485e75b64 Cc: OAuth WG , "oauth-wrap-wg@googlegroups.com" Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI 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, 06 May 2010 06:50:46 -0000 --0016e647ecc4abebfb0485e75b64 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Updated on the wiki! On Wed, May 5, 2010 at 11:48 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > draft-ietf-oauth-v2 is the current document. > > http://tools.ietf.org/html/draft-ietf-oauth-v2 > > > > The IETF status page for the OAuth working group is a good place to point > to: > > http://tools.ietf.org/wg/oauth/ > > It links to the latest drafts, mailing list, etc. > > > > (Eran=92s individual submission draft-hammer-oauth2 became the IETF worki= ng > group draft draft-ietf-oauth-v2) > > > > David, would you like to update http://wiki.oauth.net/OAuth-2.0? > > > > -- > > James Manger > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *David Recordon > *Sent:* Thursday, 6 May 2010 3:14 PM > *To:* OAuth WG; Blaine Cook > *Subject:* Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI > > > > +OAuth IETF list > > -WRAP list to BCC > > > > Hi Kevin, > > OAuth 2.0 should be pretty simple for you to implement and any feedback > your team has would be really appreciated! There are already implementati= ons > in Cocoa, Python, and Ruby list on the wiki at > http://wiki.oauth.net/OAuth-2.0 and you find find the spec at > http://tools.ietf.org/html/draft-hammer-oauth2-00. > > > > You may also be interested in the mobile web implementation we've built a= t > Facebook. http://developers.facebook.com/docs/guides/mobile/ > > > > I'm also cc'ing Blaine Cook who lives in Ireland and might be able to > present. > > > > Cheers, > > --David > > > > On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone < > mrkrcsmith@googlemail.com> wrote: > > Dear OAUTH WRAP group, > > My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile > operator project called OneAPI ('Open Network Enablers') [1]. The aim > is to provide a RESTful API to expose network functions such as > location, messaging, payments and more to developers; with the > reckoning that this will make it far easier to mash-up Web > applications with network capabilities and reduce the time to reach > all mobile subscribers in a territory. Thus far we have a live pilot > implementation across the 3 major Canadian operators [2] and a non- > commercial test site connected to > 12 European operators [3], and will be releasing v1.0 specifications > backed by the OMA this month. > > For the first release we did not attempt to prescribe an AAA model to > operators, instead leaving them to reuse their own SDP AAA > implementation for OneAPI. For our second phase now underway we would > like to provide a recommended reference implementation AAA model for > operators who are unsure how to allow secure API access whilst > allowing user consent and privacy to be respected. Therefore we have > discussed OAUTH as an ideal candidate that will be well-known to Web > developers. > > My question regards the suitability of WRAP for such a reference > implementation: the decoupling of authentication is good sense and > would be welcome by operators, however it appears that WRAP is > deprecated and is intended to be replaced by OAUTH 2.0 - is that > right? Please could you provide any details on the plans for if/how > the two will interoperate? If it's at all possible, we would very much > welcome a member of the group to present on WRAP at one of our face-to- > face meetings in London - if that is of interest please let me know > and I can make arrangements. > > Thanks for your time and look forward to your advice. > > Kind regards, > Kevin > > [1] http://www.gsmworld.com/oneapi > [2] http://canada.oneapi.gsmworld.com/ > [3] http://oneapi.aepona.com/ > > Kevin Smith > Senior Technology Strategist, R&D > Vodafone Technology > > E-mail: kevin.smith@vodafone.com > > -- > You received this message because you are subscribed to the Google Groups > "OAuth WRAP WG" group. > To post to this group, send email to oauth-wrap-wg@googlegroups.com. > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscribe@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=3Den. > > > --0016e647ecc4abebfb0485e75b64 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Updated on the wiki!

On Wed, May 5, 2010 = at 11:48 PM, Manger, James H <James.H.Manger@team.telstra.com> w= rote:

draft= -ietf-oauth-v2 is the current document.

htt= p://tools.ietf.org/html/draft-ietf-oauth-v2

=A0

The I= ETF status page for the OAuth working group is a good place to point to:

http://tools.ietf.= org/wg/oauth/

It li= nks to the latest drafts, mailing list, etc.

=A0

(Eran= =92s individual submission draft-hammer-oauth2 became the IETF working grou= p draft draft-ietf-oauth-v2)

=A0

David= , would you like to update http://wiki.o= auth.net/OAuth-2.0?

=A0

--

James= Manger

=A0

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Recordon
Sent: Thursday, 6 May 2010 3:14 PM
To: OAuth WG; Blaine Cook
Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI

=A0

+OAuth IETF list

-WRAP list to BCC

=A0

Hi Kevin,

OAuth 2.0 should be pre= tty simple for you to implement and any feedback your team has would be rea= lly appreciated! There are already implementations in Cocoa, Python, and Ru= by list on the wiki at=A0http://wiki.oauth.net/OAuth-2.0 and you find find the spec at=A0http://tools.ietf.org/html/draft-hamm= er-oauth2-00.

=A0

You may also be interes= ted in the mobile web implementation we've built at Facebook.=A0h= ttp://developers.facebook.com/docs/guides/mobile/

=A0

I'm also cc'ing= Blaine Cook who lives in Ireland and might be able to present.

=A0

Cheers,

--David

=A0

On Tue, May 4, 2010 at = 4:20 AM, Kevin Smith, Vodafone <mrkrcsmith@googlemail.com> wrote:

Dear OAUTH WRAP group,

My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile
operator project called OneAPI ('Open Network Enablers') [1]. The a= im
is to provide a RESTful API to expose network functions such as
location, messaging, payments and more to developers; with the
reckoning that this will make it far easier to mash-up Web
applications with network capabilities and reduce the time to reach
all mobile subscribers in a territory. Thus far we have a live pilot
implementation across the 3 major Canadian operators [2] and a non-
commercial test site connected to
12 European operators [3], and will be releasing v1.0 specifications
backed by the OMA this month.

For the first release we did not attempt to prescribe an AAA model to
operators, instead leaving them to reuse their own SDP AAA
implementation for OneAPI. For our second phase now underway we would
like to provide a recommended reference implementation AAA model for
operators who are unsure how to allow secure API access whilst
allowing user consent and privacy to be respected. Therefore we have
discussed OAUTH as an ideal candidate that will be well-known to Web
developers.

My question regards the suitability of WRAP for such a reference
implementation: the decoupling of authentication is good sense and
would be welcome by operators, however it appears that WRAP is
deprecated and is intended to be replaced by OAUTH 2.0 - is that
right? =A0Please could you provide any details on the plans for if/how
the two will interoperate? If it's at all possible, we would very much<= br> welcome a member of the group to present on WRAP at one of our face-to-
face meetings in London - if that is of interest please let me know
and I can make arrangements.

Thanks for your time and look forward to your advice.

Kind regards,
Kevin

[1] http://www= .gsmworld.com/oneapi
[2] http:/= /canada.oneapi.gsmworld.com/
[3] http://oneapi.a= epona.com/

Kevin Smith
Senior Technology Strategist, R&D
Vodafone Technology

E-mail: kevin= .smith@vodafone.com

--
You received this message because you are subscribed to the Google Groups &= quot;OAuth WRAP WG" group.
To post to this group, send email to oauth-wrap-wg@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-wg+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=3Den.

=A0


--0016e647ecc4abebfb0485e75b64-- From jsmarr@gmail.com Thu May 6 08:57:10 2010 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 54D953A6C09 for ; Thu, 6 May 2010 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_50=0.001, 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 qhZWzgdDPZ6z for ; Thu, 6 May 2010 08:57:08 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id AEEC73A6D79 for ; Thu, 6 May 2010 08:47:25 -0700 (PDT) Received: by pxi19 with SMTP id 19so44966pxi.31 for ; Thu, 06 May 2010 08:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; bh=rZtBEviAAc36WENKa1Ya9UgqlbodzARWy6NO2SkVp+o=; b=KTw0jDV37iPn/371OOAFbAZtzK7CRtpeOz1NLN5Y5mRynwUuiuF9BTf7Gnhnr/hM/U irUqB9D/v1VgCL6rbCWdh8sTsNUMsTfQJ41Qc21rHwkgbhgk5FLOI3ee9SXEJbmkrNPK xJm1QuMzWiwzdaX+jC7iCziGgYUf7YliM/0r4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=GjL75tF2TSqY/OfUPSX1dWO4PfQS0V5YKxt9iu5eTLQmaV3Jsr/S2i0/gdWRfNhUUs Zp/+bqwAfxyRS406r04Bx2/4qjwnRUFd/fhS6jXpOjZLpUgV1zt5YDwGwSStmaUAr8XX 4ZcmvCHeC4dxiRmBoCtISRxkYjrFtoMhuubuo= Received: by 10.142.59.10 with SMTP id h10mr442252wfa.284.1273160830353; Thu, 06 May 2010 08:47:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.164.14 with HTTP; Thu, 6 May 2010 08:46:50 -0700 (PDT) In-Reply-To: <4BE1F2A1.9040707@pidster.com> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> From: Joseph Smarr Date: Thu, 6 May 2010 08:46:50 -0700 Message-ID: To: pid@pidster.com Content-Type: multipart/alternative; boundary=00504502af980903650485eedb20 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jsmarr@stanfordalumni.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 15:57:10 -0000 --00504502af980903650485eedb20 Content-Type: text/plain; charset=ISO-8859-1 I'm hearing a lot of confusion on this thread. Evan-of course when attributes are sent *on-the-url* then they get parsed automatically by the HTTP stack, but we're talking about the response body, which every OAuth 1.0 library I've seen writes their own (usually buggy) parser for, and that's where we're proposing to use JSON. I've seen good JSON library support on every platform I've needed to work for, and it's becoming more and more common (look at Facebook's new Graph API, for instance), so I doubt many platforms will be without JSON parsers for much longer. That being said, it's prudent to look at the state-of-the-art and verify that requiring JSON is not a practical hindrance for iPhone developers, etc., but I still think it's "betting on the right horse" and it's going to be a lot simpler and less error-prone than either url-encoded values or XML. Eran-thanks for agreeing to write something up, and I agree we've got strong support for JSON being the primary/only format for the response body. I look forward to the proposed text and will happily review it. Thanks, js On Wed, May 5, 2010 at 3:35 PM, Pid wrote: > On 05/05/2010 19:49, DeWitt Clinton wrote: > > Having written more than one compliant JSON parser myself, it is most > > certainly not "trivial", and not something that can be safely done with > > a regular expression or other hacks. > > > > That said, it's not /hard/, and that alone is no reason not to mandate > > JSON, but I do want people to be clear about what mandating JSON means. > > Clients will need a fully compliant parser. Period. If the OAuth spec > > requires JSON, then it should require it by reference to RFC 4627, not > > just by giving some examples that demonstrate the curly braces. > > > > -DeWitt > > I know it's late, but can I add my 2 cents - as a developer who'll be > implementing this? > > > In the original post, Dick suggested that developers were having trouble > with the URL encoding format - but I respectfully suggest that JSON is > going to be more problematic. > > There's no guarantee that an external JSON parser will be available for > a given platform/language/business, (perhaps because of licensing, if > not other more technical reasons). So that means writing one. > > Writing a JSON parser just to cover the simple usage proposed won't be > too tricky, but if the JSON response is so simple why bother adding this > dependency at all? I'm slightly baffled... > > > URL encoding is required for at least one flow, so IMHO it might as well > stay for the rest. Simplicity is important. > > > Can someone from the pro-JSON side offer a clearer explanation as to the > benefits, so I can stop scratching my head about it all, please? > > > > Respectfully, > > Pid > > > > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt > > > wrote: > > > > Am 05.05.2010 20:01, schrieb Evan Gilbert: > >> > >> > >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert >> > wrote: > >> > >> > >> > >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt > >> > > wrote: > >> > >> Even if not supported directly by the platform there are > >> many JSON libraries available these days. > >> > >> > >> It's not hard to add JSON support, but it's a factor in the > >> choice. > >> > >> > >> > >> http://www.json.org/ lists 3 libraries for Objective-C > alone. > >> > >> Moreover, the JSON documents we are discussing now are > >> simple, something like > >> > >> > >> { "access_token": "SlAV32hkKG", "expires_in": "3600", > >> "refresh_token": "8xLOxBtZp8" } > >> > >> Parsing such a document is not a challenge even without > >> library support. > >> > >> > >> Per notes above - the client needs to do understand form > >> encoding anyway. The client needs to parse the redirect_uri > >> and also needs to generate form encoded requests. > >> > >> > >> Also, for the User-Agent flow, parsing potentially untrusted JSON > >> in JavaScript is difficult. The normal path of using eval() is > >> unsafe and leads to XSS holes - you need to run regex matcher to > >> verify that the JSON content has no executable code. > > > > You are right, using eval to parse JSON is dangerous and thus as far > > as I understand, the recommended way is to use a JSON parser (aka > > native JSON support)? > > > > regards, > > Torsten. > > > > _______________________________________________ > > 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 > > --00504502af980903650485eedb20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm hearing a lot of confusion on this thread.

Evan-= of course when attributes are sent *on-the-url* then they get parsed automa= tically by the HTTP stack, but we're talking about the response body, w= hich every OAuth 1.0 library I've seen writes their own (usually buggy)= parser for, and that's where we're proposing to use JSON.=A0

I've seen good JSON library support on every platfo= rm I've needed to work for, and it's becoming more and more common = (look at Facebook's new Graph API, for instance), so I doubt many platf= orms will be without JSON parsers for much longer. That being said, it'= s prudent to look at the state-of-the-art and verify that requiring JSON is= not a practical hindrance for iPhone developers, etc., but I still think i= t's "betting on the right horse" and it's going to be a l= ot simpler and less error-prone than either url-encoded values or XML.

Eran-thanks for agreeing to write something up, and I a= gree we've got strong support for JSON being the primary/only format fo= r the response body. I look forward to the proposed text and will happily r= eview it.

Thanks, js

On = Wed, May 5, 2010 at 3:35 PM, Pid <pid@pidster.com> wrote:
On 05/05/2010 19:49, DeWitt Clinton wrote:
> Having written more than one compliant JSON parser myself, it is most<= br> > certainly not "trivial", and not something that can be safel= y done with
> a regular expression or other hacks.
>
> That said, it's not /hard/, and that alone is no reason not to man= date
> JSON, but I do want people to be clear about what mandating JSON means= .
> =A0Clients will need a fully compliant parser. =A0Period. =A0If the OA= uth spec
> requires JSON, then it should require it by reference to RFC 4627, not=
> just by giving some examples that demonstrate the curly braces.
>
> -DeWitt

I know it's late, but can I add my 2 cents - as a developer who&#= 39;ll be
implementing this?


In the original post, Dick suggested that developers were having trouble with the URL encoding format - but I respectfully suggest that JSON is
going to be more problematic.

There's no guarantee that an external JSON parser will be available for=
a given platform/language/business, (perhaps because of licensing, if
not other more technical reasons). =A0So that means writing one.

Writing a JSON parser just to cover the simple usage proposed won't be<= br> too tricky, but if the JSON response is so simple why bother adding this dependency at all? =A0I'm slightly baffled...


URL encoding is required for at least one flow, so IMHO it might as well stay for the rest. =A0Simplicity is important.


Can someone from the pro-JSON side offer a clearer explanation as to the benefits, so I can stop scratching my head about it all, please?



Respectfully,

Pid


> On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt
> <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>
> =A0 =A0 Am 05.05.2010 20:01, schrieb Evan Gilbert:
>>
>>
>> =A0 =A0 On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert <uidude@google.com
>> =A0 =A0 <mailto:uidude@google.com>> wrote:
>>
>>
>>
>> =A0 =A0 =A0 =A0 On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderste= dt
>> =A0 =A0 =A0 =A0 <torsten@lodderstedt.net <mailto= :torsten@lodderstedt.net>= > wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Even if not supported directly by the plat= form there are
>> =A0 =A0 =A0 =A0 =A0 =A0 many JSON libraries available these days.<= br> >>
>>
>> =A0 =A0 =A0 =A0 It's not hard to add JSON support, but it'= s a factor in the
>> =A0 =A0 =A0 =A0 choice.
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 http://www.json.org/ lists 3 libraries for Objective-C alone.<= br> >>
>> =A0 =A0 =A0 =A0 =A0 =A0 Moreover, the JSON documents we are discus= sing now are
>> =A0 =A0 =A0 =A0 =A0 =A0 simple, something like
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 { "access_token": "SlAV32hk= KG", "expires_in": "3600",
>> =A0 =A0 =A0 =A0 =A0 =A0 "refresh_token": "8xLOxBtZp= 8" }
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Parsing such a document is not a challenge= even without
>> =A0 =A0 =A0 =A0 =A0 =A0 library support.
>>
>>
>> =A0 =A0 =A0 =A0 Per notes above - the client needs to do understan= d form
>> =A0 =A0 =A0 =A0 encoding anyway. The client needs to parse the red= irect_uri
>> =A0 =A0 =A0 =A0 and also needs to generate form encoded requests.<= br> >>
>>
>> =A0 =A0 Also, for the User-Agent flow, parsing potentially untrust= ed JSON
>> =A0 =A0 in JavaScript is difficult. The normal path of using eval(= ) is
>> =A0 =A0 unsafe and leads to XSS holes - you need to run regex matc= her to
>> =A0 =A0 verify that the JSON content has no executable code.
>
> =A0 =A0 You are right, using eval to parse JSON is dangerous and thus = as far
> =A0 =A0 as I understand, the recommended way is to use a JSON parser (= aka
> =A0 =A0 native JSON support)?
>
> =A0 =A0 regards,
> =A0 =A0 Torsten.
>
> =A0 =A0 _______________________________________________
> =A0 =A0 OAuth mailing list
> =A0 =A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
> =A0 =A0 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
h= ttps://www.ietf.org/mailman/listinfo/oauth


--00504502af980903650485eedb20-- From gbrail@sonoasystems.com Thu May 6 09:17:31 2010 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 5F5DE3A68AA for ; Thu, 6 May 2010 09:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 gQV8USQ+lCZ5 for ; Thu, 6 May 2010 09:17:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 220A528C0D8 for ; Thu, 6 May 2010 09:13:37 -0700 (PDT) Received: by gyh4 with SMTP id 4so86127gyh.31 for ; Thu, 06 May 2010 09:13:21 -0700 (PDT) Received: by 10.229.211.204 with SMTP id gp12mr5407421qcb.59.1273162398847; Thu, 06 May 2010 09:13:18 -0700 (PDT) From: Greg Brail References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrtNMc5e2C2l9qASrSvMgHEWaWwBwAAbd2g Date: Thu, 6 May 2010 12:13:17 -0400 Message-ID: <01bb1f595f89af50b0c37c00dbcd54cd@mail.gmail.com> To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0016363b88ae86947f0485ef3894 Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 06 May 2010 16:17:31 -0000 --0016363b88ae86947f0485ef3894 Content-Type: text/plain; charset=ISO-8859-1 I agree that JSON is the long-term winner. However, at least for Java and Python I know that JSON parsers are not part of the standard library, whereas everything needed to decode a url-formencoded library is in the standard libraries and has been there for a long, long time. Keep in mind that the overhead of using third-party code is not just in finding and using the right library, but getting legal clearance if it's open source and you work for a big company. I also realize that there was some confusion around URL encoding and OAuth 1.0, but do we understand what the issues were? Can we make the 2.0 spec simpler in that respect. *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf Of *Joseph Smarr *Sent:* Thursday, May 06, 2010 11:47 AM *To:* pid@pidster.com *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) I'm hearing a lot of confusion on this thread. Evan-of course when attributes are sent *on-the-url* then they get parsed automatically by the HTTP stack, but we're talking about the response body, which every OAuth 1.0 library I've seen writes their own (usually buggy) parser for, and that's where we're proposing to use JSON. I've seen good JSON library support on every platform I've needed to work for, and it's becoming more and more common (look at Facebook's new Graph API, for instance), so I doubt many platforms will be without JSON parsers for much longer. That being said, it's prudent to look at the state-of-the-art and verify that requiring JSON is not a practical hindrance for iPhone developers, etc., but I still think it's "betting on the right horse" and it's going to be a lot simpler and less error-prone than either url-encoded values or XML. Eran-thanks for agreeing to write something up, and I agree we've got strong support for JSON being the primary/only format for the response body. I look forward to the proposed text and will happily review it. Thanks, js On Wed, May 5, 2010 at 3:35 PM, Pid wrote: On 05/05/2010 19:49, DeWitt Clinton wrote: > Having written more than one compliant JSON parser myself, it is most > certainly not "trivial", and not something that can be safely done with > a regular expression or other hacks. > > That said, it's not /hard/, and that alone is no reason not to mandate > JSON, but I do want people to be clear about what mandating JSON means. > Clients will need a fully compliant parser. Period. If the OAuth spec > requires JSON, then it should require it by reference to RFC 4627, not > just by giving some examples that demonstrate the curly braces. > > -DeWitt I know it's late, but can I add my 2 cents - as a developer who'll be implementing this? In the original post, Dick suggested that developers were having trouble with the URL encoding format - but I respectfully suggest that JSON is going to be more problematic. There's no guarantee that an external JSON parser will be available for a given platform/language/business, (perhaps because of licensing, if not other more technical reasons). So that means writing one. Writing a JSON parser just to cover the simple usage proposed won't be too tricky, but if the JSON response is so simple why bother adding this dependency at all? I'm slightly baffled... URL encoding is required for at least one flow, so IMHO it might as well stay for the rest. Simplicity is important. Can someone from the pro-JSON side offer a clearer explanation as to the benefits, so I can stop scratching my head about it all, please? Respectfully, Pid > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt > > wrote: > > Am 05.05.2010 20:01, schrieb Evan Gilbert: >> >> >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert > > wrote: >> >> >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt >> > wrote: >> >> Even if not supported directly by the platform there are >> many JSON libraries available these days. >> >> >> It's not hard to add JSON support, but it's a factor in the >> choice. >> >> >> >> http://www.json.org/ lists 3 libraries for Objective-C alone. >> >> Moreover, the JSON documents we are discussing now are >> simple, something like >> >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600", >> "refresh_token": "8xLOxBtZp8" } >> >> Parsing such a document is not a challenge even without >> library support. >> >> >> Per notes above - the client needs to do understand form >> encoding anyway. The client needs to parse the redirect_uri >> and also needs to generate form encoded requests. >> >> >> Also, for the User-Agent flow, parsing potentially untrusted JSON >> in JavaScript is difficult. The normal path of using eval() is >> unsafe and leads to XSS holes - you need to run regex matcher to >> verify that the JSON content has no executable code. > > You are right, using eval to parse JSON is dangerous and thus as far > as I understand, the recommended way is to use a JSON parser (aka > native JSON support)? > > regards, > Torsten. > > _______________________________________________ > 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 --0016363b88ae86947f0485ef3894 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I agree that JSON is the long-term winner. However, at least for Java and Pyt= hon I know that JSON parsers are not part of the standard library, whereas ever= ything needed to decode a url-formencoded library is in the standard libraries and= has been there for a long, long time. Keep in mind that the overhead of using third-party code is not just in finding and using the right library, but getting legal clearance if it's open source and you work for a big comp= any.

=A0

I also realize that there was some confusion around URL encoding and OAuth 1.= 0, but do we understand what the issues were? Can we make the 2.0 spec simpler= in that respect.

=A0

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces@ietf.org] = On Behalf Of Joseph Smarr
Sent: Thursday, May 06, 2010 11:47 AM
To: pid@pidster.com
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

=A0

I'm hearing a lot of confusion on this thread.

=A0

Evan-of course when attributes are sent *on-the-url*= then they get parsed automatically by the HTTP stack, but we're talking abou= t the response body, which every OAuth 1.0 library I've seen writes their own (usually buggy) parser for, and that's where we're proposing to use= JSON.=A0

=A0

I've seen good JSON library support on every pla= tform I've needed to work for, and it's becoming more and more common (look at Fac= ebook's new Graph API, for instance), so I doubt many platforms will be without JSO= N parsers for much longer. That being said, it's prudent to look at the state-of-the-art and verify that requiring JSON is not a practical hindranc= e for iPhone developers, etc., but I still think it's "betting on th= e right horse" and it's going to be a lot simpler and less error-prone tha= n either url-encoded values or XML.

=A0

Eran-thanks for agreeing to write something up, and = I agree we've got strong support for JSON being the primary/only format for the response body. I look forward to the proposed text and will happily review = it.

=A0

Thanks, js

=A0

On Wed, May 5, 2010 at 3:35 PM, Pid <pid@pidster.com> wrote:

On 05/05/2010 19:49, = DeWitt Clinton wrote:
> Having written more than one compliant JSON parser myself, it is most<= br> > certainly not "trivial", and not something that can be safel= y done with
> a regular expression or other hacks.
>
> That said, it's not /hard/, and that alone is no reason not to man= date
> JSON, but I do want people to be clear about what mandating JSON means= .
> =A0Clients will need a fully compliant parser. =A0Period. =A0If the OAuth spec
> requires JSON, then it should require it by reference to RFC 4627, not=
> just by giving some examples that demonstrate the curly braces.
>
> -DeWitt

I know it's late, but can I add my 2 cents - as = a developer who'll be
implementing this?


In the original post, Dick suggested that developers were having trouble with the URL encoding format - but I respectfully suggest that JSON is
going to be more problematic.

There's no guarantee that an external JSON parser will be available for=
a given platform/language/business, (perhaps because of licensing, if
not other more technical reasons). =A0So that means writing one.

Writing a JSON parser just to cover the simple usage proposed won't be<= br> too tricky, but if the JSON response is so simple why bother adding this dependency at all? =A0I'm slightly baffled...


URL encoding is required for at least one flow, so IMHO it might as well stay for the rest. =A0Simplicity is important.


Can someone from the pro-JSON side offer a clearer explanation as to the benefits, so I can stop scratching my head about it all, please?



Respectfully,

Pid



> On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt

> <= torsten@lodderstedt.net <mailto:torsten@lodderstedt.n= et>> wrote:
>
> =A0 =A0 Am 05.05.2010 20:01, schrieb Evan Gilbert:
>>
>>
>> =A0 =A0 On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert <uidude@google.com

>> =A0 =A0 <mailto:uidude@google.com>> wrote:
>>
>>
>>
>> =A0 =A0 =A0 =A0 On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt

>> =A0 =A0 =A0 =A0 <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Even if not supported directly by the platform there are
>> =A0 =A0 =A0 =A0 =A0 =A0 many JSON libraries available these days.
>>
>>
>> =A0 =A0 =A0 =A0 It's not hard to add JSON support, but it's a factor in the
>> =A0 =A0 =A0 =A0 choice.
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 http://www.json.org/ lists 3 libraries for Objective-C alone.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Moreover, the JSON documents we are discussing now are
>> =A0 =A0 =A0 =A0 =A0 =A0 simple, something like
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 { "access_token": "SlAV32hkKG", "expires_in": "3600",
>> =A0 =A0 =A0 =A0 =A0 =A0 "refresh_token": "8xLOxBtZp8" }
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Parsing such a document is not a challenge even without
>> =A0 =A0 =A0 =A0 =A0 =A0 library support.
>>
>>
>> =A0 =A0 =A0 =A0 Per notes above - the client needs to do understand form
>> =A0 =A0 =A0 =A0 encoding anyway. The client needs to parse the redirect_uri
>> =A0 =A0 =A0 =A0 and also needs to generate form encoded requests.
>>
>>
>> =A0 =A0 Also, for the User-Agent flow, parsing potentially untrusted JSON
>> =A0 =A0 in JavaScript is difficult. The normal path of using eval() is
>> =A0 =A0 unsafe and leads to XSS holes - you need to run regex matcher to
>> =A0 =A0 verify that the JSON content has no executable code.
>
> =A0 =A0 You are right, using eval to parse JSON is dangerous and thus as far
> =A0 =A0 as I understand, the recommended way is to use a JSON parser (aka
> =A0 =A0 native JSON support)?
>
> =A0 =A0 regards,
> =A0 =A0 Torsten.
>
> =A0 =A0 _______________________________________________
> =A0 =A0 OAuth mailing list

> =A0 =A0 OAuth= @ietf.org <mailto:OAuth@ietf.org>

> =A0 =A0 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
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0

--0016363b88ae86947f0485ef3894-- From torsten@lodderstedt.net Thu May 6 10:29:23 2010 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 782E63A6A04 for ; Thu, 6 May 2010 10:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_40=-0.185, HELO_EQ_DE=0.35, 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 cOgPIgW85DTb for ; Thu, 6 May 2010 10:29:21 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by core3.amsl.com (Postfix) with ESMTP id E747C3A69E8 for ; Thu, 6 May 2010 10:29:20 -0700 (PDT) Received: from p4fff325d.dip.t-dialin.net ([79.255.50.93] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OA4sj-0002VO-Tm; Thu, 06 May 2010 19:29:06 +0200 Message-ID: <4BE2FC60.7040303@lodderstedt.net> Date: Thu, 06 May 2010 19:29:04 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: jsmarr@stanfordalumni.org References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020501080004050308020903" X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 06 May 2010 17:29:23 -0000 This is a multi-part message in MIME format. --------------020501080004050308020903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 , we've got really strong support for JSON and I'm also looking forward to review Erans proposal. I checked back today with some of our service and client application developers. All of our services offer JSON and XML as transport format, no one even considered using application/x-www-form-urlencoded for encoding web services responses. On the client side, things look even simpler. Our own client application generally use JSON on all platforms, incl. smartphones (Android, iPhone), handsets (J2ME), home entertainment, and home automation devices. Especially the later are really special since they use only a small subest of Java (no Java 5, no generics, ..) but JSON is apparently not a problem. It is mainly prefered because it combines small resource/bandwitdh consumption with ease of use. Our iPhone applications are built using external libraries, the experiences are good. As Joseph said, JSON is the "right horse to bet on". Platform support is getting better in my observation. For example, J2ME supports it and JavaScript is getting native JSON support as well. From my point of view, the Oauth API should fit well into the world of HTTP-based services and choosing a completly different encoding (application/x-www-form-urlencoded) for OAuth might appear somehow weird to developers. Moreover, what do developers really gain from that constraint? OAuth just provides the tokens for invoking other services securly. If all the other services use JSON, applications need JSON libraries anyway. So why bother with that question with respect to OAuth? regards, Torsten. Am 06.05.2010 17:46, schrieb Joseph Smarr: > I'm hearing a lot of confusion on this thread. > > Evan-of course when attributes are sent *on-the-url* then they get > parsed automatically by the HTTP stack, but we're talking about the > response body, which every OAuth 1.0 library I've seen writes their > own (usually buggy) parser for, and that's where we're proposing to > use JSON. > > I've seen good JSON library support on every platform I've needed to > work for, and it's becoming more and more common (look at Facebook's > new Graph API, for instance), so I doubt many platforms will be > without JSON parsers for much longer. That being said, it's prudent to > look at the state-of-the-art and verify that requiring JSON is not a > practical hindrance for iPhone developers, etc., but I still think > it's "betting on the right horse" and it's going to be a lot simpler > and less error-prone than either url-encoded values or XML. > > Eran-thanks for agreeing to write something up, and I agree we've got > strong support for JSON being the primary/only format for the response > body. I look forward to the proposed text and will happily review it. > > Thanks, js > > On Wed, May 5, 2010 at 3:35 PM, Pid > wrote: > > On 05/05/2010 19:49, DeWitt Clinton wrote: > > Having written more than one compliant JSON parser myself, it is > most > > certainly not "trivial", and not something that can be safely > done with > > a regular expression or other hacks. > > > > That said, it's not /hard/, and that alone is no reason not to > mandate > > JSON, but I do want people to be clear about what mandating JSON > means. > > Clients will need a fully compliant parser. Period. If the > OAuth spec > > requires JSON, then it should require it by reference to RFC > 4627, not > > just by giving some examples that demonstrate the curly braces. > > > > -DeWitt > > I know it's late, but can I add my 2 cents - as a developer who'll be > implementing this? > > > In the original post, Dick suggested that developers were having > trouble > with the URL encoding format - but I respectfully suggest that JSON is > going to be more problematic. > > There's no guarantee that an external JSON parser will be > available for > a given platform/language/business, (perhaps because of licensing, if > not other more technical reasons). So that means writing one. > > Writing a JSON parser just to cover the simple usage proposed won't be > too tricky, but if the JSON response is so simple why bother > adding this > dependency at all? I'm slightly baffled... > > > URL encoding is required for at least one flow, so IMHO it might > as well > stay for the rest. Simplicity is important. > > > Can someone from the pro-JSON side offer a clearer explanation as > to the > benefits, so I can stop scratching my head about it all, please? > > > > Respectfully, > > Pid > > > > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt > > > >> > wrote: > > > > Am 05.05.2010 20:01, schrieb Evan Gilbert: > >> > >> > >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert > > >> >> wrote: > >> > >> > >> > >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt > >> > >> > wrote: > >> > >> Even if not supported directly by the platform > there are > >> many JSON libraries available these days. > >> > >> > >> It's not hard to add JSON support, but it's a factor in the > >> choice. > >> > >> > >> > >> http://www.json.org/ lists 3 libraries for Objective-C alone. > >> > >> Moreover, the JSON documents we are discussing now are > >> simple, something like > >> > >> > >> { "access_token": "SlAV32hkKG", "expires_in": "3600", > >> "refresh_token": "8xLOxBtZp8" } > >> > >> Parsing such a document is not a challenge even without > >> library support. > >> > >> > >> Per notes above - the client needs to do understand form > >> encoding anyway. The client needs to parse the redirect_uri > >> and also needs to generate form encoded requests. > >> > >> > >> Also, for the User-Agent flow, parsing potentially > untrusted JSON > >> in JavaScript is difficult. The normal path of using eval() is > >> unsafe and leads to XSS holes - you need to run regex > matcher to > >> verify that the JSON content has no executable code. > > > > You are right, using eval to parse JSON is dangerous and > thus as far > > as I understand, the recommended way is to use a JSON parser > (aka > > native JSON support)? > > > > regards, > > Torsten. > > > > _______________________________________________ > > 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 > --------------020501080004050308020903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 , we've got really strong support for JSON and I'm also looking forward to review Erans proposal.

I checked back today with some of our service and client application developers. All of our services offer JSON and XML as transport format, no one even considered using application/x-www-form-urlencoded for encoding web services responses.

On the client side, things look even simpler. Our own client application generally use JSON on all platforms, incl. smartphones (Android, iPhone), handsets (J2ME), home entertainment, and home automation devices. Especially the later are really special since they use only a small subest of Java (no Java 5, no generics, ..) but JSON is apparently not a problem. It is mainly prefered because it combines small resource/bandwitdh consumption with ease of use. Our iPhone applications are built using external libraries, the experiences are good.

As Joseph said, JSON is the "right horse to bet on". Platform support is getting better in my observation. For example, J2ME supports it and JavaScript is getting native JSON support as well.

>From my point of view, the Oauth API should fit well into the world of HTTP-based services and choosing a completly different encoding (application/x-www-form-urlencoded) for OAuth might appear somehow weird to developers. Moreover, what do developers really gain from that constraint? OAuth just provides the tokens for invoking other services securly. If all the other services use JSON, applications need JSON libraries anyway. So why bother with that question with respect to OAuth?

regards,
Torsten.

Am 06.05.2010 17:46, schrieb Joseph Smarr:
I'm hearing a lot of confusion on this thread.

Evan-of course when attributes are sent *on-the-url* then they get parsed automatically by the HTTP stack, but we're talking about the response body, which every OAuth 1.0 library I've seen writes their own (usually buggy) parser for, and that's where we're proposing to use JSON. 

I've seen good JSON library support on every platform I've needed to work for, and it's becoming more and more common (look at Facebook's new Graph API, for instance), so I doubt many platforms will be without JSON parsers for much longer. That being said, it's prudent to look at the state-of-the-art and verify that requiring JSON is not a practical hindrance for iPhone developers, etc., but I still think it's "betting on the right horse" and it's going to be a lot simpler and less error-prone than either url-encoded values or XML.

Eran-thanks for agreeing to write something up, and I agree we've got strong support for JSON being the primary/only format for the response body. I look forward to the proposed text and will happily review it.

Thanks, js

On Wed, May 5, 2010 at 3:35 PM, Pid <pid@pidster.com> wrote:
On 05/05/2010 19:49, DeWitt Clinton wrote:
> Having written more than one compliant JSON parser myself, it is most
> certainly not "trivial", and not something that can be safely done with
> a regular expression or other hacks.
>
> That said, it's not /hard/, and that alone is no reason not to mandate
> JSON, but I do want people to be clear about what mandating JSON means.
>  Clients will need a fully compliant parser.  Period.  If the OAuth spec
> requires JSON, then it should require it by reference to RFC 4627, not
> just by giving some examples that demonstrate the curly braces.
>
> -DeWitt

I know it's late, but can I add my 2 cents - as a developer who'll be
implementing this?


In the original post, Dick suggested that developers were having trouble
with the URL encoding format - but I respectfully suggest that JSON is
going to be more problematic.

There's no guarantee that an external JSON parser will be available for
a given platform/language/business, (perhaps because of licensing, if
not other more technical reasons).  So that means writing one.

Writing a JSON parser just to cover the simple usage proposed won't be
too tricky, but if the JSON response is so simple why bother adding this
dependency at all?  I'm slightly baffled...


URL encoding is required for at least one flow, so IMHO it might as well
stay for the rest.  Simplicity is important.


Can someone from the pro-JSON side offer a clearer explanation as to the
benefits, so I can stop scratching my head about it all, please?



Respectfully,

Pid


> On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt
> <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>
>     Am 05.05.2010 20:01, schrieb Evan Gilbert:
>>
>>
>>     On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert <uidude@google.com
>>     <mailto:uidude@google.com>> wrote:
>>
>>
>>
>>         On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt
>>         <torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>> wrote:
>>
>>             Even if not supported directly by the platform there are
>>             many JSON libraries available these days.
>>
>>
>>         It's not hard to add JSON support, but it's a factor in the
>>         choice.
>>
>>
>>
>>             http://www.json.org/ lists 3 libraries for Objective-C alone.
>>
>>             Moreover, the JSON documents we are discussing now are
>>             simple, something like
>>
>>
>>             { "access_token": "SlAV32hkKG", "expires_in": "3600",
>>             "refresh_token": "8xLOxBtZp8" }
>>
>>             Parsing such a document is not a challenge even without
>>             library support.
>>
>>
>>         Per notes above - the client needs to do understand form
>>         encoding anyway. The client needs to parse the redirect_uri
>>         and also needs to generate form encoded requests.
>>
>>
>>     Also, for the User-Agent flow, parsing potentially untrusted JSON
>>     in JavaScript is difficult. The normal path of using eval() is
>>     unsafe and leads to XSS holes - you need to run regex matcher to
>>     verify that the JSON content has no executable code.
>
>     You are right, using eval to parse JSON is dangerous and thus as far
>     as I understand, the recommended way is to use a JSON parser (aka
>     native JSON support)?
>
>     regards,
>     Torsten.
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto: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

--------------020501080004050308020903-- From eran@hueniverse.com Thu May 6 12:58:14 2010 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 D8C263A6A40 for ; Thu, 6 May 2010 12:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_50=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 JlxSWhD6lDbZ for ; Thu, 6 May 2010 12:58:14 -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 A23B53A6966 for ; Thu, 6 May 2010 12:58:13 -0700 (PDT) Received: (qmail 24418 invoked from network); 6 May 2010 19:57:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 May 2010 19:57:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 6 May 2010 12:57:47 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Thu, 6 May 2010 12:58:02 -0700 Thread-Topic: Draft -02 submitted Thread-Index: AcrtVm8dDss0q/URRkesVLZx9ubDEg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723439323D1277@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] Draft -02 submitted 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, 06 May 2010 19:58:14 -0000 The new draft should show up shortly. The changes are: - Scope parameter (space-delimited for now) - JSON response format for tokens - Removed URI query restriction on redirection URI when using 'state' I am thinking of moving all the flows up section up (no more splitting them= into three categories in the sections). This will make the document less n= ested, but also will solve the issue of the assertion flow not always being= an autonomous flow, etc. Let me know if you have strong objections as I am= likely to submit a -03 tomorrow with just that change (to make diffs easie= r limit major format changes to their own drafts). EHL From root@core3.amsl.com Thu May 6 13:00:01 2010 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BD47F3A6966; Thu, 6 May 2010 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100506200001.BD47F3A6966@core3.amsl.com> Date: Thu, 6 May 2010 13:00:01 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-02.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, 06 May 2010 20:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-02.txt Pages : 50 Date : 2010-05-06 This specification describes the OAuth 2.0 protocol. OAuth provides a method for making authenticated HTTP requests using a token - an identifier used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-06125343.I-D@ietf.org> --NextPart-- From sayrer@gmail.com Thu May 6 13:04:42 2010 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 5F5C73A6C26 for ; Thu, 6 May 2010 13:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 V73aYkI3H5IU for ; Thu, 6 May 2010 13:04:39 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1F5933A6A98 for ; Thu, 6 May 2010 13:04:39 -0700 (PDT) Received: by gwaa12 with SMTP id a12so241141gwa.31 for ; Thu, 06 May 2010 13:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OQHHnHaajdVBieH0SpqOCgtDf+4+/nfOBtk5n5vwvX8=; b=w1OAW34l2VrF0j5kGfN/HuVYfKMZmm/2J7imFdzHyIcNLhhjKsMF28UGkQpZU6h9lJ M2mOJA/CEZiMWY2U/AbVCNLTL6kMqcctW7QTqrArXLw8tvqOf2AwpoLkNMqDOXeuDtcK 6gQLSRdCnaYb9uk3Y/C3tHirFwanhnJQ0u1fY= 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=gYb6qf/tKHV+h7OF78C6BIZnIbW1P3pD0rDeDJpFz5o63DO6yM9TGy06FHCYoieLHM K/wM4SgBmXM/FSPhwegRH1NkUMTZ0MERCiaA9q3rqFy9yoK/Mr2gt0U/XSoRjWld1FcF t8BqALbDyw+xpLyZJGoyd2yGXgsRXHnYVYvv8= MIME-Version: 1.0 Received: by 10.229.227.16 with SMTP id iy16mr4968722qcb.27.1273176262492; Thu, 06 May 2010 13:04:22 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Thu, 6 May 2010 13:04:22 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D1277@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723439323D1277@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 6 May 2010 16:04:22 -0400 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -02 submitted 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, 06 May 2010 20:04:42 -0000 On Thu, May 6, 2010 at 3:58 PM, Eran Hammer-Lahav wrote: > > I am likely to submit a -03 tomorrow There are some broken JSON examples that should be fixed tomorrow as well: {"error"="incorrect_client_credentials"} -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From eran@hueniverse.com Thu May 6 13:07:30 2010 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 200463A6C26 for ; Thu, 6 May 2010 13:07:30 -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=1.095, BAYES_00=-2.599, GB_I_LETTER=-2] 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 dlzrsOcu11Tb for ; Thu, 6 May 2010 13:07:29 -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 177DC3A6A98 for ; Thu, 6 May 2010 13:07:29 -0700 (PDT) Received: (qmail 13792 invoked from network); 6 May 2010 20:07:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 May 2010 20:07:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 6 May 2010 13:07:04 -0700 From: Eran Hammer-Lahav To: Robert Sayre Date: Thu, 6 May 2010 13:07:18 -0700 Thread-Topic: [OAUTH-WG] Draft -02 submitted Thread-Index: AcrtV1bQvU7qWkovRYaiO61S/ILCiAAAE49Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723439323D1288@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723439323D1277@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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -02 submitted 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, 06 May 2010 20:07:30 -0000 Ugh. I forgot to save the doc before I rendered. It is already fixed in my = local copy. I'll include that in the next refresh. EHL > -----Original Message----- > From: Robert Sayre [mailto:sayrer@gmail.com] > Sent: Thursday, May 06, 2010 1:04 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Draft -02 submitted >=20 > On Thu, May 6, 2010 at 3:58 PM, Eran Hammer-Lahav > wrote: > > > > I am likely to submit a -03 tomorrow >=20 > There are some broken JSON examples that should be fixed tomorrow as > well: >=20 > {"error"=3D"incorrect_client_credentials"} >=20 > -- >=20 > Robert Sayre >=20 > "I would have written a shorter letter, but I did not have the time." From James.H.Manger@team.telstra.com Thu May 6 16:57:49 2010 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 EF32C3A69E5 for ; Thu, 6 May 2010 16:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmFWA98ve-ow for ; Thu, 6 May 2010 16:57:49 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 4DBF83A694E for ; Thu, 6 May 2010 16:57:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,344,1270389600"; d="scan'208,217";a="2482302" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 May 2010 09:57:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1605461" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 07 May 2010 09:57:34 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 7 May 2010 09:57:33 +1000 From: "Manger, James H" To: OAuth WG Date: Fri, 7 May 2010 09:57:32 +1000 Thread-Topic: Indicating sites where a token is valid Thread-Index: Acrtd+RKgxK8uGQ7RkCGWfcUzOTj/g== Message-ID: <255B9BB34FB7D647A506DC292726F6E11263073D6D@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_255B9BB34FB7D647A506DC292726F6E11263073D6DWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 23:57:50 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11263073D6DWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIE9BdXRoMiBwcm90b2NvbCBkb2VzIG5vdCBpbmRpY2F0ZSB3aGVyZSBhIHRva2VuIGNhbiBi ZSB1c2VkLg0KDQpJdCBuZWVkcyB0byBkbyBzbyBiZWNhdXNlIGlmIGEgY2xpZW50IGFwcCBzZW5k cyBhIHRva2VuIHRvIHRoZSB3cm9uZyBzaXRlIGl0IGRlc3Ryb3lzIHRoZSBzZWN1cml0eS4NCg0K DQoNCkkgc3VnZ2VzdCBhbm90aGVyIGZpZWxkIGluIHRoZSBKU09OIHRva2VuIHJlc3BvbnNlOg0K DQogICJzaXRlcyI6IFsiaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20iLCAiaHR0cDovL3Bob3RvLmV4 YW1wbGUuY29tOjgwODAiXQ0KDQoNCg0KSXQgd291bGQgYmUgYSBsaXN0IG9mIHNpdGVzIHdoZXJl IHRoZSB0b2tlbiBjYW4gYmUgdXNlZCwgc3BlY2lmaWVkIGJ5IHNjaGVtZTovL2hvc3RbOnBvcnRd Lg0KDQoNCg0KVGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRoZSDigJxzaXRlc+KAnSBmaWVsZCBjb3Vs ZCBiZSB0aGUgdG9rZW4gZW5kcG9pbnQgc2l0ZSAob3IgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgc2l0ZSBpZiBhIHRva2VuIGVuZHBvaW50IGlzbuKAmXQgdXNlZCkuDQoNCkZvciBpbnN0YW5j ZSwgaWYgRmFjZWJvb2vigJlzIG5ldyBBUEkgdXNlcyBodHRwczovL2dyYXBoLmZhY2Vib29rLmNv bSBmb3IgYWxsIHJlc291cmNlcywgdG9rZW5zLCBhbmQgYXV0aG9yaXphdGlvbnMgaXQgY291bGQg b21pdCB0aGUg4oCcc2l0ZXPigJ0gZmllbGQuDQoNCg0KDQoNCg0KUC5TLiBJIHN1Z2dlc3RlZCB0 aGlzIGxhc3QgbW9udGggaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo L2N1cnJlbnQvbXNnMDE5MjAuaHRtbCwgIHRob3VnaCBJIG1peGVkIGluIGFkZGl0aW9uYWwgaWRl YXMgZm9yIGZvcm1hdHMgYW5kIG1lZGlhIHR5cGUgdGhhdCBhcmUgcHJvYmFibGUgYmVzdCBjb3Zl cmVkIGluIHRoZWlyIG93biB0cmVhZHMuDQoNCg0KDQoNCg0KLS0NCg0KSmFtZXMgTWFuZ2VyDQoN Cg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E11263073D6DWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIE9BdXRoMiBwcm90b2Nv bCBkb2VzIG5vdCBpbmRpY2F0ZSB3aGVyZSBhIHRva2VuIGNhbiBiZSB1c2VkLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgbmVlZHMgdG8gZG8gc28gYmVjYXVzZSBpZiBh IGNsaWVudCBhcHAgc2VuZHMgYSB0b2tlbiB0byB0aGUgd3Jvbmcgc2l0ZSBpdCBkZXN0cm95cyB0 aGUgc2VjdXJpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VnZ2VzdCBhbm90aGVyIGZp ZWxkIGluIHRoZSBKU09OIHRva2VuIHJlc3BvbnNlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZxdW90O3NpdGVzJnF1b3Q7OiBbJnF1b3Q7aHR0cHM6Ly9hcGku ZXhhbXBsZS5jb20mcXVvdDssICZxdW90O2h0dHA6Ly9waG90by5leGFtcGxlLmNvbTo4MDgwJnF1 b3Q7XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBiZSBhIGxpc3Qgb2Ygc2l0ZXMg d2hlcmUgdGhlIHRva2VuIGNhbiBiZSB1c2VkLCBzcGVjaWZpZWQgYnkgc2NoZW1lOi8vaG9zdFs6 cG9ydF0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkZWZhdWx0IHZhbHVlIGZvciB0aGUg 4oCcc2l0ZXPigJ0gZmllbGQgY291bGQgYmUgdGhlIHRva2VuIGVuZHBvaW50IHNpdGUgKG9yIHRo ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHNpdGUgaWYgYSB0b2tlbiBlbmRwb2ludCBpc27igJl0 IHVzZWQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGluc3RhbmNl LCBpZiBGYWNlYm9va+KAmXMgbmV3IEFQSSB1c2VzIDxhIGhyZWY9Imh0dHBzOi8vZ3JhcGguZmFj ZWJvb2suY29tIj4NCmh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tPC9hPiBmb3IgYWxsIHJlc291 cmNlcywgdG9rZW5zLCBhbmQgYXV0aG9yaXphdGlvbnMgaXQgY291bGQgb21pdCB0aGUg4oCcc2l0 ZXPigJ0gZmllbGQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UC5TLiBJIHN1Z2dlc3RlZCB0aGlzIGxhc3QgbW9udGgg PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJl bnQvbXNnMDE5MjAuaHRtbCI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cwMTkyMC5odG1sPC9hPiwgJm5ic3A7dGhvdWdoIEkgbWl4ZWQgaW4g YWRkaXRpb25hbCBpZGVhcyBmb3IgZm9ybWF0cyBhbmQgbWVkaWEgdHlwZSB0aGF0IGFyZSBwcm9i YWJsZSBiZXN0IGNvdmVyZWQgaW4gdGhlaXIgb3duIHRyZWFkcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E11263073D6DWSMSG3153Vsrv_-- From mscurtescu@google.com Thu May 6 17:11:52 2010 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 E49823A69E5 for ; Thu, 6 May 2010 17:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.313 X-Spam-Level: X-Spam-Status: No, score=-100.313 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 K4W-t0D1kBWW for ; Thu, 6 May 2010 17:11:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 82B623A68C8 for ; Thu, 6 May 2010 17:11:50 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o470BZhx006812 for ; Thu, 6 May 2010 17:11:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273191096; bh=ClBbJOHQog9GBPco0hDpjQ8CNoA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=XeLFDYut67xzpjRsukYMWLAkX2hGXkhnn3TwUBvvjJfT4eA8BXYq+xSMcVUsDJV/w X2vLu5JzB/BAHJc/4A/nQ== 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:content-transfer-encoding:x-system-of-record; b=xG3adP2EDLz2ZS9PYAvK+K/7H55BxZUscZJUxHOq7wbNYttsSk5f3FHwP0afwgIap fWnTrtRpnOS17Xye+afOA== Received: from pvf33 (pvf33.prod.google.com [10.241.210.97]) by hpaq14.eem.corp.google.com with ESMTP id o470BXYk029250 for ; Thu, 6 May 2010 17:11:34 -0700 Received: by pvf33 with SMTP id 33so392408pvf.2 for ; Thu, 06 May 2010 17:11:33 -0700 (PDT) Received: by 10.141.88.6 with SMTP id q6mr7303484rvl.218.1273191093134; Thu, 06 May 2010 17:11:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Thu, 6 May 2010 17:11:13 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Thu, 6 May 2010 17:11:13 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 00:11:52 -0000 Isn't this taken care of by the scope? I assume the requested scope is associated with the issued access token. It is up to the sites accepting the access tokens (the protected resources) to verify and enforce the scope. Marius On Thu, May 6, 2010 at 4:57 PM, Manger, James H wrote: > The OAuth2 protocol does not indicate where a token can be used. > > It needs to do so because if a client app sends a token to the wrong site= it > destroys the security. > > > > I suggest another field in the JSON token response: > > =A0 "sites": ["https://api.example.com", "http://photo.example.com:8080"] > > > > It would be a list of sites where the token can be used, specified by > scheme://host[:port]. > > > > The default value for the =93sites=94 field could be the token endpoint s= ite (or > the authorization endpoint site if a token endpoint isn=92t used). > > For instance, if Facebook=92s new API uses https://graph.facebook.com for= all > resources, tokens, and authorizations it could omit the =93sites=94 field= . > > > > > > P.S. I suggested this last month > http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html, =A0thou= gh I > mixed in additional ideas for formats and media type that are probable be= st > covered in their own treads. > > > > > > -- > > James Manger > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From James.H.Manger@team.telstra.com Thu May 6 18:36:33 2010 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 960493A6857 for ; Thu, 6 May 2010 18:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.24 X-Spam-Level: * X-Spam-Status: No, score=1.24 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPCxUlkKms+u for ; Thu, 6 May 2010 18:36:32 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id E11643A6890 for ; Thu, 6 May 2010 18:36:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,344,1270389600"; d="scan'208";a="2175841" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 07 May 2010 11:36:18 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1663432" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 07 May 2010 11:36:18 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 7 May 2010 11:36:18 +1000 From: "Manger, James H" To: Marius Scurtescu Date: Fri, 7 May 2010 11:36:16 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: Acrted66i8DdRZnsQ1+d4Zfwy7YRwAABetmg Message-ID: <255B9BB34FB7D647A506DC292726F6E112630740C0@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> 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 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 01:36:33 -0000 TWFyaXVzDQoNCj4gSXNuJ3QgdGhpcyB0YWtlbiBjYXJlIG9mIGJ5IHRoZSBzY29wZT8NCg0KSSBk b24ndCB0aGluayBzby4gSXQgbG9va3Mgc2ltaWxhciB0byBHb29nbGUgc2NvcGVzIChodHRwOi8v Y29kZS5nb29nbGUuY29tL2FwaXMvZ2RhdGEvZmFxLmh0bWwjQXV0aFNjb3BlcyksIGJ1dCBub3Ro aW5nIGxpa2UgRmFjZWJvb2sgc2NvcGVzIChodHRwOi8vZGV2ZWxvcGVycy5mYWNlYm9vay5jb20v ZG9jcy9hdXRoZW50aWNhdGlvbi9wZXJtaXNzaW9ucykuDQoNCg0KPiBJIGFzc3VtZSB0aGUgcmVx dWVzdGVkIHNjb3BlIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbi4N Cg0KSSBkb24ndCB0aGluayB3ZSBzaG91bGQgcmVxdWlyZSBjbGllbnQgYXBwcyB0byBrbm93IGFs bCB0aGUgc2l0ZXMgYSBzZXJ2aWNlIHVzZXMgZm9yIGl0cyByZXNvdXJjZXMgKGV2ZW4gdGhvc2Ug aW4gYSBnaXZlbiBzY29wZSkgYXQgdGhlIHN0YXJ0IG9mIHRoZSBmbG93LiBJdCBraWxscyBpbnRl cm9wIGZvciBjbGllbnRzIHdpdGhvdXQgbXVjaCBzZXJ2aWNlLXNwZWNpZmljIGtub3dsZWRnZS4g SXQgYWxzbyBjb25zdHJhaW5zIGhvdyBzZXJ2aWNlcyBhcnJhbmdlIChhbmQgcmUtYXJyYW5nZSkg dGhlaXIgcmVzb3VyY2VzLg0KDQpXaGF0IHNob3VsZCBhIGNsaWVudCBkbyB3aGVuLCBvbiBhY2Nl c3NpbmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2UsIGl0IGlzIHJlZGlyZWN0ZWQgdG8gYW5vdGhlciBz aXRlPw0KRG9lcyBpdCBzZW5kIHRoZSB0b2tlbiB0byB0aGUgbmV3IHNpdGU/DQpTb21ldGltZSBz ZW5kaW5nIHRoZSB0b2tlbiB3aWxsIGJlIGRhbmdlcm91cyDigJQgdGhlIG90aGVyIHNpdGUgc2hv dWxkbid0IHNlZSB0aGVzZSBjb25maWRlbnRpYWwgdG9rZW5zIChlZyBodHRwczovL2FwaS5leGFt cGxlLmNvbSAtMzA3LT4gaHR0cDovL2Nkbi5uZXQvMjM2NDIzKS4NCkluIG90aGVyIHNpdHVhdGlv bnMgdGhlIHRva2VuIHNob3VsZCBiZSBzZW50IGFzIHRoZSBzYW1lIHNlcnZpY2UgY29udHJvbCBi b3RoIHNpdGVzIGVxdWFsbHkgKGVnIGh0dHBzOi8vYXBpLmV4YW1wbGUuY29tIC0zMDctPiBodHRw czovL2FjY291bnQuZXhhbXBsZS5jb20pLg0KDQoNCkFzIGEgY29uY3JldGUgZXhhbXBsZSwgYWNj ZXNzIHRoZSBGYWNlYm9vayBBUEkgc3VjaCBhcyBodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9i dGF5bG9yP21ldGFkYXRhPTEgYW5kIHRoZSByZXNwb25zZSBsaXN0cyBkb3plbnMgb2Ygb3RoZXIg VVJJcy4gTW9zdCBvZiB0aGUgVVJJIGFyZSBvbiB0aGUgc2FtZSBzaXRlIChodHRwczovL2dyYXBo LmZhY2Vib29rLmNvbSkgc28gcHJlc3VtYWJseSBhIGNsaWVudCBhcHAgY2FuIHNlbmQgdGhlIHNh bWUgdG9rZW4uIEFub3RoZXIgVVJJIGlzIGF0IGEgcmVsYXRlZCBzaXRlIChodHRwOi8vd3d3LmZh Y2Vib29rLmNvbSksIGJ1dCBkb2Vzbid0IHVzZSBUTFMuIEV2ZW4gaWYgYW4gYXBwIGNvdWxkIHRl bGwgdGhpcyBkb21haW4gd2FzICJyZWxhdGVkIiBpdCBwcm9iYWJseSBzaG91bGRuJ3Qgc2VuZCB0 aGUgc2FtZSB0b2tlbi4gSWYgb25lIG9mIHRoZSBsaXN0ZWQgY29ubmVjdGlvbnMgd2FzIHRvIGFu IGV4dGVybmFsIHNpdGUgKGVnICJibG9nIjoiaHR0cHM6Ly9ibG9nLmV4YW1wbGUub3JnIikgSSB3 b3VsZCBhc3N1bWUgdGhlIHNhbWUgdG9rZW4gc2hvdWxkIE5PVCBiZSBzZW50Lg0KDQpUaGUgYXBw IG5lZWRzIHRvIGJlIGdpdmVuIHRoZSBsaXN0IG9mIHNpdGVzIGFwcHJvcHJpYXRlIGZvciBpdHMg dG9rZW4gdG8gbWFrZSB0aGVzZSBkZWNpc2lvbnMgc2FmZWx5Lg0KDQoNCj4gSXQgaXMgdXAgdG8g dGhlIHNpdGVzIGFjY2VwdGluZyB0aGUgYWNjZXNzIHRva2Vucw0KPiAodGhlIHByb3RlY3RlZCBy ZXNvdXJjZXMpIHRvIHZlcmlmeSBhbmQgZW5mb3JjZSB0aGUgc2NvcGUuDQoNCkEgc2l0ZSBjYW5u b3QgcHJldmVudCBhIHRva2VuIGJlaW5nIHNlbnQgZnJvbSBhIGNsaWVudCBhcHAgdG8gdGhlIHdy b25nIHNpdGUsIGJlY2F1c2UgdGhlIHJpZ2h0IHNpdGUgbmV2ZXIgc2VlcyB0aGUgdHJhZmZpYy4N Cg0KLS0gDQpKYW1lcyBNYW5nZXINCg0KDQpPbiBUaHUsIE1heSA2LCAyMDEwIGF0IDQ6NTcgUE0s IE1hbmdlciwgSmFtZXMgSA0KPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+IHdyb3Rl Og0KPiBJIHN1Z2dlc3QgYW5vdGhlciBmaWVsZCBpbiB0aGUgSlNPTiB0b2tlbiByZXNwb25zZToN Cj4NCj4gwqAgInNpdGVzIjogWyJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsICJodHRwOi8vcGhv dG8uZXhhbXBsZS5jb206ODA4MCJdDQo= From andrewarnott@gmail.com Thu May 6 19:02:14 2010 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 48ADA3A695F for ; Thu, 6 May 2010 19:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 yyWgobBHDRek for ; Thu, 6 May 2010 19:02:13 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 5984A3A68C8 for ; Thu, 6 May 2010 19:02:13 -0700 (PDT) Received: by gwaa12 with SMTP id a12so388614gwa.31 for ; Thu, 06 May 2010 19:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=PT9eK1Y+aYcznE98j3urDtgnyLRqINZOZDKVBPNFYAU=; b=oO7p/d4WkzHs6wINdW6VX6LUx7IAoApfczAS70ucEGsyyfLEpXuobPbwBxhJGtBDEI Ald8CJ1iGOeQbDeMRSXE8njmpQH6oDoUCgAZwtP8+Tnz7+7GjLOl4Emm+4C1qvRkjpEG n1hNJIa0j4RR0shzH0Q1YCAMVTgF8NZckIKsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VwLcjtqd/WWp3IykeXlO0NsArMroZECp1EQ+fVBV+QOWpUuoNT/aiZoUCIP1lafMTD 1pC40vhSUTQFznYEevhmO0wP/nDwiEtUoSvU02VlfntLfl6mAPDRkS/O4gkIhyyQxZLt x9+Mb4TlIooRrA+E1YKo6NtFRORPw1tjSPzNY= MIME-Version: 1.0 Received: by 10.150.172.42 with SMTP id u42mr2667603ybe.113.1273197717568; Thu, 06 May 2010 19:01:57 -0700 (PDT) Received: by 10.151.105.17 with HTTP; Thu, 6 May 2010 19:01:57 -0700 (PDT) Date: Thu, 6 May 2010 19:01:57 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd5cb00af446d0485f77171 Subject: [OAUTH-WG] Section 7.3 "token_type" vs. section 3.5.3.2 "secret_type" 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, 07 May 2010 02:02:14 -0000 --000e0cd5cb00af446d0485f77171 Content-Type: text/plain; charset=ISO-8859-1 I think there's a typo in section 7.3 of the latest draft. It mentions a token_type and that's the only place that parameter name appears. But sections that refer to 7.3 have a parameter named secret_type so maybe that's what it should be. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --000e0cd5cb00af446d0485f77171 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think there's a typo in section 7.3 of the latest draft. =A0It mentio= ns a token_type and that's the only place that parameter name appears. = =A0But sections that refer to 7.3 have a parameter named secret_type so may= be that's what it should be.
--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre
--000e0cd5cb00af446d0485f77171-- From recordond@gmail.com Thu May 6 21:05:34 2010 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 1F3473A68D4 for ; Thu, 6 May 2010 21:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_50=0.001, 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 jN5-3bXvRcOF for ; Thu, 6 May 2010 21:05:32 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id B820F3A6948 for ; Thu, 6 May 2010 21:05:32 -0700 (PDT) Received: by iwn27 with SMTP id 27so928247iwn.5 for ; Thu, 06 May 2010 21:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=f+uh+J6hJcxOXNB/FNE+THT+j+eTGN1duJyquiJS6tU=; b=wqUvaaPNJ6x4lWYQNYLT8AybmqTWNWba+pkUbEFOn10ptLlSVGNWjYptF2Cc+X0oAf dGwyPvvOyOyaTiBjzgQgKBhqvzSdefD7LihSVZzB52p+J1kL5JguEkLqXYGIACBlX7bI QfQg6PCcZ0+VgGjfZtwnPtjq8amhqfyDCFlFA= 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=rH2zCTOf78b6ojetBJIgdkMHOxfCoVxSSKKRvMpIeZRDOWIRZaFdYZ/PRdnJad46mh g+5h6toDRX9KAXmpQX/YwgQ830Sp31xRA4CiZ4kWEFFdyQcpbib1ewTfGUCXhFLCuLId j6xXgXsS+8wUR2WyvuD3oNUnztdPis58PNSeM= MIME-Version: 1.0 Received: by 10.231.190.204 with SMTP id dj12mr1648970ibb.9.1273205113864; Thu, 06 May 2010 21:05:13 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Thu, 6 May 2010 21:05:13 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 6 May 2010 21:05:13 -0700 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016363b888c89c2770485f92a04 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 04:05:34 -0000 --0016363b888c89c2770485f92a04 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hey James, Do you have a specific example in mind where this either has been an issue or will be an issue? Most client implementations I've seen of OAuth (and technologies like OAuth) have a strong binding between the access token(s), site they were issued by, and user they belong to. So I haven't heard of this being a problem in the wild... --David On Thu, May 6, 2010 at 4:57 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > The OAuth2 protocol does not indicate where a token can be used. > > It needs to do so because if a client app sends a token to the wrong site > it destroys the security. > > > > I suggest another field in the JSON token response: > > "sites": ["https://api.example.com", "http://photo.example.com:8080"] > > > > It would be a list of sites where the token can be used, specified by > scheme://host[:port]. > > > > The default value for the =93sites=94 field could be the token endpoint s= ite > (or the authorization endpoint site if a token endpoint isn=92t used). > > For instance, if Facebook=92s new API uses https://graph.facebook.com for > all resources, tokens, and authorizations it could omit the =93sites=94 f= ield. > > > > > > P.S. I suggested this last month > http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html, though > I mixed in additional ideas for formats and media type that are probable > best covered in their own treads. > > > > > > -- > > James Manger > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016363b888c89c2770485f92a04 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hey James,
Do you have a specific example in mind where this either has= been an issue or will be an issue? Most client implementations I've se= en of OAuth (and technologies like OAuth) have a strong binding between the= access token(s), site they were issued by, and user they belong to. So I h= aven't heard of this being a problem in the wild...

--David


On= Thu, May 6, 2010 at 4:57 PM, Manger, James H <James.H.Manger@team.telstra.com= > wrote:

The OAuth2 protocol does not indicate where a token = can be used.

It needs to do so because if a client app sends a to= ken to the wrong site it destroys the security.

=A0

I suggest another field in the JSON token response:<= /p>

=A0 "sites": ["https://api.example.com", "http://photo.exam= ple.com:8080"]

=A0

It would be a list of sites where the token can be u= sed, specified by scheme://host[:port].

=A0

The default value for the =93sites=94 field could be= the token endpoint site (or the authorization endpoint site if a token end= point isn=92t used).

For instance, if Facebook=92s new API uses https://graph.facebook.com for all resources, tokens, and authorization= s it could omit the =93sites=94 field.

=A0

=A0

P.S. I suggested this last month http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html, =A0th= ough I mixed in additional ideas for formats and media type that are probab= le best covered in their own treads.

=A0

=A0

--

James Manger

=A0


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


--0016363b888c89c2770485f92a04-- From James.H.Manger@team.telstra.com Thu May 6 22:06:39 2010 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 7CA2A3A6900 for ; Thu, 6 May 2010 22:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.257 X-Spam-Level: * X-Spam-Status: No, score=1.257 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHRngp7vby1g for ; Thu, 6 May 2010 22:06:38 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 52F923A6818 for ; Thu, 6 May 2010 22:06:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,346,1270389600"; d="scan'208,217";a="2828169" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 07 May 2010 15:06:19 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1678104" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdni.tcif.telstra.com.au with ESMTP; 07 May 2010 15:06:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Fri, 7 May 2010 15:06:19 +1000 From: "Manger, James H" To: David Recordon Date: Fri, 7 May 2010 15:06:18 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcrtmoBx8bDl1v+GT7af9oQzU2FQBwAAECog Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112631B24FCWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 05:06:39 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112631B24FCWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXZlcnkgZXhpc3RpbmcgdXNlIG9mIENvb2tpZXMsIEhUVFAgQmFzaWMsIGFuZCBIVFRQIERpZ2Vz dCByZWxpZXMgb24gY2xpZW50cyBiZWluZyB0b2xkIGJ5IHRoZSBzZXJ2ZXIgYWJvdXQgdGhlIHNp dGVzIGF0IHdoaWNoIHRoZSBzZWNyZXQgKGNvb2tpZS9wYXNzd29yZC90b2tlbikgY2FuIGJlIHVz ZWQgKGFuZCwgbW9yZSBpbXBvcnRhbnRseSwgd2hlcmUgaXMgbXVzdCBub3QgYmUgdXNlZCkuIFRo aXMgb2NjdXJzIHdpdGhvdXQgcmVxdWlyaW5nIHNlcnZpY2Utc3BlY2lmaWMga25vd2xlZGdlIGlu IHRoZSBjbGllbnQgYXBwLiBPQXV0aCBhaW1zIHRvIHJlcGxhY2Ugc29tZSBvZiB0aGVzZSB1c2Vz Lg0KDQoNCg0KSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiB3b3JrcyBzYWZlbHkgZnJvbSBjbGll bnRzIHdpdGggbm8gc2VydmljZS1zcGVjaWZpYyBrbm93bGVkZ2UgYmVjYXVzZSB0aGUgY2xpZW50 IGtub3dzIG5vdCB0byBzZW5kIHRoZSBwYXNzd29yZCBpdCBnZXRzIGZyb20gdGhlIHVzZXIgdG8g b3RoZXIgc2l0ZXMuDQoNCg0KDQpIVFRQIERpZ2VzdCBhdXRoZW50aWNhdGlvbiBhbGxvd3MgYSBw YXNzd29yZCB0byB1c2VkIHRvIGFjcm9zcyBhIHNldCBvZiBkb21haW5zIHNwZWNpZmllZCBpbiBh IFdXVy1BdXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyLCBidXQgdGhlIHBhc3N3b3JkIHdpbGwg bm90IGJlIHVzZWQgYXQgYXJiaXRyYXJ5IG90aGVyIHNpdGVzLg0KDQoNCg0KQ29va2llcyBhcmUg c2VudCBpbiByZXF1ZXN0cyB0byB0aGUgc2FtZSBzaXRlLCBzaXRlcyB3aXRoIHRoZSBzYW1lIHBh cmVudCwgb3Igb25seSBodHRwcyBzaXRlcywgZGVwZW5kaW5nIG9uIGRldGFpbHMgZnJvbSB0aGUg c2VydmljZSB3aGVuIHNldHRpbmcgdGhlIGNvb2tpZS4NCg0KDQoNCg0KDQpUbyBkYXRlLCBPQXV0 aCBoYXMgYXNzdW1lZCBldmVyeSBjbGllbnQgYXBwIGhhcyBsb3RzIG9mIHNlcnZpY2Utc3BlY2lm aWMga25vd2xlZGdlIHRvIG1ha2UgdGhlc2UgY2hvaWNlcy4gT0F1dGggbmVlZHMgdG8gcmVtb3Zl IHRoZSBuZWVkIGZvciBzbyBtdWNoIHNlcnZpY2Utc3BlY2lmaWMga25vd2xlZGdlIHRvIGJlIGFz IGludGVyb3BlcmFibGUgYXMgb3RoZXIgc3RhbmRhcmQgYXV0aCBtZWNoYW5pc20sIG90aGVyd2lz ZSBpdCBpcyBhIHBvb3IgcmVwbGFjZW1lbnQuDQoNCg0KDQotLQ0KDQpKYW1lcyBNYW5nZXINCg0K DQoNCkZyb206IERhdmlkIFJlY29yZG9uIFttYWlsdG86cmVjb3Jkb25kQGdtYWlsLmNvbV0NClNl bnQ6IEZyaWRheSwgNyBNYXkgMjAxMCAyOjA1IFBNDQpUbzogTWFuZ2VyLCBKYW1lcyBIDQpDYzog T0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEluZGljYXRpbmcgc2l0ZXMgd2hlcmUg YSB0b2tlbiBpcyB2YWxpZA0KDQoNCg0KSGV5IEphbWVzLA0KDQpEbyB5b3UgaGF2ZSBhIHNwZWNp ZmljIGV4YW1wbGUgaW4gbWluZCB3aGVyZSB0aGlzIGVpdGhlciBoYXMgYmVlbiBhbiBpc3N1ZSBv ciB3aWxsIGJlIGFuIGlzc3VlPyBNb3N0IGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgSSd2ZSBzZWVu IG9mIE9BdXRoIChhbmQgdGVjaG5vbG9naWVzIGxpa2UgT0F1dGgpIGhhdmUgYSBzdHJvbmcgYmlu ZGluZyBiZXR3ZWVuIHRoZSBhY2Nlc3MgdG9rZW4ocyksIHNpdGUgdGhleSB3ZXJlIGlzc3VlZCBi eSwgYW5kIHVzZXIgdGhleSBiZWxvbmcgdG8uIFNvIEkgaGF2ZW4ndCBoZWFyZCBvZiB0aGlzIGJl aW5nIGEgcHJvYmxlbSBpbiB0aGUgd2lsZC4uLg0KDQoNCg0KLS1EYXZpZA0KDQoNCg0K --_000_255B9BB34FB7D647A506DC292726F6E112631B24FCWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQog cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkV2ZXJ5IGV4aXN0aW5nIHVzZSBv ZiBDb29raWVzLCBIVFRQIEJhc2ljLCBhbmQgSFRUUCBEaWdlc3QgcmVsaWVzIG9uIGNsaWVudHMg YmVpbmcgdG9sZCBieSB0aGUgc2VydmVyIGFib3V0IHRoZSBzaXRlcyBhdCB3aGljaCB0aGUgc2Vj cmV0IChjb29raWUvcGFzc3dvcmQvdG9rZW4pDQogY2FuIGJlIHVzZWQgKGFuZCwgbW9yZSBpbXBv cnRhbnRseSwgd2hlcmUgaXMgbXVzdCBub3QgYmUgdXNlZCkuIFRoaXMgb2NjdXJzIHdpdGhvdXQg cmVxdWlyaW5nIHNlcnZpY2Utc3BlY2lmaWMga25vd2xlZGdlIGluIHRoZSBjbGllbnQgYXBwLiBP QXV0aCBhaW1zIHRvIHJlcGxhY2Ugc29tZSBvZiB0aGVzZSB1c2VzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkhU VFAgQmFzaWMgYXV0aGVudGljYXRpb24gd29ya3Mgc2FmZWx5IGZyb20gY2xpZW50cyB3aXRoIG5v IHNlcnZpY2Utc3BlY2lmaWMga25vd2xlZGdlIGJlY2F1c2UgdGhlIGNsaWVudCBrbm93cyBub3Qg dG8gc2VuZCB0aGUgcGFzc3dvcmQgaXQgZ2V0cyBmcm9tIHRoZQ0KIHVzZXIgdG8gb3RoZXIgc2l0 ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+SFRUUCBEaWdlc3QgYXV0aGVudGljYXRpb24gYWxsb3dzIGEgcGFz c3dvcmQgdG8gdXNlZCB0byBhY3Jvc3MgYSBzZXQgb2YgZG9tYWlucyBzcGVjaWZpZWQgaW4gYSBX V1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlciwgYnV0IHRoZSBwYXNzd29yZCB3aWxsIG5v dA0KIGJlIHVzZWQgYXQgYXJiaXRyYXJ5IG90aGVyIHNpdGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkNvb2tp ZXMgYXJlIHNlbnQgaW4gcmVxdWVzdHMgdG8gdGhlIHNhbWUgc2l0ZSwgc2l0ZXMgd2l0aCB0aGUg c2FtZSBwYXJlbnQsIG9yIG9ubHkgaHR0cHMgc2l0ZXMsIGRlcGVuZGluZyBvbiBkZXRhaWxzIGZy b20gdGhlIHNlcnZpY2Ugd2hlbiBzZXR0aW5nIHRoZSBjb29raWUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+VG8gZGF0ZSwgT0F1dGggaGFzIGFz c3VtZWQgZXZlcnkgY2xpZW50IGFwcCBoYXMgbG90cyBvZiBzZXJ2aWNlLXNwZWNpZmljIGtub3ds ZWRnZSB0byBtYWtlIHRoZXNlIGNob2ljZXMuIE9BdXRoIG5lZWRzIHRvIHJlbW92ZSB0aGUgbmVl ZCBmb3Igc28gbXVjaCBzZXJ2aWNlLXNwZWNpZmljDQoga25vd2xlZGdlIHRvIGJlIGFzIGludGVy b3BlcmFibGUgYXMgb3RoZXIgc3RhbmRhcmQgYXV0aCBtZWNoYW5pc20sIG90aGVyd2lzZSBpdCBp cyBhIHBvb3IgcmVwbGFjZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+LS0NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERhdmlkIFJlY29yZG9uIFtt YWlsdG86cmVjb3Jkb25kQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIDcg TWF5IDIwMTAgMjowNSBQTTxicj4NCjxiPlRvOjwvYj4gTWFuZ2VyLCBKYW1lcyBIPGJyPg0KPGI+ Q2M6PC9iPiBPQXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBJbmRp Y2F0aW5nIHNpdGVzIHdoZXJlIGEgdG9rZW4gaXMgdmFsaWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+SGV5IEphbWVzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkRvIHlvdSBoYXZlIGEgc3Bl Y2lmaWMgZXhhbXBsZSBpbiBtaW5kIHdoZXJlIHRoaXMgZWl0aGVyIGhhcyBiZWVuIGFuIGlzc3Vl IG9yIHdpbGwgYmUgYW4gaXNzdWU/IE1vc3QgY2xpZW50IGltcGxlbWVudGF0aW9ucyBJJ3ZlIHNl ZW4gb2YgT0F1dGggKGFuZCB0ZWNobm9sb2dpZXMgbGlrZSBPQXV0aCkgaGF2ZSBhIHN0cm9uZyBi aW5kaW5nIGJldHdlZW4gdGhlIGFjY2Vzcw0KIHRva2VuKHMpLCBzaXRlIHRoZXkgd2VyZSBpc3N1 ZWQgYnksIGFuZCB1c2VyIHRoZXkgYmVsb25nIHRvLiBTbyBJIGhhdmVuJ3QgaGVhcmQgb2YgdGhp cyBiZWluZyBhIHByb2JsZW0gaW4gdGhlIHdpbGQuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS1EYXZpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E112631B24FCWSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Thu May 6 22:30:32 2010 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 D1B0A3A6BCE for ; Thu, 6 May 2010 22:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.272 X-Spam-Level: * X-Spam-Status: No, score=1.272 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPxUwZ0I9q6t for ; Thu, 6 May 2010 22:30:30 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id E09963A6BEE for ; Thu, 6 May 2010 22:21:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,346,1270389600"; d="scan'208,217";a="2198271" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 07 May 2010 15:21:46 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1679282" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdni.tcif.telstra.com.au with ESMTP; 07 May 2010 15:21:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 7 May 2010 15:21:46 +1000 From: "Manger, James H" To: OAuth WG Date: Fri, 7 May 2010 15:21:45 +1000 Thread-Topic: [OAUTH-WG] Redirects Thread-Index: AcrtmoBx8bDl1v+GT7af9oQzU2FQBwACIrsg Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112631B257DWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] Redirects 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, 07 May 2010 05:30:32 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112631B257DWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IHNob3VsZCBhbiBPQXV0aCBjbGllbnQgYXBwIGJlaGF2ZSB3aGVuIGl0IGdldHMgYW4gSFRU UCByZWRpcmVjdCBvbiByZXF1ZXN0aW5nIGEgcHJvdGVjdGVkIHJlc291cmNlPw0KDQpTaW1pbGFy bHksIGhvdyBzaG91bGQgaXQgYmVoYXZlIHdoZW4gaXQgZm9sbG93cyBhbnkgb3RoZXIgbGluayBp biBhIHJlc3BvbnNlPw0KDQoNCg0KT2J2aW91c2x5IGl0IHNob3VsZCBtYWtlIGEgbmV3IHJlcXVl c3QgdG8gdGhlIFVSSSBpbiB0aGUgcmVkaXJlY3Qgb3IgbGluayDigJQgdGhhdCBpcyBub3JtYWwg SFRUUCBhbmQgaHlwZXJ0ZXh0IGJlaGF2aW91ci4NCg0KVGhlIHF1ZXN0aW9uIGlzIGRvZXMgdGhl IHRva2VuIGdldCBzZW50IHdpdGggdGhlIG5ldyByZXF1ZXN0Pw0KDQoNCg0KDQoNCkkgdGhpbmsg dGhlIHNwZWMgbmVlZHMgdG8gcHJvdmlkZSBhbiBhbnN3ZXIsIGV2ZW4gaWYgaXQgaXNu4oCZdCBt eSBzdWdnZXN0aW9uIG9mIGFuIOKAnHNpdGVz4oCdIGxpc3Qgd2hlbiBhIHRva2VuIGlzIGlzc3Vl ZC4NCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E112631B257DWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkhvdyBzaG91bGQgYW4gT0F1dGggY2xpZW50IGFwcCBi ZWhhdmUgd2hlbiBpdCBnZXRzIGFuIEhUVFAgcmVkaXJlY3Qgb24gcmVxdWVzdGluZyBhIHByb3Rl Y3RlZCByZXNvdXJjZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5TaW1pbGFybHks IGhvdyBzaG91bGQgaXQgYmVoYXZlIHdoZW4gaXQgZm9sbG93cyBhbnkgb3RoZXIgbGluayBpbiBh IHJlc3BvbnNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPk9idmlvdXNseSBpdCBzaG91bGQgbWFrZSBhIG5ldyBy ZXF1ZXN0IHRvIHRoZSBVUkkgaW4gdGhlIHJlZGlyZWN0IG9yIGxpbmsg4oCUIHRoYXQgaXMgbm9y bWFsIEhUVFAgYW5kIGh5cGVydGV4dCBiZWhhdmlvdXIuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+VGhlIHF1ZXN0aW9uIGlzIGRvZXMgdGhlIHRva2VuIGdldCBzZW50IHdpdGggdGhl IG5ldyByZXF1ZXN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPkkgdGhpbmsgdGhlIHNwZWMgbmVlZHMgdG8gcHJvdmlkZSBhbiBhbnN3ZXIsIGV2 ZW4gaWYgaXQgaXNu4oCZdCBteSBzdWdnZXN0aW9uIG9mIGFuIOKAnHNpdGVz4oCdIGxpc3Qgd2hl biBhIHRva2VuIGlzIGlzc3VlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4tLQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_255B9BB34FB7D647A506DC292726F6E112631B257DWSMSG3153Vsrv_-- From torsten@lodderstedt.net Thu May 6 22:40:24 2010 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 12BD13A6C9C for ; Thu, 6 May 2010 22:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 0h6TWxBMJVlu for ; Thu, 6 May 2010 22:40:23 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id 6E4923A6CD8 for ; Thu, 6 May 2010 22:32:46 -0700 (PDT) Received: from p4fff11be.dip.t-dialin.net ([79.255.17.190] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OAGAl-000648-Dv; Fri, 07 May 2010 07:32:27 +0200 Message-ID: <4BE3A5DC.5030601@lodderstedt.net> Date: Fri, 07 May 2010 07:32:12 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------090109080401080605060004" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 05:40:24 -0000 This is a multi-part message in MIME format. --------------090109080401080605060004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit what about an additional realm response value? If there is a binding between realm and token, the client can decide based on the realm attribute discovered using a WWW-Authenticate response which token to use. regards, Torsten. Am 07.05.2010 07:06, schrieb Manger, James H: > > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on > clients being told by the server about the sites at which the secret > (cookie/password/token) can be used (and, more importantly, where is > must not be used). This occurs without requiring service-specific > knowledge in the client app. OAuth aims to replace some of these uses. > > HTTP Basic authentication works safely from clients with no > service-specific knowledge because the client knows not to send the > password it gets from the user to other sites. > > HTTP Digest authentication allows a password to used to across a set > of domains specified in a WWW-Authenticate response header, but the > password will not be used at arbitrary other sites. > > Cookies are sent in requests to the same site, sites with the same > parent, or only https sites, depending on details from the service > when setting the cookie. > > To date, OAuth has assumed every client app has lots of > service-specific knowledge to make these choices. OAuth needs to > remove the need for so much service-specific knowledge to be as > interoperable as other standard auth mechanism, otherwise it is a poor > replacement. > > -- > > James Manger > > *From:* David Recordon [mailto:recordond@gmail.com] > *Sent:* Friday, 7 May 2010 2:05 PM > *To:* Manger, James H > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid > > Hey James, > > Do you have a specific example in mind where this either has been an > issue or will be an issue? Most client implementations I've seen of > OAuth (and technologies like OAuth) have a strong binding between the > access token(s), site they were issued by, and user they belong to. So > I haven't heard of this being a problem in the wild... > > --David > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090109080401080605060004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit what about an additional realm response value?

If there is a binding between realm and token, the client can decide based on the realm attribute discovered using a WWW-Authenticate response which token to use.

regards,
Torsten.
 
Am 07.05.2010 07:06, schrieb Manger, James H:

Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clients being told by the server about the sites at which the secret (cookie/password/token) can be used (and, more importantly, where is must not be used). This occurs without requiring service-specific knowledge in the client app. OAuth aims to replace some of these uses.

 

HTTP Basic authentication works safely from clients with no service-specific knowledge because the client knows not to send the password it gets from the user to other sites.

 

HTTP Digest authentication allows a password to used to across a set of domains specified in a WWW-Authenticate response header, but the password will not be used at arbitrary other sites.

 

Cookies are sent in requests to the same site, sites with the same parent, or only https sites, depending on details from the service when setting the cookie.

 

 

To date, OAuth has assumed every client app has lots of service-specific knowledge to make these choices. OAuth needs to remove the need for so much service-specific knowledge to be as interoperable as other standard auth mechanism, otherwise it is a poor replacement.

 

--

James Manger

 

From: David Recordon [mailto:recordond@gmail.com]
Sent: Friday, 7 May 2010 2:05 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

 

Hey James,

Do you have a specific example in mind where this either has been an issue or will be an issue? Most client implementations I've seen of OAuth (and technologies like OAuth) have a strong binding between the access token(s), site they were issued by, and user they belong to. So I haven't heard of this being a problem in the wild...

 

--David

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------090109080401080605060004-- From recordond@gmail.com Thu May 6 22:42:56 2010 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 CBC573A6B92 for ; Thu, 6 May 2010 22:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, 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 oA+AYt9tEdn1 for ; Thu, 6 May 2010 22:42:55 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id E6FB23A6BAB for ; Thu, 6 May 2010 22:36:10 -0700 (PDT) Received: by iwn27 with SMTP id 27so1006835iwn.5 for ; Thu, 06 May 2010 22:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mFP7aHAiBxu7LD6ert7osHEy2HuI7RVvvY+VieilV9U=; b=ZtSWxcjnlTue4u5qtYRRhZL9cbU5+8BNyqYObymbFxXJqtKIoNYeW8K0+d3D1GgqCj C8KSVEXJs4/ZQowpbjgS10DGFwmeDy98+YAoQUymc7LBbGihtpXbAEuLUEezbfWHRVaR icFnUjGodQr4reTZoOKzyX0z9/lTmZEiylL3E= 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=wdyqsq/G+Y/u4uYAN4dvWEn2YkpfTA+SagjPmwHBv32u8bMqM9hiNAyMPlwEMV2QAa XjUnA1zOhi9sCZlegkcM8PN5B05hbPboHubdtHv6BjJwmyHXs75d1OQOZAvxyrIHRJHE cyfp8omc12PB2MjiOFJQ9NlYMJT9kx5fVq7ks= MIME-Version: 1.0 Received: by 10.231.153.130 with SMTP id k2mr1262440ibw.78.1273210555755; Thu, 06 May 2010 22:35:55 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Thu, 6 May 2010 22:35:55 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 6 May 2010 22:35:55 -0700 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: multipart/alternative; boundary=005045013e81e66c580485fa6ec0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 05:42:57 -0000 --005045013e81e66c580485fa6ec0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Why wouldn't the client send the token with the new request? If I'm trying to access https://api.example.com/pr?access_token=3Dloin21op and I get a 30= 1 response, I'll need to follow that if I want any chance of accessing the protected resource. Maybe we're saying the same thing? On Thu, May 6, 2010 at 10:21 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > How should an OAuth client app behave when it gets an HTTP redirect on > requesting a protected resource? > > Similarly, how should it behave when it follows any other link in a > response? > > > > Obviously it should make a new request to the URI in the redirect or link= =97 > that is normal HTTP and hypertext behaviour. > > The question is does the token get sent with the new request? > > > > > > I think the spec needs to provide an answer, even if it isn=92t my sugges= tion > of an =93sites=94 list when a token is issued. > > > > -- > > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --005045013e81e66c580485fa6ec0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Why wouldn't the client send the token with the new request? If I'm= trying to access https://api.example.com/pr?access_token=3Dloin21op and I get a 30= 1 response, I'll need to follow that if I want any chance of accessing = the protected resource.

Maybe we're saying the same thing?


On Thu, May 6, 2010 at 10:21 PM, Manger, James H <James.= H.Manger@team.telstra.com> wrote:

How s= hould an OAuth client app behave when it gets an HTTP redirect on requestin= g a protected resource?

Simil= arly, how should it behave when it follows any other link in a response?

=A0

Obvio= usly it should make a new request to the URI in the redirect or link =97 th= at is normal HTTP and hypertext behaviour.

The q= uestion is does the token get sent with the new request?

=A0

=A0

I thi= nk the spec needs to provide an answer, even if it isn=92t my suggestion of= an =93sites=94 list when a token is issued.

=A0

--

James= Manger


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


--005045013e81e66c580485fa6ec0-- From lshepard@facebook.com Thu May 6 22:49:01 2010 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 803B128C134 for ; Thu, 6 May 2010 22:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 bBrcdxWgOlM0 for ; Thu, 6 May 2010 22:49:00 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 44AA428C13A for ; Thu, 6 May 2010 22:40:06 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o475dO45027511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 May 2010 22:39:30 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub02.TheFacebook.com (192.168.18.105) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 6 May 2010 22:39:42 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Thu, 6 May 2010 22:39:43 -0700 From: Luke Shepard To: Allen Tom Date: Thu, 6 May 2010 22:39:42 -0700 Thread-Topic: [OAUTH-WG] OAuth 1 Bridge Flow Thread-Index: Acrtp7Gqn4HtxwwHTiWmm+aBg8EwhQ== Message-ID: <5436B1F2-29D7-4405-B5DB-DB60C0E617AE@facebook.com> References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-07_01:2010-02-06, 2010-05-07, 2010-05-06 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 07 May 2010 05:49:01 -0000 Obviously if a service adopts OAuth 2.0, they should continue supporting th= eir old method of login - Facebook will no doubt continue to support its ol= d method of MD5 sigs for a long time, so as not to break apps in the wild. But if a user has already authorized your app, and you WANT to use OAuth 2.= 0 but you have an old token, then you should be able to silently exchange a= n OAuth 1.0 token for an access token without asking the user for permissio= n. That's the flow Marius proposed. To Marius: > Are the issued OAuth 2.0 access tokens short lived? Is "expires" a > delta or an absolute time? Our access tokens, like our session keys, can be either short lived (1 hour= ) or long lived (basically infinite). In practice, though, we don't expect = people to go to the effort of exchanging a short-lived token - after exchan= ge, the new token has the same expiration as the original. It looks like we= are using an absolute time when we should be doing a delta, good catch. On May 4, 2010, at 4:03 PM, Allen Tom wrote: > Although we have not formally announced any plans to support OAuth2 yet, = I > would expect that Yahoo would be able to simultaneously support both Oaut= h > 1.0a and OAuth2 without requiring clients to upgrade their existing Oauth > 1.0a credentials for OAuth2. >=20 > Note: Yahoo currently requires the Session Extension, so all of our Acces= s > Tokens are valid for one hour. The OAuth2 Refresh Token is equivalent to = the > Session Extension's "Auth Session Handle" >=20 > Allen >=20 >=20 > On 5/4/10 11:46 AM, "Justin Richer" wrote: >=20 >> Interesting work. So as each app upgrades its support from OAuth1 to >> OAuth2, it exchanges its old tokens for new ones once for each user, >> right? Then the app in question is effectively going to have to speak >> both flavors of OAuth to do this one-time upgrade. I always assumed that >> apps would just have to get new OAuth2 access tokens by going back to >> the user (since tokens are cheap), but I can definitely see value in >> there being a clean upgrade path, especially for wide deployments. >>=20 >> Because the other side of things, what would it take an implementor to >> have a backwards-compatible system? Since the OAuth2 protocol is by >> design not backwards compatible (though the signature-based web flows >> are all the same spirit as 1.0a, all the parameter names are different), >> I'm thinking that one would need either parallel endpoints or a proxy of >> some kind that works almost like that which was proposed here, but on an >> ongoing basis.=20 >>=20 >> -- Justin >>=20 >> On Tue, 2010-05-04 at 13:26 -0400, Marius Scurtescu wrote: >>> Hi, >>>=20 >>> I would like to suggest a flow, or endpoint, that is bridging OAuth 1 >>> and OAuth 2. See the attachment. >>>=20 >>> The OAuth 1 Bridge Flow basically defines an endpoint where you can >>> place a signed OAuth 1 request and in response you receive a short >>> lived OAuth 2.0 access token. This flow can be used by clients that >>> have a long lived OAuth 1.0 access token and want to use a short lived >>> OAuth 2.0 access token to access protected resources. >>>=20 >>> Do you have a use case for a flow like this? If not exactly but close, >>> how can the flow be improved to cover your use case as well? >>>=20 >>> Feedback more than welcome. >>>=20 >>> Thanks, >>> Marius >>=20 >>=20 >> _______________________________________________ >> 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 From lshepard@facebook.com Thu May 6 22:52:10 2010 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 2DB1B3A6BB4 for ; Thu, 6 May 2010 22:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8wTrtHzMXFzT for ; Thu, 6 May 2010 22:52:04 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 1E7083A6BE0 for ; Thu, 6 May 2010 22:44:07 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o475gbmL015452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 May 2010 22:42:37 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub01.TheFacebook.com (192.168.18.104) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 6 May 2010 22:43:12 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Thu, 6 May 2010 22:43:13 -0700 From: Luke Shepard To: "Foiles, Doug" Date: Thu, 6 May 2010 22:43:12 -0700 Thread-Topic: [OAUTH-WG] OAuth 1 Bridge Flow Thread-Index: AcrtqC5l0tYK2yq3SnSzhIKhSdrnhw== Message-ID: <98969167-FBAB-4FDE-BDBA-888AB08BB687@facebook.com> References: <1272998796.6288.55.camel@localhost.localdomain> 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-07_01:2010-02-06, 2010-05-07, 2010-05-06 signatures=0 Cc: Marius, OAuth WG Subject: Re: [OAUTH-WG] OAuth 1 Bridge Flow 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, 07 May 2010 05:52:10 -0000 On May 5, 2010, at 7:09 AM, Foiles, Doug wrote: > I would expect our OAuth 1.0 services to have support for OAuth 1.0 and 2= .0 for some period. I don't think we could expect all our clients to move = to OAuth 2.0 at once. This is an interesting idea that allows clients to b= e able to cut over to OAuth 2.0 without users having to re-authenticate/aut= horize. >=20 > Why not just transfer the remaining session lifetime to the new access to= ken (or refresh token if requested). I would expect the scope to be transf= erred as well. I would want our users to authorize any extended period. >=20 Yeah. Facebook's access tokens are literally just wrapping the old session = tokens, so the access token preserves all the original properties. I expect= many services that upgrade will likely use a similar approach. From lshepard@facebook.com Thu May 6 22:54:13 2010 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 A086F3A69B3 for ; Thu, 6 May 2010 22:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 Bpzd+pX0tN-L for ; Thu, 6 May 2010 22:54:11 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id CECB428C13D for ; Thu, 6 May 2010 22:49:25 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o475msnH002334 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 May 2010 22:48:54 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Thu, 6 May 2010 22:48:12 -0700 From: Luke Shepard To: Greg Brail Date: Thu, 6 May 2010 22:48:12 -0700 Thread-Topic: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) Thread-Index: AcrtqOE4Oq2YZM9aR+2qWUdIZTCltw== Message-ID: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> <01bb1f595f89af50b0c37c00dbcd54cd@mail.gmail.com> In-Reply-To: <01bb1f595f89af50b0c37c00dbcd54cd@mail.gmail.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_E9F67F8BDF8740D58BCFF9113D14BD77facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-07_01:2010-02-06, 2010-05-07, 2010-05-06 signatures=0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 07 May 2010 05:54:13 -0000 --_000_E9F67F8BDF8740D58BCFF9113D14BD77facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 6, 2010, at 9:13 AM, Greg Brail wrote: I agree that JSON is the long-term winner. However, at least for Java and P= ython I know that JSON parsers are not part of the standard library, wherea= s everything needed to decode a url-formencoded library is in the standard = libraries and has been there for a long, long time. Keep in mind that the o= verhead of using third-party code is not just in finding and using the righ= t library, but getting legal clearance if it's open source and you work for= a big company. Python includes a JSON parser in Python 2.6: http://docs.python.org/library= /json.html Java has JSONObject available. Are there cases where it would be difficult = to use a library like this? --_000_E9F67F8BDF8740D58BCFF9113D14BD77facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree that JSON is the long-term winner= . However, at least for Java and Python I know that JSON parsers are not pa= rt of the standard library, whereas everything needed to decode a url-forme= ncoded library is in the standard libraries and has been there for a long, = long time. Keep in mind that the overhead of using third-party code is not = just in finding and using the right library, but getting legal clearance if= it's open source and you work for a big company.
<= /span>

Python includes a JSON parser in Pyt= hon 2.6: http://d= ocs.python.org/library/json.html 

Java ha= s JSONObject available. Are there cases where it would be difficult to use = a library like this?

= --_000_E9F67F8BDF8740D58BCFF9113D14BD77facebookcom_-- From lshepard@facebook.com Thu May 6 22:55:50 2010 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 7D6823A6B3F for ; Thu, 6 May 2010 22:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 o8u0JIfxm1P8 for ; Thu, 6 May 2010 22:55:49 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 579B43A6CAB for ; Thu, 6 May 2010 22:51:48 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o475pGpb004974 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 May 2010 22:51:16 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Thu, 6 May 2010 22:51:34 -0700 From: Luke Shepard To: David Recordon Date: Thu, 6 May 2010 22:51:33 -0700 Thread-Topic: [OAUTH-WG] Redirects Thread-Index: AcrtqVm9Kr8dDE2/SXyChXm5hxI53g== Message-ID: References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.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: multipart/alternative; boundary="_000_E111581C87CE44F1881DC512FAC7B203facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-07_01:2010-02-06, 2010-05-07, 2010-05-06 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 05:55:50 -0000 --_000_E111581C87CE44F1881DC512FAC7B203facebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It's not really up to the client. If https://api.example.com/pr?access_toke= n=3Dloin21op redirects to https://api.otherapi.com/somethingelse?access_tok= en=3Dloin21op, then I just need to follow the redirect - no decisions to be= made by the client. Many low-level HTTP libraries will just do this automa= tically. There are already facilities to warn if you try to redirect from a= n https url to an http one. I think the difference between your cookie example and OAuth token is that = cookies are automatically sent on every request, so there have to be rules = about when they are automatically appended. OAuth access tokens aren't the = same thing - they are explicitly added by developers on each request, so we= don't need to overspecify rules in the protocol that should be handled by = developers. On May 6, 2010, at 10:35 PM, David Recordon wrote: Why wouldn't the client send the token with the new request? If I'm trying = to access https://api.example.com/pr?access_token=3Dloin21op and I get a 30= 1 response, I'll need to follow that if I want any chance of accessing the = protected resource. Maybe we're saying the same thing? On Thu, May 6, 2010 at 10:21 PM, Manger, James H > wrote: How should an OAuth client app behave when it gets an HTTP redirect on requ= esting a protected resource? Similarly, how should it behave when it follows any other link in a respons= e? Obviously it should make a new request to the URI in the redirect or link = =97 that is normal HTTP and hypertext behaviour. The question is does the token get sent with the new request? I think the spec needs to provide an answer, even if it isn=92t my suggesti= on of an =93sites=94 list when a token is issued. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_E111581C87CE44F1881DC512FAC7B203facebookcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It's not really up to the = client. If https://api.example.com/pr?access_token=3Dloin21op redirects t= o https://api.otherapi.com/somethingelse?access_token=3Dloin21op, = then I just need to follow the redirect - no decisions to be made by the cl= ient. Many low-level HTTP libraries will just do this automatically. There = are already facilities to warn if you try to redirect from an https url to = an http one.

I think the difference between your cookie = example and OAuth token is that cookies are automatically sent on every req= uest, so there have to be rules about when they are automatically appended.= OAuth access tokens aren't the same thing - they are explicitly added by d= evelopers on each request, so we don't need to overspecify rules in the pro= tocol that should be handled by developers.

<= br>
On May 6, 2010, at 10:35 PM, David Recordon wrote:

Why wouldn't th= e client send the token with the new request? If I'm trying to access https://api.examp= le.com/pr?access_token=3Dloin21op and I get a 301 response, I'll need t= o follow that if I want any chance of accessing the protected resource.
Maybe we're saying the same thing?


On Thu, May 6, 2010 at 10:21 PM, Manger, James H <James.H.Ma= nger@team.telstra.com> wrote:

= How should an OAuth client app behave when it gets an HTTP redirect on requ= esting a protected resource?

Similarly, how should it behave when it= follows any other link in a response?

 

Obviously it should make a new request to the URI in the redirect or li= nk =97 that is normal HTTP and hypertext behaviour.

The question is do= es the token get sent with the new request?

 
 

I think the spec needs to provi= de an answer, even if it isn=92t my suggestion of an =93sites=94 list when = a token is issued.

 

--

James Manger


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


<ATT00001..txt>

= --_000_E111581C87CE44F1881DC512FAC7B203facebookcom_-- From torsten@lodderstedt.net Thu May 6 23:01:01 2010 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 C891D3A6985 for ; Thu, 6 May 2010 23:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_05=-1.11, HELO_EQ_DE=0.35, 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 ztFOR2rkslhh for ; Thu, 6 May 2010 23:01:00 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by core3.amsl.com (Postfix) with ESMTP id 597CA3A69EB for ; Thu, 6 May 2010 23:00:56 -0700 (PDT) Received: from [79.255.17.190] (helo=[192.168.71.22]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OAGc6-00027b-Rg; Fri, 07 May 2010 08:00:43 +0200 References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> Message-Id: From: Torsten Lodderstedt To: Luke Shepard In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-17-699562371 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 7 May 2010 08:00:18 +0200 X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 06:01:01 -0000 --Apple-Mail-17-699562371 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable in the same way as BASIC authorization headers are added to requests =20 based on the associated realm, a Oauth library could automatically add =20= tokens based in the realm obtained from WWW-Authenticate response =20 header. Regards, Torsten. Am 07.05.2010 um 07:51 schrieb Luke Shepard : > It's not really up to the client. If = https://api.example.com/pr?access_token=3Dloin21op=20 > redirects to = https://api.otherapi.com/somethingelse?access_token=3Dloin21op=20 > , then I just need to follow the redirect - no decisions to be made =20= > by the client. Many low-level HTTP libraries will just do this =20 > automatically. There are already facilities to warn if you try to =20 > redirect from an https url to an http one. > > I think the difference between your cookie example and OAuth token =20 > is that cookies are automatically sent on every request, so there =20 > have to be rules about when they are automatically appended. OAuth =20 > access tokens aren't the same thing - they are explicitly added by =20 > developers on each request, so we don't need to overspecify rules in =20= > the protocol that should be handled by developers. > > > On May 6, 2010, at 10:35 PM, David Recordon wrote: > >> Why wouldn't the client send the token with the new request? If I'm =20= >> trying to access https://api.example.com/pr?access_token=3Dloin21op =20= >> and I get a 301 response, I'll need to follow that if I want any =20 >> chance of accessing the protected resource. >> >> Maybe we're saying the same thing? >> >> >> On Thu, May 6, 2010 at 10:21 PM, Manger, James H = > > wrote: >> How should an OAuth client app behave when it gets an HTTP redirect =20= >> on requesting a protected resource? >> >> Similarly, how should it behave when it follows any other link in a =20= >> response? >> >> >> Obviously it should make a new request to the URI in the redirect =20 >> or link =E2=80=94 that is normal HTTP and hypertext behaviour. >> >> The question is does the token get sent with the new request? >> >> >> >> I think the spec needs to provide an answer, even if it isn=E2=80=99t = my s=20 >> uggestion of an =E2=80=9Csites=E2=80=9D list when a token is issued. >> >> >> -- >> >> James Manger >> >> >> _______________________________________________ >> 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 --Apple-Mail-17-699562371 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
in the same way as BASIC = authorization headers are added to requests based on the associated = realm, a Oauth library could automatically add tokens based in the realm = obtained from WWW-Authenticate response = header.

Regards,
Torsten. =  


Am 07.05.2010 um 07:51 schrieb Luke Shepard = <lshepard@facebook.com>:
It's not = really up to the client. If https://api.ex= ample.com/pr?access_token=3Dloin21op redirects to ht= tps://api.otherapi.com/somethingelse?access_token=3Dloin21op, = then I just need to follow the redirect - no decisions to be made by the = client. Many low-level HTTP libraries will just do this automatically. = There are already facilities to warn if you try to redirect from an = https url to an http one.

I think the difference = between your cookie example and OAuth token is that cookies are = automatically sent on every request, so there have to be rules about = when they are automatically appended. OAuth access tokens aren't the = same thing - they are explicitly added by developers on each request, so = we don't need to overspecify rules in the protocol that should be = handled by developers.


On = May 6, 2010, at 10:35 PM, David Recordon wrote:

Why = wouldn't the client send the token with the new request? If I'm trying = to access <= a = href=3D"https://api.example.com/pr?access_token=3Dloin21op">https://api.ex= ample.com/pr?access_token=3Dloin21op and I get a 301 response, = I'll need to follow that if I want any chance of accessing the protected = resource.

Maybe we're saying the same thing?


On Thu, May 6, 2010 at 10:21 PM, Manger, James H = <James.H.Manger@team.telstr= a.com> wrote:

How should an OAuth client app = behave when it gets an HTTP redirect on requesting a protected = resource?

Similarly, how should it behave = when it follows any other link in a response?

 

Obviously it should make a new = request to the URI in the redirect or link =E2=80=94 that is normal HTTP = and hypertext behaviour.

The question is does the token = get sent with the new request?

 
 

I think the spec needs to = provide an answer, even if it isn=E2=80=99t my suggestion of an = =E2=80=9Csites=E2=80=9D list when a token is = issued.

 

--

James Manger


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= <ATT00001..txt>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
= --Apple-Mail-17-699562371-- From torsten@lodderstedt.net Thu May 6 23:08:30 2010 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 E45853A69EF for ; Thu, 6 May 2010 23:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 jLY7rZIkb1Ir for ; Thu, 6 May 2010 23:08:29 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 818113A6BC0 for ; Thu, 6 May 2010 23:06:42 -0700 (PDT) Received: from [79.255.17.190] (helo=[192.168.71.22]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OAGhg-0003fj-Dl; Fri, 07 May 2010 08:06:28 +0200 References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> Message-Id: From: Torsten Lodderstedt To: Torsten Lodderstedt In-Reply-To: <4BE3A5DC.5030601@lodderstedt.net> Content-Type: multipart/alternative; boundary=Apple-Mail-18-699908534 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 7 May 2010 08:06:03 +0200 X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 06:08:31 -0000 --Apple-Mail-18-699908534 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Additionally, I would propose to indicate the scope associated with a token to the client using a scope response parameter. This is especially useful (1) if the client did not pass a scope parameter but the server decided to associate a scope based on its policy or (2) if the user decided to authorize a subset of the requested scope only. Regards, Torsten. Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt : > what about an additional realm response value? > > If there is a binding between realm and token, the client can decide > based on the realm attribute discovered using a WWW-Authenticate > response which token to use. > > regards, > Torsten. > > Am 07.05.2010 07:06, schrieb Manger, James H: >> >> Every existing use of Cookies, HTTP Basic, and HTTP Digest relies >> on clients being told by the server about the sites at which the >> secret (cookie/password/token) can be used (and, more importantly, >> where is must not be used). This occurs without requiring service- >> specific knowledge in the client app. OAuth aims to replace some of >> these uses. >> >> HTTP Basic authentication works safely from clients with no service- >> specific knowledge because the client knows not to send the >> password it gets from the user to other sites. >> >> HTTP Digest authentication allows a password to used to across a >> set of domains specified in a WWW-Authenticate response header, but >> the password will not be used at arbitrary other sites. >> >> Cookies are sent in requests to the same site, sites with the same >> parent, or only https sites, depending on details from the service >> when setting the cookie. >> >> >> To date, OAuth has assumed every client app has lots of service- >> specific knowledge to make these choices. OAuth needs to remove the >> need for so much service-specific knowledge to be as interoperable >> as other standard auth mechanism, otherwise it is a poor replacement. >> >> -- >> James Manger >> >> From: David Recordon [mailto:recordond@gmail.com] >> Sent: Friday, 7 May 2010 2:05 PM >> To: Manger, James H >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid >> >> Hey James, >> Do you have a specific example in mind where this either has been >> an issue or will be an issue? Most client implementations I've seen >> of OAuth (and technologies like OAuth) have a strong binding >> between the access token(s), site they were issued by, and user >> they belong to. So I haven't heard of this being a problem in the >> wild... >> >> --David >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-18-699908534 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Additionally, I would propose to indicate the scope associated with a token to the client using a scope response parameter. This is especially useful (1) if the client did not pass a scope parameter but the server decided to associate a scope based on its policy or (2) if the user decided to authorize a subset of the requested scope only.

Regards,
Torsten.     



Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt <torsten@lodderstedt.net>:

what about an additional realm response value?

If there is a binding between realm and token, the client can decide based on the realm attribute discovered using a WWW-Authenticate response which token to use.

regards,
Torsten.
 
Am 07.05.2010 07:06, schrieb Manger, James H:

Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clients being told by the server about the sites at which the secret (cookie/password/token) can be used (and, more importantly, where is must not be used). This occurs without requiring service-specific knowledge in the client app. OAuth aims to replace some of these uses.

 

HTTP Basic authentication works safely from clients with no service-specific knowledge because the client knows not to send the password it gets from the user to other sites.

 

HTTP Digest authentication allows a password to used to across a set of domains specified in a WWW-Authenticate response header, but the password will not be used at arbitrary other sites.

 

Cookies are sent in requests to the same site, sites with the same parent, or only https sites, depending on details from the service when setting the cookie.

 

 

To date, OAuth has assumed every client app has lots of service-specific knowledge to make these choices. OAuth needs to remove the need for so much service-specific knowledge to be as interoperable as other standard auth mechanism, otherwise it is a poor replacement.

 

--

James Manger

 

From: David Recordon [mailto:recordond@gmail.com]
Sent: Friday, 7 May 2010 2:05 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

 

Hey James,

Do you have a specific example in mind where this either has been an issue or will be an issue? Most client implementations I've seen of OAuth (and technologies like OAuth) have a strong binding between the access token(s), site they were issued by, and user they belong to. So I haven't heard of this being a problem in the wild...

 

--David

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--Apple-Mail-18-699908534-- From James.H.Manger@team.telstra.com Thu May 6 23:09:40 2010 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 0011D3A6AA8 for ; Thu, 6 May 2010 23:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.287 X-Spam-Level: * X-Spam-Status: No, score=1.287 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDnNhIn6OuYz for ; Thu, 6 May 2010 23:09:39 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id C52303A6BAB for ; Thu, 6 May 2010 23:08:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,346,1270389600"; d="p7s'?scan'208,217";a="2260734" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 07 May 2010 16:08:11 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1633150" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbvi.tcif.telstra.com.au with ESMTP; 07 May 2010 16:08:11 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Fri, 7 May 2010 16:08:11 +1000 From: "Manger, James H" To: OAuth WG Date: Fri, 7 May 2010 16:08:10 +1000 Thread-Topic: [OAUTH-WG] Redirects Thread-Index: AcrtpyvQjD80fZDqQWGuGphhPdGG+QAAA3Iw Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B26B1@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0061_01CAEDFF.7CCFD880" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 06:09:40 -0000 ------=_NextPart_000_0061_01CAEDFF.7CCFD880 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0062_01CAEDFF.7CCFD880" ------=_NextPart_001_0062_01CAEDFF.7CCFD880 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Luke said: > I think the difference between your cookie example and OAuth token is = that cookies are automatically sent on every request, so there have to = be rules about when they are automatically appended. OAuth access tokens = aren't the same thing - they are explicitly added by developers on each = request, so we don't need to overspecify rules in the protocol that = should be handled by developers. =20 =20 It is not just cookies, but HTTP Basic, HTTP Digest, NTLM etc are = automatically sent on every request. In fact, I suspect most auth = schemes are automatically applied. OAuth should not be any different. I = hope decent libraries allow an OAuth token to be configured orthogonally = to the code that actually makes the API requests. =20 Even if tokens are =E2=80=9Cexplicitly added by developers on each = requests=E2=80=9D, the developers need to know which requests this = applies to. A cornerstone of hypertext is making request based on links = in responses. How does an app know if a link it finds in a response is = part of the same API (so the token should be added) or an = =E2=80=9Cexternal=E2=80=9D link? =20 =20 --=20 James Manger ------=_NextPart_001_0062_01CAEDFF.7CCFD880 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Luke said:

> I think the difference between your cookie = example and OAuth token is that cookies are automatically sent on every request, so = there have to be rules about when they are automatically appended. OAuth = access tokens aren't the same thing - they are explicitly added by developers = on each request, so we don't need to overspecify rules in the protocol that = should be handled by developers.

 

 

It is not just cookies, but HTTP Basic, HTTP Digest, NTLM = etc are automatically sent on every request. In fact, I suspect most auth = schemes are automatically applied. OAuth should not be any different. I hope = decent libraries allow an OAuth token to be configured orthogonally to the code = that actually makes the API requests.

 

Even if tokens are =E2=80=9Cexplicitly added by = developers on each requests=E2=80=9D, the developers need to know which requests this = applies to. A cornerstone of hypertext is making request based on links in responses. How does an = app know if a link it finds in a response is part of the same API (so the = token should be added) or an =E2=80=9Cexternal=E2=80=9D = link?

 

 

--

James Manger

------=_NextPart_001_0062_01CAEDFF.7CCFD880-- ------=_NextPart_000_0061_01CAEDFF.7CCFD880 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIc2jCCBqMw ggSLoAMCAQICEClsBJZEfCC2SncEyz0UzYEwDQYJKoZIhvcNAQEFBQAwGjEYMBYGA1UEAxMPVGVs c3RyYSBSb290IENBMB4XDTA5MTExNjA0NTkxM1oXDTM0MTExNjA1MDYxMVowGjEYMBYGA1UEAxMP VGVsc3RyYSBSb290IENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA3r3Fb5E/8GUk cHwd9/kRB14EH1trG6C7NrwmF7isLj3j8fbELwkg0Lm0qzVuYziwqC3sbB4BcpY1YU9UZfB8J7cO Efbk1GkVkSwNnpKyUHsxAWAelb0eOord3bB21M2UeUyWkGQhoU3+ZxyaAALKDm1QZQx7Tw8wdkIQ mc1mJ4cJg/I9dTk1J5ybG4ZWs4/87PnLe0A5KRD841YWeKO1oLrV6Zvj65Aa6gpme0AdLVEDStM/ 4jNtso6jf63ixizKzazfbt5lJJZizGHelymCF2BGjps0+6eMsteMmfQ84OXG82V00pFy6kwGjH6+ Y081OXTo6Gq/sR+6d4RDFIltIYGyYKKBzsEGw2MJqxqyXat9UV/50xspN26BZlB5zHFNdKI9eBKC sv6EpgklYSfv9vgNBBnwavHmGvmw12i0NUd9WlS3YybQzxnWE49Q05jIxt+ZgV4Rg6oiCRb7rktN d8qwRUb0LcSfcYOqGGffuckNQzKGNGySrkznOrC33BsVEmGMgXGqtZk4L7Sfq5NL1y7wCJUKw8qI Ox/ijs0SSfc9VDwqZmhEM9NV8sGUsvmTeH1D8G06zjmE6loXUyIQXZLohQQ96TQyjKuA3lvtCbJt yHFbgyi8wVJG+Ze3+Ywo+JB10rlR7FF6XEniihJEIYAHkSsGRqOASUzBA7p2Ip8CAwEAAaOCAeMw ggHfMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1UdDgQWBBSXNqRMMI9eSlUu k+RwLu+s1mV3iDAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwDQYJKoZIhvcNAQEFBQADggIBAHZuKnwg4R4Fk32A fxTzTHtDboZI1ZW3Yv7nSdqfZlnfF8bEAD6FSEoMJ0w6jProxVXSZwia5Fkhf4jt6M949PP+G5Cl V89x3z8pECqJhbVcZbE9p1hJXPy72IwILRblSnTnPh9CTLV0gTOkmX6SmrDMG3GSV3djTt8cf88o JTcbRe0vJgFwf5sPlMEplrK3tK0pIjomzcoGLfP9Zv+wvVLvGvu5TVxWiFIQrdtuUjzL3/2VxFb4 M5kLQaQCaxTOxcB/8epSyaInbLI1YsyhRtPyzCAT0pbTTPKR3eNgMF7YlzakASa5LbiTkWIayS8h s+MjkqIF9CX1PwOBphQgJa3yPm4bIfNBGH4520knrb5r/D/cTDtjarXh4v/ExJphEqbU6m44C4Wq Cp7jV3v6Xm91QaQbCF/e4H4RD9PTr/c+MILhmhEq879n6iF6276oe2kWZE0yXy8eiK5Ung0F2tJX PfQidNaI9NTMHViQoacVY9ah/juHnEIrnEozrYuMLqC+39i9BXAIQ4Qq7GJ132xr5o8/xb2iQ1IZ wD27yb7Or1gzcKjKvJj/pkCeDgC7fQVlxtvfDBjiKuAoWs7PXGTtGzfiObrnEmhmR0DnWSehA5ld o3/fyiGuyN53nU+ewQY4AyE8jBzPxq6YmVjWM0FAdyJLHyX+YBvYjs2VAX2cMIIG6jCCBNKgAwIB AgIKYQWDvgAAAAAABTANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9UZWxzdHJhIFJvb3QgQ0Ew HhcNMDkxMTI1MDEyNDI3WhcNMTkxMTI1MDEzNDI3WjBDMSQwIgYDVQQKExtUZWxzdHJhIENvcnBv cmF0aW9uIExpbWl0ZWQxGzAZBgNVBAMTElRlbHN0cmEgUG9saWN5IENBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAK3IBZQGtMLEw5e8k3SJcSRf/BnMWwguu1Ltka6XK/nmcmjTOPl/ qqpkC2uBZUFZAflrWJdmh5MTamCWNMsRSmtiWwSJQsFTPWstSRELqkuM0+lXIlTTU4dTFM3cp/pE l4ly+xBUd6ndQQeB/MOsTsbdkhALj/oMZzSSVLJw3cngrS4pG9TjV8zKMIkZQBeIURBgqh1yd6nX n1FNctjyDH1ybxftcuhK3hEEbPrAHJQB9YN317l7ISYqg99jec/3mVf0C1fOuzefKHGINXo8M2lL H3P4O28fSmaLyJK3p6IStoRmtrHwIkc9WHnDe0e9aieQx+PPosll61EtyJiaRX0CAwEAAaOCAwcw ggMDMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFJT5/udCeR3rxZ9HUpfHV7X4nD4oMAsG A1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYD VR0jBBgwFoAUlzakTDCPXkpVLpPkcC7vrNZld4gwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwUm9vdCUyMENBLmNybDCBlQYI KwYBBQUHAQEEgYgwgYUwSQYIKwYBBQUHMAKGPWh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVsc3Ry YS5jb20uYXUvVGVsc3RyYSUyMFJvb3QlMjBDQS5jcnQwOAYIKwYBBQUHMAGGLGh0dHA6Ly90ZWxz dHJhLW9jc3AucGtpLnRlbHN0cmEuY29tLmF1L29jc3AvMA0GCSqGSIb3DQEBBQUAA4ICAQDIYtRV XKCxl7sydCNMtC6BCJXmw7pgGswnfIDNCOF/XKTNA+5xY1+VchlRI1iWb4q15YToT6EEKXJPdWdv pO+atxyMMUScQCmZM5mW1PpbMGzXRrTL3LbDhDRaLWYD15+Wt2rgNU++iiIVA363TdgCllY3ync7 GzknJGdTl+0BEen2d4juqf0GWURu/KICxyt0YOYgoDe1O3mYbJJ4RjOOFc3lTkGPgwagtJNP22yq CcJ776pzvaa6qMTMEqzAgM5X6o6Yhp8zXHOU0M0x4/pJGb8PswKhzFi7F1TWKf0zmoKlpvAUV39U P0F8oPyMYjYPDYyBsRiaZ7iRUH1u01bPQ8XXt1jmDemXxO9w4d//Kp1qark3rcUZLi6FC4QPg0Rp S9rLWAPBDHqqFKi6mAU2W8nGWj3yY6/FI2dBPSGsxY0W2KUiEbEvgN534SPgZxJd1QT2x2CEUy1x x98EBpBZCkNQN1pMo3k3CaMn14ychHd3Y544+8UD0IYWaGzbrWiEBlcHca0yg7+F0Wu3Jln4DRM+ G0MlsB9Nq5J4YvgtX3ao0V7q+nA6oEV0TX3nPl1K99b6Xou4lILRg+/siOSIwsf+xTlaiLMntO2+ evRHTSJTPwR2H1LQQIuVatkBnTx3Yh28zMP1ge+hNLU66RHEez2mE+LktzmpQdysO8UGEzCCB0Qw ggYsoAMCAQICCjvNhgsAAAAAAEwwDQYJKoZIhvcNAQEFBQAwfDETMBEGCgmSJomT8ixkARkWA2Nv bTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzARBgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJ k/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJhIFVzZXIgSXNzdWluZyBDQTEwHhcNMTAwMzMw MjI1MzEzWhcNMTEwMzMwMjI1MzEzWjASMRAwDgYDVQQDEwdjNzk5ODc4MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA177RZ1A0Y6bicGyF7owW1qoXjfivAcx6I7POmUXIto2pUR2uNYYv Q7e1W74BDD5jhR0LST7/VHage1HtfFGJsgbQC6VXTsWPbRwnsf5ifBlUleKeQXmL5C/3zHBoJJhT oCkkpLG1VMaUcbzfQuCDLjvrAhAAjDwAAyy8y46Ukkn4KSmxThu/7ovVkWfD564+APLSRu1mOu7L J7+zZniH/dAXGMuCnCJr2zqACc8vdPnmX3F5FDINe73xmqJXz3Y8v7H9dPgsuZaaa09bTLMGsOof 1BeKxJs4aCu2Dn+RLlon1Vnh10tV3j4yAH++9W6y/+i/ngv7qRNqLmoR30xHtwIDAQABo4IEMDCC BCwwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBSIvXFbqQtgAqfVgd/2LucldVpzITA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiE1I4igu3fU4X1gxiCxrxchYe7LX6HyKV0hceteQIBZAIBBDAfBgNV HSMEGDAWgBSzErFXrmmp60LIrAigOp3IfvE23DCCATwGA1UdHwSCATMwggEvMIIBK6CCASegggEj hoHWbGRhcDovLy9DTj1UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEsQ049V1NDQVMwMTAx LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBD QTEuY3JsMIIBcQYIKwYBBQUHAQEEggFjMIIBXzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPVRl bHN0cmElMjBVc2VyJTIwSXNzdWluZyUyMENBMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxz dHJhLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTBUBggrBgEFBQcwAoZIaHR0cDovL3RlbHN0cmEtcGtpLnBraS50ZWxzdHJhLmNvbS5h dS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzATBgNVHSUEDDAKBggrBgEFBQcD BDBdBgNVHSAEVjBUMFIGDCsGAQQBiEAEGwEBATBCMEAGCCsGAQUFBwIBFjRodHRwOi8vdGVsc3Ry YS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRmMBsGCSsGAQQBgjcVCgQOMAww CgYIKwYBBQUHAwQwWAYDVR0RBFEwT6AsBgorBgEEAYI3FAIDoB4MHGM3OTk4NzhAY29yZS5kaXIu dGVsc3RyYS5jb22BH0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20wDQYJKoZIhvcNAQEF BQADggEBAJdlLwFD54TirlRG+9jSLXEkMPsEG0jf6Hcgak1fGpMs20biU+i83rFkNL+scmcUf90z R7s1XFtb95rDvPbVPz7iYWoXimE3cv16Bnny2ZECh0+f7rY+ku05bXfBGLdSrCkXqOI57QEgC9ew 4yi303MOMGhxW/xGAv6CWaY4sGBRboTE71PkJCql4k635iThBP7YxJGe8/VDbiZNk8qspSBDswpv 0gQM0xDyUPkDT1Q5PEOLqugCxYXIKTKfXuGFj9nn8obzlhkyDvWxYYKH/mx8fe10ZVPGFgkSBa0o gjG0GUg5UZxnS+apqtMoZOoPHRMcZgxpKycDj01BSNdO6FAwggf5MIIG4aADAgECAgoWWLv+AAAA AAAFMA0GCSqGSIb3DQEBBQUAMEMxJDAiBgNVBAoTG1RlbHN0cmEgQ29ycG9yYXRpb24gTGltaXRl ZDEbMBkGA1UEAxMSVGVsc3RyYSBQb2xpY3kgQ0ExMB4XDTA5MTEyOTA4MzI0NVoXDTE0MTEyOTA4 NDI0NVowfDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzAR BgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJk/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJh IFVzZXIgSXNzdWluZyBDQTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCevv2YM8z1 batCiS4O8l8YKJZNgA6wCcNatQ0E3OK1ZKLijCumkWAbGkRGHvIsZGkvU9XV4SEVzaVmdC+w83S+ wDNwj+8RtR3yjTOZ/ttiXO1/zWbXq8pS+RYalOp2NS6bIs7J6bvN5nSzYJESNEkSwv57ZxDutL12 gw2tC411FYTWqaL10rAOA3Hn5wSyr51WdrkjxNZqmmhSGvOITi+8UAeIe6rzarh/YemYJp1sA2p0 ZIg1VhBg8vvY6dONG1h/atFDjECJtroqYbvtJpQWeXQK8hSR/JlLeAYqt/J8GKQv+8mkycQUn0Xt D5gbjF60i81culOIsXttS4xIe1tzAgMBAAGjggS0MIIEsDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBSzErFXrmmp60LIrAigOp3IfvE23DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMC AQAwggGJBgNVHSAEggGAMIIBfDCCAXgGDCsGAQQBiEAEGwEBATCCAWYwggEgBggrBgEFBQcCAjCC ARIeggEOAEYAbwByACAAYQAgAGMAbwBwAHkAIABvAGYAIAB0AGgAZQAgAFQAZQBsAHMAdAByAGEA IABQAEsASQAgAEMAUABTACwAIABjAGwAaQBjAGsAIABNAG8AcgBlACAASQBuAGYAbwAuACAARgBv AHIAIABDAFAAUwAgAHEAdQBlAHIAaQBlAHMAIABjAG8AbgB0AGEAYwB0ACAAdABoAGUAIABHAG8A dgBlAHIAbgBhAG4AYwBlACAAQwBvAHUAbgBjAGkAbAAsACAARQBtAGEAaQBsADoAIABUAGUAbABz AHQAcgBhAC4AUABHAEMAQAB0AGUAYQBtAC4AdABlAGwAcwB0AHIAYQAuAGMAbwBtMEAGCCsGAQUF BwIBFjRodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRm MBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFJT5/udCeR3rxZ9HUpfHV7X4 nD4oMIIBLAYDVR0fBIIBIzCCAR8wggEboIIBF6CCAROGgc5sZGFwOi8vL0NOPVRlbHN0cmElMjBQ b2xpY3klMjBDQTEsQ049d3NjYXAwMTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEs REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0 cmlidXRpb25Qb2ludIZAaHR0cDovL3RlbHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxz dHJhJTIwUG9saWN5JTIwQ0ExLmNybDCCAWEGCCsGAQUFBwEBBIIBUzCCAU8wgcQGCCsGAQUFBzAC hoG3bGRhcDovLy9DTj1UZWxzdHJhJTIwUG9saWN5JTIwQ0ExLENOPUFJQSxDTj1QdWJsaWMlMjBL ZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGly LERDPXRlbHN0cmEsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MEwGCCsGAQUFBzAChkBodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0 cmEuY29tLmF1L1RlbHN0cmElMjBQb2xpY3klMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzANBgkqhkiG9w0BAQUFAAOCAQEA KLKdzu8ZWRTUOdOZJ02fEONNrwAHAUMMwFh5pD/2CPhY6e29qU+4zih5R30GUcj+2LVohlOHyWVq vvQJyJTxH+YTf3xrldjV69lL3lLCMfsuGX2LteGfwLsN45hUOnm1RWlvf0Gaug4GdLZeXjVLyfgU MF/BhesXEUGWB68Q5N8FxUVVgrmXRYYWyGQHGGHXWn/UCOreGjawPr7GC0HgndgkwHxjhTqgCmzo Sl0TIwWxFu6gO0eleF+3S85IFb3dwmctj+ZZm0tm3i5+59RVytuycvvAArwZT4Dc3nLD78fnjpXs c9oXwjRWF3x98fn2ycF56Ys+d3592133GLCMljGCAjgwggI0AgEBMIGKMHwxEzARBgoJkiaJk/Is ZAEZFgNjb20xFzAVBgoJkiaJk/IsZAEZFgd0ZWxzdHJhMRMwEQYKCZImiZPyLGQBGRYDZGlyMRQw EgYKCZImiZPyLGQBGRYEY29yZTEhMB8GA1UEAxMYVGVsc3RyYSBVc2VyIElzc3VpbmcgQ0ExAgo7 zYYLAAAAAABMMAkGBSsOAwIaBQCggYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTAwNTA3MDYwODA5WjAjBgkqhkiG9w0BCQQxFgQUkaOS91EdfHyzAROrIpEb+U7A o0QwJAYJKoZIhvcNAQkPMRcwFTAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASC AQAJsmzNmJc0ohXyk0t+wvXu/n4jAfAKll4ZX3lSrY4gJus8SAs8gX8OeF+5Pr4smMCMI9wGyYLQ JLJDV+mHotFLwMAo8DHuGkVJ72Sno+B2hmJzNL19Ewm0c+tXY7efrscVFS8nEgpr+RCA71TAl8Ro ss5U2bMeYBQt1xb+t7btJ/tHfhwN9+BIH/Kt/qnfxEljj+8FMLGcMYUKsbcM0NtrccLcy0mqzeaq i+QkGDpCVgYMvpIAcmKjM/feuUOfsq3o1jWg8CMRgbu7UBzL7cSyO74KPTEMhHSNX8b4VnUVWRuc S0Q774qlJQq8XCnsXnAw6A5ZL1ISEwFuluL1kcYvAAAAAAAA ------=_NextPart_000_0061_01CAEDFF.7CCFD880-- From James.H.Manger@team.telstra.com Thu May 6 23:11:10 2010 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 13F3B3A6A99 for ; Thu, 6 May 2010 23:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoGjYkgzgkDN for ; Thu, 6 May 2010 23:11:08 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 9AD7B3A6819 for ; Thu, 6 May 2010 23:09:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,346,1270389600"; d="p7s'?scan'208,217";a="2836063" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 07 May 2010 16:09:41 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1690423" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccni.tcif.telstra.com.au with ESMTP; 07 May 2010 16:09:41 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 7 May 2010 16:09:41 +1000 From: "Manger, James H" To: David Recordon Date: Fri, 7 May 2010 16:09:40 +1000 Thread-Topic: [OAUTH-WG] Redirects Thread-Index: AcrtpyvQjD80fZDqQWGuGphhPdGG+QABI7EQ Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B26C0@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0068_01CAEDFF.B28E8B10" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 06:11:10 -0000 ------=_NextPart_000_0068_01CAEDFF.B28E8B10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0069_01CAEDFF.B28E8B10" ------=_NextPart_001_0069_01CAEDFF.B28E8B10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable David said: > Why wouldn't the client send the token with the new request? If I'm = trying to access https://api.example.com/pr?access_token=3Dloin21op and = I get a 301 response, I'll need to follow that if I want any chance of = accessing the protected resource. =20 =20 If https://api.example.com/pr?access_token=3Dloin21op responses with = =E2=80=9CLocation: http://evil.com/log=E2=80=9D should the client get = http://evil.com/log or http://evil.com/log?access_token=3Dloin21op? = Surely the later is potentially insecure. I don=E2=80=99t think we can = assume (mandate) that services only redirect to =E2=80=9Cgood=E2=80=9D = sites. We certainly can=E2=80=99t assume (mandate) that links in the = content on the response are to =E2=80=9Cgood=E2=80=9D sites. =20 The answer is a bit easier if the token is passed as a query param (like = with Facebook) -- as the client could rely on the service to include or = omit the token param in the redirect/link URI as appropriate. It is less = obvious with an Authorization header, or POST is used. =20 -- James Manger ------=_NextPart_001_0069_01CAEDFF.B28E8B10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

David said:

> Why wouldn't the client send the token with = the new request? If I'm trying to access https://api.e= xample.com/pr?access_token=3Dloin21op and I get a 301 response, I'll need to follow that if I want any chance = of accessing the protected resource.

 

 

If https://api.e= xample.com/pr?access_token=3Dloin21op responses with =E2=80=9CLocation: http://evil.com/log=E2=80=9D should the client get http://evil.com/log or http://evil.com/log?= access_token=3Dloin21op? Surely the later is potentially insecure. I don=E2=80=99t think we can = assume (mandate) that services only redirect to =E2=80=9Cgood=E2=80=9D sites. We = certainly can=E2=80=99t assume (mandate) that links in the content on the response are to = =E2=80=9Cgood=E2=80=9D sites.

 

The answer is a bit easier if the token is passed as a = query param (like with Facebook) -- as the client could rely on the service to include or omit the token param in the redirect/link URI as appropriate. = It is less obvious with an Authorization header, or POST is = used.

 

--

James Manger

------=_NextPart_001_0069_01CAEDFF.B28E8B10-- ------=_NextPart_000_0068_01CAEDFF.B28E8B10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIc2jCCBqMw ggSLoAMCAQICEClsBJZEfCC2SncEyz0UzYEwDQYJKoZIhvcNAQEFBQAwGjEYMBYGA1UEAxMPVGVs c3RyYSBSb290IENBMB4XDTA5MTExNjA0NTkxM1oXDTM0MTExNjA1MDYxMVowGjEYMBYGA1UEAxMP VGVsc3RyYSBSb290IENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA3r3Fb5E/8GUk cHwd9/kRB14EH1trG6C7NrwmF7isLj3j8fbELwkg0Lm0qzVuYziwqC3sbB4BcpY1YU9UZfB8J7cO Efbk1GkVkSwNnpKyUHsxAWAelb0eOord3bB21M2UeUyWkGQhoU3+ZxyaAALKDm1QZQx7Tw8wdkIQ mc1mJ4cJg/I9dTk1J5ybG4ZWs4/87PnLe0A5KRD841YWeKO1oLrV6Zvj65Aa6gpme0AdLVEDStM/ 4jNtso6jf63ixizKzazfbt5lJJZizGHelymCF2BGjps0+6eMsteMmfQ84OXG82V00pFy6kwGjH6+ Y081OXTo6Gq/sR+6d4RDFIltIYGyYKKBzsEGw2MJqxqyXat9UV/50xspN26BZlB5zHFNdKI9eBKC sv6EpgklYSfv9vgNBBnwavHmGvmw12i0NUd9WlS3YybQzxnWE49Q05jIxt+ZgV4Rg6oiCRb7rktN d8qwRUb0LcSfcYOqGGffuckNQzKGNGySrkznOrC33BsVEmGMgXGqtZk4L7Sfq5NL1y7wCJUKw8qI Ox/ijs0SSfc9VDwqZmhEM9NV8sGUsvmTeH1D8G06zjmE6loXUyIQXZLohQQ96TQyjKuA3lvtCbJt yHFbgyi8wVJG+Ze3+Ywo+JB10rlR7FF6XEniihJEIYAHkSsGRqOASUzBA7p2Ip8CAwEAAaOCAeMw ggHfMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1UdDgQWBBSXNqRMMI9eSlUu k+RwLu+s1mV3iDAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwDQYJKoZIhvcNAQEFBQADggIBAHZuKnwg4R4Fk32A fxTzTHtDboZI1ZW3Yv7nSdqfZlnfF8bEAD6FSEoMJ0w6jProxVXSZwia5Fkhf4jt6M949PP+G5Cl V89x3z8pECqJhbVcZbE9p1hJXPy72IwILRblSnTnPh9CTLV0gTOkmX6SmrDMG3GSV3djTt8cf88o JTcbRe0vJgFwf5sPlMEplrK3tK0pIjomzcoGLfP9Zv+wvVLvGvu5TVxWiFIQrdtuUjzL3/2VxFb4 M5kLQaQCaxTOxcB/8epSyaInbLI1YsyhRtPyzCAT0pbTTPKR3eNgMF7YlzakASa5LbiTkWIayS8h s+MjkqIF9CX1PwOBphQgJa3yPm4bIfNBGH4520knrb5r/D/cTDtjarXh4v/ExJphEqbU6m44C4Wq Cp7jV3v6Xm91QaQbCF/e4H4RD9PTr/c+MILhmhEq879n6iF6276oe2kWZE0yXy8eiK5Ung0F2tJX PfQidNaI9NTMHViQoacVY9ah/juHnEIrnEozrYuMLqC+39i9BXAIQ4Qq7GJ132xr5o8/xb2iQ1IZ wD27yb7Or1gzcKjKvJj/pkCeDgC7fQVlxtvfDBjiKuAoWs7PXGTtGzfiObrnEmhmR0DnWSehA5ld o3/fyiGuyN53nU+ewQY4AyE8jBzPxq6YmVjWM0FAdyJLHyX+YBvYjs2VAX2cMIIG6jCCBNKgAwIB AgIKYQWDvgAAAAAABTANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9UZWxzdHJhIFJvb3QgQ0Ew HhcNMDkxMTI1MDEyNDI3WhcNMTkxMTI1MDEzNDI3WjBDMSQwIgYDVQQKExtUZWxzdHJhIENvcnBv cmF0aW9uIExpbWl0ZWQxGzAZBgNVBAMTElRlbHN0cmEgUG9saWN5IENBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAK3IBZQGtMLEw5e8k3SJcSRf/BnMWwguu1Ltka6XK/nmcmjTOPl/ qqpkC2uBZUFZAflrWJdmh5MTamCWNMsRSmtiWwSJQsFTPWstSRELqkuM0+lXIlTTU4dTFM3cp/pE l4ly+xBUd6ndQQeB/MOsTsbdkhALj/oMZzSSVLJw3cngrS4pG9TjV8zKMIkZQBeIURBgqh1yd6nX n1FNctjyDH1ybxftcuhK3hEEbPrAHJQB9YN317l7ISYqg99jec/3mVf0C1fOuzefKHGINXo8M2lL H3P4O28fSmaLyJK3p6IStoRmtrHwIkc9WHnDe0e9aieQx+PPosll61EtyJiaRX0CAwEAAaOCAwcw ggMDMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFJT5/udCeR3rxZ9HUpfHV7X4nD4oMAsG A1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYD VR0jBBgwFoAUlzakTDCPXkpVLpPkcC7vrNZld4gwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwUm9vdCUyMENBLmNybDCBlQYI KwYBBQUHAQEEgYgwgYUwSQYIKwYBBQUHMAKGPWh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVsc3Ry YS5jb20uYXUvVGVsc3RyYSUyMFJvb3QlMjBDQS5jcnQwOAYIKwYBBQUHMAGGLGh0dHA6Ly90ZWxz dHJhLW9jc3AucGtpLnRlbHN0cmEuY29tLmF1L29jc3AvMA0GCSqGSIb3DQEBBQUAA4ICAQDIYtRV XKCxl7sydCNMtC6BCJXmw7pgGswnfIDNCOF/XKTNA+5xY1+VchlRI1iWb4q15YToT6EEKXJPdWdv pO+atxyMMUScQCmZM5mW1PpbMGzXRrTL3LbDhDRaLWYD15+Wt2rgNU++iiIVA363TdgCllY3ync7 GzknJGdTl+0BEen2d4juqf0GWURu/KICxyt0YOYgoDe1O3mYbJJ4RjOOFc3lTkGPgwagtJNP22yq CcJ776pzvaa6qMTMEqzAgM5X6o6Yhp8zXHOU0M0x4/pJGb8PswKhzFi7F1TWKf0zmoKlpvAUV39U P0F8oPyMYjYPDYyBsRiaZ7iRUH1u01bPQ8XXt1jmDemXxO9w4d//Kp1qark3rcUZLi6FC4QPg0Rp S9rLWAPBDHqqFKi6mAU2W8nGWj3yY6/FI2dBPSGsxY0W2KUiEbEvgN534SPgZxJd1QT2x2CEUy1x x98EBpBZCkNQN1pMo3k3CaMn14ychHd3Y544+8UD0IYWaGzbrWiEBlcHca0yg7+F0Wu3Jln4DRM+ G0MlsB9Nq5J4YvgtX3ao0V7q+nA6oEV0TX3nPl1K99b6Xou4lILRg+/siOSIwsf+xTlaiLMntO2+ evRHTSJTPwR2H1LQQIuVatkBnTx3Yh28zMP1ge+hNLU66RHEez2mE+LktzmpQdysO8UGEzCCB0Qw ggYsoAMCAQICCjvNhgsAAAAAAEwwDQYJKoZIhvcNAQEFBQAwfDETMBEGCgmSJomT8ixkARkWA2Nv bTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzARBgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJ k/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJhIFVzZXIgSXNzdWluZyBDQTEwHhcNMTAwMzMw MjI1MzEzWhcNMTEwMzMwMjI1MzEzWjASMRAwDgYDVQQDEwdjNzk5ODc4MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA177RZ1A0Y6bicGyF7owW1qoXjfivAcx6I7POmUXIto2pUR2uNYYv Q7e1W74BDD5jhR0LST7/VHage1HtfFGJsgbQC6VXTsWPbRwnsf5ifBlUleKeQXmL5C/3zHBoJJhT oCkkpLG1VMaUcbzfQuCDLjvrAhAAjDwAAyy8y46Ukkn4KSmxThu/7ovVkWfD564+APLSRu1mOu7L J7+zZniH/dAXGMuCnCJr2zqACc8vdPnmX3F5FDINe73xmqJXz3Y8v7H9dPgsuZaaa09bTLMGsOof 1BeKxJs4aCu2Dn+RLlon1Vnh10tV3j4yAH++9W6y/+i/ngv7qRNqLmoR30xHtwIDAQABo4IEMDCC BCwwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBSIvXFbqQtgAqfVgd/2LucldVpzITA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiE1I4igu3fU4X1gxiCxrxchYe7LX6HyKV0hceteQIBZAIBBDAfBgNV HSMEGDAWgBSzErFXrmmp60LIrAigOp3IfvE23DCCATwGA1UdHwSCATMwggEvMIIBK6CCASegggEj hoHWbGRhcDovLy9DTj1UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEsQ049V1NDQVMwMTAx LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBD QTEuY3JsMIIBcQYIKwYBBQUHAQEEggFjMIIBXzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPVRl bHN0cmElMjBVc2VyJTIwSXNzdWluZyUyMENBMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxz dHJhLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTBUBggrBgEFBQcwAoZIaHR0cDovL3RlbHN0cmEtcGtpLnBraS50ZWxzdHJhLmNvbS5h dS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzATBgNVHSUEDDAKBggrBgEFBQcD BDBdBgNVHSAEVjBUMFIGDCsGAQQBiEAEGwEBATBCMEAGCCsGAQUFBwIBFjRodHRwOi8vdGVsc3Ry YS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRmMBsGCSsGAQQBgjcVCgQOMAww CgYIKwYBBQUHAwQwWAYDVR0RBFEwT6AsBgorBgEEAYI3FAIDoB4MHGM3OTk4NzhAY29yZS5kaXIu dGVsc3RyYS5jb22BH0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20wDQYJKoZIhvcNAQEF BQADggEBAJdlLwFD54TirlRG+9jSLXEkMPsEG0jf6Hcgak1fGpMs20biU+i83rFkNL+scmcUf90z R7s1XFtb95rDvPbVPz7iYWoXimE3cv16Bnny2ZECh0+f7rY+ku05bXfBGLdSrCkXqOI57QEgC9ew 4yi303MOMGhxW/xGAv6CWaY4sGBRboTE71PkJCql4k635iThBP7YxJGe8/VDbiZNk8qspSBDswpv 0gQM0xDyUPkDT1Q5PEOLqugCxYXIKTKfXuGFj9nn8obzlhkyDvWxYYKH/mx8fe10ZVPGFgkSBa0o gjG0GUg5UZxnS+apqtMoZOoPHRMcZgxpKycDj01BSNdO6FAwggf5MIIG4aADAgECAgoWWLv+AAAA AAAFMA0GCSqGSIb3DQEBBQUAMEMxJDAiBgNVBAoTG1RlbHN0cmEgQ29ycG9yYXRpb24gTGltaXRl ZDEbMBkGA1UEAxMSVGVsc3RyYSBQb2xpY3kgQ0ExMB4XDTA5MTEyOTA4MzI0NVoXDTE0MTEyOTA4 NDI0NVowfDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzAR BgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJk/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJh IFVzZXIgSXNzdWluZyBDQTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCevv2YM8z1 batCiS4O8l8YKJZNgA6wCcNatQ0E3OK1ZKLijCumkWAbGkRGHvIsZGkvU9XV4SEVzaVmdC+w83S+ wDNwj+8RtR3yjTOZ/ttiXO1/zWbXq8pS+RYalOp2NS6bIs7J6bvN5nSzYJESNEkSwv57ZxDutL12 gw2tC411FYTWqaL10rAOA3Hn5wSyr51WdrkjxNZqmmhSGvOITi+8UAeIe6rzarh/YemYJp1sA2p0 ZIg1VhBg8vvY6dONG1h/atFDjECJtroqYbvtJpQWeXQK8hSR/JlLeAYqt/J8GKQv+8mkycQUn0Xt D5gbjF60i81culOIsXttS4xIe1tzAgMBAAGjggS0MIIEsDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBSzErFXrmmp60LIrAigOp3IfvE23DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMC AQAwggGJBgNVHSAEggGAMIIBfDCCAXgGDCsGAQQBiEAEGwEBATCCAWYwggEgBggrBgEFBQcCAjCC ARIeggEOAEYAbwByACAAYQAgAGMAbwBwAHkAIABvAGYAIAB0AGgAZQAgAFQAZQBsAHMAdAByAGEA IABQAEsASQAgAEMAUABTACwAIABjAGwAaQBjAGsAIABNAG8AcgBlACAASQBuAGYAbwAuACAARgBv AHIAIABDAFAAUwAgAHEAdQBlAHIAaQBlAHMAIABjAG8AbgB0AGEAYwB0ACAAdABoAGUAIABHAG8A dgBlAHIAbgBhAG4AYwBlACAAQwBvAHUAbgBjAGkAbAAsACAARQBtAGEAaQBsADoAIABUAGUAbABz AHQAcgBhAC4AUABHAEMAQAB0AGUAYQBtAC4AdABlAGwAcwB0AHIAYQAuAGMAbwBtMEAGCCsGAQUF BwIBFjRodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRm MBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFJT5/udCeR3rxZ9HUpfHV7X4 nD4oMIIBLAYDVR0fBIIBIzCCAR8wggEboIIBF6CCAROGgc5sZGFwOi8vL0NOPVRlbHN0cmElMjBQ b2xpY3klMjBDQTEsQ049d3NjYXAwMTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEs REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0 cmlidXRpb25Qb2ludIZAaHR0cDovL3RlbHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxz dHJhJTIwUG9saWN5JTIwQ0ExLmNybDCCAWEGCCsGAQUFBwEBBIIBUzCCAU8wgcQGCCsGAQUFBzAC hoG3bGRhcDovLy9DTj1UZWxzdHJhJTIwUG9saWN5JTIwQ0ExLENOPUFJQSxDTj1QdWJsaWMlMjBL ZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGly LERDPXRlbHN0cmEsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MEwGCCsGAQUFBzAChkBodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0 cmEuY29tLmF1L1RlbHN0cmElMjBQb2xpY3klMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzANBgkqhkiG9w0BAQUFAAOCAQEA KLKdzu8ZWRTUOdOZJ02fEONNrwAHAUMMwFh5pD/2CPhY6e29qU+4zih5R30GUcj+2LVohlOHyWVq vvQJyJTxH+YTf3xrldjV69lL3lLCMfsuGX2LteGfwLsN45hUOnm1RWlvf0Gaug4GdLZeXjVLyfgU MF/BhesXEUGWB68Q5N8FxUVVgrmXRYYWyGQHGGHXWn/UCOreGjawPr7GC0HgndgkwHxjhTqgCmzo Sl0TIwWxFu6gO0eleF+3S85IFb3dwmctj+ZZm0tm3i5+59RVytuycvvAArwZT4Dc3nLD78fnjpXs c9oXwjRWF3x98fn2ycF56Ys+d3592133GLCMljGCAjgwggI0AgEBMIGKMHwxEzARBgoJkiaJk/Is ZAEZFgNjb20xFzAVBgoJkiaJk/IsZAEZFgd0ZWxzdHJhMRMwEQYKCZImiZPyLGQBGRYDZGlyMRQw EgYKCZImiZPyLGQBGRYEY29yZTEhMB8GA1UEAxMYVGVsc3RyYSBVc2VyIElzc3VpbmcgQ0ExAgo7 zYYLAAAAAABMMAkGBSsOAwIaBQCggYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTAwNTA3MDYwOTQwWjAjBgkqhkiG9w0BCQQxFgQUUMT6TSYTmjS9Hz4UMbyOtID/ fR0wJAYJKoZIhvcNAQkPMRcwFTAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASC AQBb8ExXUc/KnQ4h0c77GNi/08eDMaptULb1u4lOAg/gm8K+CjJnK9lppZaPDUktWMK4fx+Q0n8z UtrtuI016jr3RMJVrc+OgyfEockPNShainVRqrII43+O2+Q0ccKh/NASyZMEgkaxM0Ul31D7eWKq H+iubbaB/K9u7Dbk2Ny6XwPxlBQIa+bDM23rw/Aqh716sHpYQbayd7ymeQM91FHL8Od/y5hYDHui CDuxP2zcBJteCS0HBS/89pRJhKqb5W4MrGhitphnv92zoag6DQXUtjPIYZAolKPowsjMwaUGGObN yYEhMN6ThV/am8rg+vTyIBmWV8l1e2yu1buz38CYAAAAAAAA ------=_NextPart_000_0068_01CAEDFF.B28E8B10-- From James.H.Manger@team.telstra.com Thu May 6 23:14:23 2010 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 765C93A6819 for ; Thu, 6 May 2010 23:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.219 X-Spam-Level: * X-Spam-Status: No, score=1.219 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvUOjAjtRzVt for ; Thu, 6 May 2010 23:14:22 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id B2BDD3A68C3 for ; Thu, 6 May 2010 23:14:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,346,1270389600"; d="scan'208,217";a="2836627" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 07 May 2010 16:14:08 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1690864" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccni.tcif.telstra.com.au with ESMTP; 07 May 2010 16:14:08 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 7 May 2010 16:14:08 +1000 From: "Manger, James H" To: Torsten Lodderstedt Date: Fri, 7 May 2010 16:14:06 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcrtprTngX8DR1/1STiGzpECvcjUiAAAB3Vw Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B26DE@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> In-Reply-To: <4BE3A5DC.5030601@lodderstedt.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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112631B26DEWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 06:14:23 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112631B26DEWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiB3aGF0IGFib3V0IGFuIGFkZGl0aW9uYWwgcmVhbG0gcmVzcG9uc2UgdmFsdWU/DQoNCg0KDQpN eSBvcmlnaW5hbCBzdWdnZXN0aW9uKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9vYXV0aC9jdXJyZW50L21zZzAxOTIwLmh0bWwpIGhhZCBhIOKAnHJlYWxt4oCdIGluIGFkZGl0 aW9uIHRvIOKAnHNpdGVz4oCdLiBJIHN0aWxsIHRoaW5rIHRoYXQgc2hvdWxkIGJlIHByZXNlbnQg KHRob3VnaCBtb3JlIHRvIG1hdGNoIHRoZSBIVFRQIGF1dGggbW9kZWwgKFJGQzI2MTcpIHRoYW4g YW4gZXhwZWN0YXRpb24gdGhhdCBpdCB3aWxsIGJlIHVzZWQgYnkgbW9zdCBzZXJ2aWNlcykuDQoN Cg0KDQoNCg0KPiBJZiB0aGVyZSBpcyBhIGJpbmRpbmcgYmV0d2VlbiByZWFsbSBhbmQgdG9rZW4s IHRoZSBjbGllbnQgY2FuIGRlY2lkZSBiYXNlZCBvbiB0aGUgcmVhbG0gYXR0cmlidXRlIGRpc2Nv dmVyZWQgdXNpbmcgYSBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIHdoaWNoIHRva2VuIHRvIHVz ZS4NCg0KDQoNCuKAnHJlYWxt4oCdIGlzIG5vdCBzdWZmaWNpZW50LCBob3dldmVyLiBBIOKAnHJl YWxt4oCdIGRvZXNu4oCZdCBzdG9wIHlvdSBzZW5kaW5nIGEgdG9rZW4gdG8gYSBiYWQgc2l0ZS4g RXZlbiBpZiBhbiBhcHAgbWFrZXMgYW5kIHVuYXV0aGVudGljYXRlZCBjYWxsIGZpcnN0LCB0aGVy ZSBpcyBub3RoaW5nIHRvIHN0b3AgdGhlIGJhZCBzaXRlIHJlc3BvbmRpbmcgd2l0aCBhIFdXVy1B dXRoIGhlYWRlciB3aXRoIHRoZSByaWdodCDigJxyZWFsbeKAnSB2YWx1ZSBzbyB0aGUgY2xpZW50 IGFwcCB3aWxsIHJldmVhbCB0aGUgdG9rZW4uDQoNCg0KDQoNCg0KLS0NCg0KSmFtZXMgTWFuZ2Vy DQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E112631B26DEWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IHdoYXQgYWJv dXQgYW4gYWRkaXRpb25hbCByZWFsbSByZXNwb25zZSB2YWx1ZT88YnI+DQo8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29s b3I6IzFGNDk3RCI+TXkgb3JpZ2luYWwgc3VnZ2VzdGlvbig8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwMTkyMC5odG1sIj5odHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cwMTkyMC5o dG1sPC9hPikNCiBoYWQgYSDigJxyZWFsbeKAnSBpbiBhZGRpdGlvbiB0byDigJxzaXRlc+KAnS4g SSBzdGlsbCB0aGluayB0aGF0IHNob3VsZCBiZSBwcmVzZW50ICh0aG91Z2ggbW9yZSB0byBtYXRj aCB0aGUgSFRUUCBhdXRoIG1vZGVsIChSRkMyNjE3KSB0aGFuIGFuIGV4cGVjdGF0aW9uIHRoYXQg aXQgd2lsbCBiZSB1c2VkIGJ5IG1vc3Qgc2VydmljZXMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJZiB0 aGVyZSBpcyBhIGJpbmRpbmcgYmV0d2VlbiByZWFsbSBhbmQgdG9rZW4sIHRoZSBjbGllbnQgY2Fu IGRlY2lkZSBiYXNlZCBvbiB0aGUgcmVhbG0gYXR0cmlidXRlIGRpc2NvdmVyZWQgdXNpbmcgYSBX V1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIHdoaWNoIHRva2VuIHRvIHVzZS48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj7igJxyZWFsbeKA nSBpcyBub3Qgc3VmZmljaWVudCwgaG93ZXZlci4gQSDigJxyZWFsbeKAnSBkb2VzbuKAmXQgc3Rv cCB5b3Ugc2VuZGluZyBhIHRva2VuIHRvIGEgYmFkIHNpdGUuIEV2ZW4gaWYgYW4gYXBwIG1ha2Vz IGFuZCB1bmF1dGhlbnRpY2F0ZWQgY2FsbCBmaXJzdCwgdGhlcmUgaXMNCiBub3RoaW5nIHRvIHN0 b3AgdGhlIGJhZCBzaXRlIHJlc3BvbmRpbmcgd2l0aCBhIFdXVy1BdXRoIGhlYWRlciB3aXRoIHRo ZSByaWdodCDigJxyZWFsbeKAnSB2YWx1ZSBzbyB0aGUgY2xpZW50IGFwcCB3aWxsIHJldmVhbCB0 aGUgdG9rZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5KYW1lcyBN YW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E112631B26DEWSMSG3153Vsrv_-- From recordond@gmail.com Thu May 6 23:16:03 2010 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 606203A6998 for ; Thu, 6 May 2010 23:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsn3fV8A0qQp for ; Thu, 6 May 2010 23:16:02 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 571E43A68C3 for ; Thu, 6 May 2010 23:15:37 -0700 (PDT) Received: by iwn27 with SMTP id 27so1037746iwn.5 for ; Thu, 06 May 2010 23:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=p+delsrRER29iByD2EkWOaA4dek9EJMoio8U0RgprCY=; b=KmjvIpE8dFWkeC3IR0dm7MW3ZSzwFvSJ6FBwGUUFSe3vGSHV6wSmmelGrGCgwDioTu DQCozjWGVn8Fjw1q7f3Y6qPfxJnUtJbyfBaHhV6i8oSZ9onLHyq7tDbHS7LoFAUJFC+I T6ZIN9eetXvGzs4oZVS+m9NC4FGN12DrDqCSg= 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=SdJ8bc++zCsmVIwH+GhUD+afgpRVOgs2kOGJ7B9mnbLVCRNGK1N015z5yfXWp6+vfp AwNB9ya49u33ZdGdLWVt2H2LHcwaHPBy0MIgpXBlpAoHus1pRkMxGcti5lmcohbp2cde GkJYETKboV5xR3ANNEJVt4RUc5eSJ0pTVjiHw= MIME-Version: 1.0 Received: by 10.231.147.21 with SMTP id j21mr4302010ibv.65.1273212914083; Thu, 06 May 2010 23:15:14 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Thu, 6 May 2010 23:15:14 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112631B26C0@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B26C0@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 6 May 2010 23:15:14 -0700 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016e64758ae77a9b80485fafb82 Cc: OAuth WG Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 06:16:03 -0000 --0016e64758ae77a9b80485fafb82 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Don't you have larger problems if your protected resources are compromised? You might want to revoke access tokens or take the Google/Yahoo! model of them expiring frequently with refresh tokens. On Thu, May 6, 2010 at 11:09 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > David said: > > > Why wouldn't the client send the token with the new request? If I'm > trying to access https://api.example.com/pr?access_token=3Dloin21op and I > get a 301 response, I'll need to follow that if I want any chance of > accessing the protected resource. > > > > > > If https://api.example.com/pr?access_token=3Dloin21op responses with > =93Location: http://evil.com/log=94 should the client get http://evil.com= /logor > http://evil.com/log?access_token=3Dloin21op? Surely the later is potentia= lly > insecure. I don=92t think we can assume (mandate) that services only redi= rect > to =93good=94 sites. We certainly can=92t assume (mandate) that links in = the > content on the response are to =93good=94 sites. > > > > The answer is a bit easier if the token is passed as a query param (like > with Facebook) -- as the client could rely on the service to include or o= mit > the token param in the redirect/link URI as appropriate. It is less obvio= us > with an Authorization header, or POST is used. > > > > -- > > James Manger > --0016e64758ae77a9b80485fafb82 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Don't you have larger problems if your protected resources are compromi= sed? You might want to revoke access tokens or take the Google/Yahoo! model= of them expiring frequently with refresh tokens.


On Thu, May 6, 2010 at 11:09 PM, Manger, James H <James.H.Manger@team.telstra.= com> wrote:

David= said:

> = Why wouldn't the client send the token with the new request? If I'm trying to access https://api.example.com/pr?acces= s_token=3Dloin21op and I get a 301 response, I'll need to follow that if I want any chance= of accessing the protected resource.

=A0

=A0

If https://api.example.com/pr?access_token=3Dloin21op responses with =93Location: http://evil.com/log=94 should the client get htt= p://evil.com/log or http://evil.com/log?access_token=3Dloin21op? Surely the later is potentially insecure. I don=92t think we can assume (ma= ndate) that services only redirect to =93good=94 sites. We certainly can=92t assum= e (mandate) that links in the content on the response are to =93good=94 sites= .

=A0

The a= nswer is a bit easier if the token is passed as a query param (like with Facebook) -- as the client could rely on the service to include or omit the token param in the redirect/link URI as appropriate. It= is less obvious with an Authorization header, or POST is used.

=A0

--

James= Manger


--0016e64758ae77a9b80485fafb82-- From James.H.Manger@team.telstra.com Thu May 6 23:28:26 2010 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 E09DC3A6A89 for ; Thu, 6 May 2010 23:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNRg5vE4U5Mf for ; Thu, 6 May 2010 23:28:25 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 0A71B3A6883 for ; Thu, 6 May 2010 23:28:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,346,1270389600"; d="scan'208,217";a="2528110" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 May 2010 16:28:10 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1634467" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbvi.tcif.telstra.com.au with ESMTP; 07 May 2010 16:28:11 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Fri, 7 May 2010 16:28:10 +1000 From: "Manger, James H" To: David Recordon Date: Fri, 7 May 2010 16:28:08 +1000 Thread-Topic: [OAUTH-WG] Redirects Thread-Index: AcrtrKmE5Sbt98WxT7+eYBf4kRokkAAABn6A Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B273F@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B26C0@WSMSG3153V.srv.dir.telstra.com> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112631B273FWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 06:28:27 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112631B273FWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBEb24ndCB5b3UgaGF2ZSBsYXJnZXIgcHJvYmxlbXMgaWYgeW91ciBwcm90ZWN0ZWQgcmVzb3Vy Y2VzIGFyZSBjb21wcm9taXNlZD8NCg0KDQoNCg0KDQpUaGVyZSBpcyBubyBjb21wcm9taXNlLg0K DQpJdCBpcyBwZXJmZWN0bHkgbm9ybWFsIGZvciBhIHNlcnZpY2UgdG8gcmV0dXJuIGNvbnRlbnQg d2l0aCBsaW5rcyB0byBhcmJpdHJhcnkgb3RoZXIgc2l0ZXMuDQoNCkV2ZW4gcmVkaXJlY3RzIHRv IGFyYml0cmFyeSBvdGhlciBzaXRlcyAob3BlbiByZWRpcmVjdG9ycykg4oCUIHRob3VnaHQgdGhl eSBjYXVzZSBzb21lIGlzc3VlcyDigJQgZG9u4oCZdCBtZWFuIHRoZSBwcm90ZWN0ZWQgcmVzb3Vy Y2VzIGFyZSBjb21wcm9taXNlZC4NCg0KSXQganVzdCBtZWFucyBjbGllbnRzIG5lZWQgdG8gYmUg Y2FyZWZ1bCB3aGVuIGZvbGxvd2luZyBsaW5rcyBhbmQgcmVkaXJlY3RzIG9uIHRoZSB3ZWIsIGFu ZCB0aGV5IG5lZWQgdGhlIHJpZ2h0IGluZm8gdG8gYmUgYWJsZSB0byBiZSBjYXJlZnVsIChzdWNo IGFzIHdoZW4gdG8gaW5jbHVkZSBhIHRva2VuKS4NCg0KDQoNCg0KDQpBbGwgdGhlIOKAnGNvbm5l Y3Rpb25z4oCdIGluIHRoZSBGYWNlYm9vayBBUEkgZXhhbXBsZSBzaG93biBiZWxvdyBhcmUgdG8g RmFjZWJvb2suIElmIEZhY2Vib29rIGFsbG93ZWQgdXNlci1nZW5lcmF0ZWQgdmFsdWVzIGZvciBz b21lIG9mIHRoZXNlIHRoYXQgY291bGQgcG9pbnQgdG8gb3RoZXIgc2l0ZXMsIGl0IHdvdWxkbuKA mXQgbWVhbiBGYWNlYm9vayB3YXMgY29tcHJvbWlzZWQgdGVjaG5pY2FsbHksIGJ1dCBpdCB3b3Vs ZCBtZWFuIGEgdG9rZW4gc2hvdWxkIGJlIGluY2x1ZGUgd2hlbiBnZXR0aW5nIHNvbWUgYnV0IG5v dCBvdGhlcnMuDQoNCg0KDQpodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yP21ldGFk YXRhPTENCg0Kew0KDQogICAiaWQiOiAiMjIwNDM5IiwNCg0KICAgIm5hbWUiOiAiQnJldCBUYXls b3IiLA0KDQogICAiZmlyc3RfbmFtZSI6ICJCcmV0IiwNCg0KICAgImxhc3RfbmFtZSI6ICJUYXls b3IiLA0KDQogICAibGluayI6ICJodHRwOi8vd3d3LmZhY2Vib29rLmNvbS9idGF5bG9yIiwNCg0K ICAgImxvY2F0aW9uIjogew0KDQogICAgICAiaWQiOiAxMDk2NTA3OTU3MTk2NTEsDQoNCiAgICAg ICJuYW1lIjogIkxvcyBHYXRvcywgQ2FsaWZvcm5pYSINCg0KICAgfSwNCg0KICAgImdlbmRlciI6 ICJtYWxlIiwNCg0KICAgIm1ldGFkYXRhIjogew0KDQogICAgICAiY29ubmVjdGlvbnMiOiB7DQoN CiAgICAgICAgICJob21lIjogImh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3IvaG9t ZSIsDQoNCiAgICAgICAgICJmZWVkIjogImh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXls b3IvZmVlZCIsDQoNCiAgICAgICAgICJmcmllbmRzIjogImh0dHBzOi8vZ3JhcGguZmFjZWJvb2su Y29tL2J0YXlsb3IvZnJpZW5kcyIsDQoNCiAgICAgICAgICJmYW1pbHkiOiAiaHR0cHM6Ly9ncmFw aC5mYWNlYm9vay5jb20vYnRheWxvci9mYW1pbHkiLA0KDQogICAgICAgICAiYWN0aXZpdGllcyI6 ICJodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL2FjdGl2aXRpZXMiLA0KDQogICAg ICAgICAiaW50ZXJlc3RzIjogImh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3IvaW50 ZXJlc3RzIiwNCg0KICAgICAgICAgIm11c2ljIjogImh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29t L2J0YXlsb3IvbXVzaWMiLA0KDQogICAgICAgICAiYm9va3MiOiAiaHR0cHM6Ly9ncmFwaC5mYWNl Ym9vay5jb20vYnRheWxvci9ib29rcyIsDQoNCiAgICAgICAgICJtb3ZpZXMiOiAiaHR0cHM6Ly9n cmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9tb3ZpZXMiLA0KDQogICAgICAgICAidGVsZXZpc2lv biI6ICJodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL3RlbGV2aXNpb24iLA0KDQog ICAgICAgICAibGlrZXMiOiAiaHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9saWtl cyIsDQoNCiAgICAgICAgICJwb3N0cyI6ICJodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5 bG9yL3Bvc3RzIiwNCg0KICAgICAgICAgInRhZ2dlZCI6ICJodHRwczovL2dyYXBoLmZhY2Vib29r LmNvbS9idGF5bG9yL3RhZ2dlZCIsDQoNCiAgICAgICAgICJzdGF0dXNlcyI6ICJodHRwczovL2dy YXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL3N0YXR1c2VzIiwNCg0KICAgICAgICAgImxpbmtzIjog Imh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3IvbGlua3MiLA0KDQogICAgICAgICAi bm90ZXMiOiAiaHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9ub3RlcyIsDQoNCiAg ICAgICAgICJwaG90b3MiOiAiaHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9waG90 b3MiLA0KDQogICAgICAgICAiYWxidW1zIjogImh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0 YXlsb3IvYWxidW1zIiwNCg0KICAgICAgICAgImV2ZW50cyI6ICJodHRwczovL2dyYXBoLmZhY2Vi b29rLmNvbS9idGF5bG9yL2V2ZW50cyIsDQoNCiAgICAgICAgICJncm91cHMiOiAiaHR0cHM6Ly9n cmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9ncm91cHMiLA0KDQogICAgICAgICAidmlkZW9zIjog Imh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3IvdmlkZW9zIiwNCg0KICAgICAgICAg InBpY3R1cmUiOiAiaHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9waWN0dXJlIiwN Cg0KICAgICAgICAgImluYm94IjogImh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3Iv aW5ib3giLA0KDQogICAgICAgICAib3V0Ym94IjogImh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29t L2J0YXlsb3Ivb3V0Ym94IiwNCg0KICAgICAgICAgInVwZGF0ZXMiOiAiaHR0cHM6Ly9ncmFwaC5m YWNlYm9vay5jb20vYnRheWxvci91cGRhdGVzIg0KDQogICAgICB9DQoNCiAgIH0sDQoNCiAgICJ0 eXBlIjogInVzZXIiDQoNCn0NCg0KDQoNCg0KDQotLQ0KDQpKYW1lcyBNYW5nZXINCg0K --_000_255B9BB34FB7D647A506DC292726F6E112631B273FWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj4mZ3Q7DQo8L3NwYW4+RG9uJ3QgeW91IGhhdmUgbGFyZ2VyIHByb2Js ZW1zIGlmIHlvdXIgcHJvdGVjdGVkIHJlc291cmNlcyBhcmUgY29tcHJvbWlzZWQ/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIG5vIGNv bXByb21pc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SXQgaXMgcGVyZmVjdGx5 IG5vcm1hbCBmb3IgYSBzZXJ2aWNlIHRvIHJldHVybiBjb250ZW50IHdpdGggbGlua3MgdG8gYXJi aXRyYXJ5IG90aGVyIHNpdGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkV2ZW4g cmVkaXJlY3RzIHRvIGFyYml0cmFyeSBvdGhlciBzaXRlcyAob3BlbiByZWRpcmVjdG9ycykg4oCU IHRob3VnaHQgdGhleSBjYXVzZSBzb21lIGlzc3VlcyDigJQgZG9u4oCZdCBtZWFuIHRoZSBwcm90 ZWN0ZWQgcmVzb3VyY2VzIGFyZSBjb21wcm9taXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj5JdCBqdXN0IG1lYW5zIGNsaWVudHMgbmVlZCB0byBiZSBjYXJlZnVsIHdoZW4gZm9s bG93aW5nIGxpbmtzIGFuZCByZWRpcmVjdHMgb24gdGhlIHdlYiwgYW5kIHRoZXkgbmVlZCB0aGUg cmlnaHQgaW5mbyB0byBiZSBhYmxlIHRvIGJlIGNhcmVmdWwgKHN1Y2ggYXMgd2hlbg0KIHRvIGlu Y2x1ZGUgYSB0b2tlbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29s b3I6IzFGNDk3RCI+QWxsIHRoZSDigJxjb25uZWN0aW9uc+KAnSBpbiB0aGUgRmFjZWJvb2sgQVBJ IGV4YW1wbGUgc2hvd24gYmVsb3cgYXJlIHRvIEZhY2Vib29rLiBJZiBGYWNlYm9vayBhbGxvd2Vk IHVzZXItZ2VuZXJhdGVkIHZhbHVlcyBmb3Igc29tZSBvZiB0aGVzZSB0aGF0IGNvdWxkIHBvaW50 DQogdG8gb3RoZXIgc2l0ZXMsIGl0IHdvdWxkbuKAmXQgbWVhbiBGYWNlYm9vayB3YXMgY29tcHJv bWlzZWQgdGVjaG5pY2FsbHksIGJ1dCBpdCB3b3VsZCBtZWFuIGEgdG9rZW4gc2hvdWxkIGJlIGlu Y2x1ZGUgd2hlbiBnZXR0aW5nIHNvbWUgYnV0IG5vdCBvdGhlcnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PGEg aHJlZj0iaHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRheWxvcj9tZXRhZGF0YT0xIj5odHRw czovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yP21ldGFkYXRhPTE8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyAmcXVvdDtpZCZxdW90OzogJnF1b3Q7MjIwNDM5JnF1b3Q7LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmcXVvdDtuYW1lJnF1b3Q7OiAmcXVv dDtCcmV0IFRheWxvciZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsgJnF1b3Q7Zmlyc3RfbmFtZSZxdW90OzogJnF1b3Q7QnJldCZxdW90Oyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJnF1b3Q7bGFzdF9uYW1lJnF1 b3Q7OiAmcXVvdDtUYXlsb3ImcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7ICZxdW90O2xpbmsmcXVvdDs6ICZxdW90O2h0dHA6Ly93d3cuZmFjZWJvb2su Y29tL2J0YXlsb3ImcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7ICZxdW90O2xvY2F0aW9uJnF1b3Q7OiB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lkJnF1b3Q7OiAxMDk2 NTA3OTU3MTk2NTEsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25hbWUmcXVvdDs6ICZxdW90O0xvcyBHYXRvcywgQ2Fs aWZvcm5pYSZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyB9LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmcXVvdDtn ZW5kZXImcXVvdDs6ICZxdW90O21hbGUmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7ICZxdW90O21ldGFkYXRhJnF1b3Q7OiB7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Nv bm5lY3Rpb25zJnF1b3Q7OiB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2hvbWUmcXVv dDs6ICZxdW90O2h0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3IvaG9tZSZxdW90Oyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZmVlZCZxdW90OzogJnF1b3Q7aHR0cHM6Ly9n cmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9mZWVkJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtmcmllbmRzJnF1b3Q7OiAmcXVvdDtodHRwczovL2dyYXBoLmZhY2Vib29rLmNv bS9idGF5bG9yL2ZyaWVuZHMmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Zh bWlseSZxdW90OzogJnF1b3Q7aHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9mYW1p bHkmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2FjdGl2aXRpZXMmcXVvdDs6 ICZxdW90O2h0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3IvYWN0aXZpdGllcyZxdW90 Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aW50ZXJlc3RzJnF1b3Q7OiAmcXVvdDto dHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL2ludGVyZXN0cyZxdW90Oyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7bXVzaWMmcXVvdDs6ICZxdW90O2h0dHBzOi8vZ3JhcGgu ZmFjZWJvb2suY29tL2J0YXlsb3IvbXVzaWMmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90O2Jvb2tzJnF1b3Q7OiAmcXVvdDtodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5 bG9yL2Jvb2tzJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDttb3ZpZXMmcXVv dDs6ICZxdW90O2h0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3IvbW92aWVzJnF1b3Q7 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt0ZWxldmlzaW9uJnF1b3Q7OiAmcXVvdDto dHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL3RlbGV2aXNpb24mcXVvdDssPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2xpa2VzJnF1b3Q7OiAmcXVvdDtodHRwczovL2dyYXBo LmZhY2Vib29rLmNvbS9idGF5bG9yL2xpa2VzJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDtwb3N0cyZxdW90OzogJnF1b3Q7aHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRh eWxvci9wb3N0cyZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7dGFnZ2VkJnF1 b3Q7OiAmcXVvdDtodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL3RhZ2dlZCZxdW90 Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7c3RhdHVzZXMmcXVvdDs6ICZxdW90O2h0 dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXlsb3Ivc3RhdHVzZXMmcXVvdDssPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2xpbmtzJnF1b3Q7OiAmcXVvdDtodHRwczovL2dyYXBoLmZh Y2Vib29rLmNvbS9idGF5bG9yL2xpbmtzJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm cXVvdDtub3RlcyZxdW90OzogJnF1b3Q7aHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRheWxv ci9ub3RlcyZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7cGhvdG9zJnF1b3Q7 OiAmcXVvdDtodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL3Bob3RvcyZxdW90Oyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWxidW1zJnF1b3Q7OiAmcXVvdDtodHRwczov L2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL2FsYnVtcyZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7ZXZlbnRzJnF1b3Q7OiAmcXVvdDtodHRwczovL2dyYXBoLmZhY2Vib29r LmNvbS9idGF5bG9yL2V2ZW50cyZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 Z3JvdXBzJnF1b3Q7OiAmcXVvdDtodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL2dy b3VwcyZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7dmlkZW9zJnF1b3Q7OiAm cXVvdDtodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL3ZpZGVvcyZxdW90Oyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7cGljdHVyZSZxdW90OzogJnF1b3Q7aHR0cHM6Ly9n cmFwaC5mYWNlYm9vay5jb20vYnRheWxvci9waWN0dXJlJnF1b3Q7LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmcXVvdDtpbmJveCZxdW90OzogJnF1b3Q7aHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5j b20vYnRheWxvci9pbmJveCZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7b3V0 Ym94JnF1b3Q7OiAmcXVvdDtodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9idGF5bG9yL291dGJv eCZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7dXBkYXRlcyZxdW90OzogJnF1 b3Q7aHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYnRheWxvci91cGRhdGVzJnF1b3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgfSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJnF1b3Q7dHlwZSZxdW90Ozog JnF1b3Q7dXNlciZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPn08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4tLQ0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_255B9BB34FB7D647A506DC292726F6E112631B273FWSMSG3153Vsrv_-- From recordond@gmail.com Thu May 6 23:31:19 2010 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 172E43A6AA2 for ; Thu, 6 May 2010 23:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_50=0.001, 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 c-6QMwozBJ0d for ; Thu, 6 May 2010 23:31:17 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 61F533A6892 for ; Thu, 6 May 2010 23:31:17 -0700 (PDT) Received: by iwn27 with SMTP id 27so1049858iwn.5 for ; Thu, 06 May 2010 23:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Cbo0u3qwqjp53brw0Y1c8x26WWcGGe1t5vjCtWW/nGI=; b=s0LJWZo09/s2374A9ID2aoWhQF6TS3PR/sBNJv4Kqudoutc2vR/Eth04yv7uMbnAaA Lm+MT0q1vMHexpU2kAlIzPUGWsYw7GaBzFNUZIfvhfM5Uytzj+yRTf3SOKzaSvypvK3a tmEPuxjNR0y8dqEzacNS1WZUbc5KRQXPfsPas= 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=cQcRezOO/Z/QdjKFnt4iiw4wMq5oJYA7jwF/Stfw8xu+hKDgfPog/la5ol71nsa3f0 wEAmjmFkcuUZSoRUIooaCVMvvVM0S+um4Z2fv/6CG1MQ/58GDsK0I73iOeghgUfZLDo3 j9vKvcfwmTcLJhce3YJ//qo7BYvHp/Egtwm3k= MIME-Version: 1.0 Received: by 10.231.190.204 with SMTP id dj12mr1858061ibb.9.1273213862338; Thu, 06 May 2010 23:31:02 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Thu, 6 May 2010 23:31:02 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112631B273F@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B26C0@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B273F@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 6 May 2010 23:31:02 -0700 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016363b888cfcdf500485fb330a Cc: OAuth WG Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 06:31:19 -0000 --0016363b888cfcdf500485fb330a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I thought this thread was about https://graph.facebook.com/btaylor returnin= g a HTTP redirect, not about following links returned within the result? On Thu, May 6, 2010 at 11:28 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > Don't you have larger problems if your protected resources are > compromised? > > > > > > There is no compromise. > > It is perfectly normal for a service to return content with links to > arbitrary other sites. > > Even redirects to arbitrary other sites (open redirectors) =97 thought th= ey > cause some issues =97 don=92t mean the protected resources are compromise= d. > > It just means clients need to be careful when following links and redirec= ts > on the web, and they need the right info to be able to be careful (such a= s > when to include a token). > > > > > > All the =93connections=94 in the Facebook API example shown below are to > Facebook. If Facebook allowed user-generated values for some of these tha= t > could point to other sites, it wouldn=92t mean Facebook was compromised > technically, but it would mean a token should be include when getting som= e > but not others. > > > > https://graph.facebook.com/btaylor?metadata=3D1 > > { > > "id": "220439", > > "name": "Bret Taylor", > > "first_name": "Bret", > > "last_name": "Taylor", > > "link": "http://www.facebook.com/btaylor", > > "location": { > > "id": 109650795719651, > > "name": "Los Gatos, California" > > }, > > "gender": "male", > > "metadata": { > > "connections": { > > "home": "https://graph.facebook.com/btaylor/home", > > "feed": "https://graph.facebook.com/btaylor/feed", > > "friends": "https://graph.facebook.com/btaylor/friends", > > "family": "https://graph.facebook.com/btaylor/family", > > "activities": "https://graph.facebook.com/btaylor/activities", > > "interests": "https://graph.facebook.com/btaylor/interests", > > "music": "https://graph.facebook.com/btaylor/music", > > "books": "https://graph.facebook.com/btaylor/books", > > "movies": "https://graph.facebook.com/btaylor/movies", > > "television": "https://graph.facebook.com/btaylor/television", > > "likes": "https://graph.facebook.com/btaylor/likes", > > "posts": "https://graph.facebook.com/btaylor/posts", > > "tagged": "https://graph.facebook.com/btaylor/tagged", > > "statuses": "https://graph.facebook.com/btaylor/statuses", > > "links": "https://graph.facebook.com/btaylor/links", > > "notes": "https://graph.facebook.com/btaylor/notes", > > "photos": "https://graph.facebook.com/btaylor/photos", > > "albums": "https://graph.facebook.com/btaylor/albums", > > "events": "https://graph.facebook.com/btaylor/events", > > "groups": "https://graph.facebook.com/btaylor/groups", > > "videos": "https://graph.facebook.com/btaylor/videos", > > "picture": "https://graph.facebook.com/btaylor/picture", > > "inbox": "https://graph.facebook.com/btaylor/inbox", > > "outbox": "https://graph.facebook.com/btaylor/outbox", > > "updates": "https://graph.facebook.com/btaylor/updates" > > } > > }, > > "type": "user" > > } > > > > > > -- > > James Manger > --0016363b888cfcdf500485fb330a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I thought this thread was about https://graph.facebook.com/btaylor returning a HTTP redirect, not a= bout following links returned within the result?


On Thu, May 6, 2010 at 11:28 PM, Manger, James H <James.H.Manger@team.telstra.= com> wrote:

> Don't you have larger problems if your protected resources are c= ompromised?

=A0

=A0

There is no compromise.

It is= perfectly normal for a service to return content with links to arbitrary o= ther sites.

Even = redirects to arbitrary other sites (open redirectors) =97 thought they caus= e some issues =97 don=92t mean the protected resources are compromised.

It ju= st means clients need to be careful when following links and redirects on t= he web, and they need the right info to be able to be careful (such as when to include a token).

=A0

=A0

All t= he =93connections=94 in the Facebook API example shown below are to Faceboo= k. If Facebook allowed user-generated values for some of these that could p= oint to other sites, it wouldn=92t mean Facebook was compromised technically, b= ut it would mean a token should be include when getting some but not others= .

=A0

ht= tps://graph.facebook.com/btaylor?metadata=3D1

{

=A0= =A0 "id": "220439",

=A0= =A0 "name": "Bret Taylor",

=A0= =A0 "first_name": "Bret",

=A0= =A0 "last_name": "Taylor",

=A0= =A0 "link": "http://www.facebook.com/btaylor",

=A0= =A0 "location": {

=A0= =A0=A0=A0=A0 "id": 109650795719651,

=A0= =A0=A0=A0=A0 "name": "Los Gatos, California"

=A0= =A0 },

=A0= =A0 "gender": "male",

=A0= =A0 "metadata": {

=A0= =A0=A0=A0=A0 "connections": {

=A0= =A0=A0=A0=A0=A0=A0=A0 "home": "https://graph.facebook.com/btaylor= /home",

=A0= =A0=A0=A0=A0=A0=A0=A0 "feed": "https://graph.facebook.com/btaylor= /feed",

=A0= =A0=A0=A0=A0=A0=A0=A0 "friends": "https://graph.facebook.com/b= taylor/friends",

=A0= =A0=A0=A0=A0=A0=A0=A0 "family": "https://graph.facebook.com/bta= ylor/family",

=A0= =A0=A0=A0=A0=A0=A0=A0 "activities": "https://graph.facebook= .com/btaylor/activities",

=A0= =A0=A0=A0=A0=A0=A0=A0 "interests": "https://graph.facebook.c= om/btaylor/interests",

=A0= =A0=A0=A0=A0=A0=A0=A0 "music": "https://graph.facebook.com/btayl= or/music",

=A0= =A0=A0=A0=A0=A0=A0=A0 "books": "https://graph.facebook.com/btayl= or/books",

=A0= =A0=A0=A0=A0=A0=A0=A0 "movies": "https://graph.facebook.com/bta= ylor/movies",

=A0= =A0=A0=A0=A0=A0=A0=A0 "television": "https://graph.facebook= .com/btaylor/television",

=A0= =A0=A0=A0=A0=A0=A0=A0 "likes": "https://graph.facebook.com/btayl= or/likes",

=A0= =A0=A0=A0=A0=A0=A0=A0 "posts": "https://graph.facebook.com/btayl= or/posts",

=A0= =A0=A0=A0=A0=A0=A0=A0 "tagged": "https://graph.facebook.com/bta= ylor/tagged",

=A0= =A0=A0=A0=A0=A0=A0=A0 "statuses": "https://graph.facebook.com= /btaylor/statuses",

=A0= =A0=A0=A0=A0=A0=A0=A0 "links": "https://graph.facebook.com/btayl= or/links",

=A0= =A0=A0=A0=A0=A0=A0=A0 "notes": "https://graph.facebook.com/btayl= or/notes",

=A0= =A0=A0=A0=A0=A0=A0=A0 "photos": "https://graph.facebook.com/bta= ylor/photos",

=A0= =A0=A0=A0=A0=A0=A0=A0 "albums": "https://graph.facebook.com/bta= ylor/albums",

=A0= =A0=A0=A0=A0=A0=A0=A0 "events": "https://graph.facebook.com/bta= ylor/events",

=A0= =A0=A0=A0=A0=A0=A0=A0 "groups": "https://graph.facebook.com/bta= ylor/groups",

=A0= =A0=A0=A0=A0=A0=A0=A0 "videos": "https://graph.facebook.com/bta= ylor/videos",

=A0= =A0=A0=A0=A0=A0=A0=A0 "picture": "https://graph.facebook.com/b= taylor/picture",

=A0= =A0=A0=A0=A0=A0 =A0=A0"inbox": "https://graph.facebook.com/btayl= or/inbox",

=A0= =A0=A0=A0=A0=A0=A0=A0 "outbox": "https://graph.facebook.com/bta= ylor/outbox",

=A0= =A0=A0=A0=A0=A0=A0=A0 "updates": "https://graph.facebook.com/b= taylor/updates"

=A0= =A0=A0=A0=A0 }

=A0= =A0 },

=A0= =A0 "type": "user"

}

=A0

=A0

--

James= Manger


--0016363b888cfcdf500485fb330a-- From James.H.Manger@team.telstra.com Thu May 6 23:41:54 2010 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 85C533A6AA0 for ; Thu, 6 May 2010 23:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.333 X-Spam-Level: * X-Spam-Status: No, score=1.333 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WblA72byyekB for ; Thu, 6 May 2010 23:41:53 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 909093A6A99 for ; Thu, 6 May 2010 23:41:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,346,1270389600"; d="scan'208,217";a="2204468" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 07 May 2010 16:41:39 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1973284" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcani.tcif.telstra.com.au with ESMTP; 07 May 2010 16:41:39 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 7 May 2010 16:41:38 +1000 From: "Manger, James H" To: David Recordon Date: Fri, 7 May 2010 16:41:37 +1000 Thread-Topic: [OAUTH-WG] Redirects Thread-Index: Acrtrt7k2MeSwDogTca7O7Ek/j3UEQAADd2w Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B278D@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B257D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B26C0@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B273F@WSMSG3153V.srv.dir.telstra.com> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112631B278DWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Redirects 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, 07 May 2010 06:41:54 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112631B278DWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIHRob3VnaHQgdGhpcyB0aHJlYWQgd2FzIGFib3V0IGh0dHBzOi8vZ3JhcGguZmFjZWJvb2su Y29tL2J0YXlsb3IgcmV0dXJuaW5nIGEgSFRUUCByZWRpcmVjdCwgbm90IGFib3V0IGZvbGxvd2lu ZyBsaW5rcyByZXR1cm5lZCB3aXRoaW4gdGhlIHJlc3VsdD8NCg0KDQoNCg0KDQpPcHBzLiBJIHN0 YXJ0ZWQgYSBzZXBhcmF0ZSB0aHJlYWQgdGhlbiDigJxjcm9zc2VkIHRoZSBiZWFtc+KAnSAoSSBh bSBub3Qgc3VyZSB0aGF0IHRoZXJlIGlzIGEgZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBiZXR3ZWVu IHJlZGlyZWN0cyBhbmQgb3RoZXIgbGlua3MgaW4gcmVzcG9uc2VzIGluIHRoaXMgY29udGV4dCku DQoNCg0KDQpBcmUgeW91IHN1Z2dlc3RpbmcgdGhlIHJ1bGUgc2hvdWxkIGJlIOKAnGFsd2F5cyBp bmNsdWRlIGEgdG9rZW4gd2hlbiBmb2xsb3dpbmcgYW4gSFRUUCByZWRpcmVjdOKAnSwgYW5kIHNv bWUgb3RoZXIgcnVsZShzKSBmb3Igb3RoZXIgbGlua3MgKHBlcmhhcHMgYXBwbGljYXRpb24tc3Bl Y2lmaWMpPyBUaGlzIGlzIHBvc3NpYmxlIChpZiB0aGUgc3BlYyBleHBsaWNpdGx5IHN0YXRlcyBp dCksIGJ1dCBJIHRoaW5rIGl0IGlzIGEgZGFuZ2Vyb3VzIGFwcHJvYWNoIGFuZCBub3QgYSBnb29k IG1hdGNoIGZvciBvdGhlciB3ZWIgdGVjaG5vbG9naWVzLg0KDQoNCg0KLS0NCg0KSmFtZXMgTWFu Z2VyDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E112631B278DWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m Z3Q7IEkgdGhvdWdodCB0aGlzIHRocmVhZCB3YXMgYWJvdXQNCjxhIGhyZWY9Imh0dHBzOi8vZ3Jh cGguZmFjZWJvb2suY29tL2J0YXlsb3IiPmh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2J0YXls b3I8L2E+IHJldHVybmluZyBhIEhUVFAgcmVkaXJlY3QsIG5vdCBhYm91dCBmb2xsb3dpbmcgbGlu a3MgcmV0dXJuZWQgd2l0aGluIHRoZSByZXN1bHQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj5PcHBzLiBJIHN0YXJ0ZWQgYSBzZXBhcmF0ZSB0aHJlYWQgdGhl biDigJxjcm9zc2VkIHRoZSBiZWFtc+KAnSAoSSBhbSBub3Qgc3VyZSB0aGF0IHRoZXJlIGlzIGEg ZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBiZXR3ZWVuIHJlZGlyZWN0cyBhbmQgb3RoZXIgbGlua3Mg aW4gcmVzcG9uc2VzDQogaW4gdGhpcyBjb250ZXh0KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5BcmUgeW91IHN1 Z2dlc3RpbmcgdGhlIHJ1bGUgc2hvdWxkIGJlIOKAnGFsd2F5cyBpbmNsdWRlIGEgdG9rZW4gd2hl biBmb2xsb3dpbmcgYW4gSFRUUCByZWRpcmVjdOKAnSwgYW5kIHNvbWUgb3RoZXIgcnVsZShzKSBm b3Igb3RoZXIgbGlua3MgKHBlcmhhcHMgYXBwbGljYXRpb24tc3BlY2lmaWMpPw0KIFRoaXMgaXMg cG9zc2libGUgKGlmIHRoZSBzcGVjIGV4cGxpY2l0bHkgc3RhdGVzIGl0KSwgYnV0IEkgdGhpbmsg aXQgaXMgYSBkYW5nZXJvdXMgYXBwcm9hY2ggYW5kIG5vdCBhIGdvb2QgbWF0Y2ggZm9yIG90aGVy IHdlYiB0ZWNobm9sb2dpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E112631B278DWSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Thu May 6 23:46:31 2010 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 0BF5B3A68B0 for ; Thu, 6 May 2010 23:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.343 X-Spam-Level: * X-Spam-Status: No, score=1.343 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btkilbwSQkud for ; Thu, 6 May 2010 23:46:30 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id B3FB03A69EF for ; Thu, 6 May 2010 23:46:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,347,1270389600"; d="scan'208,217";a="2529731" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 May 2010 16:46:16 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5974"; a="1652695" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccvi.tcif.telstra.com.au with ESMTP; 07 May 2010 16:46:16 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 7 May 2010 16:46:15 +1000 From: "Manger, James H" To: OAuth WG Date: Fri, 7 May 2010 16:46:14 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcrtprTngX8DR1/1STiGzpECvcjUiAAAB3VwAAFu7TA= Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B27AF@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112631B27AFWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 06:46:31 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112631B27AFWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBub3RpY2VkIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBkcmFmdC1pZXRmLW9hdXRoLXYyLTAyIChz ZWN0aW9uIDcgQWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlKToNCg0KDQoNCuKAnENsaWVu dHMgU0hPVUxEIE5PVCBtYWtlIGF1dGhlbnRpY2F0ZWQgcmVxdWVzdHMgd2l0aCBhbiBhY2Nlc3Mg dG9rZW4NCg0KICAgdG8gdW5mYW1pbGlhciByZXNvdXJjZSBzZXJ2ZXJzLCBlc3BlY2lhbGx5IHdo ZW4gdXNpbmcgYmVhcmVyIHRva2VucywNCg0KICAgcmVnYXJkbGVzcyBvZiB0aGUgcHJlc2VuY2Ug b2YgYSBzZWN1cmUgY2hhbm5lbC7igJ0NCg0KDQoNCkEg4oCcc2l0ZXPigJ0gcGFyYW1ldGVyIHdv dWxkIGFsbG93IGEgY2xpZW50IGFwcCBjYW4gdGVsbCB3aGVuIGl0IGlzIGFib3V0IHRvIGFjY2Vz cyBhbiDigJx1bmZhbWlsaWFyIHJlc291cmNlIHNlcnZlcuKAnTogYW4g4oCcdW5mYW1pbGlhciBy ZXNvdXJjZSBzZXJ2ZXLigJ0gaXMgYSBzZXJ2ZXIgbm90IGxpc3RlZCBpbiB0aGUg4oCcc2l0ZXPi gJ0gcGFyYW1ldGVyIChvciBub3QgdGhlIHNhbWUgc2VydmVyIGFzIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBpZiDigJxzaXRlc+KAnSBpcyBhYnNlbnQpLg0KDQpPdGhlcndpc2UgdGhpcyDigJxT SE9VTEQgTk9U4oCdIGxvb2tzIHByZXR0eSBoYXJkIHRvIHRlc3QuDQoNCg0KDQotLQ0KDQpKYW1l cyBNYW5nZXINCg0K --_000_255B9BB34FB7D647A506DC292726F6E112631B27AFWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5TZWN0aW9uMQ0K CXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SSBub3RpY2VkIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBkcmFm dC1pZXRmLW9hdXRoLXYyLTAyIChzZWN0aW9uIDcgQWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291 cmNlKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj7igJxDbGllbnRzIFNIT1VMRCBOT1QgbWFrZSBhdXRoZW50aWNh dGVkIHJlcXVlc3RzIHdpdGggYW4gYWNjZXNzIHRva2VuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHRvIHVuZmFtaWxpYXIgcmVzb3VyY2Ugc2VydmVycywgZXNw ZWNpYWxseSB3aGVuIHVzaW5nIGJlYXJlciB0b2tlbnMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHJlZ2FyZGxlc3Mgb2YgdGhlIHByZXNlbmNlIG9mIGEgc2Vj dXJlIGNoYW5uZWwu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QSDigJxzaXRlc+KAnSBwYXJhbWV0ZXIgd291 bGQgYWxsb3cgYSBjbGllbnQgYXBwIGNhbiB0ZWxsIHdoZW4gaXQgaXMgYWJvdXQgdG8gYWNjZXNz IGFuIOKAnHVuZmFtaWxpYXIgcmVzb3VyY2Ugc2VydmVy4oCdOiBhbiDigJx1bmZhbWlsaWFyIHJl c291cmNlIHNlcnZlcuKAnSBpcyBhIHNlcnZlcg0KIG5vdCBsaXN0ZWQgaW4gdGhlIOKAnHNpdGVz 4oCdIHBhcmFtZXRlciAob3Igbm90IHRoZSBzYW1lIHNlcnZlciBhcyB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgaWYg4oCcc2l0ZXPigJ0gaXMgYWJzZW50KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj5PdGhlcndpc2UgdGhpcyDigJxTSE9VTEQgTk9U4oCdIGxvb2tzIHByZXR0eSBo YXJkIHRvIHRlc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E112631B27AFWSMSG3153Vsrv_-- From torsten@lodderstedt.net Fri May 7 03:18:27 2010 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 B5A463A6AF2 for ; Fri, 7 May 2010 03:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 OxBIrVStIJ0D for ; Fri, 7 May 2010 03:18:26 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id F0E853A6AE2 for ; Fri, 7 May 2010 03:18:17 -0700 (PDT) Received: from [213.216.10.66] (helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OAKd1-0000KB-P0; Fri, 07 May 2010 12:17:55 +0200 Message-ID: <4BE3E8B4.9020909@lodderstedt.net> Date: Fri, 07 May 2010 12:17:24 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B26DE@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112631B26DE@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------040401090100090107090605" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 10:18:27 -0000 This is a multi-part message in MIME format. --------------040401090100090107090605 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Am 07.05.2010 08:14, schrieb Manger, James H: > > > what about an additional realm response value? > > My original > suggestion(http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html) > had a “realm” in addition to “sites”. I still think that should be > present (though more to match the HTTP auth model (RFC2617) than an > expectation that it will be used by most services). > > > If there is a binding between realm and token, the client can decide > based on the realm attribute discovered using a WWW-Authenticate > response which token to use. > > “realm” is not sufficient, however. A “realm” doesn’t stop you sending > a token to a bad site. Even if an app makes and unauthenticated call > first, there is nothing to stop the bad site responding with a > WWW-Auth header with the right “realm” value so the client app will > reveal the token. > > -- > > James Manger > I didn't have that threat on my radar screen so far, thank you for your advice. Let me describe what I understood so far from this thread and your previous posting. I see two different scenarios: 1) Resource server controls token sites (context of the realm attribute) The realm returned in a WWW-Authenticate header is by default valid within the resource servers site (scheme + host-Part of the URL?) only. This way, a bad site cannot automatically get access to tokens intended for other sites just by spoofing the realm attribute. Using an additional "sites"-attribute in the WWW-Authenticate-Header, the resource server could indicate on which sites the given realm is considered equivalent. This broadens the context a realm is valid in. It is the resource server which authorizes the usage of tokens on other sites by the client. If the clients encounters the same realm on a site listed in "sites", it is authorized to automatically use the token there. 2) Authorization server controls token sites (context of token) If I interpret your current proposal correctly, you suggest the authorization server may determine on which sites a particular token can be used. That way, the authorization server explicitly authorizes usage of tokens based on the trusted relationship between resource server and authorization server. This is an interesting proposal since it could be used to prevent any bad site from token abuse and unauthorized access to private user data. The later is especially relevant if unencrypted, self-contained bearer tokens are used. Attack scenario: Assumption: User X has an account with site "https://www.example.com" where he stores his private data 1) The users intends to configure its mobile OAuth client for access to "https://www.example.com", but unfortunately uses the wrong URL "https://www.bad_example.com" obtained from an attackers e-Mail 2) "http://www.bad_example.com" respondes with the authorization URL of the OAuth server of "https://www.example.com" 3) The user authorizes access for "https://www.example.com" (or at least believes to do so) 4) The client acquires an access token from the authorization server 5) The mobile client access "https://www.bad_example.com" using that access token 6) "https://www.bad_example.com" proxies the request to "https://www.example.com", so neither the user nor the service realize the problem I see the following ways how "https://www.bad_example.com" could abuse the token: a) It can access the users private data on "https://www.example.com" or deposite illegal files (file sharing). b) It can read the private user data contained in the token If we follow your proposal, the authorization server would respond with a response value of "sites": ["https://www.example.com"] in step (4). The client would detect the attack attempt and refuse to send any request with the token to "https://www.bad_example.com". In my opinion, (1) improves security and eases the practicability of OAuth2 in scenarios with multiple sites and (2) is a significant security improvement. I think, both scenarios should be addressed by the WG. Any thoughts? regards, Torsten. --------------040401090100090107090605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Am 07.05.2010 08:14, schrieb Manger, James H:

> what about an additional realm response value?

My original suggestion(http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html) had a “realm” in addition to “sites”. I still think that should be present (though more to match the HTTP auth model (RFC2617) than an expectation that it will be used by most services).

 

 

> If there is a binding between realm and token, the client can decide based on the realm attribute discovered using a WWW-Authenticate response which token to use.

 

“realm” is not sufficient, however. A “realm” doesn’t stop you sending a token to a bad site. Even if an app makes and unauthenticated call first, there is nothing to stop the bad site responding with a WWW-Auth header with the right “realm” value so the client app will reveal the token.

 

 

--

James Manger


I didn't have that threat on my radar screen so far, thank you for your advice.

Let me describe what I understood so far from this thread and your previous posting. I see two different scenarios:

1) Resource server controls token sites (context of the realm attribute)

The realm returned in a WWW-Authenticate header is by default valid within the resource servers site (scheme + host-Part of the URL?) only. This way, a bad site cannot automatically get access to tokens intended for other sites just by spoofing  the realm attribute. Using an additional "sites"-attribute in the WWW-Authenticate-Header, the resource server could indicate on which sites the given realm is considered equivalent. This broadens the context a realm is valid in. It is the resource server which authorizes the usage of tokens on other sites by the client. If the clients encounters the same realm on a site listed in "sites", it is authorized to automatically use the token there.

2) Authorization server controls token sites (context of token)

If I interpret your current proposal correctly, you suggest the authorization server may determine on which sites a particular token can be used. That way, the authorization server explicitly authorizes usage of tokens based on the trusted relationship between resource server and authorization server. This is an interesting proposal since it could be used to prevent any bad site from token abuse and unauthorized access to private user data. The later is especially relevant if unencrypted, self-contained bearer tokens are used.

Attack scenario:
Assumption: User X has an account with site "https://www.example.com" where he stores his private data
1) The users intends to configure its mobile OAuth client for access to "https://www.example.com", but unfortunately uses the wrong URL "https://www.bad_example.com" obtained from an attackers e-Mail
2) "http://www.bad_example.com" respondes with the authorization URL of the OAuth server of "https://www.example.com"
3) The user authorizes access for "https://www.example.com" (or at least believes to do so) 
4) The client acquires an access token from the authorization server
5) The mobile client access "https://www.bad_example.com" using that access token
6) "https://www.bad_example.com" proxies the request to "https://www.example.com", so neither the user nor the service realize the problem

I see the following ways how "https://www.bad_example.com" could abuse the token:
a) It can access the users private data on "https://www.example.com" or deposite illegal files (file sharing).
b) It can read the private user data contained in the token
 
If we follow your proposal, the authorization server would respond with a response value of "sites": ["https://www.example.com"] in step (4). The client would detect the attack attempt and refuse to send any request with the token to "https://www.bad_example.com".

In my opinion, (1) improves security and eases the practicability of OAuth2 in scenarios with multiple sites and (2) is a significant security improvement. I think, both scenarios should be addressed by the WG.

Any thoughts?

regards,
Torsten.

--------------040401090100090107090605-- From pid@pidster.com Fri May 7 07:20:52 2010 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 B0C463A6B3D for ; Fri, 7 May 2010 07:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 DB+GlgJ6ERxx for ; Fri, 7 May 2010 07:20:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0CBEC3A6AB2 for ; Fri, 7 May 2010 07:20:31 -0700 (PDT) Received: by wwd20 with SMTP id 20so82293wwd.31 for ; Fri, 07 May 2010 07:20:13 -0700 (PDT) Received: by 10.216.156.203 with SMTP id m53mr53298wek.209.1273242013114; Fri, 07 May 2010 07:20:13 -0700 (PDT) Received: from Phoenix.local (94-193-98-41.zone7.bethere.co.uk [94.193.98.41]) by mx.google.com with ESMTPS id v59sm1030022wec.15.2010.05.07.07.20.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 07:20:11 -0700 (PDT) Message-ID: <4BE4218A.8080402@pidster.com> Date: Fri, 07 May 2010 15:19:54 +0100 From: Pid Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: OAuth WG References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> <4BE2FC60.7040303@lodderstedt.net> In-Reply-To: <4BE2FC60.7040303@lodderstedt.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2624427A5D8A29A9988437EA" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pid@pidster.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 14:20:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2624427A5D8A29A9988437EA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/05/2010 18:29, Torsten Lodderstedt wrote: > +1 , we've got really strong support for JSON and I'm also looking > forward to review Erans proposal. Sorry but I am going to continue being Devil's Advocate and keep asking why JSON is better. Just saying "we all want it" isn't a positive argument in favor of the change. > I checked back today with some of our service and client application > developers. All of our services offer JSON and XML as transport format,= > no one even considered using application/x-www-form-urlencoded for > encoding web services responses. >=20 > On the client side, things look even simpler. Our own client applicatio= n > generally use JSON on all platforms, incl. smartphones (Android, > iPhone), handsets (J2ME), home entertainment, and home automation > devices. Especially the later are really special since they use only a > small subest of Java (no Java 5, no generics, ..) but JSON is apparentl= y > not a problem.=20 How is it supported, out of interest? > It is mainly prefered because it combines small > resource/bandwitdh consumption with ease of use.=20 Compared to what? XML obviously, but not x-www-form-urlencoded, I think. > Our iPhone applications are built using external libraries, the > experiences are good. As Joseph said, JSON is the "right horse to bet o= n".=20 Why? > Platform support is getting better in my observation. For example,=20 > J2ME supports it and JavaScript is getting native JSON support as well.= Which is good, but doesn't explain why the format is better. > From my point of view, the Oauth API should fit well into the world of > HTTP-based services and choosing a completly different encoding > (application/x-www-form-urlencoded) for OAuth might appear somehow weir= d > to developers.=20 Eh? It's hardly a 'completely different' encoding, it's a key component of most HTTP-based services. POST?! Ampersand separated name/value pairs are a familiar format to web developers, it's not at all an intellectual challenge to consider their use in a response. > Moreover, what do developers really gain from that constraint?=20 One can ask the same of JSON. In fact I am asking that. Still. > OAuth just provides the tokens for invoking other services > securly. If all the other services use JSON, applications need JSON > libraries anyway. So why bother with that question with respect to OAut= h? It's a stretch to make that argument. There's no guarantee that all OAuth applications will use JSON unless it's mandated as part of the spec= =2E application/x-www-form-urlencoded is easy to understand, extremely simple to implement & parse, has no dependencies and is comprehensively supported already. JSON is better than the above because: (Please fill in the blank) p > regards, > Torsten. >=20 > Am 06.05.2010 17:46, schrieb Joseph Smarr: >> I'm hearing a lot of confusion on this thread. >> >> Evan-of course when attributes are sent *on-the-url* then they get >> parsed automatically by the HTTP stack, but we're talking about the >> response body, which every OAuth 1.0 library I've seen writes their >> own (usually buggy) parser for, and that's where we're proposing to >> use JSON.=20 >> >> I've seen good JSON library support on every platform I've needed to >> work for, and it's becoming more and more common (look at Facebook's >> new Graph API, for instance), so I doubt many platforms will be >> without JSON parsers for much longer. That being said, it's prudent to= >> look at the state-of-the-art and verify that requiring JSON is not a >> practical hindrance for iPhone developers, etc., but I still think >> it's "betting on the right horse" and it's going to be a lot simpler >> and less error-prone than either url-encoded values or XML. >> >> Eran-thanks for agreeing to write something up, and I agree we've got >> strong support for JSON being the primary/only format for the response= >> body. I look forward to the proposed text and will happily review it. >> >> Thanks, js >> >> On Wed, May 5, 2010 at 3:35 PM, Pid > > wrote: >> >> On 05/05/2010 19:49, DeWitt Clinton wrote: >> > Having written more than one compliant JSON parser myself, it is= >> most >> > certainly not "trivial", and not something that can be safely >> done with >> > a regular expression or other hacks. >> > >> > That said, it's not /hard/, and that alone is no reason not to >> mandate >> > JSON, but I do want people to be clear about what mandating JSON= >> means. >> > Clients will need a fully compliant parser. Period. If the >> OAuth spec >> > requires JSON, then it should require it by reference to RFC >> 4627, not >> > just by giving some examples that demonstrate the curly braces. >> > >> > -DeWitt >> >> I know it's late, but can I add my 2 cents - as a developer who'll= be >> implementing this? >> >> >> In the original post, Dick suggested that developers were having >> trouble >> with the URL encoding format - but I respectfully suggest that JSO= N is >> going to be more problematic. >> >> There's no guarantee that an external JSON parser will be >> available for >> a given platform/language/business, (perhaps because of licensing,= if >> not other more technical reasons). So that means writing one. >> >> Writing a JSON parser just to cover the simple usage proposed won'= t be >> too tricky, but if the JSON response is so simple why bother >> adding this >> dependency at all? I'm slightly baffled... >> >> >> URL encoding is required for at least one flow, so IMHO it might >> as well >> stay for the rest. Simplicity is important. >> >> >> Can someone from the pro-JSON side offer a clearer explanation as >> to the >> benefits, so I can stop scratching my head about it all, please? >> >> >> >> Respectfully, >> >> Pid >> >> >> > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt >> > >> >>= >> wrote: >> > >> > Am 05.05.2010 20:01, schrieb Evan Gilbert: >> >> >> >> >> >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert >> >> >> >> wrot= e: >> >> >> >> >> >> >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt >> >> > > >> wrote: >> >> >> >> Even if not supported directly by the platform >> there are >> >> many JSON libraries available these days. >> >> >> >> >> >> It's not hard to add JSON support, but it's a factor in= the >> >> choice. >> >> >> >> >> >> >> >> http://www.json.org/ lists 3 libraries for >> Objective-C alone. >> >> >> >> Moreover, the JSON documents we are discussing now = are >> >> simple, something like >> >> >> >> >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600= ", >> >> "refresh_token": "8xLOxBtZp8" } >> >> >> >> Parsing such a document is not a challenge even wit= hout >> >> library support. >> >> >> >> >> >> Per notes above - the client needs to do understand for= m >> >> encoding anyway. The client needs to parse the redirect= _uri >> >> and also needs to generate form encoded requests. >> >> >> >> >> >> Also, for the User-Agent flow, parsing potentially >> untrusted JSON >> >> in JavaScript is difficult. The normal path of using eval()= is >> >> unsafe and leads to XSS holes - you need to run regex >> matcher to >> >> verify that the JSON content has no executable code. >> > >> > You are right, using eval to parse JSON is dangerous and >> thus as far >> > as I understand, the recommended way is to use a JSON parser= >> (aka >> > native JSON support)? >> > >> > regards, >> > Torsten. >> > >> > _______________________________________________ >> > 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 >> =20 >=20 --------------enig2624427A5D8A29A9988437EA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQIVAwUBS+Qhl2oM2OGpOvr9AQolURAAksxgQ4HcHybiaZiExp4IrVEzIqj+kBbj mGRTjjKRxJ+xP8mpcl7c479dhoDbDDsvW/UaOj5zE+kvdDP4b9VVnoOeShnkX4D1 qoPHUMpE9MxX8BMr8vLw+wJykgdxRnEZ5E3w/WtZEzxIodHSbu1d7Sj/2cD2objP bcUxUyUkg7u7els0INNnsCAv55DdMlTKnDn885OLYcsIyBW4eJ7jvkuJ29HdTkOO Efe/rDiyI6ExUBq8sfUfLY19R5tgKQ+fJ7ZvjgS/OSu4PGeVpa9ZWmISzzXxnoDY 2BqVf7HMwx8cz6pJmojJCwfR6sZ4jEWv39T1K0nxHwNeftC70qPdb5j9qpfqJmA1 xut/YyLWJMVhF0AfVnJNQhwgyMihYCQ1O0wJg/SQ2vD0KF6B96fpdtp5tXUfIiPx 2YXRu5BKk7T0bf7Fb54T8TfW0vBDr47KwgRekXQBK0JzVufcWnf9YIq7b/8GGDCJ Fk9zlOBOp2Og4Wz/DuGKT5iQpyF9FYQSSBg1kGkvHUb296/qD28rUvU/XLXrsk/r gzwEkmBGZxPQIcTBui2tL7jgWQ80Kybv19TvcRqdpgT+hsVo0I2/+qENEE9mWYT0 um5sJKk2kF9w5rMZhPgEdoXW3YxWdMl/20acWpuQgwe/4U9rcSzuVgQOe67Q7eYM SDHixEm6/oY= =kgv0 -----END PGP SIGNATURE----- --------------enig2624427A5D8A29A9988437EA-- From email@pbryan.net Fri May 7 07:59:15 2010 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 3DB073A6B65 for ; Fri, 7 May 2010 07:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 FOiyeeQrTroc for ; Fri, 7 May 2010 07:59:13 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 0886E3A6B08 for ; Fri, 7 May 2010 07:59:07 -0700 (PDT) Received: from [192.168.1.3] (S0106001346fbe4af.vf.shawcable.net [174.1.44.35]) by maple.anode.ca (Postfix) with ESMTPSA id C925C650A for ; Fri, 7 May 2010 14:58:54 +0000 (UTC) From: "Paul C. Bryan" To: OAuth WG In-Reply-To: <4BE4218A.8080402@pidster.com> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> <4BE2FC60.7040303@lodderstedt.net> <4BE4218A.8080402@pidster.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 May 2010 08:01:37 -0700 Message-ID: <1273244497.24999.218.camel@Dynamo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 07 May 2010 14:59:15 -0000 Here's my 2¢ worth... Criteria: If the structure of encoded data is guaranteed to be a flat list of name-value pairs, x-www-form-urlencoded seems sufficient. If the structure could be (arbitrarily) complex (e.g. nesting lists or associative arrays), then definitely use JSON. Why JSON instead of, say, XML? JSON unambiguously translates to and from commonly used (usually native) data structures in virtually every common scripting and programming language in existence. Paul -----Original Message----- From: Pid Reply-to: pid@pidster.com To: OAuth WG Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) Date: Fri, 07 May 2010 15:19:54 +0100 On 06/05/2010 18:29, Torsten Lodderstedt wrote: > +1 , we've got really strong support for JSON and I'm also looking > forward to review Erans proposal. Sorry but I am going to continue being Devil's Advocate and keep asking why JSON is better. Just saying "we all want it" isn't a positive argument in favor of the change. > I checked back today with some of our service and client application > developers. All of our services offer JSON and XML as transport format, > no one even considered using application/x-www-form-urlencoded for > encoding web services responses. > > On the client side, things look even simpler. Our own client application > generally use JSON on all platforms, incl. smartphones (Android, > iPhone), handsets (J2ME), home entertainment, and home automation > devices. Especially the later are really special since they use only a > small subest of Java (no Java 5, no generics, ..) but JSON is apparently > not a problem. How is it supported, out of interest? > It is mainly prefered because it combines small > resource/bandwitdh consumption with ease of use. Compared to what? XML obviously, but not x-www-form-urlencoded, I think. > Our iPhone applications are built using external libraries, the > experiences are good. As Joseph said, JSON is the "right horse to bet on". Why? > Platform support is getting better in my observation. For example, > J2ME supports it and JavaScript is getting native JSON support as well. Which is good, but doesn't explain why the format is better. > From my point of view, the Oauth API should fit well into the world of > HTTP-based services and choosing a completly different encoding > (application/x-www-form-urlencoded) for OAuth might appear somehow weird > to developers. Eh? It's hardly a 'completely different' encoding, it's a key component of most HTTP-based services. POST?! Ampersand separated name/value pairs are a familiar format to web developers, it's not at all an intellectual challenge to consider their use in a response. > Moreover, what do developers really gain from that constraint? One can ask the same of JSON. In fact I am asking that. Still. > OAuth just provides the tokens for invoking other services > securly. If all the other services use JSON, applications need JSON > libraries anyway. So why bother with that question with respect to OAuth? It's a stretch to make that argument. There's no guarantee that all OAuth applications will use JSON unless it's mandated as part of the spec. application/x-www-form-urlencoded is easy to understand, extremely simple to implement & parse, has no dependencies and is comprehensively supported already. JSON is better than the above because: (Please fill in the blank) p > regards, > Torsten. > > Am 06.05.2010 17:46, schrieb Joseph Smarr: >> I'm hearing a lot of confusion on this thread. >> >> Evan-of course when attributes are sent *on-the-url* then they get >> parsed automatically by the HTTP stack, but we're talking about the >> response body, which every OAuth 1.0 library I've seen writes their >> own (usually buggy) parser for, and that's where we're proposing to >> use JSON. >> >> I've seen good JSON library support on every platform I've needed to >> work for, and it's becoming more and more common (look at Facebook's >> new Graph API, for instance), so I doubt many platforms will be >> without JSON parsers for much longer. That being said, it's prudent to >> look at the state-of-the-art and verify that requiring JSON is not a >> practical hindrance for iPhone developers, etc., but I still think >> it's "betting on the right horse" and it's going to be a lot simpler >> and less error-prone than either url-encoded values or XML. >> >> Eran-thanks for agreeing to write something up, and I agree we've got >> strong support for JSON being the primary/only format for the response >> body. I look forward to the proposed text and will happily review it. >> >> Thanks, js >> >> On Wed, May 5, 2010 at 3:35 PM, Pid > > wrote: >> >> On 05/05/2010 19:49, DeWitt Clinton wrote: >> > Having written more than one compliant JSON parser myself, it is >> most >> > certainly not "trivial", and not something that can be safely >> done with >> > a regular expression or other hacks. >> > >> > That said, it's not /hard/, and that alone is no reason not to >> mandate >> > JSON, but I do want people to be clear about what mandating JSON >> means. >> > Clients will need a fully compliant parser. Period. If the >> OAuth spec >> > requires JSON, then it should require it by reference to RFC >> 4627, not >> > just by giving some examples that demonstrate the curly braces. >> > >> > -DeWitt >> >> I know it's late, but can I add my 2 cents - as a developer who'll be >> implementing this? >> >> >> In the original post, Dick suggested that developers were having >> trouble >> with the URL encoding format - but I respectfully suggest that JSON is >> going to be more problematic. >> >> There's no guarantee that an external JSON parser will be >> available for >> a given platform/language/business, (perhaps because of licensing, if >> not other more technical reasons). So that means writing one. >> >> Writing a JSON parser just to cover the simple usage proposed won't be >> too tricky, but if the JSON response is so simple why bother >> adding this >> dependency at all? I'm slightly baffled... >> >> >> URL encoding is required for at least one flow, so IMHO it might >> as well >> stay for the rest. Simplicity is important. >> >> >> Can someone from the pro-JSON side offer a clearer explanation as >> to the >> benefits, so I can stop scratching my head about it all, please? >> >> >> >> Respectfully, >> >> Pid >> >> >> > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt >> > >> >> >> wrote: >> > >> > Am 05.05.2010 20:01, schrieb Evan Gilbert: >> >> >> >> >> >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert >> >> >> >> wrote: >> >> >> >> >> >> >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt >> >> > > >> wrote: >> >> >> >> Even if not supported directly by the platform >> there are >> >> many JSON libraries available these days. >> >> >> >> >> >> It's not hard to add JSON support, but it's a factor in the >> >> choice. >> >> >> >> >> >> >> >> http://www.json.org/ lists 3 libraries for >> Objective-C alone. >> >> >> >> Moreover, the JSON documents we are discussing now are >> >> simple, something like >> >> >> >> >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600", >> >> "refresh_token": "8xLOxBtZp8" } >> >> >> >> Parsing such a document is not a challenge even without >> >> library support. >> >> >> >> >> >> Per notes above - the client needs to do understand form >> >> encoding anyway. The client needs to parse the redirect_uri >> >> and also needs to generate form encoded requests. >> >> >> >> >> >> Also, for the User-Agent flow, parsing potentially >> untrusted JSON >> >> in JavaScript is difficult. The normal path of using eval() is >> >> unsafe and leads to XSS holes - you need to run regex >> matcher to >> >> verify that the JSON content has no executable code. >> > >> > You are right, using eval to parse JSON is dangerous and >> thus as far >> > as I understand, the recommended way is to use a JSON parser >> (aka >> > native JSON support)? >> > >> > regards, >> > Torsten. >> > >> > _______________________________________________ >> > 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 >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From blowmage@gmail.com Fri May 7 08:06:17 2010 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 CCFF73A6851 for ; Fri, 7 May 2010 08:06:17 -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 g9755UpoDTK5 for ; Fri, 7 May 2010 08:06:17 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 494BF3A6B00 for ; Fri, 7 May 2010 08:06:09 -0700 (PDT) Received: by qyk11 with SMTP id 11so1715641qyk.13 for ; Fri, 07 May 2010 08:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=RPG0C3rrFvCKNUdmNkywdRR2yM5na3F/ugiNMS5IR/M=; b=N74qjPklmroMoC3bqCexRsksfaTD4rROUSTo/aMXgP+n/pzx8IKQ7Rn7Jjzo+giHfu +Z7jfbqSHGv6dtKVebwDRH1kbhF16jKk9LSLBZLrWb+uxAyDwz96D0j9S8H8jDctEskp MSoMih4pyu0rLhlzvXTSNxycslJetpA+nJTYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vagJqEB+n98/dvjdKVhZ1O0/9pKFW8XkC772hQMcndthyNZcYje+z4L3/JCfWuksoR UFTWi/jHfysC3bxcmGY/1k3z3Sxxw6qqaNZC6589ETfTpyZbyiC5OTOKBT5gGQaEIa4f H69vFyT352nIkgk2Ao0nqXpA7/P8VXhxcPweE= MIME-Version: 1.0 Received: by 10.224.53.80 with SMTP id l16mr1271518qag.308.1273244752219; Fri, 07 May 2010 08:05:52 -0700 (PDT) Received: by 10.229.222.6 with HTTP; Fri, 7 May 2010 08:05:52 -0700 (PDT) Date: Fri, 7 May 2010 09:05:52 -0600 Message-ID: From: Mike Moore To: OAuth WG Content-Type: multipart/alternative; boundary=00c09f905f992b50a80486026546 Subject: [OAUTH-WG] application/x-www-form-urlencoded Counterproposal 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, 07 May 2010 15:06:17 -0000 --00c09f905f992b50a80486026546 Content-Type: text/plain; charset=ISO-8859-1 I propose alter the spec so that the token responses are encoded with application/x-www-form-urlencoded, matching OAuth 1.0. I also propose moving the JSON and XML support for these responses to an extension. I haven't heard an argument that convinces me that JSON adds anything over application/x-www-form-urlencoded. It seems to be a preference and as such can be accommodated as an extension. Thoughts? --00c09f905f992b50a80486026546 Content-Type: text/html; charset=ISO-8859-1
I propose alter the spec so that the token responses are encoded with application/x-www-form-urlencoded, matching OAuth 1.0. I also propose moving the JSON and XML support for these responses to an extension.

I haven't heard an argument that convinces me that JSON adds anything over application/x-www-form-urlencoded. It seems to be a preference and as such can be accommodated as an extension. Thoughts?
--00c09f905f992b50a80486026546-- From email@pbryan.net Fri May 7 08:06:56 2010 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 610513A6957 for ; Fri, 7 May 2010 08:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 wCn3hZNpCe0q for ; Fri, 7 May 2010 08:06:54 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 67BB13A6960 for ; Fri, 7 May 2010 08:06:54 -0700 (PDT) Received: from [192.168.1.3] (S0106001346fbe4af.vf.shawcable.net [174.1.44.35]) by maple.anode.ca (Postfix) with ESMTPSA id B102F650A for ; Fri, 7 May 2010 15:06:41 +0000 (UTC) From: "Paul C. Bryan" To: oauth@ietf.org In-Reply-To: References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> <4BE2FC60.7040303@lodderstedt.net> <4BE4218A.8080402@pidster.com> <1273244497.24999.218.camel@Dynamo> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 May 2010 08:09:24 -0700 Message-ID: <1273244964.24999.219.camel@Dynamo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 07 May 2010 15:06:56 -0000 Well, if the response is guaranteed to be a flat list of name-value pairs, then JSON seems like overkill. -----Original Message----- From: Mike Moore To: Paul C. Bryan Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) Date: Fri, 7 May 2010 09:04:30 -0600 On Fri, May 7, 2010 at 9:01 AM, Paul C. Bryan wrote: Here's my 2¢ worth... Criteria: If the structure of encoded data is guaranteed to be a flat list of name-value pairs, x-www-form-urlencoded seems sufficient. If the structure could be (arbitrarily) complex (e.g. nesting lists or associative arrays), then definitely use JSON. As I understand it, there was agreement that the responses would be a flat list of name-value pairs. Why JSON instead of, say, XML? JSON unambiguously translates to and from commonly used (usually native) data structures in virtually every common scripting and programming language in existence. Paul -----Original Message----- From: Pid Reply-to: pid@pidster.com To: OAuth WG Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) Date: Fri, 07 May 2010 15:19:54 +0100 On 06/05/2010 18:29, Torsten Lodderstedt wrote: > +1 , we've got really strong support for JSON and I'm also looking > forward to review Erans proposal. Sorry but I am going to continue being Devil's Advocate and keep asking why JSON is better. Just saying "we all want it" isn't a positive argument in favor of the change. > I checked back today with some of our service and client application > developers. All of our services offer JSON and XML as transport format, > no one even considered using application/x-www-form-urlencoded for > encoding web services responses. > > On the client side, things look even simpler. Our own client application > generally use JSON on all platforms, incl. smartphones (Android, > iPhone), handsets (J2ME), home entertainment, and home automation > devices. Especially the later are really special since they use only a > small subest of Java (no Java 5, no generics, ..) but JSON is apparently > not a problem. How is it supported, out of interest? > It is mainly prefered because it combines small > resource/bandwitdh consumption with ease of use. Compared to what? XML obviously, but not x-www-form-urlencoded, I think. > Our iPhone applications are built using external libraries, the > experiences are good. As Joseph said, JSON is the "right horse to bet on". Why? > Platform support is getting better in my observation. For example, > J2ME supports it and JavaScript is getting native JSON support as well. Which is good, but doesn't explain why the format is better. > From my point of view, the Oauth API should fit well into the world of > HTTP-based services and choosing a completly different encoding > (application/x-www-form-urlencoded) for OAuth might appear somehow weird > to developers. Eh? It's hardly a 'completely different' encoding, it's a key component of most HTTP-based services. POST?! Ampersand separated name/value pairs are a familiar format to web developers, it's not at all an intellectual challenge to consider their use in a response. > Moreover, what do developers really gain from that constraint? One can ask the same of JSON. In fact I am asking that. Still. > OAuth just provides the tokens for invoking other services > securly. If all the other services use JSON, applications need JSON > libraries anyway. So why bother with that question with respect to OAuth? It's a stretch to make that argument. There's no guarantee that all OAuth applications will use JSON unless it's mandated as part of the spec. application/x-www-form-urlencoded is easy to understand, extremely simple to implement & parse, has no dependencies and is comprehensively supported already. JSON is better than the above because: (Please fill in the blank) p > regards, > Torsten. > > Am 06.05.2010 17:46, schrieb Joseph Smarr: >> I'm hearing a lot of confusion on this thread. >> >> Evan-of course when attributes are sent *on-the-url* then they get >> parsed automatically by the HTTP stack, but we're talking about the >> response body, which every OAuth 1.0 library I've seen writes their >> own (usually buggy) parser for, and that's where we're proposing to >> use JSON. >> >> I've seen good JSON library support on every platform I've needed to >> work for, and it's becoming more and more common (look at Facebook's >> new Graph API, for instance), so I doubt many platforms will be >> without JSON parsers for much longer. That being said, it's prudent to >> look at the state-of-the-art and verify that requiring JSON is not a >> practical hindrance for iPhone developers, etc., but I still think >> it's "betting on the right horse" and it's going to be a lot simpler >> and less error-prone than either url-encoded values or XML. >> >> Eran-thanks for agreeing to write something up, and I agree we've got >> strong support for JSON being the primary/only format for the response >> body. I look forward to the proposed text and will happily review it. >> >> Thanks, js >> >> On Wed, May 5, 2010 at 3:35 PM, Pid > > wrote: >> >> On 05/05/2010 19:49, DeWitt Clinton wrote: >> > Having written more than one compliant JSON parser myself, it is >> most >> > certainly not "trivial", and not something that can be safely >> done with >> > a regular expression or other hacks. >> > >> > That said, it's not /hard/, and that alone is no reason not to >> mandate >> > JSON, but I do want people to be clear about what mandating JSON >> means. >> > Clients will need a fully compliant parser. Period. If the >> OAuth spec >> > requires JSON, then it should require it by reference to RFC >> 4627, not >> > just by giving some examples that demonstrate the curly braces. >> > >> > -DeWitt >> >> I know it's late, but can I add my 2 cents - as a developer who'll be >> implementing this? >> >> >> In the original post, Dick suggested that developers were having >> trouble >> with the URL encoding format - but I respectfully suggest that JSON is >> going to be more problematic. >> >> There's no guarantee that an external JSON parser will be >> available for >> a given platform/language/business, (perhaps because of licensing, if >> not other more technical reasons). So that means writing one. >> >> Writing a JSON parser just to cover the simple usage proposed won't be >> too tricky, but if the JSON response is so simple why bother >> adding this >> dependency at all? I'm slightly baffled... >> >> >> URL encoding is required for at least one flow, so IMHO it might >> as well >> stay for the rest. Simplicity is important. >> >> >> Can someone from the pro-JSON side offer a clearer explanation as >> to the >> benefits, so I can stop scratching my head about it all, please? >> >> >> >> Respectfully, >> >> Pid >> >> >> > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt >> > >> >> >> wrote: >> > >> > Am 05.05.2010 20:01, schrieb Evan Gilbert: >> >> >> >> >> >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert >> >> >> >> wrote: >> >> >> >> >> >> >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt >> >> > > >> wrote: >> >> >> >> Even if not supported directly by the platform >> there are >> >> many JSON libraries available these days. >> >> >> >> >> >> It's not hard to add JSON support, but it's a factor in the >> >> choice. >> >> >> >> >> >> >> >> http://www.json.org/ lists 3 libraries for >> Objective-C alone. >> >> >> >> Moreover, the JSON documents we are discussing now are >> >> simple, something like >> >> >> >> >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600", >> >> "refresh_token": "8xLOxBtZp8" } >> >> >> >> Parsing such a document is not a challenge even without >> >> library support. >> >> >> >> >> >> Per notes above - the client needs to do understand form >> >> encoding anyway. The client needs to parse the redirect_uri >> >> and also needs to generate form encoded requests. >> >> >> >> >> >> Also, for the User-Agent flow, parsing potentially >> untrusted JSON >> >> in JavaScript is difficult. The normal path of using eval() is >> >> unsafe and leads to XSS holes - you need to run regex >> matcher to >> >> verify that the JSON content has no executable code. >> > >> > You are right, using eval to parse JSON is dangerous and >> thus as far >> > as I understand, the recommended way is to use a JSON parser >> (aka >> > native JSON support)? >> > >> > regards, >> > Torsten. >> > >> > _______________________________________________ >> > 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 >> > _______________________________________________ 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 simoneg@apache.org Fri May 7 08:25:39 2010 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 7BE0B3A6869 for ; Fri, 7 May 2010 08:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.931 X-Spam-Level: X-Spam-Status: No, score=-7.931 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 mJ8aLa+DG6fR for ; Fri, 7 May 2010 08:25:34 -0700 (PDT) Received: from minotaur.apache.org (minotaur.apache.org [140.211.11.9]) by core3.amsl.com (Postfix) with SMTP id 634E03A6834 for ; Fri, 7 May 2010 08:24:54 -0700 (PDT) Received: (qmail 69839 invoked by uid 99); 7 May 2010 15:24:41 -0000 Received: from localhost.apache.org (HELO mail-ww0-f44.google.com) (127.0.0.1) (smtp-auth username simoneg, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 May 2010 15:24:41 +0000 Received: by wwd20 with SMTP id 20so140703wwd.31 for ; Fri, 07 May 2010 08:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.86.129 with SMTP id w1mr123910wee.174.1273245878461; Fri, 07 May 2010 08:24:38 -0700 (PDT) Received: by 10.216.18.136 with HTTP; Fri, 7 May 2010 08:24:38 -0700 (PDT) In-Reply-To: <1273244497.24999.218.camel@Dynamo> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> <4BE2FC60.7040303@lodderstedt.net> <4BE4218A.8080402@pidster.com> <1273244497.24999.218.camel@Dynamo> Date: Fri, 7 May 2010 17:24:38 +0200 Message-ID: From: Simone Gianni To: OAuth WG Content-Type: multipart/alternative; boundary=0016e6d785454c26da048602a89d Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 07 May 2010 15:25:40 -0000 --0016e6d785454c26da048602a89d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +2=A2 :D There are hundreds of formats for a flat key->value "map", expecially when you already know the native type of the value given the key. Http headers are a format, HTTP form encoding is a well known and supported format and already required by OAuth in other places. JSON is nice, but to invoke a JSON parser (not to mention an XML parser) to parse a simple map of key->value is overkill .. you can afford it if you ar= e just dealing with a javascript based client (exec('resp=3D' + json), and ri= sk injection) cause the javascript interpreter kicks in and the CPU you are wasting is not yours :D On the opposite, if the client is not a javascript based device and the CPU is yours (for example, you are authenticating your own servers each on each other) then it's uselessly overkill. Another problem is generating JSON data. Again, encoding a key->value in HTTP form encoding is quite CPU trivial and will have to be done anyway in other parts of OAuth, serializing JSON is not (from a performance POV, not from a programmer POV), unless you write the json string yourself which gives JSON no benefit for the server guys. Couldn't the specification mandate support for HTTP form encoding and optionally use the HTTP header Content-type to provide alternative encoding= s for the same key->value map? Some implementations will then support JSON cause many clients will be JavaScript, some others may not cause are specialized in other environments, some others may support YAML or other representations to better suit their clients or optimize performances or whatever. Obviously, it changes if data is structured, in which case JSON or XML are required, but it does not seem to be the case. Simone 2010/5/7 Paul C. Bryan > Here's my 2=A2 worth... > > Criteria: If the structure of encoded data is guaranteed to be a flat > list of name-value pairs, x-www-form-urlencoded seems sufficient. If the > structure could be (arbitrarily) complex (e.g. nesting lists or > associative arrays), then definitely use JSON. > > Why JSON instead of, say, XML? JSON unambiguously translates to and from > commonly used (usually native) data structures in virtually every common > scripting and programming language in existence. > > Paul > > -----Original Message----- > From: Pid > Reply-to: pid@pidster.com > To: OAuth WG > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > (Proposal) > Date: Fri, 07 May 2010 15:19:54 +0100 > > On 06/05/2010 18:29, Torsten Lodderstedt wrote: > > +1 , we've got really strong support for JSON and I'm also looking > > forward to review Erans proposal. > > Sorry but I am going to continue being Devil's Advocate and keep asking > why JSON is better. Just saying "we all want it" isn't a positive > argument in favor of the change. > > > I checked back today with some of our service and client application > > developers. All of our services offer JSON and XML as transport format, > > no one even considered using application/x-www-form-urlencoded for > > encoding web services responses. > > > > On the client side, things look even simpler. Our own client applicatio= n > > generally use JSON on all platforms, incl. smartphones (Android, > > iPhone), handsets (J2ME), home entertainment, and home automation > > devices. Especially the later are really special since they use only a > > small subest of Java (no Java 5, no generics, ..) but JSON is apparentl= y > > not a problem. > > How is it supported, out of interest? > > > It is mainly prefered because it combines small > > resource/bandwitdh consumption with ease of use. > > Compared to what? XML obviously, but not x-www-form-urlencoded, I think. > > > Our iPhone applications are built using external libraries, the > > experiences are good. As Joseph said, JSON is the "right horse to bet > on". > > Why? > > > Platform support is getting better in my observation. For example, > > J2ME supports it and JavaScript is getting native JSON support as well. > > Which is good, but doesn't explain why the format is better. > > > From my point of view, the Oauth API should fit well into the world of > > HTTP-based services and choosing a completly different encoding > > (application/x-www-form-urlencoded) for OAuth might appear somehow weir= d > > to developers. > > Eh? It's hardly a 'completely different' encoding, it's a key component > of most HTTP-based services. POST?! > > Ampersand separated name/value pairs are a familiar format to web > developers, it's not at all an intellectual challenge to consider their > use in a response. > > > Moreover, what do developers really gain from that constraint? > > One can ask the same of JSON. In fact I am asking that. Still. > > > > OAuth just provides the tokens for invoking other services > > securly. If all the other services use JSON, applications need JSON > > libraries anyway. So why bother with that question with respect to OAut= h? > > It's a stretch to make that argument. There's no guarantee that all > OAuth applications will use JSON unless it's mandated as part of the spec= . > > > application/x-www-form-urlencoded is easy to understand, extremely > simple to implement & parse, has no dependencies and is comprehensively > supported already. > > JSON is better than the above because: > > > > > (Please fill in the blank) > > > > p > > > regards, > > Torsten. > > > > Am 06.05.2010 17:46, schrieb Joseph Smarr: > >> I'm hearing a lot of confusion on this thread. > >> > >> Evan-of course when attributes are sent *on-the-url* then they get > >> parsed automatically by the HTTP stack, but we're talking about the > >> response body, which every OAuth 1.0 library I've seen writes their > >> own (usually buggy) parser for, and that's where we're proposing to > >> use JSON. > >> > >> I've seen good JSON library support on every platform I've needed to > >> work for, and it's becoming more and more common (look at Facebook's > >> new Graph API, for instance), so I doubt many platforms will be > >> without JSON parsers for much longer. That being said, it's prudent to > >> look at the state-of-the-art and verify that requiring JSON is not a > >> practical hindrance for iPhone developers, etc., but I still think > >> it's "betting on the right horse" and it's going to be a lot simpler > >> and less error-prone than either url-encoded values or XML. > >> > >> Eran-thanks for agreeing to write something up, and I agree we've got > >> strong support for JSON being the primary/only format for the response > >> body. I look forward to the proposed text and will happily review it. > >> > >> Thanks, js > >> > >> On Wed, May 5, 2010 at 3:35 PM, Pid >> > wrote: > >> > >> On 05/05/2010 19:49, DeWitt Clinton wrote: > >> > Having written more than one compliant JSON parser myself, it is > >> most > >> > certainly not "trivial", and not something that can be safely > >> done with > >> > a regular expression or other hacks. > >> > > >> > That said, it's not /hard/, and that alone is no reason not to > >> mandate > >> > JSON, but I do want people to be clear about what mandating JSON > >> means. > >> > Clients will need a fully compliant parser. Period. If the > >> OAuth spec > >> > requires JSON, then it should require it by reference to RFC > >> 4627, not > >> > just by giving some examples that demonstrate the curly braces. > >> > > >> > -DeWitt > >> > >> I know it's late, but can I add my 2 cents - as a developer who'll > be > >> implementing this? > >> > >> > >> In the original post, Dick suggested that developers were having > >> trouble > >> with the URL encoding format - but I respectfully suggest that JSO= N > is > >> going to be more problematic. > >> > >> There's no guarantee that an external JSON parser will be > >> available for > >> a given platform/language/business, (perhaps because of licensing, > if > >> not other more technical reasons). So that means writing one. > >> > >> Writing a JSON parser just to cover the simple usage proposed won'= t > be > >> too tricky, but if the JSON response is so simple why bother > >> adding this > >> dependency at all? I'm slightly baffled... > >> > >> > >> URL encoding is required for at least one flow, so IMHO it might > >> as well > >> stay for the rest. Simplicity is important. > >> > >> > >> Can someone from the pro-JSON side offer a clearer explanation as > >> to the > >> benefits, so I can stop scratching my head about it all, please? > >> > >> > >> > >> Respectfully, > >> > >> Pid > >> > >> > >> > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt > >> > > >> >> > >> wrote: > >> > > >> > Am 05.05.2010 20:01, schrieb Evan Gilbert: > >> >> > >> >> > >> >> On Wed, May 5, 2010 at 10:59 AM, Evan Gilbert > >> > >> >> >> > wrote: > >> >> > >> >> > >> >> > >> >> On Wed, May 5, 2010 at 10:47 AM, Torsten Lodderstedt > >> >> >> >> >> wrote: > >> >> > >> >> Even if not supported directly by the platform > >> there are > >> >> many JSON libraries available these days. > >> >> > >> >> > >> >> It's not hard to add JSON support, but it's a factor in > the > >> >> choice. > >> >> > >> >> > >> >> > >> >> http://www.json.org/ lists 3 libraries for > >> Objective-C alone. > >> >> > >> >> Moreover, the JSON documents we are discussing now > are > >> >> simple, something like > >> >> > >> >> > >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600= ", > >> >> "refresh_token": "8xLOxBtZp8" } > >> >> > >> >> Parsing such a document is not a challenge even > without > >> >> library support. > >> >> > >> >> > >> >> Per notes above - the client needs to do understand for= m > >> >> encoding anyway. The client needs to parse the > redirect_uri > >> >> and also needs to generate form encoded requests. > >> >> > >> >> > >> >> Also, for the User-Agent flow, parsing potentially > >> untrusted JSON > >> >> in JavaScript is difficult. The normal path of using eval() > is > >> >> unsafe and leads to XSS holes - you need to run regex > >> matcher to > >> >> verify that the JSON content has no executable code. > >> > > >> > You are right, using eval to parse JSON is dangerous and > >> thus as far > >> > as I understand, the recommended way is to use a JSON parser > >> (aka > >> > native JSON support)? > >> > > >> > regards, > >> > Torsten. > >> > > >> > _______________________________________________ > >> > 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 > >> > > > > > _______________________________________________ > 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 > --0016e6d785454c26da048602a89d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +2=A2 :D

There are hundreds of formats for a flat key->value &quo= t;map", expecially when you already know the native type of the value = given the key. Http headers are a format, HTTP form encoding is a well know= n and supported format and already required by OAuth in other places.

JSON is nice, but to invoke a JSON parser (not to mention an XML parser= ) to parse a simple map of key->value is overkill .. you can afford it i= f you are just dealing with a javascript based client (exec('resp=3D= 9; + json), and risk injection) cause the javascript interpreter kicks in a= nd the CPU you are wasting is not yours :D

On the opposite, if the client is not a javascript based device and the= CPU is yours (for example, you are authenticating your own servers each on= each other) then it's uselessly overkill.

Another problem is ge= nerating JSON data. Again, encoding a key->value in HTTP form encoding i= s quite CPU trivial and will have to be done anyway in other parts of OAuth= , serializing JSON is not (from a performance POV, not from a programmer PO= V), unless you write the json string yourself which gives JSON no benefit f= or the server guys.

Couldn't the specification mandate support for HTTP form encoding a= nd optionally use the HTTP header Content-type to provide alternative encod= ings for the same key->value map? Some implementations will then support= JSON cause many clients will be JavaScript, some others may not cause are = specialized in other environments, some others may support YAML or other re= presentations to better suit their clients or optimize performances or what= ever.

Obviously, it changes if data is structured, in which case JSON or XML = are required, but it does not seem to be the case.

Simone

2010/5/7 Paul C. Bryan <email@pbryan.net>
Here's my 2= =A2 worth...

Criteria: If the structure of encoded data is guaranteed to be a flat
list of name-value pairs, x-www-form-urlencoded seems sufficient. If the structure could be (arbitrarily) complex (e.g. nesting lists or
associative arrays), then definitely use JSON.

Why JSON instead of, say, XML? JSON unambiguously translates to and from commonly used (usually native) data structures in virtually every common scripting and programming language in existence.

Paul

-----Original Message-----
From: Pid <pid@pidster.com> Reply-to: pid@pidster.com
To: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
(Proposal)
Date: Fri, 07 May 2010 15:19:54 +0100

On 06/05/2010 18:29, Torsten Lodderstedt wrote:
> +1 , we've got really strong support for JSON and I'm also loo= king
> forward to review Erans proposal.

Sorry but I am going to continue being Devil's Advocate and keep asking=
why JSON is better. =A0Just saying "we all want it" isn't a p= ositive
argument in favor of the change.

> I checked back today with some of our service and client application > developers. All of our services offer JSON and XML as transport format= ,
> no one even considered using application/x-www-form-urlencoded for
> encoding web services responses.
>
> On the client side, things look even simpler. Our own client applicati= on
> generally use JSON on all platforms, incl. smartphones (Android,
> iPhone), handsets (J2ME), home entertainment, and home automation
> devices. Especially the later are really special since they use only a=
> small subest of Java (no Java 5, no generics, ..) but JSON is apparent= ly
> not a problem.

How is it supported, out of interest?

> It is mainly prefered because it combines small
> resource/bandwitdh consumption with ease of use.

Compared to what? XML obviously, but not x-www-form-urlencoded, I think.
> Our iPhone applications are built using external libraries, the
> experiences are good. As Joseph said, JSON is the "right horse to= bet on".

Why?

> Platform support is getting better in my observation. For example,
> J2ME supports it and JavaScript is getting native JSON support as well= .

Which is good, but doesn't explain why the format is better.

> From my point of view, the Oauth API should fit well into the world of=
> HTTP-based services and choosing a completly different encoding
> (application/x-www-form-urlencoded) for OAuth might appear somehow wei= rd
> to developers.

Eh? =A0It's hardly a 'completely different' encoding, it's = a key component
of most HTTP-based services. =A0POST?!

Ampersand separated name/value pairs are a familiar format to web
developers, it's not at all an intellectual challenge to consider their=
use in a response.

> Moreover, what do developers really gain from that constraint?

One can ask the same of JSON. =A0In fact I am asking that. =A0Still.


> OAuth just provides the tokens for invoking other services
> securly. If all the other services use JSON, applications need JSON > libraries anyway. So why bother with that question with respect to OAu= th?

It's a stretch to make that argument. =A0There's no guarantee that = all
OAuth applications will use JSON unless it's mandated as part of the sp= ec.


application/x-www-form-urlencoded is easy to understand, extremely
simple to implement & parse, has no dependencies and is comprehensively=
supported already.

JSON is better than the above because:




(Please fill in the blank)



p

> regards,
> Torsten.
>
> Am 06.05.2010 17:46, schrieb Joseph Smarr:
>> I'm hearing a lot of confusion on this thread.
>>
>> Evan-of course when attributes are sent *on-the-url* then they get=
>> parsed automatically by the HTTP stack, but we're talking abou= t the
>> response body, which every OAuth 1.0 library I've seen writes = their
>> own (usually buggy) parser for, and that's where we're pro= posing to
>> use JSON.
>>
>> I've seen good JSON library support on every platform I've= needed to
>> work for, and it's becoming more and more common (look at Face= book's
>> new Graph API, for instance), so I doubt many platforms will be >> without JSON parsers for much longer. That being said, it's pr= udent to
>> look at the state-of-the-art and verify that requiring JSON is not= a
>> practical hindrance for iPhone developers, etc., but I still think=
>> it's "betting on the right horse" and it's going= to be a lot simpler
>> and less error-prone than either url-encoded values or XML.
>>
>> Eran-thanks for agreeing to write something up, and I agree we'= ;ve got
>> strong support for JSON being the primary/only format for the resp= onse
>> body. I look forward to the proposed text and will happily review = it.
>>
>> Thanks, js
>>
>> On Wed, May 5, 2010 at 3:35 PM, Pid <pid@pidster.com
>> <mailto:pid@pidster.com&= gt;> wrote:
>>
>> =A0 =A0 On 05/05/2010 19:49, DeWitt Clinton wrote:
>> =A0 =A0 > Having written more than one compliant JSON parser my= self, it is
>> =A0 =A0 most
>> =A0 =A0 > certainly not "trivial", and not something = that can be safely
>> =A0 =A0 done with
>> =A0 =A0 > a regular expression or other hacks.
>> =A0 =A0 >
>> =A0 =A0 > That said, it's not /hard/, and that alone is no = reason not to
>> =A0 =A0 mandate
>> =A0 =A0 > JSON, but I do want people to be clear about what man= dating JSON
>> =A0 =A0 means.
>> =A0 =A0 > =A0Clients will need a fully compliant parser. =A0Per= iod. =A0If the
>> =A0 =A0 OAuth spec
>> =A0 =A0 > requires JSON, then it should require it by reference= to RFC
>> =A0 =A0 4627, not
>> =A0 =A0 > just by giving some examples that demonstrate the cur= ly braces.
>> =A0 =A0 >
>> =A0 =A0 > -DeWitt
>>
>> =A0 =A0 I know it's late, but can I add my 2 cents - as a deve= loper who'll be
>> =A0 =A0 implementing this?
>>
>>
>> =A0 =A0 In the original post, Dick suggested that developers were = having
>> =A0 =A0 trouble
>> =A0 =A0 with the URL encoding format - but I respectfully suggest = that JSON is
>> =A0 =A0 going to be more problematic.
>>
>> =A0 =A0 There's no guarantee that an external JSON parser will= be
>> =A0 =A0 available for
>> =A0 =A0 a given platform/language/business, (perhaps because of li= censing, if
>> =A0 =A0 not other more technical reasons). =A0So that means writin= g one.
>>
>> =A0 =A0 Writing a JSON parser just to cover the simple usage propo= sed won't be
>> =A0 =A0 too tricky, but if the JSON response is so simple why both= er
>> =A0 =A0 adding this
>> =A0 =A0 dependency at all? =A0I'm slightly baffled...
>>
>>
>> =A0 =A0 URL encoding is required for at least one flow, so IMHO it= might
>> =A0 =A0 as well
>> =A0 =A0 stay for the rest. =A0Simplicity is important.
>>
>>
>> =A0 =A0 Can someone from the pro-JSON side offer a clearer explana= tion as
>> =A0 =A0 to the
>> =A0 =A0 benefits, so I can stop scratching my head about it all, p= lease?
>>
>>
>>
>> =A0 =A0 Respectfully,
>>
>> =A0 =A0 Pid
>>
>>
>> =A0 =A0 > On Wed, May 5, 2010 at 11:38 AM, Torsten Lodderstedt<= br> >> =A0 =A0 > <torste= n@lodderstedt.net <mailto:torsten@lodderstedt.net>
>> =A0 =A0 <mailto:tors= ten@lodderstedt.net <mailto:torsten@lodderstedt.net>>>
>> =A0 =A0 wrote:
>> =A0 =A0 >
>> =A0 =A0 > =A0 =A0 Am 05.05.2010 20:01, schrieb Evan Gilbert: >> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 On Wed, May 5, 2010 at 10:59 AM, Evan Gil= bert
>> =A0 =A0 <uidude@google.com= <mailto:uidude@google.com&= gt;
>> =A0 =A0 >> =A0 =A0 <mailto:uidude@google.com <mailto:uidude@google.com>>> wrote:
>> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 =A0 =A0 On Wed, May 5, 2010 at 10:47 AM, = Torsten Lodderstedt
>> =A0 =A0 >> =A0 =A0 =A0 =A0 <torsten@lodderstedt.net
>> =A0 =A0 <mailto:tors= ten@lodderstedt.net> <mailto:torsten@lodderstedt.net
>> =A0 =A0 <mailto:tors= ten@lodderstedt.net>>> wrote:
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 Even if not supported dir= ectly by the platform
>> =A0 =A0 there are
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 many JSON libraries avail= able these days.
>> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 =A0 =A0 It's not hard to add JSON sup= port, but it's a factor in the
>> =A0 =A0 >> =A0 =A0 =A0 =A0 choice.
>> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 http://www.json.org/ lists 3 libraries for >> =A0 =A0 Objective-C alone.
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 Moreover, the JSON docume= nts we are discussing now are
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 simple, something like >> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 { "access_token"= ;: "SlAV32hkKG", "expires_in": "3600",
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 "refresh_token"= : "8xLOxBtZp8" }
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 Parsing such a document i= s not a challenge even without
>> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 library support.
>> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 =A0 =A0 Per notes above - the client need= s to do understand form
>> =A0 =A0 >> =A0 =A0 =A0 =A0 encoding anyway. The client needs= to parse the redirect_uri
>> =A0 =A0 >> =A0 =A0 =A0 =A0 and also needs to generate form e= ncoded requests.
>> =A0 =A0 >>
>> =A0 =A0 >>
>> =A0 =A0 >> =A0 =A0 Also, for the User-Agent flow, parsing po= tentially
>> =A0 =A0 untrusted JSON
>> =A0 =A0 >> =A0 =A0 in JavaScript is difficult. The normal pa= th of using eval() is
>> =A0 =A0 >> =A0 =A0 unsafe and leads to XSS holes - you need = to run regex
>> =A0 =A0 matcher to
>> =A0 =A0 >> =A0 =A0 verify that the JSON content has no execu= table code.
>> =A0 =A0 >
>> =A0 =A0 > =A0 =A0 You are right, using eval to parse JSON is da= ngerous and
>> =A0 =A0 thus as far
>> =A0 =A0 > =A0 =A0 as I understand, the recommended way is to us= e a JSON parser
>> =A0 =A0 (aka
>> =A0 =A0 > =A0 =A0 native JSON support)?
>> =A0 =A0 >
>> =A0 =A0 > =A0 =A0 regards,
>> =A0 =A0 > =A0 =A0 Torsten.
>> =A0 =A0 >
>> =A0 =A0 > =A0 =A0 _____________________________________________= __
>> =A0 =A0 > =A0 =A0 OAuth mailing list
>> =A0 =A0 > =A0 =A0 OAuth@ietf.= org <mailto:OAuth@ietf.org>=
>> =A0 =A0 <mailto:OAuth@ietf.or= g <mailto:OAuth@ietf.org>&g= t;
>> =A0 =A0 > =A0 =A0 https://www.ietf.org/mailman/listinfo/oauth
>> =A0 =A0 >
>> =A0 =A0 >
>> =A0 =A0 >
>> =A0 =A0 >
>> =A0 =A0 > _______________________________________________
>> =A0 =A0 > OAuth mailing list
>> =A0 =A0 > OAuth@ietf.org = <mailto:OAuth@ietf.org>
>> =A0 =A0 > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> =A0 =A0 _______________________________________________
>> =A0 =A0 OAuth mailing list
>> =A0 =A0 OAuth@ietf.org <m= ailto:OAuth@ietf.org>
>> =A0 =A0 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
h= ttps://www.ietf.org/mailman/listinfo/oauth


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

--0016e6d785454c26da048602a89d-- From eran@hueniverse.com Fri May 7 08:28:59 2010 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 11AF03A6977 for ; Fri, 7 May 2010 08:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=-0.840, 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 J0ZkPPsSWSdb for ; Fri, 7 May 2010 08:28:57 -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 525133A6957 for ; Fri, 7 May 2010 08:28:57 -0700 (PDT) Received: (qmail 6872 invoked from network); 7 May 2010 15:28:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 May 2010 15:28:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 7 May 2010 08:28:38 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Fri, 7 May 2010 08:28:55 -0700 Thread-Topic: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) Thread-Index: Acrn1JdrOMkYuKUZT+GM4uZXxgbhmQGJCNDg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343932484ADD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20100419134825.134951nuzvi35hk4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BD2A172.2070401@lodderstedt.net> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> In-Reply-To: <4BD9E1E3.7060107@lodderstedt.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] application/x-www-form-urlencoded vs JSON (Proposal) 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, 07 May 2010 15:28:59 -0000 This approach seems the most reasonable to me. Server MUST support all three formats. Client MUST support one but MAY support more formats. This puts a little extra work on the server but since this is on the serial= izing side, no parser is needed. On the client side it adds no additional c= omplexity - it reduces it because it allows the client to work in its nativ= e format (XML, JSON, text). Those arguing for a single format have not made a compelling argument why h= aving a default format with 2 other optional formats, where the client gets= complete flexibility on the parsing side is bad or too complex. Again, for the server, this is just a single printf() statement per format: printf("{\"access_token\":\"%s\",\"expires_in\":%d}", token, expires); printf("%s%d", token, expires); For the client, if they don't like the default, you can use the Accept head= er or a 'format' query parameter. Show me where this is more complex! EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Thursday, April 29, 2010 12:46 PM > To: Robert Sayre > Cc: jsmarr@stanfordalumni.org; oauth@ietf.org > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > (Proposal) >=20 > Hi all, >=20 > please find below a proposal for adding support for multiple response > formats to the specification. I have taken the current version of the dra= ft > http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf- > oauth.txt > and added some modifications indicated by dashed lines. Proposed changes > to section 3.5.2 should be applied to 3.5.3, 3.6.1., 3.7.1., 3.7.2, and 4= ., too. >=20 > Basically, the idea is that clients indicate the desired format using Acc= ept > headers (default) or request parameters (User-Agent flow) and the > response is delivered accordingly. The formats considered are > application/json, text/xml, and application/x-www-form-urlencoded. And as > suggested by Joseph, parameters are encoded straight-forward as flat JSON > object or XML document, respectively. >=20 > I would appriciate > regards, > Torsten. >=20 > 3.5.2. Web Server Flow > 3.5.2.2. Client Requests Access Token >=20 > The client obtains an access token from the authorization server by <= snip> > secret_type > OPTIONAL. The access token secret type as described by > Section 5.3. If omitted, the authorization server will issue a > bearer token (an access token without a matching secret) as > described by Section 5.2. >=20 > -------- > A client may indicate the desired response format using an Accept-Header > specifying one of the following mime types: application/x-www-form- > urlencoded, > application/xml, > or application/json. If not specified, the default response format is > application/json. > (Alternatively, the response format could be specified by a query paramet= er) > -------- >=20 > For example, the client makes the following HTTPS request (line > breaks are for display purposes only): >=20 > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > -------- > Accept: application/json > -------- >=20 > type=3Dweb_server&client_id=3Ds6BhdRkqt3& > client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& > redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb >=20 >=20 > The authorization server MUST verify that the verification code, > client identity, client secret, and redirection URI are all valid and > match its stored association. If the request is valid, the > authorization server issues an access token and delivers it to the > client in the HTTP response body using > -------- > the mime type as requested by the client or "application/json" > -------- > with a 200 status code (OK). >=20 > The response contains the following parameters: >=20 > access_token > REQUIRED. The access token issued by the authorization server. >=20 > expires_in > OPTIONAL. The duration in seconds of the access token > lifetime. >=20 > refresh_token > OPTIONAL. The refresh token used to obtain new access tokens > using the same end user access grant as described in Section 4. >=20 > access_token_secret > REQUIRED if requested by the client. The corresponding access > token secret as requested by the client. >=20 > -------- > The response format depends on the requested mime type. The > content-type header field indicates mime type and may optionaly > indicate charset. >=20 > "application/json": All parameters are encoded as one flat JSON objec= t > with one key/value pair per parameter. >=20 > For example: >=20 > HTTP/1.1 200 OK > Content-Type: application/json >=20 > { "access_token": "SlAV32hkKG", "expires_in": "3600", > "refresh_token": "8xLOxBtZp8" } >=20 > "text/xml": All parameters are encoded as one XML document with the > root element . For each parameter there is a > corresponding sub-element with the parameter name containing the > respectives parameters value. >=20 > For example: >=20 > HTTP/1.1 200 OK > Content-Type: text/xml >=20 > > SlAV32hkKG > 3600 > 8xLOxBtZp8 > >=20 > "application/x-www-form-urlencoded": parameters are encoded as > name/value pairs > -------- > For example: >=20 > HTTP/1.1 200 OK > Content-Type: application/x-www-form-urlencoded >=20 >=20 > access_token=3DSlAV32hkKG&expires_in=3D3600&refresh_token=3D8xLOxBtZp8 >=20 >=20 > If the request is invalid, the authorization server returns an error > message in the HTTP response body using the > -------- > the mime type as requested by the client or "application/json" > -------- > with a 400 status code (Bad Request). >=20 > The response contains the following parameter: >=20 > error > OPTIONAL. The parameter value MUST be set to either > "redirect_uri_mismatch" or "expired_verification_code" (case > sensitive). >=20 > -------- > The response format depends on the requested mime type. The response > rendering follows the rules as specified above. > -------- > For example: >=20 > -------- > HTTP/1.1 400 Bad Request > Content-Type: application/json >=20 > { "error"=3D"expired_verification_code" } >=20 > -------- > 3.5.1. User-Agent Flow > 3.5.1.1. Client Requests Authorization >=20 > In order for the end user to grant the client access, the client > sends the end user to the authorization server. The client > constructs the request URI by adding the following URI query > parameters to the user authorization endpoint URI: > > -------- > response_format > OPTIONAL. Indicates the format used to deliver token data and > errors to the client. The parameter value MUST be set to "text/= xml", > "application/json", or "application/x-www-form-urlencoded". > Defaults > to "application/json" if omitted. >=20 > -------- > 3.5.1.1.1. End User Grants Authorization >=20 > If the end user authorizes the access request, the authorization > server issues an access token and delivers it to the client by adding > the following parameters, using the > -------- > mime type as indicated by "response_format" > -------- > to the redirection URI fragment: >=20 > access_token > REQUIRED. The access token. >=20 > expires_in > OPTIONAL. The duration in seconds of the access token > lifetime. >=20 > refresh_token > OPTIONAL. The refresh token. >=20 > state > REQUIRED if the "state" parameter was present in the client > authorization request. Set to the exact value received from > the client. >=20 > access_token_secret > REQUIRED if requested by the client. The corresponding access > token secret as requested by the client. > -------- > The way and format parameters are added to the fragment depend on the > requested mime type. >=20 > "application/json": All parameters are encoded as one flat JSON objec= t > with one key/value pair per parameter. This document is URL encoded and > added as parameter "oauth_response" to the fragment. >=20 > For example, the authorization server redirects the end user's user- > agent by sending the following HTTP response: >=20 > HTTP/1.1 302 Found > Location: > http://example.com/rd#oauth_response=3D%7B+%22access_token%22%3A+ > %22SlAV32hkKG%22%2C+%22expires_in%22%3A+%223600%22%2C+%22refr > esh_token%22%3A+%228xLOxBtZp8%22+%7D >=20 > "text/xml": All parameters are encoded as one XML document with the > root element . For each parameter there is a > corresponding sub-element with the parameter name containing the > respectives parameters value. The XML document is URL encoded and added > as parameter "oauth_response" to the fragment. >=20 > For example: >=20 > HTTP/1.1 302 Found > Location: > http://example.com/rd#oauth_response=3D%3Ctoken_response%3E%3Cacce > ss_token%3ESlAV32hkKG%3Cexpires_in%3E3600%3C%2Fexpires_in%3E%3Cr > efresh_token%3E8xLOxBtZp8%3C%2Frefresh_token%3E%3C%2Ftoken_resp > onse%3E >=20 > "application/x-www-form-urlencoded": All parameter are directly added= as > parameters to the redirection URI fragment. > -------- > For example: >=20 > HTTP/1.1 302 Found > Location: > http://example.com/rd#access_token=3DFJQbwq9&expires_in=3D3600 >=20 > 3.5.1.1.2. End User Denies Authorization >=20 > If the end user denied the access request, the authorization server > responds to the client by adding the following parameters, using the > -------- > mime type as indicated by "response_format" > -------- > to the redirection URI fragment: >=20 > error > REQUIRED. The parameter value MUST be set to "user_denied" > (case sensitive). >=20 > state > REQUIRED if the "state" parameter was present in the client > authorization request. Set to the exact value received from > the client. > -------- > The way and format parameters are added to the fragment depend on th= e > requested mime type and follows the same rules as specified above. > -------- > For example, the authorization server responds with the following: >=20 > HTTP/1.1 302 Found > Location: > http://example.com/rd#oauth_response=3D%7b+%22error%22%3d%22user% > 5fdenied%22%7d >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From pid@pidster.com Fri May 7 08:46:49 2010 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 603953A6887 for ; Fri, 7 May 2010 08:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 xtsrCkMQ3E+4 for ; Fri, 7 May 2010 08:46:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 07D333A6AC1 for ; Fri, 7 May 2010 08:46:45 -0700 (PDT) Received: by wwd20 with SMTP id 20so159645wwd.31 for ; Fri, 07 May 2010 08:46:28 -0700 (PDT) Received: by 10.227.142.210 with SMTP id r18mr224539wbu.81.1273247188085; Fri, 07 May 2010 08:46:28 -0700 (PDT) Received: from Phoenix.local (94-193-98-41.zone7.bethere.co.uk [94.193.98.41]) by mx.google.com with ESMTPS id u8sm16479033wbc.23.2010.05.07.08.46.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 08:46:27 -0700 (PDT) Message-ID: <4BE435C6.3040807@pidster.com> Date: Fri, 07 May 2010 16:46:14 +0100 From: Pid Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "oauth@ietf.org" References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20100419134825.134951nuzvi35hk4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BD2A172.2070401@lodderstedt.net> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343932484ADD@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343932484ADD@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.0.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE7734136D5393E09175B7B05" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pid@pidster.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:46:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE7734136D5393E09175B7B05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/05/2010 16:28, Eran Hammer-Lahav wrote: > This approach seems the most reasonable to me. >=20 > Server MUST support all three formats. > Client MUST support one but MAY support more formats. >=20 > This puts a little extra work on the server but since this is on the se= rializing side, no parser is needed. On the client side it adds no additi= onal complexity - it reduces it because it allows the client to work in i= ts native format (XML, JSON, text). >=20 > Those arguing for a single format have not made a compelling argument w= hy having a default format with 2 other optional formats, where the clien= t gets complete flexibility on the parsing side is bad or too complex. > > Again, for the server, this is just a single printf() statement per for= mat: >=20 > printf("{\"access_token\":\"%s\",\"expires_in\":%d}", token, expires); > printf("%s%d", token, expires); > > For the client, if they don't like the default, you can use the Accept = header or a 'format' query parameter. >=20 > Show me where this is more complex! +1 Fair enough. Flexibility via multiple formats is an entirely different proposal and one that I think is very reasonable. I just can't find a way to justify JSON as the only permitted format for response body content. p > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= >> Of Torsten Lodderstedt >> Sent: Thursday, April 29, 2010 12:46 PM >> To: Robert Sayre >> Cc: jsmarr@stanfordalumni.org; oauth@ietf.org >> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON >> (Proposal) >> >> Hi all, >> >> please find below a proposal for adding support for multiple response >> formats to the specification. I have taken the current version of the = draft >> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf= - >> oauth.txt >> and added some modifications indicated by dashed lines. Proposed chang= es >> to section 3.5.2 should be applied to 3.5.3, 3.6.1., 3.7.1., 3.7.2, an= d 4., too. >> >> Basically, the idea is that clients indicate the desired format using = Accept >> headers (default) or request parameters (User-Agent flow) and the >> response is delivered accordingly. The formats considered are >> application/json, text/xml, and application/x-www-form-urlencoded. And= as >> suggested by Joseph, parameters are encoded straight-forward as flat J= SON >> object or XML document, respectively. >> >> I would appriciate >> regards, >> Torsten. >> >> 3.5.2. Web Server Flow >> 3.5.2.2. Client Requests Access Token >> >> The client obtains an access token from the authorization server b= y >> secret_type >> OPTIONAL. The access token secret type as described by >> Section 5.3. If omitted, the authorization server will issu= e a >> bearer token (an access token without a matching secret) as >> described by Section 5.2. >> >> -------- >> A client may indicate the desired response format using an Accept-Head= er >> specifying one of the following mime types: application/x-www-form- >> urlencoded, >> application/xml, >> or application/json. If not specified, the default response format is >> application/json. >> (Alternatively, the response format could be specified by a query para= meter) >> -------- >> >> For example, the client makes the following HTTPS request (line >> breaks are for display purposes only): >> >> POST /token HTTP/1.1 >> Host: server.example.com >> Content-Type: application/x-www-form-urlencoded >> -------- >> Accept: application/json >> -------- >> >> type=3Dweb_server&client_id=3Ds6BhdRkqt3& >> client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& >> redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb >> >> >> The authorization server MUST verify that the verification code, >> client identity, client secret, and redirection URI are all valid = and >> match its stored association. If the request is valid, the >> authorization server issues an access token and delivers it to the= >> client in the HTTP response body using >> -------- >> the mime type as requested by the client or "application/json" >> -------- >> with a 200 status code (OK). >> >> The response contains the following parameters: >> >> access_token >> REQUIRED. The access token issued by the authorization serv= er. >> >> expires_in >> OPTIONAL. The duration in seconds of the access token >> lifetime. >> >> refresh_token >> OPTIONAL. The refresh token used to obtain new access token= s >> using the same end user access grant as described in Section= 4. >> >> access_token_secret >> REQUIRED if requested by the client. The corresponding acce= ss >> token secret as requested by the client. >> >> -------- >> The response format depends on the requested mime type. The >> content-type header field indicates mime type and may optionaly >> indicate charset. >> >> "application/json": All parameters are encoded as one flat JSON ob= ject >> with one key/value pair per parameter. >> >> For example: >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> >> { "access_token": "SlAV32hkKG", "expires_in": "3600", >> "refresh_token": "8xLOxBtZp8" } >> >> "text/xml": All parameters are encoded as one XML document with th= e >> root element . For each parameter there is a >> corresponding sub-element with the parameter name containing the >> respectives parameters value. >> >> For example: >> >> HTTP/1.1 200 OK >> Content-Type: text/xml >> >> >> SlAV32hkKG >> 3600 >> 8xLOxBtZp8 >> >> >> "application/x-www-form-urlencoded": parameters are encoded as >> name/value pairs >> -------- >> For example: >> >> HTTP/1.1 200 OK >> Content-Type: application/x-www-form-urlencoded >> >> >> access_token=3DSlAV32hkKG&expires_in=3D3600&refresh_token=3D8xLOxBtZp8= >> >> >> If the request is invalid, the authorization server returns an err= or >> message in the HTTP response body using the >> -------- >> the mime type as requested by the client or "application/json" >> -------- >> with a 400 status code (Bad Request). >> >> The response contains the following parameter: >> >> error >> OPTIONAL. The parameter value MUST be set to either >> "redirect_uri_mismatch" or "expired_verification_code" (case= >> sensitive). >> >> -------- >> The response format depends on the requested mime type. The respon= se >> rendering follows the rules as specified above. >> -------- >> For example: >> >> -------- >> HTTP/1.1 400 Bad Request >> Content-Type: application/json >> >> { "error"=3D"expired_verification_code" } >> >> -------- >> 3.5.1. User-Agent Flow >> 3.5.1.1. Client Requests Authorization >> >> In order for the end user to grant the client access, the client >> sends the end user to the authorization server. The client >> constructs the request URI by adding the following URI query >> parameters to the user authorization endpoint URI: >> >> -------- >> response_format >> OPTIONAL. Indicates the format used to deliver token data an= d >> errors to the client. The parameter value MUST be set to "te= xt/xml", >> "application/json", or "application/x-www-form-urlencoded". >> Defaults >> to "application/json" if omitted. >> >> -------- >> 3.5.1.1.1. End User Grants Authorization >> >> If the end user authorizes the access request, the authorization >> server issues an access token and delivers it to the client by add= ing >> the following parameters, using the >> -------- >> mime type as indicated by "response_format" >> -------- >> to the redirection URI fragment: >> >> access_token >> REQUIRED. The access token. >> >> expires_in >> OPTIONAL. The duration in seconds of the access token >> lifetime. >> >> refresh_token >> OPTIONAL. The refresh token. >> >> state >> REQUIRED if the "state" parameter was present in the client >> authorization request. Set to the exact value received from= >> the client. >> >> access_token_secret >> REQUIRED if requested by the client. The corresponding acce= ss >> token secret as requested by the client. >> -------- >> The way and format parameters are added to the fragment depend on = the >> requested mime type. >> >> "application/json": All parameters are encoded as one flat JSON ob= ject >> with one key/value pair per parameter. This document is URL encoded an= d >> added as parameter "oauth_response" to the fragment. >> >> For example, the authorization server redirects the end user's use= r- >> agent by sending the following HTTP response: >> >> HTTP/1.1 302 Found >> Location: >> http://example.com/rd#oauth_response=3D%7B+%22access_token%22%3A+ >> %22SlAV32hkKG%22%2C+%22expires_in%22%3A+%223600%22%2C+%22refr >> esh_token%22%3A+%228xLOxBtZp8%22+%7D >> >> "text/xml": All parameters are encoded as one XML document with th= e >> root element . For each parameter there is a >> corresponding sub-element with the parameter name containing the >> respectives parameters value. The XML document is URL encoded and adde= d >> as parameter "oauth_response" to the fragment. >> >> For example: >> >> HTTP/1.1 302 Found >> Location: >> http://example.com/rd#oauth_response=3D%3Ctoken_response%3E%3Cacce >> ss_token%3ESlAV32hkKG%3Cexpires_in%3E3600%3C%2Fexpires_in%3E%3Cr >> efresh_token%3E8xLOxBtZp8%3C%2Frefresh_token%3E%3C%2Ftoken_resp >> onse%3E >> >> "application/x-www-form-urlencoded": All parameter are directly ad= ded as >> parameters to the redirection URI fragment. >> -------- >> For example: >> >> HTTP/1.1 302 Found >> Location: >> http://example.com/rd#access_token=3DFJQbwq9&expires_in=3D3600 >> >> 3.5.1.1.2. End User Denies Authorization >> >> If the end user denied the access request, the authorization serve= r >> responds to the client by adding the following parameters, using t= he >> -------- >> mime type as indicated by "response_format" >> -------- >> to the redirection URI fragment: >> >> error >> REQUIRED. The parameter value MUST be set to "user_denied" >> (case sensitive). >> >> state >> REQUIRED if the "state" parameter was present in the client >> authorization request. Set to the exact value received from= >> the client. >> -------- >> The way and format parameters are added to the fragment depend on= the >> requested mime type and follows the same rules as specified above. >> -------- >> For example, the authorization server responds with the following:= >> >> HTTP/1.1 302 Found >> Location: >> http://example.com/rd#oauth_response=3D%7b+%22error%22%3d%22user% >> 5fdenied%22%7d >> >> _______________________________________________ >> 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 --------------enigE7734136D5393E09175B7B05 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQIVAwUBS+Q10GoM2OGpOvr9AQpqhQ/+MaONh6+ShiwjChw5UhfEeC4sn3PIqWWC NDX8+DVaP9G1c7gDDJDA0w6yyEpl/ETmrN7+r+r2S4Z+qQjiT9mdrzX5RAWvV1Mq 901vgegIP4bTD2sg4CCQssOD9mVnRD5PHHH8SLF8UPATRh0xeRgmevXr2nao2fRx rYPkBwCvqDVG8P3+AeegtLm+I/qTxMEdRZK4LzgTaqfYfB4NsVpAOjJuS0VXnO78 8Hemns2cx5TNwhWMBaxCkZOS4BYeGnaowpPOGI9WpuZazvYR531JKqALVYlquKsd hWK4gTQxy4QZCVctCZFN+pGosIbS57pxnaVzXgqnOq5ALcmwV2ORjjZp9sYakp6F Z0jAAuuJmnp1m35OYT/EUDOID70uwAZlsdROIjoDu2tkAr/ImeDpJ+EMUZfWcbyg gmTSFZPkfYKbkQq+zbDr/7Fd2p7YA8NDNG3BQmLAbO/uvHQ6J1luDeiINdT8+Mse RozC7h6RoVB8oLdFZodzzRJsrQxVDD3uPMxfnUWOTtS2l4QenNIg6QUyk3a6/Xke FGg5Y9nIMLAbEiPKP9rL28wYHrLbe8m13LF9/5BQCAKSOFqO6r4YGhsvjCN9Kg5y LhQy2WdZbf5IpyaHFt5F0JmwDL4wfGqt5LSkMeoOdDC4MbnW7XTfWL9D8dkgLcx+ mxdz8ycrcbc= =3MyV -----END PGP SIGNATURE----- --------------enigE7734136D5393E09175B7B05-- From yarong@microsoft.com Fri May 7 09:50:03 2010 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 9DAD13A688F for ; Fri, 7 May 2010 09:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.456 X-Spam-Level: X-Spam-Status: No, score=-9.456 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PRGbhsswEWuB for ; Fri, 7 May 2010 09:50:01 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 0BD093A6AD7 for ; Fri, 7 May 2010 09:49:36 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 7 May 2010 09:49:23 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi; Fri, 7 May 2010 09:49:23 -0700 From: Yaron Goland To: "pid@pidster.com" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) Thread-Index: AQHK59S4dijkuO12aUS5QP9a3egKcZJGmbGAgAAE1wD//5uEgA== Date: Fri, 7 May 2010 16:49:21 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A41DCE0@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20100419134825.134951nuzvi35hk4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BD2A172.2070401@lodderstedt.net> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343932484ADD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE435C6.3040807@pidster.com> In-Reply-To: <4BE435C6.3040807@pidster.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 07 May 2010 16:50:03 -0000 Every format we add increases the probability of failing to interoperate.=20 I believe as a working group we need to specify exactly one format and only= one format. That doesn't preclude later extensions that support more forma= ts but if our goal is interoperability then the fewer options the more like= ly we get interoperability. So please, just one format. Yaron P.S. My personal vote for that format is urlencoded but I see that as a sec= ondary issue to supporting exactly one format. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Pid > Sent: Friday, May 07, 2010 8:46 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > (Proposal) >=20 > On 07/05/2010 16:28, Eran Hammer-Lahav wrote: > > This approach seems the most reasonable to me. > > > > Server MUST support all three formats. > > Client MUST support one but MAY support more formats. > > > > This puts a little extra work on the server but since this is on the se= rializing > side, no parser is needed. On the client side it adds no additional compl= exity - > it reduces it because it allows the client to work in its native format (= XML, > JSON, text). > > > > Those arguing for a single format have not made a compelling argument > why having a default format with 2 other optional formats, where the clie= nt > gets complete flexibility on the parsing side is bad or too complex. > > > > Again, for the server, this is just a single printf() statement per for= mat: > > > > printf("{\"access_token\":\"%s\",\"expires_in\":%d}", token, expires); > > > printf("%s%d s_ > > in>", token, expires); > > > > For the client, if they don't like the default, you can use the Accept = header > or a 'format' query parameter. > > > > Show me where this is more complex! >=20 > +1 Fair enough. >=20 > Flexibility via multiple formats is an entirely different proposal and on= e that I > think is very reasonable. >=20 > I just can't find a way to justify JSON as the only permitted format for > response body content. >=20 >=20 > p >=20 >=20 > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Thursday, April 29, 2010 12:46 PM > >> To: Robert Sayre > >> Cc: jsmarr@stanfordalumni.org; oauth@ietf.org > >> Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON > >> (Proposal) > >> > >> Hi all, > >> > >> please find below a proposal for adding support for multiple response > >> formats to the specification. I have taken the current version of the > >> draft > >> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-iet > >> f- > >> oauth.txt > >> and added some modifications indicated by dashed lines. Proposed > >> changes to section 3.5.2 should be applied to 3.5.3, 3.6.1., 3.7.1., 3= .7.2, and > 4., too. > >> > >> Basically, the idea is that clients indicate the desired format using > >> Accept headers (default) or request parameters (User-Agent flow) and > >> the response is delivered accordingly. The formats considered are > >> application/json, text/xml, and application/x-www-form-urlencoded. > >> And as suggested by Joseph, parameters are encoded straight-forward > >> as flat JSON object or XML document, respectively. > >> > >> I would appriciate > >> regards, > >> Torsten. > >> > >> 3.5.2. Web Server Flow > >> 3.5.2.2. Client Requests Access Token > >> > >> The client obtains an access token from the authorization server b= y > > >> secret_type > >> OPTIONAL. The access token secret type as described by > >> Section 5.3. If omitted, the authorization server will issu= e a > >> bearer token (an access token without a matching secret) as > >> described by Section 5.2. > >> > >> -------- > >> A client may indicate the desired response format using an > >> Accept-Header specifying one of the following mime types: > >> application/x-www-form- urlencoded, application/xml, or > >> application/json. If not specified, the default response format is > >> application/json. > >> (Alternatively, the response format could be specified by a query > >> parameter) > >> -------- > >> > >> For example, the client makes the following HTTPS request (line > >> breaks are for display purposes only): > >> > >> POST /token HTTP/1.1 > >> Host: server.example.com > >> Content-Type: application/x-www-form-urlencoded > >> -------- > >> Accept: application/json > >> -------- > >> > >> type=3Dweb_server&client_id=3Ds6BhdRkqt3& > >> client_secret=3DgX1fBat3bV&code=3Di1WsRn1uB1& > >> redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > >> > >> > >> The authorization server MUST verify that the verification code, > >> client identity, client secret, and redirection URI are all valid = and > >> match its stored association. If the request is valid, the > >> authorization server issues an access token and delivers it to the > >> client in the HTTP response body using > >> -------- > >> the mime type as requested by the client or "application/json" > >> -------- > >> with a 200 status code (OK). > >> > >> The response contains the following parameters: > >> > >> access_token > >> REQUIRED. The access token issued by the authorization serv= er. > >> > >> expires_in > >> OPTIONAL. The duration in seconds of the access token > >> lifetime. > >> > >> refresh_token > >> OPTIONAL. The refresh token used to obtain new access token= s > >> using the same end user access grant as described in Section= 4. > >> > >> access_token_secret > >> REQUIRED if requested by the client. The corresponding acce= ss > >> token secret as requested by the client. > >> > >> -------- > >> The response format depends on the requested mime type. The > >> content-type header field indicates mime type and may optionaly > >> indicate charset. > >> > >> "application/json": All parameters are encoded as one flat JSON > >> object with one key/value pair per parameter. > >> > >> For example: > >> > >> HTTP/1.1 200 OK > >> Content-Type: application/json > >> > >> { "access_token": "SlAV32hkKG", "expires_in": "3600", > >> "refresh_token": "8xLOxBtZp8" } > >> > >> "text/xml": All parameters are encoded as one XML document with > >> the root element . For each parameter there is a > >> corresponding sub-element with the parameter name containing the > >> respectives parameters value. > >> > >> For example: > >> > >> HTTP/1.1 200 OK > >> Content-Type: text/xml > >> > >> > >> SlAV32hkKG > >> 3600 > >> 8xLOxBtZp8 > >> > >> > >> "application/x-www-form-urlencoded": parameters are encoded as > >> name/value pairs > >> -------- > >> For example: > >> > >> HTTP/1.1 200 OK > >> Content-Type: application/x-www-form-urlencoded > >> > >> > >> > access_token=3DSlAV32hkKG&expires_in=3D3600&refresh_token=3D8xLOxBtZp8 > >> > >> > >> If the request is invalid, the authorization server returns an err= or > >> message in the HTTP response body using the > >> -------- > >> the mime type as requested by the client or "application/json" > >> -------- > >> with a 400 status code (Bad Request). > >> > >> The response contains the following parameter: > >> > >> error > >> OPTIONAL. The parameter value MUST be set to either > >> "redirect_uri_mismatch" or "expired_verification_code" (case > >> sensitive). > >> > >> -------- > >> The response format depends on the requested mime type. The > >> response rendering follows the rules as specified above. > >> -------- > >> For example: > >> > >> -------- > >> HTTP/1.1 400 Bad Request > >> Content-Type: application/json > >> > >> { "error"=3D"expired_verification_code" } > >> > >> -------- > >> 3.5.1. User-Agent Flow > >> 3.5.1.1. Client Requests Authorization > >> > >> In order for the end user to grant the client access, the client > >> sends the end user to the authorization server. The client > >> constructs the request URI by adding the following URI query > >> parameters to the user authorization endpoint URI: > >> > >> -------- > >> response_format > >> OPTIONAL. Indicates the format used to deliver token data an= d > >> errors to the client. The parameter value MUST be set to "te= xt/xml", > >> "application/json", or "application/x-www-form-urlencoded". > >> Defaults > >> to "application/json" if omitted. > >> > >> -------- > >> 3.5.1.1.1. End User Grants Authorization > >> > >> If the end user authorizes the access request, the authorization > >> server issues an access token and delivers it to the client by add= ing > >> the following parameters, using the > >> -------- > >> mime type as indicated by "response_format" > >> -------- > >> to the redirection URI fragment: > >> > >> access_token > >> REQUIRED. The access token. > >> > >> expires_in > >> OPTIONAL. The duration in seconds of the access token > >> lifetime. > >> > >> refresh_token > >> OPTIONAL. The refresh token. > >> > >> state > >> REQUIRED if the "state" parameter was present in the client > >> authorization request. Set to the exact value received from > >> the client. > >> > >> access_token_secret > >> REQUIRED if requested by the client. The corresponding acce= ss > >> token secret as requested by the client. > >> -------- > >> The way and format parameters are added to the fragment depend on > >> the requested mime type. > >> > >> "application/json": All parameters are encoded as one flat JSON > >> object with one key/value pair per parameter. This document is URL > >> encoded and added as parameter "oauth_response" to the fragment. > >> > >> For example, the authorization server redirects the end user's use= r- > >> agent by sending the following HTTP response: > >> > >> HTTP/1.1 302 Found > >> Location: > >> > http://example.com/rd#oauth_response=3D%7B+%22access_token%22%3A+ > >> > %22SlAV32hkKG%22%2C+%22expires_in%22%3A+%223600%22%2C+%22refr > >> esh_token%22%3A+%228xLOxBtZp8%22+%7D > >> > >> "text/xml": All parameters are encoded as one XML document with > >> the root element . For each parameter there is a > >> corresponding sub-element with the parameter name containing the > >> respectives parameters value. The XML document is URL encoded and > >> added as parameter "oauth_response" to the fragment. > >> > >> For example: > >> > >> HTTP/1.1 302 Found > >> Location: > >> > http://example.com/rd#oauth_response=3D%3Ctoken_response%3E%3Cacce > >> > ss_token%3ESlAV32hkKG%3Cexpires_in%3E3600%3C%2Fexpires_in%3E%3Cr > >> > efresh_token%3E8xLOxBtZp8%3C%2Frefresh_token%3E%3C%2Ftoken_resp > >> onse%3E > >> > >> "application/x-www-form-urlencoded": All parameter are directly > added as > >> parameters to the redirection URI fragment. > >> -------- > >> For example: > >> > >> HTTP/1.1 302 Found > >> Location: > >> http://example.com/rd#access_token=3DFJQbwq9&expires_in=3D3600 > >> > >> 3.5.1.1.2. End User Denies Authorization > >> > >> If the end user denied the access request, the authorization serve= r > >> responds to the client by adding the following parameters, using > >> the > >> -------- > >> mime type as indicated by "response_format" > >> -------- > >> to the redirection URI fragment: > >> > >> error > >> REQUIRED. The parameter value MUST be set to "user_denied" > >> (case sensitive). > >> > >> state > >> REQUIRED if the "state" parameter was present in the client > >> authorization request. Set to the exact value received from > >> the client. > >> -------- > >> The way and format parameters are added to the fragment depend > >> on the requested mime type and follows the same rules as specified > above. > >> -------- > >> For example, the authorization server responds with the following: > >> > >> HTTP/1.1 302 Found > >> Location: > >> > http://example.com/rd#oauth_response=3D%7b+%22error%22%3d%22user% > >> 5fdenied%22%7d > >> > >> _______________________________________________ > >> 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 >=20 From yarong@microsoft.com Fri May 7 09:50:13 2010 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 085E63A69C8 for ; Fri, 7 May 2010 09:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.742 X-Spam-Level: X-Spam-Status: No, score=-9.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 sAvQcWNE25oG for ; Fri, 7 May 2010 09:50:09 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4D5EA3A6881 for ; Fri, 7 May 2010 09:49:52 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 7 May 2010 09:49:39 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi; Fri, 7 May 2010 09:49:39 -0700 From: Yaron Goland To: Mike Moore , OAuth WG Thread-Topic: [OAUTH-WG] application/x-www-form-urlencoded Counterproposal Thread-Index: AQHK7fb0DHbTSgptHEiCOyMGjtfxSpJGLp1g Date: Fri, 7 May 2010 16:49:38 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A41DCE9@TK5EX14MBXC117.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C4A41DCE9TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded Counterproposal 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, 07 May 2010 16:50:13 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C4A41DCE9TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Moore Sent: Friday, May 07, 2010 8:06 AM To: OAuth WG Subject: [OAUTH-WG] application/x-www-form-urlencoded Counterproposal I propose alter the spec so that the token responses are encoded with appli= cation/x-www-form-urlencoded, matching OAuth 1.0. I also propose moving the= JSON and XML support for these responses to an extension. I haven't heard an argument that convinces me that JSON adds anything over = application/x-www-form-urlencoded. It seems to be a preference and as such = can be accommodated as an extension. Thoughts? --_000_7C01E631FF4B654FA1E783F1C0265F8C4A41DCE9TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf Of Mike Moore
Sent: Friday= , May 07, 2010 8:06 AM
To: OAuth WG
Subject: [OAUTH-WG]= application/x-www-form-urlencoded Counterproposal

 

I propose alter the spec so that the token responses are encoded with app= lication/x-www-form-urlencoded, matching OAuth 1.0. I also propose moving t= he JSON and XML support for these responses to an extension.

=

 

I haven't heard an argument that convinces me that JSON adds anyt= hing over application/x-www-form-urlencoded. It seems to be a preference an= d as such can be accommodated as an extension. Thoughts?

= --_000_7C01E631FF4B654FA1E783F1C0265F8C4A41DCE9TK5EX14MBXC117r_-- From sayrer@gmail.com Fri May 7 10:26:11 2010 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 4DD603A6876 for ; Fri, 7 May 2010 10:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_40=-0.185, GB_I_LETTER=-2] 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 bCy-oeHEjFFd for ; Fri, 7 May 2010 10:26:10 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id F108E3A69C9 for ; Fri, 7 May 2010 10:24:26 -0700 (PDT) Received: by qyk11 with SMTP id 11so1886298qyk.13 for ; Fri, 07 May 2010 10:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WgvWtsIxnJMR2nmrTIpSFM8EPHrnebi+Kq9XXg4zpiA=; b=UsLoXt5BC03dDMoMf/ElQ5fCHE0ohLgE2vyG8n2cZ6NRIqik7m1xpgf7e2uU34oz5Y 50j2MG9YsP7cY3pW17L/MpbRNVAIQZbxNx09K5YJsBarSy61iEsDJQPHyea13uFQU7fW whAQHyPpE31mkyRUmYTU16shdwfd/rS2dxXJk= 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=DumYniRy27NqmyRu4e2AJYxBbZDKYWAucapwAm/zOesnwZakTA+JOxYg0LCs8lmGA8 J66vRxrYIBrB/ADdmB5iG1aQ7DufZWm6u6qUlTU74xb0o/yAUrga9O9TUp8/Qh3LQJrd j2JoIYJvX/PSs4sFaesmsTaOgoAsgiJKPx1Pg= MIME-Version: 1.0 Received: by 10.229.250.78 with SMTP id mn14mr274776qcb.16.1273253050557; Fri, 07 May 2010 10:24:10 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Fri, 7 May 2010 10:24:10 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343932484ADD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20100419134825.134951nuzvi35hk4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BD2A172.2070401@lodderstedt.net> <4BD8869A.2080403@lodderstedt.net> <4BD9E1E3.7060107@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343932484ADD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 7 May 2010 13:24:10 -0400 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 07 May 2010 17:26:11 -0000 On Fri, May 7, 2010 at 11:28 AM, Eran Hammer-Lahav wrote: > > Again, for the server, this is just a single printf() statement per format: > > printf("{\"access_token\":\"%s\",\"expires_in\":%d}", token, expires); > printf("%s%d", token, expires); > > For the client, if they don't like the default, you can use the Accept header or a 'format' query parameter. > > Show me where this is more complex! You can't actually use printf to produce this output in any quality implementation, especially if you want to support extension parameters. Using printf will get you at least three varieties of escaping bugs, so you'll need special libraries to generate each format. I think form-encoding is OK if the WG knows that these response bodies will never need to be complex, and never contain more than ASCII. If these need more than ASCII, you'll be relying on everyone to use the same (unspecified, btw) input encoding before they produce their form-encoded string. You're still going to have to spec an encoding param or make all implementations promise to use UTF-8 prior to URL encoding. Neither of those strategies will work very well. That said, the spec already has this problem elsewhere, so using JSON here won't fix it entirely. Also, adding something complex to a form-encoded response will get pretty ugly, since you'll need a namespace-like thing prepended to each field name. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From mscurtescu@google.com Fri May 7 10:57:42 2010 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 7AF343A68C2 for ; Fri, 7 May 2010 10:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.288 X-Spam-Level: X-Spam-Status: No, score=-100.288 tagged_above=-999 required=5 tests=[AWL=-0.911, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 PUbKijUp5SpL for ; Fri, 7 May 2010 10:57:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7DA5E3A6884 for ; Fri, 7 May 2010 10:57:40 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o47HvPD6017529 for ; Fri, 7 May 2010 10:57:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273255046; bh=P9JnpIa7WssxLHZrYXUYFY84TNM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=suR0lH5/bXC+NbD/v2MykVyiiRpGs74SXjh/S2ZXzsaoS4mAlL+SRiGjunu+u34GC ShDpP+7r074kCS2vHYUNg== 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:content-transfer-encoding:x-system-of-record; b=Tjb2bZtbdVG6zM2MSi6lB5e5Sh63J9pRmhCGvXa6qZYLR1SkAbzJ3PO4JOyjazRLF nugIFwqVV5YG5oux83VUw== Received: from pxi14 (pxi14.prod.google.com [10.243.27.14]) by kpbe19.cbf.corp.google.com with ESMTP id o47HvNkw008893 for ; Fri, 7 May 2010 10:57:23 -0700 Received: by pxi14 with SMTP id 14so579756pxi.6 for ; Fri, 07 May 2010 10:57:23 -0700 (PDT) Received: by 10.141.213.31 with SMTP id p31mr156007rvq.21.1273255043094; Fri, 07 May 2010 10:57:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Fri, 7 May 2010 10:57:03 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112630740C0@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112630740C0@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Fri, 7 May 2010 10:57:03 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 17:57:42 -0000 On Thu, May 6, 2010 at 6:36 PM, Manger, James H wrote: > Marius > >> Isn't this taken care of by the scope? > > I don't think so. It looks similar to Google scopes (http://code.google.c= om/apis/gdata/faq.html#AuthScopes), but nothing like Facebook scopes (http:= //developers.facebook.com/docs/authentication/permissions). > > >> I assume the requested scope is associated with the issued access token. > > I don't think we should require client apps to know all the sites a servi= ce uses for its resources (even those in a given scope) at the start of the= flow. It kills interop for clients without much service-specific knowledge= . It also constrains how services arrange (and re-arrange) their resources. > > What should a client do when, on accessing a protected resource, it is re= directed to another site? > Does it send the token to the new site? > Sometime sending the token will be dangerous =97 the other site shouldn't= see these confidential tokens (eg https://api.example.com -307-> http://cd= n.net/236423). > In other situations the token should be sent as the same service control = both sites equally (eg https://api.example.com -307-> https://account.examp= le.com). > > > As a concrete example, access the Facebook API such as https://graph.face= book.com/btaylor?metadata=3D1 and the response lists dozens of other URIs. = Most of the URI are on the same site (https://graph.facebook.com) so presum= ably a client app can send the same token. Another URI is at a related site= (http://www.facebook.com), but doesn't use TLS. Even if an app could tell = this domain was "related" it probably shouldn't send the same token. If one= of the listed connections was to an external site (eg "blog":"https://blog= .example.org") I would assume the same token should NOT be sent. > > The app needs to be given the list of sites appropriate for its token to = make these decisions safely. > > >> It is up to the sites accepting the access tokens >> (the protected resources) to verify and enforce the scope. > > A site cannot prevent a token being sent from a client app to the wrong s= ite, because the right site never sees the traffic. I see what you mean. As David commented, not sure if this is a problem in real life. The resource that the client is trying to access should not redirect to an untrusted resource which is not supposed to receive access tokens. If the resources responds with a redirect I think the client should trust that and just do it. Marius From mscurtescu@google.com Fri May 7 11:02:28 2010 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 69F143A6834 for ; Fri, 7 May 2010 11:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.629 X-Spam-Level: X-Spam-Status: No, score=-104.629 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_50=0.001, 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 8mI5WCGEteby for ; Fri, 7 May 2010 11:02:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2E19B3A65A5 for ; Fri, 7 May 2010 11:02:26 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o47I2B6O023439 for ; Fri, 7 May 2010 11:02:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273255332; bh=CiahR699ip/ou4WT8OxYVT/C+CQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pRaxNJJctOsIw1mpzRJS7IlWpHOzkR7lq/jzKnSbQyz/Fto93GmEaCbbois18AtJ9 5WurSfXcksfifvmMgfb6Q== 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=yOR3/FVZ3BIKI69mIKf8LTUVEMI1zdgxKqW17gub2qGbNeG9rxgNzeQ1SH1EA4V5V oGpBfHo4UNb/lBmwe+ahQ== Received: from pwi1 (pwi1.prod.google.com [10.241.219.1]) by kpbe19.cbf.corp.google.com with ESMTP id o47I2Aiw012997 for ; Fri, 7 May 2010 11:02:10 -0700 Received: by pwi1 with SMTP id 1so655022pwi.11 for ; Fri, 07 May 2010 11:02:10 -0700 (PDT) Received: by 10.140.247.17 with SMTP id u17mr140191rvh.151.1273255330266; Fri, 07 May 2010 11:02:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Fri, 7 May 2010 11:01:50 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> From: Marius Scurtescu Date: Fri, 7 May 2010 11:01:50 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:02:28 -0000 Returning a scope parameter with issued tokens is not a bad idea. But this, and also the sites parameter suggested by James, can both potentially be solved with a transparent token format. Such a token can make explicit the: - expiry time - scopes - sites - etc. The Simple Web Token spec goes along these lines. SWT has a parameter called Audience, which I assumed would point to the client, but it could also represent "sites". Marius On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt wrote: > Additionally, I would propose to indicate the scope associated with a token > to the client using a scope response parameter. This is especially useful > (1) if the client did not pass a scope parameter but the server decided to > associate a scope based on its policy or (2) if the user decided to > authorize a subset of the requested scope only. > Regards, > Torsten. > > > > Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt > : > > what about an additional realm response value? > > If there is a binding between realm and token, the client can decide based > on the realm attribute discovered using a WWW-Authenticate response which > token to use. > > regards, > Torsten. > > Am 07.05.2010 07:06, schrieb Manger, James H: > > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clients > being told by the server about the sites at which the secret > (cookie/password/token) can be used (and, more importantly, where is must > not be used). This occurs without requiring service-specific knowledge in > the client app. OAuth aims to replace some of these uses. > > > > HTTP Basic authentication works safely from clients with no service-specific > knowledge because the client knows not to send the password it gets from the > user to other sites. > > > > HTTP Digest authentication allows a password to used to across a set of > domains specified in a WWW-Authenticate response header, but the password > will not be used at arbitrary other sites. > > > > Cookies are sent in requests to the same site, sites with the same parent, > or only https sites, depending on details from the service when setting the > cookie. > > > > > > To date, OAuth has assumed every client app has lots of service-specific > knowledge to make these choices. OAuth needs to remove the need for so much > service-specific knowledge to be as interoperable as other standard auth > mechanism, otherwise it is a poor replacement. > > > > -- > > James Manger > > > > From: David Recordon [mailto:recordond@gmail.com] > Sent: Friday, 7 May 2010 2:05 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > > > > Hey James, > > Do you have a specific example in mind where this either has been an issue > or will be an issue? Most client implementations I've seen of OAuth (and > technologies like OAuth) have a strong binding between the access token(s), > site they were issued by, and user they belong to. So I haven't heard of > this being a problem in the wild... > > > > --David > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From recordond@gmail.com Fri May 7 11:06:38 2010 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 CE47D3A65A5 for ; Fri, 7 May 2010 11:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqen-h+mP0iw for ; Fri, 7 May 2010 11:06:37 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 4FCD43A67EC for ; Fri, 7 May 2010 11:06:37 -0700 (PDT) Received: by gxk9 with SMTP id 9so997937gxk.8 for ; Fri, 07 May 2010 11:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=R6smjDGNQkcsOT649JqQN4F3k46Tlp8hFPAK+3aeGd8=; b=Ft2gTlyWCXaN1M/K5C7wkx5+pp/xEGV+qngUk9ZabKEW/rxuf+WhvWHaSy/NeXLe0t Kn5HE68SFxt164D6y5aZybXvueDZshYXp04eliJiFQB1fvo+X4fkdcWEhLclPLfUmSP6 OFXZ4zztuL/ibpXwKReaY9n/ZPGQ5K4Bm1TN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BhMUdDCkihDUCSTQ6NkrnH6unH4ouGrSV+W58S61SQVxib3LQDIW6CAUgmUmBTbi7h zAZnT8r0PbbszMnBLn9ZU4epjZrBl8yaCykPNsNNAfVh3BSdKlY3GqOJYYhoaiYEKBR6 aOluqp0ErvLflSdP6aQIebuB9Zvip+fKurnPE= MIME-Version: 1.0 Received: by 10.231.166.77 with SMTP id l13mr145362iby.63.1273255579867; Fri, 07 May 2010 11:06:19 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Fri, 7 May 2010 11:06:19 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> Date: Fri, 7 May 2010 11:06:19 -0700 Message-ID: From: David Recordon To: Marius Scurtescu Content-Type: multipart/alternative; boundary=001636d33eb98bde0f048604ea95 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:06:38 -0000 --001636d33eb98bde0f048604ea95 Content-Type: text/plain; charset=ISO-8859-1 Using SWT for your access tokens seems like a reasonable way to resolve this for servers which care. On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu wrote: > Returning a scope parameter with issued tokens is not a bad idea. > > But this, and also the sites parameter suggested by James, can both > potentially be solved with a transparent token format. Such a token > can make explicit the: > - expiry time > - scopes > - sites > - etc. > > The Simple Web Token spec goes along these lines. SWT has a parameter > called Audience, which I assumed would point to the client, but it > could also represent "sites". > > Marius > > > > On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt > wrote: > > Additionally, I would propose to indicate the scope associated with a > token > > to the client using a scope response parameter. This is especially useful > > (1) if the client did not pass a scope parameter but the server decided > to > > associate a scope based on its policy or (2) if the user decided to > > authorize a subset of the requested scope only. > > Regards, > > Torsten. > > > > > > > > Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt > > : > > > > what about an additional realm response value? > > > > If there is a binding between realm and token, the client can decide > based > > on the realm attribute discovered using a WWW-Authenticate response which > > token to use. > > > > regards, > > Torsten. > > > > Am 07.05.2010 07:06, schrieb Manger, James H: > > > > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on > clients > > being told by the server about the sites at which the secret > > (cookie/password/token) can be used (and, more importantly, where is must > > not be used). This occurs without requiring service-specific knowledge in > > the client app. OAuth aims to replace some of these uses. > > > > > > > > HTTP Basic authentication works safely from clients with no > service-specific > > knowledge because the client knows not to send the password it gets from > the > > user to other sites. > > > > > > > > HTTP Digest authentication allows a password to used to across a set of > > domains specified in a WWW-Authenticate response header, but the password > > will not be used at arbitrary other sites. > > > > > > > > Cookies are sent in requests to the same site, sites with the same > parent, > > or only https sites, depending on details from the service when setting > the > > cookie. > > > > > > > > > > > > To date, OAuth has assumed every client app has lots of service-specific > > knowledge to make these choices. OAuth needs to remove the need for so > much > > service-specific knowledge to be as interoperable as other standard auth > > mechanism, otherwise it is a poor replacement. > > > > > > > > -- > > > > James Manger > > > > > > > > From: David Recordon [mailto:recordond@gmail.com] > > Sent: Friday, 7 May 2010 2:05 PM > > To: Manger, James H > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > > > > > > > > Hey James, > > > > Do you have a specific example in mind where this either has been an > issue > > or will be an issue? Most client implementations I've seen of OAuth (and > > technologies like OAuth) have a strong binding between the access > token(s), > > site they were issued by, and user they belong to. So I haven't heard of > > this being a problem in the wild... > > > > > > > > --David > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636d33eb98bde0f048604ea95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Using SWT for your access tokens seems like a reasonable way to resolve thi= s for servers which care.


On Fri, Ma= y 7, 2010 at 11:01 AM, Marius Scurtescu <mscurtescu@google.com> wrote:
Returning a scope parameter with issued tok= ens is not a bad idea.

But this, and also the sites parameter suggested by James, can both
potentially be solved with a transparent token format. Such a token
can make explicit the:
- expiry time
- scopes
- sites
- etc.

The Simple Web Token spec goes along these lines. SWT has a parameter
called Audience, which I assumed would point to the client, but it
could also represent "sites".

Marius



On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt
<torsten@lodderstedt.net&= gt; wrote:
> Additionally, I would propose to indicate the scope associated with a = token
> to the client using a scope response parameter. This is especially use= ful
> (1) if the client did not pass a scope parameter but the server decide= d to
> associate a scope based on its policy or (2) if the user decided to > authorize a subset of the requested scope only.
> Regards,
> Torsten.
>
>
>
> Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt
> <torsten@lodderstedt.net= >:
>
> what about an additional realm response value?
>
> If there is a binding between realm and token, the client can decide b= ased
> on the realm attribute discovered using a WWW-Authenticate response wh= ich
> token to use.
>
> regards,
> Torsten.
>
> Am 07.05.2010 07:06, schrieb Manger, James H:
>
> Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on c= lients
> being told by the server about the sites at which the secret
> (cookie/password/token) can be used (and, more importantly, where is m= ust
> not be used). This occurs without requiring service-specific knowledge= in
> the client app. OAuth aims to replace some of these uses.
>
>
>
> HTTP Basic authentication works safely from clients with no service-sp= ecific
> knowledge because the client knows not to send the password it gets fr= om the
> user to other sites.
>
>
>
> HTTP Digest authentication allows a password to used to across a set o= f
> domains specified in a WWW-Authenticate response header, but the passw= ord
> will not be used at arbitrary other sites.
>
>
>
> Cookies are sent in requests to the same site, sites with the same par= ent,
> or only https sites, depending on details from the service when settin= g the
> cookie.
>
>
>
>
>
> To date, OAuth has assumed every client app has lots of service-specif= ic
> knowledge to make these choices. OAuth needs to remove the need for so= much
> service-specific knowledge to be as interoperable as other standard au= th
> mechanism, otherwise it is a poor replacement.
>
>
>
> --
>
> James Manger
>
>
>
> From: David Recordon [mailto:re= cordond@gmail.com]
> Sent: Friday, 7 May 2010 2:05 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
>
>
>
> Hey James,
>
> Do you have a specific example in mind where this either has been an i= ssue
> or will be an issue? Most client implementations I've seen of OAut= h (and
> technologies like OAuth) have a strong binding between the access toke= n(s),
> site they were issued by, and user they belong to. So I haven't he= ard of
> this being a problem in the wild...
>
>
>
> --David
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001636d33eb98bde0f048604ea95-- From gbrail@sonoasystems.com Fri May 7 11:30:20 2010 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 A40173A68C2 for ; Fri, 7 May 2010 11:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.073 X-Spam-Level: X-Spam-Status: No, score=-0.073 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 OjTIgN1zMmu0 for ; Fri, 7 May 2010 11:30:19 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 1E2733A690A for ; Fri, 7 May 2010 11:30:08 -0700 (PDT) Received: by qyk11 with SMTP id 11so1967985qyk.13 for ; Fri, 07 May 2010 11:29:52 -0700 (PDT) Received: by 10.224.72.143 with SMTP id m15mr196621qaj.231.1273256985971; Fri, 07 May 2010 11:29:45 -0700 (PDT) From: Greg Brail References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <20100430105935.20255m8kdythy6sc@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723439323D0DB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE1AF25.7000308@lodderstedt.net> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> <01bb1f595f89af50b0c37c00dbcd54cd@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrtqOE4Oq2YZM9aR+2qWUdIZTCltwAaXVJQ Date: Fri, 7 May 2010 14:29:44 -0400 Message-ID: <10577de84bc497dea170055097bc0086@mail.gmail.com> To: oauth@ietf.org Content-Type: multipart/alternative; boundary=00c09f88cfaf5bd08f0486053ea9 Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 07 May 2010 18:30:20 -0000 --00c09f88cfaf5bd08f0486053ea9 Content-Type: text/plain; charset=ISO-8859-1 JSONObject is fine. I imagine that any development organization could use it in their project as long as their legal staff is willing to forgo the option of doing Evil. (That's what the license says ;-) My point is that pulling in *any* third party code is always a bigger barrier to adoption to using something that's already built in to the environment and has been for many years, so it even works in organizations that have not yet adopted the latest releases of things. (With that said, having JSON support in Python 2.6 is a good thing and it's too bad that the Java platform is moving so slowly these days.) As others have said more eloquently, if need to ever support non-string data types, arrays, or nested structures, then JSON is the best choice, over XML or something hand-rolled. But if the need is to just handle a short list of single name-value pairs, then using form-urlencoded, to me, is the simplest choice that places the fewest barriers in front of developers on all platforms. *From:* Luke Shepard [mailto:lshepard@facebook.com] *Sent:* Friday, May 07, 2010 1:48 AM *To:* Greg Brail *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) On May 6, 2010, at 9:13 AM, Greg Brail wrote: I agree that JSON is the long-term winner. However, at least for Java and Python I know that JSON parsers are not part of the standard library, whereas everything needed to decode a url-formencoded library is in the standard libraries and has been there for a long, long time. Keep in mind that the overhead of using third-party code is not just in finding and using the right library, but getting legal clearance if it's open source and you work for a big company. Python includes a JSON parser in Python 2.6: http://docs.python.org/library/json.html Java has JSONObject available. Are there cases where it would be difficult to use a library like this? --00c09f88cfaf5bd08f0486053ea9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

JSONObject is fine. I imagine that any development organization could use it in their project as long as their legal staff is willing to forgo the option of doin= g Evil. (That's what the license says ;-)

=A0

My point is that pulling in any third party code is always a bigger bar= rier to adoption to using something that's already built in to the environme= nt and has been for many years, so it even works in organizations that have not ye= t adopted the latest releases of things. (With that said, having JSON support= in Python 2.6 is a good thing and it's too bad that the Java platform is m= oving so slowly these days.)

=A0

As others have said more eloquently, if need to ever support non-string data types, arrays, or nested structures, then JSON is the best choice, over XML= or something hand-rolled. But if the need is to just handle a short list of si= ngle name-value pairs, then using form-urlencoded, to me, is the simplest choice that places the fewest barriers in front of developers on all platforms.

=A0

From: Luke She= pard [mailto:lshepard@facebook.com]=
Sent: Friday, May 07, 2010 1:48 AM
To: Greg Brail
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal)

=A0

=A0

On May 6, 2010, at 9:13 AM, Greg Brail wrote:



I agree that JSON is the long-term winner. However, at least for Java and Pyt= hon I know that JSON parsers are not part of the standard library, whereas everything needed to decode a url-formencoded library is in the standard libraries and has been there for a long, long time. Keep in mind that the overhead of using third-party code is not just in finding and using the rig= ht library, but getting legal clearance if it's open source and you work f= or a big company.

=A0

Python includes a JSON parser in Python 2.6:=A0http://docs.python.org/libr= ary/json.html=A0

=A0

Java has JSONObject available. Are there cases where= it would be difficult to use a library like this?

=A0

--00c09f88cfaf5bd08f0486053ea9-- From andrewarnott@gmail.com Fri May 7 18:11:43 2010 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 1A1EC3A67CC for ; Fri, 7 May 2010 18:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 jNkN2Fznqi-4 for ; Fri, 7 May 2010 18:11:42 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 868F23A657C for ; Fri, 7 May 2010 18:11:39 -0700 (PDT) Received: by gxk9 with SMTP id 9so1265790gxk.8 for ; Fri, 07 May 2010 18:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=O7nyWsg4dj/fjqDiZEJCfY4LRXbq91/NengiW7AJjK4=; b=XZhYAxXOxXBgBFrVZ13JsbzzM4jyGxdqq/aJSxahhJ1Pb4ZHnpe5oEAENFnqWT3G2K aVfZncE6XVzsWYmIyxy8Yd9MQJuuCxRIrinfD4D2n3g+NauxPmyJKFIgVqNb0+rYvays dgBa8vVbW932X82HdMBQV5tPeKBJ6wwogfUr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sITP3VDQ/vBbqvhMgDCYXSmBuDCwAL8hkoelRtAjBpvFofIAvfSnze/wE+3AGL+G3x wTp+JMvLjgZGjFIoau6cDauzZFIxOQnCfZv1B4PFFfmnkdhWbVItMCRpQ0YzlCL45fH8 I9gxg+ZbGjt2yGxXfMaAxz8kkiHn+i+vQK4Wc= MIME-Version: 1.0 Received: by 10.150.250.42 with SMTP id x42mr4652114ybh.193.1273281084448; Fri, 07 May 2010 18:11:24 -0700 (PDT) Received: by 10.151.105.17 with HTTP; Fri, 7 May 2010 18:11:24 -0700 (PDT) Date: Fri, 7 May 2010 18:11:24 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd6e72cbce2a904860ada92 Subject: [OAUTH-WG] Assertion flow response missing an expires_in parameter? 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, 08 May 2010 01:11:43 -0000 --000e0cd6e72cbce2a904860ada92 Content-Type: text/plain; charset=ISO-8859-1 In the assertion flow the authorization server issues an access token. In other flows, the access token is accompanied by an expires_in parameter, but not in this one according to the latest draft of the spec. Was this intentional? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --000e0cd6e72cbce2a904860ada92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the assertion flow the authorization server issues an access token.=A0 I= n other flows, the access token is accompanied by an expires_in parameter, = but not in this one according to the latest draft of the spec.
Was this = intentional?
--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre
--000e0cd6e72cbce2a904860ada92-- From sakimura@gmail.com Fri May 7 21:45:38 2010 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 66C6C3A6880 for ; Fri, 7 May 2010 21:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=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 caGzu+bx7IUJ for ; Fri, 7 May 2010 21:45:36 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9B19A3A687C for ; Fri, 7 May 2010 21:45:36 -0700 (PDT) Received: by gyh4 with SMTP id 4so1079858gyh.31 for ; Fri, 07 May 2010 21:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=o6WnrNa1O2s0CDPjoj1IAvDXcSc+n+VDnx3W1/xQlBE=; b=Zboxq108g+rt3lZTobpJumhvposbwVrp2T/fJESTV0VBqW5QJh8Q5v4gm/4DAeNMsR erN2VRODBN838uqKIiWkXfSp/b2sOeTjQ1aBpGvBcikH01Yi/1sHHkn//PxFRb4XdQmV 5XmW46GpmK3TitwaGbCr88V/h6u9XxmdI8rw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gnopmplO72YT9RAEBylT+hbQ5p1x/paoRxEV4EdrH/lYnDGP7Z/Gvtl4HR/u39MdZO E+FRE3Gh5C9L5vj6frApAayeDHmu4xV517Y48ZyzECpJbVDjgSQkDYjCYI/6aQg8kXle 2GnQn+6ooYEYap7UkTl+Zegk9tegZNyKuZL1E= MIME-Version: 1.0 Received: by 10.231.191.137 with SMTP id dm9mr407211ibb.77.1273293921105; Fri, 07 May 2010 21:45:21 -0700 (PDT) Received: by 10.231.31.10 with HTTP; Fri, 7 May 2010 21:45:21 -0700 (PDT) Date: Sat, 8 May 2010 13:45:21 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] "3.4. Client Credentials" text change proposal 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, 08 May 2010 04:45:38 -0000 3.4. Client Credentials When requesting access from the authorization server, the client identifies itself using its authorization-server-issued client credentials. The Client Credentials does not necessarily be issued by the authorization server, but may be issued by the server that authorization server trusts. Thus, I would like to propose the text change as: 3.4. Client Credentials When requesting access from the authorization server, the client identifies itself using its authorization-server-verifiable client credentials. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From James.H.Manger@team.telstra.com Sun May 9 06:13:33 2010 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 37A963A6986 for ; Sun, 9 May 2010 06:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjCUlqBmKUEQ for ; Sun, 9 May 2010 06:13:32 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 1547B3A698B for ; Sun, 9 May 2010 06:13:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,357,1270389600"; d="scan'208";a="2572069" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 09 May 2010 23:12:58 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5976"; a="1680822" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccvi.tcif.telstra.com.au with ESMTP; 09 May 2010 23:12:58 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Sun, 9 May 2010 23:12:57 +1000 From: "Manger, James H" To: Marius Scurtescu Date: Sun, 9 May 2010 23:12:52 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcruDsOXYJdp2D/2QMSKKN77rNogpgBZcyxw Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B2987@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112630740C0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {AA11A5D8-8B08-41A0-B4D7-385CF973D138} x-cr-hashedpuzzle: ACbx Ay9i Cmxi DNxg I8Yk Jeu2 KEDU KPun Lap/ NPmv Nyf7 O56Q O/aO Q1A1 Rz8A TrTz; 2; bQBzAGMAdQByAHQAZQBzAGMAdQBAAGcAbwBvAGcAbABlAC4AYwBvAG0AOwBvAGEAdQB0AGgAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {AA11A5D8-8B08-41A0-B4D7-385CF973D138}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Sun, 09 May 2010 13:12:52 GMT; UgBFADoAIABbAE8AQQBVAFQASAAtAFcARwBdACAASQBuAGQAaQBjAGEAdABpAG4AZwAgAHMAaQB0AGUAcwAgAHcAaABlAHIAZQAgAGEAIAB0AG8AawBlAG4AIABpAHMAIAB2AGEAbABpAGQA acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 13:13:33 -0000 TWFyaXVzDQoNCj4gLi4ubm90IHN1cmUgaWYgdGhpcyBpcyBhIHByb2JsZW0gaW4gcmVhbCBsaWZl Lg0KPiBUaGUgcmVzb3VyY2UgdGhhdCB0aGUgY2xpZW50IGlzIHRyeWluZyB0byBhY2Nlc3Mgc2hv dWxkIG5vdCByZWRpcmVjdA0KPiB0byBhbiB1bnRydXN0ZWQgcmVzb3VyY2Ugd2hpY2ggaXMgbm90 IHN1cHBvc2VkIHRvIHJlY2VpdmUgYWNjZXNzIHRva2Vucy4NCg0KDQpUaGlzIGlzIGEgbWFzc2l2 ZSByZXN0cmljdGlvbiBvbiB3aGF0IGEgd2ViIHNlcnZpY2UgY2FuIGRvLg0KSXQgYnJlYWtzIHRo ZSB3ZWIgaWYgYSBzZXJ2aWNlIGNhbm5vdCByZWRpcmVjdCB0byBsZXNzIHRydXN0ZWQgc2l0ZXMu DQoNCg0KQW4gc2VydmljZSBjb3VsZG4ndCByZWRpcmVjdCB0byBhIGNvbnRlbnQgZGlzdHJpYnV0 aW9uIG5ldHdvcmsgKENETikgLS0gZXZlbiBpZiB1c2luZyB1bmd1ZXNzYWJsZSBVUklzIChpZSBj YXBhYmlsaXRpZXMpIC0tIHdpdGhvdXQgZXhwb3NpbmcgdG9rZW5zIHRvIHRoZSBDRE4uDQpBZnRl ciBhY2NlcHRpbmcgYSBzZWN1cmUsIGF1dGhlbnRpY2F0ZWQgUE9TVCBhIHNlcnZpY2UgY291bGRu J3QgcmV0dXJuIGEgMzAzIHBvaW50aW5nIGF0IGFuIHN0YW5kYXJkIChwdWJsaWMpIHJlc3BvbnNl IG9uIEhUVFAgLS0gb3IgdGhlIHRva2VuIHdvdWxkIGJlIGV4cG9zZWQgaW4gdGhlIGNsZWFyLg0K R29vZ2xlIGNvdWxkbid0IG9mZmVyIGl0cyAiSSdtIGZlZWxpbmcgbHVja3kiIGludGVyZmFjZSB0 byBhcHBzLg0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From James.H.Manger@team.telstra.com Sun May 9 06:52:04 2010 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 184B43A697B for ; Sun, 9 May 2010 06:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.362 X-Spam-Level: * X-Spam-Status: No, score=1.362 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujqI9WS+qWkP for ; Sun, 9 May 2010 06:52:03 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 2D2CE3A6985 for ; Sun, 9 May 2010 06:52:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,357,1270389600"; d="scan'208,217";a="2242707" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 09 May 2010 23:51:49 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5976"; a="1719833" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbni.tcif.telstra.com.au with ESMTP; 09 May 2010 23:51:49 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Sun, 9 May 2010 23:51:48 +1000 From: "Manger, James H" To: David Recordon , Marius Scurtescu Date: Sun, 9 May 2010 23:51:47 +1000 Thread-Topic: [OAUTH-WG] SWT for indicating sites where a token is valid Thread-Index: AcruEAWfJhP+3wNfTR+xH2TSKo7YjQBaVOZg Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112631B2989WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] SWT for indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 13:52:04 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112631B2989WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQgJiBNYXJpdXMsDQoNCg0KDQo+IFVzaW5nIFNXVCBmb3IgeW91ciBhY2Nlc3MgdG9rZW5z IHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHdheSB0byByZXNvbHZlIHRoaXMgZm9yIHNlcnZlcnMg d2hpY2ggY2FyZS4NCg0KDQoNClNXVCBpcyBjb21wbGV0ZWx5IHRoZSB3cm9uZyBzb2x1dGlvbiBm b3IgdGhpcyBpc3N1ZSwgaWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseS4NCg0KDQoNCkkgaGF2 ZW7igJl0IGZvbGxvd2VkIHRoZSBTV1Qgd29yayBtdWNoLCBidXQgbXkgdW5kZXJzdGFuZGluZyBp cyB0aGF0IGl0IGFpZHMgaW50ZXJvcCBiZXR3ZWVuIGF1dGhvcml6YXRpb24gYW5kIHJlc291cmNl IHNlcnZlcnMgYnkgZGVmaW5pbmcgYSB0b2tlbiBmb3JtYXQuIEEgY3J1Y2lhbCBmZWF0dXJlIGlz IGEgTUFDLCBjcmVhdGVkIGJ5IHRoZSBhdXRoeiBzZXJ2ZXIgYW5kIHZlcmlmaWVkIGJ5IHRoZSBy ZXNvdXJjZSBzZXJ2ZXIuDQoNCg0KDQpBIGNsaWVudCBhcHAgY2Fubm90IGhhdmUgdGhlIHNlY3Jl dCBrZXkgcmVxdWlyZWQgdG8gdmVyaWZ5IHRoZSBzaWduYXR1cmUgKE1BQykgaW4gYSBTV1QgdG9r ZW4uIFNXVCBpcyBzZXBhcmF0ZSBmcm9tIFdSQVAgKCYgT0F1dGgpIGJlY2F1c2UgaXQgaXMgYSBw cml2YXRlIG1hdHRlciBiZXR3ZWVuIHNlcnZlcnMgLS0gd2hpY2ggdGhlIGNsaWVudCBkb2VzIG5v dCBoYXZlIHRvIGtub3cgYW55dGhpbmcgYWJvdXQuDQoNCg0KDQpUaGUgY29tbW9uYWxpdHkgYmV0 d2VlbiB0aGlzIGlzc3VlICjigJxzaXRlc+KAnSB0b2tlbiByZXNwb25zZSBwYXJhbSkgYW5kIFNX VCBpcyB0aGF0IGNsaWVudCBhcHBzIGFuZCByZXNvdXJjZSBzZXJ2ZXJzIG5lZWQgdG8ga25vdyBz b21lIHNpbWlsYXIgaW5mb3JtYXRpb24gYWJvdXQgYSB0b2tlbjogc3VjaCBhcyB3aGVyZSAmIHdo ZW4gaXQgY2FuIGJlIHVzZWQuDQoNCg0KDQpUaGVvcmV0aWNhbGx5IEkgZ3Vlc3Mgd2UgY291bGQg bWFuZGF0ZSBzb21ldGhpbmcgbGlrZSBTV1QgKGZsZXNoZWQgb3V0IHdpdGggc3BlY2lmaWNzKSBm b3IgdG9rZW5zIHNvIGNsaWVudHMgYW5kIHJlc291cmNlIHNlcnZlcnMgY2FuIGdldCB0aGUgaW5m byB0aGV5IG5lZWQgZnJvbSB0aGUgc2FtZSBmaWVsZCAqaW4qIHRoZSB0b2tlbi4gSG93ZXZlciwg dG9rZW5zIHRoYXQgYXJlIG9wYXF1ZSB0byBjbGllbnRzICh3aXRoIHRoZSBpbmZvIHRoZXkgbmVl ZCBpbiBzZXBhcmF0ZSBmaWVsZHMpIGlzIGEgbXVjaCBiZXR0ZXIgYXJjaGl0ZWN0dXJlIChsZXNz IGNvdXBsaW5nKSwgZXZlbiBpZiBzb21lIGluZm8gZ2V0cyByZXBlYXRlZC4NCg0KDQoNCg0KDQpQ LlMuIEkgZm91bmQgU1dULXYwLjkuNSBhdCBodHRwOi8vZ3JvdXBzLmdvb2dsZS5jb20vZ3JvdXAv b2F1dGgtd3JhcC13Zy9maWxlcy4NCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQoNCg0KRnJv bTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBEYXZpZCBSZWNvcmRvbg0KU2VudDogU2F0dXJkYXksIDggTWF5IDIwMTAg NDowNiBBTQ0KVG86IE1hcml1cyBTY3VydGVzY3UNCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gSW5kaWNhdGluZyBzaXRlcyB3aGVyZSBhIHRva2VuIGlzIHZhbGlkDQoNCg0K DQpVc2luZyBTV1QgZm9yIHlvdXIgYWNjZXNzIHRva2VucyBzZWVtcyBsaWtlIGEgcmVhc29uYWJs ZSB3YXkgdG8gcmVzb2x2ZSB0aGlzIGZvciBzZXJ2ZXJzIHdoaWNoIGNhcmUuDQoNCg0KDQpPbiBG cmksIE1heSA3LCAyMDEwIGF0IDExOjAxIEFNLCBNYXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1 QGdvb2dsZS5jb208bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpSZXR1 cm5pbmcgYSBzY29wZSBwYXJhbWV0ZXIgd2l0aCBpc3N1ZWQgdG9rZW5zIGlzIG5vdCBhIGJhZCBp ZGVhLg0KDQpCdXQgdGhpcywgYW5kIGFsc28gdGhlIHNpdGVzIHBhcmFtZXRlciBzdWdnZXN0ZWQg YnkgSmFtZXMsIGNhbiBib3RoDQpwb3RlbnRpYWxseSBiZSBzb2x2ZWQgd2l0aCBhIHRyYW5zcGFy ZW50IHRva2VuIGZvcm1hdC4gU3VjaCBhIHRva2VuDQpjYW4gbWFrZSBleHBsaWNpdCB0aGU6DQot IGV4cGlyeSB0aW1lDQotIHNjb3Blcw0KLSBzaXRlcw0KLSBldGMuDQoNClRoZSBTaW1wbGUgV2Vi IFRva2VuIHNwZWMgZ29lcyBhbG9uZyB0aGVzZSBsaW5lcy4gU1dUIGhhcyBhIHBhcmFtZXRlcg0K Y2FsbGVkIEF1ZGllbmNlLCB3aGljaCBJIGFzc3VtZWQgd291bGQgcG9pbnQgdG8gdGhlIGNsaWVu dCwgYnV0IGl0DQpjb3VsZCBhbHNvIHJlcHJlc2VudCAic2l0ZXMiLg0KDQpNYXJpdXMNCg0KDQoN Cg== --_000_255B9BB34FB7D647A506DC292726F6E112631B2989WSMSG3153Vsrv_ 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 CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5EYXZpZCAmYW1wOyBNYXJpdXMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPC9zcGFuPlVzaW5nIFNXVCBm b3IgeW91ciBhY2Nlc3MgdG9rZW5zIHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHdheSB0byByZXNv bHZlIHRoaXMgZm9yIHNlcnZlcnMgd2hpY2ggY2FyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlNXVCBpcyBjb21wbGV0ZWx5 IHRoZSB3cm9uZyBzb2x1dGlvbiBmb3IgdGhpcyBpc3N1ZSwgaWYgSSB1bmRlcnN0YW5kIGl0IGNv cnJlY3RseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JIGhhdmVu4oCZdCBmb2xsb3dlZCB0aGUgU1dUIHdvcmsg bXVjaCwgYnV0IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdCBhaWRzIGludGVyb3AgYmV0d2Vl biBhdXRob3JpemF0aW9uIGFuZCByZXNvdXJjZSBzZXJ2ZXJzIGJ5IGRlZmluaW5nIGEgdG9rZW4g Zm9ybWF0Lg0KIEEgY3J1Y2lhbCBmZWF0dXJlIGlzIGEgTUFDLCBjcmVhdGVkIGJ5IHRoZSBhdXRo eiBzZXJ2ZXIgYW5kIHZlcmlmaWVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3 RCI+QSBjbGllbnQgYXBwIGNhbm5vdCBoYXZlIHRoZSBzZWNyZXQga2V5IHJlcXVpcmVkIHRvIHZl cmlmeSB0aGUgc2lnbmF0dXJlIChNQUMpIGluIGEgU1dUIHRva2VuLiBTV1QgaXMgc2VwYXJhdGUg ZnJvbSBXUkFQICgmYW1wOyBPQXV0aCkgYmVjYXVzZSBpdCBpcyBhIHByaXZhdGUNCiBtYXR0ZXIg YmV0d2VlbiBzZXJ2ZXJzIC0tIHdoaWNoIHRoZSBjbGllbnQgZG9lcyBub3QgaGF2ZSB0byBrbm93 IGFueXRoaW5nIGFib3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlRoZSBjb21tb25hbGl0eSBiZXR3ZWVuIHRo aXMgaXNzdWUgKOKAnHNpdGVz4oCdIHRva2VuIHJlc3BvbnNlIHBhcmFtKSBhbmQgU1dUIGlzIHRo YXQgY2xpZW50IGFwcHMgYW5kIHJlc291cmNlIHNlcnZlcnMgbmVlZCB0byBrbm93IHNvbWUgc2lt aWxhciBpbmZvcm1hdGlvbiBhYm91dA0KIGEgdG9rZW46IHN1Y2ggYXMgd2hlcmUgJmFtcDsgd2hl biBpdCBjYW4gYmUgdXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5UaGVvcmV0aWNhbGx5IEkgZ3Vlc3Mgd2Ug Y291bGQgbWFuZGF0ZSBzb21ldGhpbmcgbGlrZSBTV1QgKGZsZXNoZWQgb3V0IHdpdGggc3BlY2lm aWNzKSBmb3IgdG9rZW5zIHNvIGNsaWVudHMgYW5kIHJlc291cmNlIHNlcnZlcnMgY2FuIGdldCB0 aGUgaW5mbyB0aGV5IG5lZWQNCiBmcm9tIHRoZSBzYW1lIGZpZWxkICo8Yj5pbjwvYj4qIHRoZSB0 b2tlbi4gSG93ZXZlciwgdG9rZW5zIHRoYXQgYXJlIG9wYXF1ZSB0byBjbGllbnRzICh3aXRoIHRo ZSBpbmZvIHRoZXkgbmVlZCBpbiBzZXBhcmF0ZSBmaWVsZHMpIGlzIGEgbXVjaCBiZXR0ZXIgYXJj aGl0ZWN0dXJlIChsZXNzIGNvdXBsaW5nKSwgZXZlbiBpZiBzb21lIGluZm8gZ2V0cyByZXBlYXRl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Q LlMuIEkgZm91bmQgU1dULXYwLjkuNSBhdA0KPGEgaHJlZj0iaHR0cDovL2dyb3Vwcy5nb29nbGUu Y29tL2dyb3VwL29hdXRoLXdyYXAtd2cvZmlsZXMiPmh0dHA6Ly9ncm91cHMuZ29vZ2xlLmNvbS9n cm91cC9vYXV0aC13cmFwLXdnL2ZpbGVzPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4tLQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gb2F1dGgtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkRhdmlkIFJlY29yZG9uPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCA4IE1h eSAyMDEwIDQ6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcml1cyBTY3VydGVzY3U8YnI+DQo8Yj5D Yzo8L2I+IE9BdXRoIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIEluZGlj YXRpbmcgc2l0ZXMgd2hlcmUgYSB0b2tlbiBpcyB2YWxpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5Vc2luZyBTV1QgZm9yIHlvdXIgYWNjZXNzIHRva2VucyBzZWVtcyBsaWtl IGEgcmVhc29uYWJsZSB3YXkgdG8gcmVzb2x2ZSB0aGlzIGZvciBzZXJ2ZXJzIHdoaWNoIGNhcmUu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOg0KMTIuMHB0 O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBGcmksIE1heSA3 LCAyMDEwIGF0IDExOjAxIEFNLCBNYXJpdXMgU2N1cnRlc2N1ICZsdDs8YSBocmVmPSJtYWlsdG86 bXNjdXJ0ZXNjdUBnb29nbGUuY29tIj5tc2N1cnRlc2N1QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPlJldHVybmluZyBhIHNjb3BlIHBhcmFtZXRlciB3aXRoIGlzc3VlZCB0b2tlbnMg aXMgbm90IGEgYmFkIGlkZWEuPGJyPg0KPGJyPg0KQnV0IHRoaXMsIGFuZCBhbHNvIHRoZSBzaXRl cyBwYXJhbWV0ZXIgc3VnZ2VzdGVkIGJ5IEphbWVzLCBjYW4gYm90aDxicj4NCnBvdGVudGlhbGx5 IGJlIHNvbHZlZCB3aXRoIGEgdHJhbnNwYXJlbnQgdG9rZW4gZm9ybWF0LiBTdWNoIGEgdG9rZW48 YnI+DQpjYW4gbWFrZSBleHBsaWNpdCB0aGU6PGJyPg0KLSBleHBpcnkgdGltZTxicj4NCi0gc2Nv cGVzPGJyPg0KLSBzaXRlczxicj4NCi0gZXRjLjxicj4NCjxicj4NClRoZSBTaW1wbGUgV2ViIFRv a2VuIHNwZWMgZ29lcyBhbG9uZyB0aGVzZSBsaW5lcy4gU1dUIGhhcyBhIHBhcmFtZXRlcjxicj4N CmNhbGxlZCBBdWRpZW5jZSwgd2hpY2ggSSBhc3N1bWVkIHdvdWxkIHBvaW50IHRvIHRoZSBjbGll bnQsIGJ1dCBpdDxicj4NCmNvdWxkIGFsc28gcmVwcmVzZW50ICZxdW90O3NpdGVzJnF1b3Q7Ljxi cj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQpNYXJpdXM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E112631B2989WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Sun May 9 07:39:23 2010 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 2B3C33A6837 for ; Sun, 9 May 2010 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.371 X-Spam-Level: * X-Spam-Status: No, score=1.371 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B60S3nuXcX-1 for ; Sun, 9 May 2010 07:39:22 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 9F0C63A6994 for ; Sun, 9 May 2010 07:39:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,357,1270389600"; d="scan'208";a="2572898" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 10 May 2010 00:39:08 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5976"; a="1681465" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipccvi.tcif.telstra.com.au with ESMTP; 10 May 2010 00:39:08 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Mon, 10 May 2010 00:39:07 +1000 From: "Manger, James H" To: Torsten Lodderstedt Date: Mon, 10 May 2010 00:39:06 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcrtzpiOsQbVRXjrRr6B37T5syBL8gBsv8WQ Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B298B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B26DE@WSMSG3153V.srv.dir.telstra.com> <4BE3E8B4.9020909@lodderstedt.net> In-Reply-To: <4BE3E8B4.9020909@lodderstedt.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 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 14:39:23 -0000 VG9yc3RlbiwNCg0KVGhhbmtzIGZvciB5b3VyIGFuYWx5c2lzLg0KDQo+IDEpIFJlc291cmNlIHNl cnZlciBjb250cm9scyB0b2tlbiBzaXRlcyAoY29udGV4dCBvZiB0aGUgcmVhbG0gYXR0cmlidXRl KQ0KDQo+IDIpIEF1dGhvcml6YXRpb24gc2VydmVyIGNvbnRyb2xzIHRva2VuIHNpdGVzIChjb250 ZXh0IG9mIHRva2VuKQ0KDQo+IEluIG15IG9waW5pb24sICgxKSBpbXByb3ZlcyBzZWN1cml0eSBh bmQgZWFzZXMgdGhlIHByYWN0aWNhYmlsaXR5IG9mIE9BdXRoMiBpbiBzY2VuYXJpb3Mgd2l0aCBt dWx0aXBsZSBzaXRlcyBhbmQgKDIpIGlzIGEgc2lnbmlmaWNhbnQgc2VjdXJpdHkgaW1wcm92ZW1l bnQuIEkgdGhpbmssIGJvdGggc2NlbmFyaW9zIHNob3VsZCBiZSBhZGRyZXNzZWQgYnkgdGhlIFdH Lg0KDQoNClNjZW5hcmlvIDEgaXMgYmFzaWNhbGx5IGhvdyBIVFRQIERpZ2VzdCB3b3JrcyAtLSB1 c2luZyBhICJkb21haW5zIiBwYXJhbSwgd2hpY2ggaXMgYSBsaXN0IG9mIFVSSSBwcmVmaXhlcy4N Cg0KDQpJZiBhIHJlc291cmNlIHNlcnZlciBpcyBkZWxlZ2F0aW5nIHRvIGFuIGF1dGh6IHNlcnZl ciwgaXQgbWF5IGFzIHdlbGwgYWxzbyByZWx5IG9uIHRoZSBhdXRoeiBzZXJ2ZXIgdG8gaW5kaWNh dGUgInJlYWxtIiB2YWx1ZXMgdGhhdCBhcmUgZXF1aXZhbGVudCBhY3Jvc3MgbXVsdGlwbGUgcmVz b3VyY2Ugc2VydmVycy4NClRoYXQgaXMsIEkgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIHJldHVybiAi c2l0ZXMiIGFuZCAicmVhbG0iIHZhbHVlcyBpbiBhIHRva2VuIHJlc3BvbnNlIGZyb20gYW4gYXV0 aHogc2VydmVyLCBidXQgdGhhdCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIHJldHVybiAic2l0ZXMi IGluIGEgNDAxIHJlc291cmNlIHNlcnZlciByZXNwb25zZSBpbiBPQXV0aC4NCk9uZSByZXNvdXJj ZSBzZXJ2ZXIgbWF5IHdlbGwgbm90IGtub3cgYWJvdXQgYWxsIHRoZSBvdGhlciByZXNvdXJjZSBz ZXJ2ZXJzLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From root@core3.amsl.com Sun May 9 09:45:05 2010 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4EF643A6A59; Sun, 9 May 2010 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100509164502.4EF643A6A59@core3.amsl.com> Date: Sun, 9 May 2010 09:45:01 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-03.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: Sun, 09 May 2010 16:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-03.txt Pages : 50 Date : 2010-05-09 This specification describes the OAuth 2.0 protocol. OAuth provides a method for making authenticated HTTP requests using a token - an identifier used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-09093533.I-D@ietf.org> --NextPart-- From eran@hueniverse.com Sun May 9 10:12:24 2010 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 CD11D3A6A7C for ; Sun, 9 May 2010 10:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=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 rCQO4xUL3+KH for ; Sun, 9 May 2010 10:12:23 -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 2285D3A6A77 for ; Sun, 9 May 2010 10:12:20 -0700 (PDT) Received: (qmail 21076 invoked from network); 9 May 2010 17:12:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 17:12:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 May 2010 10:12:06 -0700 From: Eran Hammer-Lahav To: Brian Eaton , David Recordon Date: Sun, 9 May 2010 10:12:06 -0700 Thread-Topic: [OAUTH-WG] device profile comments Thread-Index: Acrl0rY3zOZMJVVHQ4C/UTKkqPpJMAJxz+uw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 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] device profile comments 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, 09 May 2010 17:12:25 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Monday, April 26, 2010 11:27 PM > To: David Recordon > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] device profile comments >=20 > On Thu, Apr 22, 2010 at 5:58 PM, David Recordon > wrote: > > I don't fully understand what you're proposing. The device would show > > a screen which tells the user to visit http://fb.me/xbox and enter the > > code 123456. (Or to visit http://xbox.com/fb.) Asking a user to go to > > http://goo.gl/?client_id=3Dbndi12boi1 seems like it's prone to user err= or. >=20 > Yeah, we are shooting for the exact same UX and typable URLs that you are= . > I was thinking that this would be done without requiring preregistration = at > the authorization server. That requires that the device point to a frien= dly > URL (e.g. http://xbox.com/fb), which then automatically redirects to the > authorization server with a few more bits of information tacked on to the > URL. >=20 > But, as you point out, the protocol that requires pre-registration is sim= pler. I > don't think asking manufacturers to register is a problem, either. >=20 > Proposed changes to the spec (for clarity, I don't think these change the > protocol flows.) >=20 > "The client is incapable of receiving incoming requests from the authoriz= ation > server (incapable of acting as an HTTP server). ADD: > The device manufacturer is assumed to have registered with the > authorization server. The authorization server and device manufacturer > agree on a client id used to identify the manufacturer's devices." I don't see the point. The fact that there is a client_id parameter makes t= his clear enough. This is true for all flows. > "(B) The authorization server issues a verification code, a user code, an= d > provides the end user authorization URI. ADD: The authorization URI > SHOULD be suitable for manual user entry. Authorization servers MAY > return different approval URLs for different authorization requests. (Th= ese > different approval URLs allow the user interface to be customized for > different clients.)" I added the 'suitable for manual entry' text to the parameter definition. T= he rest is stating the obvious. > New step E. >=20 > "(E) After the end user grants or denies access, the Authorization Server > MAY redirect to a callback URL previously registered for the client. If = the user > denies access, the Authorization Server must append the query parameter > "error=3Duser_denied" to the callback URL. > The callback URL can be used to provide further instructions to the user = if > necessary." If the client can receive callbacks, why use this flow? EHL From eran@hueniverse.com Sun May 9 10:26:27 2010 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 66B2A3A6A84 for ; Sun, 9 May 2010 10:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[AWL=-1.194, BAYES_50=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 C4Myy8vZTu2N for ; Sun, 9 May 2010 10:26:26 -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 7B5483A6A7C for ; Sun, 9 May 2010 10:26:26 -0700 (PDT) Received: (qmail 1551 invoked from network); 9 May 2010 17:26:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 17:26:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 9 May 2010 10:26:15 -0700 From: Eran Hammer-Lahav To: "Foiles, Doug" , OAuth WG Date: Sun, 9 May 2010 10:26:15 -0700 Thread-Topic: [OAUTH-WG] Autonomous clients and resource owners (editorial) Thread-Index: AcrmIscm/BOC6W7iSh+JMT0dgGCAkgAALcx1AAY05pAAC/rNUADksrvwAWctR9A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5DEB74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intuit.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 Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) 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, 09 May 2010 17:26:28 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Foiles, Doug > Sent: Sunday, May 02, 2010 8:41 AM > To: OAuth WG > Subject: Re: [OAUTH-WG] Autonomous clients and resource owners > (editorial) >=20 > I wanted to poke on the idea of not allowing Refresh Tokens for the > assertion flow. How not leaving this up to the server to decide a bad thing? Clearly not al= l assertions will map directly to the OAuth token and expiration, so the to= ken is already a different trust relationship. The current draft has a SHOU= LD NOT for refresh token. > And I am wondering if the assertion flow where the client is acting on be= half > of a user is on the list of things to be added??? This is a problem with the autonomous grouping, not the flow. > And I still don't see the corresponding flow in OAuth 2.0 for an OAuth 1.= 0 - 2 > Legged use case where clients are acting on behalf of a resource owner th= at > is not themselves.=A0 Will there be a flow to support this???=A0 I can ac= tually see > how another type of "end user credentials flow" would work where the > credential is something different than the username and password. No. The 1.0 2-legged use-case was really an abuse of the OAuth signature me= thod to make signed requests using a username and password (client credenti= als) instead of using Basic auth. In OAuth 2.0, you have to go through an a= dditional step: the client first uses its client credentials to get a token= (over HTTPS) and it uses that token to make requests (signed or not). EHL From eran@hueniverse.com Sun May 9 10:44:57 2010 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 B72C23A6A84 for ; Sun, 9 May 2010 10:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_50=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 6jaY8MInkxAU for ; Sun, 9 May 2010 10:44:56 -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 A5B443A69F1 for ; Sun, 9 May 2010 10:44:56 -0700 (PDT) Received: (qmail 17538 invoked from network); 9 May 2010 17:44:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 17:44:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 10:44:44 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Sun, 9 May 2010 10:44:44 -0700 Thread-Topic: [OAUTH-WG] Scope - Coming to a Consensus Thread-Index: Acrpk6vOPnVOdWKjSzqddhqyA+nnWgBJrrYwATkATnA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <60C3123B-4FCF-425C-A808-AFB4745AECC6@facebook.com> <255B9BB34FB7D647A506DC292726F6E1126277CFE7@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126277CFE7@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus 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, 09 May 2010 17:44:57 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Monday, May 03, 2010 6:24 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus >=20 > A comma is a better separator here. > Allow URIs as scopes -- as long as the chosen URIs don't have commas. Thi= s > isn't a big restriction on services. It's an odd restriction that violated the server's name space. > [If a service provider really needs to include arbitrary URIs in an autho= rization > URI they can still do so by defining another parameter, say "urls". We ar= e > barely defining any semantics for "scope" -- at least none that libraries= can > use -- so not much is lost in using a different parameter name.] All this just to use a comma separator? =20 > A space-separated list (encoded as per the transport) sounds nice at a lo= gical > level, but is just a bit unnecessarily awkward. The only place scope valu= es > appear is in an authz URI so the only encoding is URI-encoding. Are the > spaces escaped as "%20" or "+"? Even if we try to pick one answer I suspe= ct > both will occur (it depends on which part of the software builds the auth= z URI > -- ie prepare for interop glitches). > Any spaces in a URI used as a scope value needs to be %-escaped twice. It > seems unnecessary to even allow this. They would have to be encoded twice either way. Form-encoded query (accordi= ng to the HTML 4 specification) allows only '.', '_', '-', and '~' to remai= n unencoded. Everything else must be encoded including a comma. The fact th= at you can send a comma in the query doesn't make it a valid way to transmi= t form-encoded parameters. EHL From eran@hueniverse.com Sun May 9 10:56:32 2010 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 B36863A6987 for ; Sun, 9 May 2010 10:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_40=-0.185] 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 XPmX59xe7QJs for ; Sun, 9 May 2010 10:56:31 -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 D30113A688F for ; Sun, 9 May 2010 10:56:29 -0700 (PDT) Received: (qmail 4206 invoked from network); 9 May 2010 17:56:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2010 17:56:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 9 May 2010 10:56:17 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 9 May 2010 10:56:17 -0700 Thread-Topic: [OAUTH-WG] Refresh tokens security enhancement Thread-Index: AcrsiSECQXrU3wXQS9OAemKwU2hEUwDF8gAA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE06831.60105@lodderstedt.net> <4BE1C6D0.6010600@lodderstedt.net> In-Reply-To: <4BE1C6D0.6010600@lodderstedt.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: Re: [OAUTH-WG] Refresh tokens security enhancement 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, 09 May 2010 17:56:32 -0000 Draft -02 made this possible already. I added the following text: The authorization server MAY issue a new refresh token in which cas= e the client MUST NOT use the previous refresh token and replace it with the newly issued= refresh token. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Wednesday, May 05, 2010 12:28 PM > To: Marius Scurtescu > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh tokens security enhancement >=20 > Am 04.05.2010 21:44, schrieb Marius Scurtescu: > > On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt > > wrote: > > > >> Am 03.05.2010 18:55, schrieb Allen Tom: > >> > >>> Invalidating the Refresh Token (and presumably also invalidating any > >>> outstanding Access Tokens) would make sense as an option for > >>> applications that require a high level of security. However, I do > >>> not think that invalidating the Refresh Token on every Refresh > >>> request should be required in the spec - it should be an implementati= on > specific detail. > >>> > >>> > >> It could be an optional feature of the spec (as many other features). > >> > > Torsten, can you please have a look a the "explicit request for > > refresh token" thread? > > > > Would a "refresh_token_type=3Dsingle" parameter solve the above? > > > > > > Marius > > >=20 > Hi Marius, >=20 > I expected the authorization server to decide which kind of token to use. > Your proposal makes sense as well. > So the client can act according to its security requirements. If the > authorization server would like to enforce its own policy, it can detect = any > mismatch during token issuance. >=20 > Nevertheless, support for the optional "refresh_token" response parameter > of the "refresh" request is the prerequisite. >=20 > regards, > Torsten. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Doug_Foiles@intuit.com Sun May 9 13:07:38 2010 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 7CFAF3A684C for ; Sun, 9 May 2010 13:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.73 X-Spam-Level: X-Spam-Status: No, score=-3.73 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_50=0.001, 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 vqubkq0fxcxN for ; Sun, 9 May 2010 13:07:37 -0700 (PDT) Received: from mail2.intuit.com (mail2.intuit.com [12.149.175.12]) by core3.amsl.com (Postfix) with ESMTP id 0758F3A67EF for ; Sun, 9 May 2010 13:07:36 -0700 (PDT) DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Return-Path: X-OriginalArrivalTime; b=dHtZBUS4osTxQYOJmBuGcVBYBJX0qCKrOgZENvArubgz8Tca2nbQpJXo xXP8ukY1TRs7AEpUsZW505/mdChWZiHdxxvLaeB1Hl+LlC9c/Gn/dhuu/ OriQxs7IGB584JX; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Doug_Foiles@intuit.com; q=dns/txt; s=default; t=1273435646; x=1304971646; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; z=MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Subject:=20RE:=20[OAUTH-WG]=20Autonomous=20clie nts=20and=20resource=20owners=20(editorial)|Date:=20Sun, =209=20May=202010=2013:07:23=20-0700|Message-ID:=20|In-Reply-To:=20<90C41DD21FB7C64BB94121FBBC2E72343B 3AB46E0C@P3PW5EX1MB01.EX1.SECURESERVER.NET>|References: =20<5DEB74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.c orp.intuit.net> =20=20<90C41DD21FB7C64BB94121FBBC2E72343B3AB4 6E0C@P3PW5EX1MB01.EX1.SECURESERVER.NET>|From:=20"Foiles, =20Doug"=20|To:=20"Eran=20Hammer- Lahav"=20,=0D=0A=09"OAuth=20WG"=20; bh=KRG8qI1TE7LOgHXRtmco3Ru8rervLp7qKQ8mejkbfHg=; b=o3vUWDFbcu9M5HlhOWTLrPZuIXBq0MudlDWkEww88jq2G0+RQf94sJ7e M57jUDJcT59ghzj/9URkFhtKbykNpKIqMtDPtqHOo42ORku6gzOBWIpul dVWcZ3c9F3YCzkQ; X-SBRS: None X-IronPort-AV: E=Sophos;i="4.52,357,1270450800"; d="scan'208";a="183664987" Received: from relay-ex.sd.intuit.com (HELO SDGEXBH03.corp.intuit.net) ([172.17.135.77]) by mail2.sdg.ie.intuit.com with ESMTP; 09 May 2010 13:07:25 -0700 Received: from SDGEXEVS07.corp.intuit.net ([172.17.135.1]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 May 2010 13:07:25 -0700 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: Sun, 9 May 2010 13:07:23 -0700 Message-ID: In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Autonomous clients and resource owners (editorial) Thread-Index: AcrmIscm/BOC6W7iSh+JMT0dgGCAkgAALcx1AAY05pAAC/rNUADksrvwAWctR9AABTLR8A== References: <5DEB74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intuit.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Foiles, Doug" To: "Eran Hammer-Lahav" , "OAuth WG" X-OriginalArrivalTime: 09 May 2010 20:07:25.0033 (UTC) FILETIME=[3DE8C590:01CAEFB3] Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) 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, 09 May 2010 20:07:38 -0000 Thanks for addressing my questions Eran. For the Assertion Flow I would assume the lifetime of the authorization = grant would be the same with or without the refresh token support. It = doesn't seem to me like the overall lifetime of the authorization grant = would change based upon the use of the refresh token. However I certainly do see that the usefulness of the refresh token is = very questionable based upon wanting the authorization grant lifetimes = to be short for the Assertion Flow. And providing the refresh token for = this flow almost leads the resource provider in granting longer than = recommended authorization grant lifetimes ... which ultimately should be = avoided. Is this the point? Thanks. Doug =20 -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Sunday, May 09, 2010 10:26 AM To: Foiles, Doug; OAuth WG Subject: RE: [OAUTH-WG] Autonomous clients and resource owners = (editorial) > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Foiles, Doug > Sent: Sunday, May 02, 2010 8:41 AM > To: OAuth WG > Subject: Re: [OAUTH-WG] Autonomous clients and resource owners > (editorial) >=20 > I wanted to poke on the idea of not allowing Refresh Tokens for the > assertion flow. How not leaving this up to the server to decide a bad thing? Clearly not = all assertions will map directly to the OAuth token and expiration, so = the token is already a different trust relationship. The current draft = has a SHOULD NOT for refresh token. > And I am wondering if the assertion flow where the client is acting on = behalf > of a user is on the list of things to be added??? This is a problem with the autonomous grouping, not the flow. > And I still don't see the corresponding flow in OAuth 2.0 for an OAuth = 1.0 - 2 > Legged use case where clients are acting on behalf of a resource owner = that > is not themselves.=A0 Will there be a flow to support this???=A0 I can = actually see > how another type of "end user credentials flow" would work where the > credential is something different than the username and password. No. The 1.0 2-legged use-case was really an abuse of the OAuth signature = method to make signed requests using a username and password (client = credentials) instead of using Basic auth. In OAuth 2.0, you have to go = through an additional step: the client first uses its client credentials = to get a token (over HTTPS) and it uses that token to make requests = (signed or not). EHL From eran@hueniverse.com Sun May 9 13:56:56 2010 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 4B3633A68E9 for ; Sun, 9 May 2010 13:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 ILSjfgLJuwdt for ; Sun, 9 May 2010 13:56:55 -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 AC8473A6800 for ; Sun, 9 May 2010 13:56:51 -0700 (PDT) Received: (qmail 22365 invoked from network); 9 May 2010 20:56:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 20:56:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 May 2010 13:56:39 -0700 From: Eran Hammer-Lahav To: "Foiles, Doug" , OAuth WG Date: Sun, 9 May 2010 13:56:39 -0700 Thread-Topic: [OAUTH-WG] Autonomous clients and resource owners (editorial) Thread-Index: AcrmIscm/BOC6W7iSh+JMT0dgGCAkgAALcx1AAY05pAAC/rNUADksrvwAWctR9AABTLR8AACRLXg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5DEB74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intuit.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@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 Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) 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, 09 May 2010 20:56:56 -0000 > -----Original Message----- > From: Foiles, Doug [mailto:Doug_Foiles@intuit.com] > Sent: Sunday, May 09, 2010 1:07 PM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: [OAUTH-WG] Autonomous clients and resource owners > (editorial) >=20 > Thanks for addressing my questions Eran. >=20 > For the Assertion Flow I would assume the lifetime of the authorization g= rant > would be the same with or without the refresh token support. It doesn't > seem to me like the overall lifetime of the authorization grant would cha= nge > based upon the use of the refresh token. You have three expirations: - The assertion - The access token - The refresh token (if present) The authorization server can issue an access token with any expiration but = should not issue expiration later than that of the assertion. But still, th= ere is nothing to prevent that. The authorization server may issue an acces= s token with a shorter expiration than the assertion. In that case, it can = require the use of the same assertion again to get another token, or it can= issue a refresh token to accomplish the same thing. I reject the argument that the expiration policy (and getting it implemente= d correctly) has much to do with making a refresh token available to the se= rver as a tool. EHL From eran@hueniverse.com Sun May 9 14:00:55 2010 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 4B50E3A6902 for ; Sun, 9 May 2010 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-0.805, 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 ZVvLYTzRd9Fx for ; Sun, 9 May 2010 14:00:54 -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 664CE3A6800 for ; Sun, 9 May 2010 14:00:49 -0700 (PDT) Received: (qmail 2707 invoked from network); 9 May 2010 21:00:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2010 21:00:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 14:00:36 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , OAuth WG Date: Sun, 9 May 2010 14:00:36 -0700 Thread-Topic: [OAUTH-WG] explicit request for refresh token Thread-Index: Acrrun//xuKHNFDdQJOXmw2+pNS59AEAAvsA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 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 Subject: Re: [OAUTH-WG] explicit request for refresh 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, 09 May 2010 21:00:55 -0000 Seems like extra complexity for little gain. The only benefit is saving ser= ver resources when a refresh token isn't going to be used by the client, bu= t since most clients are likely to use it, the saving isn't much. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Tuesday, May 04, 2010 11:41 AM > To: OAuth WG > Subject: [OAUTH-WG] explicit request for refresh token >=20 > Currently all flows return an optional refresh token and I think it was > mentioned that the Autonomous Client flows should never return a refresh > token. >=20 > While a refresh token will probably be used in most cases by the other fl= ows, > in some cases the refresh token will be just ignored by the client. Ideal= ly in > these cases the refresh token is not issued at all. >=20 > Also, Torsten suggested that when a new access token is requested then > also a new refresh token is issued, this would allow the authorization se= rver > to detected if a refresh token was leaked and used by an attacker. Howeve= r, > this will not work in all cases. >=20 > I suggest we add a parameter to the requests that normally issues the > refresh token as a hint to the authorization server that the client wants= a > multi-use, single-use or no refresh token at all. This will be just a hin= t, the > authorization server can decide how to proceed. >=20 > For example, this parameter could look something like: > - refresh_token_type =3D [none | multi | single] >=20 > The default would be "none". "multi" is the normal refresh token and > "single" is the refresh token suggested by Torsten. >=20 > If the server does not support "single" type refresh tokens then it will = issue a > regular token and when the access token is renewed then it will not send = a > new refresh token. If for a certain flow or client the authz server does = not > want to issue refresh tokens at all then it can ignore the refresh_token_= type > request and just not issue one. If "multi" is requested then either "mult= i" or > "none" should be issued. >=20 > This refresh token type request parameter could be implemented as an > extension as well. >=20 > Thoughts? >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun May 9 14:06:55 2010 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 9F8683A68E4 for ; Sun, 9 May 2010 14:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_50=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 R43g2U9UrrQf for ; Sun, 9 May 2010 14:06:54 -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 B24E03A6822 for ; Sun, 9 May 2010 14:06:54 -0700 (PDT) Received: (qmail 31083 invoked from network); 9 May 2010 21:06:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 21:06:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 May 2010 14:06:43 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 9 May 2010 14:06:43 -0700 Thread-Topic: Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@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] Open Issues: Group Survey (respond by 5/13) 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, 09 May 2010 21:06:55 -0000 DEADLINE: 5/13 I would like to publish one more draft before our interim meeting in two we= eks (5/20). Below are two open issues we have on the list. Please reply wit= h your preference (or additional solutions) to each item. Issues with conse= nsus will be incorporated into the next draft. Those without will be discus= sed at the meeting. EHL --- 1. Server Response Format After extensive debate, we have a large group in favor of using JSON as the= only response format (current draft). We also have a smaller group but wit= h stronger feelings on the subject that JSON adds complexity with no obviou= s value. A. Form-encoded only (original draft) B. JSON only (current draft) C. JSON as default with form-encoded and XML available with an optional req= uest parameter --- 2. Client Authentication (in flows) How should the client authenticate when making token requests? The current = draft defines special request parameters for sending client credentials. So= me have argued that this is not the correct way, and that the client should= be using existing HTTP authentication schemes to accomplish that such as B= asic. A. Client authenticates by sending its credentials using special parameters= (current draft) B. Client authenticated by using HTTP Basic (or other schemes supported by = the server such as Digest) From eran@hueniverse.com Sun May 9 14:16:08 2010 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 A8C153A69C1 for ; Sun, 9 May 2010 14:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 rzsVKGOPI1FH for ; Sun, 9 May 2010 14:16:08 -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 87AA33A690A for ; Sun, 9 May 2010 14:16:00 -0700 (PDT) Received: (qmail 6327 invoked from network); 9 May 2010 21:15:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 21:15:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 14:15:49 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 9 May 2010 14:15:47 -0700 Thread-Topic: User Endpoint Thread-Index: AcrvvMs8h1y92qj0QM61kvryHnnBEQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AatQ B4e0 DTR1 DuV8 EL49 ExmP FZF8 F4Lw GbpP Hzqk H3qx H+KI JBqb JpRV Jw98 LUs6; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {35551A02-74D1-45D4-8409-5F447F163AF5}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Sun, 09 May 2010 21:15:47 GMT;VQBzAGUAcgAgAEUAbgBkAHAAbwBpAG4AdAA= x-cr-puzzleid: {35551A02-74D1-45D4-8409-5F447F163AF5} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] User Endpoint 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, 09 May 2010 21:16:08 -0000 I would like to rename the authorization endpoint to the user endpoint. Any= objections? EHL From eran@hueniverse.com Sun May 9 14:29:34 2010 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 3148B3A69CE for ; Sun, 9 May 2010 14:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.164 X-Spam-Level: X-Spam-Status: No, score=-1.164 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_50=0.001, 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 AFizgIDqLW6v for ; Sun, 9 May 2010 14:29:26 -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 144813A6800 for ; Sun, 9 May 2010 14:29:25 -0700 (PDT) Received: (qmail 7117 invoked from network); 9 May 2010 21:29:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2010 21:29:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 14:29:14 -0700 From: Eran Hammer-Lahav To: David Recordon , Marius Scurtescu Date: Sun, 9 May 2010 14:29:15 -0700 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcruEAUKwnx3j4csRMOC6KIWXd2OkQBroXOA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.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_90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1FP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 21:29:34 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1FP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The idea of embedding this information into the token is wrong. This is cle= arly token metadata and that information belongs alongside the token, just = like 'expires_in'. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= avid Recordon Sent: Friday, May 07, 2010 11:06 AM To: Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid Using SWT for your access tokens seems like a reasonable way to resolve thi= s for servers which care. On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu > wrote: Returning a scope parameter with issued tokens is not a bad idea. But this, and also the sites parameter suggested by James, can both potentially be solved with a transparent token format. Such a token can make explicit the: - expiry time - scopes - sites - etc. The Simple Web Token spec goes along these lines. SWT has a parameter called Audience, which I assumed would point to the client, but it could also represent "sites". Marius On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt > wrote: > Additionally, I would propose to indicate the scope associated with a tok= en > to the client using a scope response parameter. This is especially useful > (1) if the client did not pass a scope parameter but the server decided t= o > associate a scope based on its policy or (2) if the user decided to > authorize a subset of the requested scope only. > Regards, > Torsten. > > > > Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt > >: > > what about an additional realm response value? > > If there is a binding between realm and token, the client can decide base= d > on the realm attribute discovered using a WWW-Authenticate response which > token to use. > > regards, > Torsten. > > Am 07.05.2010 07:06, schrieb Manger, James H: > > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clie= nts > being told by the server about the sites at which the secret > (cookie/password/token) can be used (and, more importantly, where is must > not be used). This occurs without requiring service-specific knowledge in > the client app. OAuth aims to replace some of these uses. > > > > HTTP Basic authentication works safely from clients with no service-speci= fic > knowledge because the client knows not to send the password it gets from = the > user to other sites. > > > > HTTP Digest authentication allows a password to used to across a set of > domains specified in a WWW-Authenticate response header, but the password > will not be used at arbitrary other sites. > > > > Cookies are sent in requests to the same site, sites with the same parent= , > or only https sites, depending on details from the service when setting t= he > cookie. > > > > > > To date, OAuth has assumed every client app has lots of service-specific > knowledge to make these choices. OAuth needs to remove the need for so mu= ch > service-specific knowledge to be as interoperable as other standard auth > mechanism, otherwise it is a poor replacement. > > > > -- > > James Manger > > > > From: David Recordon [mailto:recordond@gmail.com] > Sent: Friday, 7 May 2010 2:05 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > > > > Hey James, > > Do you have a specific example in mind where this either has been an issu= e > or will be an issue? Most client implementations I've seen of OAuth (and > technologies like OAuth) have a strong binding between the access token(s= ), > site they were issued by, and user they belong to. So I haven't heard of > this being a problem in the wild... > > > > --David > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1FP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The idea = of embedding this information into the token is wrong. This is clearly toke= n metadata and that information belongs alongside the token, just like R= 16;expires_in’.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@i= etf.org] On Behalf Of David Recordon
Sent: Friday, May 07,= 2010 11:06 AM
To: Marius Scurtescu
Cc: OAuth WG
= Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

 

Using SWT for your access tokens seems like a reasonable way = to resolve this for servers which care.

 

On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu <mscurtescu@google.com> wrote:=

Returning a scope parameter with issued tokens is = not a bad idea.

But this, and also the sites parameter suggested by = James, can both
potentially be solved with a transparent token format. S= uch a token
can make explicit the:
- expiry time
- scopes
- sit= es
- etc.

The Simple Web Token spec goes along these lines. SWT h= as a parameter
called Audience, which I assumed would point to the clien= t, but it
could also represent "sites".

Marius

<= br>

On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt
<torsten@lodderstedt.net> wrot= e:
> Additionally, I would propose to indicate the scope associated w= ith a token
> to the client using a scope response parameter. This is= especially useful
> (1) if the client did not pass a scope parameter= but the server decided to
> associate a scope based on its policy or= (2) if the user decided to
> authorize a subset of the requested sco= pe only.
> Regards,
> Torsten.
>
>
>
> = Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt
> <torsten@lodderstedt.net>:
>
= > what about an additional realm response value?
>
> If ther= e is a binding between realm and token, the client can decide based
>= on the realm attribute discovered using a WWW-Authenticate response which<= br>> token to use.
>
> regards,
> Torsten.
>
= > Am 07.05.2010 07:06, schrieb Manger, James H:
>
> Every ex= isting use of Cookies, HTTP Basic, and HTTP Digest relies on clients
>= ; being told by the server about the sites at which the secret
> (coo= kie/password/token) can be used (and, more importantly, where is must
&g= t; not be used). This occurs without requiring service-specific knowledge i= n
> the client app. OAuth aims to replace some of these uses.
>=
>
>
> HTTP Basic authentication works safely from client= s with no service-specific
> knowledge because the client knows not t= o send the password it gets from the
> user to other sites.
>>
>
> HTTP Digest authentication allows a password to used= to across a set of
> domains specified in a WWW-Authenticate respons= e header, but the password
> will not be used at arbitrary other site= s.
>
>
>
> Cookies are sent in requests to the same= site, sites with the same parent,
> or only https sites, depending o= n details from the service when setting the
> cookie.
>
>=
>
>
>
> To date, OAuth has assumed every client ap= p has lots of service-specific
> knowledge to make these choices. OAu= th needs to remove the need for so much
> service-specific knowledge = to be as interoperable as other standard auth
> mechanism, otherwise = it is a poor replacement.
>
>
>
> --
>
>= ; James Manger
>
>
>
> From: David Recordon [mailto= :recordond@gmail.com]
> Se= nt: Friday, 7 May 2010 2:05 PM
> To: Manger, James H
> Cc: OAut= h WG
> Subject: Re: [OAUTH-WG] Indicating sites where a token is vali= d
>
>
>
> Hey James,
>
> Do you have a = specific example in mind where this either has been an issue
> or wil= l be an issue? Most client implementations I've seen of OAuth (and
> = technologies like OAuth) have a strong binding between the access token(s),=
> site they were issued by, and user they belong to. So I haven't he= ard of
> this being a problem in the wild...
>
>
><= br>> --David
>
>
>
> ___________________________= ____________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listi= nfo/oauth
>
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth<= /a>
>
> _______________________________________________
>= OAuth mailing list
> OAuth@ietf.or= g
> https://www.ietf.org/mailman/listinfo/oauth
>
>= ;
_______________________________________________
OAuth mailing list<= br>OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1FP3PW5EX1MB01E_-- From eran@hueniverse.com Sun May 9 14:30:11 2010 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 015F93A69CE for ; Sun, 9 May 2010 14:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pFAN5RQxJy9 for ; Sun, 9 May 2010 14:30:09 -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 624C13A6917 for ; Sun, 9 May 2010 14:30:09 -0700 (PDT) Received: (qmail 18261 invoked from network); 9 May 2010 21:29:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 21:29:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 May 2010 14:29:57 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , OAuth WG Date: Sun, 9 May 2010 14:29:58 -0700 Thread-Topic: Indicating sites where a token is valid Thread-Index: Acrtd+RKgxK8uGQ7RkCGWfcUzOTj/gCRtgSg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263073D6D@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_90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 21:30:11 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRkIHNvbWUgc29ydCBvZiB3aWxkY2FyZCBzdXBwb3J0IGFuZCBJIHRoaW5rIHRoaXMgbG9va3Mg Z29vZC4NCg0KRUhMDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFuZ2VyLCBKYW1lcyBIDQpTZW50OiBU aHVyc2RheSwgTWF5IDA2LCAyMDEwIDQ6NTggUE0NClRvOiBPQXV0aCBXRw0KU3ViamVjdDogW09B VVRILVdHXSBJbmRpY2F0aW5nIHNpdGVzIHdoZXJlIGEgdG9rZW4gaXMgdmFsaWQNCg0KVGhlIE9B dXRoMiBwcm90b2NvbCBkb2VzIG5vdCBpbmRpY2F0ZSB3aGVyZSBhIHRva2VuIGNhbiBiZSB1c2Vk Lg0KSXQgbmVlZHMgdG8gZG8gc28gYmVjYXVzZSBpZiBhIGNsaWVudCBhcHAgc2VuZHMgYSB0b2tl biB0byB0aGUgd3Jvbmcgc2l0ZSBpdCBkZXN0cm95cyB0aGUgc2VjdXJpdHkuDQoNCkkgc3VnZ2Vz dCBhbm90aGVyIGZpZWxkIGluIHRoZSBKU09OIHRva2VuIHJlc3BvbnNlOg0KICAic2l0ZXMiOiBb Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tIiwgImh0dHA6Ly9waG90by5leGFtcGxlLmNvbTo4MDgw Il0NCg0KSXQgd291bGQgYmUgYSBsaXN0IG9mIHNpdGVzIHdoZXJlIHRoZSB0b2tlbiBjYW4gYmUg dXNlZCwgc3BlY2lmaWVkIGJ5IHNjaGVtZTovL2hvc3RbOnBvcnRdLg0KDQpUaGUgZGVmYXVsdCB2 YWx1ZSBmb3IgdGhlIOKAnHNpdGVz4oCdIGZpZWxkIGNvdWxkIGJlIHRoZSB0b2tlbiBlbmRwb2lu dCBzaXRlIChvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBzaXRlIGlmIGEgdG9rZW4gZW5k cG9pbnQgaXNu4oCZdCB1c2VkKS4NCkZvciBpbnN0YW5jZSwgaWYgRmFjZWJvb2vigJlzIG5ldyBB UEkgdXNlcyBodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbSBmb3IgYWxsIHJlc291cmNlcywgdG9r ZW5zLCBhbmQgYXV0aG9yaXphdGlvbnMgaXQgY291bGQgb21pdCB0aGUg4oCcc2l0ZXPigJ0gZmll bGQuDQoNCg0KUC5TLiBJIHN1Z2dlc3RlZCB0aGlzIGxhc3QgbW9udGggaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDE5MjAuaHRtbCwgIHRob3Vn aCBJIG1peGVkIGluIGFkZGl0aW9uYWwgaWRlYXMgZm9yIGZvcm1hdHMgYW5kIG1lZGlhIHR5cGUg dGhhdCBhcmUgcHJvYmFibGUgYmVzdCBjb3ZlcmVkIGluIHRoZWlyIG93biB0cmVhZHMuDQoNCg0K LS0NCkphbWVzIE1hbmdlcg0KDQo= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDg0NTg3OTY1Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoyODM2NDAyMTA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxDQoJe21zby1saXN0LWlkOjE1MDg0MDM2MjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0yNjYyMDQ3NDQ7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlk OjE2NTg0NTgxNzU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02MTk5MTA0MjI7fQ0KQGxpc3Qg bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE3MTg3NzQxMTM7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0yMjc3NjIyNjA7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QWRkIHNv bWUgc29ydCBvZiB3aWxkY2FyZCBzdXBwb3J0IGFuZCBJIHRoaW5rIHRoaXMgbG9va3MgZ29vZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+TWFuZ2VyLCBKYW1lcyBIPGJyPjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgTWF5IDA2LCAyMDEwIDQ6NTggUE08YnI+PGI+VG86PC9iPiBPQXV0aCBXRzxi cj48Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBJbmRpY2F0aW5nIHNpdGVzIHdoZXJlIGEgdG9r ZW4gaXMgdmFsaWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUFVPlRoZSBPQXV0aDIgcHJvdG9jb2wgZG9lcyBub3QgaW5kaWNhdGUgd2hlcmUgYSB0b2tl biBjYW4gYmUgdXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tQVU+SXQgbmVlZHMgdG8gZG8gc28gYmVjYXVzZSBpZiBhIGNsaWVudCBhcHAg c2VuZHMgYSB0b2tlbiB0byB0aGUgd3Jvbmcgc2l0ZSBpdCBkZXN0cm95cyB0aGUgc2VjdXJpdHku PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1BVT5JIHN1Z2dlc3QgYW5vdGhlciBmaWVsZCBpbiB0aGUgSlNPTiB0b2tlbiByZXNwb25z ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t QVU+Jm5ic3A7ICZxdW90O3NpdGVzJnF1b3Q7OiBbJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9hcGku ZXhhbXBsZS5jb20iPmh0dHBzOi8vYXBpLmV4YW1wbGUuY29tPC9hPiZxdW90OywgJnF1b3Q7PGEg aHJlZj0iaHR0cDovL3Bob3RvLmV4YW1wbGUuY29tOjgwODAiPmh0dHA6Ly9waG90by5leGFtcGxl LmNvbTo4MDgwPC9hPiZxdW90O108bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPkl0IHdvdWxkIGJlIGEgbGlzdCBvZiBzaXRlcyB3 aGVyZSB0aGUgdG9rZW4gY2FuIGJlIHVzZWQsIHNwZWNpZmllZCBieSBzY2hlbWU6Ly9ob3N0Wzpw b3J0XS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUFVPlRoZSBkZWZhdWx0IHZhbHVlIGZvciB0aGUg4oCcc2l0ZXPigJ0gZmllbGQg Y291bGQgYmUgdGhlIHRva2VuIGVuZHBvaW50IHNpdGUgKG9yIHRoZSBhdXRob3JpemF0aW9uIGVu ZHBvaW50IHNpdGUgaWYgYSB0b2tlbiBlbmRwb2ludCBpc27igJl0IHVzZWQpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5Gb3IgaW5zdGFu Y2UsIGlmIEZhY2Vib29r4oCZcyBuZXcgQVBJIHVzZXMgPGEgaHJlZj0iaHR0cHM6Ly9ncmFwaC5m YWNlYm9vay5jb20iPmh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tPC9hPiBmb3IgYWxsIHJlc291 cmNlcywgdG9rZW5zLCBhbmQgYXV0aG9yaXphdGlvbnMgaXQgY291bGQgb21pdCB0aGUg4oCcc2l0 ZXPigJ0gZmllbGQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+UC5TLiBJIHN1Z2dlc3RlZCB0aGlzIGxhc3QgbW9u dGggPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMDE5MjAuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29hdXRoL2N1cnJlbnQvbXNnMDE5MjAuaHRtbDwvYT4sICZuYnNwO3Rob3VnaCBJIG1peGVkIGlu IGFkZGl0aW9uYWwgaWRlYXMgZm9yIGZvcm1hdHMgYW5kIG1lZGlhIHR5cGUgdGhhdCBhcmUgcHJv YmFibGUgYmVzdCBjb3ZlcmVkIGluIHRoZWlyIG93biB0cmVhZHMuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+LS0g PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV PkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9i b2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20P3PW5EX1MB01E_-- From torsten@lodderstedt.net Sun May 9 14:56:54 2010 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 AE02E3A6A96 for ; Sun, 9 May 2010 14:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_20=-0.74, HELO_EQ_DE=0.35] 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 kccd6FBFwX75 for ; Sun, 9 May 2010 14:56:53 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by core3.amsl.com (Postfix) with ESMTP id 8FB983A684A for ; Sun, 9 May 2010 14:56:53 -0700 (PDT) Received: from p4fff3e28.dip.t-dialin.net ([79.255.62.40] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OBEUJ-0007hh-Vq; Sun, 09 May 2010 23:56:40 +0200 Message-ID: <4BE72F91.9090705@lodderstedt.net> Date: Sun, 09 May 2010 23:56:33 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4BE06831.60105@lodderstedt.net> <4BE1C6D0.6010600@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh tokens security enhancement 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, 09 May 2010 21:56:54 -0000 Hi Eran, I cannot find this text in -02 or -03. Would you please refer my to the respective page/section? regads, Torsten. Am 09.05.2010 19:56, schrieb Eran Hammer-Lahav: > Draft -02 made this possible already. > > I added the following text: > > The authorization server MAY issue a new refresh token in which case the client MUST NOT > use the previous refresh token and replace it with the newly issued refresh token. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Wednesday, May 05, 2010 12:28 PM >> To: Marius Scurtescu >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Refresh tokens security enhancement >> >> Am 04.05.2010 21:44, schrieb Marius Scurtescu: >> >>> On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt >>> wrote: >>> >>> >>>> Am 03.05.2010 18:55, schrieb Allen Tom: >>>> >>>> >>>>> Invalidating the Refresh Token (and presumably also invalidating any >>>>> outstanding Access Tokens) would make sense as an option for >>>>> applications that require a high level of security. However, I do >>>>> not think that invalidating the Refresh Token on every Refresh >>>>> request should be required in the spec - it should be an implementation >>>>> >> specific detail. >> >>>>> >>>>> >>>> It could be an optional feature of the spec (as many other features). >>>> >>>> >>> Torsten, can you please have a look a the "explicit request for >>> refresh token" thread? >>> >>> Would a "refresh_token_type=single" parameter solve the above? >>> >>> >>> Marius >>> >>> >> Hi Marius, >> >> I expected the authorization server to decide which kind of token to use. >> Your proposal makes sense as well. >> So the client can act according to its security requirements. If the >> authorization server would like to enforce its own policy, it can detect any >> mismatch during token issuance. >> >> Nevertheless, support for the optional "refresh_token" response parameter >> of the "refresh" request is the prerequisite. >> >> regards, >> Torsten. >> >> >> _______________________________________________ >> 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 Sun May 9 14:59:23 2010 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 63F363A6A9F for ; Sun, 9 May 2010 14:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 noXjRUVL4Dym for ; Sun, 9 May 2010 14:59:22 -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 30E9E3A6A9E for ; Sun, 9 May 2010 14:59:22 -0700 (PDT) Received: (qmail 11499 invoked from network); 9 May 2010 21:59:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 May 2010 21:59:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 14:59:10 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sun, 9 May 2010 14:59:10 -0700 Thread-Topic: [OAUTH-WG] Refresh tokens security enhancement Thread-Index: AcrvwoO4wAdU/ja1RbSitzIR5hs85wAAEptw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E23@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE06831.60105@lodderstedt.net> <4BE1C6D0.6010600@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE72F91.9090705@lodderstedt.net> In-Reply-To: <4BE72F91.9090705@lodderstedt.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh tokens security enhancement 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, 09 May 2010 21:59:23 -0000 The text is in -04. -02 made the refresh token available in token refresh. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Sunday, May 09, 2010 2:57 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh tokens security enhancement >=20 > Hi Eran, >=20 > I cannot find this text in -02 or -03. Would you please refer my to the > respective page/section? >=20 > regads, > Torsten. >=20 > Am 09.05.2010 19:56, schrieb Eran Hammer-Lahav: > > Draft -02 made this possible already. > > > > I added the following text: > > > > The authorization server MAY issue a new refresh token in whic= h case > the client MUST NOT > > use the previous refresh token and replace it with the newly i= ssued > refresh token. > > > > EHL > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Wednesday, May 05, 2010 12:28 PM > >> To: Marius Scurtescu > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Refresh tokens security enhancement > >> > >> Am 04.05.2010 21:44, schrieb Marius Scurtescu: > >> > >>> On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt > >>> wrote: > >>> > >>> > >>>> Am 03.05.2010 18:55, schrieb Allen Tom: > >>>> > >>>> > >>>>> Invalidating the Refresh Token (and presumably also invalidating > >>>>> any outstanding Access Tokens) would make sense as an option for > >>>>> applications that require a high level of security. However, I do > >>>>> not think that invalidating the Refresh Token on every Refresh > >>>>> request should be required in the spec - it should be an > >>>>> implementation > >>>>> > >> specific detail. > >> > >>>>> > >>>>> > >>>> It could be an optional feature of the spec (as many other features)= . > >>>> > >>>> > >>> Torsten, can you please have a look a the "explicit request for > >>> refresh token" thread? > >>> > >>> Would a "refresh_token_type=3Dsingle" parameter solve the above? > >>> > >>> > >>> Marius > >>> > >>> > >> Hi Marius, > >> > >> I expected the authorization server to decide which kind of token to u= se. > >> Your proposal makes sense as well. > >> So the client can act according to its security requirements. If the > >> authorization server would like to enforce its own policy, it can > >> detect any mismatch during token issuance. > >> > >> Nevertheless, support for the optional "refresh_token" response > >> parameter of the "refresh" request is the prerequisite. > >> > >> regards, > >> Torsten. > >> > >> > >> _______________________________________________ > >> 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 > > >=20 From torsten@lodderstedt.net Sun May 9 15:02:07 2010 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 E49AD3A688C for ; Sun, 9 May 2010 15:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 BWXYitVL+-ln for ; Sun, 9 May 2010 15:02:06 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by core3.amsl.com (Postfix) with ESMTP id AB3883A66B4 for ; Sun, 9 May 2010 15:02:02 -0700 (PDT) Received: from p4fff3e28.dip.t-dialin.net ([79.255.62.40] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OBEZJ-0007Yp-Ck; Mon, 10 May 2010 00:01:49 +0200 Message-ID: <4BE730CC.1090607@lodderstedt.net> Date: Mon, 10 May 2010 00:01:48 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" , Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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: Sun, 09 May 2010 22:02:08 -0000 I have put together some comments/suggestions regarding the current draft. 3.2.1. Response Format The authorization server MUST include the HTTP "Cache-Control" response header field with a value of "no-store" in any response containing tokens, secrets, or other sensitive information. Would'nt it make sense to require "no-cache", too? 3.2.1.1. Access Token Response expires_in OPTIONAL. The duration in seconds of the access token lifetime. refresh_token OPTIONAL. The refresh token used to obtain new access tokens using the same end-user access grant as described in Section 6. What is the exact meaning/idea of OPTIONAL response parameters? Who actually decides to use them? The client or the authorization server or both? Is it optional to implement this feature or is it envisioned the server dynamically decides to use those parameters based on its policy? expires_in Why is there information passed back about the access tokens duration but not about the refresh tokens duration? 3.2.1.2. Error Response If the token request is invalid or unauthorized, the authorization server constructs a JSON-formatted response which includes the common parameters set as well as additional flow-specific parameters. The formatted parameters are sent to the client in the entity body of the HTTP response with a 400 status code (Bad Request). To use status code 400 for all kinds of errors is very generic from my point of view. How shall the client implement a dedicated error handling if it cannot distinguish different errors. I would suggest either to define error codes (not only messages) in the spec or to use appropriate HTTP status codes for different error conditions, e.g. 401 for unauthorized calls. 3.4. Client Credentials The client credentials include a client identifier and an OPTIONAL symmetric shared secret. What is meant by "symmetric shared secret"? I'm familiar with the term "symmetric" in the context of cryptographical algorithms only. I think "shared secret" is sufficient. 3.5. User-Agent Flow These clients cannot keep client secrets confidential and the authentication of the client is based on the user-agent's same-origin policy. Does this still hold in the context of "HTTP Origin Headers" (http://www.petefreitag.com/item/702.cfm)? BTW: Will Brian's security considerations document be updated to be in sync with the draft? 3.5.1. Client Requests Authorization If the client has previously registered a redirection URI with the authorization server, the authorization server MUST verify that the redirection URI received matches the registered URI associated with the client identifier. Does this mean equality? Or just the same base string? 3.5.1.1. End-user Grants Authorization I would suggest to use JSON encoding here, since the URI fragment is handled by a client more or less like a response result. 3.6.1.1. End-user Grants Authorization Why not call the "code" Parameter "verification_code"? It's called verification code in the text. 3.6.2. Client Requests Access Token client_secret REQUIRED if the client identifier has a matching secret. The client secret as described in Section 3.4. 1) I'm having trouble to understand the meaning of "if the client identifier has a matching secret". Is the assumption underneath that authorization servers require this secrets from all clients they have issued a secret to? What about client w/o a secret? Are they also allowed to use this flow? Or is there envisioned a dependency between the client type, clients credentials and the flows a particular client is authorized to use? I would have expected a clear policy which flows require authentication and which not. 2) I would suggest to replace the request parameter by an Authorization header. First of all because that's the way credential transmission is handled in HTTP. Moreover, it better fits with error handling. If the secret is missing or wrong, the authorization server can answer with status code 401 and a WWW-Authenticate header(s) specifiying mechanism and realms to be used by the client in order to authenticate to the server. In the long run it gives deployments more freedom to use other mechanisms than sending shared secrets as plain text over the wire. HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store {"error"="incorrect_client_credentials"} From my point of view, "redirect_uri_mismatch" and "bad_verification_code" call for status code 403, whereas "incorrect_client_credentials" is the 401 candidate. 3.7.1. Client Requests Authorization HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store {"code":"74tq5miHKB","user_code":"94248","user_uri":"http%3A%2F%2 Fwww%2Eexample%2Ecom%2Fdevice","interval"=5} Why is the user_uri URL-encoded? 3.7.2. Client Requests Access Token "authorization_declined" Why does the spec interpret a request as bad request if the user just has declined the authorization? According to rfc2616 the semantics of 400 is: "The request could not be understood by the server due to malformed syntax". The calling client did not sent a malformed request, it cannot foresee or influence this outcome. I would suggest to either use status 403 or to return status code 200 for all syntactically correct and authorized request and to use another return codes in the response body to detail the requests outcome. 4. Username and Password Flow 4.1. Client Requests Access Token As statet in this section's introduction, this flow is intended to migrate existing clients from BASIC/DIGEST to OAuth. I therefore would suggest to use excactly these HTTP authentication schemes to transfer user credentials. This would mean to remove the parameters "username" and "password" and to use Authorization headers instead. At Deutsche Telekom, we have to deal with that class of clients. Such clients have already implemented their credential handling including header manipulation. The proposed change would further simplify their migration. 6. Assertion Flow This flow is suitable when the client is acting autonomously or on behalf of the end-user (based on the content of the assertion used). Let's assume the assertion attests an end-user's identity. How shall the authorization server determine the clients identity in this case? I would suggest to add optional client_id/client_secret parameters (or an Authorization header) for that case. 7. Refreshing an Access Token I would suggest to add an optional "scope" parameter to this request. This could be used to downgrade the scope associated with a token. 8.1. The Authorization Request Header I consider the name "Token" of the authentication schema much to generic. That was also the feedback of all colleagues I talked to about the upcoming standard. Why not call it "OAuth2"? 8.2.2. Form-Encoded Body Parameter I would suggest to drop this section/feature. General note: Would it make sense to add explicit format handling to the OAuth API? If we envision authorization servers supporting more than one token format (e.g. SAML, SWT, ...), the client should given the option to request a certain format and responses returning access tokens should indicate the format of this token. The OAuth authorization header could also have an optional format attribute for the same purpose. regards, Torsten. From eran@hueniverse.com Sun May 9 15:25:36 2010 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 B5DE53A68F2 for ; Sun, 9 May 2010 15:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[AWL=-1.457, BAYES_50=0.001, J_CHICKENPOX_52=0.6] 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 WDEIoUNxNDhz for ; Sun, 9 May 2010 15:25:34 -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 D36743A6980 for ; Sun, 9 May 2010 15:25:25 -0700 (PDT) Received: (qmail 525 invoked from network); 9 May 2010 22:25:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2010 22:25:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 15:25:13 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , "OAuth WG (oauth@ietf.org)" Date: Sun, 9 May 2010 15:25:14 -0700 Thread-Topic: Comments on draft-ietf-oauth-v2-03.txt Thread-Index: Acrvwzvl4gfH9nBDTD+pipTXezR4UQAAMdhw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> In-Reply-To: <4BE730CC.1090607@lodderstedt.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: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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: Sun, 09 May 2010 22:25:36 -0000 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Sunday, May 09, 2010 3:02 PM > To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav > Subject: Comments on draft-ietf-oauth-v2-03.txt >=20 > I have put together some comments/suggestions regarding the current > draft. Well, there is already -04... :-) I messed up the section numbers in -03. > 3.2.1. Response Format >=20 > The authorization server MUST include the HTTP "Cache-Control" > response header field with a value of "no-store" in any response > containing tokens, secrets, or other sensitive information. >=20 > Would'nt it make sense to require "no-cache", too? No idea. > 3.2.1.1. Access Token Response > expires_in > OPTIONAL. The duration in seconds of the access token > lifetime. >=20 > refresh_token > OPTIONAL. The refresh token used to obtain new access tokens > using the same end-user access grant as described in Section 6. > > What is the exact meaning/idea of OPTIONAL response parameters? > Who actually decides to use them? The client or the authorization server = or > both? > Is it optional to implement this feature or is it envisioned the server > dynamically decides to use those parameters based on its policy? Optional means the server gets to decide to include them or not. I think it= is pretty clear that optional is decided by the entity constructing the me= ssage. > expires_in >=20 > Why is there information passed back about the access tokens duration but > not about the refresh tokens duration? No one asked for that. Is there interest in specifying the authorization du= ration in addition to the token duration? > 3.2.1.2. Error Response >=20 > If the token request is invalid or unauthorized, the authorization > server constructs a JSON-formatted response which includes the common > parameters set as well as additional flow-specific parameters. The > formatted parameters are sent to the client in the entity body of the > HTTP response with a 400 status code (Bad Request). >=20 > To use status code 400 for all kinds of errors is very generic from my po= int of > view. How shall the client implement a dedicated error handling if it can= not > distinguish different errors. I would suggest either to define error code= s (not > only > messages) in the spec or to use appropriate HTTP status codes for differe= nt > error conditions, e.g. 401 for unauthorized calls. It does define error codes and sends them in the 'error' parameter. > 3.4. Client Credentials >=20 > The client credentials include a client identifier and > an OPTIONAL symmetric shared secret. >=20 > What is meant by "symmetric shared secret"? I'm familiar with the term > "symmetric" in the context of cryptographical algorithms only. I think "s= hared > secret" is sufficient. Shared secret can be symmetric (password) or asymmetric (key pair). > 3.5. User-Agent Flow >=20 > These clients > cannot keep client secrets confidential and the authentication of the > client is based on the user-agent's same-origin policy. >=20 > Does this still hold in the context of "HTTP Origin Headers" > (http://www.petefreitag.com/item/702.cfm)? >=20 > BTW: Will Brian's security considerations document be updated to be in sy= nc > with the draft? Brian's document was written for WRAP. We need to write a full security rev= iew for 2.0 that is structure similarly to OAuth 1.0. > 3.5.1. Client Requests Authorization >=20 > If the client has previously registered a redirection URI with the > authorization server, the authorization server MUST verify that the > redirection URI received matches the registered URI associated with > the client identifier. >=20 > Does this mean equality? Or just the same base string? Right now it depends on the server. > 3.5.1.1. End-user Grants Authorization >=20 > I would suggest to use JSON encoding here, since the URI fragment is > handled by a client more or less like a response result. > > 3.6.1.1. End-user Grants Authorization >=20 > Why not call the "code" Parameter "verification_code"? It's called verifi= cation > code in the text. Longer for no reason. > 3.6.2. Client Requests Access Token >=20 > client_secret > REQUIRED if the client identifier has a matching secret. The > client secret as described in Section 3.4. >=20 > 1) I'm having trouble to understand the meaning of "if the client identi= fier > has a matching secret". Is the assumption underneath that authorization > servers require this secrets from all clients they have issued a secret t= o? > What about client w/o a secret? Are they also allowed to use this flow? > Or is there envisioned a dependency > between the client type, clients credentials and the flows a particular c= lient is > authorized to use? >=20 > I would have expected a clear policy which flows require authentication a= nd > which not. >=20 > 2) I would suggest to replace the request parameter by an Authorization > header. First of all because that's the way credential transmission is ha= ndled > in HTTP. Moreover, it better fits with error handling. If the secret is m= issing or > wrong, the authorization server can answer with status code 401 and a > WWW-Authenticate header(s) specifiying mechanism and realms to be used > by the client in order to authenticate to the server. >=20 > In the long run it gives deployments more freedom to use other mechanisms > than sending shared secrets as plain text over the wire. >=20 > HTTP/1.1 400 Bad Request > Content-Type: application/json > Cache-Control: no-store >=20 > {"error"=3D"incorrect_client_credentials"} >=20 > From my point of view, "redirect_uri_mismatch" and > "bad_verification_code" call for status code 403, whereas > "incorrect_client_credentials" is the 401 candidate. >=20 > 3.7.1. Client Requests Authorization > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store >=20 > {"code":"74tq5miHKB","user_code":"94248","user_uri":"http%3A%2F%2 > Fwww%2Eexample%2Ecom%2Fdevice","interval"=3D5} >=20 > Why is the user_uri URL-encoded? Conversion mistake. > 3.7.2. Client Requests Access Token >=20 > "authorization_declined" >=20 > Why does the spec interpret a request as bad request if the user just has > declined the authorization? According to rfc2616 the semantics of > 400 is: "The request could not be understood by the server due to > malformed syntax". >=20 > The calling client did not sent a malformed request, it cannot foresee or > influence this outcome. I would suggest to either use status 403 or to re= turn > status code 200 for all syntactically correct and authorized request and = to use > another return codes in the response body to detail the requests outcome. >=20 > 4. Username and Password Flow > 4.1. Client Requests Access Token >=20 > As statet in this section's introduction, this flow is intended to migrat= e > existing clients from BASIC/DIGEST to OAuth. I therefore would suggest to > use excactly these HTTP authentication schemes to transfer user credentia= ls. > This would mean to remove the parameters "username" > and "password" and to use Authorization headers instead. At Deutsche > Telekom, we have to deal with that class of clients. Such clients have al= ready > implemented their credential handling including header manipulation. The > proposed change would further simplify their migration. How would you send both client credentials and user credentials? Migration = is only one example. > 6. Assertion Flow >=20 > This flow is suitable when the client is acting autonomously or on behalf= of > the end-user (based on the content of the assertion used). >=20 > Let's assume the assertion attests an end-user's identity. How shall the > authorization server determine the clients identity in this case? I would > suggest to add optional client_id/client_secret parameters (or an > Authorization header) for that case. That's the whole point - it doesn't need it because it uses a different tru= st framework where the client identity is part of. > 7. Refreshing an Access Token >=20 > I would suggest to add an optional "scope" parameter to this request. > This could be used to downgrade the scope associated with a token. That would be the wrong way to do it given that people will expect to also = be able to upgrade scope. > 8.1. The Authorization Request Header >=20 > I consider the name "Token" of the authentication schema much to generic. > That was also the feedback of all colleagues I talked to about the upcomi= ng > standard. Why not call it "OAuth2"? It is meant to be generic. I consider OAuth to be the part of the protocol = dealing with getting a token. There will be many new ways to get a token in= the future. > 8.2.2. Form-Encoded Body Parameter >=20 > I would suggest to drop this section/feature. >=20 > General note: Would it make sense to add explicit format handling to the > OAuth API? If we envision authorization servers supporting more than one > token format (e.g. SAML, SWT, ...), the client should given the option to > request a certain format and responses returning access tokens should > indicate the format of this token. The OAuth authorization header could a= lso > have an optional format attribute for the same purpose. You mean token format? OAuth defined the token as opaque so that would be c= ounter-productive. EHL From recordond@gmail.com Sun May 9 16:14:11 2010 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 1DD3A3A694D for ; Sun, 9 May 2010 16:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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+LAjazMQ+ER for ; Sun, 9 May 2010 16:14:07 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 7B9DE3A6AAE for ; Sun, 9 May 2010 16:14:01 -0700 (PDT) Received: by gwaa12 with SMTP id a12so1677189gwa.31 for ; Sun, 09 May 2010 16:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zjgf4eoe9WEMAV2ZPDI+jnlhmOb6DswtRP0Qj6bwG80=; b=JTQRgCQvVgLvvBLeK/uVWPnGrBwAVTAZzgPavyxwxWisY9TZyANANNafBODeOZ1+O0 gXW8I0c1Nsq5JhA2OCWJba0eyU46/ViJrU8S5hch2ePq1AEvKAE3AoZBqIHnmPQR78zr 93rmS7Xo14wnLROMziaJUIV6jhAqbzX41brgE= 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=Yfe3mgJfiJ0B/8NOD5wnAzgiG9RCSWOnGXERSskl0B7yW3XlIG+2qvI9o4YOsCouZq IV1KUe/ePbpYI9zfQgjB+0gwelZrEuranO1tqyM3NkEwSX6YfweUiDRt+5yhlTwzANBC IGmbRgsHHFXyXPA6mvjfoMUqHmWAL753pbhNU= MIME-Version: 1.0 Received: by 10.231.156.19 with SMTP id u19mr1473553ibw.66.1273446826375; Sun, 09 May 2010 16:13:46 -0700 (PDT) Received: by 10.231.183.195 with HTTP; Sun, 9 May 2010 16:13:46 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 9 May 2010 16:13:46 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 09 May 2010 23:14:11 -0000 On Sun, May 9, 2010 at 2:06 PM, Eran Hammer-Lahav wro= te: > DEADLINE: 5/13 > > I would like to publish one more draft before our interim meeting in two = weeks (5/20). Below are two open issues we have on the list. Please reply w= ith your preference (or additional solutions) to each item. Issues with con= sensus will be incorporated into the next draft. Those without will be disc= ussed at the meeting. > > EHL > > --- > > 1. Server Response Format > > After extensive debate, we have a large group in favor of using JSON as t= he only response format (current draft). We also have a smaller group but w= ith stronger feelings on the subject that JSON adds complexity with no obvi= ous value. > > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional r= equest parameter It doesn't seem to make a lot of sense to require a client have a JSON parser if the API they're interacting with is XML. And conversely it doesn't make a lot of sense to require a client have a XML parser if the API they're interacting with is JSON. Given the expressed desire for JSON, I think that option C makes the most sense. Default is JSON but the client can ask for XML or form-encoded instead. > --- > > 2. Client Authentication (in flows) > > How should the client authenticate when making token requests? The curren= t draft defines special request parameters for sending client credentials. = Some have argued that this is not the correct way, and that the client shou= ld be using existing HTTP authentication schemes to accomplish that such as= Basic. > > A. Client authenticates by sending its credentials using special paramete= rs (current draft) > B. Client authenticated by using HTTP Basic (or other schemes supported b= y the server such as Digest) I'd prefer that OAuth remain as self contained as possible. Thus A. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dick.hardt@gmail.com Sun May 9 17:17:39 2010 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 607593A6ABA for ; Sun, 9 May 2010 17:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Fgu9G6GLIgCi for ; Sun, 9 May 2010 17:17:37 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 51BA73A6A7A for ; Sun, 9 May 2010 17:17:36 -0700 (PDT) Received: by pvc21 with SMTP id 21so38447pvc.31 for ; Sun, 09 May 2010 17:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=9/ZTWbjoZCNGvwmA4m1iCODc1OkinP3g5dTVAwqZioE=; b=U4prJgL33FRB1DnCoMyVa6frpIGavVfkNPSFHI8c1nVeXWSl0icmgtfVr4Kd4B+isJ CsyxDEhIbZgbtyigj06xlZ812WpufVwhxs7j60VubJ+rFzv71qfa+/bW8HVkIJIMODq8 8WyWrmV+oho02AkZHsde+1EyI1BpqHPQbx2mA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=k+xMxo1hN+Gc40cy6/Se9eeNbRCDWV9jZLoCeCT95oZ5QzlHaEALOmYP2z/GSARItP Xxpn1oUeNKzdaQVTE8D991qE5fteBrpXjCqr7zQMboCQ2tUVaJuTm1MlD8eH9hSfSy8A JxQSL1AROOzRX+FDZHy+9Ytr5PoUauAtBVGug= Received: by 10.115.38.22 with SMTP id q22mr2494654waj.41.1273450641714; Sun, 09 May 2010 17:17:21 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id n32sm22747505wae.10.2010.05.09.17.17.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 17:17:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 9 May 2010 17:17:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1F6D82E6-7544-4845-916F-7361165ADA4B@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 00:17:39 -0000 On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote: > DEADLINE: 5/13 >=20 > I would like to publish one more draft before our interim meeting in = two weeks (5/20). Below are two open issues we have on the list. Please = reply with your preference (or additional solutions) to each item. = Issues with consensus will be incorporated into the next draft. Those = without will be discussed at the meeting. >=20 > EHL >=20 > --- >=20 > 1. Server Response Format >=20 > After extensive debate, we have a large group in favor of using JSON = as the only response format (current draft). We also have a smaller = group but with stronger feelings on the subject that JSON adds = complexity with no obvious value. >=20 > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an = optional request parameter I vote for B I would argue that form-encoded data adds complexity with no obvious = value. *If* a JSON parser is not available, parsing the JSON that is returned = is not that much different from parsing form-encoded data (remember that = we are only using a very small subset of JSON) More and more sites are returning both JSON and XML. Eventually everyone = will see the light wrt. JSON ;-) >=20 > --- >=20 > 2. Client Authentication (in flows) >=20 > How should the client authenticate when making token requests? The = current draft defines special request parameters for sending client = credentials. Some have argued that this is not the correct way, and that = the client should be using existing HTTP authentication schemes to = accomplish that such as Basic. >=20 > A. Client authenticates by sending its credentials using special = parameters (current draft) > B. Client authenticated by using HTTP Basic (or other schemes = supported by the server such as Digest) C. support both flows in the spec. An AS can decide what it wants to = support. I would like to retain A as it may be challenging for some = clients to use HTTP Basic, and easier for an AS to be always parsing = parameters for each flow. I can see the advantages for some in using = HTTP Basic. -- Dick From James.H.Manger@team.telstra.com Sun May 9 17:31:49 2010 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 0ECC53A6AC2 for ; Sun, 9 May 2010 17:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.379 X-Spam-Level: * X-Spam-Status: No, score=1.379 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCL4GkCFH2J4 for ; Sun, 9 May 2010 17:31:48 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 0722E3A679C for ; Sun, 9 May 2010 17:31:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,358,1270389600"; d="scan'208";a="2591764" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 10 May 2010 10:31:30 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5977"; a="1677278" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcbvi.tcif.telstra.com.au with ESMTP; 10 May 2010 10:31:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Mon, 10 May 2010 10:31:30 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Mon, 10 May 2010 10:31:28 +1000 Thread-Topic: User Endpoint Thread-Index: AcrvvMs8h1y92qj0QM61kvryHnnBEQAFD6wg Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B2DAE@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@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] User Endpoint 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, 10 May 2010 00:31:49 -0000 PiBJIHdvdWxkIGxpa2UgdG8gcmVuYW1lIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHRvIHRo ZSB1c2VyIGVuZHBvaW50LiBBbnkgb2JqZWN0aW9ucz8NCg0KU291bmRzIG9rLiBBbiBBdXRob3Jp emF0aW9uIHNlcnZlciBvZmZlcnMgdG9rZW4gZW5kcG9pbnRzIGFuZCB1c2VyIGVuZHBvaW50cy4N Cg0KQ2FuIHdlIGNoYW5nZSAicmVzb3VyY2Ugb3duZXIiIHRvICJ1c2VyIiB3aGVyZSBhcHBsaWNh YmxlLiBIZW5jZSwgYSB1c2VyIGdldCBkaXJlY3RlZCB0byBhIHVzZXIgZW5kcG9pbnQuDQoNClN1 Z2dlc3RlZCBuZXcgdGV4dCBmb3IgMy4xICJBdXRob3JpemF0aW9uIEVuZHBvaW50IjoNCg0KIjMu MSBVc2VyIGVuZHBvaW50DQoNCiJBIGNsaWVudCBhcHAgZGlyZWN0cyBhIHVzZXIgdG8gYSB1c2Vy IGVuZHBvaW50IGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBhcHByb3ZlIHRoZSBjbGll bnTigJlzIGFjY2Vzcy4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGF1dGhlbnRpY2F0 ZSB0aGUgdXNlciBhbmQgb2J0YWluIHRoZWlyIGFwcHJvdmFsLCB0aG91Z2ggdGhlIHdheSB0aGlz IGlzIGFjaGlldmVkIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIChl ZyBwYXNzd29yZCwgT3BlbklELCBzZXNzaW9uIGNvb2tpZSkuDQoNCiJBIGNsaWVudCBhcHAgY2Fu IG9idGFpbiBhIHVzZXIgZW5kcG9pbnQgZnJvbSBhIFdXVy1BdXRoZW50aWNhdGUgSFRUUCByZXNw b25zZSBoZWFkZXIgcmV0dXJuZWQgYnkgYSByZXNvdXJjZSBzZXJ2ZXIgd2hlbiBpdCBpbmRpY2F0 ZXMgdGhhdCBPQXV0aCBpcyByZXF1aXJlZCAoc2VlIHNlY3Rpb24gOS4xLjIpLiBTb21lIGNsaWVu dCBhcHBzIG1heSBhbHJlYWR5IGtub3cgYSB1c2VyIGVuZHBvaW50IGZyb20gc2VydmVyIGRvY3Vt ZW50YXRpb24uDQoNCiJBIHVzZXIgZW5kcG9pbnQgYWR2ZXJ0aXNlZCBieSBhIHJlc291cmNlIHNl cnZlciBtYXkgYWxyZWFkeSBpbmNsdWRlIHF1ZXJ5IHBhcmFtZXRlcnMsIHdoaWNoIE1VU1QgYmUg cmV0YWluZWQgd2hlbiB0aGUgY2xpZW50IGFkZHMgb3RoZXIgcXVlcnkgcGFyYW1ldGVycy4NCg0K IkEgdXNlciBlbmRwb2ludCBTSE9VTEQgYmUgYW4gSFRUUFMgVVJJIChvciByZXF1aXJlIGEgc2Vj dXJlIGNoYW5uZWwgd2l0aCBlcXVpdmFsZW50IHByb3RlY3Rpb25zKSBhcyBpbnRlcmFjdGlvbnMg d2l0aCBhIHVzZXIgZW5kcG9pbnQgaW52b2x2ZSB1c2VyIGF1dGhlbnRpY2F0aW9uIGFuZCB0aGUg dHJhbnNtaXNzaW9uIG9mIHNlbnNpdGl2ZSB2YWx1ZXMuIg0KDQoNCi0tIA0KSmFtZXMgTWFuZ2Vy DQo= From dick.hardt@gmail.com Sun May 9 17:52:31 2010 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 4B9D53A6AC3 for ; Sun, 9 May 2010 17:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 ILsCXlTFHe-h for ; Sun, 9 May 2010 17:52:30 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 0EE433A6AC0 for ; Sun, 9 May 2010 17:52:30 -0700 (PDT) Received: by pwj2 with SMTP id 2so1525066pwj.31 for ; Sun, 09 May 2010 17:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=6HrSpc5gPFiSNYj0FLIrRe5xFdMO0KphTOlHTkt6kX8=; b=fpHCuRfdRqe5AlcqYK2+fNLcFX8t81oIsLwq1qZ34iCulN47NjkZaDaynqjCB7QW6a 98Q3Lv/i5ii3tUM91ETAI9d8Y0IgbYX+DjPduNb2BzIvUayepn1aNycKrIVqgzFeNBej 4OyOs/z2zd1rv6dZTm9qi4oOwCHFL232G9xYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Xp4H+q82mpFMpiUMWpYi9khJ74E3zTF3R0ZOj/GXgACRqF9HUFBX2g+5WuAyGu3jLG cvG3G1lNVWgR0igHC9DQtcGKN7qYx0rcAzin/oqrYH2MhGuKz9yD9yr+2WtGjR4MiG3c imUYNVVafwVws9IWty9gF/Mt3ot82cUkg6SF0= Received: by 10.142.122.24 with SMTP id u24mr1914337wfc.264.1273452735140; Sun, 09 May 2010 17:52:15 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id f11sm22869677wai.23.2010.05.09.17.52.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 17:52:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 9 May 2010 17:52:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 00:52:31 -0000 On 2010-05-09, at 3:25 PM, Eran Hammer-Lahav wrote: >=20 >> 3.2.1.1. Access Token Response >> expires_in >> OPTIONAL. The duration in seconds of the access token >> lifetime. >>=20 >> refresh_token >> OPTIONAL. The refresh token used to obtain new access = tokens >> using the same end-user access grant as described in Section = 6. >>=20 >> What is the exact meaning/idea of OPTIONAL response parameters? >> Who actually decides to use them? The client or the authorization = server or >> both? >> Is it optional to implement this feature or is it envisioned the = server >> dynamically decides to use those parameters based on its policy? >=20 > Optional means the server gets to decide to include them or not. I = think it is pretty clear that optional is decided by the entity = constructing the message. >=20 >> expires_in >>=20 >> Why is there information passed back about the access tokens duration = but >> not about the refresh tokens duration? >=20 > No one asked for that. Is there interest in specifying the = authorization duration in addition to the token duration? I have not heard of a scenario where it would be useful to the client to = know the refresh token duration. Unlike the access token where the AS usually sets as expiry time. = Authorization could be cancelled at any time for a wide variety of = reasons, so there is little knowledge or certainty when it will expire. >=20 >> 3.5. User-Agent Flow >>=20 >> These clients >> cannot keep client secrets confidential and the authentication of = the >> client is based on the user-agent's same-origin policy. >>=20 >> Does this still hold in the context of "HTTP Origin Headers" >> (http://www.petefreitag.com/item/702.cfm)? >>=20 >> BTW: Will Brian's security considerations document be updated to be = in sync >> with the draft? >=20 > Brian's document was written for WRAP. We need to write a full = security review for 2.0 that is structure similarly to OAuth 1.0. Besides changing some terminology, I would think Brian's doc would be = mainly reusable. Perhaps you could insert a version with changes you = understand, then people can suggest changes that need to be made. >=20 >> 3.5.1. Client Requests Authorization >>=20 >> If the client has previously registered a redirection URI with the >> authorization server, the authorization server MUST verify that = the >> redirection URI received matches the registered URI associated = with >> the client identifier. >>=20 >> Does this mean equality? Or just the same base string? >=20 > Right now it depends on the server. The spec should clarify that. Suggested wording: If the client has previously registered a redirection URI with the = authorization server, the authorization server MUST verify that the = redirection URI received matches the registered URI associated with the = client identifier. The components of the redirection URI that must match = the registered URI is authorization server dependant. >=20 >> 7. Refreshing an Access Token >>=20 >> I would suggest to add an optional "scope" parameter to this request. >> This could be used to downgrade the scope associated with a token. >=20 > That would be the wrong way to do it given that people will expect to = also be able to upgrade scope. Would you elaborate? Would not providing a scope parameter enable any = potential change in scope to the access token? The change may be neither = an upgrade or downgrade, just different. >=20 >> 8.1. The Authorization Request Header >>=20 >> I consider the name "Token" of the authentication schema much to = generic. >> That was also the feedback of all colleagues I talked to about the = upcoming >> standard. Why not call it "OAuth2"? >=20 > It is meant to be generic. I consider OAuth to be the part of the = protocol dealing with getting a token. There will be many new ways to = get a token in the future. I also find the use of Token here. >=20 >> 8.2.2. Form-Encoded Body Parameter >>=20 >> I would suggest to drop this section/feature. >>=20 >> General note: Would it make sense to add explicit format handling to = the >> OAuth API? If we envision authorization servers supporting more than = one >> token format (e.g. SAML, SWT, ...), the client should given the = option to >> request a certain format and responses returning access tokens should >> indicate the format of this token. The OAuth authorization header = could also >> have an optional format attribute for the same purpose. >=20 > You mean token format? OAuth defined the token as opaque so that would = be counter-productive. Not only can the AS support multiple formats, but a PR could support = multiple formats. While the token is opaque to the client, the PR is = going to need to detect what kind of token was presented in some way. We = can make this easier by something in the spec, or defer this to the PR = to detect tokens by examining the token. The scope parameter could be = used by the AS to determine the token type to be generated. -- Dick= From James.H.Manger@team.telstra.com Sun May 9 17:55:23 2010 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 845313A6AC4 for ; Sun, 9 May 2010 17:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.387 X-Spam-Level: * X-Spam-Status: No, score=1.387 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf5n0QijoQ5W for ; Sun, 9 May 2010 17:55:22 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 694063A6ACA for ; Sun, 9 May 2010 17:55:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,358,1270389600"; d="scan'208";a="2594944" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 10 May 2010 10:55:10 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5977"; a="1679215" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 10 May 2010 10:55:11 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Mon, 10 May 2010 10:55:10 +1000 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Mon, 10 May 2010 10:55:09 +1000 Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrv1jA22NMhzJrkSMyGHo4rbwxUSwAAft1w Message-ID: <255B9BB34FB7D647A506DC292726F6E112631B2E83@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1F6D82E6-7544-4845-916F-7361165ADA4B@gmail.com> In-Reply-To: <1F6D82E6-7544-4845-916F-7361165ADA4B@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] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 00:55:23 -0000 PiAxLiBTZXJ2ZXIgUmVzcG9uc2UgRm9ybWF0DQo+IA0KPiBBLiBGb3JtLWVuY29kZWQgb25seSAo b3JpZ2luYWwgZHJhZnQpDQo+IEIuIEpTT04gb25seSAoY3VycmVudCBkcmFmdCkNCj4gQy4gSlNP TiBhcyBkZWZhdWx0IHdpdGggZm9ybS1lbmNvZGVkIGFuZCBYTUwgYXZhaWxhYmxlIHdpdGggYW4g b3B0aW9uYWwgcmVxdWVzdCBwYXJhbWV0ZXINCg0KSSB2b3RlIGZvciBCDQoNCkIgZG9lc24ndCBz dG9wIHNwZWNpZmljIHNlcnZpY2VzIGFsc28gb2ZmZXJpbmcgZm9ybS1lbmNvZGVkIG9yIFhNTCB2 YXJpYW50cyAtLSBwYXJ0aWN1bGFybHkgaWYgdGhhdCBtYXRjaGVzIHRoZSByZXN0IG9mIHRoZWly IEFQSS4gQSBjbGllbnQgYXBwIHdyaXR0ZW4gc3BlY2lmaWNhbGx5IGZvciBzdWNoIGEgc2Vydmlj ZSBjb3VsZCBzdGlsbCBhdm9pZCBKU09OLg0KQ2hvaWNlIEIgbWVhbnMgYSBnZW5lcmljIGNsaWVu dCBuZWVkcyB0byBzdXBwb3J0IEpTT04sIHdoaWNoIEkgZmVlbCBpc24ndCB1bnJlYXNvbmFibGUu DQoNCg0KPiAyLiBDbGllbnQgQXV0aGVudGljYXRpb24gKGluIGZsb3dzKQ0KPiANCj4gQS4gQ2xp ZW50IGF1dGhlbnRpY2F0ZXMgYnkgc2VuZGluZyBpdHMgY3JlZGVudGlhbHMgdXNpbmcgc3BlY2lh bCBwYXJhbWV0ZXJzIChjdXJyZW50IGRyYWZ0KQ0KPiBCLiBDbGllbnQgYXV0aGVudGljYXRlZCBi eSB1c2luZyBIVFRQIEJhc2ljIChvciBvdGhlciBzY2hlbWVzIHN1cHBvcnRlZCBieSB0aGUgc2Vy dmVyIHN1Y2ggYXMgRGlnZXN0KQ0KDQo+PiBDLiBzdXBwb3J0IGJvdGggZmxvd3MgaW4gdGhlIHNw ZWMuDQoNCkkgdm90ZSBmb3IgQisuDQpUaGUgc3BlYyBtZXNzYWdlcyBoYXZlIG5vIGRlcGVuZGVu Y2Ugb24gYW55IHNwZWNpZmljIGNsaWVudCBhdXRoIG1lY2hhbmlzbS4NClRoZSBzcGVjIHNheXMg Y2xpZW50IGFwcHMgY2FwYWJsZSBvZiBhdXRoZW50aWNhdGluZyB3aXRoIGEgc2hhcmVkIHNlY3Jl dCBNVVNUIHN1cHBvcnQgSFRUUCBCQVNJQy4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From dick.hardt@gmail.com Sun May 9 17:55:46 2010 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 67BD73A6ABE for ; Sun, 9 May 2010 17:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 oTiaZTdH13j1 for ; Sun, 9 May 2010 17:55:45 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id B2BAC3A6978 for ; Sun, 9 May 2010 17:55:45 -0700 (PDT) Received: by pxi19 with SMTP id 19so1525673pxi.31 for ; Sun, 09 May 2010 17:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=hjocgpofknucRX2O7TzdjcigAB15VJyDaeqTy3HCrno=; b=ZKL82zBsbEBi1Y29HTF1PfazmbbhFMYFM66TvHzdWbpLUC3MoiPrA5ateFu+sfSIOX XW3pSY5TtJwNTNsA0ClJyV5IZ6vkCxNmNacgdhTiJJXGtIIhfevQbr6LOfIJ16bABm5b 0yCF0AvcQv/jfJHvny8jJB2djOYxryqL6pB9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MGraw53Zo/wjKBH0XiLOFQj7TYkh7RFfhhjByoLDcA+/3t7sMcWLyzKrqbbVnkv4op eWek31M5hy8qjeQqJ0aEH0KmpeZBjCQ9taTDlVxttwdTJeegalR44Cp/CMljjG3/IMCi j4i3KUUIvVrNRBN9OQBsJMbbuuQrpAxq90NZ4= Received: by 10.114.251.23 with SMTP id y23mr2530327wah.42.1273452929959; Sun, 09 May 2010 17:55:29 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id d16sm22901122wam.0.2010.05.09.17.55.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 17:55:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 9 May 2010 17:55:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43C2E5D4-FA8B-4C72-91C1-6ED4435334D2@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] User Endpoint 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, 10 May 2010 00:55:46 -0000 I prefer authorization endpoint as it talks about the functionality of = what the client gets from that endpoint. Delegation endpoint is another = alternative. User endpoint implies there must be a user present. I = envision scenarios where an identity agent deals with the authorization = for the user and the user is not involved.=20 On 2010-05-09, at 2:15 PM, Eran Hammer-Lahav wrote: > I would like to rename the authorization endpoint to the user = endpoint. Any objections? >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Sun May 9 19:19:42 2010 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 51D0F3A69A8 for ; Sun, 9 May 2010 19:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_05=-1.11] 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 dGZwsWEOwhqL for ; Sun, 9 May 2010 19:19:40 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 4FAED3A6992 for ; Sun, 9 May 2010 19:19:31 -0700 (PDT) Received: by pzk38 with SMTP id 38so1578165pzk.31 for ; Sun, 09 May 2010 19:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=Zckb1KPCjowFhNFVHDhlhaAsIUAYRbxa92JDs4lzM/c=; b=kmeqrldRFIz/KZ1uEALz4IHF75CE1VW60OUSBYMqxYx9NZVCGvsh2JNxyheTdcAkdj vVpM1u+Qw13fbGL/owwazaRk89nt/KplSbBAuNZBbIdIKB0cKEjYcKW28rDiYcFSroye fiJRN0ob8CWpb/MTLSjBn3hqb0Z7S9uC5hC4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=q4ot8xszcXKbOglp4Y4Nt3Qa7Qjio/4mHgwObgx/K8SpK7m/v6wZOLmqw02XENrwoh Q6zsDLmMKabKhPxJfoz7aAkAX7Uejmv9IEZK90CT18J+vo+KqEd8SCkV+icBc6DQuQ47 pYNYE26Qr6sFIVSAeoEf+PGWsUqRi4Kca/BL0= Received: by 10.115.80.14 with SMTP id h14mr2590795wal.14.1273457957534; Sun, 09 May 2010 19:19:17 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id d16sm23207015wam.0.2010.05.09.19.19.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 19:19:17 -0700 (PDT) From: Dick Hardt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 9 May 2010 19:19:16 -0700 Message-Id: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> To: "OAuth WG (oauth@ietf.org)" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [OAUTH-WG] modifying the scope of an access 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, 10 May 2010 02:19:42 -0000 There has been some discussion about modifying the scope of the access = token during a refresh. Perhaps we can add another "method" to what the = AS MAY support that allows modifying the scope of an access token. Type = of request is "modify" and the scope parameter is required to indicate = the new scope required. Suggested copy below: type REQUIRED. The parameter value MUST be set to modify client_id REQUIRED. The client identifier as described in Section 3.4. client_secret REQUIRED if the client was issued a secret. The client secret. refresh_token REQUIRED. The refresh token associated with the access token to = be refreshed. scope REQUIRED. The new scope of the access request expressed as a = list of space-delimited strings. The value of the scope parameter is = defined by the authorization server. If the value contains multiple = space-delimited strings, their order does not matter, and each string = adds additional access range to the requested scope. secret_type OPTIONAL. The access token secret type as described by Section = 8.3. If omitted, the authorization server will issue a bearer token (an = access token without a matching secret) as described by Section 8.2. From dick.hardt@gmail.com Sun May 9 19:34:25 2010 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 138073A698E for ; Sun, 9 May 2010 19:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_40=-0.185] 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 dPLdZ8ATu-bF for ; Sun, 9 May 2010 19:34:24 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 28A573A66B4 for ; Sun, 9 May 2010 19:34:24 -0700 (PDT) Received: by pwj2 with SMTP id 2so1562495pwj.31 for ; Sun, 09 May 2010 19:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=8UlLPeoGpzt7sP8XfXpvfh19mhdzbRgB79FoRZamJL8=; b=SMKkd87jRUlZP2mJSMTIpJZORfQQOZf0mJjRNZQqBJTqTgV/syNzJ8LvfDzOFqOWiv BGeo5SnKMt9NMyNKSM99ph3Zf0Uw8/nbR77Bk4hnTnopr1tLSOGyDuI1cYlqoFCb0a2+ +66pIqVUOIjZjxbMeTwLdkWsVMxf/pMkVaxy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=pqmCJcW0gMBnqceW0pxYRndZiljEZ6qWawjmUwCUgsbmkWNBn0UeQEMYvcSzm5ZM/D 1LUQYdkhNQ4Hy4bblyDrvK2SAt6GUbfYAvVeYUljowNG6bKp9vzCjYIqpcLTTxUdrcoc 7VzOCTWKK7k92qveyqQ+uJyb+XfLI6/U/eDI0= Received: by 10.115.37.28 with SMTP id p28mr2560474waj.218.1273458849984; Sun, 09 May 2010 19:34:09 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id d16sm23245293wam.12.2010.05.09.19.34.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 19:34:09 -0700 (PDT) From: Dick Hardt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 9 May 2010 19:34:09 -0700 Message-Id: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.com> To: "OAuth WG (oauth@ietf.org)" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [OAUTH-WG] delegating access to another client 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, 10 May 2010 02:34:25 -0000 Twitter has an interesting use case that may become common: one client = needs to delegate access to another client. Similar to the 'modify' = method where the scope of the access token can be modified, the = 'delegate' method allows a client to request delegation to another = client (the delegate). Here is some proposed copy for the request: type REQUIRED. The parameter value MUST be set to delegate client_id REQUIRED. The client identifier as described in Section 3.4. client_secret REQUIRED if the client was issued a secret. The client secret. refresh_token REQUIRED. The refresh token associated with the client. delegate_id REQUIRED. The client identifier of the delegate scope OPTIONAL. The scope the client is requesting for the delegate. secret_type OPTIONAL. The access token secret type as described by Section = 8.3. If omitted, the authorization server will issue a bearer token (an = access token without a matching secret) as described by Section 8.2. There a couple of choices for the flows for how a successful delegation = is conveyed to the delegate. The AS could return a delegation code that = is similar to a verification code and the delegate acquires an access = token similar to 3.6.2 Alternatively, the AS could return an delegation token that is used = similar to a refresh token to obtain an access token and refresh token. Do people think this is worth adding to the spec? It seems to be a = simple addition and allows us to standardize what is emerging as a = common capability. -- Dick= From dewitt@unto.net Sun May 9 21:46:15 2010 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 A5D3F3A6AD7 for ; Sun, 9 May 2010 21:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 hRv3Vw3s2VS2 for ; Sun, 9 May 2010 21:46:14 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with SMTP id A9BAA3A6A5C for ; Sun, 9 May 2010 21:46:13 -0700 (PDT) Received: from source ([209.85.161.53]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKS+ePiWB1hHQdos7TsNa3WGln86TtHoZg@postini.com; Sun, 09 May 2010 21:46:03 PDT Received: by fxm1 with SMTP id 1so2016932fxm.12 for ; Sun, 09 May 2010 21:46:01 -0700 (PDT) Received: by 10.239.131.11 with SMTP id 11mr245342hbl.107.1273466761140; Sun, 09 May 2010 21:46:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.162.68 with HTTP; Sun, 9 May 2010 21:45:41 -0700 (PDT) In-Reply-To: <1F6D82E6-7544-4845-916F-7361165ADA4B@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1F6D82E6-7544-4845-916F-7361165ADA4B@gmail.com> From: DeWitt Clinton Date: Sun, 9 May 2010 21:45:41 -0700 Message-ID: To: Dick Hardt Content-Type: multipart/alternative; boundary=001485f7d49cee5911048636152c Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 04:46:15 -0000 --001485f7d49cee5911048636152c Content-Type: text/plain; charset=ISO-8859-1 Response inline. On Sun, May 9, 2010 at 5:17 PM, Dick Hardt wrote: > > On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote: > > > DEADLINE: 5/13 > > > > I would like to publish one more draft before our interim meeting in two > weeks (5/20). Below are two open issues we have on the list. Please reply > with your preference (or additional solutions) to each item. Issues with > consensus will be incorporated into the next draft. Those without will be > discussed at the meeting. > > > > EHL > > > > --- > > > > 1. Server Response Format > > > > After extensive debate, we have a large group in favor of using JSON as > the only response format (current draft). We also have a smaller group but > with stronger feelings on the subject that JSON adds complexity with no > obvious value. > > > > A. Form-encoded only (original draft) > > B. JSON only (current draft) > > C. JSON as default with form-encoded and XML available with an optional > request parameter > > I vote for B > > I would argue that form-encoded data adds complexity with no obvious value. > > *If* a JSON parser is not available, parsing the JSON that is returned is > not that much different from parsing form-encoded data (remember that we are > only using a very small subset of JSON) > I strongly disagree here. The subset of JSON returned is "all valid JSON", pure and simple. Indeed, this was exactly what I was concerned about before. The server is *no* obligation to return something that can be parsed more easily than full JSON. If we don't make that crystal clear, then I worry about no end to unsafe encoding and escaping issues down the road. If the decision is to go with either option B or C, please do it only via language that says that clients and servers both MUST be RFC 4627 compliant. I.e., a full JSON parser, or no JSON at all. -DeWitt > More and more sites are returning both JSON and XML. Eventually everyone > will see the light wrt. JSON ;-) > > > > > --- > > > > 2. Client Authentication (in flows) > > > > How should the client authenticate when making token requests? The > current draft defines special request parameters for sending client > credentials. Some have argued that this is not the correct way, and that the > client should be using existing HTTP authentication schemes to accomplish > that such as Basic. > > > > A. Client authenticates by sending its credentials using special > parameters (current draft) > > B. Client authenticated by using HTTP Basic (or other schemes supported > by the server such as Digest) > > C. support both flows in the spec. An AS can decide what it wants to > support. I would like to retain A as it may be challenging for some clients > to use HTTP Basic, and easier for an AS to be always parsing parameters for > each flow. I can see the advantages for some in using HTTP Basic. > > -- Dick > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001485f7d49cee5911048636152c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Response inline.

On Sun, May 9, 2010 at 5= :17 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote:

> DEADLINE: 5/13
>
> I would like to publish one more draft before our interim meeting in t= wo weeks (5/20). Below are two open issues we have on the list. Please repl= y with your preference (or additional solutions) to each item. Issues with = consensus will be incorporated into the next draft. Those without will be d= iscussed at the meeting.
>
> EHL
>
> ---
>
> 1. Server Response Format
>
> After extensive debate, we have a large group in favor of using JSON a= s the only response format (current draft). We also have a smaller group bu= t with stronger feelings on the subject that JSON adds complexity with no o= bvious value.
>
> A. Form-encoded only (original draft)
> B. JSON only (current draft)
> C. JSON as default with form-encoded and XML available with an optiona= l request parameter

I vote for B

I would argue that form-encoded data adds complexity with no obvious value.=

*If* a JSON parser is not available, parsing the JSON that is returned is n= ot that much different from parsing form-encoded data (remember that we are= only using a very small subset of JSON)

I strongly disagree here. =A0The subset of JSON returned is "all = valid JSON", pure and simple. =A0Indeed, this was exactly what I was c= oncerned about before.

The server is no obl= igation to return something that can be parsed more easily than full JSON. = =A0If we don't make that crystal clear, then I worry about no end to un= safe encoding and escaping issues down the road.

If the decision is to go with either option B or C, ple= ase do it only via language that says that clients and servers=A0both MUST = be RFC 4627 compliant. =A0I.e., a full JSON parser, or no JSON at all.

=A0-DeWitt


More and more sites are returning both JSON and XML. Eventually everyone wi= ll see the light wrt. JSON ;-)

>
> ---
>
> 2. Client Authentication (in flows)
>
> How should the client authenticate when making token requests? The cur= rent draft defines special request parameters for sending client credential= s. Some have argued that this is not the correct way, and that the client s= hould be using existing HTTP authentication schemes to accomplish that such= as Basic.
>
> A. Client authenticates by sending its credentials using special param= eters (current draft)
> B. Client authenticated by using HTTP Basic (or other schemes supporte= d by the server such as Digest)

C. support both flows in the spec. An AS can decide what it wants to = support. I would like to retain A as it may be challenging for some clients= to use HTTP Basic, and easier for an AS to be always parsing parameters fo= r each flow. I can see the advantages for some in using HTTP Basic.

-- Dick


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

--001485f7d49cee5911048636152c-- From eran@hueniverse.com Sun May 9 22:10:05 2010 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 74B123A67DB for ; Sun, 9 May 2010 22:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.241 X-Spam-Level: X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_40=-0.185] 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 yHp6Q+HHvuWK for ; Sun, 9 May 2010 22:10: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 B12C43A6AE7 for ; Sun, 9 May 2010 22:09:53 -0700 (PDT) Received: (qmail 22566 invoked from network); 10 May 2010 05:09:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2010 05:09:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 9 May 2010 22:09:41 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Sun, 9 May 2010 22:09:42 -0700 Thread-Topic: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt Thread-Index: Acrv2w23sf/PKOeMS2yKi7p3XwQGcAAIpMww Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> In-Reply-To: <918F548B-2501-4630-977E-0A7D4484D067@gmail.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 05:10:05 -0000 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, May 09, 2010 5:52 PM > >> BTW: Will Brian's security considerations document be updated to be > >> in sync with the draft? > > > > Brian's document was written for WRAP. We need to write a full security > review for 2.0 that is structure similarly to OAuth 1.0. >=20 > Besides changing some terminology, I would think Brian's doc would be > mainly reusable. Perhaps you could insert a version with changes you > understand, then people can suggest changes that need to be made. Since the security section is all non-normative language, it is the least i= mportant part on my list. Brian's document is useful but is not something I= can work with quickly. If someone wants to take a stab at converting it in= to a section that can be cut-and-paste into the draft, I would be very happ= y to incorporate it. =20 > >> 3.5.1. Client Requests Authorization > >> > >> If the client has previously registered a redirection URI with the > >> authorization server, the authorization server MUST verify that the > >> redirection URI received matches the registered URI associated with > >> the client identifier. > >> > >> Does this mean equality? Or just the same base string? > > > > Right now it depends on the server. >=20 > The spec should clarify that. Suggested wording: >=20 >=20 > If the client has previously registered a redirection URI with the author= ization > server, the authorization server MUST verify that the redirection URI > received matches the registered URI associated with the client identifier= . The > components of the redirection URI that must match the registered URI is > authorization server dependant. I don't see how that helps... I also don't see why we can't just profile th= is and decide on how the matching should be done. We have the state paramet= er to help too. > >> 7. Refreshing an Access Token > >> > >> I would suggest to add an optional "scope" parameter to this request. > >> This could be used to downgrade the scope associated with a token. > > > > That would be the wrong way to do it given that people will expect to a= lso > be able to upgrade scope. >=20 > Would you elaborate? Would not providing a scope parameter enable any > potential change in scope to the access token? The change may be neither = an > upgrade or downgrade, just different. Downgrading scope is the only modification allowed without getting the end-= user involved again (or using any of the flows from the beginning). When yo= u refresh a token, you can ask to get a new token with less scope because t= hat will not conflict with the access grant. > >> 8.1. The Authorization Request Header > >> > >> I consider the name "Token" of the authentication schema much to > generic. > >> That was also the feedback of all colleagues I talked to about the > >> upcoming standard. Why not call it "OAuth2"? > > > > It is meant to be generic. I consider OAuth to be the part of the proto= col > dealing with getting a token. There will be many new ways to get a token = in > the future. >=20 > I also find the use of Token here. Find it...? > >> 8.2.2. Form-Encoded Body Parameter > >> > >> I would suggest to drop this section/feature. > >> > >> General note: Would it make sense to add explicit format handling to > >> the OAuth API? If we envision authorization servers supporting more > >> than one token format (e.g. SAML, SWT, ...), the client should given > >> the option to request a certain format and responses returning access > >> tokens should indicate the format of this token. The OAuth > >> authorization header could also have an optional format attribute for = the > same purpose. > > > > You mean token format? OAuth defined the token as opaque so that > would be counter-productive. >=20 > Not only can the AS support multiple formats, but a PR could support > multiple formats. While the token is opaque to the client, the PR is goin= g to > need to detect what kind of token was presented in some way. We can > make this easier by something in the spec, or defer this to the PR to det= ect > tokens by examining the token. The scope parameter could be used by the > AS to determine the token type to be generated. Token type negotiation is something this group has strongly rejected in the= past. I am not sure we can even agree on the right abstraction layer. Eith= er way, there is nothing to stop someone from extending the spec. And BTW, people can write extensions *now*. This is not aimed at anyone: if= you feel strongly about a feature getting little love by this group or fac= ing strong objections, it is your responsibility to draft it and promote it= . If you get enough people to like it, we can incorporate it. If not, you c= an publish it as a companion document. EHL From eran@hueniverse.com Sun May 9 22:11:40 2010 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 F2AED3A6AE8 for ; Sun, 9 May 2010 22:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 NlKt8udydJgm for ; Sun, 9 May 2010 22:11:38 -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 3A5693A6AE1 for ; Sun, 9 May 2010 22:11:13 -0700 (PDT) Received: (qmail 22798 invoked from network); 10 May 2010 05:11:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2010 05:11:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 22:11:01 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Sun, 9 May 2010 22:11:03 -0700 Thread-Topic: [OAUTH-WG] User Endpoint Thread-Index: Acrv230cu1dA4dv1TmGvqh6UTgbI3QAI5KLA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E38@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <43C2E5D4-FA8B-4C72-91C1-6ED4435334D2@gmail.com> In-Reply-To: <43C2E5D4-FA8B-4C72-91C1-6ED4435334D2@gmail.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] User Endpoint 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, 10 May 2010 05:11:40 -0000 Both endpoints deal with authorization of sorts. The reason why we have two= is one is for direct client-server communication and the other one involve= s the end-user (a human). EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, May 09, 2010 5:55 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] User Endpoint >=20 > I prefer authorization endpoint as it talks about the functionality of wh= at the > client gets from that endpoint. Delegation endpoint is another alternativ= e. > User endpoint implies there must be a user present. I envision scenarios > where an identity agent deals with the authorization for the user and the > user is not involved. >=20 > On 2010-05-09, at 2:15 PM, Eran Hammer-Lahav wrote: >=20 > > I would like to rename the authorization endpoint to the user endpoint. > Any objections? > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun May 9 22:14:04 2010 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 65E9B3A6ADD for ; Sun, 9 May 2010 22:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 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 zdNfJ62WEmX9 for ; Sun, 9 May 2010 22:14: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 12CC93A6AF5 for ; Sun, 9 May 2010 22:14:02 -0700 (PDT) Received: (qmail 23233 invoked from network); 10 May 2010 05:13:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2010 05:13:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 22:13:50 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Sun, 9 May 2010 22:13:52 -0700 Thread-Topic: a couple editorial comments on draft-ietf-oauth-v2-03 Thread-Index: Acrv5heqk8BNgmwATFWDtCF75gcOqgAGTHmA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E39@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] a couple editorial comments on draft-ietf-oauth-v2-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: Mon, 10 May 2010 05:14:04 -0000 > -----Original Message----- > From: Dick Hardt [mailto:dick@sxipper.com] > Sent: Sunday, May 09, 2010 7:11 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: a couple editorial comments on draft-ietf-oauth-v2-03 >=20 > Use of term "identifier" wrt. access token and refresh token. The Abstrac= t, > Introduction, 2.1 access token, refresh token, still refer to the access = token > as an identifier. I agreed with you before and asked (repeatedly) for new text. Please sugges= t alternatives. > 3.2.1 > Numerical number are included as JSON numbers. >=20 > should be >=20 > Numerical numbers are included as JSON numbers. Actually: Numerical values are included as JSON numbers. But thanks for the catch :-) EHL From eran@hueniverse.com Sun May 9 22:23:53 2010 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 AA9A63A6B40 for ; Sun, 9 May 2010 22:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 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 ceZROcxOlMMh for ; Sun, 9 May 2010 22:22:45 -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 30A683A6B0C for ; Sun, 9 May 2010 22:17:24 -0700 (PDT) Received: (qmail 23933 invoked from network); 10 May 2010 05:17:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2010 05:17:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 9 May 2010 22:17:13 -0700 From: Eran Hammer-Lahav To: Dick Hardt , "OAuth WG (oauth@ietf.org)" Date: Sun, 9 May 2010 22:17:14 -0700 Thread-Topic: [OAUTH-WG] modifying the scope of an access token Thread-Index: Acrv5z1K40U/kkjiT1SysLwnegfZ0wAGG0jg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> In-Reply-To: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.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] modifying the scope of an access 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, 10 May 2010 05:23:53 -0000 This would only work for the client credentials flow (because you keep the = same authorization source). For all other flows you are breaking the author= ization boundaries. What would be useful is to allow asking for more scope. For example, when a= sking for a token (the last step of each flow), also include a valid token = to get a new token with the combined scope (new approval and previous). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dick Hardt > Sent: Sunday, May 09, 2010 7:19 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] modifying the scope of an access token >=20 > There has been some discussion about modifying the scope of the access > token during a refresh. Perhaps we can add another "method" to what the > AS MAY support that allows modifying the scope of an access token. Type o= f > request is "modify" and the scope parameter is required to indicate the n= ew > scope required. Suggested copy below: >=20 > type > REQUIRED. The parameter value MUST be set to modify >=20 > client_id > REQUIRED. The client identifier as described in Section 3.4. >=20 > client_secret > REQUIRED if the client was issued a secret. The client secret. >=20 > refresh_token > REQUIRED. The refresh token associated with the access token to be > refreshed. >=20 > scope > REQUIRED. The new scope of the access request expressed as a list > of space-delimited strings. The value of the scope parameter is defined b= y > the authorization server. If the value contains multiple space-delimited > strings, their order does not matter, and each string adds additional acc= ess > range to the requested scope. >=20 > secret_type > OPTIONAL. The access token secret type as described by Section 8.3. > If omitted, the authorization server will issue a bearer token (an access= token > without a matching secret) as described by Section 8.2. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun May 9 22:30:29 2010 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 D1D3928C126 for ; Sun, 9 May 2010 22:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 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 qo3-mrrwJgam for ; Sun, 9 May 2010 22:30:28 -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 7F5F23A6B08 for ; Sun, 9 May 2010 22:20:36 -0700 (PDT) Received: (qmail 6685 invoked from network); 10 May 2010 05:20:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 May 2010 05:20:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 9 May 2010 22:20:15 -0700 From: Eran Hammer-Lahav To: Dick Hardt , "OAuth WG (oauth@ietf.org)" Date: Sun, 9 May 2010 22:20:16 -0700 Thread-Topic: [OAUTH-WG] delegating access to another client Thread-Index: Acrv6Up5fZGdb+bqR5eEQfFa1TwPbwAFt22g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.com> In-Reply-To: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.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] delegating access to another client 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, 10 May 2010 05:30:30 -0000 Re-delegation is something people asked for since we started talking about = OAuth. There is also a draft I-D about it. This is explicitly out of scope = for the core spec (but not something that should stop us from having a disc= ussion). The main concern is how should the resource owner express their approval fo= r such arrangement? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dick Hardt > Sent: Sunday, May 09, 2010 7:34 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] delegating access to another client >=20 > Twitter has an interesting use case that may become common: one client > needs to delegate access to another client. Similar to the 'modify' metho= d > where the scope of the access token can be modified, the 'delegate' metho= d > allows a client to request delegation to another client (the delegate). H= ere is > some proposed copy for the request: >=20 > type > REQUIRED. The parameter value MUST be set to delegate >=20 > client_id > REQUIRED. The client identifier as described in Section 3.4. >=20 > client_secret > REQUIRED if the client was issued a secret. The client secret. >=20 > refresh_token > REQUIRED. The refresh token associated with the client. >=20 > delegate_id > REQUIRED. The client identifier of the delegate >=20 > scope > OPTIONAL. The scope the client is requesting for the delegate. >=20 > secret_type > OPTIONAL. The access token secret type as described by Section 8.3. > If omitted, the authorization server will issue a bearer token (an access= token > without a matching secret) as described by Section 8.2. >=20 > There a couple of choices for the flows for how a successful delegation i= s > conveyed to the delegate. The AS could return a delegation code that is > similar to a verification code and the delegate acquires an access token > similar to 3.6.2 Alternatively, the AS could return an delegation token t= hat is > used similar to a refresh token to obtain an access token and refresh tok= en. >=20 > Do people think this is worth adding to the spec? It seems to be a simple > addition and allows us to standardize what is emerging as a common > capability. >=20 > -- Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun May 9 22:33:17 2010 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 753BE3A6B4C for ; Sun, 9 May 2010 22:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_50=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 9+ickMBkCRWl for ; Sun, 9 May 2010 22:33:16 -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 29EA73A6B57 for ; Sun, 9 May 2010 22:26:07 -0700 (PDT) Received: (qmail 25499 invoked from network); 10 May 2010 05:25:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2010 05:25:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 9 May 2010 22:25:14 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 9 May 2010 22:25:16 -0700 Thread-Topic: Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vAARQkvQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@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: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 05:33:17 -0000 No strong views on either one. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Sunday, May 09, 2010 2:07 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > DEADLINE: 5/13 >=20 > I would like to publish one more draft before our interim meeting in two > weeks (5/20). Below are two open issues we have on the list. Please reply > with your preference (or additional solutions) to each item. Issues with > consensus will be incorporated into the next draft. Those without will be > discussed at the meeting. >=20 > EHL >=20 > --- >=20 > 1. Server Response Format >=20 > After extensive debate, we have a large group in favor of using JSON as t= he > only response format (current draft). We also have a smaller group but wi= th > stronger feelings on the subject that JSON adds complexity with no obviou= s > value. >=20 > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional > request parameter I think C is the right solution, but as someone who wrote his own JSON pars= er from scratch (which took a day and a lot of debugging), I can live with = either option. > --- >=20 > 2. Client Authentication (in flows) >=20 > How should the client authenticate when making token requests? The > current draft defines special request parameters for sending client > credentials. Some have argued that this is not the correct way, and that = the > client should be using existing HTTP authentication schemes to accomplish > that such as Basic. >=20 > A. Client authenticates by sending its credentials using special paramete= rs > (current draft) > B. Client authenticated by using HTTP Basic (or other schemes > supported by the server such as Digest) B is the right approach (limited to client credentials), but it requires a = lot more work than just moving the client credentials out to the header. To= do it right, the entire token endpoint needs to become more restful, and I= doubt it is something this group has an appetite for (except for James...)= . So A seems like an easier path to a final spec with B as a future cleanup= (basically a new set of flows). EHL From dick.hardt@gmail.com Sun May 9 22:34:25 2010 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 7E04B28C0FA for ; Sun, 9 May 2010 22:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, 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 Jn0bBxEfSz-X for ; Sun, 9 May 2010 22:34:24 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 7EDE528C11F for ; Sun, 9 May 2010 22:28:56 -0700 (PDT) Received: by pzk38 with SMTP id 38so1649686pzk.31 for ; Sun, 09 May 2010 22:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=nBEmBxUJhi9ORvLz0YJzbVZ3ACJmFIa6HwWIWUPW6AU=; b=UHFkQ8+rurSrB271yDs2fhAPg/ffICKGC3rOhhkZfogSLwOzyIpkFSslu4gG2Kwm4V tFR9+Ivl7oMh66//GuxREcaRjSI1kUnbN25us3tzrRWlKtQLvUor09xxgox/qgI8EQBf uF4CInXCW8P3d+BV0omZysxNka+XdfJ82QCn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=K60X7RDcC4leeGBefCFAHUY9wbgTPmJGHbHuoPWOmtNnio2n3OdIfKynKb4UH24cxJ UN14gy3H0TI8miXzmCVp7wSVV2mQy/mGcw3E1yV6yhck8mTt6Er4r2oFpc9szFPaAn4x JvEXqBBIIkHf6Ob0axxQYoouwN8IQ/ewEygl4= Received: by 10.114.162.24 with SMTP id k24mr2721942wae.158.1273469322267; Sun, 09 May 2010 22:28:42 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id 33sm23861125wad.20.2010.05.09.22.28.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 22:28:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 9 May 2010 22:28:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36F7CC05-9622-45C7-8840-D3B3CB78CFF3@gmail.com> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 05:34:25 -0000 >>>=20 >>> Right now it depends on the server. >>=20 >> The spec should clarify that. Suggested wording: >>=20 >>=20 >> If the client has previously registered a redirection URI with the = authorization >> server, the authorization server MUST verify that the redirection URI >> received matches the registered URI associated with the client = identifier. The >> components of the redirection URI that must match the registered URI = is >> authorization server dependant. >=20 > I don't see how that helps... I also don't see why we can't just = profile this and decide on how the matching should be done. We have the = state parameter to help too. Don't need to take my wording. We do need to explain the matching. >=20 >>>> 7. Refreshing an Access Token >>>>=20 >>>> I would suggest to add an optional "scope" parameter to this = request. >>>> This could be used to downgrade the scope associated with a token. >>>=20 >>> That would be the wrong way to do it given that people will expect = to also >> be able to upgrade scope. >>=20 >> Would you elaborate? Would not providing a scope parameter enable any >> potential change in scope to the access token? The change may be = neither an >> upgrade or downgrade, just different. >=20 > Downgrading scope is the only modification allowed without getting the = end-user involved again (or using any of the flows from the beginning). = When you refresh a token, you can ask to get a new token with less scope = because that will not conflict with the access grant. The client could downgrade and then upgrade again later, which would not = change the delegation granted by a user.=20 From eran@hueniverse.com Sun May 9 22:42:34 2010 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 410593A6AE3 for ; Sun, 9 May 2010 22:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 t9Gad4RkCERq for ; Sun, 9 May 2010 22:42:33 -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 729103A6B02 for ; Sun, 9 May 2010 22:40:49 -0700 (PDT) Received: (qmail 24683 invoked from network); 10 May 2010 05:40:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 May 2010 05:40:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 May 2010 22:40:38 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Sun, 9 May 2010 22:40:39 -0700 Thread-Topic: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt Thread-Index: AcrwAafXjDdbaOyXREecVHOGExmjUQAAYMkg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <36F7CC05-9622-45C7-8840-D3B3CB78CFF3@gmail.com> In-Reply-To: <36F7CC05-9622-45C7-8840-D3B3CB78CFF3@gmail.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 05:42:34 -0000 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, May 09, 2010 10:29 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt >=20 >=20 > >>> > >>> Right now it depends on the server. > >> > >> The spec should clarify that. Suggested wording: > >> > >> > >> If the client has previously registered a redirection URI with the > >> authorization server, the authorization server MUST verify that the > >> redirection URI received matches the registered URI associated with > >> the client identifier. The components of the redirection URI that > >> must match the registered URI is authorization server dependant. > > > > I don't see how that helps... I also don't see why we can't just profil= e this > and decide on how the matching should be done. We have the state > parameter to help too. >=20 > Don't need to take my wording. We do need to explain the matching. I agree we need to. Would you like to suggest more detailed rules? > > > >>>> 7. Refreshing an Access Token > >>>> > >>>> I would suggest to add an optional "scope" parameter to this request= . > >>>> This could be used to downgrade the scope associated with a token. > >>> > >>> That would be the wrong way to do it given that people will expect > >>> to also > >> be able to upgrade scope. > >> > >> Would you elaborate? Would not providing a scope parameter enable any > >> potential change in scope to the access token? The change may be > >> neither an upgrade or downgrade, just different. > > > > Downgrading scope is the only modification allowed without getting the > end-user involved again (or using any of the flows from the beginning). > When you refresh a token, you can ask to get a new token with less scope > because that will not conflict with the access grant. >=20 > The client could downgrade and then upgrade again later, which would not > change the delegation granted by a user. I think that will cause more confusion and problems than help. I am also no= t sure if there are real use cases for this limited capability. EHL From root@core3.amsl.com Sun May 9 22:45:19 2010 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2957E3A6B0C; Sun, 9 May 2010 22:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100510054516.2957E3A6B0C@core3.amsl.com> Date: Sun, 9 May 2010 22:45:02 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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, 10 May 2010 05:45:20 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-04.txt Pages : 51 Date : 2010-05-09 This specification describes the OAuth 2.0 protocol. OAuth provides a method for making authenticated HTTP requests using a token - an identifier used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-09223903.I-D@ietf.org> --NextPart-- From david@alkaline-solutions.com Sun May 9 23:39:59 2010 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 463993A6B48 for ; Sun, 9 May 2010 23:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.619 X-Spam-Level: ** X-Spam-Status: No, score=2.619 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.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 v1aAu6G4YA4e for ; Sun, 9 May 2010 23:39:58 -0700 (PDT) Received: from alkaline-solutions.com (208-78-100-23.slicehost.net [208.78.100.23]) by core3.amsl.com (Postfix) with ESMTP id 59F923A6B57 for ; Sun, 9 May 2010 23:39:32 -0700 (PDT) Received: from [192.168.3.2] (c-24-9-79-15.hsd1.co.comcast.net [24.9.79.15]) by alkaline-solutions.com (Postfix) with ESMTPSA id F313D11C0BA; Mon, 10 May 2010 06:39:20 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-212-961096513 From: David Waite In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 00:39:16 -0600 Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 06:39:59 -0000 --Apple-Mail-212-961096513 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote: >=20 > 1. Server Response Format >=20 > After extensive debate, we have a large group in favor of using JSON = as the only response format (current draft). We also have a smaller = group but with stronger feelings on the subject that JSON adds = complexity with no obvious value. >=20 > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an = optional request parameter I'm for A or B, but not so hot about C. Specifically (to throw my 2c = into the pot): - if form-encoded form or XML is an optional feature for servers to = implement, then general-purpose client libraries cannot be built to = expect them to be there.=20 - for that reason, it feels the alternate encodings are not there to = provide flexibility for client developers, but to allow implementations = of OAuth to use other encodings in their clients (and support them in = their servers) without the clients being considered out of spec = compliance. - as a security protocol, implementations might be concerned about = reducing their overall vulnerability surface area. It is plausible that = implementors on both sides would be more apt to not implement alternate = protocols if it means importing and exposing three libraries for = creating/consuming the encoded forms. > --- >=20 > 2. Client Authentication (in flows) >=20 > How should the client authenticate when making token requests? The = current draft defines special request parameters for sending client = credentials. Some have argued that this is not the correct way, and that = the client should be using existing HTTP authentication schemes to = accomplish that such as Basic. >=20 > A. Client authenticates by sending its credentials using special = parameters (current draft) > B. Client authenticated by using HTTP Basic (or other schemes = supported by the server such as Digest) Prefer B. - David Waite= --Apple-Mail-212-961096513 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

1. Server = Response Format

After extensive debate, we have a large group in = favor of using JSON as the only response format (current draft). We also = have a smaller group but with stronger feelings on the subject that JSON = adds complexity with no obvious value.

A. Form-encoded only = (original draft)
B. JSON only (current draft)
C. JSON as default = with form-encoded and XML available with an optional request = parameter

I'm for A or B, but not = so hot about C. Specifically (to throw my 2c into the = pot):

- if form-encoded form or XML is an = optional feature for servers to implement, then general-purpose client = libraries cannot be built to expect them to be there. 
- = for that reason, it feels the alternate encodings are not there to = provide flexibility for client developers, but to allow implementations = of OAuth to use other encodings in their clients (and support them in = their servers) without the clients being considered out of spec = compliance.
- as a security protocol, implementations might be = concerned about reducing their overall vulnerability surface area. It is = plausible that implementors on both sides would be more apt to not = implement alternate protocols if it means importing and exposing three = libraries for creating/consuming the encoded = forms.

---

2. Client Authentication (in = flows)

How should the client authenticate when making token = requests? The current draft defines special request parameters for = sending client credentials. Some have argued that this is not the = correct way, and that the client should be using existing HTTP = authentication schemes to accomplish that such as Basic.

A. = Client authenticates by sending its credentials using special parameters = (current draft)
B. Client authenticated by using HTTP Basic (or other = schemes supported by the server such as = Digest)

Prefer = B.

- David Waite
= --Apple-Mail-212-961096513-- From jsmarr@gmail.com Sun May 9 23:58:37 2010 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 063FE3A67F5 for ; Sun, 9 May 2010 23:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_50=0.001, 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 hj0sM5XiSauQ for ; Sun, 9 May 2010 23:58:35 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 13A3F3A6B4F for ; Sun, 9 May 2010 23:58:34 -0700 (PDT) Received: by pxi19 with SMTP id 19so1664662pxi.31 for ; Sun, 09 May 2010 23:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; bh=caWw9NuBwzY+O8mFIeuKUu9rXRNwsQ51O3BplWjOuhY=; b=t4TB7H6JoFc2OlB7YmXa70JtojAzz8GGBcA8/6Q6urPU+e4TTS69T73qYpVxQ1cl4q CboZ+mPnYE14hjIeWx7LBSzzOf/Z9H+8Gd+xSdBySkjv+zFCWf8bR9vlrZxeSvDickm9 vuy37uxqn/UcNxViQy6xNvYR6kPr5USVnPvXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=iz6N5SU76isT+owacuwKaGmgHy7x+GIbwXWiFdjKSjJ99vFKdm1HZARAIX08h5DrqG 39m7ZJS/X1Fw19Zm7juDjtarbv2FC8oSKjQR0kFLBY1DZOZUNWT1aMyMH5lV6oNCDcdY S9SdoOjrw5XZcs6SeV/JA/gguW2jCaMs1It6A= Received: by 10.142.3.41 with SMTP id 41mr2081869wfc.291.1273474699128; Sun, 09 May 2010 23:58:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.2.7 with HTTP; Sun, 9 May 2010 23:57:59 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Joseph Smarr Date: Sun, 9 May 2010 23:57:59 -0700 Message-ID: To: David Waite Content-Type: multipart/alternative; boundary=00504502c153127223048637efea Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jsmarr@stanfordalumni.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 06:58:37 -0000 --00504502c153127223048637efea Content-Type: text/plain; charset=ISO-8859-1 > 1. Server Response Format I vote for B, though I could live with C. (A would make me sad though) We've had a healthy and reasonable debate about the trade-offs here, but I think the main counterargument for requiring JSON support is that it's not quite yet a "no-brainer" to have JSON support in all environments (e.g. iPhone libraries currently would need to statically link in an available JSON library), whereas the counterarguments for A are the well-documented problems properly decoding url-encoded params from OAuth 1.0, plus the fact that it's not a common response format, whereas JSON (and XML) are. Since I think JSON will continue to increase in use for at least the next several years, the pain associated with requiring JSON is likely to be higher now than it will be in the future, and it's already low enough that we've had this debate about whether it's already acceptable or not-quite-yet. And JSON has been proven to "just work" in terms of avoiding encoding/decoding headaches in the wild, which for something like OAuth is really critical. > 2. Client Authentication (in flows) No strong opinion, but slight preference for A, perhaps with additional profiles to follow that support HTTP Basic/Digest if it really does become a problem in practice to do A. Main thing is that there *should* be some way for a client to exchange raw username/password credentials for a token, since this pattern is not going away anytime soon, and thus if we don't standardize it, we'll wish we had. On Sun, May 9, 2010 at 11:39 PM, David Waite wrote: > > On May 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote: > > > 1. Server Response Format > > After extensive debate, we have a large group in favor of using JSON as the > only response format (current draft). We also have a smaller group but with > stronger feelings on the subject that JSON adds complexity with no obvious > value. > > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional > request parameter > > > I'm for A or B, but not so hot about C. Specifically (to throw my 2c into > the pot): > > - if form-encoded form or XML is an optional feature for servers to > implement, then general-purpose client libraries cannot be built to expect > them to be there. > - for that reason, it feels the alternate encodings are not there to > provide flexibility for client developers, but to allow implementations of > OAuth to use other encodings in their clients (and support them in their > servers) without the clients being considered out of spec compliance. > - as a security protocol, implementations might be concerned about reducing > their overall vulnerability surface area. It is plausible that implementors > on both sides would be more apt to not implement alternate protocols if it > means importing and exposing three libraries for creating/consuming the > encoded forms. > > --- > > 2. Client Authentication (in flows) > > How should the client authenticate when making token requests? The current > draft defines special request parameters for sending client credentials. > Some have argued that this is not the correct way, and that the client > should be using existing HTTP authentication schemes to accomplish that such > as Basic. > > A. Client authenticates by sending its credentials using special parameters > (current draft) > B. Client authenticated by using HTTP Basic (or other schemes supported by > the server such as Digest) > > > Prefer B. > > - David Waite > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00504502c153127223048637efea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >=A01. Server Response Format

I vote for B, though I = could live with C. (A would make me sad though)

We= 've had a healthy and reasonable debate about the trade-offs here, but = I think the main counterargument for requiring JSON support is that it'= s not quite yet a "no-brainer" to have JSON support in all enviro= nments (e.g. iPhone libraries currently would need to statically link in an= available JSON library), whereas the counterarguments for A are the well-d= ocumented problems properly decoding url-encoded params from OAuth 1.0, plu= s the fact that it's not a common response format, whereas JSON (and XM= L) are. Since I think JSON will continue to increase in use for at least th= e next several years, the pain associated with requiring JSON is likely to = be =A0higher now than it will be in the future, and it's already low en= ough that we've had this debate about whether it's already acceptab= le or not-quite-yet. And JSON has been proven to "just work" in t= erms of avoiding encoding/decoding headaches in the wild, which for somethi= ng like OAuth is really critical.

>=A02. Client Authentication (in flows)
No strong opinion, but slight preference for A, perhaps with a= dditional profiles to follow that support HTTP Basic/Digest if it really do= es become a problem in practice to do A. Main thing is that there *should* = be some way for a client to exchange raw username/password credentials for = a token, since this pattern is not going away anytime soon, and thus if we = don't standardize it, we'll wish we had.

On Sun, May 9, 2010 at 11:39 PM, David = Waite <david@alkaline-solutions.com> wrote:

On May = 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote:

1. Server Response Format

= After extensive debate, we have a large group in favor of using JSON as the= only response format (current draft). We also have a smaller group but wit= h stronger feelings on the subject that JSON adds complexity with no obviou= s value.

A. Form-encoded only (original draft)
B. JSON only (current draft)C. JSON as default with form-encoded and XML available with an optional r= equest parameter

I'm for A o= r B, but not so hot about C. Specifically (to throw my 2c into the pot):

- if form-encoded form or XML is an optional feature fo= r servers to implement, then general-purpose client libraries cannot be bui= lt to expect them to be there.=A0
- for that reason, it feels the= alternate encodings are not there to provide flexibility for client develo= pers, but to allow implementations of OAuth to use other encodings in their= clients (and support them in their servers) without the clients being cons= idered out of spec compliance.
- as a security protocol, implementations might be concerned about red= ucing their overall vulnerability surface area. It is plausible that implem= entors on both sides would be more apt to not implement alternate protocols= if it means importing and exposing three libraries for creating/consuming = the encoded forms.

---
2. Client Authentication (in flows)

How should the client authe= nticate when making token requests? The current draft defines special reque= st parameters for sending client credentials. Some have argued that this is= not the correct way, and that the client should be using existing HTTP aut= hentication schemes to accomplish that such as Basic.

A. Client authenticates by sending its credentials using special parame= ters (current draft)
B. Client authenticated by using HTTP Basic (or oth= er schemes supported by the server such as Digest)

Prefer B.

=
- David Waite

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


--00504502c153127223048637efea-- From pid@pidster.com Mon May 10 01:12:21 2010 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 BE6CA28C149 for ; Mon, 10 May 2010 01:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 dxP+fz4d+vLO for ; Mon, 10 May 2010 01:12:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2735A3A6B7F for ; Mon, 10 May 2010 01:11:28 -0700 (PDT) Received: by wyb39 with SMTP id 39so879495wyb.31 for ; Mon, 10 May 2010 01:11:14 -0700 (PDT) Received: by 10.216.163.4 with SMTP id z4mr2152480wek.83.1273479074409; Mon, 10 May 2010 01:11:14 -0700 (PDT) Received: from Phoenix.local (cpc2-lewi13-2-0-cust269.2-4.cable.virginmedia.com [86.14.119.14]) by mx.google.com with ESMTPS id g17sm1383982wee.5.2010.05.10.01.11.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 May 2010 01:11:13 -0700 (PDT) Message-ID: <4BE7BF9A.2050209@pidster.com> Date: Mon, 10 May 2010 09:11:06 +0100 From: Pid Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: OAuth WG References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig387AF95805772EA00417EEFF" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pid@pidster.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 08:12:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig387AF95805772EA00417EEFF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/05/2010 07:57, Joseph Smarr wrote: >> 1. Server Response Format >=20 > I vote for B, though I could live with C. (A would make me sad though) > > We've had a healthy and reasonable debate about the trade-offs here, bu= t > I think the main counterargument for requiring JSON support is that it'= s > not quite yet a "no-brainer" to have JSON support in all environments > (e.g. iPhone libraries currently would need to statically link in an > available JSON library), whereas the counterarguments for A are the > well-documented problems properly decoding url-encoded params from OAut= h > 1.0, plus the fact that it's not a common response format, whereas JSON= > (and XML) are. Since I think JSON will continue to increase in use for > at least the next several years, the pain associated with requiring JSO= N > is likely to be higher now than it will be in the future, and it's > already low enough that we've had this debate about whether it's alread= y > acceptable or not-quite-yet. And JSON has been proven to "just work" in= > terms of avoiding encoding/decoding headaches in the wild, which for > something like OAuth is really critical. I don't believe this is an accurate summary. I asked for someone in the pro-JSON camp to describe the technical merits of that format over url encoded, but to date, there's no one who has responded. The options we've been offered seem contrived to support JSON, so instead I propose a more logical alternative: 4. urlencoded as the default, with optional JSON and XML p >> 2. Client Authentication (in flows) >=20 > No strong opinion, but slight preference for A, perhaps with additional= > profiles to follow that support HTTP Basic/Digest if it really does > become a problem in practice to do A. Main thing is that there *should*= > be some way for a client to exchange raw username/password credentials > for a token, since this pattern is not going away anytime soon, and thu= s > if we don't standardize it, we'll wish we had. >=20 > On Sun, May 9, 2010 at 11:39 PM, David Waite > > wr= ote: >=20 >=20 > On May 9, 2010, at 3:06 PM, Eran Hammer-Lahav wrote: >> >> 1. Server Response Format >> >> After extensive debate, we have a large group in favor of using >> JSON as the only response format (current draft). We also have a >> smaller group but with stronger feelings on the subject that JSON >> adds complexity with no obvious value. >> >> A. Form-encoded only (original draft) >> B. JSON only (current draft) >> C. JSON as default with form-encoded and XML available with an >> optional request parameter >=20 > I'm for A or B, but not so hot about C. Specifically (to throw my 2= c > into the pot): >=20 > - if form-encoded form or XML is an optional feature for servers to= > implement, then general-purpose client libraries cannot be built to= > expect them to be there.=20 > - for that reason, it feels the alternate encodings are not there t= o > provide flexibility for client developers, but to allow > implementations of OAuth to use other encodings in their clients > (and support them in their servers) without the clients being > considered out of spec compliance. > - as a security protocol, implementations might be concerned about > reducing their overall vulnerability surface area. It is plausible > that implementors on both sides would be more apt to not implement > alternate protocols if it means importing and exposing three > libraries for creating/consuming the encoded forms. >=20 >> --- >> >> 2. Client Authentication (in flows) >> >> How should the client authenticate when making token requests? The= >> current draft defines special request parameters for sending >> client credentials. Some have argued that this is not the correct >> way, and that the client should be using existing HTTP >> authentication schemes to accomplish that such as Basic. >> >> A. Client authenticates by sending its credentials using special >> parameters (current draft) >> B. Client authenticated by using HTTP Basic (or other schemes >> supported by the server such as Digest) >=20 > Prefer B. >=20 > - David Waite >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------enig387AF95805772EA00417EEFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQIVAwUBS+e/n2oM2OGpOvr9AQpj9g/+ISEAw4ZVBWZMmQMZXjbtdAzePct/hHjI 9R4teOdGQ942e/lE41J5BakjdTPFrgGn59oWzvisbOI1eD/pI/SrMAcgRPu2Rmxp 7pRRELEDg4xmovmxG3hCd76uhXy4DiQODivW6+5FPOZMEfbRbZbKrKQelTXsON8H DDmj8gHVQJHXSSn/jjMYIdCXKbR1CNuMU4/VIgEeAXyrcY6HADhkYB7FMW/nqYYz 0n/q3ojDxtF5m9iyNGDbnHDba4eh8c0fnUpTJEnViukUYTBFqMRVn4foy3YNfEGW Mz76qhacCD/RyLCZPCJCBjE7AW+t5/uj9F5k4qpokEpTON1vSl80BcqHdNt7NXCF SPFNPD9v8ZXATeaMKPervIZF0J/Xb15y+YZ3hFm/MAZP5NXpM4XB3QUFKdXMp5Pt xgtfmBxaUAfFT3ooPNOSWca9SI1LT3Yy46o8yQ3JPMhVhKngDh2EDLxqZcV09MTw Bz2vVi2gVREvc7ez0ldXJd4j7SPVFab5BI2XEmfu6YtGNtCX/uSknrncyxJswQkD RaEYwjnw66WqbPS9W3X1jWNdMZYe2RVFhgA/urxx5M485A9xPvwucODT3xe075ss WeDDzXTkWrfJcl6Klklmaqwut79fyopkY5vapq8t6gVw8aU3eG4RsDo2FC7jahTu lzg+qn8Y7mU= =gxs8 -----END PGP SIGNATURE----- --------------enig387AF95805772EA00417EEFF-- From bart.bv.vrancken@alcatel-lucent.com Mon May 10 01:29:05 2010 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 4EFBE28C14E for ; Mon, 10 May 2010 01:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=0.35] 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 xEZbLyv4tIIQ for ; Mon, 10 May 2010 01:29:04 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id BB51528C16A for ; Mon, 10 May 2010 01:28:18 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4A8QeY7024372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 May 2010 10:28:06 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 10 May 2010 10:27:35 +0200 From: "Vrancken, Bart bv (Bart)" To: "OAuth WG (oauth@ietf.org)" Date: Mon, 10 May 2010 10:27:34 +0200 Thread-Topic: [OAUTH-WG] delegating access to another client Thread-Index: Acrv6Up5fZGdb+bqR5eEQfFa1TwPbwAFt22gAAZQNeA= Message-ID: <7804DC3922510442A2F612A645323ED10A06B086@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3B@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 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [OAUTH-WG] delegating access to another client 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, 10 May 2010 08:29:05 -0000 You can find the idea of re-delegation on http://tools.ietf.org/id/draft-vr= ancken-oauth-redelegation-01.txt About the main concern that Eran is indicating, my view is that at the time= the user is authorizing the request giving authority to the client to act = on behalf of the user, the approval is clearly documented on the web server= . This could be done by giving the following options to the user: - The client may act on behalf of the user for every other possible client - The user could select the clients that may get authorization by that cli= ent. This could be similar to indicate some kind of scope in standard OAuth. Best regards, Bart -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: maandag 10 mei 2010 7:20 To: Dick Hardt; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] delegating access to another client Re-delegation is something people asked for since we started talking about = OAuth. There is also a draft I-D about it. This is explicitly out of scope = for the core spec (but not something that should stop us from having a disc= ussion). The main concern is how should the resource owner express their approval fo= r such arrangement? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dick Hardt > Sent: Sunday, May 09, 2010 7:34 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] delegating access to another client >=20 > Twitter has an interesting use case that may become common: one client > needs to delegate access to another client. Similar to the 'modify' metho= d > where the scope of the access token can be modified, the 'delegate' metho= d > allows a client to request delegation to another client (the delegate). H= ere is > some proposed copy for the request: >=20 > type > REQUIRED. The parameter value MUST be set to delegate >=20 > client_id > REQUIRED. The client identifier as described in Section 3.4. >=20 > client_secret > REQUIRED if the client was issued a secret. The client secret. >=20 > refresh_token > REQUIRED. The refresh token associated with the client. >=20 > delegate_id > REQUIRED. The client identifier of the delegate >=20 > scope > OPTIONAL. The scope the client is requesting for the delegate. >=20 > secret_type > OPTIONAL. The access token secret type as described by Section 8.3. > If omitted, the authorization server will issue a bearer token (an access= token > without a matching secret) as described by Section 8.2. >=20 > There a couple of choices for the flows for how a successful delegation i= s > conveyed to the delegate. The AS could return a delegation code that is > similar to a verification code and the delegate acquires an access token > similar to 3.6.2 Alternatively, the AS could return an delegation token t= hat is > used similar to a refresh token to obtain an access token and refresh tok= en. >=20 > Do people think this is worth adding to the spec? It seems to be a simple > addition and allows us to standardize what is emerging as a common > capability. >=20 > -- Dick > _______________________________________________ > 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 mark.mcgloin@ie.ibm.com Mon May 10 02:15:58 2010 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 8CB1A3A681F; Mon, 10 May 2010 02:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_50=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 AYByAz0hEzEm; Mon, 10 May 2010 02:15:57 -0700 (PDT) Received: from mtagate3.uk.ibm.com (mtagate3.uk.ibm.com [194.196.100.163]) by core3.amsl.com (Postfix) with ESMTP id D217128C163; Mon, 10 May 2010 02:15:50 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o4A9Faj6005039; Mon, 10 May 2010 09:15:36 GMT Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4A9FRx41404956; Mon, 10 May 2010 10:15:35 +0100 Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4A9FRQs022601; Mon, 10 May 2010 03:15:27 -0600 Received: from d06ml901.portsmouth.uk.ibm.com (d06ml901.portsmouth.uk.ibm.com [9.149.39.138]) by d06av06.portsmouth.uk.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o4A9FQvB022594; Mon, 10 May 2010 03:15:26 -0600 In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Lotus Notes Release 7.0 HF400 February 20, 2008 Message-ID: From: Mark Mcgloin Date: Mon, 10 May 2010 10:15:29 +0100 X-MIMETrack: Serialize by Router on D06ML901/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 10/05/2010 10:15:26 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "OAuth WG \(oauth@ietf.org\)" , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 09:15:58 -0000 > 1. Server Response Format No Preference > 2. Client Authentication (in flows) > A. Client authenticates by sending its credentials using special parameters (current draft) > B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest) Prefer B Mark From jricher@mitre.org Mon May 10 05:20:19 2010 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 7059828C1BB for ; Mon, 10 May 2010 05:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.665 X-Spam-Level: X-Spam-Status: No, score=-4.665 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 lRfeW+Y0-g62 for ; Mon, 10 May 2010 05:20:18 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id ADFDF28C1A7 for ; Mon, 10 May 2010 05:19:04 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4ACIq5w006131 for ; Mon, 10 May 2010 08:18:52 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4ACIqd9006128; Mon, 10 May 2010 08:18:52 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 10 May 2010 08:18:52 -0400 From: "Richer, Justin P." To: Eran Hammer-Lahav , David Recordon , Marius Scurtescu Date: Mon, 10 May 2010 08:18:33 -0400 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcruEAUKwnx3j4csRMOC6KIWXd2OkQBroXOAAB8Xdtw= Message-ID: References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> , <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@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: multipart/alternative; boundary="_000_D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62IMCMBX3MITREO_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 12:20:19 -0000 --_000_D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62IMCMBX3MITREO_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 Any information that the client needs to care about should live outside the= token. -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Sunday, May 09, 2010 5:29 PM To: David Recordon; Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid The idea of embedding this information into the token is wrong. This is cle= arly token metadata and that information belongs alongside the token, just = like =91expires_in=92. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= avid Recordon Sent: Friday, May 07, 2010 11:06 AM To: Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid Using SWT for your access tokens seems like a reasonable way to resolve thi= s for servers which care. On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu > wrote: Returning a scope parameter with issued tokens is not a bad idea. But this, and also the sites parameter suggested by James, can both potentially be solved with a transparent token format. Such a token can make explicit the: - expiry time - scopes - sites - etc. The Simple Web Token spec goes along these lines. SWT has a parameter called Audience, which I assumed would point to the client, but it could also represent "sites". Marius On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt > wrote: > Additionally, I would propose to indicate the scope associated with a tok= en > to the client using a scope response parameter. This is especially useful > (1) if the client did not pass a scope parameter but the server decided t= o > associate a scope based on its policy or (2) if the user decided to > authorize a subset of the requested scope only. > Regards, > Torsten. > > > > Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt > >: > > what about an additional realm response value? > > If there is a binding between realm and token, the client can decide base= d > on the realm attribute discovered using a WWW-Authenticate response which > token to use. > > regards, > Torsten. > > Am 07.05.2010 07:06, schrieb Manger, James H: > > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clie= nts > being told by the server about the sites at which the secret > (cookie/password/token) can be used (and, more importantly, where is must > not be used). This occurs without requiring service-specific knowledge in > the client app. OAuth aims to replace some of these uses. > > > > HTTP Basic authentication works safely from clients with no service-speci= fic > knowledge because the client knows not to send the password it gets from = the > user to other sites. > > > > HTTP Digest authentication allows a password to used to across a set of > domains specified in a WWW-Authenticate response header, but the password > will not be used at arbitrary other sites. > > > > Cookies are sent in requests to the same site, sites with the same parent= , > or only https sites, depending on details from the service when setting t= he > cookie. > > > > > > To date, OAuth has assumed every client app has lots of service-specific > knowledge to make these choices. OAuth needs to remove the need for so mu= ch > service-specific knowledge to be as interoperable as other standard auth > mechanism, otherwise it is a poor replacement. > > > > -- > > James Manger > > > > From: David Recordon [mailto:recordond@gmail.com] > Sent: Friday, 7 May 2010 2:05 PM > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > > > > Hey James, > > Do you have a specific example in mind where this either has been an issu= e > or will be an issue? Most client implementations I've seen of OAuth (and > technologies like OAuth) have a strong binding between the access token(s= ), > site they were issued by, and user they belong to. So I haven't heard of > this being a problem in the wild... > > > > --David > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62IMCMBX3MITREO_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1<= /font>
 
Any information that the = client needs to care about should live outside the token.
 
 -- Justin
 
From: oauth-bounces@ietf.org [oauth= -bounces@ietf.org] On Behalf Of Eran Hammer-Lahav [eran@hueniverse.com]
Sent: Sunday, May 09, 2010 5:29 PM
To: David Recordon; Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

The idea of embedding this information int= o the token is wrong. This is clearly token metadata and that information b= elongs alongside the token, just like =91expires_in=92.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@i= etf.org] On Behalf Of David Recordon
Sent: Friday, May 07, 2010 11:06 AM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

 

Using SWT for your access tokens seems like a reason= able way to resolve this for servers which care.

 

On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu &l= t;mscurtescu@google.com> wr= ote:

Returning a scope parameter with issued tokens is no= t a bad idea.

But this, and also the sites parameter suggested by James, can both
potentially be solved with a transparent token format. Such a token
can make explicit the:
- expiry time
- scopes
- sites
- etc.

The Simple Web Token spec goes along these lines. SWT has a parameter
called Audience, which I assumed would point to the client, but it
could also represent "sites".

Marius




On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt
<torsten@lodderstedt.net&= gt; wrote:
> Additionally, I would propose to indicate the scope associated with a = token
> to the client using a scope response parameter. This is especially use= ful
> (1) if the client did not pass a scope parameter but the server decide= d to
> associate a scope based on its policy or (2) if the user decided to > authorize a subset of the requested scope only.
> Regards,
> Torsten.
>
>
>
> Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt
> <torsten@lodderstedt.net= >:
>
> what about an additional realm response value?
>
> If there is a binding between realm and token, the client can decide b= ased
> on the realm attribute discovered using a WWW-Authenticate response wh= ich
> token to use.
>
> regards,
> Torsten.
>
> Am 07.05.2010 07:06, schrieb Manger, James H:
>
> Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on c= lients
> being told by the server about the sites at which the secret
> (cookie/password/token) can be used (and, more importantly, where is m= ust
> not be used). This occurs without requiring service-specific knowledge= in
> the client app. OAuth aims to replace some of these uses.
>
>
>
> HTTP Basic authentication works safely from clients with no service-sp= ecific
> knowledge because the client knows not to send the password it gets fr= om the
> user to other sites.
>
>
>
> HTTP Digest authentication allows a password to used to across a set o= f
> domains specified in a WWW-Authenticate response header, but the passw= ord
> will not be used at arbitrary other sites.
>
>
>
> Cookies are sent in requests to the same site, sites with the same par= ent,
> or only https sites, depending on details from the service when settin= g the
> cookie.
>
>
>
>
>
> To date, OAuth has assumed every client app has lots of service-specif= ic
> knowledge to make these choices. OAuth needs to remove the need for so= much
> service-specific knowledge to be as interoperable as other standard au= th
> mechanism, otherwise it is a poor replacement.
>
>
>
> --
>
> James Manger
>
>
>
> From: David Recordon [mailto:re= cordond@gmail.com]
> Sent: Friday, 7 May 2010 2:05 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
>
>
>
> Hey James,
>
> Do you have a specific example in mind where this either has been an i= ssue
> or will be an issue? Most client implementations I've seen of OAuth (a= nd
> technologies like OAuth) have a strong binding between the access toke= n(s),
> site they were issued by, and user they belong to. So I haven't heard = of
> this being a problem in the wild...
>
>
>
> --David
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

--_000_D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62IMCMBX3MITREO_-- From jricher@mitre.org Mon May 10 05:23:27 2010 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 600CB28C1E7 for ; Mon, 10 May 2010 05:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.484 X-Spam-Level: X-Spam-Status: No, score=-5.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 JeCYa46I-NdB for ; Mon, 10 May 2010 05:23:26 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 8A89A3A6BBC for ; Mon, 10 May 2010 05:20:55 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4ACKi8O007742 for ; Mon, 10 May 2010 08:20:44 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4ACKiKD007739; Mon, 10 May 2010 08:20:44 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 10 May 2010 08:20:44 -0400 From: "Richer, Justin P." To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Mon, 10 May 2010 08:18:56 -0400 Thread-Topic: User Endpoint Thread-Index: AcrvvMs8h1y92qj0QM61kvryHnnBEQAfisBs Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@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: Re: [OAUTH-WG] User Endpoint 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, 10 May 2010 12:23:27 -0000 So long as we keep some language in the text that this is the endpoint wher= e the authorization by the user takes place, this change makes sense to me.= People coming from OAuth 1 and similar schemes are going to be looking for= the "authorization" part, I think. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Sunday, May 09, 2010 5:15 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] User Endpoint I would like to rename the authorization endpoint to the user endpoint. Any= objections? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth= From jricher@mitre.org Mon May 10 06:06:40 2010 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 463A93A68AB for ; Mon, 10 May 2010 06:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.343 X-Spam-Level: X-Spam-Status: No, score=-4.343 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_50=0.001, 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 IXjwe2vL95aD for ; Mon, 10 May 2010 06:06:39 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id DD5993A68A0 for ; Mon, 10 May 2010 06:06:37 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4AD6Q9T018915 for ; Mon, 10 May 2010 09:06:26 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4AD6Q7x018904; Mon, 10 May 2010 09:06:26 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 10 May 2010 09:06:26 -0400 From: "Richer, Justin P." To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Mon, 10 May 2010 09:06:25 -0400 Thread-Topic: Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vAAhEOhM Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@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: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 13:06:40 -0000 1. Server Response Format A. Form-encoded only (original draft) B. JSON only (current draft) C. JSON as default with form-encoded and XML available with an optional r= equest parameter Vote for C, to be specified as: "Server MUST support JSON, form-encoded, an= d XML. Client MAY request any of the three, specified by a "format" paramet= er. Server will respond with JSON unless requested otherwise. Generic clien= t libraries SHOULD support all three." Other formats (say, LISP s-expressio= ns or Java Properties File format) can be specified through extensions that= define the encoding and the value of the "format" parameter to match. Gene= ration of valid data in these three formats is a much simpler problem than = parsing, so I'd wager this isn't much of an imposition on the servers. Pers= onally, I always found the form-encoded response a little strange, though I= agree with the notion of "keep it as simple as possible".=20 --- 2. Client Authentication (in flows) A. Client authenticates by sending its credentials using special paramet= ers (current draft) B. Client authenticated by using HTTP Basic (or other schemes supported = by the server such as Digest) Option A is absolutely still needed. I agree with Dick that OAuth should be= self-contained wherever possible. But that said, I can see value in someth= ing like B as well for some deployments. I propose that we actually define = a new flow for these cases, but instead of specifying Basic or Digest, we s= imply say that the client authenticates to the server using some out-of-ban= d authentication method. It expected by the OAuth bits that the AS knows wh= o the client represents by the time the request gets there. However the AS = figures that out can effectively be outside the realm of OAuth, which gives= us the ability to leverage Basic/Digest or other means (maybe even other O= Auth tokens?) to accomplish this. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth= From paul.madsen@gmail.com Mon May 10 06:21:05 2010 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 6D7C43A6956 for ; Mon, 10 May 2010 06:21:05 -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 xSsQ0igE3g-F for ; Mon, 10 May 2010 06:20:58 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id B9D043A694C for ; Mon, 10 May 2010 06:20:49 -0700 (PDT) Received: by yxe9 with SMTP id 9so2233257yxe.29 for ; Mon, 10 May 2010 06:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=7et+VilzOxxIoHOvbiJlgdJrTQh+DNk06VZkbLTqS1Y=; b=o8Ij2V+XkQd5Sv7FlWwTm000ryEfQvdRYDoLi/s9VRiURjX6I1zVvDe115JM/n/A4O TMiPj5lDR3Ys9yp0bwck8dGeL05WMcQ2ZWokzjQqFzOAIzi6k6EwNQg7OND+She8W8Dq 6bpRKbkVnrljNyGGmo3Uk1ggqYS8eA9DX5WN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=PioqYqG4VDttAp604hwj5gA8g5/NfbL8GvB08bQVzVnNCrjlSJd084+5AjHYFyy8GY eh3adgR2BdlPnjMjLoNJb6YunE2Eaev1ai//lOX9L9g5Qg+nIJYzRGuGU4kdqZ2MrXYw ePs1+ErXIjgIv/cRl5Vg8wze+AXaiYD0UxMAE= Received: by 10.231.153.130 with SMTP id k2mr2135185ibw.78.1273497635224; Mon, 10 May 2010 06:20:35 -0700 (PDT) Received: from [192.168.0.175] (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id bk12sm1594906ibb.2.2010.05.10.06.20.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 May 2010 06:20:34 -0700 (PDT) Message-ID: <4BE80820.7060907@gmail.com> Date: Mon, 10 May 2010 09:20:32 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <20100510054516.2957E3A6B0C@core3.amsl.com> In-Reply-To: <20100510054516.2957E3A6B0C@core3.amsl.com> Content-Type: multipart/alternative; boundary="------------090105040704060307080609" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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, 10 May 2010 13:21:05 -0000 This is a multi-part message in MIME format. --------------090105040704060307080609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit some feedback wrt the device flow - 'verification URI' and 'authorization URI' are used interchangeably - in the example messages, the verification code the client sends on its request for an access token is 'J2vC42OifV', not the same as that previously issued by the authorization server, namely '74tq5miHKB' - in the following, 'provided by the client' might confuse, as it was the end-user that provided the code to the authorization server (F) Assuming the end-user granted access, the authorization server validates the verification code provided by the client and responds back with the access token. - the text 'The end-user manually types' and other similar would seem to unnecessarily preclude other possible mechanisms by which the verification URI and user code might be passed between client & user-agent .... Related, is anybody thinking of a variant of the device flow where the user-agent sits on a device with QR-code capabilities, and so the user needn't type anything (uri or code)? paul On 5/10/2010 1:45 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Authentication Protocol Working Group of the IETF. > > > Title : The OAuth 2.0 Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-04.txt > Pages : 51 > Date : 2010-05-09 > > This specification describes the OAuth 2.0 protocol. OAuth provides > a method for making authenticated HTTP requests using a token - an > identifier used to denote an access grant with specific scope, > duration, and other attributes. Tokens are issued to third-party > clients by an authorization server with the approval of the resource > owner. OAuth defines multiple flows for obtaining a token to support > a wide range of client types and user experience. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090105040704060307080609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit some feedback wrt the device flow

- 'verification URI' and 'authorization URI' are used interchangeably

- in the example messages, the verification code the client sends on its request for an access token is 'J2vC42OifV', not the same as that previously issued by the authorization server, namely '74tq5miHKB'

- in the following, 'provided by the client' might confuse, as it was the end-user that provided the code to the authorization server
   (F)  Assuming the end-user granted access, the authorization server
        validates the verification code provided by the client and
        responds back with the access token.

- the text 'The end-user manually types' and other similar would seem to unnecessarily preclude other possible mechanisms by which the verification URI and user code might be passed between client & user-agent ....

Related, is anybody thinking of a variant of the device flow where the user-agent sits on a device with QR-code capabilities, and so the user needn't type anything (uri or code)?

paul

On 5/10/2010 1:45 AM, Internet-Drafts@ietf.org wrote: 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of the IETF.


	Title           : The OAuth 2.0 Protocol
	Author(s)       : E. Hammer-Lahav, et al.
	Filename        : draft-ietf-oauth-v2-04.txt
	Pages           : 51
	Date            : 2010-05-09

This specification describes the OAuth 2.0 protocol.  OAuth provides
a method for making authenticated HTTP requests using a token - an
identifier used to denote an access grant with specific scope,
duration, and other attributes.  Tokens are issued to third-party
clients by an authorization server with the approval of the resource
owner.  OAuth defines multiple flows for obtaining a token to support
a wide range of client types and user experience.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------090105040704060307080609-- From James.H.Manger@team.telstra.com Mon May 10 07:33:05 2010 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 231CC3A69D8 for ; Mon, 10 May 2010 07:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.395 X-Spam-Level: * X-Spam-Status: No, score=1.395 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f4rTnzZFCpB for ; Mon, 10 May 2010 07:33:03 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 27D663A68C7 for ; Mon, 10 May 2010 07:32:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,362,1270389600"; d="scan'208,217";a="2312636" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 11 May 2010 00:32:40 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5977"; a="1778072" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 11 May 2010 00:32:40 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 11 May 2010 00:32:39 +1000 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Tue, 11 May 2010 00:32:38 +1000 Thread-Topic: sites with wildcard Thread-Index: AcrwTaPsC4ggYQawSQ6EnsB9Iie0cQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E11263284E5B@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_255B9BB34FB7D647A506DC292726F6E11263284E5BWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] sites with wildcard 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, 10 May 2010 14:33:05 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11263284E5BWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIHZhcmlvdXMgd2F5cyB0byBpbmRpY2F0ZSB3aGVyZSBhIHRva2VuIGNhbiBiZSB1 c2VkICh3aGVuIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhIHRva2VuIHRvIGEgY2xp ZW50IGFwcCkuDQoNCg0KDQpBLiBMaXN0IG9mIFVSSSBwcmVmaXhlcw0KDQpCLiBMaXN0IG9mIHNj aGVtZTovL2hvc3RbOnBvcnRdIHR1cGxlcw0KDQpDLiBMaXN0IG9mIGRvbWFpbiBuYW1lcw0KDQpE LiBBbnkgb2YgdGhlIGFib3ZlIGxpc3RzIHdpdGggYSB3aWxkY2FyZCB0byBpbmNsdWRlIGFsbCBz dWItZG9tYWlucywgZWcg4oCcc2l0ZXPigJ06W+KAnGh0dHBzOi8vKi5leGFtcGxlLmNvbeKAnV0N Cg0KRS4gUmVndWxhciBleHByZXNzaW9uDQoNCg0KDQpJIGhhdmUgYmVlbiBzdWdnZXN0aW5nIChC KS4NCg0KSFRUUCBEaWdlc3QgdXNlcyAoQSkuIChBKSBpcyBhIHByZXR0eSBnb29kIG1hdGNoIHRv IGhvdyBHb29nbGUgdXNlcyBzY29wZSB2YWx1ZXMuDQoNCihDKSBpcyBhIGxpdHRsZSBzaW1wbGVy OyBidXQgdW5hY2NlcHRhYmxlIGJlY2F1c2Ugd2Ugc2hvdWxkIGRpc3Rpbmd1aXNoIEhUVFAgYW5k IEhUVFBTLg0KDQpBIHJlZ3VsYXIgZXhwcmVzc2lvbiAoRSkgY291bGQgZG8gdGhlIGpvYi4NCg0K KEQpIGNhbiBjb3ZlciBzb21lIHZpcnR1YWwgaG9zdGluZyBzaXR1YXRpb25zIHdoZXJlIGFsbW9z dCBhcmJpdHJhcnkgbnVtYmVycyBvZiBzdWItZG9tYWlucyBhcmUgY29udGludWFsbHkgY3JlYXRl ZCAoZWcgcGVyLXVzZXIgc3ViLWRvbWFpbnMpLiBFcmFuIGFza2VkIGZvciB3aWxkY2FyZHMuDQoN Cg0KDQpJZiBhIHdpbGRjYXJkIGlzIGFsbG93ZWQgSSBzdWdnZXN0IG9ubHkgYWxsb3dpbmcgYSBz aW5nbGUg4oCcKi7igJ0gcHJlZml4IHRvIHRoZSBkb21haW4gbmFtZS4gSXRzIHByZXNlbmNlIHdv dWxkIG1lYW4gYWxsIHN1Yi1kb21haW5zIChidXQgbm90IHRoZSBwYXJlbnQgZG9tYWluLCB3aGlj aCBjYW4gYmUgc3BlY2lmaWVkIHNlcGFyYXRlbHkgaWYgbmVlZGVkKS4gUHJvYmFibHkgZWFzaWVz dCB0byBpbmNsdWRlIHN1Yi1zdWItZG9tYWlucyBldGMuDQoNCg0KDQpJIGNvdWxkIGxpdmUgd2l0 aCBBLCBCLCBELCBvciBFIChqdXN0IG5vdCBDLCBhbmQgbm90IG5vdGhpbmcpLg0KDQoNCg0KU3Vn Z2VzdGVkIHRleHQgZm9yIEIrRCBmb3IgdGhlIEFjY2VzcyBUb2tlbiBSZXNwb25zZSBzZWN0aW9u Og0KDQoNCg0KDQoNCiAgc2l0ZXMNCg0KICAgIE9QVElPTkFMLiBBbiBhcnJheSBvZiBzdHJpbmdz IGluZGljYXRpbmcgdGhlIHNpdGVzIHdoZXJlIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4NCg0KDQoN ClRoZSBvcHRpb25hbCDigJxzaXRlc+KAnSBmaWVsZCBpbmRpY2F0ZXMgd2hlcmUgdGhlIGlzc3Vl ZCB0b2tlbiBjYW4gYmUgdXNlZC4gSXRzIHZhbHVlIGlzIGFuIGFycmF5IG9mIHN0cmluZ3MsIHdo ZXJlIGVhY2ggc3RyaW5nIG9iZXlzIHRoZSDigJxzaXRl4oCdIHByb2R1Y3Rpb24uIElmIHRoZSDi gJxzaXRlc+KAnSBmaWVsZCBpcyBhYnNlbnQgaXQgTVVTVCBiZSB0cmVhdGVkIGFzIHRob3VnaCB0 aGUgZmllbGQgd2FzIHByZXNlbnQgd2l0aCBhIHNpbmdsZSBzdHJpbmcgY29uc2lzdGluZyBvZiB0 aGUgc2NoZW1lLCBob3N0LCBhbmQgcG9ydCBvZiB0aGUgcmVxdWVzdCB0aGF0IHJldHVybmVkIHRo ZSB0b2tlbi4NCg0KDQoNCiAgc2l0ZSA6PSBzY2hlbWUg4oCcOi8v4oCdIFt3aWxkY2FyZCDigJwu 4oCdXSBob3N0IFvigJw64oCdIHBvcnRdDQoNCiAgd2lsZGNhcmQgOj0g4oCcKuKAnQ0KDQoNCg0K VGhlIHRva2VuIE1VU1QgTk9UIGJlIHVzZWQgd2l0aCBhIHJlcXVlc3QgdG8gYSBVUkkgdW5sZXNz IHRoZSBVUkkgbWF0Y2hlcyBhdCBsZWFzdCBvbmUgc3RyaW5nIGluIHRoZSDigJxzaXRlc+KAnSB2 YWx1ZS4gQSB0b2tlbiBTSE9VTEQgYmUgdXNlZCBwcmUtZW1wdGl2ZWx5IHdoZW4gdGhlIFVSSSBk b2VzIG1hdGNoLiBBIFVSSSBtYXRjaGVzIGEgc3RyaW5nIGlmIHRoZSBmb2xsb3dpbmcgY29uZGl0 aW9ucyBhcmUgYWxsIG1ldDoNCg0KMS4gVGhlIHNjaGVtZSBvZiB0aGUgVVJJIGFuZCBzdHJpbmcg YXJlIGVxdWFsLCBpZ25vcmluZyBjYXNlLg0KDQoyLiBUaGUgcG9ydCBudW1iZXIgb2YgdGhlIFVS SSBhbmQgc3RyaW5nIGFyZSBudW1lcmljYWxseSBlcXVhbCwgdXNpbmcgdGhlIGRlZmF1bHQgcG9y dCBudW1iZXIgZm9yIGEgc2NoZW1lIGlmIG5vIHBvcnQgaXMgc3BlY2lmaWVkIChlZyA0NDMgZm9y IGh0dHBzKS4NCg0KMy4gVGhlIGhvc3Qgb2YgdGhlIFVSSSBhbmQgc3RyaW5nIGFyZSBlcXVhbCwg aWdub3JpbmcgY2FzZSwgYW5kIChpZiB0aGUgd2lsZGNhcmQgaXMgcHJlc2VudCkgaWdub3Jpbmcg b25lIG9yIG1vcmUgbGVhZGluZyBkb21haW4gbGFiZWxzIG9mIHRoZSBVUkkgaG9zdC4NCg0KDQoN CkV4YW1wbGU6DQoNCg0KDQogIOKAnHNpdGVz4oCdOiBb4oCcaHR0cHM6Ly9hcGkuZXhhbXBsZS5j b23igJ0sIOKAnGh0dHBzOi8vKi5kYXRhLmV4YW1wbGUuY29t4oCdXQ0KDQoNCg0KVGhlIGZvbGxv d2luZyBVUklzIG1hdGNoIChzbyB0aGUgdG9rZW4gc2hvdWxkIGJlIHVzZWQpOg0KDQogIGh0dHBz Oi8vYXBpLmV4YW1wbGUuY29tOjQ0My94eXo/cT0xDQoNCiAgSFRUUFM6Ly9XV1cuSU1HLkRBVEEu RVhBTVBMRS5DT00vNzg2ODU2LmpwZw0KDQoNCg0KVGhlIGZvbGxvd2luZyBVUklzIGRvIE5PVCBt YXRjaCAoc28gdGhlIHRva2VuIG11c3Qgbm90IGJlIHVzZWQpOg0KDQogIGh0dHA6Ly9hcGkuZXhh bXBsZS5jb20vaW5kZXguaHRtbCAgKHdyb25nIHNjaGVtZSkNCg0KICBodHRwczovL2RhdGEuZXhh bXBsZS5jb20vNDI1NC5qc29uICAoaG9zdCBub3QgYSBzdWItZG9tYWluKQ0KDQoNCg0KLS0NCg0K SmFtZXMgTWFuZ2VyDQoNCg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E11263284E5BWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSB2YXJpb3VzIHdheXMgdG8g aW5kaWNhdGUgd2hlcmUgYSB0b2tlbiBjYW4gYmUgdXNlZCAod2hlbiBhbiBhdXRob3JpemF0aW9u IHNlcnZlciBpc3N1ZXMgYSB0b2tlbiB0byBhIGNsaWVudCBhcHApLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BLiBMaXN0IG9mIFVSSSBwcmVmaXhlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Qi4gTGlzdCBvZiBzY2hlbWU6Ly9ob3N0Wzpwb3J0XSB0dXBsZXM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMuIExpc3Qgb2YgZG9tYWluIG5hbWVzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ELiBBbnkgb2YgdGhlIGFib3ZlIGxp c3RzIHdpdGggYSB3aWxkY2FyZCB0byBpbmNsdWRlIGFsbCBzdWItZG9tYWlucywgZWcg4oCcc2l0 ZXPigJ06W+KAnGh0dHBzOi8vKi5leGFtcGxlLmNvbeKAnV08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkUuIFJlZ3VsYXIgZXhwcmVzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGhhdmUgYmVlbiBzdWdnZXN0aW5nIChCKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhUVFAgRGlnZXN0IHVzZXMgKEEpLiAoQSkgaXMgYSBwcmV0dHkgZ29vZCBt YXRjaCB0byBob3cgR29vZ2xlIHVzZXMgc2NvcGUgdmFsdWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KEMpIGlzIGEgbGl0dGxlIHNpbXBsZXI7IGJ1dCB1bmFjY2VwdGFi bGUgYmVjYXVzZSB3ZSBzaG91bGQgZGlzdGluZ3Vpc2ggSFRUUCBhbmQgSFRUUFMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHJlZ3VsYXIgZXhwcmVzc2lvbiAoRSkgY291 bGQgZG8gdGhlIGpvYi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihEKSBj YW4gY292ZXIgc29tZSB2aXJ0dWFsIGhvc3Rpbmcgc2l0dWF0aW9ucyB3aGVyZSBhbG1vc3QgYXJi aXRyYXJ5IG51bWJlcnMgb2Ygc3ViLWRvbWFpbnMgYXJlIGNvbnRpbnVhbGx5IGNyZWF0ZWQgKGVn IHBlci11c2VyIHN1Yi1kb21haW5zKS4gRXJhbiBhc2tlZCBmb3Igd2lsZGNhcmRzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JZiBhIHdpbGRjYXJkIGlzIGFsbG93ZWQgSSBzdWdnZXN0IG9ubHkg YWxsb3dpbmcgYSBzaW5nbGUg4oCcKi7igJ0gcHJlZml4IHRvIHRoZSBkb21haW4gbmFtZS4gSXRz IHByZXNlbmNlIHdvdWxkIG1lYW4gYWxsIHN1Yi1kb21haW5zIChidXQgbm90IHRoZSBwYXJlbnQg ZG9tYWluLCB3aGljaCBjYW4gYmUgc3BlY2lmaWVkIHNlcGFyYXRlbHkgaWYgbmVlZGVkKS4gUHJv YmFibHkgZWFzaWVzdCB0byBpbmNsdWRlIHN1Yi1zdWItZG9tYWlucw0KIGV0Yy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBjb3VsZCBsaXZlIHdpdGggQSwgQiwgRCwgb3IgRSAoanVzdCBub3Qg QywgYW5kIG5vdCBub3RoaW5nKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VnZ2VzdGVkIHRl eHQgZm9yIEImIzQzO0QgZm9yIHRoZSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2Ugc2VjdGlvbjo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgc2l0ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyBPUFRJT05BTC4gQW4gYXJyYXkgb2Ygc3RyaW5ncyBpbmRpY2F0 aW5nIHRoZSBzaXRlcyB3aGVyZSB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBvcHRpb25hbCDigJxzaXRlc+KAnSBmaWVsZCBpbmRpY2F0ZXMgd2hlcmUg dGhlIGlzc3VlZCB0b2tlbiBjYW4gYmUgdXNlZC4gSXRzIHZhbHVlIGlzIGFuIGFycmF5IG9mIHN0 cmluZ3MsIHdoZXJlIGVhY2ggc3RyaW5nIG9iZXlzIHRoZSDigJxzaXRl4oCdIHByb2R1Y3Rpb24u IElmIHRoZSDigJxzaXRlc+KAnSBmaWVsZCBpcyBhYnNlbnQgaXQgTVVTVCBiZSB0cmVhdGVkIGFz IHRob3VnaCB0aGUgZmllbGQgd2FzIHByZXNlbnQNCiB3aXRoIGEgc2luZ2xlIHN0cmluZyBjb25z aXN0aW5nIG9mIHRoZSBzY2hlbWUsIGhvc3QsIGFuZCBwb3J0IG9mIHRoZSByZXF1ZXN0IHRoYXQg cmV0dXJuZWQgdGhlIHRva2VuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgc2l0ZSA6 PSBzY2hlbWUg4oCcOi8v4oCdIFt3aWxkY2FyZCDigJwu4oCdXSBob3N0IFvigJw64oCdIHBvcnRd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgd2lsZGNhcmQgOj0g 4oCcKuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdG9rZW4gTVVTVCBOT1QgYmUgdXNl ZCB3aXRoIGEgcmVxdWVzdCB0byBhIFVSSSB1bmxlc3MgdGhlIFVSSSBtYXRjaGVzIGF0IGxlYXN0 IG9uZSBzdHJpbmcgaW4gdGhlIOKAnHNpdGVz4oCdIHZhbHVlLiBBIHRva2VuIFNIT1VMRCBiZSB1 c2VkIHByZS1lbXB0aXZlbHkgd2hlbiB0aGUgVVJJIGRvZXMgbWF0Y2guIEEgVVJJIG1hdGNoZXMg YSBzdHJpbmcgaWYgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIGFyZSBhbGwNCiBtZXQ6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBUaGUgc2NoZW1lIG9mIHRoZSBVUkkg YW5kIHN0cmluZyBhcmUgZXF1YWwsIGlnbm9yaW5nIGNhc2UuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4yLiBUaGUgcG9ydCBudW1iZXIgb2YgdGhlIFVSSSBhbmQgc3RyaW5n IGFyZSBudW1lcmljYWxseSBlcXVhbCwgdXNpbmcgdGhlIGRlZmF1bHQgcG9ydCBudW1iZXIgZm9y IGEgc2NoZW1lIGlmIG5vIHBvcnQgaXMgc3BlY2lmaWVkIChlZyA0NDMgZm9yIGh0dHBzKS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIFRoZSBob3N0IG9mIHRoZSBVUkkg YW5kIHN0cmluZyBhcmUgZXF1YWwsIGlnbm9yaW5nIGNhc2UsIGFuZCAoaWYgdGhlIHdpbGRjYXJk IGlzIHByZXNlbnQpIGlnbm9yaW5nIG9uZSBvciBtb3JlIGxlYWRpbmcgZG9tYWluIGxhYmVscyBv ZiB0aGUgVVJJIGhvc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4YW1wbGU6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyDigJxzaXRlc+KAnTogW+KAnGh0dHBzOi8vYXBpLmV4YW1w bGUuY29t4oCdLCDigJxodHRwczovLyouZGF0YS5leGFtcGxlLmNvbeKAnV08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGZvbGxvd2luZyBVUklzIG1hdGNoIChzbyB0aGUgdG9rZW4gc2hvdWxk IGJlIHVzZWQpOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGh0 dHBzOi8vYXBpLmV4YW1wbGUuY29tOjQ0My94eXo/cT0xPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgSFRUUFM6Ly9XV1cuSU1HLkRBVEEuRVhBTVBMRS5DT00vNzg2 ODU2LmpwZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZm9sbG93aW5nIFVSSXMgZG8gTk9U IG1hdGNoIChzbyB0aGUgdG9rZW4gbXVzdCBub3QgYmUgdXNlZCk6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgaHR0cDovL2FwaS5leGFtcGxlLmNvbS9pbmRleC5o dG1sJm5ic3A7ICh3cm9uZyBzY2hlbWUpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgaHR0cHM6Ly9kYXRhLmV4YW1wbGUuY29tLzQyNTQuanNvbiZuYnNwOyAoaG9z dCBub3QgYSBzdWItZG9tYWluKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E11263284E5BWSMSG3153Vsrv_-- From dick.hardt@gmail.com Mon May 10 07:57:00 2010 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 0CDA63A69A3 for ; Mon, 10 May 2010 07:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-0.171, 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 uc-BftGvDSFC for ; Mon, 10 May 2010 07:56:59 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B6A0D3A69DF for ; Mon, 10 May 2010 07:56:58 -0700 (PDT) Received: by pwj2 with SMTP id 2so1877176pwj.31 for ; Mon, 10 May 2010 07:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=3cuXqj6dtd49TVV29Twvx1C43yqAi8NQn+lFm4O3s5U=; b=IRWPF1PJTn8bq1VDuZB4l4e/vfvawhSjO8kwsg9RtAkV2WtCblxpHXhcqyoyNAXJjd ylUxg/34U6Tq/+V52bwtFcwLhorDRVhyQa8SasMvVo5urcScRVIE/tV6MjWL5HIsvXci 1tLaOaBeCOgnYHIa/2ogBiV468ZEJspZvYnWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MrqG3Rr0fgEgrWnDU+OQtgSY0bM++GYvlFypEo41QJwENK2ngsgwVPbMmhxkJg05uL 0UqHUvPUisaMfje6MVEA2NC/wcteXrG/4vo538NgVK2/CsjdNYx7MOXhH0l/j0NCLEQP pY+ntbgdcF/F8wbvoIXfBgw/vMUUmtbrKXH4k= Received: by 10.114.32.31 with SMTP id f31mr3210839waf.195.1273503402710; Mon, 10 May 2010 07:56:42 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id n32sm26545200wae.22.2010.05.10.07.56.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 May 2010 07:56:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4BE7BF9A.2050209@pidster.com> Date: Mon, 10 May 2010 07:56:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1222443C-7C2C-49C4-B03A-4E760538B4BB@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE7BF9A.2050209@pidster.com> To: pid@pidster.com X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 14:57:00 -0000 On 2010-05-10, at 1:11 AM, Pid wrote: > On 10/05/2010 07:57, Joseph Smarr wrote: >>> 1. Server Response Format >>=20 >> I vote for B, though I could live with C. (A would make me sad = though) >>=20 >> We've had a healthy and reasonable debate about the trade-offs here, = but >> I think the main counterargument for requiring JSON support is that = it's >> not quite yet a "no-brainer" to have JSON support in all environments >> (e.g. iPhone libraries currently would need to statically link in an >> available JSON library), whereas the counterarguments for A are the >> well-documented problems properly decoding url-encoded params from = OAuth >> 1.0, plus the fact that it's not a common response format, whereas = JSON >> (and XML) are. Since I think JSON will continue to increase in use = for >> at least the next several years, the pain associated with requiring = JSON >> is likely to be higher now than it will be in the future, and it's >> already low enough that we've had this debate about whether it's = already >> acceptable or not-quite-yet. And JSON has been proven to "just work" = in >> terms of avoiding encoding/decoding headaches in the wild, which for >> something like OAuth is really critical. >=20 > I don't believe this is an accurate summary. Are you saying the information is not accurate or not a complete = summary? >=20 > I asked for someone in the pro-JSON camp to describe the technical > merits of that format over url encoded, but to date, there's no one = who > has responded. per http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html client libraries exist to parse JSON responses client libraries do NOT exist to parse url encoded responses Implementations of both OAuth 1.0 and WRAP improperly decoded the = responses. >=20 > The options we've been offered seem contrived to support JSON, would you elaborate on why you think the options presented by the editor = were contrived?= From blowmage@gmail.com Mon May 10 08:11:41 2010 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 51A1D3A6403 for ; Mon, 10 May 2010 08:11:41 -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 4fVvz0e6iIKt for ; Mon, 10 May 2010 08:11:40 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id AB91B3A6994 for ; Mon, 10 May 2010 08:11:37 -0700 (PDT) Received: by qyk11 with SMTP id 11so5708559qyk.13 for ; Mon, 10 May 2010 08:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PhZrvoB2clvCfY2i4toj3yLuoh2S+esZUYcn6Ho/gtQ=; b=di5B6LFIpkvMMklMQZQAYHO/ekUJs9tnOev8tHMk3zMDog7VqbWb5KVWJzSCCjT67T RXoLoNfYQVRLYfHZ3sSJsEuMbZJIOhkW12Cv1LR0OccowEjxw+OZm39cuiPkCZ7Dq2Jz 8UJtqU88eFK67n7VlBJL2eue7exgbb22FaQo8= 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=Y94Ev3+QxEH/1pY6x9Qnj3lO4mK2B9KPNwp+WkV8ypl8uFGfM1UXtW46f/pxO4/zkX botCg3Ap7vz6DCkzObLSvI/RxGypLnG78o8/Fpr9ScXSC4hIyy1G8JPogN1QGzZisyUP ryWKqZdsm9krdnh2pEX0Kh+j7SIqmfQF+hieM= MIME-Version: 1.0 Received: by 10.224.49.77 with SMTP id u13mr2702588qaf.363.1273504283385; Mon, 10 May 2010 08:11:23 -0700 (PDT) Received: by 10.229.222.6 with HTTP; Mon, 10 May 2010 08:11:23 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 09:11:23 -0600 Message-ID: From: Mike Moore To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001485e7c9466e8d5204863ed2f4 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 15:11:41 -0000 --001485e7c9466e8d5204863ed2f4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 9, 2010 at 3:06 PM, Eran Hammer-Lahav wrote: > DEADLINE: 5/13 > > I would like to publish one more draft before our interim meeting in two > weeks (5/20). Below are two open issues we have on the list. Please reply > with your preference (or additional solutions) to each item. Issues with > consensus will be incorporated into the next draft. Those without will be > discussed at the meeting. > > EHL > > --- > > 1. Server Response Format > > After extensive debate, we have a large group in favor of using JSON as the > only response format (current draft). We also have a smaller group but with > stronger feelings on the subject that JSON adds complexity with no obvious > value. > > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional > request parameter > A, with both JSON and XML support via an optional extension. I'd prefer to keep the core spec as clean as possible, and I think form encoding does that. > --- > > 2. Client Authentication (in flows) > > How should the client authenticate when making token requests? The current > draft defines special request parameters for sending client credentials. > Some have argued that this is not the correct way, and that the client > should be using existing HTTP authentication schemes to accomplish that such > as Basic. > > A. Client authenticates by sending its credentials using special parameters > (current draft) > B. Client authenticated by using HTTP Basic (or other schemes supported by > the server such as Digest) > B, if possible. (I'm fairly convinced it is possible, but I'm not 100% sure yet.) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001485e7c9466e8d5204863ed2f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, May 9, 2010 at 3:06 PM, Eran Hammer-Laha= v <eran@huenive= rse.com> wrote:
DEADLINE: 5/13

I would like to publish one more draft before our interim meeting in two we= eks (5/20). Below are two open issues we have on the list. Please reply wit= h your preference (or additional solutions) to each item. Issues with conse= nsus will be incorporated into the next draft. Those without will be discus= sed at the meeting.

EHL

---

1. Server Response Format

After extensive debate, we have a large group in favor of using JSON as the= only response format (current draft). We also have a smaller group but wit= h stronger feelings on the subject that JSON adds complexity with no obviou= s value.

A. Form-encoded only (original draft)
B. JSON only (current draft)
C. JSON as default with form-encoded and XML available with an optional req= uest parameter

A, with both JSON and XM= L support via an optional extension. I'd prefer to keep the core spec a= s clean as possible, and I think form encoding does that.
=A0
---

2. Client Authentication (in flows)

How should the client authenticate when making token requests? The current = draft defines special request parameters for sending client credentials. So= me have argued that this is not the correct way, and that the client should= be using existing HTTP authentication schemes to accomplish that such as B= asic.

A. Client authenticates by sending its credentials using special parameters= (current draft)
B. Client authenticated by using HTTP Basic (or other schemes supported by = the server such as Digest)

B, if possib= le. (I'm fairly convinced it is possible, but I'm not 100% sure yet= .)
=A0
_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001485e7c9466e8d5204863ed2f4-- From Doug_Foiles@intuit.com Mon May 10 09:05:22 2010 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 F0FF03A69A0 for ; Mon, 10 May 2010 09:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[AWL=1.502, 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 z6dTdJ64DYIc for ; Mon, 10 May 2010 09:05:20 -0700 (PDT) Received: from mail2.intuit.com (mail2.intuit.com [12.149.175.12]) by core3.amsl.com (Postfix) with ESMTP id 271A23A67CC for ; Mon, 10 May 2010 09:05:20 -0700 (PDT) DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Return-Path: X-OriginalArrivalTime; b=looQ4dlbnFo+VUgZq382O+pJrkGAQhbkjlqgv46OFc+Qyw4Uj4Bz4R66 VhkhZ/HauAVSUml0YO4UUbQyPQpevobmgJOZZ4HXdQFwc7JO6Hpkhy9cw 7jwn/MlcP58PA95; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Doug_Foiles@intuit.com; q=dns/txt; s=default; t=1273507509; x=1305043509; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; z=MIME-Version:=201.0|Content-Transfer-Encoding:=20base64 |Subject:=20RE:=20[OAUTH-WG]=20Autonomous=20clients=20and =20resource=20owners=20(editorial)|Date:=20Mon,=2010=20Ma y=202010=2009:05:03=20-0700|Message-ID:=20 |In-Reply-To:=20<90C41DD21FB7C64BB94121FBBC2E72343B3AB46E 1A@P3PW5EX1MB01.EX1.SECURESERVER.NET>|References:=20<5DEB 74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intu it.net>=20=20<90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@P3PW 5EX1MB01.EX1.SECURESERVER.NET>=20=20<90C41DD2 1FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECUR ESERVER.NET>|From:=20"Foiles,=20Doug"=20|To:=20"Eran=20Hammer-Lahav"=20,=0D=0A=09"OAuth=20WG"=20; bh=1b5cXWw0rx6mYAXqIceEiJ/8dwnsfvdTHbPh2HK8gNE=; b=TLyHmmfJiIVGZZ3bt6bLwQS6EuGWttmYQmCY5uIsMLQWUStgbDJdO9bA tl+0iHALikqun71cBq5QuGWIubDbOjtvBGJRDUBKM5rw069iN9x4g5/CG ypfHN/49XXq/fn9; X-SBRS: None X-IronPort-AV: E=Sophos;i="4.52,362,1270450800"; d="scan'208";a="183805439" Received: from sdgexbh03.corp.intuit.net ([172.17.135.77]) by mail2.sdg.ie.intuit.com with ESMTP; 10 May 2010 09:05:04 -0700 Received: from SDGEXEVS07.corp.intuit.net ([172.17.135.1]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 May 2010 09:05:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 10 May 2010 09:05:03 -0700 Message-ID: In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Autonomous clients and resource owners (editorial) Thread-Index: AcrmIscm/BOC6W7iSh+JMT0dgGCAkgAALcx1AAY05pAAC/rNUADksrvwAWctR9AABTLR8AACRLXgACgwRrA= References: <5DEB74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intuit.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Foiles, Doug" To: "Eran Hammer-Lahav" , "OAuth WG" X-OriginalArrivalTime: 10 May 2010 16:05:03.0997 (UTC) FILETIME=[8D3082D0:01CAF05A] Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) 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, 10 May 2010 16:05:22 -0000 VGhhbmtzIGZvciB0aGUgY2xhcml0eSBFcmFuIGFuZCBJIHVuZGVyc3RhbmQuDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5A aHVlbml2ZXJzZS5jb21dIA0KU2VudDogU3VuZGF5LCBNYXkgMDksIDIwMTAgMTo1NyBQTQ0KVG86 IEZvaWxlcywgRG91ZzsgT0F1dGggV0cNClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIEF1dG9ub21v dXMgY2xpZW50cyBhbmQgcmVzb3VyY2Ugb3duZXJzIChlZGl0b3JpYWwpDQoNCg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEZvaWxlcywgRG91ZyBbbWFpbHRvOkRvdWdf Rm9pbGVzQGludHVpdC5jb21dDQo+IFNlbnQ6IFN1bmRheSwgTWF5IDA5LCAyMDEwIDE6MDcgUE0N Cj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRw0KPiBTdWJqZWN0OiBSRTogW09BVVRI LVdHXSBBdXRvbm9tb3VzIGNsaWVudHMgYW5kIHJlc291cmNlIG93bmVycw0KPiAoZWRpdG9yaWFs KQ0KPiANCj4gVGhhbmtzIGZvciBhZGRyZXNzaW5nIG15IHF1ZXN0aW9ucyBFcmFuLg0KPiANCj4g Rm9yIHRoZSBBc3NlcnRpb24gRmxvdyBJIHdvdWxkIGFzc3VtZSB0aGUgbGlmZXRpbWUgb2YgdGhl IGF1dGhvcml6YXRpb24gZ3JhbnQNCj4gd291bGQgYmUgdGhlIHNhbWUgd2l0aCBvciB3aXRob3V0 IHRoZSByZWZyZXNoIHRva2VuIHN1cHBvcnQuICBJdCBkb2Vzbid0DQo+IHNlZW0gdG8gbWUgbGlr ZSB0aGUgb3ZlcmFsbCBsaWZldGltZSBvZiB0aGUgYXV0aG9yaXphdGlvbiBncmFudCB3b3VsZCBj aGFuZ2UNCj4gYmFzZWQgdXBvbiB0aGUgdXNlIG9mIHRoZSByZWZyZXNoIHRva2VuLg0KDQpZb3Ug aGF2ZSB0aHJlZSBleHBpcmF0aW9uczoNCg0KLSBUaGUgYXNzZXJ0aW9uDQotIFRoZSBhY2Nlc3Mg dG9rZW4NCi0gVGhlIHJlZnJlc2ggdG9rZW4gKGlmIHByZXNlbnQpDQoNClRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBjYW4gaXNzdWUgYW4gYWNjZXNzIHRva2VuIHdpdGggYW55IGV4cGlyYXRpb24g YnV0IHNob3VsZCBub3QgaXNzdWUgZXhwaXJhdGlvbiBsYXRlciB0aGFuIHRoYXQgb2YgdGhlIGFz c2VydGlvbi4gQnV0IHN0aWxsLCB0aGVyZSBpcyBub3RoaW5nIHRvIHByZXZlbnQgdGhhdC4gVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIG1heSBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gd2l0aCBhIHNo b3J0ZXIgZXhwaXJhdGlvbiB0aGFuIHRoZSBhc3NlcnRpb24uIEluIHRoYXQgY2FzZSwgaXQgY2Fu IHJlcXVpcmUgdGhlIHVzZSBvZiB0aGUgc2FtZSBhc3NlcnRpb24gYWdhaW4gdG8gZ2V0IGFub3Ro ZXIgdG9rZW4sIG9yIGl0IGNhbiBpc3N1ZSBhIHJlZnJlc2ggdG9rZW4gdG8gYWNjb21wbGlzaCB0 aGUgc2FtZSB0aGluZy4NCg0KSSByZWplY3QgdGhlIGFyZ3VtZW50IHRoYXQgdGhlIGV4cGlyYXRp b24gcG9saWN5IChhbmQgZ2V0dGluZyBpdCBpbXBsZW1lbnRlZCBjb3JyZWN0bHkpIGhhcyBtdWNo IHRvIGRvIHdpdGggbWFraW5nIGEgcmVmcmVzaCB0b2tlbiBhdmFpbGFibGUgdG8gdGhlIHNlcnZl ciBhcyBhIHRvb2wuDQoNCkVITA0K From torsten@lodderstedt.net Mon May 10 10:34:17 2010 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 F094E3A6BFB for ; Mon, 10 May 2010 10:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 5OEUB7K0PdIg for ; Mon, 10 May 2010 10:34:17 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id 5C8CC3A6C11 for ; Mon, 10 May 2010 10:29:09 -0700 (PDT) Received: from p4fff0c18.dip.t-dialin.net ([79.255.12.24] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OBWmm-0000h7-Gr; Mon, 10 May 2010 19:28:56 +0200 Message-ID: <4BE84252.80006@lodderstedt.net> Date: Mon, 10 May 2010 19:28:50 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 17:34:18 -0000 Am 09.05.2010 23:06, schrieb Eran Hammer-Lahav: > DEADLINE: 5/13 > > I would like to publish one more draft before our interim meeting in two weeks (5/20). Below are two open issues we have on the list. Please reply with your preference (or additional solutions) to each item. Issues with consensus will be incorporated into the next draft. Those without will be discussed at the meeting. > > EHL > > --- > > 1. Server Response Format > > After extensive debate, we have a large group in favor of using JSON as the only response format (current draft). We also have a smaller group but with stronger feelings on the subject that JSON adds complexity with no obvious value. > > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional request parameter > I prefer B, but I also could live with C. If the WG chooses C, I would suggest to support all three formats for POST requests and responses. The default response format could be the format of the request sent by the client, additionally the client could indicate the desired format w/ a request parameter. That's propably a new option D? > --- > > 2. Client Authentication (in flows) > > How should the client authenticate when making token requests? The current draft defines special request parameters for sending client credentials. Some have argued that this is not the correct way, and that the client should be using existing HTTP authentication schemes to accomplish that such as Basic. > > A. Client authenticates by sending its credentials using special parameters (current draft) > B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest) > Clearly B, I'm fine with using HTTP authentication schemes for client authentication only. This is cleaner (and thus easier) than also using BASIC/DIGEST authentication for user credentials in the "Username and Password Flow". regards, Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Mon May 10 10:58:53 2010 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 38F903A6A5B for ; Mon, 10 May 2010 10:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.265 X-Spam-Level: X-Spam-Status: No, score=-100.265 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 LQz+tq6eyy-g for ; Mon, 10 May 2010 10:58:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id AB2923A6BFF for ; Mon, 10 May 2010 10:58:21 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o4AHw8pk013272 for ; Mon, 10 May 2010 10:58:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273514289; bh=XD0MB9r5YAbux7ADkykAFSqMZ+g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=u2ruSHh6gMyKOrqcjmGZ7sU+0zrwHYR1YiCvVkKfhTOVaGg/c9WXTVr+9ktDTffTJ gpcmsirri+ersrXMw0xBA== 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:content-transfer-encoding:x-system-of-record; b=PJFsWWtmhSm0sqSh53G8b0/Wm72NI+x/OVj62RDUFUMTwmTuDGkjVmPYcFly6HVVZ w2nBrX4Ua7S4wZ0hLEK8w== Received: from pxi19 (pxi19.prod.google.com [10.243.27.19]) by hpaq3.eem.corp.google.com with ESMTP id o4AHw6YB015835 for ; Mon, 10 May 2010 10:58:07 -0700 Received: by pxi19 with SMTP id 19so1974657pxi.31 for ; Mon, 10 May 2010 10:58:06 -0700 (PDT) Received: by 10.141.110.6 with SMTP id n6mr2886056rvm.163.1273514286102; Mon, 10 May 2010 10:58:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 10:57:46 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Mon, 10 May 2010 10:57:46 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] SWT for indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 17:58:53 -0000 Hi James, I was suggesting a transparent token format in general, SWT was just an example. Yes, SWT does have a few problems: - symmetric key encryption - URL encoded name/value pairs as format It can be easily extended to support public key crypto, but this will help only key management between the authorization server and the protected resources. The client does not really need to verify the signature. If the token was compromised then the protected resource will refuse it anyhow. It was also suggested to use JSON and then web safe base64 for the format. As a side note, I was thinking more about the suggested "sites" parameter. In practice that sites where an access token can be used is limited to what protected resources can decrypt or verify the token. An access token cannot be really used at the wrong site. A "sites" parameter could be a nice hint for the client, but not a security requirement. Marius On Sun, May 9, 2010 at 6:51 AM, Manger, James H wrote: > David & Marius, > > > >> Using SWT for your access tokens seems like a reasonable way to resolve >> this for servers which care. > > > > SWT is completely the wrong solution for this issue, if I understand it > correctly. > > > > I haven=92t followed the SWT work much, but my understanding is that it a= ids > interop between authorization and resource servers by defining a token > format. A crucial feature is a MAC, created by the authz server and verif= ied > by the resource server. > > > > A client app cannot have the secret key required to verify the signature > (MAC) in a SWT token. SWT is separate from WRAP (& OAuth) because it is a > private matter between servers -- which the client does not have to know > anything about. > > > > The commonality between this issue (=93sites=94 token response param) and= SWT is > that client apps and resource servers need to know some similar informati= on > about a token: such as where & when it can be used. > > > > Theoretically I guess we could mandate something like SWT (fleshed out wi= th > specifics) for tokens so clients and resource servers can get the info th= ey > need from the same field *in* the token. However, tokens that are opaque = to > clients (with the info they need in separate fields) is a much better > architecture (less coupling), even if some info gets repeated. > > > > > > P.S. I found SWT-v0.9.5 at > http://groups.google.com/group/oauth-wrap-wg/files. > > > > -- > > James Manger > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > David Recordon > Sent: Saturday, 8 May 2010 4:06 AM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > > > > Using SWT for your access tokens seems like a reasonable way to resolve t= his > for servers which care. > > > > On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu > wrote: > > Returning a scope parameter with issued tokens is not a bad idea. > > But this, and also the sites parameter suggested by James, can both > potentially be solved with a transparent token format. Such a token > can make explicit the: > - expiry time > - scopes > - sites > - etc. > > The Simple Web Token spec goes along these lines. SWT has a parameter > called Audience, which I assumed would point to the client, but it > could also represent "sites". > > Marius > > From mscurtescu@google.com Mon May 10 11:04:04 2010 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 DAE163A6964 for ; Mon, 10 May 2010 11:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.679 X-Spam-Level: X-Spam-Status: No, score=-104.679 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_40=-0.185, 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 nupEwpJGCuds for ; Mon, 10 May 2010 11:04:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 551F73A6A2B for ; Mon, 10 May 2010 11:03:35 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o4AI3NnD029675 for ; Mon, 10 May 2010 11:03:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273514603; bh=nosNpBZc60c8EyzwTfBuGOU/ANA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HInnMfs2B20/HQVgCQD6MbBTPFkpG+TNwLJYB1oAPioe8AbZP1WgAbpyVERmJ055m 5W/SLSu034aMy2s1T/4ZA== 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=o+PDIQEUti1IfZpUkgpX7JYE92Evnr9J4PN/5cpHU0B1LHCLBFmPfJ7RgtO4c+Ki1 Nx8+HbeKe06ZR0pBw8xPg== Received: from pvg13 (pvg13.prod.google.com [10.241.210.141]) by hpaq12.eem.corp.google.com with ESMTP id o4AI3LKh030274 for ; Mon, 10 May 2010 11:03:22 -0700 Received: by pvg13 with SMTP id 13so131397pvg.31 for ; Mon, 10 May 2010 11:03:21 -0700 (PDT) Received: by 10.141.108.16 with SMTP id k16mr2961544rvm.100.1273514600804; Mon, 10 May 2010 11:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 11:03:00 -0700 (PDT) In-Reply-To: <4BE80820.7060907@gmail.com> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <4BE80820.7060907@gmail.com> From: Marius Scurtescu Date: Mon, 10 May 2010 11:03:00 -0700 Message-ID: To: Paul Madsen Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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, 10 May 2010 18:04:04 -0000 On Mon, May 10, 2010 at 6:20 AM, Paul Madsen wrote: > Related, is anybody thinking of a variant of the device flow where the > user-agent sits on a device with QR-code capabilities, and so the user > needn't type anything (uri or code)? The end user will point their phone to the device screen and the phone browser will take it from there? I think the device still needs to show the URI and code as fallback, in case the user does not have a smart phone, right? Does the spec need to change in any way to support this? Isn't this just a particular implementation? Marius From mscurtescu@google.com Mon May 10 11:07:46 2010 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 B812A3A6C06 for ; Mon, 10 May 2010 11:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.849 X-Spam-Level: X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=0.128, 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 BhAMBSw7RIiD for ; Mon, 10 May 2010 11:07:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1F4843A6BF4 for ; Mon, 10 May 2010 11:06:48 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o4AI6aBs030404 for ; Mon, 10 May 2010 11:06:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273514796; bh=vhrwHOtnzPDEdjKYQwnn8m7z5g4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ozt5LZ8lg5r3N2LrxwUcbeCZrQhC+pz72LiDQNJwcFsevsSsOEo7ZnJDrR+gSj8/x MMOUWph8oM60PuQV0TxFg== 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:content-transfer-encoding:x-system-of-record; b=WRp/97BhNkGcygkc8HCiBmLTF1rl3EiZsA9iAUjnvn367eiuxTbkNKIHbH39f6U1Y aRhHjndM/k46eSwhFn9Sw== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by wpaz33.hot.corp.google.com with ESMTP id o4AI6ZtS013691 for ; Mon, 10 May 2010 11:06:35 -0700 Received: by pwj3 with SMTP id 3so1778889pwj.22 for ; Mon, 10 May 2010 11:06:34 -0700 (PDT) Received: by 10.140.252.10 with SMTP id z10mr2969180rvh.45.1273514794835; Mon, 10 May 2010 11:06:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 11:06:14 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0B@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 10 May 2010 11:06:14 -0700 Message-ID: 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] device profile comments 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, 10 May 2010 18:07:46 -0000 On Sun, May 9, 2010 at 10:12 AM, Eran Hammer-Lahav wr= ote: > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Eaton >> Sent: Monday, April 26, 2010 11:27 PM >> To: David Recordon >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] device profile comments >> >> New step E. >> >> "(E) After the end user grants or denies access, the Authorization Serve= r >> MAY redirect to a callback URL previously registered for the client. =A0= If the user >> denies access, the Authorization Server must append the query parameter >> "error=3Duser_denied" to the callback URL. >> The callback URL can be used to provide further instructions to the user= if >> necessary." > > If the client can receive callbacks, why use this flow? I think this is a generic callback page with information for this specific class of devices. The device itself cannot receive callbacks. Marius From mscurtescu@google.com Mon May 10 11:14:39 2010 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 B774A3A6A50 for ; Mon, 10 May 2010 11:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.108 X-Spam-Level: X-Spam-Status: No, score=-105.108 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_05=-1.11, 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 nsgpYqnwmY1h for ; Mon, 10 May 2010 11:14:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BA7473A6956 for ; Mon, 10 May 2010 11:12:18 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o4AIC5Y8007323 for ; Mon, 10 May 2010 11:12:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273515127; bh=FjeIZsUqmgct8MyLvHqsAxA9kN8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=rwCkuhfjNjyh2dv6loV8zQ2wF8G2b9xdf4NVKEOrV9vEq/lZF5DeXxtJhaIT74JdL o4aOFMcGD5IsY5uSd9pJQ== 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=m2lep3ZTFZ9mIPKfr7p/NC8PY5hGAmsyvGKGFrerxhDSQiqUjJZUb5gq5G55kwsu0 0sROaArN+q8JxSwwaThZQ== Received: from pzk41 (pzk41.prod.google.com [10.243.19.169]) by kpbe13.cbf.corp.google.com with ESMTP id o4AIC4gI011871 for ; Mon, 10 May 2010 11:12:04 -0700 Received: by pzk41 with SMTP id 41so1943531pzk.10 for ; Mon, 10 May 2010 11:12:04 -0700 (PDT) Received: by 10.141.108.15 with SMTP id k15mr2904902rvm.117.1273515124106; Mon, 10 May 2010 11:12:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 11:11:44 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1B@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 10 May 2010 11:11:44 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] explicit request for refresh 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, 10 May 2010 18:14:39 -0000 On Sun, May 9, 2010 at 2:00 PM, Eran Hammer-Lahav wrote: > Seems like extra complexity for little gain. The only benefit is saving server resources when a refresh token isn't going to be used by the client, but since most clients are likely to use it, the saving isn't much. You could be right, it all depends on how many clients will end up ignoring the refresh token. The only flow where most clients will probably ignore a refresh token, if ever sent by authz servers, is User-Agent. Saving server resources is one advantage, the other is making the flows a bit more secure, less chance to leak a very powerful token. Marius > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Tuesday, May 04, 2010 11:41 AM >> To: OAuth WG >> Subject: [OAUTH-WG] explicit request for refresh token >> >> Currently all flows return an optional refresh token and I think it was >> mentioned that the Autonomous Client flows should never return a refresh >> token. >> >> While a refresh token will probably be used in most cases by the other flows, >> in some cases the refresh token will be just ignored by the client. Ideally in >> these cases the refresh token is not issued at all. >> >> Also, Torsten suggested that when a new access token is requested then >> also a new refresh token is issued, this would allow the authorization server >> to detected if a refresh token was leaked and used by an attacker. However, >> this will not work in all cases. >> >> I suggest we add a parameter to the requests that normally issues the >> refresh token as a hint to the authorization server that the client wants a >> multi-use, single-use or no refresh token at all. This will be just a hint, the >> authorization server can decide how to proceed. >> >> For example, this parameter could look something like: >> - refresh_token_type = [none | multi | single] >> >> The default would be "none". "multi" is the normal refresh token and >> "single" is the refresh token suggested by Torsten. >> >> If the server does not support "single" type refresh tokens then it will issue a >> regular token and when the access token is renewed then it will not send a >> new refresh token. If for a certain flow or client the authz server does not >> want to issue refresh tokens at all then it can ignore the refresh_token_type >> request and just not issue one. If "multi" is requested then either "multi" or >> "none" should be issued. >> >> This refresh token type request parameter could be implemented as an >> extension as well. >> >> Thoughts? >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From pid@pidster.com Mon May 10 11:41:44 2010 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 5E3C13A6C8E for ; Mon, 10 May 2010 11:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=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 3CuRQNAv3eqG for ; Mon, 10 May 2010 11:41:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A72B03A6BF4 for ; Mon, 10 May 2010 11:34:02 -0700 (PDT) Received: by wwi18 with SMTP id 18so880837wwi.31 for ; Mon, 10 May 2010 11:33:50 -0700 (PDT) Received: by 10.227.134.194 with SMTP id k2mr4119630wbt.118.1273516430379; Mon, 10 May 2010 11:33:50 -0700 (PDT) Received: from Phoenix.local (94-193-98-41.zone7.bethere.co.uk [94.193.98.41]) by mx.google.com with ESMTPS id h22sm12031143wbh.3.2010.05.10.11.33.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 May 2010 11:33:49 -0700 (PDT) Message-ID: <4BE85186.1080401@pidster.com> Date: Mon, 10 May 2010 19:33:42 +0100 From: Pid Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: OAuth WG References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE7BF9A.2050209@pidster.com> <1222443C-7C2C-49C4-B03A-4E760538B4BB@gmail.com> In-Reply-To: <1222443C-7C2C-49C4-B03A-4E760538B4BB@gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCA7B3973E5CFBD38FE575FDA" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pid@pidster.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:41:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCA7B3973E5CFBD38FE575FDA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/05/2010 15:56, Dick Hardt wrote: >=20 > On 2010-05-10, at 1:11 AM, Pid wrote: >=20 >> On 10/05/2010 07:57, Joseph Smarr wrote: >>>> 1. Server Response Format >>> >>> I vote for B, though I could live with C. (A would make me sad though= ) >>> >>> We've had a healthy and reasonable debate about the trade-offs here, = but >>> I think the main counterargument for requiring JSON support is that i= t's >>> not quite yet a "no-brainer" to have JSON support in all environments= >>> (e.g. iPhone libraries currently would need to statically link in an >>> available JSON library), whereas the counterarguments for A are the >>> well-documented problems properly decoding url-encoded params from OA= uth >>> 1.0, plus the fact that it's not a common response format, whereas JS= ON >>> (and XML) are. Since I think JSON will continue to increase in use fo= r >>> at least the next several years, the pain associated with requiring J= SON >>> is likely to be higher now than it will be in the future, and it's >>> already low enough that we've had this debate about whether it's alre= ady >>> acceptable or not-quite-yet. And JSON has been proven to "just work" = in >>> terms of avoiding encoding/decoding headaches in the wild, which for >>> something like OAuth is really critical. >> >> I don't believe this is an accurate summary. >=20 > Are you saying the information is not accurate or not a complete summar= y? >=20 >> >> I asked for someone in the pro-JSON camp to describe the technical >> merits of that format over url encoded, but to date, there's no one wh= o >> has responded. >=20 > per http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html Is that the right message? There's not much in the way of positive arguments for JSON in that one. > client libraries exist to parse JSON responses Meaning a dependency. > client libraries do NOT exist to parse url encoded responses There aren't libraries to perform that type of decoding because it's trivial, (as you acknowledged). > Implementations of both OAuth 1.0 and WRAP improperly decoded the respo= nses. > Also with reference to: "many developers have been caught just splitting the parameters and forgetting to URL decode the token" With respect, I think this is pretty close to a straw man. It would be just as easy to argue that developers will make a mess of parsing JSON. Everyone seems to have, (in some cases grudgingly), agreed that it's easier to decode/parse urlencoded data than JSON. There are definitely occasions when using JSON for data description & transmission is advantageous, I just don't think this is one of them. It's a proverbial sledgehammer for a tiny OAuth nut. There should be something positive to say about JSON that establishes why it is a better format for this purpose. >> The options we've been offered seem contrived to support JSON, >=20 > would you elaborate on why you think the options presented by the edito= r were contrived? Sure. Two of them offer JSON as the default, including the putative 'compromise' option. JSON and XML add complexity, as the editor states. IMHO it's odd therefore not to select the least complex as the default, if multiple formats are offered. I appreciate that JSON is popular and there is a degree of devil's advocacy to my position here, (as I've already said), but if it's not possible to make a list of logical, positive statements in favour of the technical merits of JSON over the original format choice then it shouldn't be selected as the default. p --------------enigCA7B3973E5CFBD38FE575FDA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQIVAwUBS+hRi2oM2OGpOvr9AQpnug/9FkD1dUcs18ZhNGbuWJafZFNnP0wKG17Y CcqPH2mNe+2iGqcgwLzA84Af2wgq28+ZLMEsDA8WCr0HS8YXEcXMQ5Pa2/Hy4WNG niK/KpE0Vcf/F89f6de7diWv8w/zYTPrWZDCSvBq0EjwYSBqErSMOS1VmZlb6WOJ GZhDhYYW6eTZ19R8BycenWSWPSWh0uvVcvaCVqnUc+Zt/PV4w6a7zWEspaw/4p98 2dhsAAbqJaqn5vJ5nyFAUu+UVq5xGzRlO4+SNBcwMrhSsrW/Ta5nwNq7LDKDPELD bYQ8KmXBwt5A37lDx7FayZhc4iq7i+69uYganMN3Paq6WOLRbpExRtLPnp6rRKZD /sCLLiPjRAK8+U7fzeUDgxsNSXpE/frapOviJ5XMqNPyXOP6xrANWZOCVI6ZrLte gcrcwrMj/m4WepWMi8Zc6B30JbpS9aUW5FvYoNk+KbG3ctyCZLFGFKPyZCqAU5ns qUUBo4z1c7NARNJ7z7u1lteuHQpMZ9yjuUDPmT3uxpIg+T9Vt0D0pqMI91fdUoFP V5BpOsDg0IwIymNZ/BSbYCDHDiASvUU2YMLaYmx+QPzgFMwnXSIvb6cYeiPyAuDs wBTaHf61J4M03sV7NQRlyu4OWDFeNyg9TODRvLuLzvb2PiBa1g4xXEb3D2vM+6Y4 V6iDpd63SOQ= =Fn3S -----END PGP SIGNATURE----- --------------enigCA7B3973E5CFBD38FE575FDA-- From torsten@lodderstedt.net Mon May 10 12:27:50 2010 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 532873A6C2E for ; Mon, 10 May 2010 12:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[AWL=-1.354, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, J_CHICKENPOX_52=0.6] 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 bpjYsgF5flzX for ; Mon, 10 May 2010 12:27:48 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id 90B9528C1C7 for ; Mon, 10 May 2010 12:12:21 -0700 (PDT) Received: from p4fff0c18.dip.t-dialin.net ([79.255.12.24] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OBYOe-0003v1-O0; Mon, 10 May 2010 21:12:09 +0200 Message-ID: <4BE85A86.2020701@lodderstedt.net> Date: Mon, 10 May 2010 21:12:06 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 19:27:50 -0000 Am 10.05.2010 00:25, schrieb Eran Hammer-Lahav: > >> 3.2.1. Response Format >> >> The authorization server MUST include the HTTP "Cache-Control" >> response header field with a value of "no-store" in any response >> containing tokens, secrets, or other sensitive information. >> >> Would'nt it make sense to require "no-cache", too? >> > No idea. > I checked back with the rfc2616. I apparently misinterpreted the semantics of the field and withdraw the question :-) >> expires_in >> >> Why is there information passed back about the access tokens duration but >> not about the refresh tokens duration? >> > No one asked for that. Is there interest in specifying the authorization duration in addition to the token duration? > Hmmm, is most people's assumption that refresh tokens never expire? Our refresh tokens will expire. And if an application is interested to know the duration of the access token it will also consider the refresh tokens duration. Some people will probably ignore both data and wait until the access/refresh token gets rejected by the service/authorization server. So the error message "authorization_expired" of the "refresh" request is much more important. >> 3.4. Client Credentials >> >> The client credentials include a client identifier and >> an OPTIONAL symmetric shared secret. >> >> What is meant by "symmetric shared secret"? I'm familiar with the term >> "symmetric" in the context of cryptographical algorithms only. I think "shared >> secret" is sufficient. >> > Shared secret can be symmetric (password) or asymmetric (key pair). > Which secret is shared in the asymmetric case? > >> 3.5. User-Agent Flow >> >> These clients >> cannot keep client secrets confidential and the authentication of the >> client is based on the user-agent's same-origin policy. >> >> Does this still hold in the context of "HTTP Origin Headers" >> (http://www.petefreitag.com/item/702.cfm)? >> >> BTW: Will Brian's security considerations document be updated to be in sync >> with the draft? >> > Brian's document was written for WRAP. We need to write a full security review for 2.0 that is structure similarly to OAuth 1.0. > ---I copied the folliwing from other messages in this thread--- >Besides changing some terminology, I would think Brian's doc would be > mainly reusable. Perhaps you could insert a version with changes you > understand, then people can suggest changes that need to be made. >Since the security section is all non-normative language, it is the least important part on my list. Brian's document is useful but is not something I can work with>quickly. If someone wants to take a stab at converting it into a section that can be cut-and-paste into the draft, I would be very happy to incorporate it. Is reformatting this document really sufficient? I would like to assess the specification's security level from the perspective of our usage scenarios. What I miss in the document is a threat model of OAuth along with relations between possible threats and respective countermeasures. So do I have to built this model on my own? Or will there be a joint effort? >> 3.5.1.1. End-user Grants Authorization >> >> I would suggest to use JSON encoding here, since the URI fragment is >> handled by a client more or less like a response result. >> >> 3.6.1.1. End-user Grants Authorization >> >> Why not call the "code" Parameter "verification_code"? It's called verification >> code in the text. >> > Longer for no reason. > for the sake of clarity? > >> 3.6.2. Client Requests Access Token >> >> client_secret >> REQUIRED if the client identifier has a matching secret. The >> client secret as described in Section 3.4. >> >> 1) I'm having trouble to understand the meaning of "if the client identifier >> has a matching secret". Is the assumption underneath that authorization >> servers require this secrets from all clients they have issued a secret to? >> What about client w/o a secret? Are they also allowed to use this flow? >> Or is there envisioned a dependency >> between the client type, clients credentials and the flows a particular client is >> authorized to use? >> >> I would have expected a clear policy which flows require authentication and >> which not. >> Did you miss this question? >> 3.7.2. Client Requests Access Token >> >> "authorization_declined" >> >> Why does the spec interpret a request as bad request if the user just has >> declined the authorization? According to rfc2616 the semantics of >> 400 is: "The request could not be understood by the server due to >> malformed syntax". >> >> The calling client did not sent a malformed request, it cannot foresee or >> influence this outcome. I would suggest to either use status 403 or to return >> status code 200 for all syntactically correct and authorized request and to use >> another return codes in the response body to detail the requests outcome. >> Did you miss this question? >> 4. Username and Password Flow >> 4.1. Client Requests Access Token >> >> As statet in this section's introduction, this flow is intended to migrate >> existing clients from BASIC/DIGEST to OAuth. I therefore would suggest to >> use excactly these HTTP authentication schemes to transfer user credentials. >> This would mean to remove the parameters "username" >> and "password" and to use Authorization headers instead. At Deutsche >> Telekom, we have to deal with that class of clients. Such clients have already >> implemented their credential handling including header manipulation. The >> proposed change would further simplify their migration. >> > How would you send both client credentials and user credentials? Migration is only one example. > I withdraw this proposal. As I have written in my response to "Open Issues: Group Survey": I would leave the end-user credential handling as is in favour of using Authorization headers for client authentication only. This will convey clarity. >> 6. Assertion Flow >> >> This flow is suitable when the client is acting autonomously or on behalf of >> the end-user (based on the content of the assertion used). >> >> Let's assume the assertion attests an end-user's identity. How shall the >> authorization server determine the clients identity in this case? I would >> suggest to add optional client_id/client_secret parameters (or an >> Authorization header) for that case. >> > That's the whole point - it doesn't need it because it uses a different trust framework where the client identity is part of. > Could you please elaborate on the term trust framework? A SAML assertion contains at most one identity but we need two of them. Where should the second identity come from? >> 7. Refreshing an Access Token >> >> I would suggest to add an optional "scope" parameter to this request. >> This could be used to downgrade the scope associated with a token. >> > That would be the wrong way to do it given that people will expect to also be able to upgrade scope. > What would be the right way? >> 8.1. The Authorization Request Header >> >> I consider the name "Token" of the authentication schema much to generic. >> That was also the feedback of all colleagues I talked to about the upcoming >> standard. Why not call it "OAuth2"? >> > It is meant to be generic. I consider OAuth to be the part of the protocol dealing with getting a token. There will be many new ways to get a token in the future. > That's interesting! I consider the authentication scheme the major contribution of OAuth since it allows for a standardized way of service interaction. So 3rd party software components can be integrated into a companies infrastructure (incl. AS) w/o customization. Moreover, as you pointed out, there will be many other ways to get tokens in the future. > >> 8.2.2. Form-Encoded Body Parameter >> >> I would suggest to drop this section/feature. >> >> General note: Would it make sense to add explicit format handling to the >> OAuth API? If we envision authorization servers supporting more than one >> token format (e.g. SAML, SWT, ...), the client should given the option to >> request a certain format and responses returning access tokens should >> indicate the format of this token. The OAuth authorization header could also >> have an optional format attribute for the same purpose. >> > You mean token format? OAuth defined the token as opaque so that would be counter-productive. > I dont't mean OAuth shall define token formats. I just ask for a way to request tokens in a particular format and pass such meta data from AS to resource server via the client. Why is that counter-productive? Otherwise the resource server has to implement some token format discovery. regards, Torsten. > EHL > From mscurtescu@google.com Mon May 10 13:00:42 2010 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 9C42A3A6A55 for ; Mon, 10 May 2010 13:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.798 X-Spam-Level: X-Spam-Status: No, score=-100.798 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 3FjFtNceQFQl for ; Mon, 10 May 2010 13:00:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A24513A69F2 for ; Mon, 10 May 2010 12:49:05 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o4AJmrNn005621 for ; Mon, 10 May 2010 12:48:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273520933; bh=QckhUc/zI/OR+/uXguPZgzj1Mno=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=QXgQ+w6v4T+a4U/G+gkz+wsAklf6Us36/3bkZeediO/nSxf0kbcROJbrdIcq0kdM3 ZGx6XPLjJced8SFLzfS8Q== 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:content-transfer-encoding:x-system-of-record; b=BTOK9p83otJSb4/uSiEmQTyx/ds78IBPxE8qiduZPxNSIll15gqKrgfmhDf0CS4eW hhBTAzIybQ52XE3GpbbYQ== Received: from pvg4 (pvg4.prod.google.com [10.241.210.132]) by hpaq6.eem.corp.google.com with ESMTP id o4AJmokt030357 for ; Mon, 10 May 2010 12:48:51 -0700 Received: by pvg4 with SMTP id 4so456172pvg.38 for ; Mon, 10 May 2010 12:48:50 -0700 (PDT) Received: by 10.140.82.6 with SMTP id f6mr3008511rvb.74.1273520930446; Mon, 10 May 2010 12:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 12:48:30 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 10 May 2010 12:48:30 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] modifying the scope of an access 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, 10 May 2010 20:00:42 -0000 On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav wr= ote: > This would only work for the client credentials flow (because you keep th= e same authorization source). For all other flows you are breaking the auth= orization boundaries. If the requested scope is a subset of the original scope associated with the refresh token then it should be acceptable, right? This would allow a client to request a larger set of scopes, needed for all API calls need for its function, but then get sub-scoped access tokens, particular to each API. This will prevent an API from receiving a too powerful access token. A compromised API could use access tokens to place calls against other APIs, but not if it is narrowly scoped. Marius > > What would be useful is to allow asking for more scope. For example, when= asking for a token (the last step of each flow), also include a valid toke= n to get a new token with the combined scope (new approval and previous). > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Dick Hardt >> Sent: Sunday, May 09, 2010 7:19 PM >> To: OAuth WG (oauth@ietf.org) >> Subject: [OAUTH-WG] modifying the scope of an access token >> >> There has been some discussion about modifying the scope of the access >> token during a refresh. Perhaps we can add another "method" to what the >> AS MAY support that allows modifying the scope of an access token. Type = of >> request is "modify" and the scope parameter is required to indicate the = new >> scope required. Suggested copy below: >> >> type >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set to modify >> >> client_id >> =A0 =A0 =A0 REQUIRED. The client identifier as described in Section 3.4. >> >> client_secret >> =A0 =A0 =A0 REQUIRED if the client was issued a secret. The client secre= t. >> >> refresh_token >> =A0 =A0 =A0 REQUIRED. The refresh token associated with the access token= to be >> refreshed. >> >> scope >> =A0 =A0 =A0 REQUIRED. The new scope of the access request expressed as a= list >> of space-delimited strings. The value of the scope parameter is defined = by >> the authorization server. If the value contains multiple space-delimited >> strings, their order does not matter, and each string adds additional ac= cess >> range to the requested scope. >> >> secret_type >> =A0 =A0 =A0 OPTIONAL. The access token secret type as described by Secti= on 8.3. >> If omitted, the authorization server will issue a bearer token (an acces= s token >> without a matching secret) as described by Section 8.2. >> >> _______________________________________________ >> 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 mscurtescu@google.com Mon May 10 13:11:01 2010 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 90AEA3A6D32 for ; Mon, 10 May 2010 13:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.79 X-Spam-Level: X-Spam-Status: No, score=-100.79 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 J79uHqS3pQQ7 for ; Mon, 10 May 2010 13:11:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C357D28C298 for ; Mon, 10 May 2010 13:02:57 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o4AK2jds006737 for ; Mon, 10 May 2010 13:02:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273521765; bh=RcS66kS+t5Aqy5TGWM/XlbJH23A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=VYU0GZm/qouRElq3zJl+7R5SDdQIsNWz82ka3R2ksWD+z3qlnBm4+PWpc5gie30R/ Q3qi7WguMbOZEzw3qpuUQ== 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:content-transfer-encoding:x-system-of-record; b=lM0V3xwx7HstpbudvW3R/zoPpmfY/yhyM5zmm9ZDXvoPSqiwqXqB0Bb+1rs+iSZTL Z7Pl4u3hPv+lerF/XY7iw== Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by hpaq13.eem.corp.google.com with ESMTP id o4AK2hpw004200 for ; Mon, 10 May 2010 13:02:44 -0700 Received: by pwj8 with SMTP id 8so2915150pwj.24 for ; Mon, 10 May 2010 13:02:43 -0700 (PDT) Received: by 10.141.213.31 with SMTP id p31mr3039603rvq.21.1273521763107; Mon, 10 May 2010 13:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 13:02:23 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <36F7CC05-9622-45C7-8840-D3B3CB78CFF3@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 10 May 2010 13:02:23 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 20:11:01 -0000 On Sun, May 9, 2010 at 10:40 PM, Eran Hammer-Lahav wr= ote: >> >>>> 7. =A0Refreshing an Access Token >> >>>> >> >>>> I would suggest to add an optional "scope" parameter to this reques= t. >> >>>> This could be used to downgrade the scope associated with a token. >> >>> >> >>> That would be the wrong way to do it given that people will expect >> >>> to also >> >> be able to upgrade scope. >> >> >> >> Would you elaborate? Would not providing a scope parameter enable any >> >> potential change in scope to the access token? The change may be >> >> neither an upgrade or downgrade, just different. >> > >> > Downgrading scope is the only modification allowed without getting the >> end-user involved again (or using any of the flows from the beginning). >> When you refresh a token, you can ask to get a new token with less scope >> because that will not conflict with the access grant. >> >> The client could downgrade and then upgrade again later, which would not >> change the delegation granted by a user. > > I think that will cause more confusion and problems than help. I am also = not sure if there are real use cases for this limited capability. Not sure how downgrade then upgrade would work. I think down/up grade is always relative to the scope associated with the refreshed token. The refresh token never changes, so the base scope is always the same. Marius From mscurtescu@google.com Mon May 10 13:17:14 2010 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 0F6FB3A6AA0 for ; Mon, 10 May 2010 13:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.833 X-Spam-Level: X-Spam-Status: No, score=-105.833 tagged_above=-999 required=5 tests=[AWL=0.144, 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 SI4m0EZ0qVMc for ; Mon, 10 May 2010 13:17:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5559B3A6A21 for ; Mon, 10 May 2010 13:07:46 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o4AK7WZU031080 for ; Mon, 10 May 2010 13:07:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273522052; bh=E/6jRshXo7LtA8A+M4feUocHrvc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=TVV9D4jN6wGOhCzaFWGaGZ/WPSEEJRtuga2SCeVMJk/opvBPLc65O0/2BV9R92COf 67Pl8PGqgnbbnnXNBPIRA== 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:content-transfer-encoding:x-system-of-record; b=BWs9ZajZ+2Ne3wWpesYFMTxAxS2NcMVc/0G2xpJ4K1vbAGBjfElr9kxYZjSalI7PY gvom4uD8v0dhUYLWc4Yuw== Received: from pvb32 (pvb32.prod.google.com [10.241.209.96]) by wpaz13.hot.corp.google.com with ESMTP id o4AK7UmG023144 for ; Mon, 10 May 2010 13:07:30 -0700 Received: by pvb32 with SMTP id 32so153457pvb.5 for ; Mon, 10 May 2010 13:07:30 -0700 (PDT) Received: by 10.141.107.19 with SMTP id j19mr3031096rvm.90.1273522049114; Mon, 10 May 2010 13:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 13:07:09 -0700 (PDT) In-Reply-To: <4BE730CC.1090607@lodderstedt.net> References: <4BE730CC.1090607@lodderstedt.net> From: Marius Scurtescu Date: Mon, 10 May 2010 13:07:09 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 20:17:14 -0000 On Sun, May 9, 2010 at 3:01 PM, Torsten Lodderstedt wrote: > 3.5.1.1. =A0End-user Grants Authorization > > I would suggest to use JSON encoding here, since the URI fragment is hand= led > by a client more or less like a response result. Evan mentioned that returning JSON in this case is a bad idea because it is very hard to safely parse JSON in JavaScript. Marius From mscurtescu@google.com Mon May 10 13:28:54 2010 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 52A3B3A6C25 for ; Mon, 10 May 2010 13:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.783 X-Spam-Level: X-Spam-Status: No, score=-100.783 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 CLWo19V48IX2 for ; Mon, 10 May 2010 13:28:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9A0FD3A6823 for ; Mon, 10 May 2010 13:16:40 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o4AKGSHV032766 for ; Mon, 10 May 2010 13:16:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273522588; bh=pXpJh4s94pSMpayv/UpJW3dT2m8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=l0zPgGuRuxM9htilJ3N2SZ+IjLzIWEV/xQJvExl6JgtzhBNTqmp8VRvrSBVTDA32C ZDxGqp9/oQd23MW5t5SLA== 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:content-transfer-encoding:x-system-of-record; b=SrbFs7lttcJQ3Xt9B2uRO7DrtBtNirLt0A9Lv+XhHX9ten98bWN65j9O1AagN0A53 Gu7dPEmCIdIkCIW/U5rIA== Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by wpaz21.hot.corp.google.com with ESMTP id o4AKGQ5s017833 for ; Mon, 10 May 2010 13:16:26 -0700 Received: by pxi1 with SMTP id 1so1732336pxi.36 for ; Mon, 10 May 2010 13:16:26 -0700 (PDT) Received: by 10.141.187.25 with SMTP id o25mr2901009rvp.71.1273522586129; Mon, 10 May 2010 13:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 13:16:06 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 10 May 2010 13:16:06 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 20:28:54 -0000 On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav wr= ote: > >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Sunday, May 09, 2010 5:52 PM > >> >> 3.5.1. =A0Client Requests Authorization >> >> >> >> If the client has previously registered a redirection URI with the >> >> =A0 =A0authorization server, the authorization server MUST verify tha= t the >> >> =A0 =A0redirection URI received matches the registered URI associated= with >> >> =A0 =A0the client identifier. >> >> >> >> Does this mean equality? Or just the same base string? >> > >> > Right now it depends on the server. >> >> The spec should clarify that. Suggested wording: >> >> >> If the client has previously registered a redirection URI with the autho= rization >> server, the authorization server MUST verify that the redirection URI >> received matches the registered URI associated with the client identifie= r. The >> components of the redirection URI that must match the registered URI is >> authorization server dependant. > > I don't see how that helps... I also don't see why we can't just profile = this and decide on how the matching should be done. We have the state param= eter to help too. I also think the spec should specify how the matching should be done. If left up to the authz server then a client that designs its OAuth 2 implementation will have to assume that all authz servers will do strict equality matching, otherwise it may not be able to interact with some servers. For example, if the client assumes that it can use load balancing by varying the first part of the host name, and this may work with the fist authz server it integrate with, later this client will not be able to interact with an authz server which does strict matching on host name. And changing the load balancing architecture once deployed could be very hard. Since there is a state parameter maybe it is enough to allow wild cards only in the domain name of the callback URI. Marius From mscurtescu@google.com Mon May 10 13:30:29 2010 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 57FD63A6AA4 for ; Mon, 10 May 2010 13:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.521 X-Spam-Level: X-Spam-Status: No, score=-101.521 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Mm8CYk8Gvs9G for ; Mon, 10 May 2010 13:30:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id B010628C294 for ; Mon, 10 May 2010 13:18:55 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o4AKIh6X017690 for ; Mon, 10 May 2010 13:18:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273522723; bh=/wwpFR1p5AueOduut4/iUHHPTSI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=bLz2OP7fxCmyoo/HpATUtDNYpusZJ1M4w18y9P/KNeqPl284vacHVO9IpbQzQGD2P jhJ4Qqpqrr8ksBHfab1eQ== 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:content-transfer-encoding:x-system-of-record; b=Ls+9RQtXiP72Hkwp75Go3niY7jQ5ixdrbWbzyeg+BT4sB7uhYDMRTE6WdpsnWu/bC 3BACINZ5uqD5hXllL/yVg== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by hpaq12.eem.corp.google.com with ESMTP id o4AKIfOQ012215 for ; Mon, 10 May 2010 13:18:42 -0700 Received: by pzk28 with SMTP id 28so2003227pzk.11 for ; Mon, 10 May 2010 13:18:41 -0700 (PDT) Received: by 10.141.110.6 with SMTP id n6mr3007659rvm.163.1273522721128; Mon, 10 May 2010 13:18:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 13:18:21 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 10 May 2010 13:18:21 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 20:30:29 -0000 On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav wr= ote: > >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Sunday, May 09, 2010 5:52 PM > >> >> 8.1. =A0The Authorization Request Header >> >> >> >> I consider the name "Token" of the authentication schema much to >> generic. >> >> That was also the feedback of all colleagues I talked to about the >> >> upcoming standard. Why not call it "OAuth2"? >> > >> > It is meant to be generic. I consider OAuth to be the part of the prot= ocol >> dealing with getting a token. There will be many new ways to get a token= in >> the future. >> >> I also find the use of Token here. > > Find it...? I also think that "token" is too generic. Many new ways to get a token also mean many types of tokens. An OAuth 1 access token is not the same as an OAuth 2 access token. Marius From torsten@lodderstedt.net Mon May 10 13:31:55 2010 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 8C5B728C0E6 for ; Mon, 10 May 2010 13:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.682 X-Spam-Level: X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 1erBaYcbp9-R for ; Mon, 10 May 2010 13:31:54 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id 80E1628C0DD for ; Mon, 10 May 2010 13:21:22 -0700 (PDT) Received: from [79.255.12.24] (helo=[192.168.71.22]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OBZTR-000658-Is; Mon, 10 May 2010 22:21:09 +0200 References: <4BE730CC.1090607@lodderstedt.net> Message-Id: <38BB2577-B607-4033-A1C0-F8780DF47746@lodderstedt.net> From: Torsten Lodderstedt To: Marius Scurtescu In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Mon, 10 May 2010 22:20:46 +0200 X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 10 May 2010 20:31:55 -0000 Am 10.05.2010 um 22:07 schrieb Marius Scurtescu : > On Sun, May 9, 2010 at 3:01 PM, Torsten Lodderstedt > wrote: >> 3.5.1.1. End-user Grants Authorization >> >> I would suggest to use JSON encoding here, since the URI fragment >> is handled >> by a client more or less like a response result. > > Evan mentioned that returning JSON in this case is a bad idea because > it is very hard to safely parse JSON in JavaScript. > > Marius Native JSON support makes it easier. From beaton@google.com Mon May 10 14:46:07 2010 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 4466A3A69DC for ; Mon, 10 May 2010 14:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.313 X-Spam-Level: X-Spam-Status: No, score=-104.313 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km74pCXFW5HY for ; Mon, 10 May 2010 14:46:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5A6353A6902 for ; Mon, 10 May 2010 14:46:06 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o4ALjoAL017376 for ; Mon, 10 May 2010 14:45:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273527951; bh=GUJ1S3UfnUMCKoTIe94zGaGH1qs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=GIjME7/61lAW1tfC8PCmZp6OcvLLczvgQQf3jNbdKR469/MGtzonL9UEgKpI1e440 6f4BCyITGQxGqFqnZAhCg== 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=rklXE1DE/EgzUmnYbwBbcDAJDXejiPtA0n7byiG5h5F6lhOkJL6hmlve6MvHwgZIm 47rlmGcU6K3aEOkJ8Q/eg== Received: from pzk35 (pzk35.prod.google.com [10.243.19.163]) by hpaq5.eem.corp.google.com with ESMTP id o4ALjmEG000544 for ; Mon, 10 May 2010 14:45:49 -0700 Received: by pzk35 with SMTP id 35so1710219pzk.0 for ; Mon, 10 May 2010 14:45:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.25.38 with SMTP id c38mr3092606wfj.251.1273527947984; Mon, 10 May 2010 14:45:47 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Mon, 10 May 2010 14:45:47 -0700 (PDT) In-Reply-To: <10577de84bc497dea170055097bc0086@mail.gmail.com> References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <4BE1BB10.7060009@lodderstedt.net> <4BE1F2A1.9040707@pidster.com> <01bb1f595f89af50b0c37c00dbcd54cd@mail.gmail.com> <10577de84bc497dea170055097bc0086@mail.gmail.com> Date: Mon, 10 May 2010 14:45:47 -0700 Message-ID: From: Brian Eaton To: Greg Brail Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON (Proposal) 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, 10 May 2010 21:46:07 -0000 On Fri, May 7, 2010 at 11:29 AM, Greg Brail wrote: > JSONObject is fine. I imagine that any development organization could use it > in their project as long as their legal staff is willing to forgo the option > of doing Evil. (That's what the license says ;-) If the issue is purely the quirky licensing of the org.json code, gson should be an option: http://code.google.com/p/google-gson/ Cheers, Brian From jsmarr@gmail.com Mon May 10 15:36:00 2010 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 AC7363A68A9 for ; Mon, 10 May 2010 15:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, 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 CQDltdRuHdN6 for ; Mon, 10 May 2010 15:35:59 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id A937B3A68BC for ; Mon, 10 May 2010 15:35:57 -0700 (PDT) Received: by pzk38 with SMTP id 38so2144684pzk.31 for ; Mon, 10 May 2010 15:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; bh=rzO+or+q7USTCt9zakuxrQY/Y9VmlbiU06sjTqJSQWw=; b=IS1vzcvUTmX99O3L/mMegel7+cJCbAztkbpt9qs9sayMNyDP6+mWPS+6M2c4/akc4X rvSwbTAEHH3gc4y6iTMfNhGl586w/ODyfZOLVDgdpkOgeP7u4hPEMfcZzqIkdJ9Pi3Xm NPZfBzhxVkaqUqagc9QXwQWwaAjuc3QhbUIMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=twmthdGrB50I7KZYfiOGqYpAOJLlWnYS4MnoaG9585QriFtyEyNVyAGZtUGScfKej5 y8XyTB7pRaVRXheeGtJqUQ+l9vCWv/2tZzJCZU3LWsCbY79evx4Ha/86DNOSQPfM82Zm 3Tugn/xpek/DBr9d4aKfbqiUTjuPwHdkpCkhQ= Received: by 10.142.119.26 with SMTP id r26mr2975446wfc.257.1273530944119; Mon, 10 May 2010 15:35:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.2.7 with HTTP; Mon, 10 May 2010 15:35:24 -0700 (PDT) In-Reply-To: <4BE85186.1080401@pidster.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE7BF9A.2050209@pidster.com> <1222443C-7C2C-49C4-B03A-4E760538B4BB@gmail.com> <4BE85186.1080401@pidster.com> From: Joseph Smarr Date: Mon, 10 May 2010 15:35:24 -0700 Message-ID: To: pid@pidster.com Content-Type: multipart/alternative; boundary=001636e0b72288e47204864507a5 Cc: OAuth WG Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jsmarr@stanfordalumni.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 22:36:00 -0000 --001636e0b72288e47204864507a5 Content-Type: text/plain; charset=ISO-8859-1 Let me try to offer some of those "logical, positive statements in favour of the technical merits of JSON over the original format choice" for those that aren't familiar or haven't gleaned them from the thread thus far: - unambiguous spec for encoding/decoding (including how to represent spaces and unicode chars, both of which are common points of ambiguity in url-encoding that lead to bugs, confusion, and lack of ability to use built-in libraries, if available). For example, the OAuth PHP library does the following: return str_replace('+', ' ', str_replace('%7E', '~', rawurlencode($input)) -- yuck! - easier to read the encoded format (because it has clear sentinel braces, quoted attributes, and no url-encoding of parameters; only some backslashing of reserved chars) - widely available libraries with good track records in the wild, and increasingly built in to many platforms - extensible support for more representing more complex data structures in the future, if needed - simple enough that it's easy to understand, but just complex enough that it's not too tempting to roll your own parser (which leads empirically to better compliance due to use of common libraries) - more likely to be recognized and understood by developers, since they've seen it elsewhere in API response formats I think that about covers it. Again, it's an objective fact that url-encoding has caused confusion and bugs in OAuth 1.0 implementations, and it's also an objective fact that JSON has had a very high "just works" rate in the wild, to the point that it's the default API response format for many widely used APIs from large providers targeting many platforms. So this is not a choice based on "fashion", but based on trying to learn from history to increase developer success and remove the opportunity for subtle bugs, which was one of the major problems with OAuth 1.0a that prompted us to work on OAuth 2.0 in the first place. Thanks, js On Mon, May 10, 2010 at 11:33 AM, Pid wrote: > On 10/05/2010 15:56, Dick Hardt wrote: > > > > On 2010-05-10, at 1:11 AM, Pid wrote: > > > >> On 10/05/2010 07:57, Joseph Smarr wrote: > >>>> 1. Server Response Format > >>> > >>> I vote for B, though I could live with C. (A would make me sad though) > >>> > >>> We've had a healthy and reasonable debate about the trade-offs here, > but > >>> I think the main counterargument for requiring JSON support is that > it's > >>> not quite yet a "no-brainer" to have JSON support in all environments > >>> (e.g. iPhone libraries currently would need to statically link in an > >>> available JSON library), whereas the counterarguments for A are the > >>> well-documented problems properly decoding url-encoded params from > OAuth > >>> 1.0, plus the fact that it's not a common response format, whereas JSON > >>> (and XML) are. Since I think JSON will continue to increase in use for > >>> at least the next several years, the pain associated with requiring > JSON > >>> is likely to be higher now than it will be in the future, and it's > >>> already low enough that we've had this debate about whether it's > already > >>> acceptable or not-quite-yet. And JSON has been proven to "just work" in > >>> terms of avoiding encoding/decoding headaches in the wild, which for > >>> something like OAuth is really critical. > >> > >> I don't believe this is an accurate summary. > > > > Are you saying the information is not accurate or not a complete summary? > > > >> > >> I asked for someone in the pro-JSON camp to describe the technical > >> merits of that format over url encoded, but to date, there's no one who > >> has responded. > > > > per http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html > > Is that the right message? There's not much in the way of positive > arguments for JSON in that one. > > > > client libraries exist to parse JSON responses > > Meaning a dependency. > > > > client libraries do NOT exist to parse url encoded responses > > There aren't libraries to perform that type of decoding because it's > trivial, (as you acknowledged). > > > > Implementations of both OAuth 1.0 and WRAP improperly decoded the > responses. > > Also with reference to: "many developers have been caught just > splitting the parameters and forgetting to URL decode the token" > > With respect, I think this is pretty close to a straw man. It would be > just as easy to argue that developers will make a mess of parsing JSON. > > > > Everyone seems to have, (in some cases grudgingly), agreed that it's > easier to decode/parse urlencoded data than JSON. > > There are definitely occasions when using JSON for data description & > transmission is advantageous, I just don't think this is one of them. > It's a proverbial sledgehammer for a tiny OAuth nut. > > > There should be something positive to say about JSON that establishes > why it is a better format for this purpose. > > > >> The options we've been offered seem contrived to support JSON, > > > > would you elaborate on why you think the options presented by the editor > were contrived? > > Sure. Two of them offer JSON as the default, including the putative > 'compromise' option. > > JSON and XML add complexity, as the editor states. IMHO it's odd > therefore not to select the least complex as the default, if multiple > formats are offered. > > > > I appreciate that JSON is popular and there is a degree of devil's > advocacy to my position here, (as I've already said), but if it's not > possible to make a list of logical, positive statements in favour of the > technical merits of JSON over the original format choice then it > shouldn't be selected as the default. > > > p > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001636e0b72288e47204864507a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let me try to offer some of those "logical, positive statements in favou= r of the=A0technical merits of JSON over the original format choice" f= or those that aren't familiar or haven't gleaned them from the thre= ad thus far:

- unambiguous spec for encoding/decoding (including how to r= epresent spaces and unicode chars, both of which are common points of ambig= uity in url-encoding that lead to bugs, confusion, and lack of ability to u= se built-in libraries, if available). For example, the OAuth PHP library do= es the following:=A0return str_= replace('+', ' &#= 39;, str_replace('%7E', '~', rawurlencode($input)) -- yuck!

- easier to read the encoded format (because it has cle= ar=A0sentinel=A0braces, quoted attributes, and no url-encoding of parameter= s; only some backslashing of reserved chars)

- wid= ely available libraries with good track records in the wild, and increasing= ly built in to many platforms

- extensible support for more representing more complex= data structures in the future, if needed

- simple= enough that it's easy to understand, but just complex enough that it&#= 39;s not too tempting to roll your own parser (which leads empirically to b= etter compliance due to use of common libraries)

- more likely to be recognized and understood by develo= pers, since they've seen it elsewhere in API response formats

I think that about covers it. Again, it's an objective = fact that url-encoding has caused confusion and bugs in OAuth 1.0 implement= ations, and it's also an objective fact that JSON has had a very high &= quot;just works" rate in the wild, to the point that it's the defa= ult API response format for many widely used APIs from large providers targ= eting many platforms. So this is not a choice based on "fashion",= but based on trying to learn from history to increase developer success an= d remove the opportunity for subtle bugs, which was one of the major proble= ms with OAuth 1.0a that prompted us to work on OAuth 2.0 in the first place= .

Thanks, js

On = Mon, May 10, 2010 at 11:33 AM, Pid <pid@pidster.com> wrote:
On 10/05/2010 15:56, Dick Hardt wrote: >
> On 2010-05-10, at 1:11 AM, Pid wrote:
>
>> On 10/05/2010 07:57, Joseph Smarr wrote:
>>>> 1. Server Response Format
>>>
>>> I vote for B, though I could live with C. (A would make me sad= though)
>>>
>>> We've had a healthy and reasonable debate about the trade-= offs here, but
>>> I think the main counterargument for requiring JSON support is= that it's
>>> not quite yet a "no-brainer" to have JSON support in= all environments
>>> (e.g. iPhone libraries currently would need to statically link= in an
>>> available JSON library), whereas the counterarguments for A ar= e the
>>> well-documented problems properly decoding url-encoded params = from OAuth
>>> 1.0, plus the fact that it's not a common response format,= whereas JSON
>>> (and XML) are. Since I think JSON will continue to increase in= use for
>>> at least the next several years, the pain associated with requ= iring JSON
>>> is likely to be =A0higher now than it will be in the future, a= nd it's
>>> already low enough that we've had this debate about whethe= r it's already
>>> acceptable or not-quite-yet. And JSON has been proven to "= ;just work" in
>>> terms of avoiding encoding/decoding headaches in the wild, whi= ch for
>>> something like OAuth is really critical.
>>
>> I don't believe this is an accurate summary.
>
> Are you saying the information is not accurate or not a complete summa= ry?
>
>>
>> I asked for someone in the pro-JSON camp to describe the technical=
>> merits of that format over url encoded, but to date, there's n= o one who
>> has responded.
>
> per http://www.ietf.org/mail-archive/web/oauth/cur= rent/msg01992.html

Is that the right message? =A0There's not much in the way o= f positive
arguments for JSON in that one.


> client libraries exist to parse JSON responses

Meaning a dependency.


> client libraries do NOT exist to parse url encoded responses

There aren't libraries to perform that type of decoding because i= t's
trivial, (as you acknowledged).


> Implementations of both OAuth 1.0 and WRAP improperly decoded the resp= onses.
> Also with reference to: "many developers have been caught j= ust
splitting the parameters and forgetting to URL decode the token"

With respect, I think this is pretty close to a straw man. =A0It would be just as easy to argue that developers will make a mess of parsing JSON.



Everyone seems to have, (in some cases grudgingly), agreed that it's easier to decode/parse urlencoded data than JSON.

There are definitely occasions when using JSON for data description & transmission is advantageous, I just don't think this is one of them. It's a proverbial sledgehammer for a tiny OAuth nut.


There should be something positive to say about JSON that establishes
why it is a better format for this purpose.


>> The options we've been offered seem contrived to support JSON,=
>
> would you elaborate on why you think the options presented by the edit= or were contrived?

Sure. =A0Two of them offer JSON as the default, including the putativ= e
'compromise' option.

JSON and XML add complexity, as the editor states. =A0IMHO it's odd
therefore not to select the least complex as the default, if multiple
formats are offered.



I appreciate that JSON is popular and there is a degree of devil's
advocacy to my position here, (as I've already said), but if it's n= ot
possible to make a list of logical, positive statements in favour of the technical merits of JSON over the original format choice then it
shouldn't be selected as the default.


p





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


--001636e0b72288e47204864507a5-- From jsmarr@gmail.com Mon May 10 15:38:48 2010 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 7D9AD28C210 for ; Mon, 10 May 2010 15:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_50=0.001, 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 Jqdzg8y7R2g6 for ; Mon, 10 May 2010 15:38:46 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id AC8FF28C20F for ; Mon, 10 May 2010 15:38:46 -0700 (PDT) Received: by pzk38 with SMTP id 38so2145723pzk.31 for ; Mon, 10 May 2010 15:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; bh=be+4r5gOtMfMpNIlCJAsfDaaLwD/e0JjmjPG6mLbgyQ=; b=trZFLzzxqmNinmF/SZOJ8NnIcwuEmaeJS/oOsJSorIZ1MkYcrjmE33AoR5YZdMHqI5 4RugpYtj0F59E/cUMf4gv852vrU2Bk8dhrHAsbf0WU4R3WdJgcjkBnPh9yRMU8zjFer8 KOfH/MAdaOZo6mbiFMoaGIb6Utzf503aVK6nQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=KfIR4Hh6S/azCjya3orWsXYGozpf1UQ67k0J7kmQ4hZsfvrejRAEkBdTJk78XF04kX j9mDg/olhiIkT9qdYVSWzOFKNvgcqxX9rr5wzkLcGQQDRSj24L0uT04oSeJJWFlURFsj KnknUoHJr5mF1D48mMP++NDq/e1cuIXuO3e9U= Received: by 10.142.9.10 with SMTP id 10mr3073324wfi.42.1273531113122; Mon, 10 May 2010 15:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.2.7 with HTTP; Mon, 10 May 2010 15:38:13 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE7BF9A.2050209@pidster.com> <1222443C-7C2C-49C4-B03A-4E760538B4BB@gmail.com> <4BE85186.1080401@pidster.com> From: Joseph Smarr Date: Mon, 10 May 2010 15:38:13 -0700 Message-ID: To: pid@pidster.com Content-Type: multipart/alternative; boundary=00504502b4989bae220486451121 Cc: OAuth WG Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jsmarr@stanfordalumni.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 22:38:48 -0000 --00504502b4989bae220486451121 Content-Type: text/plain; charset=ISO-8859-1 Oh, one other quick benefit of JSON (kind of an extension of point 1 below): - no ambiguous treatment of whitespace or newlines (this is a problem I've observed multiple times while helping developers debug OAuth 1.0 implementations--since they just split on & and =, they often don't trim extra whitespace or newlines that were returned by the server, leading to those spaces/newlines being part of the parsed attribute values, which then cause broken signatures and are very hard to debug, since the chars are invisible when printed). Not a problem with JSON. On Mon, May 10, 2010 at 3:35 PM, Joseph Smarr wrote: > Let me try to offer some of those "logical, positive statements in favour > of the technical merits of JSON over the original format choice" for those > that aren't familiar or haven't gleaned them from the thread thus far: > > - unambiguous spec for encoding/decoding (including how to represent spaces > and unicode chars, both of which are common points of ambiguity in > url-encoding that lead to bugs, confusion, and lack of ability to use > built-in libraries, if available). For example, the OAuth PHP library does > the following: return str_replace('+', ' ', str_replace('%7E', '~', > rawurlencode($input)) -- yuck! > > - easier to read the encoded format (because it has clear sentinel braces, > quoted attributes, and no url-encoding of parameters; only some backslashing > of reserved chars) > > - widely available libraries with good track records in the wild, and > increasingly built in to many platforms > > - extensible support for more representing more complex data structures in > the future, if needed > > - simple enough that it's easy to understand, but just complex enough that > it's not too tempting to roll your own parser (which leads empirically to > better compliance due to use of common libraries) > > - more likely to be recognized and understood by developers, since they've > seen it elsewhere in API response formats > > I think that about covers it. Again, it's an objective fact that > url-encoding has caused confusion and bugs in OAuth 1.0 implementations, and > it's also an objective fact that JSON has had a very high "just works" rate > in the wild, to the point that it's the default API response format for many > widely used APIs from large providers targeting many platforms. So this is > not a choice based on "fashion", but based on trying to learn from history > to increase developer success and remove the opportunity for subtle bugs, > which was one of the major problems with OAuth 1.0a that prompted us to work > on OAuth 2.0 in the first place. > > Thanks, js > > On Mon, May 10, 2010 at 11:33 AM, Pid wrote: > >> On 10/05/2010 15:56, Dick Hardt wrote: >> > >> > On 2010-05-10, at 1:11 AM, Pid wrote: >> > >> >> On 10/05/2010 07:57, Joseph Smarr wrote: >> >>>> 1. Server Response Format >> >>> >> >>> I vote for B, though I could live with C. (A would make me sad though) >> >>> >> >>> We've had a healthy and reasonable debate about the trade-offs here, >> but >> >>> I think the main counterargument for requiring JSON support is that >> it's >> >>> not quite yet a "no-brainer" to have JSON support in all environments >> >>> (e.g. iPhone libraries currently would need to statically link in an >> >>> available JSON library), whereas the counterarguments for A are the >> >>> well-documented problems properly decoding url-encoded params from >> OAuth >> >>> 1.0, plus the fact that it's not a common response format, whereas >> JSON >> >>> (and XML) are. Since I think JSON will continue to increase in use for >> >>> at least the next several years, the pain associated with requiring >> JSON >> >>> is likely to be higher now than it will be in the future, and it's >> >>> already low enough that we've had this debate about whether it's >> already >> >>> acceptable or not-quite-yet. And JSON has been proven to "just work" >> in >> >>> terms of avoiding encoding/decoding headaches in the wild, which for >> >>> something like OAuth is really critical. >> >> >> >> I don't believe this is an accurate summary. >> > >> > Are you saying the information is not accurate or not a complete >> summary? >> > >> >> >> >> I asked for someone in the pro-JSON camp to describe the technical >> >> merits of that format over url encoded, but to date, there's no one who >> >> has responded. >> > >> > per http://www.ietf.org/mail-archive/web/oauth/current/msg01992.html >> >> Is that the right message? There's not much in the way of positive >> arguments for JSON in that one. >> >> >> > client libraries exist to parse JSON responses >> >> Meaning a dependency. >> >> >> > client libraries do NOT exist to parse url encoded responses >> >> There aren't libraries to perform that type of decoding because it's >> trivial, (as you acknowledged). >> >> >> > Implementations of both OAuth 1.0 and WRAP improperly decoded the >> responses. >> > Also with reference to: "many developers have been caught just >> splitting the parameters and forgetting to URL decode the token" >> >> With respect, I think this is pretty close to a straw man. It would be >> just as easy to argue that developers will make a mess of parsing JSON. >> >> >> >> Everyone seems to have, (in some cases grudgingly), agreed that it's >> easier to decode/parse urlencoded data than JSON. >> >> There are definitely occasions when using JSON for data description & >> transmission is advantageous, I just don't think this is one of them. >> It's a proverbial sledgehammer for a tiny OAuth nut. >> >> >> There should be something positive to say about JSON that establishes >> why it is a better format for this purpose. >> >> >> >> The options we've been offered seem contrived to support JSON, >> > >> > would you elaborate on why you think the options presented by the editor >> were contrived? >> >> Sure. Two of them offer JSON as the default, including the putative >> 'compromise' option. >> >> JSON and XML add complexity, as the editor states. IMHO it's odd >> therefore not to select the least complex as the default, if multiple >> formats are offered. >> >> >> >> I appreciate that JSON is popular and there is a degree of devil's >> advocacy to my position here, (as I've already said), but if it's not >> possible to make a list of logical, positive statements in favour of the >> technical merits of JSON over the original format choice then it >> shouldn't be selected as the default. >> >> >> p >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --00504502b4989bae220486451121 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oh, one other quick benefit of JSON (kind of an extension of point 1 below)= :

- no ambiguous treatment of whitespace or newlines (th= is is a problem I've observed multiple times while helping developers d= ebug OAuth 1.0 implementations--since they just split on & and =3D, the= y often don't trim extra whitespace or newlines that were returned by t= he server, leading to those spaces/newlines being part of the parsed attrib= ute values, which then cause broken signatures and are very hard to debug, = since the chars are invisible when printed). Not a problem with JSON.

On Mon, May 10, 2010 at 3:35 PM, Joseph= Smarr <jsmarr@gma= il.com> wrote:
Let me try to offer some of those "logical, positive statements in fav= our of the=A0technical merits of JSON over the original format choice"= for those that aren't familiar or haven't gleaned them from the th= read thus far:

- unambiguous spec for encoding/decoding (including how to r= epresent spaces and unicode chars, both of which are common points of ambig= uity in url-encoding that lead to bugs, confusion, and lack of ability to u= se built-in libraries, if available). For example, the OAuth PHP library do= es the following:=A0= return str_replace('+', ' ', str_replace('%7E', '~', rawurlen= code($input)) -- yuck!

- easier to read the encoded format (because it has cle= ar=A0sentinel=A0braces, quoted attributes, and no url-encoding of parameter= s; only some backslashing of reserved chars)

- wid= ely available libraries with good track records in the wild, and increasing= ly built in to many platforms

- extensible support for more representing more complex= data structures in the future, if needed

- simple= enough that it's easy to understand, but just complex enough that it&#= 39;s not too tempting to roll your own parser (which leads empirically to b= etter compliance due to use of common libraries)

- more likely to be recognized and understood by develo= pers, since they've seen it elsewhere in API response formats

I think that about covers it. Again, it's an objective = fact that url-encoding has caused confusion and bugs in OAuth 1.0 implement= ations, and it's also an objective fact that JSON has had a very high &= quot;just works" rate in the wild, to the point that it's the defa= ult API response format for many widely used APIs from large providers targ= eting many platforms. So this is not a choice based on "fashion",= but based on trying to learn from history to increase developer success an= d remove the opportunity for subtle bugs, which was one of the major proble= ms with OAuth 1.0a that prompted us to work on OAuth 2.0 in the first place= .

Thanks, js

On Mon, May 10, 2010 at 11:33 AM, Pid <pid@pi= dster.com> wrote:
On 10/05/2010 15:56, Dick Hardt wrote:
>
> On 2010-05-10, at 1:11 AM, Pid wrote:
>
>> On 10/05/2010 07:57, Joseph Smarr wrote:
>>>> 1. Server Response Format
>>>
>>> I vote for B, though I could live with C. (A would make me sad= though)
>>>
>>> We've had a healthy and reasonable debate about the trade-= offs here, but
>>> I think the main counterargument for requiring JSON support is= that it's
>>> not quite yet a "no-brainer" to have JSON support in= all environments
>>> (e.g. iPhone libraries currently would need to statically link= in an
>>> available JSON library), whereas the counterarguments for A ar= e the
>>> well-documented problems properly decoding url-encoded params = from OAuth
>>> 1.0, plus the fact that it's not a common response format,= whereas JSON
>>> (and XML) are. Since I think JSON will continue to increase in= use for
>>> at least the next several years, the pain associated with requ= iring JSON
>>> is likely to be =A0higher now than it will be in the future, a= nd it's
>>> already low enough that we've had this debate about whethe= r it's already
>>> acceptable or not-quite-yet. And JSON has been proven to "= ;just work" in
>>> terms of avoiding encoding/decoding headaches in the wild, whi= ch for
>>> something like OAuth is really critical.
>>
>> I don't believe this is an accurate summary.
>
> Are you saying the information is not accurate or not a complete summa= ry?
>
>>
>> I asked for someone in the pro-JSON camp to describe the technical=
>> merits of that format over url encoded, but to date, there's n= o one who
>> has responded.
>
> per http://www.ietf.org/mail-archive/web/oauth/cur= rent/msg01992.html

Is that the right message? =A0There's not much in the way o= f positive
arguments for JSON in that one.


> client libraries exist to parse JSON responses

Meaning a dependency.


> client libraries do NOT exist to parse url encoded responses

There aren't libraries to perform that type of decoding because i= t's
trivial, (as you acknowledged).


> Implementations of both OAuth 1.0 and WRAP improperly decoded the resp= onses.
> Also with reference to: "many developers have been caught j= ust
splitting the parameters and forgetting to URL decode the token"

With respect, I think this is pretty close to a straw man. =A0It would be just as easy to argue that developers will make a mess of parsing JSON.



Everyone seems to have, (in some cases grudgingly), agreed that it's easier to decode/parse urlencoded data than JSON.

There are definitely occasions when using JSON for data description & transmission is advantageous, I just don't think this is one of them. It's a proverbial sledgehammer for a tiny OAuth nut.


There should be something positive to say about JSON that establishes
why it is a better format for this purpose.


>> The options we've been offered seem contrived to support JSON,=
>
> would you elaborate on why you think the options presented by the edit= or were contrived?

Sure. =A0Two of them offer JSON as the default, including the putativ= e
'compromise' option.

JSON and XML add complexity, as the editor states. =A0IMHO it's odd
therefore not to select the least complex as the default, if multiple
formats are offered.



I appreciate that JSON is popular and there is a degree of devil's
advocacy to my position here, (as I've already said), but if it's n= ot
possible to make a list of logical, positive statements in favour of the technical merits of JSON over the original format choice then it
shouldn't be selected as the default.


p





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



--00504502b4989bae220486451121-- From beaton@google.com Mon May 10 16:17:24 2010 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 889E83A6C69 for ; Mon, 10 May 2010 16:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.416 X-Spam-Level: X-Spam-Status: No, score=-100.416 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 4zhIbmBPsBFx for ; Mon, 10 May 2010 16:17:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 16A3428C279 for ; Mon, 10 May 2010 16:11:23 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o4ANBB8Q028907 for ; Mon, 10 May 2010 16:11:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273533072; bh=xgYWaPFA1xJzNOLecbVE/QnjStc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=xJ/XASg9K1DoRqLWMMtDGdbG7aoPAT6POuG4tu8EKe5zyl4fvcw99dnpcq8VqYqKo XMhyn/GvS0U0L4+Zf4hmA== 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=T2BRbhcd74vm8gidOOVjfNQIx6kr6y/pblD+8CC/QWpL/VZexhqd3I1lYA1gIwZnk n8xzyhGB6k79BmM116ozw== Received: from pzk14 (pzk14.prod.google.com [10.243.19.142]) by hpaq7.eem.corp.google.com with ESMTP id o4ANB9tb023377 for ; Mon, 10 May 2010 16:11:10 -0700 Received: by pzk14 with SMTP id 14so798989pzk.25 for ; Mon, 10 May 2010 16:11:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.207.17 with SMTP id e17mr3182670wfg.81.1273533068669; Mon, 10 May 2010 16:11:08 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Mon, 10 May 2010 16:11:08 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 10 May 2010 16:11:08 -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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 10 May 2010 23:17:24 -0000 On Mon, May 10, 2010 at 7:32 AM, Manger, James H wrote: > HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good match to how Google uses scope > values. It's not, actually. Our scopes are sometimes URI prefixes, and sometimes are not. The reality is complicated, and to be honest is poorly documented. We're working on it. As I've said in a few other e-mail threads, I think it would be a serious mistake to publish a standard that doesn't reflect things that are already deployed in the wild and are well-understood. If people want to see systems that automatically determines scopes and reuses tokens, I think they should go and build those systems. Then come back to the community with explanations of what they did, and why other people should adopt it. Cheers, Brian From beaton@google.com Mon May 10 16:19:38 2010 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 79F063A6C3E for ; Mon, 10 May 2010 16:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.92 X-Spam-Level: X-Spam-Status: No, score=-100.92 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 qEhRzlKkWd7v for ; Mon, 10 May 2010 16:19:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 57A2328C0EB for ; Mon, 10 May 2010 16:14:26 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o4ANEDEu032639 for ; Mon, 10 May 2010 16:14:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273533254; bh=0oOgOiXxXiNpP2rYOgvjzrrAsYM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BS1wlvPLGdEzh/dT6zwwtuIWzVzdJv5Pz7yB0fEGbyyT/lnXHDKCtvwO39lRiwMzX zqG3tXmopZAAqKxOrC5bg== 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=g42zpITMFgVrUZTXOScCrJacob1tIS620PI0noEs8v/X4OP+gRAXhQwxA2rWGX+xo Y+sd+ZGJ+MrNkfn/7I6Ig== Received: from pzk2 (pzk2.prod.google.com [10.243.19.130]) by wpaz24.hot.corp.google.com with ESMTP id o4ANEBSN008027 for ; Mon, 10 May 2010 16:14:12 -0700 Received: by pzk2 with SMTP id 2so3337487pzk.29 for ; Mon, 10 May 2010 16:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.136.2 with SMTP id o2mr3273416wfn.94.1273533251581; Mon, 10 May 2010 16:14:11 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Mon, 10 May 2010 16:14:11 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5DEB74B3E9FA574EAA911DB8167C559E04425EBE@SDGEXEVS12.corp.intuit.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 16:14:11 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "Foiles, Doug" , OAuth WG Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial) 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, 10 May 2010 23:19:38 -0000 On Sun, May 9, 2010 at 1:56 PM, Eran Hammer-Lahav wrote: > The authorization server can issue an access token with any expiration but should not issue expiration > later than that of the assertion. But still, there is nothing to prevent that. Wait, why shouldn't the authorization server issue an access token with an expiration past the notAfter date in the assertion? The common process here is to swap a SAML assertion with a very short lifetime (a minute or two) for a cookie that lasts a longer period of time. From beaton@google.com Mon May 10 16:25:27 2010 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 5EF5E3A6C51 for ; Mon, 10 May 2010 16:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.344 X-Spam-Level: X-Spam-Status: No, score=-100.344 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 eghaSQEfUGwh for ; Mon, 10 May 2010 16:25:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 46E1E3A6BFF for ; Mon, 10 May 2010 16:20:45 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o4ANKXd8031962 for ; Mon, 10 May 2010 16:20:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273533633; bh=V70ekCHTEImcDyahm7yFFS+RIRw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=fQ3NfO/dcDifVlDjc1eK/OXq2LRoUM/CuwiJ0tNJiTG4EldJYaBVQU84n+oU/M6A8 +5bDYbwfPZY4eXWsDdrkA== 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=X6hPMag1+AI9RHKklipcKwq5heo3mBLCzYjnknEKEPdhFrmnU8MmauGHyL8xJvqLM VqOBpJK6/S3SweHKnqVOw== Received: from pxi13 (pxi13.prod.google.com [10.243.27.13]) by hpaq13.eem.corp.google.com with ESMTP id o4ANKVuk028266 for ; Mon, 10 May 2010 16:20:31 -0700 Received: by pxi13 with SMTP id 13so1779739pxi.10 for ; Mon, 10 May 2010 16:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.129.2 with SMTP id g2mr3131548wfn.322.1273533626405; Mon, 10 May 2010 16:20:26 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Mon, 10 May 2010 16:20:26 -0700 (PDT) In-Reply-To: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.com> References: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.com> Date: Mon, 10 May 2010 16:20:26 -0700 Message-ID: From: Brian Eaton To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] delegating access to another client 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, 10 May 2010 23:25:27 -0000 On Sun, May 9, 2010 at 7:34 PM, Dick Hardt wrote: > There a couple of choices for the flows for how a successful delegation is conveyed to the delegate. The AS could return a delegation code that is similar to a verification code and the delegate acquires an access token similar to 3.6.2 > Alternatively, the AS could return an delegation token that is used similar to a refresh token to obtain an access token and refresh token. How about lifespan? When does the token expire? And can the client request a shorter expiration? Can the client request revocation of the delegate's token? What are the semantics around revocation? If a client has their access revoked, is the delegate access revoked as well? > Do people think this is worth adding to the spec? Maybe. > The main concern is how should the resource owner express their approval for such arrangement? I don't think this is a fundamental problem. The client already has the authority they are delegating, and they could expose a proxy service to share that data with fourth-parties. Dick is describing a cleaner (and possibly more secure?) way to do that. It's up to clients and service providers to figure out user expectations and set appropriate policies on when data can be shared with fourth parties.. Cheers, Brian From beaton@google.com Mon May 10 16:26:48 2010 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 EEE483A69E1 for ; Mon, 10 May 2010 16:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.6 X-Spam-Level: X-Spam-Status: No, score=-101.6 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eC00uvNCiE+9 for ; Mon, 10 May 2010 16:26:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5E6AD3A6B86 for ; Mon, 10 May 2010 16:24:43 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o4ANOVK7014118 for ; Mon, 10 May 2010 16:24:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273533871; bh=v3MMbdR+7gwtz9axWfgEm74Vk+w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=iwNSDhz6ily/3H92sO5/xR4gwPaCgUuv12SJjzaS4KjjmyNXX7peLwecR9OTc4IfO 51STVjBymOQGN17ARG39w== 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=LtW21ZOzojgU/8KI55+BOQnh+nnxXq6AS/NyfPwqZOi102qXuvmYlgjL5uAoveJ7G XQmtaHcZZ2v5Bh2Oe6yYw== Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by hpaq14.eem.corp.google.com with ESMTP id o4ANO2VK031821 for ; Mon, 10 May 2010 16:24:30 -0700 Received: by pxi1 with SMTP id 1so1891284pxi.22 for ; Mon, 10 May 2010 16:24:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.27.18 with SMTP id e18mr3260900wfj.41.1273533869422; Mon, 10 May 2010 16:24:29 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Mon, 10 May 2010 16:24:29 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E0B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 16:24:29 -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] device profile comments 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, 10 May 2010 23:26:48 -0000 On Sun, May 9, 2010 at 10:12 AM, Eran Hammer-Lahav wr= ote: >> "The client is incapable of receiving incoming requests from the authori= zation >> server (incapable of acting as an HTTP server). =A0ADD: >> The device manufacturer is assumed to have registered with the >> authorization server. =A0The authorization server and device manufacture= r >> agree on a client id used to identify the manufacturer's devices." > > I don't see the point. The fact that there is a client_id parameter makes= this clear enough. This is true for all flows. It's definitely not true for all flows. Neither the web app profile, nor the javascript profile, nor the installed application profile requires preregistration in order to work. The appropriate user experience happens via the callback URL. The device profile is different because you really cannot achieve a suitable user experience without preregistration. From uidude@google.com Mon May 10 16:30:52 2010 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 42B4B3A6822 for ; Mon, 10 May 2010 16:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.789 X-Spam-Level: X-Spam-Status: No, score=-101.789 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 UK5tuQvfysDn for ; Mon, 10 May 2010 16:30:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 2DAEF3A6812 for ; Mon, 10 May 2010 16:30:50 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o4ANUbEi021499 for ; Mon, 10 May 2010 16:30:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273534238; bh=hiMMu3Hk6EMsBENXv0Puq5hMek4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=a0tnO5YWLkghucyj7rGAjiQEIl9OA/CXT0u/a0dEa7Hz7Cj4v5XjzOgwPRwypwyVt 7+yc7VZwH+ESn+a9elGtg== 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=dvENJ9Ct9e4Jrgcef+YTcmQoCdcua0w2IktrXl3/HImk7hu3+ofvfVZDs5lyUbmuV o5k7vaILs6uuguwHz3fXQ== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by kpbe14.cbf.corp.google.com with ESMTP id o4ANU7An003758 for ; Mon, 10 May 2010 16:30:36 -0700 Received: by qyk30 with SMTP id 30so7547315qyk.16 for ; Mon, 10 May 2010 16:30:35 -0700 (PDT) Received: by 10.229.230.65 with SMTP id jl1mr4155426qcb.7.1273534234803; Mon, 10 May 2010 16:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Mon, 10 May 2010 16:30:14 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Mon, 10 May 2010 16:30:14 -0700 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=00163630e9a5acbf8e048645cb8f X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:30:52 -0000 --00163630e9a5acbf8e048645cb8f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I really like the idea behind the "sites" parameter I think this idea relates closely to scopes and probably needs to be bound more tightly to the inbound scope parameter. Both identify a set of protected resources that can be accessed with the token - one is the requested resources, the other is the granted resources. In both cases you need to have a way to find a mapping from protected resource identifier -> API endpoint you can call. On Mon, May 10, 2010 at 5:18 AM, Richer, Justin P. wrote= : > +1 > > Any information that the client needs to care about should live outside t= he > token. > > -- Justin > > ------------------------------ > *From:* oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran > Hammer-Lahav [eran@hueniverse.com] > *Sent:* Sunday, May 09, 2010 5:29 PM > *To:* David Recordon; Marius Scurtescu > > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid > > The idea of embedding this information into the token is wrong. This is > clearly token metadata and that information belongs alongside the token, > just like =91expires_in=92. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *David Recordon > *Sent:* Friday, May 07, 2010 11:06 AM > *To:* Marius Scurtescu > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid > > > > Using SWT for your access tokens seems like a reasonable way to resolve > this for servers which care. > > > > On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu > wrote: > > Returning a scope parameter with issued tokens is not a bad idea. > > But this, and also the sites parameter suggested by James, can both > potentially be solved with a transparent token format. Such a token > can make explicit the: > - expiry time > - scopes > - sites > - etc. > > The Simple Web Token spec goes along these lines. SWT has a parameter > called Audience, which I assumed would point to the client, but it > could also represent "sites". > > Marius > > > > > On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt > wrote: > > Additionally, I would propose to indicate the scope associated with a > token > > to the client using a scope response parameter. This is especially usef= ul > > (1) if the client did not pass a scope parameter but the server decided > to > > associate a scope based on its policy or (2) if the user decided to > > authorize a subset of the requested scope only. > > Regards, > > Torsten. > > > > > > > > Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt > > : > > > > what about an additional realm response value? > > > > If there is a binding between realm and token, the client can decide > based > > on the realm attribute discovered using a WWW-Authenticate response whi= ch > > token to use. > > > > regards, > > Torsten. > > > > Am 07.05.2010 07:06, schrieb Manger, James H: > > > > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on > clients > > being told by the server about the sites at which the secret > > (cookie/password/token) can be used (and, more importantly, where is mu= st > > not be used). This occurs without requiring service-specific knowledge = in > > the client app. OAuth aims to replace some of these uses. > > > > > > > > HTTP Basic authentication works safely from clients with no > service-specific > > knowledge because the client knows not to send the password it gets fro= m > the > > user to other sites. > > > > > > > > HTTP Digest authentication allows a password to used to across a set of > > domains specified in a WWW-Authenticate response header, but the passwo= rd > > will not be used at arbitrary other sites. > > > > > > > > Cookies are sent in requests to the same site, sites with the same > parent, > > or only https sites, depending on details from the service when setting > the > > cookie. > > > > > > > > > > > > To date, OAuth has assumed every client app has lots of service-specifi= c > > knowledge to make these choices. OAuth needs to remove the need for so > much > > service-specific knowledge to be as interoperable as other standard aut= h > > mechanism, otherwise it is a poor replacement. > > > > > > > > -- > > > > James Manger > > > > > > > > From: David Recordon [mailto:recordond@gmail.com] > > Sent: Friday, 7 May 2010 2:05 PM > > To: Manger, James H > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > > > > > > > > Hey James, > > > > Do you have a specific example in mind where this either has been an > issue > > or will be an issue? Most client implementations I've seen of OAuth (an= d > > technologies like OAuth) have a strong binding between the access > token(s), > > site they were issued by, and user they belong to. So I haven't heard o= f > > this being a problem in the wild... > > > > > > > > --David > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00163630e9a5acbf8e048645cb8f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I really like the idea behind the "sites" parameter

I think this idea relates closely to scopes and probably n= eeds to be bound more tightly to the inbound scope parameter. Both identify= a set of protected resources that can be accessed with the token - one is = the requested resources, the other is the granted resources. In both cases = you need to have a way to find a mapping from protected resource identifier= -> API endpoint you can call.=A0

On Mon, May 10, 2010 at 5:18= AM, Richer, Justin P. <jricher@mitre.org> wrote:
+1
=A0
Any information that the = client needs to care about should live outside the token.
=A0
=A0-- Justin
=A0
From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On = Behalf Of Eran Hammer-Lahav [eran@hueniverse.com]
Sent: Sunday, May 09, 2010 5:29 PM
To: David Recordon; Marius Scurtescu

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

The ide= a of embedding this information into the token is wrong. This is clearly to= ken metadata and that information belongs alongside the token, just like =91expires_in=92.

= =A0

EHL

= =A0

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Recordon
Sent: Friday, May 07, 2010 11:06 AM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

=A0

Using SWT for your access tokens seems like a reason= able way to resolve this for servers which care.

=A0

On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu &l= t;mscurtescu@goo= gle.com> wrote:

Returning a scope parameter with issued tokens is no= t a bad idea.

But this, and also the sites parameter suggested by James, can both
potentially be solved with a transparent token format. Such a token
can make explicit the:
- expiry time
- scopes
- sites
- etc.

The Simple Web Token spec goes along these lines. SWT has a parameter
called Audience, which I assumed would point to the client, but it
could also represent "sites".

Marius




On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt
<torsten@lo= dderstedt.net> wrote:
> Additionally, I would propose to indicate the scope associated with a = token
> to the client using a scope response parameter. This is especially use= ful
> (1) if the client did not pass a scope parameter but the server decide= d to
> associate a scope based on its policy or (2) if the user decided to > authorize a subset of the requested scope only.
> Regards,
> Torsten.
>
>
>
> Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt
> <torst= en@lodderstedt.net>:
>
> what about an additional realm response value?
>
> If there is a binding between realm and token, the client can decide b= ased
> on the realm attribute discovered using a WWW-Authenticate response wh= ich
> token to use.
>
> regards,
> Torsten.
>
> Am 07.05.2010 07:06, schrieb Manger, James H:
>
> Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on c= lients
> being told by the server about the sites at which the secret
> (cookie/password/token) can be used (and, more importantly, where is m= ust
> not be used). This occurs without requiring service-specific knowledge= in
> the client app. OAuth aims to replace some of these uses.
>
>
>
> HTTP Basic authentication works safely from clients with no service-sp= ecific
> knowledge because the client knows not to send the password it gets fr= om the
> user to other sites.
>
>
>
> HTTP Digest authentication allows a password to used to across a set o= f
> domains specified in a WWW-Authenticate response header, but the passw= ord
> will not be used at arbitrary other sites.
>
>
>
> Cookies are sent in requests to the same site, sites with the same par= ent,
> or only https sites, depending on details from the service when settin= g the
> cookie.
>
>
>
>
>
> To date, OAuth has assumed every client app has lots of service-specif= ic
> knowledge to make these choices. OAuth needs to remove the need for so= much
> service-specific knowledge to be as interoperable as other standard au= th
> mechanism, otherwise it is a poor replacement.
>
>
>
> --
>
> James Manger
>
>
>
> From: David Recordon [mailto:recordond@gmail.com]
> Sent: Friday, 7 May 2010 2:05 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
>
>
>
> Hey James,
>
> Do you have a specific example in mind where this either has been an i= ssue
> or will be an issue? Most client implementations I've seen of OAut= h (and
> technologies like OAuth) have a strong binding between the access toke= n(s),
> site they were issued by, and user they belong to. So I haven't he= ard of
> this being a problem in the wild...
>
>
>
> --David
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0


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


--00163630e9a5acbf8e048645cb8f-- From yarong@microsoft.com Mon May 10 16:43:26 2010 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 744023A6C15 for ; Mon, 10 May 2010 16:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.913 X-Spam-Level: X-Spam-Status: No, score=-9.913 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 qyxkL1DqsUlP for ; Mon, 10 May 2010 16:43:25 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id AE7E93A6A5D for ; Mon, 10 May 2010 16:43:25 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 May 2010 16:43:14 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi; Mon, 10 May 2010 16:43:14 -0700 From: Yaron Goland To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Thread-Topic: Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vAA21lGg Date: Mon, 10 May 2010 23:43:14 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 10 May 2010 23:43:26 -0000 Please see inline > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Sunday, May 09, 2010 2:07 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > DEADLINE: 5/13 >=20 > I would like to publish one more draft before our interim meeting in two > weeks (5/20). Below are two open issues we have on the list. Please reply > with your preference (or additional solutions) to each item. Issues with > consensus will be incorporated into the next draft. Those without will be > discussed at the meeting. >=20 > EHL >=20 > --- >=20 > 1. Server Response Format >=20 > After extensive debate, we have a large group in favor of using JSON as t= he > only response format (current draft). We also have a smaller group but wi= th > stronger feelings on the subject that JSON adds complexity with no obviou= s > value. >=20 > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional > request parameter >=20 [Yaron Goland] I prefer A, can live with B and object to C. > --- >=20 > 2. Client Authentication (in flows) >=20 > How should the client authenticate when making token requests? The > current draft defines special request parameters for sending client > credentials. Some have argued that this is not the correct way, and that = the > client should be using existing HTTP authentication schemes to accomplish > that such as Basic. >=20 > A. Client authenticates by sending its credentials using special paramete= rs > (current draft) B. Client authenticated by using HTTP Basic (or other sch= emes > supported by the server such as Digest) >=20 [Yaron Goland] A is needed at a minimum because there are physical limitati= ons to how many bytes can go into an authorization header. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From yarong@microsoft.com Mon May 10 16:45:27 2010 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 1C77D3A6A5D for ; Mon, 10 May 2010 16:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.727 X-Spam-Level: X-Spam-Status: No, score=-8.727 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 IuPt4l5oJIw5 for ; Mon, 10 May 2010 16:45:26 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 369213A6C7B for ; Mon, 10 May 2010 16:45:25 -0700 (PDT) Received: from TK5EX14CASC129.redmond.corp.microsoft.com (157.54.52.7) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 May 2010 16:45:14 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC129.redmond.corp.microsoft.com ([157.54.52.7]) with mapi; Mon, 10 May 2010 16:45:15 -0700 From: Yaron Goland To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Thread-Topic: sites with wildcard Thread-Index: AcrwTaPsC4ggYQawSQ6EnsB9Iie0cQATPiVw Date: Mon, 10 May 2010 23:45:14 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C4A426BD7TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] sites with wildcard 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, 10 May 2010 23:45:27 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C4A426BD7TK5EX14MBXC117r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIHNjZW5hcmlvIHRoYXQgcmVxdWlyZXMgdGhpcyBmZWF0 dXJlLiBXaGVuIGRvZXMgc29tZW9uZSBhc2sgZm9yIGEgdG9rZW4gd2l0aG91dCBrbm93aW5nIHdo ZXJlIGl0IGlzIGdvaW5nPw0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hbmdlciwgSmFtZXMgSA0KU2Vu dDogTW9uZGF5LCBNYXkgMTAsIDIwMTAgNzozMyBBTQ0KVG86IE9BdXRoIFdHIChvYXV0aEBpZXRm Lm9yZykNClN1YmplY3Q6IFtPQVVUSC1XR10gc2l0ZXMgd2l0aCB3aWxkY2FyZA0KDQpUaGVyZSBh cmUgdmFyaW91cyB3YXlzIHRvIGluZGljYXRlIHdoZXJlIGEgdG9rZW4gY2FuIGJlIHVzZWQgKHdo ZW4gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGEgdG9rZW4gdG8gYSBjbGllbnQgYXBw KS4NCg0KQS4gTGlzdCBvZiBVUkkgcHJlZml4ZXMNCkIuIExpc3Qgb2Ygc2NoZW1lOi8vaG9zdFs6 cG9ydF0gdHVwbGVzDQpDLiBMaXN0IG9mIGRvbWFpbiBuYW1lcw0KRC4gQW55IG9mIHRoZSBhYm92 ZSBsaXN0cyB3aXRoIGEgd2lsZGNhcmQgdG8gaW5jbHVkZSBhbGwgc3ViLWRvbWFpbnMsIGVnIOKA nHNpdGVz4oCdOlvigJxodHRwczovLyouZXhhbXBsZS5jb23igJ1dDQpFLiBSZWd1bGFyIGV4cHJl c3Npb24NCg0KSSBoYXZlIGJlZW4gc3VnZ2VzdGluZyAoQikuDQpIVFRQIERpZ2VzdCB1c2VzIChB KS4gKEEpIGlzIGEgcHJldHR5IGdvb2QgbWF0Y2ggdG8gaG93IEdvb2dsZSB1c2VzIHNjb3BlIHZh bHVlcy4NCihDKSBpcyBhIGxpdHRsZSBzaW1wbGVyOyBidXQgdW5hY2NlcHRhYmxlIGJlY2F1c2Ug d2Ugc2hvdWxkIGRpc3Rpbmd1aXNoIEhUVFAgYW5kIEhUVFBTLg0KQSByZWd1bGFyIGV4cHJlc3Np b24gKEUpIGNvdWxkIGRvIHRoZSBqb2IuDQooRCkgY2FuIGNvdmVyIHNvbWUgdmlydHVhbCBob3N0 aW5nIHNpdHVhdGlvbnMgd2hlcmUgYWxtb3N0IGFyYml0cmFyeSBudW1iZXJzIG9mIHN1Yi1kb21h aW5zIGFyZSBjb250aW51YWxseSBjcmVhdGVkIChlZyBwZXItdXNlciBzdWItZG9tYWlucykuIEVy YW4gYXNrZWQgZm9yIHdpbGRjYXJkcy4NCg0KSWYgYSB3aWxkY2FyZCBpcyBhbGxvd2VkIEkgc3Vn Z2VzdCBvbmx5IGFsbG93aW5nIGEgc2luZ2xlIOKAnCou4oCdIHByZWZpeCB0byB0aGUgZG9tYWlu IG5hbWUuIEl0cyBwcmVzZW5jZSB3b3VsZCBtZWFuIGFsbCBzdWItZG9tYWlucyAoYnV0IG5vdCB0 aGUgcGFyZW50IGRvbWFpbiwgd2hpY2ggY2FuIGJlIHNwZWNpZmllZCBzZXBhcmF0ZWx5IGlmIG5l ZWRlZCkuIFByb2JhYmx5IGVhc2llc3QgdG8gaW5jbHVkZSBzdWItc3ViLWRvbWFpbnMgZXRjLg0K DQpJIGNvdWxkIGxpdmUgd2l0aCBBLCBCLCBELCBvciBFIChqdXN0IG5vdCBDLCBhbmQgbm90IG5v dGhpbmcpLg0KDQpTdWdnZXN0ZWQgdGV4dCBmb3IgQitEIGZvciB0aGUgQWNjZXNzIFRva2VuIFJl c3BvbnNlIHNlY3Rpb246DQoNCg0KICBzaXRlcw0KICAgIE9QVElPTkFMLiBBbiBhcnJheSBvZiBz dHJpbmdzIGluZGljYXRpbmcgdGhlIHNpdGVzIHdoZXJlIHRoZSB0b2tlbiBjYW4gYmUgdXNlZC4N Cg0KVGhlIG9wdGlvbmFsIOKAnHNpdGVz4oCdIGZpZWxkIGluZGljYXRlcyB3aGVyZSB0aGUgaXNz dWVkIHRva2VuIGNhbiBiZSB1c2VkLiBJdHMgdmFsdWUgaXMgYW4gYXJyYXkgb2Ygc3RyaW5ncywg d2hlcmUgZWFjaCBzdHJpbmcgb2JleXMgdGhlIOKAnHNpdGXigJ0gcHJvZHVjdGlvbi4gSWYgdGhl IOKAnHNpdGVz4oCdIGZpZWxkIGlzIGFic2VudCBpdCBNVVNUIGJlIHRyZWF0ZWQgYXMgdGhvdWdo IHRoZSBmaWVsZCB3YXMgcHJlc2VudCB3aXRoIGEgc2luZ2xlIHN0cmluZyBjb25zaXN0aW5nIG9m IHRoZSBzY2hlbWUsIGhvc3QsIGFuZCBwb3J0IG9mIHRoZSByZXF1ZXN0IHRoYXQgcmV0dXJuZWQg dGhlIHRva2VuLg0KDQogIHNpdGUgOj0gc2NoZW1lIOKAnDovL+KAnSBbd2lsZGNhcmQg4oCcLuKA nV0gaG9zdCBb4oCcOuKAnSBwb3J0XQ0KICB3aWxkY2FyZCA6PSDigJwq4oCdDQoNClRoZSB0b2tl biBNVVNUIE5PVCBiZSB1c2VkIHdpdGggYSByZXF1ZXN0IHRvIGEgVVJJIHVubGVzcyB0aGUgVVJJ IG1hdGNoZXMgYXQgbGVhc3Qgb25lIHN0cmluZyBpbiB0aGUg4oCcc2l0ZXPigJ0gdmFsdWUuIEEg dG9rZW4gU0hPVUxEIGJlIHVzZWQgcHJlLWVtcHRpdmVseSB3aGVuIHRoZSBVUkkgZG9lcyBtYXRj aC4gQSBVUkkgbWF0Y2hlcyBhIHN0cmluZyBpZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJl IGFsbCBtZXQ6DQoxLiBUaGUgc2NoZW1lIG9mIHRoZSBVUkkgYW5kIHN0cmluZyBhcmUgZXF1YWws IGlnbm9yaW5nIGNhc2UuDQoyLiBUaGUgcG9ydCBudW1iZXIgb2YgdGhlIFVSSSBhbmQgc3RyaW5n IGFyZSBudW1lcmljYWxseSBlcXVhbCwgdXNpbmcgdGhlIGRlZmF1bHQgcG9ydCBudW1iZXIgZm9y IGEgc2NoZW1lIGlmIG5vIHBvcnQgaXMgc3BlY2lmaWVkIChlZyA0NDMgZm9yIGh0dHBzKS4NCjMu IFRoZSBob3N0IG9mIHRoZSBVUkkgYW5kIHN0cmluZyBhcmUgZXF1YWwsIGlnbm9yaW5nIGNhc2Us IGFuZCAoaWYgdGhlIHdpbGRjYXJkIGlzIHByZXNlbnQpIGlnbm9yaW5nIG9uZSBvciBtb3JlIGxl YWRpbmcgZG9tYWluIGxhYmVscyBvZiB0aGUgVVJJIGhvc3QuDQoNCkV4YW1wbGU6DQoNCiAg4oCc c2l0ZXPigJ06IFvigJxodHRwczovL2FwaS5leGFtcGxlLmNvbeKAnSwg4oCcaHR0cHM6Ly8qLmRh dGEuZXhhbXBsZS5jb23igJ1dDQoNClRoZSBmb2xsb3dpbmcgVVJJcyBtYXRjaCAoc28gdGhlIHRv a2VuIHNob3VsZCBiZSB1c2VkKToNCiAgaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb206NDQzL3h5ej9x PTENCiAgSFRUUFM6Ly9XV1cuSU1HLkRBVEEuRVhBTVBMRS5DT00vNzg2ODU2LmpwZw0KDQpUaGUg Zm9sbG93aW5nIFVSSXMgZG8gTk9UIG1hdGNoIChzbyB0aGUgdG9rZW4gbXVzdCBub3QgYmUgdXNl ZCk6DQogIGh0dHA6Ly9hcGkuZXhhbXBsZS5jb20vaW5kZXguaHRtbCAgKHdyb25nIHNjaGVtZSkN CiAgaHR0cHM6Ly9kYXRhLmV4YW1wbGUuY29tLzQyNTQuanNvbiAgKGhvc3Qgbm90IGEgc3ViLWRv bWFpbikNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= --_000_7C01E631FF4B654FA1E783F1C0265F8C4A426BD7TK5EX14MBXC117r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZs aW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBzY2VuYXJp byB0aGF0IHJlcXVpcmVzIHRoaXMgZmVhdHVyZS4gV2hlbiBkb2VzIHNvbWVvbmUgYXNrIGZvciBh IHRva2VuIHdpdGhvdXQga25vd2luZyB3aGVyZSBpdCBpcyBnb2luZz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+TWFuZ2VyLCBKYW1lcyBIPGJyPjxi PlNlbnQ6PC9iPiBNb25kYXksIE1heSAxMCwgMjAxMCA3OjMzIEFNPGJyPjxiPlRvOjwvYj4gT0F1 dGggV0cgKG9hdXRoQGlldGYub3JnKTxicj48Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBzaXRl cyB3aXRoIHdpbGRjYXJkPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1BVT5UaGVyZSBhcmUgdmFyaW91cyB3YXlzIHRvIGluZGljYXRlIHdoZXJlIGEgdG9r ZW4gY2FuIGJlIHVzZWQgKHdoZW4gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGEgdG9r ZW4gdG8gYSBjbGllbnQgYXBwKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPkEuIExpc3Qgb2YgVVJJIHByZWZpeGVzPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPkIuIExp c3Qgb2Ygc2NoZW1lOi8vaG9zdFs6cG9ydF0gdHVwbGVzPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPkMuIExpc3Qgb2YgZG9tYWluIG5hbWVz PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV PkQuIEFueSBvZiB0aGUgYWJvdmUgbGlzdHMgd2l0aCBhIHdpbGRjYXJkIHRvIGluY2x1ZGUgYWxs IHN1Yi1kb21haW5zLCBlZyDigJxzaXRlc+KAnTpb4oCcPGEgaHJlZj0iaHR0cHM6Ly8qLmV4YW1w bGUuY29tIj5odHRwczovLyouZXhhbXBsZS5jb208L2E+4oCdXTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5FLiBSZWd1bGFyIGV4cHJlc3Np b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t QVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLUFVPkkgaGF2ZSBiZWVuIHN1Z2dlc3RpbmcgKEIpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5IVFRQIERpZ2VzdCB1c2VzIChB KS4gKEEpIGlzIGEgcHJldHR5IGdvb2QgbWF0Y2ggdG8gaG93IEdvb2dsZSB1c2VzIHNjb3BlIHZh bHVlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQVU+KEMpIGlzIGEgbGl0dGxlIHNpbXBsZXI7IGJ1dCB1bmFjY2VwdGFibGUgYmVjYXVzZSB3 ZSBzaG91bGQgZGlzdGluZ3Vpc2ggSFRUUCBhbmQgSFRUUFMuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPkEgcmVndWxhciBleHByZXNzaW9u IChFKSBjb3VsZCBkbyB0aGUgam9iLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1BVT4oRCkgY2FuIGNvdmVyIHNvbWUgdmlydHVhbCBob3N0aW5n IHNpdHVhdGlvbnMgd2hlcmUgYWxtb3N0IGFyYml0cmFyeSBudW1iZXJzIG9mIHN1Yi1kb21haW5z IGFyZSBjb250aW51YWxseSBjcmVhdGVkIChlZyBwZXItdXNlciBzdWItZG9tYWlucykuIEVyYW4g YXNrZWQgZm9yIHdpbGRjYXJkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPklmIGEgd2lsZGNhcmQgaXMgYWxsb3dlZCBJIHN1 Z2dlc3Qgb25seSBhbGxvd2luZyBhIHNpbmdsZSDigJwqLuKAnSBwcmVmaXggdG8gdGhlIGRvbWFp biBuYW1lLiBJdHMgcHJlc2VuY2Ugd291bGQgbWVhbiBhbGwgc3ViLWRvbWFpbnMgKGJ1dCBub3Qg dGhlIHBhcmVudCBkb21haW4sIHdoaWNoIGNhbiBiZSBzcGVjaWZpZWQgc2VwYXJhdGVseSBpZiBu ZWVkZWQpLiBQcm9iYWJseSBlYXNpZXN0IHRvIGluY2x1ZGUgc3ViLXN1Yi1kb21haW5zIGV0Yy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUFVPkkgY291bGQgbGl2ZSB3aXRoIEEsIEIsIEQsIG9yIEUgKGp1c3Qgbm90IEMsIGFuZCBu b3Qgbm90aGluZykuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1BVT5TdWdnZXN0ZWQgdGV4dCBmb3IgQitEIGZvciB0aGUgQWNjZXNz IFRva2VuIFJlc3BvbnNlIHNlY3Rpb246PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+Jm5ic3A7IHNpdGVzPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPiZuYnNw OyZuYnNwOyZuYnNwOyBPUFRJT05BTC4gQW4gYXJyYXkgb2Ygc3RyaW5ncyBpbmRpY2F0aW5nIHRo ZSBzaXRlcyB3aGVyZSB0aGUgdG9rZW4gY2FuIGJlIHVzZWQuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5UaGUgb3B0aW9uYWwg 4oCcc2l0ZXPigJ0gZmllbGQgaW5kaWNhdGVzIHdoZXJlIHRoZSBpc3N1ZWQgdG9rZW4gY2FuIGJl IHVzZWQuIEl0cyB2YWx1ZSBpcyBhbiBhcnJheSBvZiBzdHJpbmdzLCB3aGVyZSBlYWNoIHN0cmlu ZyBvYmV5cyB0aGUg4oCcc2l0ZeKAnSBwcm9kdWN0aW9uLiBJZiB0aGUg4oCcc2l0ZXPigJ0gZmll bGQgaXMgYWJzZW50IGl0IE1VU1QgYmUgdHJlYXRlZCBhcyB0aG91Z2ggdGhlIGZpZWxkIHdhcyBw cmVzZW50IHdpdGggYSBzaW5nbGUgc3RyaW5nIGNvbnNpc3Rpbmcgb2YgdGhlIHNjaGVtZSwgaG9z dCwgYW5kIHBvcnQgb2YgdGhlIHJlcXVlc3QgdGhhdCByZXR1cm5lZCB0aGUgdG9rZW4uPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1B VT4mbmJzcDsgc2l0ZSA6PSBzY2hlbWUg4oCcOi8v4oCdIFt3aWxkY2FyZCDigJwu4oCdXSBob3N0 IFvigJw64oCdIHBvcnRdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLUFVPiZuYnNwOyB3aWxkY2FyZCA6PSDigJwq4oCdPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT5UaGUgdG9r ZW4gTVVTVCBOT1QgYmUgdXNlZCB3aXRoIGEgcmVxdWVzdCB0byBhIFVSSSB1bmxlc3MgdGhlIFVS SSBtYXRjaGVzIGF0IGxlYXN0IG9uZSBzdHJpbmcgaW4gdGhlIOKAnHNpdGVz4oCdIHZhbHVlLiBB IHRva2VuIFNIT1VMRCBiZSB1c2VkIHByZS1lbXB0aXZlbHkgd2hlbiB0aGUgVVJJIGRvZXMgbWF0 Y2guIEEgVVJJIG1hdGNoZXMgYSBzdHJpbmcgaWYgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIGFy ZSBhbGwgbWV0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1BVT4xLiBUaGUgc2NoZW1lIG9mIHRoZSBVUkkgYW5kIHN0cmluZyBhcmUgZXF1YWws IGlnbm9yaW5nIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLUFVPjIuIFRoZSBwb3J0IG51bWJlciBvZiB0aGUgVVJJIGFuZCBzdHJpbmcg YXJlIG51bWVyaWNhbGx5IGVxdWFsLCB1c2luZyB0aGUgZGVmYXVsdCBwb3J0IG51bWJlciBmb3Ig YSBzY2hlbWUgaWYgbm8gcG9ydCBpcyBzcGVjaWZpZWQgKGVnIDQ0MyBmb3IgaHR0cHMpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT4zLiBU aGUgaG9zdCBvZiB0aGUgVVJJIGFuZCBzdHJpbmcgYXJlIGVxdWFsLCBpZ25vcmluZyBjYXNlLCBh bmQgKGlmIHRoZSB3aWxkY2FyZCBpcyBwcmVzZW50KSBpZ25vcmluZyBvbmUgb3IgbW9yZSBsZWFk aW5nIGRvbWFpbiBsYWJlbHMgb2YgdGhlIFVSSSBob3N0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+RXhhbXBsZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV PiZuYnNwOyDigJxzaXRlc+KAnTogW+KAnDxhIGhyZWY9Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29t Ij5odHRwczovL2FwaS5leGFtcGxlLmNvbTwvYT7igJ0sIOKAnDxhIGhyZWY9Imh0dHBzOi8vKi5k YXRhLmV4YW1wbGUuY29tIj5odHRwczovLyouZGF0YS5leGFtcGxlLmNvbTwvYT7igJ1dPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1B VT5UaGUgZm9sbG93aW5nIFVSSXMgbWF0Y2ggKHNvIHRoZSB0b2tlbiBzaG91bGQgYmUgdXNlZCk6 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV PiZuYnNwOyA8YSBocmVmPSJodHRwczovL2FwaS5leGFtcGxlLmNvbTo0NDMveHl6P3E9MSI+aHR0 cHM6Ly9hcGkuZXhhbXBsZS5jb206NDQzL3h5ej9xPTE8L2E+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPiZuYnNwOyA8YSBocmVmPSJIVFRQ UzovL1dXVy5JTUcuREFUQS5FWEFNUExFLkNPTS83ODY4NTYuanBnIj5IVFRQUzovL1dXVy5JTUcu REFUQS5FWEFNUExFLkNPTS83ODY4NTYuanBnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+VGhlIGZvbGxvd2luZyBVUklz IGRvIE5PVCBtYXRjaCAoc28gdGhlIHRva2VuIG11c3Qgbm90IGJlIHVzZWQpOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT4mbmJzcDsgPGEg aHJlZj0iaHR0cDovL2FwaS5leGFtcGxlLmNvbS9pbmRleC5odG1sIj5odHRwOi8vYXBpLmV4YW1w bGUuY29tL2luZGV4Lmh0bWw8L2E+Jm5ic3A7ICh3cm9uZyBzY2hlbWUpPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVPiZuYnNwOyA8YSBocmVm PSJodHRwczovL2RhdGEuZXhhbXBsZS5jb20vNDI1NC5qc29uIj5odHRwczovL2RhdGEuZXhhbXBs ZS5jb20vNDI1NC5qc29uPC9hPiZuYnNwOyAoaG9zdCBub3QgYSBzdWItZG9tYWluKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVU+ LS0gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUFVPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1BVT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PC9ib2R5PjwvaHRtbD4= --_000_7C01E631FF4B654FA1E783F1C0265F8C4A426BD7TK5EX14MBXC117r_-- From James.H.Manger@team.telstra.com Mon May 10 16:46:19 2010 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 A8F5E3A694D for ; Mon, 10 May 2010 16:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.402 X-Spam-Level: * X-Spam-Status: No, score=1.402 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRlRmqZ-zPLu for ; Mon, 10 May 2010 16:46:19 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id B2DB63A68D5 for ; Mon, 10 May 2010 16:46:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,203,1272808800"; d="scan'208";a="2327228" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 11 May 2010 09:46:02 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5978"; a="1782311" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdni.tcif.telstra.com.au with ESMTP; 11 May 2010 09:46:03 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 11 May 2010 09:46:02 +1000 From: "Manger, James H" To: Marius Scurtescu Date: Tue, 11 May 2010 09:46:00 +1000 Thread-Topic: [OAUTH-WG] SWT for indicating sites where a token is valid Thread-Index: AcrwamAOOBZ0zMi6RragZwTcVUHRcgAL04Hg Message-ID: <255B9BB34FB7D647A506DC292726F6E1126328511A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> 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 Cc: OAuth WG Subject: Re: [OAUTH-WG] SWT for indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:46:19 -0000 TWFyaXVzLA0KDQo+IEFzIGEgc2lkZSBub3RlLCBJIHdhcyB0aGlua2luZyBtb3JlIGFib3V0IHRo ZSBzdWdnZXN0ZWQgInNpdGVzIg0KPiBwYXJhbWV0ZXIuIEluIHByYWN0aWNlIHRoYXQgc2l0ZXMg d2hlcmUgYW4gYWNjZXNzIHRva2VuIGNhbiBiZSB1c2VkIGlzDQo+IGxpbWl0ZWQgdG8gd2hhdCBw cm90ZWN0ZWQgcmVzb3VyY2VzIGNhbiBkZWNyeXB0IG9yIHZlcmlmeSB0aGUgdG9rZW4uDQo+IEFu IGFjY2VzcyB0b2tlbiBjYW5ub3QgYmUgcmVhbGx5IHVzZWQgYXQgdGhlIHdyb25nIHNpdGUuIEEg InNpdGVzIg0KPiBwYXJhbWV0ZXIgY291bGQgYmUgYSBuaWNlIGhpbnQgZm9yIHRoZSBjbGllbnQs IGJ1dCBub3QgYSBzZWN1cml0eQ0KPiByZXF1aXJlbWVudC4NCg0KDQpBIGJlYXJlciB0b2tlbiB0 aGF0IGdvZXMgdG8gdGhlIHdyb25nIHNpdGUgY2FuIGJlIHVzZWQgLS0gdG8gYWNjZXNzIHRoZSBw cm90ZWN0ZWQgcmVzb3VyY2Ugb24gdGhlIHJpZ2h0IHNpdGUgLS0gc28gdGhpcyBpcyBhIHRvdGFs IHNlY3VyaXR5IGZhaWx1cmUsIG5vdCBhIG5pY2UgaGludC4NCg0KSWYgdGhlIHdyb25nIHNpdGUg dXNlcyBIVFRQIHRoZW4gdGhlIHRva2VuIGlzIGFsc28gZXhwb3NlZCBvbiB0aGUgbmV0d29yayAt LSBzbyBpdCBoYXMganVzdCBiZWVuIGJyb2FkY2FzdCBpbiB0aGUgY2xlYXIgaWYgeW91IGFyZSB1 c2luZyBwdWJsaWMgd2lmaS4gQWdhaW4gYSBzZWN1cml0eSBmYWlsdXJlLg0KDQoNCi0tIA0KSmFt ZXMgTWFuZ2VyDQo= From uidude@google.com Mon May 10 16:50:50 2010 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 67ED83A6AA9 for ; Mon, 10 May 2010 16:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.496 X-Spam-Level: X-Spam-Status: No, score=-100.496 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 GqlWuhbfFSRc for ; Mon, 10 May 2010 16:50:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1A9FF3A694D for ; Mon, 10 May 2010 16:50:48 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o4ANoaCI016199 for ; Mon, 10 May 2010 16:50:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273535437; bh=LGsmZtM21nUVlOfAurR2lvRJBa4=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=FiItKGFeaeBDcrKvPsIfWm/NWDWNqPSbSA3OTWFA2WjDIn16IROAwJRSDozKF8sJI alYQkFkyef8dSsJLkKg6A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:cc: content-type:x-system-of-record; b=Q4hCUBbg4JazWtyQ/YfxPzK2Jfr3Qn/T1vRKXl7uyphAQWqclM8xxp0YgIhc1eDb5 mciXL0p6yO1wLdLWU7WJg== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by kpbe13.cbf.corp.google.com with ESMTP id o4ANoJMj000987 for ; Mon, 10 May 2010 16:50:35 -0700 Received: by qyk30 with SMTP id 30so7577635qyk.16 for ; Mon, 10 May 2010 16:50:34 -0700 (PDT) Received: by 10.224.109.8 with SMTP id h8mr3257029qap.60.1273535434585; Mon, 10 May 2010 16:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Mon, 10 May 2010 16:50:13 -0700 (PDT) From: Evan Gilbert Date: Mon, 10 May 2010 16:50:13 -0700 Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=00c09f97274730005804864613e3 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: [OAUTH-WG] Provisional OAuth enhancements 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, 10 May 2010 23:50:50 -0000 --00c09f97274730005804864613e3 Content-Type: text/plain; charset=ISO-8859-1 I'm seeing a few OAuth features in spec discussions which: - Feel like it would be a major omission if they don't make it into OAuth 2.0, but - Haven't been used previously or even prototyped, which makes people uncomfortable with adding to the spec This includes the scope / sites syntax discussion (among others). I'm wondering if there would any interest in collaborating on a Wiki for "provisional" spec enhancements. The goal would be have a place for early implementers to share a spec- these changes would not go into the OAuth 2.0 draft until we have implementation experienc. However discussions would still be on the main mailing list. On Mon, May 10, 2010 at 4:11 PM, Brian Eaton wrote: > On Mon, May 10, 2010 at 7:32 AM, Manger, James H > wrote: > > HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good > match to how Google uses scope > > values. > > It's not, actually. Our scopes are sometimes URI prefixes, and > sometimes are not. The reality is complicated, and to be honest is > poorly documented. We're working on it. > > As I've said in a few other e-mail threads, I think it would be a > serious mistake to publish a standard that doesn't reflect things that > are already deployed in the wild and are well-understood. > > If people want to see systems that automatically determines scopes and > reuses tokens, I think they should go and build those systems. Then > come back to the community with explanations of what they did, and why > other people should adopt it. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00c09f97274730005804864613e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'= ;m seeing a few OAuth features in spec discussions which:
- Feel = like it would be a major omission if they don't make it into OAuth 2.0,= but
- Haven't been used previously or even prototyped, which makes peo= ple uncomfortable with adding to the spec

This includes t= he scope / sites syntax discussion (among others).

I'm wo= ndering if there would any interest in collaborating on a Wiki for "pr= ovisional" spec enhancements. The goal would be have a place for early= implementers to share a spec- these changes would not go into the OAuth 2.= 0 draft until we have implementation experienc. However discussions would s= till be on the main mailing list.

On Mon, May 10, 2010 at 4:11 PM, Bria= n Eaton <beaton@google.com> wrote:
On Mon, May 10, 2010 at 7:32 AM, Manger, James H
<Ja= mes.H.Manger@team.telstra.com> wrote:
> HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good m= atch to how Google uses scope
> values.

It's not, actually. =A0Our scopes are sometimes URI prefixes, and
sometimes are not. =A0The reality is complicated, and to be honest is
poorly documented. =A0We're working on it.

As I've said in a few other e-mail threads, I think it would be a
serious mistake to publish a standard that doesn't reflect things that<= br> are already deployed in the wild and are well-understood.

If people want to see systems that automatically determines scopes and
reuses tokens, I think they should go and build those systems. =A0Then
come back to the community with explanations of what they did, and why
other people should adopt it.

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

--00c09f97274730005804864613e3-- From mscurtescu@google.com Mon May 10 16:51:40 2010 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 78BE03A6AA9 for ; Mon, 10 May 2010 16:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.324 X-Spam-Level: X-Spam-Status: No, score=-100.324 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 0lsqrbyXl0aV for ; Mon, 10 May 2010 16:51:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7B0DC3A67AD for ; Mon, 10 May 2010 16:51:39 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o4ANpHqO024631 for ; Mon, 10 May 2010 16:51:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273535478; bh=IHLVf402zZw9Qq5okH+qvn2jQdQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=p5bs20nPNIIj5qfs2KxmG7HR7+sFFvpxOaCgVPI+8kDPqPSjRa0BGbzyXqZ/qYgb/ WZ17UUMlWy0pEx33bqsRw== 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=Z/c1W2OipY2A4EaDISQXSp3svSFMazpFZIMBmmeyoXt1+w71okLzS4gexNvN6/Sj4 tWLGSnMjfFTmwM4gVULlw== Received: from pwi9 (pwi9.prod.google.com [10.241.219.9]) by kpbe11.cbf.corp.google.com with ESMTP id o4ANpGh2021034 for ; Mon, 10 May 2010 16:51:16 -0700 Received: by pwi9 with SMTP id 9so2065032pwi.13 for ; Mon, 10 May 2010 16:51:16 -0700 (PDT) Received: by 10.141.107.19 with SMTP id j19mr3194734rvm.90.1273535476085; Mon, 10 May 2010 16:51:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 10 May 2010 16:50:56 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126328511A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1126328511A@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Mon, 10 May 2010 16:50:56 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] SWT for indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 23:51:40 -0000 On Mon, May 10, 2010 at 4:46 PM, Manger, James H wrote: > Marius, > >> As a side note, I was thinking more about the suggested "sites" >> parameter. In practice that sites where an access token can be used is >> limited to what protected resources can decrypt or verify the token. >> An access token cannot be really used at the wrong site. A "sites" >> parameter could be a nice hint for the client, but not a security >> requirement. > > > A bearer token that goes to the wrong site can be used -- to access the protected resource on the right site -- so this is a total security failure, not a nice hint. Yes, you are right. I was thinking about information leak from the token. But then again, how does the client end up making a request to the wrong site? > If the wrong site uses HTTP then the token is also exposed on the network -- so it has just been broadcast in the clear if you are using public wifi. Again a security failure. Sure, but the "sites" parameter does not help in these cases. Marius From yarong@microsoft.com Mon May 10 16:52:20 2010 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 B39373A6C88 for ; Mon, 10 May 2010 16:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.923 X-Spam-Level: X-Spam-Status: No, score=-9.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 j8Gl+Ci+T1PM for ; Mon, 10 May 2010 16:52:20 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 074CE3A67AD for ; Mon, 10 May 2010 16:52:20 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 May 2010 16:52:09 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi; Mon, 10 May 2010 16:52:09 -0700 From: Yaron Goland To: Brian Eaton , "Manger, James H" Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AQHK8JcGO/EckACqnUaErT7DgXKBwpJLVmcg Date: Mon, 10 May 2010 23:52:08 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A426C97@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 10 May 2010 23:52:20 -0000 +1 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Monday, May 10, 2010 4:11 PM > To: Manger, James H > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] sites with wildcard >=20 > On Mon, May 10, 2010 at 7:32 AM, Manger, James H > wrote: > > HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good > > match to how Google uses scope values. >=20 > It's not, actually. Our scopes are sometimes URI prefixes, and sometimes= are > not. The reality is complicated, and to be honest is poorly documented. > We're working on it. >=20 > As I've said in a few other e-mail threads, I think it would be a serious= mistake > to publish a standard that doesn't reflect things that are already deploy= ed in > the wild and are well-understood. >=20 > If people want to see systems that automatically determines scopes and > reuses tokens, I think they should go and build those systems. Then come > back to the community with explanations of what they did, and why other > people should adopt it. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From uidude@google.com Mon May 10 16:56:55 2010 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 130B63A67AD for ; Mon, 10 May 2010 16:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.009 X-Spam-Level: X-Spam-Status: No, score=-101.009 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 S1l8euasfc3z for ; Mon, 10 May 2010 16:56:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9E0BE3A6C7F for ; Mon, 10 May 2010 16:56:46 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id o4ANuYEF021379 for ; Mon, 10 May 2010 16:56:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273535794; bh=gwUI4ZrV45/gGBVfPoIxL3yyuIc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=lLV70VRhtOS/0XjkCsVdOMEcbhSN1v+UDZoKXgpKq4lHeSFXSOvxIl1tALN+Ia3jK 7TYlGvIKYibN6xgvCEHOg== 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=dba+muqVrpAphV9k3sMcfe08C/1Dx7Mlhx3o6z/+dRzB64358k9z2a/t7/na1EXvi Zi/JaK7vteuCHh+MBe38A== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by hpaq11.eem.corp.google.com with ESMTP id o4ANuWNh031860 for ; Mon, 10 May 2010 16:56:33 -0700 Received: by qyk38 with SMTP id 38so4566138qyk.18 for ; Mon, 10 May 2010 16:56:32 -0700 (PDT) Received: by 10.229.239.149 with SMTP id kw21mr4045857qcb.99.1273535792132; Mon, 10 May 2010 16:56:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Mon, 10 May 2010 16:56:12 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Mon, 10 May 2010 16:56:12 -0700 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=0016e648a6187fb2a204864628cd X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] User Endpoint 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, 10 May 2010 23:56:55 -0000 --0016e648a6187fb2a204864628cd Content-Type: text/plain; charset=ISO-8859-1 +1 on delegation. This conveys the purpose nicely - I think these endpoints are always to verify that there is a currently logged in user for the purpose of delegation. "User" seems a bit vague - "user agent" seems more appropriate if we want to reference that this occurs in a browser. Also note that "token endpoint" is confusing given the fact that you can get a token without ever talking to the token endpoint (in the User Agent flow). Don't have great suggestions, but wanted to point out. On Mon, May 10, 2010 at 5:18 AM, Richer, Justin P. wrote: > So long as we keep some language in the text that this is the endpoint > where the authorization by the user takes place, this change makes sense to > me. People coming from OAuth 1 and similar schemes are going to be looking > for the "authorization" part, I think. > > -- Justin > > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran > Hammer-Lahav [eran@hueniverse.com] > Sent: Sunday, May 09, 2010 5:15 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] User Endpoint > > I would like to rename the authorization endpoint to the user endpoint. Any > objections? > > EHL > _______________________________________________ > 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 > --0016e648a6187fb2a204864628cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 on delegation.=A0

This conveys the purpose nicely - I= think these endpoints are always to verify that there is a currently logge= d in user for the purpose of delegation. "User" seems a bit vague= - "user agent" seems more appropriate if we want to reference th= at this occurs in a browser.

Also note that "token endpoint" is confusing given= the fact that you can get a token without ever talking to the token endpoi= nt (in the User Agent flow). Don't have great suggestions, but wanted t= o point out.

On Mon, May 10, 2010 at 5:18 AM, Richer= , Justin P. <jric= her@mitre.org> wrote:
So long as we keep some language in the text that this is the endpoint wher= e the authorization by the user takes place, this change makes sense to me.= People coming from OAuth 1 and similar schemes are going to be looking for= the "authorization" part, I think.

=A0-- Justin

________________________________________
From: oauth-bounces@ietf.org = [oauth-bounces@ietf.org] On B= ehalf Of Eran Hammer-Lahav [eran@hue= niverse.com]
Sent: Sunday, May 09, 2010 5:15 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] User Endpoint

I would like to rename the authorization endpoint to the user endpoint. Any= objections?

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

--0016e648a6187fb2a204864628cd-- From dick.hardt@gmail.com Mon May 10 17:10:36 2010 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 D675028C0F0 for ; Mon, 10 May 2010 17:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.783, 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 WRm4GMHlV1Ih for ; Mon, 10 May 2010 17:10:33 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 2951528C0ED for ; Mon, 10 May 2010 17:10:30 -0700 (PDT) Received: by pwj2 with SMTP id 2so2137222pwj.31 for ; Mon, 10 May 2010 17:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=HZdtLET2NHJwb19V/LUTDcXBdRpJh5m8dwgAs4XszCM=; b=L0427rlSGPSQhTSWFuflHLE+QgDY9C+VC+46cuUNawNJgNlWdvKFquXQxriPjjVG8r 2pR7/Y2T+NTtRm5eDMPFpmHEkygckbavyni3KY/c+oIihHvYZcg8BOYmpcnARAiN3N+R RLLo2f68OoOChAomtH18kwtPS/M2C6GIFTiJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=yHN/DXxYrw6NNYjWns4aUW6Zh301Q2igLUnGreUGFuCnF0vvcnrcAsqYnmkAVWGDc+ WQOMMO6x9ODXyqhV1nwGd0G+fHyOGvCU1QoDmAaWBEf8gwupMgCf35NFfngAgqwPItF1 aT+y5kJ1Doulx9bDaS8GMz6+tPtPDPGFUw16M= Received: by 10.115.113.31 with SMTP id q31mr3811603wam.1.1273536615588; Mon, 10 May 2010 17:10:15 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id c14sm30002908waa.13.2010.05.10.17.10.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 May 2010 17:10:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Mon, 10 May 2010 17:10:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9541BCD6-6A04-4CD2-8F1B-711BFA602E77@gmail.com> References: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.com> To: Brian Eaton X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] delegating access to another client 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, 11 May 2010 00:10:36 -0000 On 2010-05-10, at 4:20 PM, Brian Eaton wrote: > On Sun, May 9, 2010 at 7:34 PM, Dick Hardt = wrote: >> There a couple of choices for the flows for how a successful = delegation is conveyed to the delegate. The AS could return a delegation = code that is similar to a verification code and the delegate acquires an = access token similar to 3.6.2 >> Alternatively, the AS could return an delegation token that is used = similar to a refresh token to obtain an access token and refresh token. >=20 > How about lifespan? When does the token expire? And can the client > request a shorter expiration? I would expect these to be contained in the scope requested. >=20 > Can the client request revocation of the delegate's token? >=20 > What are the semantics around revocation? If a client has their > access revoked, is the delegate access revoked as well? Had not considered revocation by the client. I have no answer to these = questions right now. :) -- Dick= From James.H.Manger@team.telstra.com Mon May 10 17:31:39 2010 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 E20FE28C0F4 for ; Mon, 10 May 2010 17:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.409 X-Spam-Level: * X-Spam-Status: No, score=1.409 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c2wFtWJr3W7 for ; Mon, 10 May 2010 17:31:38 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 0395228C0F0 for ; Mon, 10 May 2010 17:31:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,203,1272808800"; d="scan'208,217";a="2395954" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 11 May 2010 10:31:26 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5978"; a="1734443" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 11 May 2010 10:31:26 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Tue, 11 May 2010 10:31:23 +1000 From: "Manger, James H" To: Yaron Goland , "OAuth WG (oauth@ietf.org)" Date: Tue, 11 May 2010 10:31:22 +1000 Thread-Topic: sites with wildcard Thread-Index: AcrwTaPsC4ggYQawSQ6EnsB9Iie0cQATPiVwAAA9JoA= Message-ID: <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.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_255B9BB34FB7D647A506DC292726F6E112632852F1WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 00:31:40 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112632852F1WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFyb24sDQoNCg0KDQo+IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBzY2VuYXJpbyB0aGF0IHJl cXVpcmVzIHRoaXMgZmVhdHVyZS4gV2hlbiBkb2VzIHNvbWVvbmUgYXNrIGZvciBhIHRva2VuIHdp dGhvdXQga25vd2luZyB3aGVyZSBpdCBpcyBnb2luZz8NCg0KDQoNCkV4YW1wbGU6DQoNCkEgY2xp ZW50IGFwcCBnZXRzIGEgdG9rZW4gdG8gbWFrZSBhbiBBUEkgY2FsbCB0byBhIHByb3RlY3RlZCBy ZXNvdXJjZSB0aGF0IHJldHVybnMgYW4gQXRvbSBmZWVkLg0KDQpUaGUgZmVlZCBjb250YWlucyBs b3RzIG9mIGVudHJpZXMsIHdpdGggbGlua3MgdG8gcGhvdG9zLCBzdHlsZSBzaGVldHMsIGFuZCBz Y3JpcHRzLg0KDQpUaGUgY2xpZW50IGFwcCBnZXRzIHRoZSBwaG90b3MuDQoNCg0KDQpTaG91bGQg aXQgc2VuZCB0aGUgdG9rZW4gd2hlbiBnZXR0aW5nIHRoZSBwaG90b3M/DQoNCg0KDQpPbiBzZXJ2 aWNlIEEgdGhlIEF0b20gZmVlZCBhbmQgdGhlIHBob3RvcyBhcmUgYWxsIHNlcnZlZCBmcm9tIHRo ZSBzYW1lIEhUVFBTIGhvc3QsIHdpdGggdGhlIHNhbWUgcHJvdGVjdGlvbiwgc28gdGhlIHRva2Vu IG11c3QgYmUgc2VudC4NCg0KDQoNCk9uIHNlcnZpY2UgQiB0aGUgcGhvdG9zIGFyZSBob3N0ZWQg b24gYSBzZXBhcmF0ZSBvdXRzb3VyY2VkIGNvbnRlbnQgZGlzdHJpYnV0aW9uIG5ldHdvcmsuIFRo ZSBwaG90b3MgYXJlIHByb3RlY3RlZCBieSB1c2luZyBsb25nIHVuZ3Vlc3NhYmxlIFVSSXMgKHRo ZSBVUklzIGFyZSBlZmZlY3RpdmVseSDigJxjYXBhYmlsaXRpZXPigJ0gdG8gcmVhZCB0aGUgcGhv dG9zKS4gVGhlIHRva2VuIGRvZXMgbm90IG5lZWQgdG8gYmUgc2VudC4NCg0KDQoNCk9uIHNlcnZp Y2UgQyB0aGUgcGhvdG9zIGFyZSBhbnkgaW1hZ2VzIGZyb20gYW55d2hlcmUgb24gdGhlIEludGVy bmV0IHRoYXQgdGhlIHVzZXIgaGFzIGNob3NlbiB0byBsaW5rIHRvLiBUaGUgQXRvbSBjb2xsZWN0 aW9uIGlzIHByb3RlY3RlZCwgYnV0IG5vdCB0aGUgcGhvdG9zLiBUaGUgdG9rZW4gYWJzb2x1dGVs eSBtdXN0IG5vdCBiZSBzZW50IHdoZW4gZ2V0dGluZyB0aGUgcGhvdG9zLg0KDQoNCg0KDQoNCkEg Y2xpZW50IGFwcCBuZWVkcyB0byBrbm93IHdoZXRoZXIgdGhlIHNlcnZpY2UgaXQgaXMgYWNjZXNz aW5nIGlzIGxpa2UgQSwgQiwgb3IgQy4gSXQgbmVlZHMgdG8ga25vdyBmb3IgcmVkaXJlY3RzLCBm b3IgbGlua3MgaW4gSFRUUCBoZWFkZXJzLCBmb3IgbGlua3MgdG8gaW1hZ2VzLCBmb3IgYW55IG90 aGVyIHNvcnQgb2YgbGluayB0aGF0IGlzIGNhbiBkZXJpdmUgZnJvbSB0aGUgcmVzcG9uc2UuDQoN Cg0KDQpTb21lIHNlcnZpY2VzIG1pZ2h0IGJlIGNvbXBsZXRlbHkgd2FsbGVkIGdhcmRlbnMgc28g dGhlIGNsaWVudCBjYW4gYXNzdW1lIHRoZXkgYXJlIGxpa2UgQS4NCg0KU29tZSBzZXJ2aWNlcyBt aWdodCBleHBsaWNpdGx5IHN0YXRlIGluIHRoZWlyIGRvY3VtZW50YXRpb246IHdoaWNoIGxpbmtz IGFuZCByZWRpcmVjdHMgYXJlIGFsd2F5cyBndWFyYW50ZWVkIHRvIGJlIG90aGVyIEFQSSBjYWxs cyAoc2VuZCB0aGUgdG9rZW4pOyB3aGljaCB3aWxsIGFsd2F5cyBiZSB0byBvdGhlciBzZWN1cml0 eSBjb250ZXh0cyAoZG9u4oCZdCBzZW5kIHRoZSB0b2tlbik7IGFuZCB3aGljaCBtaWdodCBiZSBl aXRoZXIgKGRvbuKAmXQgc2VuZCB0aGUgdG9rZW4sIHNlZSBpZiB5b3UgZ2V0IGEgNDAxLzQwMywg Z3Vlc3MsIHNlbmQgdGhlIHRva2VuKS4NCg0KDQoNCkluIGdlbmVyYWwsIHRoZSB3ZWIgaXMgYWJv dXQgZm9sbG93aW5nIGxpbmtzLiBDbGllbnRzIG5lZWQgdG8ga25vdyB3aGVuIGZvbGxvd2luZyBh IGxpbmsgY3Jvc3NlcyBhIHNlY3VyaXR5IGJvdW5kYXJ5LiBDb29raWVzIHByb3ZpZGUgdGhpczsg QmFzaWMgcHJvdmlkZXMgdGhpczsgRGlnZXN0IHByb3ZpZGVzIHRoaXM7IE9BdXRoIG5lZWRzIHRo aXMgdG9vLg0KDQoNCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E112632852F1WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu U2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPllh cm9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jmd0OyA8L3NwYW4+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBzY2VuYXJpbyB0aGF0IHJlcXVpcmVz IHRoaXMgZmVhdHVyZS4gV2hlbiBkb2VzIHNvbWVvbmUgYXNrIGZvciBhIHRva2VuIHdpdGhvdXQg a25vd2luZyB3aGVyZSBpdCBpcyBnb2luZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkV4YW1wbGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkEgY2xpZW50IGFwcCBnZXRzIGEgdG9rZW4g dG8gbWFrZSBhbiBBUEkgY2FsbCB0byBhIHByb3RlY3RlZCByZXNvdXJjZSB0aGF0IHJldHVybnMg YW4gQXRvbSBmZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgZmVlZCBjb250YWlucyBsb3RzIG9mIGVu dHJpZXMsIHdpdGggbGlua3MgdG8gcGhvdG9zLCBzdHlsZSBzaGVldHMsIGFuZCBzY3JpcHRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5UaGUgY2xpZW50IGFwcCBnZXRzIHRoZSBwaG90b3MuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TaG91bGQgaXQgc2VuZCB0aGUgdG9rZW4gd2hlbiBn ZXR0aW5nIHRoZSBwaG90b3M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5P biBzZXJ2aWNlIEEgdGhlIEF0b20gZmVlZCBhbmQgdGhlIHBob3RvcyBhcmUgYWxsIHNlcnZlZCBm cm9tIHRoZSBzYW1lIEhUVFBTIGhvc3QsIHdpdGggdGhlIHNhbWUgcHJvdGVjdGlvbiwgc28gdGhl IHRva2VuIG11c3QgYmUgc2VudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi Pk9uIHNlcnZpY2UgQiB0aGUgcGhvdG9zIGFyZSBob3N0ZWQgb24gYSBzZXBhcmF0ZSBvdXRzb3Vy Y2VkIGNvbnRlbnQgZGlzdHJpYnV0aW9uIG5ldHdvcmsuIFRoZSBwaG90b3MgYXJlIHByb3RlY3Rl ZCBieSB1c2luZyBsb25nIHVuZ3Vlc3NhYmxlIFVSSXMgKHRoZSBVUklzIGFyZSBlZmZlY3RpdmVs eSDigJxjYXBhYmlsaXRpZXPigJ0gdG8gcmVhZCB0aGUgcGhvdG9zKS4NCiBUaGUgdG9rZW4gZG9l cyBub3QgbmVlZCB0byBiZSBzZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+T24gc2VydmljZSBDIHRoZSBwaG90b3MgYXJlIGFueSBpbWFnZXMgZnJvbSBhbnl3aGVyZSBv biB0aGUgSW50ZXJuZXQgdGhhdCB0aGUgdXNlciBoYXMgY2hvc2VuIHRvIGxpbmsgdG8uIFRoZSBB dG9tIGNvbGxlY3Rpb24gaXMgcHJvdGVjdGVkLCBidXQgbm90IHRoZSBwaG90b3MuIFRoZSB0b2tl biBhYnNvbHV0ZWx5IG11c3Qgbm90IGJlIHNlbnQgd2hlbiBnZXR0aW5nDQogdGhlIHBob3Rvcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5BIGNsaWVudCBhcHAgbmVlZHMgdG8ga25vdyB3aGV0aGVyIHRoZSBzZXJ2aWNlIGl0IGlzIGFj Y2Vzc2luZyBpcyBsaWtlIEEsIEIsIG9yIEMuIEl0IG5lZWRzIHRvIGtub3cgZm9yIHJlZGlyZWN0 cywgZm9yIGxpbmtzIGluIEhUVFAgaGVhZGVycywgZm9yIGxpbmtzIHRvIGltYWdlcywgZm9yIGFu eSBvdGhlciBzb3J0IG9mIGxpbmsgdGhhdCBpcyBjYW4gZGVyaXZlDQogZnJvbSB0aGUgcmVzcG9u c2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Tb21lIHNlcnZpY2VzIG1p Z2h0IGJlIGNvbXBsZXRlbHkgd2FsbGVkIGdhcmRlbnMgc28gdGhlIGNsaWVudCBjYW4gYXNzdW1l IHRoZXkgYXJlIGxpa2UgQS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U29tZSBzZXJ2aWNlcyBtaWdodCBleHBs aWNpdGx5IHN0YXRlIGluIHRoZWlyIGRvY3VtZW50YXRpb246IHdoaWNoIGxpbmtzIGFuZCByZWRp cmVjdHMgYXJlIGFsd2F5cyBndWFyYW50ZWVkIHRvIGJlIG90aGVyIEFQSSBjYWxscyAoc2VuZCB0 aGUgdG9rZW4pOyB3aGljaCB3aWxsIGFsd2F5cyBiZSB0byBvdGhlciBzZWN1cml0eSBjb250ZXh0 cyAoZG9u4oCZdCBzZW5kDQogdGhlIHRva2VuKTsgYW5kIHdoaWNoIG1pZ2h0IGJlIGVpdGhlciAo ZG9u4oCZdCBzZW5kIHRoZSB0b2tlbiwgc2VlIGlmIHlvdSBnZXQgYSA0MDEvNDAzLCBndWVzcywg c2VuZCB0aGUgdG9rZW4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4g Z2VuZXJhbCwgdGhlIHdlYiBpcyBhYm91dCBmb2xsb3dpbmcgbGlua3MuIENsaWVudHMgbmVlZCB0 byBrbm93IHdoZW4gZm9sbG93aW5nIGEgbGluayBjcm9zc2VzIGEgc2VjdXJpdHkgYm91bmRhcnku IENvb2tpZXMgcHJvdmlkZSB0aGlzOyBCYXNpYyBwcm92aWRlcyB0aGlzOyBEaWdlc3QgcHJvdmlk ZXMgdGhpczsgT0F1dGggbmVlZHMgdGhpcyB0b28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E112632852F1WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Mon May 10 17:36:54 2010 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 5B5B228C0F9 for ; Mon, 10 May 2010 17:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.416 X-Spam-Level: * X-Spam-Status: No, score=1.416 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5YNvzISeU-V for ; Mon, 10 May 2010 17:36:53 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 645753A67AD for ; Mon, 10 May 2010 17:36:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,203,1272808800"; d="scan'208";a="3013389" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 11 May 2010 10:36:42 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5978"; a="1787679" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbni.tcif.telstra.com.au with ESMTP; 11 May 2010 10:36:42 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 11 May 2010 10:36:41 +1000 From: "Manger, James H" To: Marius Scurtescu Date: Tue, 11 May 2010 10:36:39 +1000 Thread-Topic: [OAUTH-WG] SWT for indicating sites where a token is valid Thread-Index: Acrwm7ILVrA/+RI5RBm8dGkNOu2+sgAAB4nA Message-ID: <255B9BB34FB7D647A506DC292726F6E1126328531E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1126328511A@WSMSG3153V.srv.dir.telstra.com> 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 Cc: OAuth WG Subject: Re: [OAUTH-WG] SWT for indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 00:36:54 -0000 TWFyaXVzLA0KDQo+IEJ1dCB0aGVuIGFnYWluLCBob3cgZG9lcyB0aGUgY2xpZW50IGVuZCB1cCBt YWtpbmcgYSByZXF1ZXN0IHRvDQp0aGUgd3Jvbmcgc2l0ZT8NCg0KVGhlIGNsaWVudCBmb2xsb3dz IGEgcmVkaXJlY3Qgb3IgbGluay4gSXQgZG9lc24ndCBrbm93IGlmIHRoZSB1bHRpbWF0ZSBzb3Vy Y2Ugb2YgdGhlIG5ldyBVUkkgd2FzIHRoZSByZXNvdXJjZSBzZXJ2ZXLigJlzIGludGVybmFsIGxv Z2ljLCB1c2VyLWdlbmVyYXRlZCBjb250ZW50LCBvciBhIHBhcmFtZXRlciBpbiB0aGUgcmVxdWVz dCBVUkkgKGVnIGFuIG9wZW4gcmVkaXJlY3RvcikuDQoNCg0KPj4gSWYgdGhlIHdyb25nIHNpdGUg dXNlcyBIVFRQIHRoZW4gdGhlIHRva2VuIGlzIGFsc28gZXhwb3NlZCBvbiB0aGUgbmV0d29yayAt LSBzbyBpdCBoYXMganVzdCBiZWVuIGJyb2FkY2FzdCBpbiB0aGUgY2xlYXIgaWYgeW91IGFyZSB1 c2luZyBwdWJsaWMgd2lmaS4gQWdhaW4gYSBzZWN1cml0eSBmYWlsdXJlLg0KDQo+IFN1cmUsIGJ1 dCB0aGUgInNpdGVzIiBwYXJhbWV0ZXIgZG9lcyBub3QgaGVscCBpbiB0aGVzZSBjYXNlcy4NCg0K InNpdGVzIiBkb2VzIGhlbHAuIElmIGl0cyB2YWx1ZSB3YXM6DQogICJzaXRlcyI6IFsiaHR0cHM6 Ly9hcGkuZXhhbXBsZS5jb20iLCAiaHR0cHM6Ly9pbWcuZXhhbXBsZS5jb20iXQ0KVGhlbiBubyBI VFRQIFVSSSBtYXRjaGVzIHNvIHRoZSB0b2tlbiBpcyBuZXZlciBzZW50IGluIHRoZSBjbGVhci4N Cg0KLS0NCkphbWVzIE1hbmdlcg0K From uidude@google.com Mon May 10 17:43:56 2010 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 8E9C028C0F9 for ; Mon, 10 May 2010 17:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.734 X-Spam-Level: X-Spam-Status: No, score=-101.734 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 TBwJec4GhOIB for ; Mon, 10 May 2010 17:43:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 744573A67AD for ; Mon, 10 May 2010 17:43:55 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o4B0hhtF025957 for ; Mon, 10 May 2010 17:43:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273538623; bh=t9H+9F5NZ+MfgOseUIBXsSfvdGU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mZCqZy4KSUbIggll4Qk8sT/fprhZD3p9wALvJYFCMq2tqqmViN+s9zfBiIMGUgWwy rOV25LQJy1KsFBlqWgppA== 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=lO/eVmL2KLfUYiAi06ZKipKcK2u5zFU8NwDCobHv7ZPaRu6sj2kh5/+RDDiSVLg1O XGn7JvOV6a6BbzpYCrQDw== Received: from qyk35 (qyk35.prod.google.com [10.241.83.163]) by hpaq12.eem.corp.google.com with ESMTP id o4B0hfD9022434 for ; Mon, 10 May 2010 17:43:42 -0700 Received: by qyk35 with SMTP id 35so6749062qyk.15 for ; Mon, 10 May 2010 17:43:41 -0700 (PDT) Received: by 10.229.188.72 with SMTP id cz8mr4132131qcb.75.1273538621282; Mon, 10 May 2010 17:43:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Mon, 10 May 2010 17:43:21 -0700 (PDT) In-Reply-To: <38BB2577-B607-4033-A1C0-F8780DF47746@lodderstedt.net> References: <4BE730CC.1090607@lodderstedt.net> <38BB2577-B607-4033-A1C0-F8780DF47746@lodderstedt.net> From: Evan Gilbert Date: Mon, 10 May 2010 17:43:21 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=0016364ecce8211b8f048646d15f X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 11 May 2010 00:43:56 -0000 --0016364ecce8211b8f048646d15f Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 10, 2010 at 1:20 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > > > Am 10.05.2010 um 22:07 schrieb Marius Scurtescu : > > > On Sun, May 9, 2010 at 3:01 PM, Torsten Lodderstedt >> wrote: >> >>> 3.5.1.1. End-user Grants Authorization >>> >>> I would suggest to use JSON encoding here, since the URI fragment is >>> handled >>> by a client more or less like a response result. >>> >> >> Evan mentioned that returning JSON in this case is a bad idea because >> it is very hard to safely parse JSON in JavaScript. >> >> Marius >> > > Native JSON support makes it easier. Only for newer browsers - every web site that wants to work on older browser would need a JSON parsing library. Think that people on the form encoding or JSON thread were in rough agreement that redirect_uri responses should be form encoded. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016364ecce8211b8f048646d15f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 10, 2010 at 1:20 PM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:


Am 10.05.2010 um 22:07 schrieb Marius Scurtescu <mscurtescu@google.com>:


On Sun, May 9, 2010 at 3:01 PM, Torsten Lodderstedt
<torsten@lo= dderstedt.net> wrote:
3.5.1.1. =A0End-user Grants Authorization

I would suggest to use JSON encoding here, since the URI fragment is handle= d
by a client more or less like a response result.

Evan mentioned that returning JSON in this case is a bad idea because
it is very hard to safely parse JSON in JavaScript.

Marius

Native JSON support makes it easier.

Only for newer br= owsers - every web site that wants to work on older browser would need a JS= ON parsing library.

Think that people on the form encoding or= JSON thread were in rough agreement that redirect_uri responses should be = form encoded.


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

--0016364ecce8211b8f048646d15f-- From recordond@gmail.com Mon May 10 18:28:22 2010 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 E27493A6AB9 for ; Mon, 10 May 2010 18:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_50=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 2T3mL9RbrlSt for ; Mon, 10 May 2010 18:28:21 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 983B93A67AB for ; Mon, 10 May 2010 18:28:21 -0700 (PDT) Received: by gwaa12 with SMTP id a12so2490288gwa.31 for ; Mon, 10 May 2010 18:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2p5w6ZEwyqBW5G/e8aAl7sMK9QvB41n8pnokWYkGFLc=; b=CAg0vohLY1Gr88K2wKZPG0fKS3kobGqOGdO33wNr8R8Jl0GCwXyzzoGMJA4S8WUgq6 A9pJ+geE3C9mx22BuLPFHE0iWZGens9/ohdFM7Tl8KUwT+Jg38ojUlykzOBnk9Qu1Z0B oQ6f2WAWdc+jZqXa7TVwLQFQrrm0IR5QPAirw= 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=fRcSAmnzQhL5Y7C/Sn3E1TEWHWxwhfE8NBjL4ZcJfEFkurvBL6rPWVJgMpUZeP5ZWF oocyhElpd2P8n6zgyMkj8j/OWCr3GuOw1TjAXQ30RE1SFk19GVVOxKL5C9mWMiaXX6Pg kTbvjroETgBueQiAbZdrJm0rDE2TwD4Fr5ujk= MIME-Version: 1.0 Received: by 10.231.190.5 with SMTP id dg5mr3076083ibb.44.1273541284059; Mon, 10 May 2010 18:28:04 -0700 (PDT) Received: by 10.231.176.4 with HTTP; Mon, 10 May 2010 18:28:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 May 2010 18:28:03 -0700 Message-ID: From: David Recordon To: Evan Gilbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Provisional OAuth enhancements 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, 11 May 2010 01:28:23 -0000 If you're volunteering to draft text, then go for it. Otherwise I'm unclear what you're actually proposing... And we do have an implementation of scope in the wild. See "Requesting Extended Permissions" on http://developers.facebook.com/docs/authentication/. --David On Mon, May 10, 2010 at 4:50 PM, Evan Gilbert wrote: > I'm seeing a few OAuth features in spec discussions which: > - Feel like it would be a major omission if they don't make it into OAuth > 2.0, but > - Haven't been used previously or even prototyped, which makes people > uncomfortable with adding to the spec > > This includes the scope / sites syntax discussion (among others). > I'm wondering if there would any interest in collaborating on a Wiki for > "provisional" spec enhancements. The goal would be have a place for early > implementers to share a spec- these changes would not go into the OAuth 2= .0 > draft until we have implementation experienc. However discussions would > still be on the main mailing list. > On Mon, May 10, 2010 at 4:11 PM, Brian Eaton wrote: >> >> On Mon, May 10, 2010 at 7:32 AM, Manger, James H >> wrote: >> > HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good >> > match to how Google uses scope >> > values. >> >> It's not, actually. =A0Our scopes are sometimes URI prefixes, and >> sometimes are not. =A0The reality is complicated, and to be honest is >> poorly documented. =A0We're working on it. >> >> As I've said in a few other e-mail threads, I think it would be a >> serious mistake to publish a standard that doesn't reflect things that >> are already deployed in the wild and are well-understood. >> >> If people want to see systems that automatically determines scopes and >> reuses tokens, I think they should go and build those systems. =A0Then >> come back to the community with explanations of what they did, and why >> other people should adopt it. >> >> 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 recordond@gmail.com Mon May 10 18:32:01 2010 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 774E63A6978 for ; Mon, 10 May 2010 18:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 Sl73hkdu199H for ; Mon, 10 May 2010 18:32:00 -0700 (PDT) Received: from mail-gx0-f216.google.com (mail-gx0-f216.google.com [209.85.217.216]) by core3.amsl.com (Postfix) with ESMTP id 5409E28C0FE for ; Mon, 10 May 2010 18:32:00 -0700 (PDT) Received: by gxk8 with SMTP id 8so466160gxk.9 for ; Mon, 10 May 2010 18:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kQYWhRVvSxV9i57ENvUYCO7pC0V778UP6EG1k1JkWsk=; b=ubypv941d3+tvvGl6S4I+r+hwQfu88NpNWfWUHVd7l+nIaNo8gtF7gULcX9odiNM1q HoJxac/fofqahes0sDYmR/vOoUB7t2TQ6BAHK3T4YLsNT4FQmI3EbN1kftHCTXfDSt9E Gm3bpU6DHUEnhTrdWDGIpPtMjXH+Rmu3a2e+c= 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=FmqGc0wY7Qld7P1y9fB8+W6HQs04WLXk9yGvvr+DG6O61yVVp5GCcHcEQsMaOnRoJi a/rGCW1wbv27XuUWnHbTjOsr2kA5TG3TbKJHqcfvCyKKEqLjmIaLbpeW16feL+O6ijjA zYR/IeQM1anCgionZF4cVgVcl0AsD/pgfJQ3Q= MIME-Version: 1.0 Received: by 10.231.167.7 with SMTP id o7mr3089661iby.39.1273541506555; Mon, 10 May 2010 18:31:46 -0700 (PDT) Received: by 10.231.176.4 with HTTP; Mon, 10 May 2010 18:31:46 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 18:31:46 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] delegating access to another client 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, 11 May 2010 01:32:01 -0000 I'm concerned about prematurely standardizing something which we don't have deployment experience to guide. One of the things I like most about OAuth 2.0 is that we're largely not inventing new things. Rather learning from what others have done in the past. My view is that redelegation should first be drafted and deployed as an extension. --David On Sun, May 9, 2010 at 10:20 PM, Eran Hammer-Lahav wr= ote: > Re-delegation is something people asked for since we started talking abou= t OAuth. There is also a draft I-D about it. This is explicitly out of scop= e for the core spec (but not something that should stop us from having a di= scussion). > > The main concern is how should the resource owner express their approval = for such arrangement? > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Dick Hardt >> Sent: Sunday, May 09, 2010 7:34 PM >> To: OAuth WG (oauth@ietf.org) >> Subject: [OAUTH-WG] delegating access to another client >> >> Twitter has an interesting use case that may become common: one client >> needs to delegate access to another client. Similar to the 'modify' meth= od >> where the scope of the access token can be modified, the 'delegate' meth= od >> allows a client to request delegation to another client (the delegate). = Here is >> some proposed copy for the request: >> >> type >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set to delegate >> >> client_id >> =A0 =A0 =A0 REQUIRED. The client identifier as described in Section 3.4. >> >> client_secret >> =A0 =A0 =A0 REQUIRED if the client was issued a secret. The client secre= t. >> >> refresh_token >> =A0 =A0 =A0 REQUIRED. The refresh token associated with the client. >> >> delegate_id >> =A0 =A0 =A0 REQUIRED. The client identifier of the delegate >> >> scope >> =A0 =A0 =A0 OPTIONAL. The scope the client is requesting for the delegat= e. >> >> secret_type >> =A0 =A0 =A0 OPTIONAL. The access token secret type as described by Secti= on 8.3. >> If omitted, the authorization server will issue a bearer token (an acces= s token >> without a matching secret) as described by Section 8.2. >> >> There a couple of choices for the flows for how a successful delegation = is >> conveyed to the delegate. The AS could return a delegation code that is >> similar to a verification code and the delegate acquires an access token >> similar to 3.6.2 Alternatively, the AS could return an delegation token = that is >> used similar to a refresh token to obtain an access token and refresh to= ken. >> >> Do people think this is worth adding to the spec? It seems to be a simpl= e >> addition and allows us to standardize what is emerging as a common >> capability. >> >> -- Dick >> _______________________________________________ >> 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 recordond@gmail.com Mon May 10 18:34:22 2010 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 6120928C1BE for ; Mon, 10 May 2010 18:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_50=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 NupoOVy-9Col for ; Mon, 10 May 2010 18:34:21 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 6FF6C28C18F for ; Mon, 10 May 2010 18:34:21 -0700 (PDT) Received: by ywh3 with SMTP id 3so1443122ywh.31 for ; Mon, 10 May 2010 18:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SaBBcKkPjmVwh8BJzIEa7Yy/+UGd88GoZpHb34hDiJo=; b=hn3dDq5F8SO3+Am8we5reziGi/RFyS3k06vWvLVpxxqJs2zvIGR9bhY4uvsaGMeDUc n2mo2X7iXaPqkDVVhhdD+406PQYV0YVnQT1z9QaxA6gRkRBtLWyvnQwiXjnh8PWWUYQQ C5NSVSeU/j+s9AEGKv5FGuiCRniVm4vOeDQDU= 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=Vfe5o4ihishEo4s87MRD27uRP6/Z818g4uvuecLlYxIv2yeVn9HCGOj1KQHEIkVdg5 G7yjlSxK6adnD7L++vF9VqVuOSo6v8ktzRudU9/KEwyjwrjJN76Ao0wHROd2YR5XD9fh 5bqIF43Jbvruz8k5SLJKFSQLBnIbRLmcT6O/I= MIME-Version: 1.0 Received: by 10.231.171.204 with SMTP id i12mr3508080ibz.45.1273541645522; Mon, 10 May 2010 18:34:05 -0700 (PDT) Received: by 10.231.176.4 with HTTP; Mon, 10 May 2010 18:34:05 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 10 May 2010 18:34:05 -0700 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 01:34:22 -0000 Hey James, I guess the way that we solved this was having the Protected Resource include the access token in links as applicable. We don't do cross site access tokens and I'd hate to see us standardize this more complex use case without real world deployment experience. Do you have an implementation with this problem that we can look at? Thanks, --David On Mon, May 10, 2010 at 5:31 PM, Manger, James H wrote: > Yaron, > > > >> I don=92t understand the scenario that requires this feature. When does >> someone ask for a token without knowing where it is going? > > > > Example: > > A client app gets a token to make an API call to a protected resource tha= t > returns an Atom feed. > > The feed contains lots of entries, with links to photos, style sheets, an= d > scripts. > > The client app gets the photos. > > > > Should it send the token when getting the photos? > > > > On service A the Atom feed and the photos are all served from the same HT= TPS > host, with the same protection, so the token must be sent. > > > > On service B the photos are hosted on a separate outsourced content > distribution network. The photos are protected by using long unguessable > URIs (the URIs are effectively =93capabilities=94 to read the photos). Th= e token > does not need to be sent. > > > > On service C the photos are any images from anywhere on the Internet that > the user has chosen to link to. The Atom collection is protected, but not > the photos. The token absolutely must not be sent when getting the photos= . > > > > > > A client app needs to know whether the service it is accessing is like A,= B, > or C. It needs to know for redirects, for links in HTTP headers, for link= s > to images, for any other sort of link that is can derive from the respons= e. > > > > Some services might be completely walled gardens so the client can assume > they are like A. > > Some services might explicitly state in their documentation: which links = and > redirects are always guaranteed to be other API calls (send the token); > which will always be to other security contexts (don=92t send the token);= and > which might be either (don=92t send the token, see if you get a 401/403, > guess, send the token). > > > > In general, the web is about following links. Clients need to know when > following a link crosses a security boundary. Cookies provide this; Basic > provides this; Digest provides this; OAuth needs this too. > > > > > > -- > > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From James.H.Manger@team.telstra.com Mon May 10 19:11:25 2010 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 2AD7A3A67EC for ; Mon, 10 May 2010 19:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50n1b6qomHW0 for ; Mon, 10 May 2010 19:11:24 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id B22DF3A67BD for ; Mon, 10 May 2010 19:11:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,204,1272808800"; d="scan'208";a="2345289" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 11 May 2010 12:11:05 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5978"; a="2084323" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 11 May 2010 12:11:06 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 11 May 2010 12:11:05 +1000 From: "Manger, James H" To: David Recordon Date: Tue, 11 May 2010 12:10:58 +1000 Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AcrwqgxTLF7lIm8BTtiEy4N7zNdyCwAACAeQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1126328565D@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {9503B28C-4B8D-413C-8815-F01ADC68CC2E} x-cr-hashedpuzzle: CgNK H8hT NdNM OMQU QUz+ QbXH TAEL VAz8 WpPm XpFN ajjD bLn5 cHN/ caqH iX+V jNOk; 3; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnADsAcgBlAGMAbwByAGQAbwBuAGQAQABnAG0AYQBpAGwALgBjAG8AbQA7AHkAYQByAG8AbgBnAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=; Sosha1_v1; 7; {9503B28C-4B8D-413C-8815-F01ADC68CC2E}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Tue, 11 May 2010 02:10:58 GMT; UgBFADoAIABbAE8AQQBVAFQASAAtAFcARwBdACAAcwBpAHQAZQBzACAAdwBpAHQAaAAgAHcAaQBsAGQAYwBhAHIAZAA= acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 02:11:25 -0000 SGkgRGF2aWQsDQoNCj4gSSBndWVzcyB0aGUgd2F5IHRoYXQgd2Ugc29sdmVkIHRoaXMgd2FzIGhh dmluZyB0aGUgUHJvdGVjdGVkIFJlc291cmNlDQo+IGluY2x1ZGUgdGhlIGFjY2VzcyB0b2tlbiBp biBsaW5rcyBhcyBhcHBsaWNhYmxlLg0KDQpZZXMsIEkgbm90aWNlZCBGYWNlYm9vayBkaWQgdGhp cyBpbiBzb21lIGFjdHVhbCByZXNwb25zZXMgKHRob3VnaCBJIGRvbid0IHRoaW5rIEkgc2F3IGl0 IGRvY3VtZW50ZWQpLg0KSSBkb24ndCBwZXJzb25hbGx5IHRoaW5rIGl0IGlzIGEgZ3JlYXQgYXJj aGl0ZWN0dXJhbCBjaG9pY2UsIGJ1dCBJIGd1ZXNzIGl0IHdvcmtzIGZvciBGYWNlYm9vayB0b2Rh eS4NCkkgaG9wZSB0aGF0IGlzbuKAmXQgdGhlIG9ubHkgYXBwcm9hY2ggZmVhc2libGUgd2l0aCBP QXV0aC4NCg0KSW5jbHVkaW5nIHRva2VucyBpbiBsaW5rcyBkb2VzIG5vdCB3b3JrIGlmIHlvdSB3 YW50IHRvIHVzZSB0aGUgQXV0aG9yaXphdGlvbiBIVFRQIGhlYWRlciAtLSB3aGljaCBvZmZlcnMg c29tZSBzZWN1cml0eSBiZW5lZml0cywgYW5kIGlzIHBhcnQgb2YgT0F1dGguDQpJdCBkb2Vzbid0 IHBsYXkgdGhhdCBuaWNlbHkgd2l0aCBvdGhlciBhc3BlY3RzIG9mIHRoZSB3ZWIgYXJjaGl0ZWN0 dXJlIChzdWNoIGFzIGNhY2hpbmcsIGV0YWdzLCBjb25kaXRpb25hbCByZXF1ZXN0cywgYm9va21h cmtzLi4uKSBhcyBhbGwgdGhlIFVSSXMgY2hhbmdlIGZvciBlYWNoIGNsaWVudC91c2VyL3JlZnJl c2guIFRoZSBzZXJ2ZXIgYWxzbyBoYXMgdG8gZHluYW1pY2FsbHkgZ2VuZXJhdGUgZWFjaCBwYWdl IGZvciBlYWNoIHRva2VuLg0KSXQgcHV0cyBzZWNyZXRzIGluIHBsYWNlcyB3aGVyZSB0aGV5IG1p Z2h0IG5vdCBiZSBleHBlY3RlZC4gRG8gRmFjZWJvb2sgYXBwcyBrbm93IHRoYXQgZXhwb3Npbmcg dGhlIGNvbnRlbnQgb2YgYSBwcm90ZWN0ZWQgcmVzb3VyY2Ugb3IgZXhwb3NpbmcgYSBsaW5rIGl0 IGNvbnRhaW5zIGFsc28gZXhwb3NlcyB0aGVpciBzZWNyZXQgdG9rZW4/IFRoYXQgZG9lc24ndCBo YXBwZW4gd2l0aCBvdGhlciBhdXRoZW50aWNhdGlvbiBzY2hlbWVzLiBUb2tlbnMgaW4gVVJJcyB3 aWxsIGVuZCB1cCBpbiBtb3JlIGxvZ3MgYW5kIHNlYXJjaCBlbmdpbmUgaW5kZXhlcyBldGMuDQoN Cg0KPiBXZSBkb24ndCBkbyBjcm9zcyBzaXRlIGFjY2VzcyB0b2tlbnMNCg0KQXJlIHlvdSBzdXJl IHlvdSB3aWxsIG5vdCBpbiB0aGUgZnV0dXJlIChwZXJoYXBzIGFmdGVyIGEgbWVyZ2VyIG9yIGFj cXVpc2l0aW9uKT8NCg0KPiBhbmQgSSdkIGhhdGUgdG8gc2VlIHVzIHN0YW5kYXJkaXplIHRoaXMg bW9yZSBjb21wbGV4IHVzZSBjYXNlDQoNCkl0cyBub3QgdmVyeSBjb21wbGV4LCBwYXJ0aWN1bGFy bHkgaWYgdGhlIGRlZmF1bHQgdmFsdWUgZm9yICJzaXRlcyIgd2FzIHRoZSBzaXRlIHJldHVybmlu ZyB0aGUgdG9rZW4uIEZhY2Vib29rIHdvdWxkbid0IGhhdmUgdG8gZG8gYW55dGhpbmchIEV2ZW4g RmFjZWJvb2stc3BlY2lmaWMgYXBwcyBjb3VsZCBpZ25vcmUgYW55ICJzaXRlcyIgZmllbGQgYW5k IGp1c3QgaGFyZC13aXJlZCBhIHJ1bGUgdG8gdXNlIGEgRmFjZWJvb2sgdG9rZW4gb24gaW5pdGlh bCByZXF1ZXN0cyB0byBodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbSBVUklzIGFuZCB0aGF0J3Mg YWxsIChhc3N1bWluZyBGYWNlYm9vayBzYXlzIHRoYXQgaXMgaG93IHRoZWlyIEFQSSBpcyBkZXNp Z25lZCB0byB3b3JrKS4NCg0KDQo+IERvIHlvdSBoYXZlIGFuIGltcGxlbWVudGF0aW9uIHdpdGgg dGhpcyBwcm9ibGVtIHRoYXQgd2UgY2FuIGxvb2sgYXQ/DQoNClRoZSB3aG9sZSBJbnRlcm5ldCBp cyBhIHdlYiBvZiBsaW5rcyBhY3Jvc3Mgc2VjdXJpdHkgYm91bmRhcmllcy4NCkkgZG9uJ3QgaGF2 ZSBhIHNwZWNpZmljIE9BdXRoIGltcGxlbWVudGF0aW9uIHRvIGNoYW1waW9uIHRoaXMgaXNzdWUu DQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From James.H.Manger@team.telstra.com Mon May 10 19:18:12 2010 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 471483A67D3 for ; Mon, 10 May 2010 19:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.428 X-Spam-Level: * X-Spam-Status: No, score=1.428 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCsY+3aM2PXC for ; Mon, 10 May 2010 19:18:11 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 2E0B73A67A1 for ; Mon, 10 May 2010 19:18:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,204,1272808800"; d="scan'208";a="2344970" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 11 May 2010 12:17:59 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5978"; a="1803174" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccni.tcif.telstra.com.au with ESMTP; 11 May 2010 12:18:00 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 11 May 2010 12:17:59 +1000 From: "Manger, James H" To: Brian Eaton Date: Tue, 11 May 2010 12:17:58 +1000 Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AcrwliABXQ5gLwnfQvqKnGDHJsuTaQADVPnA Message-ID: <255B9BB34FB7D647A506DC292726F6E11263285695@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> 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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 02:18:12 -0000 QnJpYW4sDQoNCk9BdXRoIGJlYXJlciB0b2tlbnMgYXJlIHRvIGEgbGFyZ2UgZGVncmVlIGdsb3Jp ZmllZCBjb29raWVzLiBDb29raWVzIGhhdmUgYmVlbiBtYXNzaXZlbHkgZGVwbG95ZWQgaW4gdGhl IHdpbGQgd2l0aCB0aGVpciBvd24gdmFyaWV0eSBvZiBhICJzaXRlcyIgcGFyYW1ldGVyICgiZG9t YWluIiwgInBhdGgiIGFuZCAic2VjdXJlIiBwYXJhbWV0ZXJzKS4NCg0KVGhlIGJpZ2dlc3QgZGlm ZmVyZW50IGJldHdlZW4gY29va2llcyBhbmQgT0F1dGggdG9rZW5zIHRvZGF5IGlzIHRoYXQgYSBj bGllbnQgYXBwIG5lZWRzIGEgaHVnZSBkb2xsb3Agb2Ygc2VydmljZS1zcGVjaWZpYyBrbm93bGVk Z2UgdG8gdXNlIE9BdXRoLg0KDQpJJ2QgYXJndWUgdGhhdCB0aGUgY29va2llIGV4cGVyaWVuY2Ug Y291bnRzIGFzIGRldGVybWluaW5nIHdoYXQgYSBiZWFyZXIgdG9rZW4gc3lzdGVtIG5lZWRzIHRv IHdvcmsgYXQgSW50ZXJuZXQgc2NhbGUuDQoNCg0KUC5TLiBJIGhhdmUgYSBoYXp5IG1lbW9yeSB0 aGF0IEdvb2dsZSBkaWQgdXNlIHJlZGlyZWN0cyB3aXRoIGFuIE9BdXRoIDEgQVBJIHRoYXQgY2F1 c2VkIHNvbWUgY2xpZW50cyB0byBicmVhay4gSSB0aGluayBzb21lIHJlLXNpZ25lZCByZXF1ZXN0 cywgYW5kIG90aGVycyBkaWRuJ3QuIFRoYXQgbWlnaHQgYmUgYSBjYXNlIHdoZXJlIGEgInNpdGVz IiBwYXJhbWV0ZXIgd291bGQgaGF2ZSBtYWRlIHRoZSByaWdodCBhcHByb2FjaCBvYnZpb3VzICh1 bmxlc3MgaXQgd2FzIGp1c3QgYW4gZXNjYXBpbmcgaXNzdWUpLiBBbnlvbmUgaGF2ZSBhIGJldHRl ciBtZW1vcnk/DQoNCi0tIA0KSmFtZXMgTWFuZ2VyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEJyaWFuIEVhdG9uIFttYWlsdG86YmVhdG9uQGdvb2dsZS5jb21dIA0KU2Vu dDogVHVlc2RheSwgMTEgTWF5IDIwMTAgOToxMSBBTQ0KVG86IE1hbmdlciwgSmFtZXMgSA0KQ2M6 IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHNpdGVz IHdpdGggd2lsZGNhcmQNCg0KLi4uDQpBcyBJJ3ZlIHNhaWQgaW4gYSBmZXcgb3RoZXIgZS1tYWls IHRocmVhZHMsIEkgdGhpbmsgaXQgd291bGQgYmUgYQ0Kc2VyaW91cyBtaXN0YWtlIHRvIHB1Ymxp c2ggYSBzdGFuZGFyZCB0aGF0IGRvZXNuJ3QgcmVmbGVjdCB0aGluZ3MgdGhhdA0KYXJlIGFscmVh ZHkgZGVwbG95ZWQgaW4gdGhlIHdpbGQgYW5kIGFyZSB3ZWxsLXVuZGVyc3Rvb2QuDQoNCklmIHBl b3BsZSB3YW50IHRvIHNlZSBzeXN0ZW1zIHRoYXQgYXV0b21hdGljYWxseSBkZXRlcm1pbmVzIHNj b3BlcyBhbmQNCnJldXNlcyB0b2tlbnMsIEkgdGhpbmsgdGhleSBzaG91bGQgZ28gYW5kIGJ1aWxk IHRob3NlIHN5c3RlbXMuICBUaGVuDQpjb21lIGJhY2sgdG8gdGhlIGNvbW11bml0eSB3aXRoIGV4 cGxhbmF0aW9ucyBvZiB3aGF0IHRoZXkgZGlkLCBhbmQgd2h5DQpvdGhlciBwZW9wbGUgc2hvdWxk IGFkb3B0IGl0Lg0KDQpDaGVlcnMsDQpCcmlhbg0K From eran@hueniverse.com Mon May 10 19:43:57 2010 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 1B8CA3A69AC for ; Mon, 10 May 2010 19:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 O0zkjzGvbSKB for ; Mon, 10 May 2010 19:43:56 -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 19E5B3A6992 for ; Mon, 10 May 2010 19:43:55 -0700 (PDT) Received: (qmail 24581 invoked from network); 11 May 2010 02:43:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 May 2010 02:43:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 May 2010 19:43:44 -0700 From: Eran Hammer-Lahav To: Yaron Goland , "OAuth WG (oauth@ietf.org)" Date: Mon, 10 May 2010 19:43:48 -0700 Thread-Topic: Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vAA21lGgAAczO1A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.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] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 02:43:57 -0000 > -----Original Message----- > From: Yaron Goland [mailto:yarong@microsoft.com] > Sent: Monday, May 10, 2010 4:43 PM > > 2. Client Authentication (in flows) > > > > How should the client authenticate when making token requests? The > > current draft defines special request parameters for sending client > > credentials. Some have argued that this is not the correct way, and > > that the client should be using existing HTTP authentication schemes > > to accomplish that such as Basic. > > > > A. Client authenticates by sending its credentials using special > > parameters (current draft) B. Client authenticated by using HTTP Basic > > (or other schemes supported by the server such as Digest) > > > [Yaron Goland] A is needed at a minimum because there are physical > limitations to how many bytes can go into an authorization header. What? Basic auth seems to be working just fine for the entire web... EHL From eran@hueniverse.com Mon May 10 19:46:29 2010 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 C57AE3A6992 for ; Mon, 10 May 2010 19:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_50=0.001, 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 eafkAj6GsQKv for ; Mon, 10 May 2010 19:46:28 -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 714053A677E for ; Mon, 10 May 2010 19:46:28 -0700 (PDT) Received: (qmail 25303 invoked from network); 11 May 2010 02:46:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 May 2010 02:46:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 May 2010 19:46:17 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , Yaron Goland , "OAuth WG (oauth@ietf.org)" Date: Mon, 10 May 2010 19:46:21 -0700 Thread-Topic: sites with wildcard Thread-Index: AcrwTaPsC4ggYQawSQ6EnsB9Iie0cQATPiVwAAA9JoAABiNswA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112632852F1@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_90C41DD21FB7C64BB94121FBBC2E72343B3AB4712BP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 02:46:29 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB4712BP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdHJvbmdseSBhZ3JlZS4NCg0KRUhMDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFuZ2VyLCBKYW1l cyBIDQpTZW50OiBNb25kYXksIE1heSAxMCwgMjAxMCA1OjMxIFBNDQpUbzogWWFyb24gR29sYW5k OyBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBzaXRl cyB3aXRoIHdpbGRjYXJkDQoNCllhcm9uLA0KDQo+IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBz Y2VuYXJpbyB0aGF0IHJlcXVpcmVzIHRoaXMgZmVhdHVyZS4gV2hlbiBkb2VzIHNvbWVvbmUgYXNr IGZvciBhIHRva2VuIHdpdGhvdXQga25vd2luZyB3aGVyZSBpdCBpcyBnb2luZz8NCg0KRXhhbXBs ZToNCkEgY2xpZW50IGFwcCBnZXRzIGEgdG9rZW4gdG8gbWFrZSBhbiBBUEkgY2FsbCB0byBhIHBy b3RlY3RlZCByZXNvdXJjZSB0aGF0IHJldHVybnMgYW4gQXRvbSBmZWVkLg0KVGhlIGZlZWQgY29u dGFpbnMgbG90cyBvZiBlbnRyaWVzLCB3aXRoIGxpbmtzIHRvIHBob3Rvcywgc3R5bGUgc2hlZXRz LCBhbmQgc2NyaXB0cy4NClRoZSBjbGllbnQgYXBwIGdldHMgdGhlIHBob3Rvcy4NCg0KU2hvdWxk IGl0IHNlbmQgdGhlIHRva2VuIHdoZW4gZ2V0dGluZyB0aGUgcGhvdG9zPw0KDQpPbiBzZXJ2aWNl IEEgdGhlIEF0b20gZmVlZCBhbmQgdGhlIHBob3RvcyBhcmUgYWxsIHNlcnZlZCBmcm9tIHRoZSBz YW1lIEhUVFBTIGhvc3QsIHdpdGggdGhlIHNhbWUgcHJvdGVjdGlvbiwgc28gdGhlIHRva2VuIG11 c3QgYmUgc2VudC4NCg0KT24gc2VydmljZSBCIHRoZSBwaG90b3MgYXJlIGhvc3RlZCBvbiBhIHNl cGFyYXRlIG91dHNvdXJjZWQgY29udGVudCBkaXN0cmlidXRpb24gbmV0d29yay4gVGhlIHBob3Rv cyBhcmUgcHJvdGVjdGVkIGJ5IHVzaW5nIGxvbmcgdW5ndWVzc2FibGUgVVJJcyAodGhlIFVSSXMg YXJlIGVmZmVjdGl2ZWx5IOKAnGNhcGFiaWxpdGllc+KAnSB0byByZWFkIHRoZSBwaG90b3MpLiBU aGUgdG9rZW4gZG9lcyBub3QgbmVlZCB0byBiZSBzZW50Lg0KDQpPbiBzZXJ2aWNlIEMgdGhlIHBo b3RvcyBhcmUgYW55IGltYWdlcyBmcm9tIGFueXdoZXJlIG9uIHRoZSBJbnRlcm5ldCB0aGF0IHRo ZSB1c2VyIGhhcyBjaG9zZW4gdG8gbGluayB0by4gVGhlIEF0b20gY29sbGVjdGlvbiBpcyBwcm90 ZWN0ZWQsIGJ1dCBub3QgdGhlIHBob3Rvcy4gVGhlIHRva2VuIGFic29sdXRlbHkgbXVzdCBub3Qg YmUgc2VudCB3aGVuIGdldHRpbmcgdGhlIHBob3Rvcy4NCg0KDQpBIGNsaWVudCBhcHAgbmVlZHMg dG8ga25vdyB3aGV0aGVyIHRoZSBzZXJ2aWNlIGl0IGlzIGFjY2Vzc2luZyBpcyBsaWtlIEEsIEIs IG9yIEMuIEl0IG5lZWRzIHRvIGtub3cgZm9yIHJlZGlyZWN0cywgZm9yIGxpbmtzIGluIEhUVFAg aGVhZGVycywgZm9yIGxpbmtzIHRvIGltYWdlcywgZm9yIGFueSBvdGhlciBzb3J0IG9mIGxpbmsg dGhhdCBpcyBjYW4gZGVyaXZlIGZyb20gdGhlIHJlc3BvbnNlLg0KDQpTb21lIHNlcnZpY2VzIG1p Z2h0IGJlIGNvbXBsZXRlbHkgd2FsbGVkIGdhcmRlbnMgc28gdGhlIGNsaWVudCBjYW4gYXNzdW1l IHRoZXkgYXJlIGxpa2UgQS4NClNvbWUgc2VydmljZXMgbWlnaHQgZXhwbGljaXRseSBzdGF0ZSBp biB0aGVpciBkb2N1bWVudGF0aW9uOiB3aGljaCBsaW5rcyBhbmQgcmVkaXJlY3RzIGFyZSBhbHdh eXMgZ3VhcmFudGVlZCB0byBiZSBvdGhlciBBUEkgY2FsbHMgKHNlbmQgdGhlIHRva2VuKTsgd2hp Y2ggd2lsbCBhbHdheXMgYmUgdG8gb3RoZXIgc2VjdXJpdHkgY29udGV4dHMgKGRvbuKAmXQgc2Vu ZCB0aGUgdG9rZW4pOyBhbmQgd2hpY2ggbWlnaHQgYmUgZWl0aGVyIChkb27igJl0IHNlbmQgdGhl IHRva2VuLCBzZWUgaWYgeW91IGdldCBhIDQwMS80MDMsIGd1ZXNzLCBzZW5kIHRoZSB0b2tlbiku DQoNCkluIGdlbmVyYWwsIHRoZSB3ZWIgaXMgYWJvdXQgZm9sbG93aW5nIGxpbmtzLiBDbGllbnRz IG5lZWQgdG8ga25vdyB3aGVuIGZvbGxvd2luZyBhIGxpbmsgY3Jvc3NlcyBhIHNlY3VyaXR5IGJv dW5kYXJ5LiBDb29raWVzIHByb3ZpZGUgdGhpczsgQmFzaWMgcHJvdmlkZXMgdGhpczsgRGlnZXN0 IHByb3ZpZGVzIHRoaXM7IE9BdXRoIG5lZWRzIHRoaXMgdG9vLg0KDQoNCi0tDQpKYW1lcyBNYW5n ZXINCg== --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB4712BP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5r PXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkkgc3Ryb25nbHkgYWdyZWUuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+RUhMPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhh bGYgT2YgPC9iPk1hbmdlciwgSmFtZXMgSDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMTAs IDIwMTAgNTozMSBQTTxicj48Yj5Ubzo8L2I+IFlhcm9uIEdvbGFuZDsgT0F1dGggV0cgKG9hdXRo QGlldGYub3JnKTxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gc2l0ZXMgd2l0aCB3 aWxkY2FyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t QVUgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPllhcm9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jmd0OyA8 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRo ZSBzY2VuYXJpbyB0aGF0IHJlcXVpcmVzIHRoaXMgZmVhdHVyZS4gV2hlbiBkb2VzIHNvbWVvbmUg YXNrIGZvciBhIHRva2VuIHdpdGhvdXQga25vd2luZyB3aGVyZSBpdCBpcyBnb2luZz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+RXhhbXBsZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPkEgY2xpZW50IGFwcCBnZXRzIGEgdG9rZW4gdG8gbWFrZSBhbiBB UEkgY2FsbCB0byBhIHByb3RlY3RlZCByZXNvdXJjZSB0aGF0IHJldHVybnMgYW4gQXRvbSBmZWVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1B VSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIGZlZWQgY29udGFpbnMgbG90cyBvZiBlbnRyaWVz LCB3aXRoIGxpbmtzIHRvIHBob3Rvcywgc3R5bGUgc2hlZXRzLCBhbmQgc2NyaXB0cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPlRoZSBjbGllbnQgYXBwIGdldHMgdGhlIHBob3Rvcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+U2hvdWxkIGl0IHNlbmQg dGhlIHRva2VuIHdoZW4gZ2V0dGluZyB0aGUgcGhvdG9zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5PbiBzZXJ2aWNlIEEgdGhlIEF0b20gZmVlZCBh bmQgdGhlIHBob3RvcyBhcmUgYWxsIHNlcnZlZCBmcm9tIHRoZSBzYW1lIEhUVFBTIGhvc3QsIHdp dGggdGhlIHNhbWUgcHJvdGVjdGlvbiwgc28gdGhlIHRva2VuIG11c3QgYmUgc2VudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+T24gc2VydmljZSBC IHRoZSBwaG90b3MgYXJlIGhvc3RlZCBvbiBhIHNlcGFyYXRlIG91dHNvdXJjZWQgY29udGVudCBk aXN0cmlidXRpb24gbmV0d29yay4gVGhlIHBob3RvcyBhcmUgcHJvdGVjdGVkIGJ5IHVzaW5nIGxv bmcgdW5ndWVzc2FibGUgVVJJcyAodGhlIFVSSXMgYXJlIGVmZmVjdGl2ZWx5IOKAnGNhcGFiaWxp dGllc+KAnSB0byByZWFkIHRoZSBwaG90b3MpLiBUaGUgdG9rZW4gZG9lcyBub3QgbmVlZCB0byBi ZSBzZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz5PbiBzZXJ2aWNlIEMgdGhlIHBob3RvcyBhcmUgYW55IGltYWdlcyBmcm9tIGFueXdoZXJlIG9u IHRoZSBJbnRlcm5ldCB0aGF0IHRoZSB1c2VyIGhhcyBjaG9zZW4gdG8gbGluayB0by4gVGhlIEF0 b20gY29sbGVjdGlvbiBpcyBwcm90ZWN0ZWQsIGJ1dCBub3QgdGhlIHBob3Rvcy4gVGhlIHRva2Vu IGFic29sdXRlbHkgbXVzdCBub3QgYmUgc2VudCB3aGVuIGdldHRpbmcgdGhlIHBob3Rvcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5BIGNsaWVudCBhcHAgbmVlZHMgdG8ga25vdyB3aGV0aGVyIHRo ZSBzZXJ2aWNlIGl0IGlzIGFjY2Vzc2luZyBpcyBsaWtlIEEsIEIsIG9yIEMuIEl0IG5lZWRzIHRv IGtub3cgZm9yIHJlZGlyZWN0cywgZm9yIGxpbmtzIGluIEhUVFAgaGVhZGVycywgZm9yIGxpbmtz IHRvIGltYWdlcywgZm9yIGFueSBvdGhlciBzb3J0IG9mIGxpbmsgdGhhdCBpcyBjYW4gZGVyaXZl IGZyb20gdGhlIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdj b2xvcjojMUY0OTdEJz5Tb21lIHNlcnZpY2VzIG1pZ2h0IGJlIGNvbXBsZXRlbHkgd2FsbGVkIGdh cmRlbnMgc28gdGhlIGNsaWVudCBjYW4gYXNzdW1lIHRoZXkgYXJlIGxpa2UgQS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPlNvbWUgc2VydmljZXMgbWlnaHQgZXhwbGljaXRseSBzdGF0ZSBpbiB0aGVp ciBkb2N1bWVudGF0aW9uOiB3aGljaCBsaW5rcyBhbmQgcmVkaXJlY3RzIGFyZSBhbHdheXMgZ3Vh cmFudGVlZCB0byBiZSBvdGhlciBBUEkgY2FsbHMgKHNlbmQgdGhlIHRva2VuKTsgd2hpY2ggd2ls bCBhbHdheXMgYmUgdG8gb3RoZXIgc2VjdXJpdHkgY29udGV4dHMgKGRvbuKAmXQgc2VuZCB0aGUg dG9rZW4pOyBhbmQgd2hpY2ggbWlnaHQgYmUgZWl0aGVyIChkb27igJl0IHNlbmQgdGhlIHRva2Vu LCBzZWUgaWYgeW91IGdldCBhIDQwMS80MDMsIGd1ZXNzLCBzZW5kIHRoZSB0b2tlbikuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkluIGdlbmVyYWws IHRoZSB3ZWIgaXMgYWJvdXQgZm9sbG93aW5nIGxpbmtzLiBDbGllbnRzIG5lZWQgdG8ga25vdyB3 aGVuIGZvbGxvd2luZyBhIGxpbmsgY3Jvc3NlcyBhIHNlY3VyaXR5IGJvdW5kYXJ5LiBDb29raWVz IHByb3ZpZGUgdGhpczsgQmFzaWMgcHJvdmlkZXMgdGhpczsgRGlnZXN0IHByb3ZpZGVzIHRoaXM7 IE9BdXRoIG5lZWRzIHRoaXMgdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+LS0gPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB4712BP3PW5EX1MB01E_-- From eran@hueniverse.com Mon May 10 19:51:37 2010 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 AA7E73A677E for ; Mon, 10 May 2010 19:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 EI5rvFIGL5QL for ; Mon, 10 May 2010 19:51: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 7E05C3A6992 for ; Mon, 10 May 2010 19:51:35 -0700 (PDT) Received: (qmail 7039 invoked from network); 11 May 2010 02:51:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 May 2010 02:51:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 10 May 2010 19:51:21 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Mon, 10 May 2010 19:51:25 -0700 Thread-Topic: [OAUTH-WG] modifying the scope of an access token Thread-Index: AcrwedcEDoaom4K9QLyMt66mFtPXeAAOsv4Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] modifying the scope of an access 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, 11 May 2010 02:51:37 -0000 Are there actual use cases for this? Either way sounds like it belongs in a= n extension. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Monday, May 10, 2010 12:49 PM > To: Eran Hammer-Lahav > Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] modifying the scope of an access token >=20 > On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav > wrote: > > This would only work for the client credentials flow (because you keep = the > same authorization source). For all other flows you are breaking the > authorization boundaries. >=20 > If the requested scope is a subset of the original scope associated with = the > refresh token then it should be acceptable, right? >=20 > This would allow a client to request a larger set of scopes, needed for a= ll API > calls need for its function, but then get sub-scoped access tokens, parti= cular > to each API. This will prevent an API from receiving a too powerful acces= s > token. A compromised API could use access tokens to place calls against > other APIs, but not if it is narrowly scoped. >=20 > Marius >=20 > > > > What would be useful is to allow asking for more scope. For example, wh= en > asking for a token (the last step of each flow), also include a valid tok= en to > get a new token with the combined scope (new approval and previous). > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Dick Hardt > >> Sent: Sunday, May 09, 2010 7:19 PM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: [OAUTH-WG] modifying the scope of an access token > >> > >> There has been some discussion about modifying the scope of the > >> access token during a refresh. Perhaps we can add another "method" to > >> what the AS MAY support that allows modifying the scope of an access > >> token. Type of request is "modify" and the scope parameter is > >> required to indicate the new scope required. Suggested copy below: > >> > >> type > >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set to modify > >> > >> client_id > >> =A0 =A0 =A0 REQUIRED. The client identifier as described in Section 3.= 4. > >> > >> client_secret > >> =A0 =A0 =A0 REQUIRED if the client was issued a secret. The client sec= ret. > >> > >> refresh_token > >> =A0 =A0 =A0 REQUIRED. The refresh token associated with the access tok= en to > >> be refreshed. > >> > >> scope > >> =A0 =A0 =A0 REQUIRED. The new scope of the access request expressed as= a > >> list of space-delimited strings. The value of the scope parameter is > >> defined by the authorization server. If the value contains multiple > >> space-delimited strings, their order does not matter, and each string > >> adds additional access range to the requested scope. > >> > >> secret_type > >> =A0 =A0 =A0 OPTIONAL. The access token secret type as described by Sec= tion 8.3. > >> If omitted, the authorization server will issue a bearer token (an > >> access token without a matching secret) as described by Section 8.2. > >> > >> _______________________________________________ > >> 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 Mon May 10 19:53:43 2010 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 0B3B028C0D6 for ; Mon, 10 May 2010 19:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 OHg8TtC6u28i for ; Mon, 10 May 2010 19:53:42 -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 0691F3A6992 for ; Mon, 10 May 2010 19:53:41 -0700 (PDT) Received: (qmail 26888 invoked from network); 11 May 2010 02:53:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 May 2010 02:53:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 10 May 2010 19:53:30 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Mon, 10 May 2010 19:53:33 -0700 Thread-Topic: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt Thread-Index: Acrwfa3L0PrXyanRSYKqkERpVq1fWgAN3RxQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47130@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 11 May 2010 02:53:43 -0000 Propose text. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Monday, May 10, 2010 1:16 PM > To: Eran Hammer-Lahav > Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt >=20 > On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav > wrote: > > > >> -----Original Message----- > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Sunday, May 09, 2010 5:52 PM > > > >> >> 3.5.1. =A0Client Requests Authorization > >> >> > >> >> If the client has previously registered a redirection URI with the > >> >> =A0 =A0authorization server, the authorization server MUST verify t= hat > >> >> the > >> >> =A0 =A0redirection URI received matches the registered URI associat= ed > >> >> with > >> >> =A0 =A0the client identifier. > >> >> > >> >> Does this mean equality? Or just the same base string? > >> > > >> > Right now it depends on the server. > >> > >> The spec should clarify that. Suggested wording: > >> > >> > >> If the client has previously registered a redirection URI with the > >> authorization server, the authorization server MUST verify that the > >> redirection URI received matches the registered URI associated with > >> the client identifier. The components of the redirection URI that > >> must match the registered URI is authorization server dependant. > > > > I don't see how that helps... I also don't see why we can't just profil= e this > and decide on how the matching should be done. We have the state > parameter to help too. >=20 > I also think the spec should specify how the matching should be done. >=20 > If left up to the authz server then a client that designs its OAuth 2 > implementation will have to assume that all authz servers will do strict > equality matching, otherwise it may not be able to interact with some > servers. >=20 > For example, if the client assumes that it can use load balancing by vary= ing > the first part of the host name, and this may work with the fist authz se= rver it > integrate with, later this client will not be able to interact with an au= thz server > which does strict matching on host name. And changing the load balancing > architecture once deployed could be very hard. >=20 > Since there is a state parameter maybe it is enough to allow wild cards o= nly in > the domain name of the callback URI. >=20 > Marius From eran@hueniverse.com Mon May 10 20:05:44 2010 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 63BF528C0D6 for ; Mon, 10 May 2010 20:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_20=-0.74, 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 91IY0zhc90cd for ; Mon, 10 May 2010 20:05:38 -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 E51CB3A6992 for ; Mon, 10 May 2010 20:05:37 -0700 (PDT) Received: (qmail 29750 invoked from network); 11 May 2010 03:05:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 May 2010 03:05:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 May 2010 20:05:26 -0700 From: Eran Hammer-Lahav To: Evan Gilbert Date: Mon, 10 May 2010 20:05:28 -0700 Thread-Topic: [OAUTH-WG] Provisional OAuth enhancements Thread-Index: Acrwm5sRmABvOruSSn2JckGfGUkNiQAGrGJQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47132@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 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_90C41DD21FB7C64BB94121FBBC2E72343B3AB47132P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Provisional OAuth enhancements 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, 11 May 2010 03:05:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB47132P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see how moving the discussion/work on these features elsewhere will= help reach consensus on them. If someone has an idea that fails to get mom= entum on this list, they should work harder or reach out to the key people = on this list in private and try to talk them into supporting it. Back-chann= els are an important tool of creating a standard (as long as all decisions = are always made on the public list). But I'm not going to stop anyone from playing with the wiki... (or publish = their own extension I-D). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= van Gilbert Sent: Monday, May 10, 2010 4:50 PM To: Brian Eaton Cc: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Provisional OAuth enhancements I'm seeing a few OAuth features in spec discussions which: - Feel like it would be a major omission if they don't make it into OAuth 2= .0, but - Haven't been used previously or even prototyped, which makes people uncom= fortable with adding to the spec This includes the scope / sites syntax discussion (among others). I'm wondering if there would any interest in collaborating on a Wiki for "p= rovisional" spec enhancements. The goal would be have a place for early imp= lementers to share a spec- these changes would not go into the OAuth 2.0 dr= aft until we have implementation experienc. However discussions would still= be on the main mailing list. On Mon, May 10, 2010 at 4:11 PM, Brian Eaton > wrote: On Mon, May 10, 2010 at 7:32 AM, Manger, James H > w= rote: > HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good matc= h to how Google uses scope > values. It's not, actually. Our scopes are sometimes URI prefixes, and sometimes are not. The reality is complicated, and to be honest is poorly documented. We're working on it. As I've said in a few other e-mail threads, I think it would be a serious mistake to publish a standard that doesn't reflect things that are already deployed in the wild and are well-understood. If people want to see systems that automatically determines scopes and reuses tokens, I think they should go and build those systems. Then come back to the community with explanations of what they did, and why other people should adopt it. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB47132P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I donR= 17;t see how moving the discussion/work on these features elsewhere will he= lp reach consensus on them. If someone has an idea that fails to get moment= um on this list, they should work harder or reach out to the key people on = this list in private and try to talk them into supporting it. Back-channels= are an important tool of creating a standard (as long as all decisions are= always made on the public list).

 

But I’= ;m not going to stop anyone from playing with the wiki… (or publish t= heir own extension I-D).

<= o:p> 

EHL

 

 

 

From: oauth= -bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Evan = Gilbert
Sent: Monday, May 10, 2010 4:50 PM
To: Brian Ea= ton
Cc: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] P= rovisional OAuth enhancements

 

I'm seei= ng a few OAuth features in spec discussions which:

- Feel like it would be a major omission if they don't = make it into OAuth 2.0, but

- H= aven't been used previously or even prototyped, which makes people uncomfor= table with adding to the spec

<= br>This includes the scope / sites syntax discussion (among others).


I'm wondering if there would any = interest in collaborating on a Wiki for "provisional" spec enhanc= ements. The goal would be have a place for early implementers to share a sp= ec- these changes would not go into the OAuth 2.0 draft until we have imple= mentation experienc. However discussions would still be on the main mailing= list.

 

On Mon, May 10, 2010 at 4:11 PM, Brian Eaton <= ;beaton@google.com> wrote:

On Mon, May 10, 2010 at 7:= 32 AM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
&= gt; HTTP Digest uses (A) [A. List of URI prefixes]. (A) is a pretty good ma= tch to how Google uses scope
> values.

It's not, actually. &nb= sp;Our scopes are sometimes URI prefixes, and
sometimes are not.  T= he reality is complicated, and to be honest is
poorly documented.  = We're working on it.

As I've said in a few other e-mail threads, I t= hink it would be a
serious mistake to publish a standard that doesn't re= flect things that
are already deployed in the wild and are well-understo= od.

If people want to see systems that automatically determines scop= es and
reuses tokens, I think they should go and build those systems. &n= bsp;Then
come back to the community with explanations of what they did, = and why
other people should adopt it.

Cheers,
Brian
_______= ________________________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB47132P3PW5EX1MB01E_-- From eran@hueniverse.com Mon May 10 20:07:13 2010 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 A35DF28C10A for ; Mon, 10 May 2010 20:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_05=-1.11] 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 UIDRRT69Y341 for ; Mon, 10 May 2010 20:07:12 -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 5D75F3A6AC5 for ; Mon, 10 May 2010 20:07:11 -0700 (PDT) Received: (qmail 21978 invoked from network); 11 May 2010 03:07:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 May 2010 03:07:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 10 May 2010 20:07:00 -0700 From: Eran Hammer-Lahav To: David Recordon , "Manger, James H" Date: Mon, 10 May 2010 20:07:01 -0700 Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AcrwqhIiw+1jpN4hTguQu0OWwtuw0wADObmQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47133@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 03:07:13 -0000 Redirections are a bad example when used with an access token in the query = parameter... EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of David Recordon > Sent: Monday, May 10, 2010 6:34 PM > To: Manger, James H > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] sites with wildcard >=20 > Hey James, > I guess the way that we solved this was having the Protected Resource > include the access token in links as applicable. We don't do cross site a= ccess > tokens and I'd hate to see us standardize this more complex use case > without real world deployment experience. >=20 > Do you have an implementation with this problem that we can look at? >=20 > Thanks, > --David >=20 >=20 > On Mon, May 10, 2010 at 5:31 PM, Manger, James H > wrote: > > Yaron, > > > > > > > >> I don't understand the scenario that requires this feature. When does > >> someone ask for a token without knowing where it is going? > > > > > > > > Example: > > > > A client app gets a token to make an API call to a protected resource > > that returns an Atom feed. > > > > The feed contains lots of entries, with links to photos, style sheets, > > and scripts. > > > > The client app gets the photos. > > > > > > > > Should it send the token when getting the photos? > > > > > > > > On service A the Atom feed and the photos are all served from the same > > HTTPS host, with the same protection, so the token must be sent. > > > > > > > > On service B the photos are hosted on a separate outsourced content > > distribution network. The photos are protected by using long > > unguessable URIs (the URIs are effectively "capabilities" to read the > > photos). The token does not need to be sent. > > > > > > > > On service C the photos are any images from anywhere on the Internet > > that the user has chosen to link to. The Atom collection is protected, > > but not the photos. The token absolutely must not be sent when getting > the photos. > > > > > > > > > > > > A client app needs to know whether the service it is accessing is like > > A, B, or C. It needs to know for redirects, for links in HTTP headers, > > for links to images, for any other sort of link that is can derive from= the > response. > > > > > > > > Some services might be completely walled gardens so the client can > > assume they are like A. > > > > Some services might explicitly state in their documentation: which > > links and redirects are always guaranteed to be other API calls (send > > the token); which will always be to other security contexts (don't > > send the token); and which might be either (don't send the token, see > > if you get a 401/403, guess, send the token). > > > > > > > > In general, the web is about following links. Clients need to know > > when following a link crosses a security boundary. Cookies provide > > this; Basic provides this; Digest provides this; OAuth needs this too. > > > > > > > > > > > > -- > > > > James Manger > > > > _______________________________________________ > > 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 recordond@gmail.com Mon May 10 20:45:52 2010 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 1EBDB28C10C for ; Mon, 10 May 2010 20:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 wwDRdE3k5oM3 for ; Mon, 10 May 2010 20:45:50 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 5834228C103 for ; Mon, 10 May 2010 20:45:50 -0700 (PDT) Received: by ywh3 with SMTP id 3so1506857ywh.31 for ; Mon, 10 May 2010 20:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U0p3snf3kS7UCyNfaPDFnem6qmkj0b6cuKBE6FccP2g=; b=a1M6vdDZ1/r8kpF3tMfWULvKAt9ZcExRReCQKo2fXzcTrUxpjYOgn2Dp3ZjGocxman fBg68Vt1+s+sl57jiR+wum9TORiAo8ZrrJMVyInxLRc4E2oFAx8AKZncz2qynRD+xd1i lDSuVOGDhEw/zuLFAQhi32v4ifgivkloC9/Mc= 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=EMfa+PggfxwtwlIhGx31ngyIWW0Ium2InBAkjTPhvwJAeQ+fOlHvn/NLG/MuwfDYIX DNI50FxGtkU3myXA5EhSor4jsp0spi2ylcfxWQ+PNJETx8LFpmUMZ3pKnkJovs2uKM5F XXRp4yVs4GqY3skif8tDA5qfGaNcHO/xzZxDU= MIME-Version: 1.0 Received: by 10.231.145.210 with SMTP id e18mr3255893ibv.6.1273549536642; Mon, 10 May 2010 20:45:36 -0700 (PDT) Received: by 10.231.176.4 with HTTP; Mon, 10 May 2010 20:45:36 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 20:45:36 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 03:45:52 -0000 If the sites parameter is not specified, would it default to the domain of the authorization server. If it is specified, then the valid sites are what is explicitly listed. Wildcards would only be supported for subdomains and it would be assumed that any resource on that domain is valid. Thus with the user endpoint being https://graph.facebook.com/oauth/authoriz= e: 1) no sites parameter means the access token is only valid on https://graph.facebook.com/* 2) sites key with a value of ["https://graph.facebook.com/"] means that the access token is only valid on https://graph.facebook.com/* 3) sites key with a value of ["https://*.facebook.com/"] means that https://graph.facebook.com/* and https://www.facebook.com/* would both be valid (among other subdomains) 4) sites key with a value of ["https://graph.facebook.com/", "https://api.facebook.com/"] means that only https://graph.facebook.com/* and https://api.facebook.com/* would be valid 5) sites key with a value of ["https://api.facebook.com/"] means that the the token isn't valid on https://graph.facebook.com/ even though that's the authorization server Obviously the sites parameter isn't restricted to being on the same domain, just used it that way for these examples. Am I understanding the proposal correctly? Thanks, --David On Sun, May 9, 2010 at 2:29 PM, Eran Hammer-Lahav wro= te: > Add some sort of wildcard support and I think this looks good. > > EHL > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Manger, James H > Sent: Thursday, May 06, 2010 4:58 PM > To: OAuth WG > Subject: [OAUTH-WG] Indicating sites where a token is valid > > > > The OAuth2 protocol does not indicate where a token can be used. > > It needs to do so because if a client app sends a token to the wrong site= it > destroys the security. > > > > I suggest another field in the JSON token response: > > =A0 "sites": ["https://api.example.com", "http://photo.example.com:8080"] > > > > It would be a list of sites where the token can be used, specified by > scheme://host[:port]. > > > > The default value for the =93sites=94 field could be the token endpoint s= ite (or > the authorization endpoint site if a token endpoint isn=92t used). > > For instance, if Facebook=92s new API uses https://graph.facebook.com for= all > resources, tokens, and authorizations it could omit the =93sites=94 field= . > > > > > > P.S. I suggested this last month > http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html, =A0thou= gh I > mixed in additional ideas for formats and media type that are probable be= st > covered in their own treads. > > > > > > -- > > James Manger > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From sayrer@gmail.com Mon May 10 20:49:41 2010 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 A172F28C103 for ; Mon, 10 May 2010 20:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_20=-0.74, GB_I_LETTER=-2] 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 So4loHluvob6 for ; Mon, 10 May 2010 20:49:40 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id B3B6728C0F7 for ; Mon, 10 May 2010 20:49:40 -0700 (PDT) Received: by qyk11 with SMTP id 11so6700572qyk.13 for ; Mon, 10 May 2010 20:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=wgXC3HJy1BfQLbDSR2vWQmhW1D/wsxDCCg5BTzghXrg=; b=v6RVgG/nNflV83r7lxzfg/cg0w15+q2y14v6UioZ3fbpTvl337bgimEwt+ef4/llMk xNGXmLXx82BVuo53fIbZM/k+Ha8NnXv+zyGOYVc9sa4umtlijCMgKjSZTqZGIVbOCnoZ /z9BvJN5HXoy9bji8LsY87wFJZnjttc8M5g28= 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=TssIu7x5576n1Wfi5dIACUa4nrWERRo3Xk6yVbLzQ+MfJpJmkiRKMHVhr9KysocJC1 oEavtajNO/HWSw2/2hCNlp6EcoI1X8vb2MiWp744Qoxly8MArb8nlJD7V1CrlfrfJTgn 6TGKDzv4oiWRFROBb/36YCk4kuwtx9iejVq7w= MIME-Version: 1.0 Received: by 10.229.182.5 with SMTP id ca5mr4156363qcb.98.1273549766600; Mon, 10 May 2010 20:49:26 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Mon, 10 May 2010 20:49:26 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 23:49:26 -0400 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 03:49:41 -0000 On Mon, May 10, 2010 at 10:43 PM, Eran Hammer-Lahav wrote: > > What? > > Basic auth seems to be working just fine for the entire web... I hadn't heard of implementations hitting a limitation on header size, but Basic and Digest are both broken. Basic leaves the input character encoding unspecified, so it doesn't handle anything but ASCII in an interoperable way. OAuth implementations will certainly screw this up too, but I suspect it will be somewhat less buggy, since most people will probably just guess it's supposed to be UTF-8. The way Digest hashes credentials is incompatible with pretty much every authentication database, so it never gets used, and it isn't very secure anyway. What /would/ be nice is an HTTP authentication scheme that used some sort of PAKE... but don't gate the OAuth spec on that. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From James.H.Manger@team.telstra.com Mon May 10 20:52:39 2010 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 6351F28C10C for ; Mon, 10 May 2010 20:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.063 X-Spam-Level: * X-Spam-Status: No, score=1.063 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-m60-oafO4P for ; Mon, 10 May 2010 20:52:38 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 1D96628C0F7 for ; Mon, 10 May 2010 20:52:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,204,1272808800"; d="scan'208";a="2355173" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 11 May 2010 13:52:26 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5978"; a="2091821" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcani.tcif.telstra.com.au with ESMTP; 11 May 2010 13:52:27 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Tue, 11 May 2010 13:52:26 +1000 From: "Manger, James H" To: David Recordon , Eran Hammer-Lahav Date: Tue, 11 May 2010 13:52:25 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcrwvGvGN2+3JanCTM+S+wS+9Pg0BgAADnEA Message-ID: <255B9BB34FB7D647A506DC292726F6E11263313BE9@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20@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 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 03:52:39 -0000 Q29ycmVjdC4gQWxsIHlvdXIgZXhhbXBsZXMgbWF0Y2ggbXkgaW50ZW50aW9uLCBEYXZpZC4NCg0K LS0gDQpKYW1lcyBNYW5nZXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog RGF2aWQgUmVjb3Jkb24gW21haWx0bzpyZWNvcmRvbmRAZ21haWwuY29tXSANClNlbnQ6IFR1ZXNk YXksIDExIE1heSAyMDEwIDE6NDYgUE0NClRvOiBFcmFuIEhhbW1lci1MYWhhdg0KQ2M6IE1hbmdl ciwgSmFtZXMgSDsgT0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEluZGljYXRpbmcg c2l0ZXMgd2hlcmUgYSB0b2tlbiBpcyB2YWxpZA0KDQpJZiB0aGUgc2l0ZXMgcGFyYW1ldGVyIGlz IG5vdCBzcGVjaWZpZWQsIHdvdWxkIGl0IGRlZmF1bHQgdG8gdGhlDQpkb21haW4gb2YgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyLiBJZiBpdCBpcyBzcGVjaWZpZWQsIHRoZW4gdGhlIHZhbGlkDQpz aXRlcyBhcmUgd2hhdCBpcyBleHBsaWNpdGx5IGxpc3RlZC4gV2lsZGNhcmRzIHdvdWxkIG9ubHkg YmUgc3VwcG9ydGVkDQpmb3Igc3ViZG9tYWlucyBhbmQgaXQgd291bGQgYmUgYXNzdW1lZCB0aGF0 IGFueSByZXNvdXJjZSBvbiB0aGF0DQpkb21haW4gaXMgdmFsaWQuDQoNClRodXMgd2l0aCB0aGUg dXNlciBlbmRwb2ludCBiZWluZyBodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9vYXV0aC9hdXRo b3JpemU6DQoNCjEpIG5vIHNpdGVzIHBhcmFtZXRlciBtZWFucyB0aGUgYWNjZXNzIHRva2VuIGlz IG9ubHkgdmFsaWQgb24NCmh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tLyoNCg0KMikgc2l0ZXMg a2V5IHdpdGggYSB2YWx1ZSBvZiBbImh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tLyJdIG1lYW5z DQp0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gaXMgb25seSB2YWxpZCBvbiBodHRwczovL2dyYXBoLmZh Y2Vib29rLmNvbS8qDQoNCjMpIHNpdGVzIGtleSB3aXRoIGEgdmFsdWUgb2YgWyJodHRwczovLyou ZmFjZWJvb2suY29tLyJdIG1lYW5zIHRoYXQNCmh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tLyog YW5kIGh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS8qIHdvdWxkIGJvdGgNCmJlIHZhbGlkIChhbW9u ZyBvdGhlciBzdWJkb21haW5zKQ0KDQo0KSBzaXRlcyBrZXkgd2l0aCBhIHZhbHVlIG9mIFsiaHR0 cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vIiwNCiJodHRwczovL2FwaS5mYWNlYm9vay5jb20vIl0g bWVhbnMgdGhhdCBvbmx5DQpodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS8qIGFuZCBodHRwczov L2FwaS5mYWNlYm9vay5jb20vKiB3b3VsZCBiZQ0KdmFsaWQNCg0KNSkgc2l0ZXMga2V5IHdpdGgg YSB2YWx1ZSBvZiBbImh0dHBzOi8vYXBpLmZhY2Vib29rLmNvbS8iXSBtZWFucyB0aGF0DQp0aGUg dGhlIHRva2VuIGlzbid0IHZhbGlkIG9uIGh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tLyBldmVu IHRob3VnaA0KdGhhdCdzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcg0KDQpPYnZpb3VzbHkgdGhl IHNpdGVzIHBhcmFtZXRlciBpc24ndCByZXN0cmljdGVkIHRvIGJlaW5nIG9uIHRoZSBzYW1lDQpk b21haW4sIGp1c3QgdXNlZCBpdCB0aGF0IHdheSBmb3IgdGhlc2UgZXhhbXBsZXMuIEFtIEkgdW5k ZXJzdGFuZGluZw0KdGhlIHByb3Bvc2FsIGNvcnJlY3RseT8NCg0KVGhhbmtzLA0KLS1EYXZpZA0K From recordond@gmail.com Mon May 10 21:06:17 2010 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 68A3F3A67B4 for ; Mon, 10 May 2010 21:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 6V20m2kyLvHo for ; Mon, 10 May 2010 21:06:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id A60B13A657C for ; Mon, 10 May 2010 21:06:15 -0700 (PDT) Received: by gwaa12 with SMTP id a12so2564612gwa.31 for ; Mon, 10 May 2010 21:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Ba4xxeQSHsMQd0GDRvjU+8sd+veWYvW2RmDTq5HJlgk=; b=N14D2JrtdhCtmk0vcW3rEQX+ExhiKuzTIFdxNJ0JasPWQCL1u0J/GYUjfTNHKTT5H2 yC6UsV+Pan/hPY2KwfuRsSkWMpY9NMxmRaQKzkBltPcBKa9/jkhgEr60/A5RLdGFGxNK 7GRq2094Qkd+gheeiO+Pb24JAQcGAKIm+woLM= 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=NNtSr2nh5YPnKvz0USsPQboVY/ye1Qhg8xnzwe3jcYn2GYl/mk3K2Zex0VcNMaJDxw 0rYK2YKYYmUnBHHdivvyAtdRaDz0YGAxhUIpCRagXI+oAXssBO39baPHFpawUrwE4kjQ TR60GukEwHQ35x3cQmGH8ZAbYa6KABaGEhFJQ= MIME-Version: 1.0 Received: by 10.231.152.78 with SMTP id f14mr3448453ibw.51.1273550761496; Mon, 10 May 2010 21:06:01 -0700 (PDT) Received: by 10.231.176.4 with HTTP; Mon, 10 May 2010 21:06:01 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263313BE9@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263313BE9@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 10 May 2010 21:06:01 -0700 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 04:06:17 -0000 Sweet, +1 then to adding this as an optional return parameter when receiving an access token. On Mon, May 10, 2010 at 8:52 PM, Manger, James H wrote: > Correct. All your examples match my intention, David. > > -- > James Manger > > > -----Original Message----- > From: David Recordon [mailto:recordond@gmail.com] > Sent: Tuesday, 11 May 2010 1:46 PM > To: Eran Hammer-Lahav > Cc: Manger, James H; OAuth WG > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > > If the sites parameter is not specified, would it default to the > domain of the authorization server. If it is specified, then the valid > sites are what is explicitly listed. Wildcards would only be supported > for subdomains and it would be assumed that any resource on that > domain is valid. > > Thus with the user endpoint being https://graph.facebook.com/oauth/authorize: > > 1) no sites parameter means the access token is only valid on > https://graph.facebook.com/* > > 2) sites key with a value of ["https://graph.facebook.com/"] means > that the access token is only valid on https://graph.facebook.com/* > > 3) sites key with a value of ["https://*.facebook.com/"] means that > https://graph.facebook.com/* and https://www.facebook.com/* would both > be valid (among other subdomains) > > 4) sites key with a value of ["https://graph.facebook.com/", > "https://api.facebook.com/"] means that only > https://graph.facebook.com/* and https://api.facebook.com/* would be > valid > > 5) sites key with a value of ["https://api.facebook.com/"] means that > the the token isn't valid on https://graph.facebook.com/ even though > that's the authorization server > > Obviously the sites parameter isn't restricted to being on the same > domain, just used it that way for these examples. Am I understanding > the proposal correctly? > > Thanks, > --David > From dick.hardt@gmail.com Mon May 10 22:28:03 2010 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 D2F9B3A6CB1 for ; Mon, 10 May 2010 22:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.685, 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 8Zx+ja6fsO0m for ; Mon, 10 May 2010 22:28:00 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id ED1A23A6CA2 for ; Mon, 10 May 2010 22:22:46 -0700 (PDT) Received: by pzk38 with SMTP id 38so2312783pzk.31 for ; Mon, 10 May 2010 22:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=vsHzLqGD7wpGFEIvFcS521do3QLwzpdUSEt7jGbPqos=; b=IyqCaPKYhC+TrqhK2rJgiy1a13ZM66dTZNW2aq8fwmerM8O2hsKiuiaVmH4iSQqhYx 4j5TSWNNBvXqjB2qMk78CHwjezt4XCCRrmR1PdZ5/ZFNfSABrgIgjYJSKmZ+IbNO7t5I RxP/V+MERaJbHC2nMz9mQZqYpNc/s4m95shPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fyGs5+U2CHD92Mk2C8xvRa4+BXgWPjjO6RdQg5GydNbEH42HLNzL0+Nj9SZEGlViVO aaK3c2qRW02W+JbW+qY6BUjqLTiUEA1vR4QpmFa8Q6qEPiEVIGzvkWZFP8DuPh3pqU/P aZhaKJNyh5uwF2OBbYCWOcx84+fHr3Q4lylQ4= Received: by 10.141.14.21 with SMTP id r21mr3431417rvi.144.1273555314420; Mon, 10 May 2010 22:21:54 -0700 (PDT) Received: from [192.168.1.102] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id o38sm2503959rvp.0.2010.05.10.22.21.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 May 2010 22:21:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 22:21:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] modifying the scope of an access 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, 11 May 2010 05:28:04 -0000 I don't know of use cases, but if we are going to have this as a = capability in the spec, then here is a suggested mechanism.=20 -- Dick On 2010-05-10, at 7:51 PM, Eran Hammer-Lahav wrote: > Are there actual use cases for this? Either way sounds like it belongs = in an extension. >=20 > EHL >=20 >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Monday, May 10, 2010 12:49 PM >> To: Eran Hammer-Lahav >> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] modifying the scope of an access token >>=20 >> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav >> wrote: >>> This would only work for the client credentials flow (because you = keep the >> same authorization source). For all other flows you are breaking the >> authorization boundaries. >>=20 >> If the requested scope is a subset of the original scope associated = with the >> refresh token then it should be acceptable, right? >>=20 >> This would allow a client to request a larger set of scopes, needed = for all API >> calls need for its function, but then get sub-scoped access tokens, = particular >> to each API. This will prevent an API from receiving a too powerful = access >> token. A compromised API could use access tokens to place calls = against >> other APIs, but not if it is narrowly scoped. >>=20 >> Marius >>=20 >>>=20 >>> What would be useful is to allow asking for more scope. For example, = when >> asking for a token (the last step of each flow), also include a valid = token to >> get a new token with the combined scope (new approval and previous). >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Dick Hardt >>>> Sent: Sunday, May 09, 2010 7:19 PM >>>> To: OAuth WG (oauth@ietf.org) >>>> Subject: [OAUTH-WG] modifying the scope of an access token >>>>=20 >>>> There has been some discussion about modifying the scope of the >>>> access token during a refresh. Perhaps we can add another "method" = to >>>> what the AS MAY support that allows modifying the scope of an = access >>>> token. Type of request is "modify" and the scope parameter is >>>> required to indicate the new scope required. Suggested copy below: >>>>=20 >>>> type >>>> REQUIRED. The parameter value MUST be set to modify >>>>=20 >>>> client_id >>>> REQUIRED. The client identifier as described in Section 3.4. >>>>=20 >>>> client_secret >>>> REQUIRED if the client was issued a secret. The client = secret. >>>>=20 >>>> refresh_token >>>> REQUIRED. The refresh token associated with the access token = to >>>> be refreshed. >>>>=20 >>>> scope >>>> REQUIRED. The new scope of the access request expressed as a >>>> list of space-delimited strings. The value of the scope parameter = is >>>> defined by the authorization server. If the value contains multiple >>>> space-delimited strings, their order does not matter, and each = string >>>> adds additional access range to the requested scope. >>>>=20 >>>> secret_type >>>> OPTIONAL. The access token secret type as described by = Section 8.3. >>>> If omitted, the authorization server will issue a bearer token (an >>>> access token without a matching secret) as described by Section = 8.2. >>>>=20 >>>> _______________________________________________ >>>> 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 >>>=20 From jpanzer@google.com Mon May 10 22:40:03 2010 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 650F63A69F8 for ; Mon, 10 May 2010 22:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.232 X-Spam-Level: X-Spam-Status: No, score=-101.232 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 MnQ-kZFQ1ApN for ; Mon, 10 May 2010 22:40:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 33B4E3A69A6 for ; Mon, 10 May 2010 22:40:01 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o4B5dmVo027971 for ; Mon, 10 May 2010 22:39:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273556389; bh=MQMLSQ1TvqXPm0BX1mPIlxZ17/8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=EwC3lt+Cj7Gx+x6Q/9y9FYFbX+QgyAgTJPDxb4FOujy6kmLcVMNl52VR1VJdx3F4U 9j19MM5Bl0rbD4Lx07bpA== 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=fLnv3sDqcG2gYlA3/PWoGmFPMFUmSr8VfOPx+w/lkGmo48N4s2SF5Tsze3lf3bWFI UwPQRXQXLeVIrFC+vqMBg== Received: from gyh20 (gyh20.prod.google.com [10.243.50.212]) by kpbe14.cbf.corp.google.com with ESMTP id o4B5dkJT008872 for ; Mon, 10 May 2010 22:39:47 -0700 Received: by gyh20 with SMTP id 20so2649574gyh.13 for ; Mon, 10 May 2010 22:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.219.1 with SMTP id r1mr2087048agg.118.1273556383969; Mon, 10 May 2010 22:39:43 -0700 (PDT) Received: by 10.91.211.18 with HTTP; Mon, 10 May 2010 22:39:43 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 22:39:43 -0700 Message-ID: From: John Panzer To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] modifying the scope of an access 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, 11 May 2010 05:40:03 -0000 Yes; a service that does a one time configuration step, requiring extensive access, followed by an ongoing lower level of access (say, read-only). Lowering access means it only needs to store low-risk tokens in its data store, limiting exposure (and liability). On Monday, May 10, 2010, Eran Hammer-Lahav wrote: > Are there actual use cases for this? Either way sounds like it belongs in= an extension. > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Monday, May 10, 2010 12:49 PM >> To: Eran Hammer-Lahav >> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] modifying the scope of an access token >> >> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav >> wrote: >> > This would only work for the client credentials flow (because you keep= the >> same authorization source). For all other flows you are breaking the >> authorization boundaries. >> >> If the requested scope is a subset of the original scope associated with= the >> refresh token then it should be acceptable, right? >> >> This would allow a client to request a larger set of scopes, needed for = all API >> calls need for its function, but then get sub-scoped access tokens, part= icular >> to each API. This will prevent an API from receiving a too powerful acce= ss >> token. A compromised API could use access tokens to place calls against >> other APIs, but not if it is narrowly scoped. >> >> Marius >> >> > >> > What would be useful is to allow asking for more scope. For example, w= hen >> asking for a token (the last step of each flow), also include a valid to= ken to >> get a new token with the combined scope (new approval and previous). >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Dick Hardt >> >> Sent: Sunday, May 09, 2010 7:19 PM >> >> To: OAuth WG (oauth@ietf.org) >> >> Subject: [OAUTH-WG] modifying the scope of an access token >> >> >> >> There has been some discussion about modifying the scope of the >> >> access token during a refresh. Perhaps we can add another "method" to >> >> what the AS MAY support that allows modifying the scope of an access >> >> token. Type of request is "modify" and the scope parameter is >> >> required to indicate the new scope required. Suggested copy below: >> >> >> >> type >> >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set to modify >> >> >> >> client_id >> >> =A0 =A0 =A0 REQUIRED. The client identifier as described in Section 3= .4. >> >> >> >> client_secret >> >> =A0 =A0 =A0 REQUIRED if the client was issued a secret. The client se= cret. >> >> >> >> refresh_token >> >> =A0 =A0 =A0 REQUIRED. The refresh token associated with the access to= ken to >> >> be refreshed. >> >> >> >> scope >> >> =A0 =A0 =A0 REQUIRED. The new scope of the access request expressed a= s a >> >> list of space-delimited strings. The value of the scope parameter is >> >> defined by the authorization server. If the value contains multiple >> >> space-delimited strings, their order does not matter, and each string >> >> adds additional access range to the requested scope. >> >> >> >> secret_type >> >> =A0 =A0 =A0 OPTIONAL. The access token secret type as described by Se= ction 8.3. >> >> If omitted, the authorization server will issue a bearer token (an >> >> access token without a matching secret) as described by Section 8.2. >> >> >> >> _______________________________________________ >> >> 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 >> > > _______________ --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From recordond@gmail.com Mon May 10 22:43:33 2010 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 6BD663A6ADF for ; Mon, 10 May 2010 22:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 es-FxDN4mN-j for ; Mon, 10 May 2010 22:43:31 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id D65DF3A69F8 for ; Mon, 10 May 2010 22:43:30 -0700 (PDT) Received: by yxe9 with SMTP id 9so2861029yxe.29 for ; Mon, 10 May 2010 22:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zaIlNn4sC0V8x6YWKNP7tAcoeyxa3Pmc7hDxe6LHFi8=; b=gHY5brh+3WpYnKN5xnx0sIml1lbkOQg2H1fEgpiMUrxq4rAiT/1VL/FAbNr2lWaIqY qOGqUxSd+isTjwVPfmJBurpqDa4IKn0xHPvS+qv4wTpiZIRSl0LlCtlAEG8KCUxngVwU u/7zJIavW0Xnpg2nhSYboCQFbi+6E+5ITT5m4= 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=gryXBoeN1Wit+16PmgidgMlPv8nDyrOuxtnquf2Kg1GeSNPZKe1+Ib9seJPQQuJT2x mL2b/ogMa6aBcvoMXrL7ADLnS3di3/6kdvTP4F8t7UJglkhMNvPOGwPiR3JwxiB5zydK 7MiW6DMcI+0JyUECreugqlE39dkuDlIprYOXE= MIME-Version: 1.0 Received: by 10.231.171.204 with SMTP id i12mr3624395ibz.45.1273556597093; Mon, 10 May 2010 22:43:17 -0700 (PDT) Received: by 10.231.176.4 with HTTP; Mon, 10 May 2010 22:43:17 -0700 (PDT) In-Reply-To: References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 May 2010 22:43:17 -0700 Message-ID: From: David Recordon To: John Panzer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] modifying the scope of an access 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, 11 May 2010 05:43:33 -0000 I'm wondering if this could be achieved by adding an optional scope parameter to the existing refresh request versus creating a new request type. Both because Dick's proposed text requires a refresh token and it seems like services worried about this sort of risk would not want to issue long lived access tokens. --David On Mon, May 10, 2010 at 10:39 PM, John Panzer wrote: > Yes; a service that does a one time configuration step, requiring > extensive access, followed by an ongoing lower level of access (say, > read-only). =A0Lowering access means it only needs to store low-risk > tokens in its data store, limiting exposure (and liability). > > On Monday, May 10, 2010, Eran Hammer-Lahav wrote: >> Are there actual use cases for this? Either way sounds like it belongs i= n an extension. >> >> EHL >> >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>> Sent: Monday, May 10, 2010 12:49 PM >>> To: Eran Hammer-Lahav >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token >>> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav >>> wrote: >>> > This would only work for the client credentials flow (because you kee= p the >>> same authorization source). For all other flows you are breaking the >>> authorization boundaries. >>> >>> If the requested scope is a subset of the original scope associated wit= h the >>> refresh token then it should be acceptable, right? >>> >>> This would allow a client to request a larger set of scopes, needed for= all API >>> calls need for its function, but then get sub-scoped access tokens, par= ticular >>> to each API. This will prevent an API from receiving a too powerful acc= ess >>> token. A compromised API could use access tokens to place calls against >>> other APIs, but not if it is narrowly scoped. >>> >>> Marius >>> >>> > >>> > What would be useful is to allow asking for more scope. For example, = when >>> asking for a token (the last step of each flow), also include a valid t= oken to >>> get a new token with the combined scope (new approval and previous). >>> > >>> > EHL >>> > >>> >> -----Original Message----- >>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>> >> Behalf Of Dick Hardt >>> >> Sent: Sunday, May 09, 2010 7:19 PM >>> >> To: OAuth WG (oauth@ietf.org) >>> >> Subject: [OAUTH-WG] modifying the scope of an access token >>> >> >>> >> There has been some discussion about modifying the scope of the >>> >> access token during a refresh. Perhaps we can add another "method" t= o >>> >> what the AS MAY support that allows modifying the scope of an access >>> >> token. Type of request is "modify" and the scope parameter is >>> >> required to indicate the new scope required. Suggested copy below: >>> >> >>> >> type >>> >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set to modify >>> >> >>> >> client_id >>> >> =A0 =A0 =A0 REQUIRED. The client identifier as described in Section = 3.4. >>> >> >>> >> client_secret >>> >> =A0 =A0 =A0 REQUIRED if the client was issued a secret. The client s= ecret. >>> >> >>> >> refresh_token >>> >> =A0 =A0 =A0 REQUIRED. The refresh token associated with the access t= oken to >>> >> be refreshed. >>> >> >>> >> scope >>> >> =A0 =A0 =A0 REQUIRED. The new scope of the access request expressed = as a >>> >> list of space-delimited strings. The value of the scope parameter is >>> >> defined by the authorization server. If the value contains multiple >>> >> space-delimited strings, their order does not matter, and each strin= g >>> >> adds additional access range to the requested scope. >>> >> >>> >> secret_type >>> >> =A0 =A0 =A0 OPTIONAL. The access token secret type as described by S= ection 8.3. >>> >> If omitted, the authorization server will issue a bearer token (an >>> >> access token without a matching secret) as described by Section 8.2. >>> >> >>> >> _______________________________________________ >>> >> 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 >>> > >> _______________ > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Mon May 10 22:47:15 2010 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 A03703A69F8 for ; Mon, 10 May 2010 22:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_05=-1.11, HELO_EQ_DE=0.35] 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 jco5kp6Y1lJj for ; Mon, 10 May 2010 22:47:12 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id AAD3F3A6ADF for ; Mon, 10 May 2010 22:47:10 -0700 (PDT) Received: from p4fff1096.dip.t-dialin.net ([79.255.16.150] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OBiJ0-0004Ht-7n; Tue, 11 May 2010 07:46:58 +0200 Message-ID: <4BE8EF51.1070305@lodderstedt.net> Date: Tue, 11 May 2010 07:46:57 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yaron Goland References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 05:47:15 -0000 Am 11.05.2010 01:43, schrieb Yaron Goland: > >> --- >> >> 2. Client Authentication (in flows) >> >> How should the client authenticate when making token requests? The >> current draft defines special request parameters for sending client >> credentials. Some have argued that this is not the correct way, and that the >> client should be using existing HTTP authentication schemes to accomplish >> that such as Basic. >> >> A. Client authenticates by sending its credentials using special parameters >> (current draft) B. Client authenticated by using HTTP Basic (or other schemes >> supported by the server such as Digest) >> >> > [Yaron Goland] A is needed at a minimum because there are physical limitations to how many bytes can go into an authorization header. > As far as I know, 4KB is the minimum size for headers that must be supported by user agents, which should suffice from my point of view. Moreover, other HTTP authentication mechanisms need much more than 4KB, For example, SPNEGO authentication headers can be up to 12392 bytes. regards, Torsten. >> _______________________________________________ >> 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 jpanzer@google.com Mon May 10 23:52:55 2010 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 137DA3A6AFB for ; Mon, 10 May 2010 23:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.145 X-Spam-Level: X-Spam-Status: No, score=-105.145 tagged_above=-999 required=5 tests=[AWL=0.830, 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 n6nSbrxBThGR for ; Mon, 10 May 2010 23:52:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CDF523A6AF9 for ; Mon, 10 May 2010 23:52:51 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o4B6qbCp026991 for ; Mon, 10 May 2010 23:52:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273560758; bh=BPSPwqtp7jCPAljSHSwMpvhR5P8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=lN53YSkfEY5lwqbrVR2kAuniTA/ipLdYGEdkSWsH9by/mXCoX6givJUoJSkReQgdj yB/153dukAXqChkF8L3vA== 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=nckiyb1Sxi60LX0EKhWN3kUUt4I42zTmydGqe91LkKOEVUwriXMfVBWQYi6l7qFCN Z4GKuNiyrFU9IgVAxEqEQ== Received: from gwaa18 (gwaa18.prod.google.com [10.200.27.18]) by wpaz17.hot.corp.google.com with ESMTP id o4B6qaxP003137 for ; Mon, 10 May 2010 23:52:37 -0700 Received: by gwaa18 with SMTP id a18so2363259gwa.9 for ; Mon, 10 May 2010 23:52:36 -0700 (PDT) Received: by 10.91.95.15 with SMTP id x15mr2568668agl.104.1273560756478; Mon, 10 May 2010 23:52:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.211.18 with HTTP; Mon, 10 May 2010 23:52:16 -0700 (PDT) In-Reply-To: References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 10 May 2010 23:52:16 -0700 Message-ID: To: David Recordon Content-Type: multipart/alternative; boundary=0016e64f84587d62ef04864bf8cd X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] modifying the scope of an access 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, 11 May 2010 06:52:55 -0000 --0016e64f84587d62ef04864bf8cd Content-Type: text/plain; charset=ISO-8859-1 (Note that in my use case, it's actually the client who wants to dispose of its dangerous full-access token as quickly as possible, retaining only the least-authority token it needs to continue its ongoing work. This would be the case even if the token granting service is handing out tokens like free candy.) On Mon, May 10, 2010 at 10:43 PM, David Recordon wrote: > I'm wondering if this could be achieved by adding an optional scope > parameter to the existing refresh request versus creating a new > request type. Both because Dick's proposed text requires a refresh > token and it seems like services worried about this sort of risk would > not want to issue long lived access tokens. > > --David > > > On Mon, May 10, 2010 at 10:39 PM, John Panzer wrote: > > Yes; a service that does a one time configuration step, requiring > > extensive access, followed by an ongoing lower level of access (say, > > read-only). Lowering access means it only needs to store low-risk > > tokens in its data store, limiting exposure (and liability). > > > > On Monday, May 10, 2010, Eran Hammer-Lahav wrote: > >> Are there actual use cases for this? Either way sounds like it belongs > in an extension. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>> Sent: Monday, May 10, 2010 12:49 PM > >>> To: Eran Hammer-Lahav > >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token > >>> > >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav > >>> wrote: > >>> > This would only work for the client credentials flow (because you > keep the > >>> same authorization source). For all other flows you are breaking the > >>> authorization boundaries. > >>> > >>> If the requested scope is a subset of the original scope associated > with the > >>> refresh token then it should be acceptable, right? > >>> > >>> This would allow a client to request a larger set of scopes, needed for > all API > >>> calls need for its function, but then get sub-scoped access tokens, > particular > >>> to each API. This will prevent an API from receiving a too powerful > access > >>> token. A compromised API could use access tokens to place calls against > >>> other APIs, but not if it is narrowly scoped. > >>> > >>> Marius > >>> > >>> > > >>> > What would be useful is to allow asking for more scope. For example, > when > >>> asking for a token (the last step of each flow), also include a valid > token to > >>> get a new token with the combined scope (new approval and previous). > >>> > > >>> > EHL > >>> > > >>> >> -----Original Message----- > >>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>> >> Behalf Of Dick Hardt > >>> >> Sent: Sunday, May 09, 2010 7:19 PM > >>> >> To: OAuth WG (oauth@ietf.org) > >>> >> Subject: [OAUTH-WG] modifying the scope of an access token > >>> >> > >>> >> There has been some discussion about modifying the scope of the > >>> >> access token during a refresh. Perhaps we can add another "method" > to > >>> >> what the AS MAY support that allows modifying the scope of an access > >>> >> token. Type of request is "modify" and the scope parameter is > >>> >> required to indicate the new scope required. Suggested copy below: > >>> >> > >>> >> type > >>> >> REQUIRED. The parameter value MUST be set to modify > >>> >> > >>> >> client_id > >>> >> REQUIRED. The client identifier as described in Section 3.4. > >>> >> > >>> >> client_secret > >>> >> REQUIRED if the client was issued a secret. The client secret. > >>> >> > >>> >> refresh_token > >>> >> REQUIRED. The refresh token associated with the access token > to > >>> >> be refreshed. > >>> >> > >>> >> scope > >>> >> REQUIRED. The new scope of the access request expressed as a > >>> >> list of space-delimited strings. The value of the scope parameter is > >>> >> defined by the authorization server. If the value contains multiple > >>> >> space-delimited strings, their order does not matter, and each > string > >>> >> adds additional access range to the requested scope. > >>> >> > >>> >> secret_type > >>> >> OPTIONAL. The access token secret type as described by Section > 8.3. > >>> >> If omitted, the authorization server will issue a bearer token (an > >>> >> access token without a matching secret) as described by Section 8.2. > >>> >> > >>> >> _______________________________________________ > >>> >> 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 > >>> > > >> _______________ > > > > -- > > -- > > John Panzer / Google > > jpanzer@google.com / abstractioneer.org / @jpanzer > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > --0016e64f84587d62ef04864bf8cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (Note that in my use case, it's actually the client who wants to dispos= e of its dangerous full-access token as quickly as possible, retaining only= the least-authority token it needs to continue its ongoing work. =A0This w= ould be the case even if the token granting service is handing out tokens l= ike free candy.)

On Mon, May 10, 2010 at 10:43 PM, David Reco= rdon <recordond= @gmail.com> wrote:
I'm wondering if this could be achieved by adding an optional scope
parameter to the existing refresh request versus creating a new
request type. Both because Dick's proposed text requires a refresh
token and it seems like services worried about this sort of risk would
not want to issue long lived access tokens.

--David


On Mon, May 10, 2010 at 10:39 PM, John Panzer <jpanzer@google.com> wrote:
> Yes; a service that does a one time configuration step, requiring
> extensive access, followed by an ongoing lower level of access (say, > read-only). =A0Lowering access means it only needs to store low-risk > tokens in its data store, limiting exposure (and liability).
>
> On Monday, May 10, 2010, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> Are there actual use cases for this? Either way sounds like it bel= ongs in an extension.
>>
>> EHL
>>
>>> -----Original Message-----
>>> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>>> Sent: Monday, May 10, 2010 12:49 PM
>>> To: Eran Hammer-Lahav
>>> Cc: Dick Hardt; OAuth WG (oa= uth@ietf.org)
>>> Subject: Re: [OAUTH-WG] modifying the scope of an access token=
>>>
>>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav
>>> <eran@hueniverse.com= > wrote:
>>> > This would only work for the client credentials flow (bec= ause you keep the
>>> same authorization source). For all other flows you are breaki= ng the
>>> authorization boundaries.
>>>
>>> If the requested scope is a subset of the original scope assoc= iated with the
>>> refresh token then it should be acceptable, right?
>>>
>>> This would allow a client to request a larger set of scopes, n= eeded for all API
>>> calls need for its function, but then get sub-scoped access to= kens, particular
>>> to each API. This will prevent an API from receiving a too pow= erful access
>>> token. A compromised API could use access tokens to place call= s against
>>> other APIs, but not if it is narrowly scoped.
>>>
>>> Marius
>>>
>>> >
>>> > What would be useful is to allow asking for more scope. F= or example, when
>>> asking for a token (the last step of each flow), also include = a valid token to
>>> get a new token with the combined scope (new approval and prev= ious).
>>> >
>>> > EHL
>>> >
>>> >> -----Original Message-----
>>> >> From: oauth= -bounces@ietf.org [mailto:oau= th-bounces@ietf.org] On
>>> >> Behalf Of Dick Hardt
>>> >> Sent: Sunday, May 09, 2010 7:19 PM
>>> >> To: OAuth WG (oauth= @ietf.org)
>>> >> Subject: [OAUTH-WG] modifying the scope of an access = token
>>> >>
>>> >> There has been some discussion about modifying the sc= ope of the
>>> >> access token during a refresh. Perhaps we can add ano= ther "method" to
>>> >> what the AS MAY support that allows modifying the sco= pe of an access
>>> >> token. Type of request is "modify" and the = scope parameter is
>>> >> required to indicate the new scope required. Suggeste= d copy below:
>>> >>
>>> >> type
>>> >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set= to modify
>>> >>
>>> >> client_id
>>> >> =A0 =A0 =A0 REQUIRED. The client identifier as descri= bed in Section 3.4.
>>> >>
>>> >> client_secret
>>> >> =A0 =A0 =A0 REQUIRED if the client was issued a secre= t. The client secret.
>>> >>
>>> >> refresh_token
>>> >> =A0 =A0 =A0 REQUIRED. The refresh token associated wi= th the access token to
>>> >> be refreshed.
>>> >>
>>> >> scope
>>> >> =A0 =A0 =A0 REQUIRED. The new scope of the access req= uest expressed as a
>>> >> list of space-delimited strings. The value of the sco= pe parameter is
>>> >> defined by the authorization server. If the value con= tains multiple
>>> >> space-delimited strings, their order does not matter,= and each string
>>> >> adds additional access range to the requested scope.<= br> >>> >>
>>> >> secret_type
>>> >> =A0 =A0 =A0 OPTIONAL. The access token secret type as= described by Section 8.3.
>>> >> If omitted, the authorization server will issue a bea= rer token (an
>>> >> access token without a matching secret) as described = by Section 8.2.
>>> >>
>>> >> _______________________________________________
>>> >> OAuth mailing list
>>> >> OAuth@ietf.org<= br> >>> >> https://www.ietf.org/mailman/listinfo/oauth
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>> >
>> _______________
>
> --
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @= jpanzer
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0016e64f84587d62ef04864bf8cd-- From recordond@gmail.com Tue May 11 00:01:46 2010 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 B4DED3A6AED for ; Tue, 11 May 2010 00:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 vroXU1PwKNWI for ; Tue, 11 May 2010 00:01:45 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 34F4A3A69A6 for ; Tue, 11 May 2010 00:01:43 -0700 (PDT) Received: by ywh3 with SMTP id 3so1581078ywh.31 for ; Tue, 11 May 2010 00:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7GWqOWWbyNth32w6+VNPYtL/EtGKE9d/EyJQ9vNYj8w=; b=qsduHJu3NI0J1Wt3sVheLTM9UABbjzBvlaGAaSzApN9/apEKArnuxs4EEpt8a2OLk2 Qrm1mNUP244w+5Upbu4O/fzqmQYjSJX4C7bx7cRf1IjW9zqETUiDhXHBpJcW40eugyZO +IsV85wAGyrehgFXkkw7g8EGaJ/4k0fR92a4U= 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=HoO1l5jay2S1Ld73s80Yj6mVgxUKMVYj9tCd5uo/hbe0Z/3hM42l1FVaHYSzPSGUKs 42AqMobBX0rPG3v7sug+yf6/L3WjzeMLo3MaYZFefEQHIoU31hI3+oxNmHbqKVc0D2tl dEDHdQH52ONkiMN7/a6VZUzt/on19UmQsPcs4= MIME-Version: 1.0 Received: by 10.231.168.85 with SMTP id t21mr3772244iby.0.1273561289647; Tue, 11 May 2010 00:01:29 -0700 (PDT) Received: by 10.231.176.4 with HTTP; Tue, 11 May 2010 00:01:29 -0700 (PDT) In-Reply-To: References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 May 2010 00:01:29 -0700 Message-ID: From: David Recordon To: John Panzer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] modifying the scope of an access 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, 11 May 2010 07:01:46 -0000 Yes. In the case of an authorization server handing out tokens like free candy, it's unlikely that it would implement the ability to restrict scope on a token it already issued. Thus my argument is that it seems like this method would be implemented by authorization servers who make use of refresh tokens. On Mon, May 10, 2010 at 11:52 PM, John Panzer wrote: > (Note that in my use case, it's actually the client who wants to dispose = of > its dangerous full-access token as quickly as possible, retaining only th= e > least-authority token it needs to continue its ongoing work. =A0This woul= d be > the case even if the token granting service is handing out tokens like fr= ee > candy.) > On Mon, May 10, 2010 at 10:43 PM, David Recordon > wrote: >> >> I'm wondering if this could be achieved by adding an optional scope >> parameter to the existing refresh request versus creating a new >> request type. Both because Dick's proposed text requires a refresh >> token and it seems like services worried about this sort of risk would >> not want to issue long lived access tokens. >> >> --David >> >> >> On Mon, May 10, 2010 at 10:39 PM, John Panzer wrote= : >> > Yes; a service that does a one time configuration step, requiring >> > extensive access, followed by an ongoing lower level of access (say, >> > read-only). =A0Lowering access means it only needs to store low-risk >> > tokens in its data store, limiting exposure (and liability). >> > >> > On Monday, May 10, 2010, Eran Hammer-Lahav wrote= : >> >> Are there actual use cases for this? Either way sounds like it belong= s >> >> in an extension. >> >> >> >> EHL >> >> >> >>> -----Original Message----- >> >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> >>> Sent: Monday, May 10, 2010 12:49 PM >> >>> To: Eran Hammer-Lahav >> >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) >> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token >> >>> >> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav >> >>> wrote: >> >>> > This would only work for the client credentials flow (because you >> >>> > keep the >> >>> same authorization source). For all other flows you are breaking the >> >>> authorization boundaries. >> >>> >> >>> If the requested scope is a subset of the original scope associated >> >>> with the >> >>> refresh token then it should be acceptable, right? >> >>> >> >>> This would allow a client to request a larger set of scopes, needed >> >>> for all API >> >>> calls need for its function, but then get sub-scoped access tokens, >> >>> particular >> >>> to each API. This will prevent an API from receiving a too powerful >> >>> access >> >>> token. A compromised API could use access tokens to place calls >> >>> against >> >>> other APIs, but not if it is narrowly scoped. >> >>> >> >>> Marius >> >>> >> >>> > >> >>> > What would be useful is to allow asking for more scope. For exampl= e, >> >>> > when >> >>> asking for a token (the last step of each flow), also include a vali= d >> >>> token to >> >>> get a new token with the combined scope (new approval and previous). >> >>> > >> >>> > EHL >> >>> > >> >>> >> -----Original Message----- >> >>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >>> >> Behalf Of Dick Hardt >> >>> >> Sent: Sunday, May 09, 2010 7:19 PM >> >>> >> To: OAuth WG (oauth@ietf.org) >> >>> >> Subject: [OAUTH-WG] modifying the scope of an access token >> >>> >> >> >>> >> There has been some discussion about modifying the scope of the >> >>> >> access token during a refresh. Perhaps we can add another "method= " >> >>> >> to >> >>> >> what the AS MAY support that allows modifying the scope of an >> >>> >> access >> >>> >> token. Type of request is "modify" and the scope parameter is >> >>> >> required to indicate the new scope required. Suggested copy below= : >> >>> >> >> >>> >> type >> >>> >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set to modify >> >>> >> >> >>> >> client_id >> >>> >> =A0 =A0 =A0 REQUIRED. The client identifier as described in Secti= on 3.4. >> >>> >> >> >>> >> client_secret >> >>> >> =A0 =A0 =A0 REQUIRED if the client was issued a secret. The clien= t >> >>> >> secret. >> >>> >> >> >>> >> refresh_token >> >>> >> =A0 =A0 =A0 REQUIRED. The refresh token associated with the acces= s token >> >>> >> to >> >>> >> be refreshed. >> >>> >> >> >>> >> scope >> >>> >> =A0 =A0 =A0 REQUIRED. The new scope of the access request express= ed as a >> >>> >> list of space-delimited strings. The value of the scope parameter >> >>> >> is >> >>> >> defined by the authorization server. If the value contains multip= le >> >>> >> space-delimited strings, their order does not matter, and each >> >>> >> string >> >>> >> adds additional access range to the requested scope. >> >>> >> >> >>> >> secret_type >> >>> >> =A0 =A0 =A0 OPTIONAL. The access token secret type as described b= y >> >>> >> Section 8.3. >> >>> >> If omitted, the authorization server will issue a bearer token (a= n >> >>> >> access token without a matching secret) as described by Section >> >>> >> 8.2. >> >>> >> >> >>> >> _______________________________________________ >> >>> >> 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 >> >>> > >> >> _______________ >> > >> > -- >> > -- >> > John Panzer / Google >> > jpanzer@google.com / abstractioneer.org / @jpanzer >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > > > From eran@hueniverse.com Tue May 11 00:21:57 2010 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 6A90C3A6B0A for ; Tue, 11 May 2010 00:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 GsQqSS1wXbxH for ; Tue, 11 May 2010 00:21: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 647DE3A6B07 for ; Tue, 11 May 2010 00:21:20 -0700 (PDT) Received: (qmail 8916 invoked from network); 11 May 2010 07:21:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 May 2010 07:21:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 11 May 2010 00:21:03 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Tue, 11 May 2010 00:21:07 -0700 Thread-Topic: [OAUTH-WG] modifying the scope of an access token Thread-Index: AcrwzF9EF8pg1MTRShesAAW6zmEv5QADhnVg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47172@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] modifying the scope of an access 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, 11 May 2010 07:21:57 -0000 Are you actually (planning on) writing something like this? EHL > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Monday, May 10, 2010 10:40 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] modifying the scope of an access token >=20 > Yes; a service that does a one time configuration step, requiring extensi= ve > access, followed by an ongoing lower level of access (say, read-only). > Lowering access means it only needs to store low-risk tokens in its data = store, > limiting exposure (and liability). >=20 > On Monday, May 10, 2010, Eran Hammer-Lahav > wrote: > > Are there actual use cases for this? Either way sounds like it belongs = in an > extension. > > > > EHL > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Monday, May 10, 2010 12:49 PM > >> To: Eran Hammer-Lahav > >> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] modifying the scope of an access token > >> > >> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav > >> wrote: > >> > This would only work for the client credentials flow (because you > >> > keep the > >> same authorization source). For all other flows you are breaking the > >> authorization boundaries. > >> > >> If the requested scope is a subset of the original scope associated > >> with the refresh token then it should be acceptable, right? > >> > >> This would allow a client to request a larger set of scopes, needed > >> for all API calls need for its function, but then get sub-scoped > >> access tokens, particular to each API. This will prevent an API from > >> receiving a too powerful access token. A compromised API could use > >> access tokens to place calls against other APIs, but not if it is narr= owly > scoped. > >> > >> Marius > >> > >> > > >> > What would be useful is to allow asking for more scope. For > >> > example, when > >> asking for a token (the last step of each flow), also include a valid > >> token to get a new token with the combined scope (new approval and > previous). > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> >> Behalf Of Dick Hardt > >> >> Sent: Sunday, May 09, 2010 7:19 PM > >> >> To: OAuth WG (oauth@ietf.org) > >> >> Subject: [OAUTH-WG] modifying the scope of an access token > >> >> > >> >> There has been some discussion about modifying the scope of the > >> >> access token during a refresh. Perhaps we can add another "method" > >> >> to what the AS MAY support that allows modifying the scope of an > >> >> access token. Type of request is "modify" and the scope parameter > >> >> is required to indicate the new scope required. Suggested copy belo= w: > >> >> > >> >> type > >> >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set to modify > >> >> > >> >> client_id > >> >> =A0 =A0 =A0 REQUIRED. The client identifier as described in Section= 3.4. > >> >> > >> >> client_secret > >> >> =A0 =A0 =A0 REQUIRED if the client was issued a secret. The client = secret. > >> >> > >> >> refresh_token > >> >> =A0 =A0 =A0 REQUIRED. The refresh token associated with the access = token > >> >> to be refreshed. > >> >> > >> >> scope > >> >> =A0 =A0 =A0 REQUIRED. The new scope of the access request expressed= as a > >> >> list of space-delimited strings. The value of the scope parameter > >> >> is defined by the authorization server. If the value contains > >> >> multiple space-delimited strings, their order does not matter, and > >> >> each string adds additional access range to the requested scope. > >> >> > >> >> secret_type > >> >> =A0 =A0 =A0 OPTIONAL. The access token secret type as described by = Section > 8.3. > >> >> If omitted, the authorization server will issue a bearer token (an > >> >> access token without a matching secret) as described by Section 8.2= . > >> >> > >> >> _______________________________________________ > >> >> 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 > >> > > > _______________ >=20 > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer From pid@pidster.com Tue May 11 01:16:35 2010 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 668F228C11A for ; Tue, 11 May 2010 01:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, 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 5anEH4Tt2BjT for ; Tue, 11 May 2010 01:16:34 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7C09E3A6B47 for ; Tue, 11 May 2010 01:15:42 -0700 (PDT) Received: by wyb36 with SMTP id 36so586676wyb.31 for ; Tue, 11 May 2010 01:15:24 -0700 (PDT) Received: by 10.227.154.4 with SMTP id m4mr4996027wbw.153.1273565724642; Tue, 11 May 2010 01:15:24 -0700 (PDT) Received: from Phoenix.local (cpc2-lewi13-2-0-cust269.2-4.cable.virginmedia.com [86.14.119.14]) by mx.google.com with ESMTPS id u8sm47313934wbc.17.2010.05.11.01.15.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 May 2010 01:15:23 -0700 (PDT) Message-ID: <4BE91213.7090302@pidster.com> Date: Tue, 11 May 2010 09:15:15 +0100 From: Pid Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Joseph Smarr References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE7BF9A.2050209@pidster.com> <1222443C-7C2C-49C4-B03A-4E760538B4BB@gmail.com> <4BE85186.1080401@pidster.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig962120F51C1AEAF9280F86C0" Cc: OAuth WG Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pid@pidster.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 08:16:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig962120F51C1AEAF9280F86C0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/05/2010 23:38, Joseph Smarr wrote: > Oh, one other quick benefit of JSON (kind of an extension of point 1 be= low): >=20 > - no ambiguous treatment of whitespace or newlines (this is a problem > I've observed multiple times while helping developers debug OAuth 1.0 > implementations--since they just split on & and =3D, they often don't t= rim > extra whitespace or newlines that were returned by the server, leading > to those spaces/newlines being part of the parsed attribute values, > which then cause broken signatures and are very hard to debug, since th= e > chars are invisible when printed). Not a problem with JSON. >=20 > Let me try to offer some of those "logical, positive statements in > favour of the technical merits of JSON over the original format > choice" for those that aren't familiar or haven't gleaned them from= > the thread thus far: >=20 > - unambiguous spec for encoding/decoding (including how to represen= t > spaces and unicode chars, both of which are common points of > ambiguity in url-encoding that lead to bugs, confusion, and lack of= > ability to use built-in libraries, if available). For example, the > OAuth PHP library does the following: return str_replace('+', ' ', > str_replace('%7E', '~', rawurlencode($input)) -- yuck! > > - easier to read the encoded format (because it has > clear sentinel braces, quoted attributes, and no url-encoding of > parameters; only some backslashing of reserved chars) >=20 > - widely available libraries with good track records in the wild, > and increasingly built in to many platforms >=20 > - extensible support for more representing more complex data > structures in the future, if needed >=20 > - simple enough that it's easy to understand, but just complex > enough that it's not too tempting to roll your own parser (which > leads empirically to better compliance due to use of common librari= es) >=20 > - more likely to be recognized and understood by developers, since > they've seen it elsewhere in API response formats Thanks for taking the trouble to respond in detail, the arguments in favour of JSON are now much clearer. > I think that about covers it. Again, it's an objective fact that > url-encoding has caused confusion and bugs in OAuth 1.0 > implementations, and it's also an objective fact that JSON has had = a > very high "just works" rate in the wild, to the point that it's the= > default API response format for many widely used APIs from large > providers targeting many platforms. So this is not a choice based o= n > "fashion", but based on trying to learn from history to increase > developer success and remove the opportunity for subtle bugs, which= > was one of the major problems with OAuth 1.0a that prompted us to > work on OAuth 2.0 in the first place. I take your point. I'm slightly less convinced that this means that JSON is a single best format, as much of the above could apply to XML too. (Though I am aware of the other JSON vs XML arguments, which favour JSON). My preference is for multiple formats, but I'll leave this topic alone no= w. cheers, p > Thanks, js >=20 > On Mon, May 10, 2010 at 11:33 AM, Pid > wrote: >=20 > On 10/05/2010 15:56, Dick Hardt wrote: > > > > On 2010-05-10, at 1:11 AM, Pid wrote: > > > >> On 10/05/2010 07:57, Joseph Smarr wrote: > >>>> 1. Server Response Format > >>> > >>> I vote for B, though I could live with C. (A would make me > sad though) > >>> > >>> We've had a healthy and reasonable debate about the > trade-offs here, but > >>> I think the main counterargument for requiring JSON support= > is that it's > >>> not quite yet a "no-brainer" to have JSON support in all > environments > >>> (e.g. iPhone libraries currently would need to statically > link in an > >>> available JSON library), whereas the counterarguments for A= > are the > >>> well-documented problems properly decoding url-encoded > params from OAuth > >>> 1.0, plus the fact that it's not a common response format, > whereas JSON > >>> (and XML) are. Since I think JSON will continue to increase= > in use for > >>> at least the next several years, the pain associated with > requiring JSON > >>> is likely to be higher now than it will be in the future, > and it's > >>> already low enough that we've had this debate about whether= > it's already > >>> acceptable or not-quite-yet. And JSON has been proven to > "just work" in > >>> terms of avoiding encoding/decoding headaches in the wild, > which for > >>> something like OAuth is really critical. > >> > >> I don't believe this is an accurate summary. > > > > Are you saying the information is not accurate or not a > complete summary? > > > >> > >> I asked for someone in the pro-JSON camp to describe the > technical > >> merits of that format over url encoded, but to date, there's= > no one who > >> has responded. > > > > per > http://www.ietf.org/mail-archive/web/oauth/current/msg01992.htm= l >=20 > Is that the right message? There's not much in the way of posi= tive > arguments for JSON in that one. >=20 >=20 > > client libraries exist to parse JSON responses >=20 > Meaning a dependency. >=20 >=20 > > client libraries do NOT exist to parse url encoded responses >=20 > There aren't libraries to perform that type of decoding because= it's > trivial, (as you acknowledged). >=20 >=20 > > Implementations of both OAuth 1.0 and WRAP improperly decoded= > the responses. > > Also with reference to: "many developers have been caught jus= t > splitting the parameters and forgetting to URL decode the token= " >=20 > With respect, I think this is pretty close to a straw man. It > would be > just as easy to argue that developers will make a mess of > parsing JSON. >=20 >=20 >=20 > Everyone seems to have, (in some cases grudgingly), agreed that= it's > easier to decode/parse urlencoded data than JSON. >=20 > There are definitely occasions when using JSON for data > description & > transmission is advantageous, I just don't think this is one of= > them. > It's a proverbial sledgehammer for a tiny OAuth nut. >=20 >=20 > There should be something positive to say about JSON that > establishes > why it is a better format for this purpose. >=20 >=20 > >> The options we've been offered seem contrived to support JSO= N, > > > > would you elaborate on why you think the options presented by= > the editor were contrived? >=20 > Sure. Two of them offer JSON as the default, including the put= ative > 'compromise' option. >=20 > JSON and XML add complexity, as the editor states. IMHO it's o= dd > therefore not to select the least complex as the default, if > multiple > formats are offered. >=20 >=20 >=20 > I appreciate that JSON is popular and there is a degree of devi= l's > advocacy to my position here, (as I've already said), but if > it's not > possible to make a list of logical, positive statements in > favour of the > technical merits of JSON over the original format choice then i= t > shouldn't be selected as the default. >=20 >=20 > p >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 --------------enig962120F51C1AEAF9280F86C0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQIVAwUBS+kSGWoM2OGpOvr9AQoQSQ//cL7d2xu9Yh5ccnxqhGLOf7PMG52EkI9t 2fVCMb4VeC7HyyKXXDdv918RQU82FudwprhpQKzIjh+fXrCjQF67YpFyev4JCSzG CGGGjt1tUyLdadFUg2rUHN4DxYUCQXf57A6Z8tIKhu+di9N1NqMMyPkGu5mpNLEW KuzZ/hyDZfQg4bFGR1RMRJvdSBhJ8ZReibo2PzJmkfhTSSJMzYHkFjJQBnxnxnXJ B7MpbLXyntlQjC6qeD1f8K0wnmsWuiodzd3gGOU2Tkba1Hab7uPIU6aepyJw8RYw bvJd2Eu8iTatS6eMH2Mt8IBT5cotDZZx35nLEw8nuAqk7KW/RlL1ipdpahzRZJuF QA9QPj2i+qLBZOAT6tr+lQB2cOag971CLHFd6NdEfYUuQOeyJHIvg8oeNYaEJkhi PiQVaLtc33iWj1MmOIjhW8A6gSq20o6mOIvGT6mAMRQb5wHXYJxNeS5K0gKB4J8N s1ZxvHNP08opvJ6l+SgJhyLJLTeQBowbgRDAfkeDw01RLXkSfCNGuyYmUjCJtGO7 7PMbO7gGlspbDP516aOUUNoB0C13BG8/DNcclP8cJNwifZQZoK6XPVVm5x1OnvfD S3zMn9JhjpqVP1hkg+zXyfiiO8JEhmWkgMUSyjDLbznnB+Pq5bh7MAHNEzqo3RnG eSaDhVa/0Eo= =ja/Q -----END PGP SIGNATURE----- --------------enig962120F51C1AEAF9280F86C0-- From bart.bv.vrancken@alcatel-lucent.com Tue May 11 01:23:29 2010 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 5E96F3A6405 for ; Tue, 11 May 2010 01:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_EQ_FR=0.35] 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 wzDp7PeEq7jp for ; Tue, 11 May 2010 01:23:27 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id B47673A6B3A for ; Tue, 11 May 2010 01:20:49 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o4B8KRo3001830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 11 May 2010 10:20:35 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 11 May 2010 10:20:28 +0200 From: "Vrancken, Bart bv (Bart)" To: "OAuth WG (oauth@ietf.org)" Date: Tue, 11 May 2010 10:20:26 +0200 Thread-Topic: [OAUTH-WG] delegating access to another client Thread-Index: AcrwmA/hKjnx64nbTZuOhEyj4q07zAASXImA Message-ID: <7804DC3922510442A2F612A645323ED10A0C86A0@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.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 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [OAUTH-WG] delegating access to another client 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, 11 May 2010 08:23:29 -0000 Lifespan of this delegation token could be: - One time usage of token - Time or numbers of usage given to the AS when the delegation has been as= ked. If the access of the client is revoked, all the delegate tokens should be a= lso revoked. I have implemented a couple of scenarios for recursive delegation. If you u= se a minimal library for OAuth1 that handles only the signatures and the bu= ilding of the requests, nothing has to be changed to the original library. = You must only depending on your implementation have 2 or 3 extra endpoints = to handle the flow, or incorporate it with some extra parameters or logic i= n the original endpoints. For clarity, I used extra endpoints. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: dinsdag 11 mei 2010 1:20 To: Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] delegating access to another client On Sun, May 9, 2010 at 7:34 PM, Dick Hardt wrote: > There a couple of choices for the flows for how a successful delegation i= s conveyed to the delegate. The AS could return a delegation code that is s= imilar to a verification code and the delegate acquires an access token sim= ilar to 3.6.2 > Alternatively, the AS could return an delegation token that is used simil= ar to a refresh token to obtain an access token and refresh token. How about lifespan? When does the token expire? And can the client request a shorter expiration? Can the client request revocation of the delegate's token? What are the semantics around revocation? If a client has their access revoked, is the delegate access revoked as well? > Do people think this is worth adding to the spec? Maybe. > The main concern is how should the resource owner express their approval = for such arrangement? I don't think this is a fundamental problem. The client already has the authority they are delegating, and they could expose a proxy service to share that data with fourth-parties. Dick is describing a cleaner (and possibly more secure?) way to do that. It's up to clients and service providers to figure out user expectations and set appropriate policies on when data can be shared with fourth parties.. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From raffi@twitter.com Tue May 11 01:39:44 2010 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 634453A6B18 for ; Tue, 11 May 2010 01:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 C0LUaP4wXZ7e for ; Tue, 11 May 2010 01:39:43 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 3F8FB28C107 for ; Tue, 11 May 2010 01:39:14 -0700 (PDT) Received: by pxi19 with SMTP id 19so2356969pxi.31 for ; Tue, 11 May 2010 01:39:01 -0700 (PDT) Received: by 10.141.188.41 with SMTP id q41mr3449565rvp.203.1273567140839; Tue, 11 May 2010 01:39:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.144.9 with HTTP; Tue, 11 May 2010 01:38:40 -0700 (PDT) In-Reply-To: References: <92E1EDC3-1A6C-4E90-B274-AB839DC40FB8@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3B@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Raffi Krikorian Date: Tue, 11 May 2010 09:38:40 +0100 Message-ID: To: David Recordon Content-Type: multipart/alternative; boundary=000e0cd179240702c604864d7557 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] delegating access to another client 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, 11 May 2010 08:39:44 -0000 --000e0cd179240702c604864d7557 Content-Type: text/plain; charset=ISO-8859-1 although we are the ones who are pushing this into our ecosystem right now, i agree with david on this one -- i'm happy to take the lead in drafting this (i have some sketches of it working in the oauth 1.0a world for a one time use -- http://mehack.com/oauth-echo-delegation-in-identity-verificatio), but i think this should be an extension. On Tue, May 11, 2010 at 2:31 AM, David Recordon wrote: > I'm concerned about prematurely standardizing something which we don't > have deployment experience to guide. One of the things I like most > about OAuth 2.0 is that we're largely not inventing new things. Rather > learning from what others have done in the past. > > My view is that redelegation should first be drafted and deployed as > an extension. > > --David > > > On Sun, May 9, 2010 at 10:20 PM, Eran Hammer-Lahav > wrote: > > Re-delegation is something people asked for since we started talking > about OAuth. There is also a draft I-D about it. This is explicitly out of > scope for the core spec (but not something that should stop us from having a > discussion). > > > > The main concern is how should the resource owner express their approval > for such arrangement? > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >> Of Dick Hardt > >> Sent: Sunday, May 09, 2010 7:34 PM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: [OAUTH-WG] delegating access to another client > >> > >> Twitter has an interesting use case that may become common: one client > >> needs to delegate access to another client. Similar to the 'modify' > method > >> where the scope of the access token can be modified, the 'delegate' > method > >> allows a client to request delegation to another client (the delegate). > Here is > >> some proposed copy for the request: > >> > >> type > >> REQUIRED. The parameter value MUST be set to delegate > >> > >> client_id > >> REQUIRED. The client identifier as described in Section 3.4. > >> > >> client_secret > >> REQUIRED if the client was issued a secret. The client secret. > >> > >> refresh_token > >> REQUIRED. The refresh token associated with the client. > >> > >> delegate_id > >> REQUIRED. The client identifier of the delegate > >> > >> scope > >> OPTIONAL. The scope the client is requesting for the delegate. > >> > >> secret_type > >> OPTIONAL. The access token secret type as described by Section > 8.3. > >> If omitted, the authorization server will issue a bearer token (an > access token > >> without a matching secret) as described by Section 8.2. > >> > >> There a couple of choices for the flows for how a successful delegation > is > >> conveyed to the delegate. The AS could return a delegation code that is > >> similar to a verification code and the delegate acquires an access token > >> similar to 3.6.2 Alternatively, the AS could return an delegation token > that is > >> used similar to a refresh token to obtain an access token and refresh > token. > >> > >> Do people think this is worth adding to the spec? It seems to be a > simple > >> addition and allows us to standardize what is emerging as a common > >> capability. > >> > >> -- Dick > >> _______________________________________________ > >> 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 > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi --000e0cd179240702c604864d7557 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable although we are the ones who are pushing this into our ecosystem right now,= i agree with david on this one -- i'm happy to take the lead in drafti= ng this (i have some sketches of it working in the oauth 1.0a world for a o= ne time use --=A0http://mehack.com/oauth-echo-delegation-in-identity-verif= icatio), but i think this should be an extension.


On Tue, May 11, 2010 at 2:31 = AM, David Recordon <recordond@gmail.com> wrote:
I'm concerned about prematurely standardizing something which we don= 9;t
have deployment experience to guide. One of the things I like most
about OAuth 2.0 is that we're largely not inventing new things. Rather<= br> learning from what others have done in the past.

My view is that redelegation should first be drafted and deployed as
an extension.

--David


On Sun, May 9, 2010 at 10:20 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Re-delegation is something people asked for since we started talking a= bout OAuth. There is also a draft I-D about it. This is explicitly out of s= cope for the core spec (but not something that should stop us from having a= discussion).
>
> The main concern is how should the resource owner express their approv= al for such arrangement?
>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ie= tf.org] On Behalf
>> Of Dick Hardt
>> Sent: Sunday, May 09, 2010 7:34 PM
>> To: OAuth WG (oauth@ietf.org= )
>> Subject: [OAUTH-WG] delegating access to another client
>>
>> Twitter has an interesting use case that may become common: one cl= ient
>> needs to delegate access to another client. Similar to the 'mo= dify' method
>> where the scope of the access token can be modified, the 'dele= gate' method
>> allows a client to request delegation to another client (the deleg= ate). Here is
>> some proposed copy for the request:
>>
>> type
>> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set to delegate<= br> >>
>> client_id
>> =A0 =A0 =A0 REQUIRED. The client identifier as described in Sectio= n 3.4.
>>
>> client_secret
>> =A0 =A0 =A0 REQUIRED if the client was issued a secret. The client= secret.
>>
>> refresh_token
>> =A0 =A0 =A0 REQUIRED. The refresh token associated with the client= .
>>
>> delegate_id
>> =A0 =A0 =A0 REQUIRED. The client identifier of the delegate
>>
>> scope
>> =A0 =A0 =A0 OPTIONAL. The scope the client is requesting for the d= elegate.
>>
>> secret_type
>> =A0 =A0 =A0 OPTIONAL. The access token secret type as described by= Section 8.3.
>> If omitted, the authorization server will issue a bearer token (an= access token
>> without a matching secret) as described by Section 8.2.
>>
>> There a couple of choices for the flows for how a successful deleg= ation is
>> conveyed to the delegate. The AS could return a delegation code th= at is
>> similar to a verification code and the delegate acquires an access= token
>> similar to 3.6.2 Alternatively, the AS could return an delegation = token that is
>> used similar to a refresh token to obtain an access token and refr= esh token.
>>
>> Do people think this is worth adding to the spec? It seems to be a= simple
>> addition and allows us to standardize what is emerging as a common=
>> capability.
>>
>> -- Dick
>> _______________________________________________
>> 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
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Raffi Kriko= rian
Twitter Platform Team
http:= //twitter.com/raffi
--000e0cd179240702c604864d7557-- From y.oiwa@aist.go.jp Tue May 11 03:13:56 2010 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 E67F33A6887 for ; Tue, 11 May 2010 03:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 82qM0wLiSZkG for ; Tue, 11 May 2010 03:13:56 -0700 (PDT) Received: from faust.rcis.jp (faust.rcis.jp [61.194.89.210]) by core3.amsl.com (Postfix) with ESMTP id EAB293A6B87 for ; Tue, 11 May 2010 03:13:31 -0700 (PDT) Received: from [192.168.58.131] (pl280.nas946.p-tokyo.nttpc.ne.jp [210.153.204.24]) (authenticated bits=0) by faust.rcis.jp (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4BAD3cF020669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 May 2010 19:13:05 +0900 Message-ID: <4BE92DB7.4040901@aist.go.jp> Date: Tue, 11 May 2010 19:13:11 +0900 From: Yutaka OIWA Organization: RCIS, AIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Robert Sayre References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 10:13:57 -0000 On 2010/05/11 12:49, Robert Sayre wrote: > Basic leaves the input character encoding unspecified, so it doesn't > handle anything but ASCII in an interoperable way. OAuth > implementations will certainly screw this up too, but I suspect it > will be somewhat less buggy, since most people will probably just > guess it's supposed to be UTF-8. For the purpose of using Basic auth internally for OAuth, we could specify that it should be treated as UTF-8 under OAuth's context. However, if we go that way please make it an explicit rule in addition to RFC2617, not just as a people's guess. In Japan there is a long, non-ignorable history of using MS-Windows/MS-DOS local encoding (Shift_JIS) for Basic auth. And there is still many major implementations not using UTF-8 for this purpose. I afraid that, if Basic is used with no explicit charset rule, clients may use the core libraries of those and thus they will not assume UTF-8. At least under my short experiment, IE7 (ja) still assumes Shift_JIS for all of realm, user-name and password. This may be depending on the locale of either the browser or the operating system (I do not know which). # "Authorization: Basic k/qWe4zqOpP6lnuM6g==", # where both user/pass are the 3-char word "nihon-go" in Japanese characters. FF3.5.9 (Windows, ja) assumes ISO-8859-1(?) for realm, and sends some meaningless data for Japanese user-name/password (possibly each character truncated to single-octet forcibly). # "Authorization: Basic 5SyeOuUsng==". You can see there is only # 7 octets (for 6 Japanese characters + a colon) after decoding BASE64. -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From y.oiwa@aist.go.jp Tue May 11 03:31:55 2010 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 BFA053A6783 for ; Tue, 11 May 2010 03:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 qNlJ4ouBl+vL for ; Tue, 11 May 2010 03:31:53 -0700 (PDT) Received: from faust.rcis.jp (faust.rcis.jp [61.194.89.210]) by core3.amsl.com (Postfix) with ESMTP id AE0E63A6C0D for ; Tue, 11 May 2010 03:30:46 -0700 (PDT) Received: from [192.168.58.131] (pl280.nas946.p-tokyo.nttpc.ne.jp [210.153.204.24]) (authenticated bits=0) by faust.rcis.jp (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4BAUQ89020804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 May 2010 19:30:28 +0900 Message-ID: <4BE931CA.1070602@aist.go.jp> Date: Tue, 11 May 2010 19:30:34 +0900 From: Yutaka OIWA Organization: RCIS, AIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Robert Sayre References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 10:31:55 -0000 On 2010/05/11 12:49, Robert Sayre wrote: > What /would/ be nice is an HTTP authentication scheme that used some > sort of PAKE... but don't gate the OAuth spec on that. FYI for people interested: my proposal for PAKE-based HTTP authentication submitted as an Internet-Draft: . I designed it mainly considering Browser-based authentication, but I do not limit its possible uses to Browsers. Feedbacks from other possible usage area, if possible, is much appreciated. -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From hiddenharmony@gmail.com Tue May 11 03:34:07 2010 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 81C293A67F8 for ; Tue, 11 May 2010 03:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 sH+YBOciKAS6 for ; Tue, 11 May 2010 03:34:06 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 8F0293A6783 for ; Tue, 11 May 2010 03:34:06 -0700 (PDT) Received: by ywh3 with SMTP id 3so1670804ywh.31 for ; Tue, 11 May 2010 03:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7VIjy3uU5q8xJ6gzEkbjEJrjKYK6UTcaVV9sGHQ8WgQ=; b=Ts6CrpHfryuv8IjM8CiJTlLUmWDdsZm6vCxyV7NCPNbu6aZ3a0iwkKC01qsRmD53BI KXW4wkNv2dpPjrwEYPyeaCbIhGCLJpM3rG8NnuHVbf/7z6Qi1mUfe8qhyQLBjQxTt5WM i76fVYZfQb9dgrmuhOvV053d/gaT+tPZU1azE= 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=mjwy3jEUMstsqwhAPAPS8gUj+dhac0yBwJSlldsxMrokcpmkuKGhJgM7mrZ202OoXo mthkA4x/iYRT7cjiHTV6RgED5+D+I3bHLzDcFPzVUW2xnf9BA1Foa/MXcletfNGuK8Sk pTn75l4FDx0wwG4G2c3WFt+1/QJGNRr2NtugA= MIME-Version: 1.0 Received: by 10.100.246.9 with SMTP id t9mr1949071anh.3.1273574031553; Tue, 11 May 2010 03:33:51 -0700 (PDT) Received: by 10.100.153.11 with HTTP; Tue, 11 May 2010 03:33:51 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 May 2010 16:03:51 +0530 Message-ID: From: Vivek Khurana To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 10:34:07 -0000 On Mon, May 10, 2010 at 2:36 AM, Eran Hammer-Lahav wr= ote: > DEADLINE: 5/13 > > I would like to publish one more draft before our interim meeting in two = weeks (5/20). Below are two open issues we have on the list. Please reply w= ith your preference (or additional solutions) to each item. Issues with con= sensus will be incorporated into the next draft. Those without will be disc= ussed at the meeting. > > EHL > > --- > > 1. Server Response Format > > After extensive debate, we have a large group in favor of using JSON as t= he only response format (current draft). We also have a smaller group but w= ith stronger feelings on the subject that JSON adds complexity with no obvi= ous value. > > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional r= equest parameter Being someone who has been involved in development of general purpose libraries, I will either A or B, which means either full JSON RFC 4267 compliance or Form-encoded only. Support of multiple format not only increases development and maintenance effort, it increases the size of library too. Since on the web, client might have to download the library, keeping library size small is very important. If the standard supports multiple formats, we might end up with libraries which will support either JSON or XML or Form-encoded, thus leading to confusion among developers. > > --- > > 2. Client Authentication (in flows) > > How should the client authenticate when making token requests? The curren= t draft defines special request parameters for sending client credentials. = Some have argued that this is not the correct way, and that the client shou= ld be using existing HTTP authentication schemes to accomplish that such as= Basic. > > A. Client authenticates by sending its credentials using special paramete= rs (current draft) > B. Client authenticated by using HTTP Basic (or other schemes supported b= y the server such as Digest) Either of them is acceptable, but if we go with B, the specification should specify the charset to be used for Basic authentication. regards Vivek --=20 The hidden harmony is better than the obvious!! From paul.madsen@gmail.com Tue May 11 04:13:44 2010 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 44BB43A6B99 for ; Tue, 11 May 2010 04:13:44 -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 L7VJKBKe0SUx for ; Tue, 11 May 2010 04:13:43 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 6D2873A6B8D for ; Tue, 11 May 2010 04:12:57 -0700 (PDT) Received: by qyk11 with SMTP id 11so7154325qyk.13 for ; Tue, 11 May 2010 04:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=gJQWMLrAI37uw2kn+eQnMG9GaFYdSwF/GuVT6g4AHIs=; b=AnLnrg8fhmbbvqk9N9o1uBhtnOnoMZeVZ0T5fhuTfhXjw2FFWU8cgkP4BLEHlVyvDc yRud3ApfeUaFFbijKJUsA9LYPWfsLoc41QZ/lYzX6kRe/rA+8ET03pDYzKtP+20KkJ68 gQo1bccoDGaca1i7ualScjzzujdiBRW+OHkpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=M6tjkUAWerU3GrrYSIm2ACBAIt+peOqAye/yBaugIfrMZXzj3BlTW3GnQ55MQXa83e tdwE4+zpz99gXuly7YK+HXAsPMzQiyKHbfIT5Pr60wGc8yeI9dRCcmM/1+//w35qWpns zPR9BeQEHm73Wx91JId/GxCtZfZIcMOMPcTOA= Received: by 10.224.58.78 with SMTP id f14mr3567095qah.385.1273576363509; Tue, 11 May 2010 04:12:43 -0700 (PDT) Received: from [192.168.0.175] (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id 22sm3926318qyk.10.2010.05.11.04.12.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 May 2010 04:12:42 -0700 (PDT) Message-ID: <4BE93BA9.90604@gmail.com> Date: Tue, 11 May 2010 07:12:41 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: <20100510054516.2957E3A6B0C@core3.amsl.com> <4BE80820.7060907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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, 11 May 2010 11:13:44 -0000 Yes that's the idea. Where in the authorization server response would the QR code (or ref) go, especially if it also includes the uri & user code? I don't see mention of an extensibility model by which additional params could be defined/added On 5/10/2010 2:03 PM, Marius Scurtescu wrote: > On Mon, May 10, 2010 at 6:20 AM, Paul Madsen wrote: > >> Related, is anybody thinking of a variant of the device flow where the >> user-agent sits on a device with QR-code capabilities, and so the user >> needn't type anything (uri or code)? >> > The end user will point their phone to the device screen and the phone > browser will take it from there? I think the device still needs to > show the URI and code as fallback, in case the user does not have a > smart phone, right? > > Does the spec need to change in any way to support this? Isn't this > just a particular implementation? > > Marius > > From torsten@lodderstedt.net Tue May 11 08:53:58 2010 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 86C223A69E8 for ; Tue, 11 May 2010 08:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_40=-0.185, HELO_EQ_DE=0.35] 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 dHFsJCW+UACJ for ; Tue, 11 May 2010 08:53:57 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by core3.amsl.com (Postfix) with ESMTP id B8DF33A67AE for ; Tue, 11 May 2010 08:53:57 -0700 (PDT) Received: from p4fff1096.dip.t-dialin.net ([79.255.16.150] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OBrmD-0003jt-Eb; Tue, 11 May 2010 17:53:45 +0200 Message-ID: <4BE97D7F.7020303@lodderstedt.net> Date: Tue, 11 May 2010 17:53:35 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Vivek Khurana References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 15:53:58 -0000 Am 11.05.2010 12:33, schrieb Vivek Khurana: >> 2. Client Authentication (in flows) >> >> How should the client authenticate when making token requests? The current draft defines special request parameters for sending client credentials. Some have argued that this is not the correct way, and that the client should be using existing HTTP authentication schemes to accomplish that such as Basic. >> >> A. Client authenticates by sending its credentials using special parameters (current draft) >> B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest) >> > Either of them is acceptable, but if we go with B, the specification > should specify the charset to be used for Basic authentication. > > regards > Vivek > > What about defining a new Authentication Scheme for the purpose of OAuth client authentication? Would this help to deal with such problems? regards, Torsten. From romeda@gmail.com Tue May 11 09:04:04 2010 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 992E33A67A2 for ; Tue, 11 May 2010 09:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_50=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 vI9d-xsoDg-z for ; Tue, 11 May 2010 09:04:03 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 001FE3A68C7 for ; Tue, 11 May 2010 09:04:00 -0700 (PDT) Received: by pzk38 with SMTP id 38so2658165pzk.31 for ; Tue, 11 May 2010 09:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=lgwaMePsBIkK8jUZBnX53ZqbH0/Uppg2B07UL1lD4m8=; b=OZ05QStOnfl7ojffvTrYP8q2aEVGsZkR+JrL/UkBsXS1qgo28+KmYv8DnFJzggTWmK WTx45fB+M8UxWo/m5CiTPxeNa/ydQI0mBdHGmrx3/pkOVkACrZYUwPUea6M/LpNxFdwf brimPYke6ibbfIextu6JDz3caM2l2QsdU0omw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=M2XNjI+RHoRI/QPAmWE/JDqLrpXrMXkhMiUF3Lk6p4+UWL9uOpTVabZwtOGzBYmvAy 1bXoCCVxHhSObSwZ4a5XcnT85mweu6hYkhU0sM4x+Op6YBw5teoRXrpJg3sZ1kvddrCZ JDo7Rmuqcippsx++DecluRKGaWxdrmvMwjRAk= Received: by 10.141.2.10 with SMTP id e10mr3884231rvi.240.1273593601040; Tue, 11 May 2010 09:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.207.6 with HTTP; Tue, 11 May 2010 08:59:40 -0700 (PDT) From: Blaine Cook Date: Tue, 11 May 2010 16:59:40 +0100 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [OAUTH-WG] Call for Issues 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, 11 May 2010 16:04:04 -0000 Hannes and I are currently working on preparing an agenda for next week's meeting. In addition to the two issues Eran has open for comments on the list, we would like to solicit open issues from the community. Thanks to the incredible efforts that Eran and everyone else who has contributed recently, the scope and complexity of the issues has decreased substantially. As such, we'd like to incorporate the use of the working group issue tracker[1] to provide a simplified way to track progress and ensure that we're not losing things as we go. WHAT'S NEEDED FROM YOU: If you'd like to discuss an issue or idea at the upcoming meeting, you must add your issue to the issue tracker before 16:00 PST, SUNDAY, MAY 16 (that's midnight Sunday for those in Europe). You can create new tickets by going to [2]; if you haven't used (or can't remember using) the IETF issue tracker before, the easiest way to get started is to visit [3], set a password, and then visit [2]. This will give everyone the opportunity to coalesce, sub-divide, and prioritise issues before the meeting next week. If you do not raise your issue before Sunday, we cannot guarantee that there will be time to discuss it at the meeting. thanks very much from the chairs, Blaine & Hannes [1] http://trac.tools.ietf.org/wg/oauth/trac/report/1 [2] http://trac.tools.ietf.org/wg/oauth/trac/newticket [3] http://trac.tools.ietf.org/newlogin From beaton@google.com Tue May 11 09:18:42 2010 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 07E703A691B for ; Tue, 11 May 2010 09:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.723 X-Spam-Level: X-Spam-Status: No, score=-105.723 tagged_above=-999 required=5 tests=[AWL=0.254, 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 1+bcFSw2kGhD for ; Tue, 11 May 2010 09:18:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4289E3A691D for ; Tue, 11 May 2010 09:18:22 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o4BGIAwr007449 for ; Tue, 11 May 2010 09:18:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273594691; bh=qtJmig8Qjen0DO0U7QTlw/+FwWI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gRs5VABQ0BGfWUkQ2XcKN0qpzYvfvmlh8Q/DBlbvu0R+7UK7HAPnnX92O/eVuMcss hxhsYI8otaCe2lHE9Y+FA== 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=T//d/HgScq3kthR6Txn9xRDCzu/o/J5R/+pVMM7wxb09adGwXH8hjw1HyXW5WOLAz cWLQNtTQFIhN9EkE7MNkQ== Received: from pxi20 (pxi20.prod.google.com [10.243.27.20]) by wpaz17.hot.corp.google.com with ESMTP id o4BGI9hh004427 for ; Tue, 11 May 2010 09:18:09 -0700 Received: by pxi20 with SMTP id 20so2508732pxi.13 for ; Tue, 11 May 2010 09:18:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.196.7 with SMTP id t7mr4012774wff.151.1273594688677; Tue, 11 May 2010 09:18:08 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Tue, 11 May 2010 09:18:08 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 11 May 2010 09:18:08 -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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 16:18:42 -0000 On Mon, May 10, 2010 at 5:31 PM, Manger, James H wrote: > In general, the web is about following links. Clients need to know when > following a link crosses a security boundary. Cookies provide this; Basic > provides this; Digest provides this; OAuth needs this too. Notably absent from the list of protocols that need this: - AuthSub - ClientLogin - BBAuth - FBAuth - AOL OpenAuth - OAuth 1.0 Cheers, Brian From beaton@google.com Tue May 11 09:25:33 2010 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 929D93A6CE8 for ; Tue, 11 May 2010 09:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.616 X-Spam-Level: X-Spam-Status: No, score=-101.616 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 CEEA6H7A+WOx for ; Tue, 11 May 2010 09:25:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A4FC13A689C for ; Tue, 11 May 2010 09:25:18 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o4BGP0IU013302 for ; Tue, 11 May 2010 09:25:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273595101; bh=vLOjMq6Z850FuWtgyFX76SIdxNk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=TaVeUG+9PI+Tg2aUsnHlbZB3DlxDu6BQnlS3Cpm3FYKDierEBoq5IFA1zqOOmOFeW 7lVitEALWcgQUQVD+irXA== 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=ji7xiUcUkBKqClFoAo6S6nFUNGf5v7X+ZavLOHK9NekncgqSjd5NbKdSS04HUyITm jQ6RHDAf807tIg7Eq2SCw== Received: from pva18 (pva18.prod.google.com [10.241.209.18]) by kpbe16.cbf.corp.google.com with ESMTP id o4BGOJLq017520 for ; Tue, 11 May 2010 09:24:20 -0700 Received: by pva18 with SMTP id 18so75785pva.33 for ; Tue, 11 May 2010 09:24:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.196.15 with SMTP id t15mr4065520wff.238.1273595059645; Tue, 11 May 2010 09:24:19 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Tue, 11 May 2010 09:24:19 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47132@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47132@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 May 2010 09:24:19 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Provisional OAuth enhancements 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, 11 May 2010 16:25:33 -0000 On Mon, May 10, 2010 at 8:05 PM, Eran Hammer-Lahav wr= ote: > I don=92t see how moving the discussion/work on these features elsewhere = will > help reach consensus on them. I think the proposal is to keep discussion on the IETF mailing list, but clearly separate things that are speculative from things that are known to be practical. There have been a few cases where speculative things have nearly gotten included in the core spec, which seems fairly dangerous to me. > But I=92m not going to stop anyone from playing with the wiki=85 (or publ= ish > their own extension I-D). That's the idea. From torsten@lodderstedt.net Tue May 11 10:23:45 2010 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 647C43A6A08 for ; Tue, 11 May 2010 10:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.472 X-Spam-Level: X-Spam-Status: No, score=-0.472 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_40=-0.185, HELO_EQ_DE=0.35] 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 qOafas5biPj7 for ; Tue, 11 May 2010 10:23:42 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by core3.amsl.com (Postfix) with ESMTP id 185E23A6C42 for ; Tue, 11 May 2010 10:22:16 -0700 (PDT) Received: from p4fff1096.dip.t-dialin.net ([79.255.16.150] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OBt9Z-0003RF-QR; Tue, 11 May 2010 19:21:57 +0200 Message-ID: <4BE99233.4000901@lodderstedt.net> Date: Tue, 11 May 2010 19:21:55 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B26DE@WSMSG3153V.srv.dir.telstra.com> <4BE3E8B4.9020909@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B298B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112631B298B@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:23:45 -0000 Am 09.05.2010 16:39, schrieb Manger, James H: > Torsten, > > Thanks for your analysis. > > >> 1) Resource server controls token sites (context of the realm attribute) >> > >> 2) Authorization server controls token sites (context of token) >> > >> In my opinion, (1) improves security and eases the practicability of OAuth2 in scenarios with multiple sites and (2) is a significant security improvement. I think, both scenarios should be addressed by the WG. >> > > Scenario 1 is basically how HTTP Digest works -- using a "domains" param, which is a list of URI prefixes. > > > If a resource server is delegating to an authz server, it may as well also rely on the authz server to indicate "realm" values that are equivalent across multiple resource servers. > That is, I think it is useful to return "sites" and "realm" values in a token response from an authz server, but that it is not necessary to return "sites" in a 401 resource server response in OAuth. > One resource server may well not know about all the other resource servers. > > -- > James Manger > So you suggest to return "sites" from the authz server only? regards, Torsten. From eran@hueniverse.com Tue May 11 10:49:06 2010 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 B522C28C1E5 for ; Tue, 11 May 2010 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 RDbROnfOp1kn for ; Tue, 11 May 2010 10:49:05 -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 6CC2028C1F6 for ; Tue, 11 May 2010 10:49:05 -0700 (PDT) Received: (qmail 2860 invoked from network); 11 May 2010 17:48:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 May 2010 17:48:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 11 May 2010 10:48:53 -0700 From: Eran Hammer-Lahav To: Brian Eaton , "Manger, James H" Date: Tue, 11 May 2010 10:49:01 -0700 Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AcrxJZrH08YaFEy2SQeU0bDV5198MwADEpLw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB472B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 17:49:06 -0000 This is completely meaningless. This list is all vendors specific (including OAuth 1.0 which lacks any form= of discovery) which means libraries can easily hard-code the sites allowed= into their library. Also, because there really isn't any authentication ch= allenge involved, there is no issue with unfamiliar servers. On the other hand, browsers encounter Cookie and Basic authentication reque= sts all the time, and always with unfamiliar servers. That's the relevant e= xample. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Tuesday, May 11, 2010 9:18 AM > To: Manger, James H > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] sites with wildcard >=20 > On Mon, May 10, 2010 at 5:31 PM, Manger, James H > wrote: > > In general, the web is about following links. Clients need to know > > when following a link crosses a security boundary. Cookies provide > > this; Basic provides this; Digest provides this; OAuth needs this too. >=20 > Notably absent from the list of protocols that need this: > - AuthSub > - ClientLogin > - BBAuth > - FBAuth > - AOL OpenAuth > - OAuth 1.0 >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Tue May 11 10:52:49 2010 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 85D9828C192 for ; Tue, 11 May 2010 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.887 X-Spam-Level: X-Spam-Status: No, score=-100.887 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 hH+LRRnKJYdm for ; Tue, 11 May 2010 10:52:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 8A9DD28C1A2 for ; Tue, 11 May 2010 10:52:46 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o4BHqX6Q020398 for ; Tue, 11 May 2010 10:52:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273600354; bh=lI4Ieawsd9oNUG22HAu5tWhsqoA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Lf7qUKwyLzJ/3j4TpIV4MD0taDKkxolUpsp3SezolRSMumf052isVY3dw+LJ7D9ng jaB/h8Hu+fjPHNTGOSySQ== 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=HVstzY5AL9bnqSFMJRgrIHWxd7kGF8/h5yL36Jdi8S6MyYkg0d06ZEMVs2bbes6sE CPVgloltF7sDNHID4QbCw== Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by kpbe19.cbf.corp.google.com with ESMTP id o4BHqVjR030290 for ; Tue, 11 May 2010 10:52:32 -0700 Received: by pzk6 with SMTP id 6so2489962pzk.1 for ; Tue, 11 May 2010 10:52:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.86.10 with SMTP id o10mr3934969wfl.142.1273600350894; Tue, 11 May 2010 10:52:30 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Tue, 11 May 2010 10:52:30 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB472B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB472B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 May 2010 10:52:30 -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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 17:52:49 -0000 On Tue, May 11, 2010 at 10:49 AM, Eran Hammer-Lahav w= rote: > This is completely meaningless. > > This list is all vendors specific (including OAuth 1.0 which lacks any fo= rm of discovery) which means libraries can easily hard-code the sites allow= ed into their library. Also, because there really isn't any authentication = challenge involved, there is no issue with unfamiliar servers. > > On the other hand, browsers encounter Cookie and Basic authentication req= uests all the time, and always with unfamiliar servers. That's the relevant= example. Cookies and basic auth are largely irrelevant, because OAuth 2 doesn't need to replace cookies and basic auth. Cookies and basic auth work *just fine* in web browsers today. Every vendor participating in this discussion uses cookies, so I'd say that we have all the standardization we need in that space. OAuth 2 does need to replace all the vendor specific delegation protocols, though. Cheers, Brian From eran@hueniverse.com Tue May 11 11:03:44 2010 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 2CA963A6A4B for ; Tue, 11 May 2010 11:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 rGyBZruw+wlt for ; Tue, 11 May 2010 11:03:43 -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 662773A6A79 for ; Tue, 11 May 2010 11:03:22 -0700 (PDT) Received: (qmail 22255 invoked from network); 11 May 2010 18:03:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 May 2010 18:03:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 11 May 2010 11:03:10 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 11 May 2010 11:03:17 -0700 Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AcrxMr7j343mdJWXQAKsoEpotq95TgAAWmAQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB472D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB472B9@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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 18:03:44 -0000 That's a pretty limited view on what OAuth 2.0 is for. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Tuesday, May 11, 2010 10:53 AM > To: Eran Hammer-Lahav > Cc: Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] sites with wildcard >=20 > On Tue, May 11, 2010 at 10:49 AM, Eran Hammer-Lahav > wrote: > > This is completely meaningless. > > > > This list is all vendors specific (including OAuth 1.0 which lacks any = form of > discovery) which means libraries can easily hard-code the sites allowed i= nto > their library. Also, because there really isn't any authentication challe= nge > involved, there is no issue with unfamiliar servers. > > > > On the other hand, browsers encounter Cookie and Basic authentication > requests all the time, and always with unfamiliar servers. That's the rel= evant > example. >=20 > Cookies and basic auth are largely irrelevant, because OAuth 2 doesn't ne= ed > to replace cookies and basic auth. Cookies and basic auth work *just fin= e* in > web browsers today. Every vendor participating in this discussion uses > cookies, so I'd say that we have all the standardization we need in that = space. >=20 > OAuth 2 does need to replace all the vendor specific delegation protocols= , > though. >=20 > Cheers, > Brian From mscurtescu@google.com Tue May 11 11:24:02 2010 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 7447328C26F for ; Tue, 11 May 2010 11:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.214 X-Spam-Level: X-Spam-Status: No, score=-100.214 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 We86sELpxAdO for ; Tue, 11 May 2010 11:24:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1BAE428C26D for ; Tue, 11 May 2010 11:20:21 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o4BIK8bF030216 for ; Tue, 11 May 2010 11:20:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273602009; bh=5OnFh6/OaqRuLMe2o/jR5YE93NI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=LH/ru1Cmd1ilOASyCPvsob6kwBFgOvlhwp+ES3KcQv/T5camSbXE4WKAWfnlrtxWj rR3sm8KZIlz4wBF6CWKag== 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:content-transfer-encoding:x-system-of-record; b=O0gsTahQwKTEDGrdr5V6pUl8SavwUxXKS1HMLxmNRJW+5K3I8UuyKK5LwNaetvvTV X0o9ubCpn6QGXHeeltZfA== Received: from pvg4 (pvg4.prod.google.com [10.241.210.132]) by kpbe19.cbf.corp.google.com with ESMTP id o4BIJgoZ026462 for ; Tue, 11 May 2010 11:19:44 -0700 Received: by pvg4 with SMTP id 4so438007pvg.3 for ; Tue, 11 May 2010 11:19:42 -0700 (PDT) Received: by 10.140.248.20 with SMTP id v20mr4023425rvh.235.1273601982129; Tue, 11 May 2010 11:19:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Tue, 11 May 2010 11:19:22 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126328531E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1126328511A@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1126328531E@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Tue, 11 May 2010 11:19:22 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] SWT for indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:24:03 -0000 Hi James, On Mon, May 10, 2010 at 5:36 PM, Manger, James H wrote: > Marius, > >> But then again, how does the client end up making a request to > the wrong site? > > The client follows a redirect or link. It doesn't know if the ultimate so= urce of the new URI was the resource server=92s internal logic, user-genera= ted content, or a parameter in the request URI (eg an open redirector). If the protected resource sends a redirect instead of serving the resource then probably it knows what it is doing. Following links, how do you see that happening? Normally a client will not follow links without understanding them and at the same time send access tokens. All I am saying is that IMO it is not very likely that redirects and links will cause tokens to leak. I do agree that "sites" can help in these cases, just not sure it is worth the complexity. >>> If the wrong site uses HTTP then the token is also exposed on the netwo= rk -- so it has just been broadcast in the clear if you are using public wi= fi. Again a security failure. > >> Sure, but the "sites" parameter does not help in these cases. > > "sites" does help. If its value was: > =A0"sites": ["https://api.example.com", "https://img.example.com"] > Then no HTTP URI matches so the token is never sent in the clear. Yes, but HTTP and WIFI can compromise tokens even if sent to the proper sites. Right? Marius From mscurtescu@google.com Tue May 11 11:37:59 2010 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 A4F113A67B5 for ; Tue, 11 May 2010 11:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.496 X-Spam-Level: X-Spam-Status: No, score=-101.496 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JLODYxPV0TQe for ; Tue, 11 May 2010 11:37:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 482B93A6979 for ; Tue, 11 May 2010 11:37:42 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o4BIbTw6005839 for ; Tue, 11 May 2010 11:37:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273603050; bh=1BQGaD5Uf2CmhkIvP0O/6NSrFaw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=yWQ1tdFwbaHQtnSpUxD71Dvj0He253z5qpHDwieRzjYIsyPs8bTlFrJOUmJhxzhiT 4CdCiDRQI95lNHoSeCPCg== 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=MWUSCju6jikTsrOpckC3oVpXZuQt6jvf0slZHxRM9Fv9rH0jAng8yfdZQQ4JSOhuK p4IlDMGxP3c+2aGKgL9gg== Received: from pxi13 (pxi13.prod.google.com [10.243.27.13]) by kpbe11.cbf.corp.google.com with ESMTP id o4BIbCX9007758 for ; Tue, 11 May 2010 11:37:28 -0700 Received: by pxi13 with SMTP id 13so2846033pxi.37 for ; Tue, 11 May 2010 11:37:28 -0700 (PDT) Received: by 10.140.58.1 with SMTP id g1mr3915504rva.138.1273603048207; Tue, 11 May 2010 11:37:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Tue, 11 May 2010 11:37:08 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E20@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 11 May 2010 11:37:08 -0700 Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:37:59 -0000 On Mon, May 10, 2010 at 8:45 PM, David Recordon wrote: > If the sites parameter is not specified, would it default to the > domain of the authorization server. What is the domain of the authz server? The authz server is defined by two URLs, they may not have the same domain. Marius From beaton@google.com Tue May 11 11:39:10 2010 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 6D6B83A69F1 for ; Tue, 11 May 2010 11:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.74 X-Spam-Level: X-Spam-Status: No, score=-105.74 tagged_above=-999 required=5 tests=[AWL=0.237, 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 LjbcHgBwO6DY for ; Tue, 11 May 2010 11:39:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D99343A69ED for ; Tue, 11 May 2010 11:39:08 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o4BIcrM5016975 for ; Tue, 11 May 2010 11:38:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273603137; bh=WosvllvZzybV3EE80/k6msgDv/c=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bzvDjzjozWf5IqiCTG0Z140lT8rLeVW4tAbX1dquca/T0tOMPKgWDTTdK2xSqpdcX h/qK6kUkyvcofiXohlnVQ== 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=HXJixHIuquzHJ+0LUR/o8TxMWmdddFijcMJmEsKY0d3Mi8p1Ot3p6p6aUG7ENvw3N DxiZD0yb6N/uNxy0yP3zQ== Received: from pwi9 (pwi9.prod.google.com [10.241.219.9]) by hpaq13.eem.corp.google.com with ESMTP id o4BIcpPE008417 for ; Tue, 11 May 2010 11:38:52 -0700 Received: by pwi9 with SMTP id 9so2630367pwi.13 for ; Tue, 11 May 2010 11:38:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.56.21 with SMTP id e21mr4431753wfa.327.1273603131403; Tue, 11 May 2010 11:38:51 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Tue, 11 May 2010 11:38:51 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB472D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB472B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB472D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 May 2010 11:38: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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 18:39:10 -0000 On Tue, May 11, 2010 at 11:03 AM, Eran Hammer-Lahav wrote: > That's a pretty limited view on what OAuth 2.0 is for. It it what has brought a large community into this mailing list. From mscurtescu@google.com Tue May 11 13:56:59 2010 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 B10C53A6964 for ; Tue, 11 May 2010 13:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.506 X-Spam-Level: X-Spam-Status: No, score=-101.506 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rGneDV9SZ5Ju for ; Tue, 11 May 2010 13:56:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 6A9AF3A68E3 for ; Tue, 11 May 2010 13:56:25 -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 o4BKuCwW012950 for ; Tue, 11 May 2010 13:56:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273611373; bh=MmZlzZ+kz21adW8TEOHgzvuxC8k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=DCdPRjhZ0UQ2ex+8Y0DdpNzgf/jSYFV7+PWWcBB7UDG0LMaMsFNN1jDJVLUvYp/TF Bm5HmC0jZ/f619BgspyqA== 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:content-transfer-encoding:x-system-of-record; b=HOdvioXCXDhIyuUu38EyjdNXn9rmZUVYJmw4r1Mq+QbcG56VbIcYD5ENTImbAyj/4 e4zrMLPdMBXgrjQ6+VxuQ== Received: from pzk16 (pzk16.prod.google.com [10.243.19.144]) by wpaz1.hot.corp.google.com with ESMTP id o4BKuAAo008535 for ; Tue, 11 May 2010 13:56:11 -0700 Received: by pzk16 with SMTP id 16so2542327pzk.22 for ; Tue, 11 May 2010 13:56:10 -0700 (PDT) Received: by 10.140.179.39 with SMTP id b39mr4162030rvf.298.1273611370479; Tue, 11 May 2010 13:56:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Tue, 11 May 2010 13:55:50 -0700 (PDT) In-Reply-To: <4BE93BA9.90604@gmail.com> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <4BE80820.7060907@gmail.com> <4BE93BA9.90604@gmail.com> From: Marius Scurtescu Date: Tue, 11 May 2010 13:55:50 -0700 Message-ID: To: Paul Madsen 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] I-D Action:draft-ietf-oauth-v2-04.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, 11 May 2010 20:56:59 -0000 On Tue, May 11, 2010 at 4:12 AM, Paul Madsen wrote: > Yes that's the idea. > > Where in the authorization server response would the QR code (or ref) go, > especially if it also includes the uri & user code? I don't know how QR codes are generated, but I was assuming that the device can generate one without any help from the authz server, only based on uri and code. That's not going to work? Marius > > I don't see mention of an extensibility model by which additional params > could be defined/added > > On 5/10/2010 2:03 PM, Marius Scurtescu wrote: >> >> On Mon, May 10, 2010 at 6:20 AM, Paul Madsen >> =A0wrote: >> >>> >>> Related, is anybody thinking of a variant of the device flow where the >>> user-agent sits on a device with QR-code capabilities, and so the user >>> needn't type anything (uri or code)? >>> >> >> The end user will point their phone to the device screen and the phone >> browser will take it from there? I think the device still needs to >> show the URI and code as fallback, in case the user does not have a >> smart phone, right? >> >> Does the spec need to change in any way to support this? Isn't this >> just a particular implementation? >> >> Marius >> >> > From mscurtescu@google.com Tue May 11 14:05:28 2010 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 84A983A6A00 for ; Tue, 11 May 2010 14:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.538 X-Spam-Level: X-Spam-Status: No, score=-104.538 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_50=0.001, 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 4IoVS2DWYNtm for ; Tue, 11 May 2010 14:05:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 118AC3A684C for ; Tue, 11 May 2010 14:05:25 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o4BL56nr013291 for ; Tue, 11 May 2010 14:05:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273611906; bh=PDF18d2SZJxz7eaZW4FWwhkyFV0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=xboSsxiWVECPJ63Vb9REu22BsWHdDOH9FAmeKuJ53i584+dSvMn0srwC2y/HYtVzd BLrkw+G4CQwQPWusmtJBg== 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:content-transfer-encoding:x-system-of-record; b=Wt+5y0L2AAsPcw7xJBQvECNmUKRyryD3+xULEh+eUHHJxpWCE8xBpToldqJUxR1Jk SX6MdsY58inZX+Ppiby9A== Received: from pvg13 (pvg13.prod.google.com [10.241.210.141]) by wpaz33.hot.corp.google.com with ESMTP id o4BL54Fe019510 for ; Tue, 11 May 2010 14:05:05 -0700 Received: by pvg13 with SMTP id 13so718857pvg.35 for ; Tue, 11 May 2010 14:05:04 -0700 (PDT) Received: by 10.141.88.1 with SMTP id q1mr4230469rvl.198.1273611904293; Tue, 11 May 2010 14:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Tue, 11 May 2010 14:04:44 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 11 May 2010 14:04:44 -0700 Message-ID: To: Vivek Khurana Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 21:05:28 -0000 On Tue, May 11, 2010 at 3:33 AM, Vivek Khurana wr= ote: > On Mon, May 10, 2010 at 2:36 AM, Eran Hammer-Lahav = wrote: >> DEADLINE: 5/13 >> >> I would like to publish one more draft before our interim meeting in two= weeks (5/20). Below are two open issues we have on the list. Please reply = with your preference (or additional solutions) to each item. Issues with co= nsensus will be incorporated into the next draft. Those without will be dis= cussed at the meeting. >> >> EHL >> >> --- >> >> 1. Server Response Format >> >> After extensive debate, we have a large group in favor of using JSON as = the only response format (current draft). We also have a smaller group but = with stronger feelings on the subject that JSON adds complexity with no obv= ious value. >> >> A. Form-encoded only (original draft) >> B. JSON only (current draft) >> C. JSON as default with form-encoded and XML available with an optional = request parameter > > =A0Being someone who has been involved in development of general purpose > libraries, I will either A or B, which means either full JSON RFC 4267 > compliance or Form-encoded only. Support of multiple format not only > increases development and maintenance effort, it increases the size of > library too. Since on the web, client might have to download the > library, keeping library size small is very important. If the standard > supports multiple formats, we might end up with libraries which will > support either JSON or XML or Form-encoded, thus leading to confusion > among developers. For C, I don't think clients would be required to support both, only servers must support both. That being said, clients have to support A regardless (refresh token request still require clients to use form-encoded for the request; browser based requests require adding parameters to query string; browser based responses require parsing the query string; the User-Agent flow requires parsing query string from fragment). To me B and C are the same when it comes to dependencies and complexity. Marius From mscurtescu@google.com Tue May 11 14:12:18 2010 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 9CBDA3A6817 for ; Tue, 11 May 2010 14:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.804 X-Spam-Level: X-Spam-Status: No, score=-105.804 tagged_above=-999 required=5 tests=[AWL=0.173, 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 lTzWoCwH1GNG for ; Tue, 11 May 2010 14:12:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8701C3A6835 for ; Tue, 11 May 2010 14:12:16 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o4BLC0j4014159 for ; Tue, 11 May 2010 14:12:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273612322; bh=V6e3ZHmaBiBhey4OfJ14nziG+Co=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=oQLqwkhsYZckrvWiHXsgcWeCa71EtzlHUc0BnIgkVG8x5s9i7o3g4fzCpxo0NmM7u jqwY+RypyARbmaaEX/XJg== 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:content-transfer-encoding:x-system-of-record; b=P3WmNL242Vvfi1N1WniqVMYAnOEEKX0P3Kk6FKi4ykJaw0yvttjYPZvPO89EzuDD9 15ZqwQRIZha7/o6CFKgbQ== Received: from pxi14 (pxi14.prod.google.com [10.243.27.14]) by hpaq14.eem.corp.google.com with ESMTP id o4BLBwWt030306 for ; Tue, 11 May 2010 14:11:59 -0700 Received: by pxi14 with SMTP id 14so2291664pxi.6 for ; Tue, 11 May 2010 14:11:58 -0700 (PDT) Received: by 10.141.100.16 with SMTP id c16mr4152711rvm.29.1273612318147; Tue, 11 May 2010 14:11:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Tue, 11 May 2010 14:11:38 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Tue, 11 May 2010 14:11:38 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 21:12:18 -0000 On Mon, May 10, 2010 at 5:31 PM, Manger, James H wrote: > Yaron, > > > >> I don=92t understand the scenario that requires this feature. When does >> someone ask for a token without knowing where it is going? > > > > Example: > > A client app gets a token to make an API call to a protected resource tha= t > returns an Atom feed. > > The feed contains lots of entries, with links to photos, style sheets, an= d > scripts. > > The client app gets the photos. > > > > Should it send the token when getting the photos? I would say definitely not. If the client gets back a 403 with discovery info that points to the same authz server and approved scopes, only then could the client re-try with a token. Would that work? Marius From paul.madsen@gmail.com Tue May 11 14:30:15 2010 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 DFD353A6942 for ; Tue, 11 May 2010 14:30: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.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 0iXlUcuWs8AC for ; Tue, 11 May 2010 14:30:15 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6F7813A6817 for ; Tue, 11 May 2010 14:30:08 -0700 (PDT) Received: by vws13 with SMTP id 13so108474vws.31 for ; Tue, 11 May 2010 14:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=O4ETXjNTPJKuBi7jcaYo+CnJ01YHqajRZYT1LoBv+eA=; b=wIGc8h/qGlfKTDkKiOWeS4TORDipPN7XyPMjpufrHVzUmR1MMKTR+Sl4/P10/ODw4X 2B6Pm8JizEjTc8HIbkHNGKL1JTEy/dYru5fUdOs5DeXFzNh5QzpoOlC0QU35UJAh43LC RVVAFb1L/HElgZlMXBujS1AezNVYQd/qRooVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=b/q4JAStg42hA0qs36uTcgKIUFNJmNm9SqS1tVJe8IIuiq9MJlBEeAdJ/b6/mE3AFU TbeZpUoG6ihxw+d4tm1fPPcHW76WotaWzh05CwARjRtm3EoKuneNoWcsS/SkZZSgKI8W SpmW+TEcBxYlMQozgDYw6v5nHrnjRstP6k3EE= Received: by 10.229.241.139 with SMTP id le11mr4511493qcb.95.1273613394868; Tue, 11 May 2010 14:29:54 -0700 (PDT) Received: from [192.168.0.175] (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id x34sm4872547qce.3.2010.05.11.14.29.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 May 2010 14:29:54 -0700 (PDT) Message-ID: <4BE9CC4F.7000906@gmail.com> Date: Tue, 11 May 2010 17:29:51 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: <20100510054516.2957E3A6B0C@core3.amsl.com> <4BE80820.7060907@gmail.com> <4BE93BA9.90604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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, 11 May 2010 21:30:16 -0000 Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in a QR code and add it to the response to the client (perhaps as you say in addition to the raw URI & user code). There would be no user-code, as we would no longer be constrained by the user's short-term memory for strings If (as you describe) the client creates the QR code from the 'raw' URI and user-code that the AS provided it, then there would need be sufficient OAuth smarts on the phone to reconstruct the URI and code from the QR code the client displayed If, on the other hand, the AS creates the QR code from a URI it generates, then the phone need only launch a browser to load that URI. paul On 5/11/2010 4:55 PM, Marius Scurtescu wrote: > On Tue, May 11, 2010 at 4:12 AM, Paul Madsen wrote: > >> Yes that's the idea. >> >> Where in the authorization server response would the QR code (or ref) go, >> especially if it also includes the uri& user code? >> > I don't know how QR codes are generated, but I was assuming that the > device can generate one without any help from the authz server, only > based on uri and code. That's not going to work? > > Marius > > >> I don't see mention of an extensibility model by which additional params >> could be defined/added >> >> On 5/10/2010 2:03 PM, Marius Scurtescu wrote: >> >>> On Mon, May 10, 2010 at 6:20 AM, Paul Madsen >>> wrote: >>> >>> >>>> Related, is anybody thinking of a variant of the device flow where the >>>> user-agent sits on a device with QR-code capabilities, and so the user >>>> needn't type anything (uri or code)? >>>> >>>> >>> The end user will point their phone to the device screen and the phone >>> browser will take it from there? I think the device still needs to >>> show the URI and code as fallback, in case the user does not have a >>> smart phone, right? >>> >>> Does the spec need to change in any way to support this? Isn't this >>> just a particular implementation? >>> >>> Marius >>> >>> >>> >> > From mscurtescu@google.com Tue May 11 14:47:53 2010 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 4B6303A6AA5 for ; Tue, 11 May 2010 14:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.516 X-Spam-Level: X-Spam-Status: No, score=-101.516 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 difrGWFeSCpw for ; Tue, 11 May 2010 14:47:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 8BDE03A6A93 for ; Tue, 11 May 2010 14:47:43 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o4BLlV8Q027454 for ; Tue, 11 May 2010 14:47:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273614451; bh=faG8yhLInNmkanAjKht7lmSlIjM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bTl0ZJpenGiolSwkT+YRYoJEwPqW4eei0MS6gvX4YYENeLwEFVqJ4S1B8HOktcZaU yYtETL32AwKz0lnZeF5gA== 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=m+V5C/zOUk/gLCbF491FYmV7rXqtW0RZMGqfcQkfpmZipNWc2KAmVnAPQLhp6fTXB 1d/RBcw4VqwHeWDlljRiw== Received: from pwj7 (pwj7.prod.google.com [10.241.219.71]) by hpaq12.eem.corp.google.com with ESMTP id o4BLlTAk000667 for ; Tue, 11 May 2010 14:47:29 -0700 Received: by pwj7 with SMTP id 7so4994347pwj.2 for ; Tue, 11 May 2010 14:47:28 -0700 (PDT) Received: by 10.140.252.3 with SMTP id z3mr4200109rvh.285.1273614448341; Tue, 11 May 2010 14:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Tue, 11 May 2010 14:47:08 -0700 (PDT) In-Reply-To: <4BE9CC4F.7000906@gmail.com> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <4BE80820.7060907@gmail.com> <4BE93BA9.90604@gmail.com> <4BE9CC4F.7000906@gmail.com> From: Marius Scurtescu Date: Tue, 11 May 2010 14:47:08 -0700 Message-ID: To: Paul Madsen Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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, 11 May 2010 21:47:53 -0000 On Tue, May 11, 2010 at 2:29 PM, Paul Madsen wrote: > Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in a > QR code and add it to the response to the client (perhaps as you say in > addition to the raw URI & user code). There would be no user-code, as we > would no longer be constrained by the user's short-term memory for strings I see, this would allow for a longer user code. Yes, an extension would be needed for this case. > If (as you describe) the client creates the QR code from the 'raw' URI and > user-code that the AS provided it, then there would need be sufficient OAuth > smarts on the phone to reconstruct the URI and code from the QR code the > client displayed The client can simply append the user code as a query parameter, so the phone still deals with just a URL. But I guess the authz server may or may not accept that (it could require a special param name for the code or POST only). > If, on the other hand, the AS creates the QR code from a URI it generates, > then the phone need only launch a browser to load that URI. Maybe we should start a thread about extensions. Sounds like a good topic for next week :-) Thanks for clarifying. Marius From uidude@google.com Tue May 11 15:05:41 2010 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 516833A6A8B for ; Tue, 11 May 2010 15:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.998 X-Spam-Level: X-Spam-Status: No, score=-100.998 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 KFv3l6BEkrLz for ; Tue, 11 May 2010 15:05:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5A9A93A6C03 for ; Tue, 11 May 2010 15:05:06 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o4BM4rgf000962 for ; Tue, 11 May 2010 15:04:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273615494; bh=HR+SUczlooVjJ55nVU+E8gRdbZs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NsTo2j8mmu1+jYrrrpKYKpQeMnwkB5oZajr6mrTQuoxsJxqrtbFy4vdVr+sd2/E+5 T0rAJBC372iC2qUaoPBNA== 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=ng+dFRfuMloIb5pgyw0dMQG2DKdgnc5fi1osqJFShMeng0JMTtFd5p0waPFDfuRyp L4MRVzFM+Knn07biSpWXg== Received: from vws15 (vws15.prod.google.com [10.241.21.143]) by kpbe14.cbf.corp.google.com with ESMTP id o4BM4Fgc022665 for ; Tue, 11 May 2010 15:04:52 -0700 Received: by vws15 with SMTP id 15so7864280vws.2 for ; Tue, 11 May 2010 15:04:52 -0700 (PDT) Received: by 10.229.214.20 with SMTP id gy20mr366740qcb.149.1273615490644; Tue, 11 May 2010 15:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Tue, 11 May 2010 15:04:28 -0700 (PDT) In-Reply-To: References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Tue, 11 May 2010 15:04:28 -0700 Message-ID: To: Marius Scurtescu Content-Type: multipart/alternative; boundary=0016363b9058e67b2d048658b651 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 11 May 2010 22:05:41 -0000 --0016363b9058e67b2d048658b651 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu wrote: > On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav > wrote: > > > >> -----Original Message----- > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Sunday, May 09, 2010 5:52 PM > > > >> >> 3.5.1. Client Requests Authorization > >> >> > >> >> If the client has previously registered a redirection URI with the > >> >> authorization server, the authorization server MUST verify that > the > >> >> redirection URI received matches the registered URI associated > with > >> >> the client identifier. > >> >> > >> >> Does this mean equality? Or just the same base string? > >> > > >> > Right now it depends on the server. > >> > >> The spec should clarify that. Suggested wording: > >> > >> > >> If the client has previously registered a redirection URI with the > authorization > >> server, the authorization server MUST verify that the redirection URI > >> received matches the registered URI associated with the client > identifier. The > >> components of the redirection URI that must match the registered URI is > >> authorization server dependant. > > > > I don't see how that helps... I also don't see why we can't just profile > this and decide on how the matching should be done. We have the state > parameter to help too. > > I also think the spec should specify how the matching should be done. > > If left up to the authz server then a client that designs its OAuth 2 > implementation will have to assume that all authz servers will do > strict equality matching, otherwise it may not be able to interact > with some servers. > > For example, if the client assumes that it can use load balancing by > varying the first part of the host name, and this may work with the > fist authz server it integrate with, later this client will not be > able to interact with an authz server which does strict matching on > host name. And changing the load balancing architecture once deployed > could be very hard. > > Since there is a state parameter maybe it is enough to allow wild > cards only in the domain name of the callback URI. > I think this we should leave this matching undefined for now - since you have to preregister with every site, you will have provider-specific logic anyway. This will be much more important when we have a discovery mechanism for callback URLs. Also note that for the load balancing use case a client can set up their own redirector. This is dangerous (open redirectors are very easy to create), but if you're doing load balancing you can probably get the redirection logic right. > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016363b9058e67b2d048658b651 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 10, 2010 at 1:16 PM, Marius = Scurtescu <ms= curtescu@google.com> wrote:
On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>
>> -----Original Message-----
>> From: Dick Hardt [mailto:d= ick.hardt@gmail.com]
>> Sent: Sunday, May 09, 2010 5:52 PM
>
>> >> 3.5.1. =A0Client Requests Authori= zation
>> >>
>> >> If the client has previously registered a redirection URI= with the
>> >> =A0 =A0authorization server, the authorization server MUS= T verify that the
>> >> =A0 =A0redirection URI received matches the registered UR= I associated with
>> >> =A0 =A0the client identifier.
>> >>
>> >> Does this mean equality? Or just the same base string? >> >
>> > Right now it depends on the server.
>>
>> The spec should clarify that. Suggested wording:
>>
>>
>> If the client has previously registered a redirection URI with the= authorization
>> server, the authorization server MUST verify that the redirection = URI
>> received matches the registered URI associated with the client ide= ntifier. The
>> components of the redirection URI that must match the registered U= RI is
>> authorization server dependant.
>
> I don't see how that helps... I also don't see why we can'= t just profile this and decide on how the matching should be done. We have = the state parameter to help too.

I also think the spec should specify how the matching should be done.=

If left up to the authz server then a client that designs its OAuth 2
implementation will have to assume that all authz servers will do
strict equality matching, otherwise it may not be able to interact
with some servers.

For example, if the client assumes that it can use load balancing by
varying the first part of the host name, and this may work with the
fist authz server it integrate with, later this client will not be
able to interact with an authz server which does strict matching on
host name. And changing the load balancing architecture once deployed
could be very hard.

Since there is a state parameter maybe it is enough to allow wild
cards only in the domain name of the callback URI.
I think this we should leave this matching undefined for now - since you h= ave to preregister with every site, you will have provider-specific logic a= nyway. This will=A0be much more important when we have a discovery mechanis= m for callback URLs.

Also note that for the load balancing use case a client= can set up their own redirector. This is dangerous (open redirectors are v= ery easy to create), but if you're doing load balancing you can probabl= y get the redirection logic right.


Marius
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016363b9058e67b2d048658b651-- From mscurtescu@google.com Tue May 11 15:14:28 2010 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 F28C13A6989 for ; Tue, 11 May 2010 15:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.226 X-Spam-Level: X-Spam-Status: No, score=-100.226 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 mrMMtOWLEVp5 for ; Tue, 11 May 2010 15:14:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 262EE3A6A8B for ; Tue, 11 May 2010 15:14:20 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o4BME9Qj012523 for ; Tue, 11 May 2010 15:14:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273616049; bh=7YTifQ8S1AMfNhiqmrD1+/4/dwQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=OGom7eGfzmgU2G99pEZ8c36+Ycf90H8DFH2yUt8U0qyPPqAkXix7Sg9RMuB4pEB1m tlYQSAZqst2JeK9kiT6DQ== 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:content-transfer-encoding:x-system-of-record; b=kyh+ywm8wbrHebVDovdOjP21OvF2S2DjBhzSFb0HFtcbH+IcM0H4whTH4rQjiSdy6 okL5Aa7Z51qFARVxByPzg== Received: from pwj4 (pwj4.prod.google.com [10.241.219.68]) by kpbe18.cbf.corp.google.com with ESMTP id o4BMDgjq017820 for ; Tue, 11 May 2010 15:14:07 -0700 Received: by pwj4 with SMTP id 4so527168pwj.25 for ; Tue, 11 May 2010 15:14:07 -0700 (PDT) Received: by 10.141.100.16 with SMTP id c16mr4204047rvm.29.1273616047343; Tue, 11 May 2010 15:14:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Tue, 11 May 2010 15:13:47 -0700 (PDT) In-Reply-To: References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 11 May 2010 15:13:47 -0700 Message-ID: To: Evan Gilbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 11 May 2010 22:14:28 -0000 On Tue, May 11, 2010 at 3:04 PM, Evan Gilbert wrote: > > On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu > wrote: >> >> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav >> wrote: >> > >> >> -----Original Message----- >> >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> >> Sent: Sunday, May 09, 2010 5:52 PM >> > >> >> >> 3.5.1. =A0Client Requests Authorization >> >> >> >> >> >> If the client has previously registered a redirection URI with the >> >> >> =A0 =A0authorization server, the authorization server MUST verify = that >> >> >> the >> >> >> =A0 =A0redirection URI received matches the registered URI associa= ted >> >> >> with >> >> >> =A0 =A0the client identifier. >> >> >> >> >> >> Does this mean equality? Or just the same base string? >> >> > >> >> > Right now it depends on the server. >> >> >> >> The spec should clarify that. Suggested wording: >> >> >> >> >> >> If the client has previously registered a redirection URI with the >> >> authorization >> >> server, the authorization server MUST verify that the redirection URI >> >> received matches the registered URI associated with the client >> >> identifier. The >> >> components of the redirection URI that must match the registered URI = is >> >> authorization server dependant. >> > >> > I don't see how that helps... I also don't see why we can't just profi= le >> > this and decide on how the matching should be done. We have the state >> > parameter to help too. >> >> I also think the spec should specify how the matching should be done. >> >> If left up to the authz server then a client that designs its OAuth 2 >> implementation will have to assume that all authz servers will do >> strict equality matching, otherwise it may not be able to interact >> with some servers. >> >> For example, if the client assumes that it can use load balancing by >> varying the first part of the host name, and this may work with the >> fist authz server it integrate with, later this client will not be >> able to interact with an authz server which does strict matching on >> host name. And changing the load balancing architecture once deployed >> could be very hard. >> >> Since there is a state parameter maybe it is enough to allow wild >> cards only in the domain name of the callback URI. > > I think this we should leave this matching undefined for now - since you > have to preregister with every site, you will have provider-specific logi= c > anyway. This will=A0be much more important when we have a discovery mecha= nism > for callback URLs. If we leave undefined then that is the same as enforcing strict equality matching. Then let's make that explicit. Are we OK with that? A client that eventually wants to interact with several authz servers will have to assume the "greatest common divisor", which is strict matching. Marius From yarong@microsoft.com Tue May 11 16:09:57 2010 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 ADF2C3A6A1A for ; Tue, 11 May 2010 16:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.008 X-Spam-Level: X-Spam-Status: No, score=-10.008 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YkqMjovyBnVv for ; Tue, 11 May 2010 16:09:57 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id F1E013A695F for ; Tue, 11 May 2010 16:09:56 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 11 May 2010 16:09:46 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Tue, 11 May 2010 16:09:46 -0700 From: Yaron Goland To: Brian Eaton , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AQHK8SWhrXmdu8iAMU+K7OlC4RFdKJJM94eAgAAA+QCAAAMEgIAACfCA///WI1A= Date: Tue, 11 May 2010 23:09:43 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A429608@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB472B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB472D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 23:09:57 -0000 Limited views on what a protocol is far tend to produce protocols that are = actually interoperable. We should strive to do as little as possible in the= standard and make sure we do a great job leaving the door open to later ex= tensions. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Tuesday, May 11, 2010 11:39 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] sites with wildcard >=20 > On Tue, May 11, 2010 at 11:03 AM, Eran Hammer-Lahav > wrote: > > That's a pretty limited view on what OAuth 2.0 is for. >=20 > It it what has brought a large community into this mailing list. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From yarong@microsoft.com Tue May 11 16:24:38 2010 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 3BFAF3A6C12 for ; Tue, 11 May 2010 16:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.144 X-Spam-Level: X-Spam-Status: No, score=-9.144 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] 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 DapNBVz7SwS4 for ; Tue, 11 May 2010 16:24:37 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id DABC53A6A92 for ; Tue, 11 May 2010 16:24:05 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 11 May 2010 16:23:55 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi; Tue, 11 May 2010 16:23:54 -0700 From: Yaron Goland To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: AQHK8M2JqAP3Yhb/w06D/QdCD+DPKpJMuIJQ Date: Tue, 11 May 2010 23:23:51 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A4296A0@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> <4BE8EF51.1070305@lodderstedt.net> In-Reply-To: <4BE8EF51.1070305@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 23:24:38 -0000 Actually it's server side that's the problem. Many servers limit the size o= f the HTTP request headers they will accept. Apache 2.2, for example, uses = the LimitRequestFieldSize Directive (http://httpd.apache.org/docs/2.2/mod/c= ore.html). Its default size is 8190 bytes. IIS, I Believe, defaults to arou= nd 16K. But SAML assertions can easily clock in at 30 or 40k without even t= rying. So as a practical matter we need a way to allow clients to assert their rig= ht to a token using the request body so as to not need to artificially limi= t the size of the token that is being submitted. Yaron > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, May 10, 2010 10:47 PM > To: Yaron Goland > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > Am 11.05.2010 01:43, schrieb Yaron Goland: > > > >> --- > >> > >> 2. Client Authentication (in flows) > >> > >> How should the client authenticate when making token requests? The > >> current draft defines special request parameters for sending client > >> credentials. Some have argued that this is not the correct way, and > >> that the client should be using existing HTTP authentication schemes > >> to accomplish that such as Basic. > >> > >> A. Client authenticates by sending its credentials using special > >> parameters (current draft) B. Client authenticated by using HTTP > >> Basic (or other schemes supported by the server such as Digest) > >> > >> > > [Yaron Goland] A is needed at a minimum because there are physical > limitations to how many bytes can go into an authorization header. > > >=20 > As far as I know, 4KB is the minimum size for headers that must be suppor= ted > by user agents, which should suffice from my point of view. > Moreover, other HTTP authentication mechanisms need much more than > 4KB, For example, SPNEGO authentication headers can be up to 12392 bytes. >=20 > regards, > Torsten. >=20 > >> _______________________________________________ > >> 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 > > >=20 >=20 From yarong@microsoft.com Tue May 11 16:29:06 2010 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 0C6FC3A6A1A for ; Tue, 11 May 2010 16:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.733 X-Spam-Level: X-Spam-Status: No, score=-8.733 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Sw341FNelMzv for ; Tue, 11 May 2010 16:29:05 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id ED6CB3A69FC for ; Tue, 11 May 2010 16:29:04 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 11 May 2010 16:28:54 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi; Tue, 11 May 2010 16:28:54 -0700 From: Yaron Goland To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Thread-Topic: sites with wildcard Thread-Index: AcrwTaPsC4ggYQawSQ6EnsB9Iie0cQATPiVwAAA9JoAAMWf8oA== Date: Tue, 11 May 2010 23:28:51 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A429748@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C4A429748TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 23:29:06 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C4A429748TK5EX14MBXC117r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBleHBsYWluaW5nLCBJIG5vdyBiZWxpZXZlIEkgdW5kZXJzdGFuZCB0aGUgdXNl IGNhc2UuDQoNCkJ1dCBJIHdvdWxkIHBvaW50IG91dCB0aGF0IHRoaXMgaXMgcmVhbGx5IGFuIHVu c29sdmVkIHByb2JsZW0gaW4gZ2VuZXJhbCBhbmQgaWYgd2UgYXJlIHRvIHRhY2tsZSBpdCB3ZSBo YXZlIHRvIGRlYWwgd2l0aCByZWFsIGNvbmNlcm5zIHN1Y2ggYXMg4oCTIHdoYXQgaGFwcGVucyBp ZiBpbiB0aGUgdGltZSBzaW5jZSB0aGUgc2l0ZSBsaXN0IHdhcyBwcm92aWRlZCBhbmQgd2hlbiB0 aGUgdG9rZW4gd2FzIHVzZWQgdGhlIGxpc3Qgd2FzIGNoYW5nZWQ/IElmIGFuIGF0dGFja2VyIG5v dyBjb250cm9scyBhIHByZXZpb3VzbHkgbGlzdGVkIHNpdGUgdGhlbiB0aGUgYXR0YWNrZXIgY2Fu IGp1c3Qgc3dhbGxvdyB0aGUgYmVhcmVyIHRva2VuIGFuZCBkbyBiYWQgdGhpbmdzLiBTbyBub3cg d2UgaGF2ZSB0byB0aGluayBhYm91dCBleHBpcmF0aW9uIGluZm9ybWF0aW9uIG9uIHRoZSBzaXRl IGxpc3Qgb3IgYSByZXZvY2F0aW9uIG1lY2hhbmlzbSBvciBzb21lIGtpbmQgb2YgbmVnb3RpYXRp b24uDQoNCk9uZSB3b25kZXJzIGlmIGl0IHdvdWxkbuKAmXQgYmUgc2ltcGxlciBmb3IgY2xpZW50 cyB0aGF0IGFyZSBpbiBkb3VidCB0byBqdXN0IG1ha2UgYW5vdGhlciB0b2tlbiByZXF1ZXN0IHRv IHRoZSBvcmlnaW5hbCBzZXJ2aWNl4oCZcyB0b2tlbiBpc3N1ZXIgd2l0aCBhIHNjb3BlIGZvciB0 aGUgZGVzaXJlZCBzaXRlLiBUaGF0IHdvcmtzIHdpdGggdGhlIGV4aXN0aW5nIHByb3RvY29sIGFu ZCBtaXRpZ2F0ZXMgdGhlIHByZXZpb3VzIGF0dGFjay4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBKdXN0IGEgdGhvdWdodCwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgWWFyb24NCg0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21h aWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KU2VudDogTW9uZGF5LCBNYXkg MTAsIDIwMTAgNTozMSBQTQ0KVG86IFlhcm9uIEdvbGFuZDsgT0F1dGggV0cgKG9hdXRoQGlldGYu b3JnKQ0KU3ViamVjdDogUkU6IHNpdGVzIHdpdGggd2lsZGNhcmQNCg0KWWFyb24sDQoNCj4gSSBk b27igJl0IHVuZGVyc3RhbmQgdGhlIHNjZW5hcmlvIHRoYXQgcmVxdWlyZXMgdGhpcyBmZWF0dXJl LiBXaGVuIGRvZXMgc29tZW9uZSBhc2sgZm9yIGEgdG9rZW4gd2l0aG91dCBrbm93aW5nIHdoZXJl IGl0IGlzIGdvaW5nPw0KDQpFeGFtcGxlOg0KQSBjbGllbnQgYXBwIGdldHMgYSB0b2tlbiB0byBt YWtlIGFuIEFQSSBjYWxsIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlIHRoYXQgcmV0dXJucyBhbiBB dG9tIGZlZWQuDQpUaGUgZmVlZCBjb250YWlucyBsb3RzIG9mIGVudHJpZXMsIHdpdGggbGlua3Mg dG8gcGhvdG9zLCBzdHlsZSBzaGVldHMsIGFuZCBzY3JpcHRzLg0KVGhlIGNsaWVudCBhcHAgZ2V0 cyB0aGUgcGhvdG9zLg0KDQpTaG91bGQgaXQgc2VuZCB0aGUgdG9rZW4gd2hlbiBnZXR0aW5nIHRo ZSBwaG90b3M/DQoNCk9uIHNlcnZpY2UgQSB0aGUgQXRvbSBmZWVkIGFuZCB0aGUgcGhvdG9zIGFy ZSBhbGwgc2VydmVkIGZyb20gdGhlIHNhbWUgSFRUUFMgaG9zdCwgd2l0aCB0aGUgc2FtZSBwcm90 ZWN0aW9uLCBzbyB0aGUgdG9rZW4gbXVzdCBiZSBzZW50Lg0KDQpPbiBzZXJ2aWNlIEIgdGhlIHBo b3RvcyBhcmUgaG9zdGVkIG9uIGEgc2VwYXJhdGUgb3V0c291cmNlZCBjb250ZW50IGRpc3RyaWJ1 dGlvbiBuZXR3b3JrLiBUaGUgcGhvdG9zIGFyZSBwcm90ZWN0ZWQgYnkgdXNpbmcgbG9uZyB1bmd1 ZXNzYWJsZSBVUklzICh0aGUgVVJJcyBhcmUgZWZmZWN0aXZlbHkg4oCcY2FwYWJpbGl0aWVz4oCd IHRvIHJlYWQgdGhlIHBob3RvcykuIFRoZSB0b2tlbiBkb2VzIG5vdCBuZWVkIHRvIGJlIHNlbnQu DQoNCk9uIHNlcnZpY2UgQyB0aGUgcGhvdG9zIGFyZSBhbnkgaW1hZ2VzIGZyb20gYW55d2hlcmUg b24gdGhlIEludGVybmV0IHRoYXQgdGhlIHVzZXIgaGFzIGNob3NlbiB0byBsaW5rIHRvLiBUaGUg QXRvbSBjb2xsZWN0aW9uIGlzIHByb3RlY3RlZCwgYnV0IG5vdCB0aGUgcGhvdG9zLiBUaGUgdG9r ZW4gYWJzb2x1dGVseSBtdXN0IG5vdCBiZSBzZW50IHdoZW4gZ2V0dGluZyB0aGUgcGhvdG9zLg0K DQoNCkEgY2xpZW50IGFwcCBuZWVkcyB0byBrbm93IHdoZXRoZXIgdGhlIHNlcnZpY2UgaXQgaXMg YWNjZXNzaW5nIGlzIGxpa2UgQSwgQiwgb3IgQy4gSXQgbmVlZHMgdG8ga25vdyBmb3IgcmVkaXJl Y3RzLCBmb3IgbGlua3MgaW4gSFRUUCBoZWFkZXJzLCBmb3IgbGlua3MgdG8gaW1hZ2VzLCBmb3Ig YW55IG90aGVyIHNvcnQgb2YgbGluayB0aGF0IGlzIGNhbiBkZXJpdmUgZnJvbSB0aGUgcmVzcG9u c2UuDQoNClNvbWUgc2VydmljZXMgbWlnaHQgYmUgY29tcGxldGVseSB3YWxsZWQgZ2FyZGVucyBz byB0aGUgY2xpZW50IGNhbiBhc3N1bWUgdGhleSBhcmUgbGlrZSBBLg0KU29tZSBzZXJ2aWNlcyBt aWdodCBleHBsaWNpdGx5IHN0YXRlIGluIHRoZWlyIGRvY3VtZW50YXRpb246IHdoaWNoIGxpbmtz IGFuZCByZWRpcmVjdHMgYXJlIGFsd2F5cyBndWFyYW50ZWVkIHRvIGJlIG90aGVyIEFQSSBjYWxs cyAoc2VuZCB0aGUgdG9rZW4pOyB3aGljaCB3aWxsIGFsd2F5cyBiZSB0byBvdGhlciBzZWN1cml0 eSBjb250ZXh0cyAoZG9u4oCZdCBzZW5kIHRoZSB0b2tlbik7IGFuZCB3aGljaCBtaWdodCBiZSBl aXRoZXIgKGRvbuKAmXQgc2VuZCB0aGUgdG9rZW4sIHNlZSBpZiB5b3UgZ2V0IGEgNDAxLzQwMywg Z3Vlc3MsIHNlbmQgdGhlIHRva2VuKS4NCg0KSW4gZ2VuZXJhbCwgdGhlIHdlYiBpcyBhYm91dCBm b2xsb3dpbmcgbGlua3MuIENsaWVudHMgbmVlZCB0byBrbm93IHdoZW4gZm9sbG93aW5nIGEgbGlu ayBjcm9zc2VzIGEgc2VjdXJpdHkgYm91bmRhcnkuIENvb2tpZXMgcHJvdmlkZSB0aGlzOyBCYXNp YyBwcm92aWRlcyB0aGlzOyBEaWdlc3QgcHJvdmlkZXMgdGhpczsgT0F1dGggbmVlZHMgdGhpcyB0 b28uDQoNCg0KLS0NCkphbWVzIE1hbmdlcg0K --_000_7C01E631FF4B654FA1E783F1C0265F8C4A429748TK5EX14MBXC117r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48 L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9 V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+VGhhbmtzIGZvciBleHBsYWluaW5nLCBJIG5vdyBiZWxpZXZlIEkgdW5kZXJzdGFuZCB0aGUg dXNlIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+QnV0IEkgd291bGQgcG9pbnQg b3V0IHRoYXQgdGhpcyBpcyByZWFsbHkgYW4gdW5zb2x2ZWQgcHJvYmxlbSBpbiBnZW5lcmFsIGFu ZCBpZiB3ZSBhcmUgdG8gdGFja2xlIGl0IHdlIGhhdmUgdG8gZGVhbCB3aXRoIHJlYWwgY29uY2Vy bnMgc3VjaCBhcyDigJMgd2hhdCBoYXBwZW5zIGlmIGluIHRoZSB0aW1lIHNpbmNlIHRoZSBzaXRl IGxpc3Qgd2FzIHByb3ZpZGVkIGFuZCB3aGVuIHRoZSB0b2tlbiB3YXMgdXNlZCB0aGUgbGlzdCB3 YXMgY2hhbmdlZD8gSWYgYW4gYXR0YWNrZXIgbm93IGNvbnRyb2xzIGEgcHJldmlvdXNseSBsaXN0 ZWQgc2l0ZSB0aGVuIHRoZSBhdHRhY2tlciBjYW4ganVzdCBzd2FsbG93IHRoZSBiZWFyZXIgdG9r ZW4gYW5kIGRvIGJhZCB0aGluZ3MuIFNvIG5vdyB3ZSBoYXZlIHRvIHRoaW5rIGFib3V0IGV4cGly YXRpb24gaW5mb3JtYXRpb24gb24gdGhlIHNpdGUgbGlzdCBvciBhIHJldm9jYXRpb24gbWVjaGFu aXNtIG9yIHNvbWUga2luZCBvZiBuZWdvdGlhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz5PbmUgd29uZGVycyBpZiBpdCB3b3VsZG7igJl0IGJlIHNpbXBsZXIgZm9yIGNsaWVudHMg dGhhdCBhcmUgaW4gZG91YnQgdG8ganVzdCBtYWtlIGFub3RoZXIgdG9rZW4gcmVxdWVzdCB0byB0 aGUgb3JpZ2luYWwgc2VydmljZeKAmXMgdG9rZW4gaXNzdWVyIHdpdGggYSBzY29wZSBmb3IgdGhl IGRlc2lyZWQgc2l0ZS4gVGhhdCB3b3JrcyB3aXRoIHRoZSBleGlzdGluZyBwcm90b2NvbCBhbmQg bWl0aWdhdGVzIHRoZSBwcmV2aW91cyBhdHRhY2suPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgSnVzdCBhIHRob3VnaHQsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBZYXJvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBNYW5nZXIsIEphbWVzIEggW21haWx0 bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXSA8YnI+PGI+U2VudDo8L2I+IE1vbmRh eSwgTWF5IDEwLCAyMDEwIDU6MzEgUE08YnI+PGI+VG86PC9iPiBZYXJvbiBHb2xhbmQ7IE9BdXRo IFdHIChvYXV0aEBpZXRmLm9yZyk8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBzaXRlcyB3aXRoIHdp bGRjYXJkPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1B VSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+WWFyb24sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7IDwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SSBkb27igJl0IHVuZGVyc3RhbmQgdGhl IHNjZW5hcmlvIHRoYXQgcmVxdWlyZXMgdGhpcyBmZWF0dXJlLiBXaGVuIGRvZXMgc29tZW9uZSBh c2sgZm9yIGEgdG9rZW4gd2l0aG91dCBrbm93aW5nIHdoZXJlIGl0IGlzIGdvaW5nPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5FeGFtcGxlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHls ZT0nY29sb3I6IzFGNDk3RCc+QSBjbGllbnQgYXBwIGdldHMgYSB0b2tlbiB0byBtYWtlIGFuIEFQ SSBjYWxsIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlIHRoYXQgcmV0dXJucyBhbiBBdG9tIGZlZWQu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFV IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGUgZmVlZCBjb250YWlucyBsb3RzIG9mIGVudHJpZXMs IHdpdGggbGlua3MgdG8gcGhvdG9zLCBzdHlsZSBzaGVldHMsIGFuZCBzY3JpcHRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+VGhlIGNsaWVudCBhcHAgZ2V0cyB0aGUgcGhvdG9zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5TaG91bGQgaXQgc2VuZCB0 aGUgdG9rZW4gd2hlbiBnZXR0aW5nIHRoZSBwaG90b3M/PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQVUgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPk9uIHNlcnZpY2UgQSB0aGUgQXRvbSBmZWVkIGFu ZCB0aGUgcGhvdG9zIGFyZSBhbGwgc2VydmVkIGZyb20gdGhlIHNhbWUgSFRUUFMgaG9zdCwgd2l0 aCB0aGUgc2FtZSBwcm90ZWN0aW9uLCBzbyB0aGUgdG9rZW4gbXVzdCBiZSBzZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5PbiBzZXJ2aWNlIEIg dGhlIHBob3RvcyBhcmUgaG9zdGVkIG9uIGEgc2VwYXJhdGUgb3V0c291cmNlZCBjb250ZW50IGRp c3RyaWJ1dGlvbiBuZXR3b3JrLiBUaGUgcGhvdG9zIGFyZSBwcm90ZWN0ZWQgYnkgdXNpbmcgbG9u ZyB1bmd1ZXNzYWJsZSBVUklzICh0aGUgVVJJcyBhcmUgZWZmZWN0aXZlbHkg4oCcY2FwYWJpbGl0 aWVz4oCdIHRvIHJlYWQgdGhlIHBob3RvcykuIFRoZSB0b2tlbiBkb2VzIG5vdCBuZWVkIHRvIGJl IHNlbnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn Pk9uIHNlcnZpY2UgQyB0aGUgcGhvdG9zIGFyZSBhbnkgaW1hZ2VzIGZyb20gYW55d2hlcmUgb24g dGhlIEludGVybmV0IHRoYXQgdGhlIHVzZXIgaGFzIGNob3NlbiB0byBsaW5rIHRvLiBUaGUgQXRv bSBjb2xsZWN0aW9uIGlzIHByb3RlY3RlZCwgYnV0IG5vdCB0aGUgcGhvdG9zLiBUaGUgdG9rZW4g YWJzb2x1dGVseSBtdXN0IG5vdCBiZSBzZW50IHdoZW4gZ2V0dGluZyB0aGUgcGhvdG9zLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHls ZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPkEgY2xpZW50IGFwcCBuZWVkcyB0byBrbm93IHdoZXRoZXIgdGhl IHNlcnZpY2UgaXQgaXMgYWNjZXNzaW5nIGlzIGxpa2UgQSwgQiwgb3IgQy4gSXQgbmVlZHMgdG8g a25vdyBmb3IgcmVkaXJlY3RzLCBmb3IgbGlua3MgaW4gSFRUUCBoZWFkZXJzLCBmb3IgbGlua3Mg dG8gaW1hZ2VzLCBmb3IgYW55IG90aGVyIHNvcnQgb2YgbGluayB0aGF0IGlzIGNhbiBkZXJpdmUg ZnJvbSB0aGUgcmVzcG9uc2UuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPlNvbWUgc2VydmljZXMgbWlnaHQgYmUgY29tcGxldGVseSB3YWxsZWQgZ2Fy ZGVucyBzbyB0aGUgY2xpZW50IGNhbiBhc3N1bWUgdGhleSBhcmUgbGlrZSBBLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29s b3I6IzFGNDk3RCc+U29tZSBzZXJ2aWNlcyBtaWdodCBleHBsaWNpdGx5IHN0YXRlIGluIHRoZWly IGRvY3VtZW50YXRpb246IHdoaWNoIGxpbmtzIGFuZCByZWRpcmVjdHMgYXJlIGFsd2F5cyBndWFy YW50ZWVkIHRvIGJlIG90aGVyIEFQSSBjYWxscyAoc2VuZCB0aGUgdG9rZW4pOyB3aGljaCB3aWxs IGFsd2F5cyBiZSB0byBvdGhlciBzZWN1cml0eSBjb250ZXh0cyAoZG9u4oCZdCBzZW5kIHRoZSB0 b2tlbik7IGFuZCB3aGljaCBtaWdodCBiZSBlaXRoZXIgKGRvbuKAmXQgc2VuZCB0aGUgdG9rZW4s IHNlZSBpZiB5b3UgZ2V0IGEgNDAxLzQwMywgZ3Vlc3MsIHNlbmQgdGhlIHRva2VuKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1BVSBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SW4gZ2VuZXJhbCwg dGhlIHdlYiBpcyBhYm91dCBmb2xsb3dpbmcgbGlua3MuIENsaWVudHMgbmVlZCB0byBrbm93IHdo ZW4gZm9sbG93aW5nIGEgbGluayBjcm9zc2VzIGEgc2VjdXJpdHkgYm91bmRhcnkuIENvb2tpZXMg cHJvdmlkZSB0aGlzOyBCYXNpYyBwcm92aWRlcyB0aGlzOyBEaWdlc3QgcHJvdmlkZXMgdGhpczsg T0F1dGggbmVlZHMgdGhpcyB0b28uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4tLSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_7C01E631FF4B654FA1E783F1C0265F8C4A429748TK5EX14MBXC117r_-- From eran@hueniverse.com Tue May 11 16:36:10 2010 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 6F1BE3A699E for ; Tue, 11 May 2010 16:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.764, 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 iQJc95lYQxSx for ; Tue, 11 May 2010 16:36: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 3DAAA3A69A1 for ; Tue, 11 May 2010 16:36:07 -0700 (PDT) Received: (qmail 6845 invoked from network); 11 May 2010 23:35:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 May 2010 23:35:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 11 May 2010 16:35:54 -0700 From: Eran Hammer-Lahav To: Yaron Goland , "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Tue, 11 May 2010 16:36:01 -0700 Thread-Topic: sites with wildcard Thread-Index: AcrwTaPsC4ggYQawSQ6EnsB9Iie0cQATPiVwAAA9JoAAMWf8oAAASw0w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47460@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A429748@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A429748@TK5EX14MBXC117.redmond.corp.microsoft.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] sites with wildcard 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, 11 May 2010 23:36:10 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBZ YXJvbiBHb2xhbmQNCj4gU2VudDogVHVlc2RheSwgTWF5IDExLCAyMDEwIDQ6MjkgUE0NCj4gVG86 IE1hbmdlciwgSmFtZXMgSDsgT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBzaXRlcyB3aXRoIHdpbGRjYXJkDQo+IA0KPiBUaGFua3MgZm9yIGV4cGxh aW5pbmcsIEkgbm93IGJlbGlldmUgSSB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZS4NCj4gDQo+IEJ1 dCBJIHdvdWxkIHBvaW50IG91dCB0aGF0IHRoaXMgaXMgcmVhbGx5IGFuIHVuc29sdmVkIHByb2Js ZW0gaW4gZ2VuZXJhbCBhbmQgaWYNCj4gd2UgYXJlIHRvIHRhY2tsZSBpdCB3ZSBoYXZlIHRvIGRl YWwgd2l0aCByZWFsIGNvbmNlcm5zIHN1Y2ggYXMg4oCTIHdoYXQgaGFwcGVucw0KPiBpZiBpbiB0 aGUgdGltZSBzaW5jZSB0aGUgc2l0ZSBsaXN0IHdhcyBwcm92aWRlZCBhbmQgd2hlbiB0aGUgdG9r ZW4gd2FzIHVzZWQNCj4gdGhlIGxpc3Qgd2FzIGNoYW5nZWQ/IElmIGFuIGF0dGFja2VyIG5vdyBj b250cm9scyBhIHByZXZpb3VzbHkgbGlzdGVkIHNpdGUgdGhlbg0KPiB0aGUgYXR0YWNrZXIgY2Fu IGp1c3Qgc3dhbGxvdyB0aGUgYmVhcmVyIHRva2VuIGFuZCBkbyBiYWQgdGhpbmdzLiBTbyBub3cg d2UNCj4gaGF2ZSB0byB0aGluayBhYm91dCBleHBpcmF0aW9uIGluZm9ybWF0aW9uIG9uIHRoZSBz aXRlIGxpc3Qgb3IgYSByZXZvY2F0aW9uDQo+IG1lY2hhbmlzbSBvciBzb21lIGtpbmQgb2YgbmVn b3RpYXRpb24uDQoNClRva2VucyBjYW4gYmUgc2hvcnQgbGl2ZWQgLSB0aGF0J3Mgd2h5IHdlIGhh dmUgcmVmcmVzaCB0b2tlbnMuIEFuZCBpZiB0aGVyZSBpcyBhIGNoYW5jZSBvZiB0aGUgc2l0ZXMg bGlzdCBjaGFuZ2luZywgdGhlIHRva2VucyBzaG91bGQgbm90IGJlIGlzc3VlZCB0byBvdmVybGFw IHdpdGggc3VjaCBhIGNoYW5nZS4gQnV0IGluIGdlbmVyYWwsIHRoaXMgaXMgcmVhbGx5IG5vdCBh IHJlYWwgY29uY2VybiBpbiBhbnkgcHJvZHVjdGlvbiBlbnZpcm9ubWVudCB3aGVyZSBwZW9wbGUg bG9zZSBjb250cm9sIG92ZXIgdGhlaXIgZG9tYWluIG5hbWVzIGluIHN1Y2ggYSB0aW1lZnJhbWUu DQoNCj4gT25lIHdvbmRlcnMgaWYgaXQgd291bGRu4oCZdCBiZSBzaW1wbGVyIGZvciBjbGllbnRz IHRoYXQgYXJlIGluIGRvdWJ0IHRvIGp1c3QNCj4gbWFrZSBhbm90aGVyIHRva2VuIHJlcXVlc3Qg dG8gdGhlIG9yaWdpbmFsIHNlcnZpY2XigJlzIHRva2VuIGlzc3VlciB3aXRoIGENCj4gc2NvcGUg Zm9yIHRoZSBkZXNpcmVkIHNpdGUuIFRoYXQgd29ya3Mgd2l0aCB0aGUgZXhpc3RpbmcgcHJvdG9j b2wgYW5kDQo+IG1pdGlnYXRlcyB0aGUgcHJldmlvdXMgYXR0YWNrLg0KDQpUaGF0J3MgYSB2ZXJ5 IGJhZCB1c2VyIGV4cGVyaWVuY2UgKGhhdmluZyB0byBncmFuZCBhY2Nlc3MgYWdhaW4gZm9yIHRo ZSBzYW1lIGNsaWVudCksIGFzc3VtaW5nIHRoZXJlIGV2ZW4gaXMgYSB1c2VyIHRvIGJ1ZyBhYm91 dCBhdXRob3JpemF0aW9uLg0KDQpFSEwNCg== From eran@hueniverse.com Tue May 11 16:37:25 2010 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 3357C3A6934 for ; Tue, 11 May 2010 16:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 eq4jE2A1I4CW for ; Tue, 11 May 2010 16:37: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 68FA93A68BF for ; Tue, 11 May 2010 16:37:23 -0700 (PDT) Received: (qmail 23755 invoked from network); 11 May 2010 23:37:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 May 2010 23:37:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 11 May 2010 16:36:42 -0700 From: Eran Hammer-Lahav To: Yaron Goland , Torsten Lodderstedt Date: Tue, 11 May 2010 16:36:51 -0700 Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: AQHK8M2JqAP3Yhb/w06D/QdCD+DPKpJMuIJQgAAreAA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47465@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> <4BE8EF51.1070305@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A4296A0@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A4296A0@TK5EX14MBXC117.redmond.corp.microsoft.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 11 May 2010 23:37:25 -0000 No one was suggesting putting the assertion in the header. Just the client = credentials... EHL > -----Original Message----- > From: Yaron Goland [mailto:yarong@microsoft.com] > Sent: Tuesday, May 11, 2010 4:24 PM > To: Torsten Lodderstedt > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > Actually it's server side that's the problem. Many servers limit the size= of the > HTTP request headers they will accept. Apache 2.2, for example, uses the > LimitRequestFieldSize Directive > (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is 819= 0 > bytes. IIS, I Believe, defaults to around 16K. But SAML assertions can ea= sily > clock in at 30 or 40k without even trying. >=20 > So as a practical matter we need a way to allow clients to assert their r= ight to > a token using the request body so as to not need to artificially limit th= e size of > the token that is being submitted. >=20 > Yaron >=20 > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Monday, May 10, 2010 10:47 PM > > To: Yaron Goland > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > > > Am 11.05.2010 01:43, schrieb Yaron Goland: > > > > > >> --- > > >> > > >> 2. Client Authentication (in flows) > > >> > > >> How should the client authenticate when making token requests? The > > >> current draft defines special request parameters for sending client > > >> credentials. Some have argued that this is not the correct way, and > > >> that the client should be using existing HTTP authentication > > >> schemes to accomplish that such as Basic. > > >> > > >> A. Client authenticates by sending its credentials using special > > >> parameters (current draft) B. Client authenticated by using HTTP > > >> Basic (or other schemes supported by the server such as Digest) > > >> > > >> > > > [Yaron Goland] A is needed at a minimum because there are physical > > limitations to how many bytes can go into an authorization header. > > > > > > > As far as I know, 4KB is the minimum size for headers that must be > > supported by user agents, which should suffice from my point of view. > > Moreover, other HTTP authentication mechanisms need much more than > > 4KB, For example, SPNEGO authentication headers can be up to 12392 > bytes. > > > > regards, > > Torsten. > > > > >> _______________________________________________ > > >> 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 May 11 16:42:48 2010 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 E982D3A6A18 for ; Tue, 11 May 2010 16:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 fW7y12Hp-BE8 for ; Tue, 11 May 2010 16:42:48 -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 1439E3A68BF for ; Tue, 11 May 2010 16:42:48 -0700 (PDT) Received: (qmail 8908 invoked from network); 11 May 2010 23:42:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 May 2010 23:42:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 11 May 2010 16:42:37 -0700 From: Eran Hammer-Lahav To: Yaron Goland , Brian Eaton Date: Tue, 11 May 2010 16:42:45 -0700 Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AQHK8SWhrXmdu8iAMU+K7OlC4RFdKJJM94eAgAAA+QCAAAMEgIAACfCA///WI1CAAAfr8A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4746D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB472B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB472D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A429608@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A429608@TK5EX14MBXC117.redmond.corp.microsoft.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 11 May 2010 23:42:49 -0000 We should strive to do as much as rough consensus allows. The way we decide= what's in scope is by discussing it until we reach a mature proposal. Obje= ctions must always come with a technical argument why the proposal is bad. All specs include features that are a little bit experimental (in OAuth 1.0= it was Google's demand for RSA support). There is nothing wrong with that = as long as the core (and required) parts are well specified. People are here for many reasons. EHL > -----Original Message----- > From: Yaron Goland [mailto:yarong@microsoft.com] > Sent: Tuesday, May 11, 2010 4:10 PM > To: Brian Eaton; Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] sites with wildcard >=20 > Limited views on what a protocol is far tend to produce protocols that ar= e > actually interoperable. We should strive to do as little as possible in t= he > standard and make sure we do a great job leaving the door open to later > extensions. >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Brian Eaton > > Sent: Tuesday, May 11, 2010 11:39 AM > > To: Eran Hammer-Lahav > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] sites with wildcard > > > > On Tue, May 11, 2010 at 11:03 AM, Eran Hammer-Lahav > > wrote: > > > That's a pretty limited view on what OAuth 2.0 is for. > > > > It it what has brought a large community into this mailing list. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Tue May 11 17:31:05 2010 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 660153A688C for ; Tue, 11 May 2010 17:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnNax7EmJS5n for ; Tue, 11 May 2010 17:31:04 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 633613A6C18 for ; Tue, 11 May 2010 17:31:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,210,1272808800"; d="scan'208";a="2473120" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 12 May 2010 10:30:48 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5979"; a="1791560" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 12 May 2010 10:30:49 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 12 May 2010 10:30:48 +1000 From: "Manger, James H" To: Marius Scurtescu Date: Wed, 12 May 2010 10:30:47 +1000 Thread-Topic: [OAUTH-WG] SWT for indicating sites where a token is valid Thread-Index: AcrxNovgwHx2+CJ0R7KPmX4n0FIfBgAJkobA Message-ID: <255B9BB34FB7D647A506DC292726F6E112633147DC@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112631B2989@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1126328511A@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1126328531E@WSMSG3153V.srv.dir.telstra.com> 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 Cc: OAuth WG Subject: Re: [OAUTH-WG] SWT for indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 00:31:05 -0000 TWFyaXVzLA0KDQo+IElmIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2Ugc2VuZHMgYSByZWRpcmVjdCBp bnN0ZWFkIG9mIHNlcnZpbmcgdGhlDQo+IHJlc291cmNlIHRoZW4gcHJvYmFibHkgaXQga25vd3Mg d2hhdCBpdCBpcyBkb2luZy4NCg0KU3VyZSwgdGhlIHNlcnZlciBrbm93cyB3aGF0IGl0IGlzIGRv aW5nLiBIb3dldmVyIGl0IGlzIGNvbXBsZXRlbHkgbGVnaXRpbWF0ZSBmb3IgYSBzZXJ2ZXIgdG8g a25vd2luZ2x5IHJlZGlyZWN0IHRvIGFuIGV4dGVybmFsIHNpdGUsIHRvIGEgc2l0ZSBjb25maWd1 cmVkIGJ5IGEgdXNlciwgdG8gYSBzaXRlIG1hdGNoaW5nIGEgc2VhcmNoIHRlcm0gZXRjLg0KVGhl IHNlcnZlciBrbm93cyB3aGV0aGVyIGEgcmVkaXJlY3QgKG9yIGxpbmspIG1pZ2h0IGNyb3NzIGEg c2VjdXJpdHkgYm91bmRhcnksIGJ1dCB0aGUgaXNzdWUgaXMgaG93IGRvZXMgdGhlIGNsaWVudCBr bm93Lg0KDQoNCj4gRm9sbG93aW5nIGxpbmtzLCBob3cgZG8geW91IHNlZSB0aGF0IGhhcHBlbmlu Zz8gTm9ybWFsbHkgYSBjbGllbnQgd2lsbA0KPiBub3QgZm9sbG93IGxpbmtzIHdpdGhvdXQgdW5k ZXJzdGFuZGluZyB0aGVtIGFuZCBhdCB0aGUgc2FtZSB0aW1lIHNlbmQNCj4gYWNjZXNzIHRva2Vu cy4NCg0KQSBjbGllbnQgYXBwIHVuZGVyc3RhbmRzIHRoYXTigJlzIGEgVVJJIGluIGFuIDxpbWc+ IHRhZyBvciBhIEZhY2Vib29rICJwaG90b3MiIGxpbmsgc2hvdWxkIGxlYWQgdG8gYW4gaW1hZ2Uu IEl0IGlzIGZhciBsZXNzIG9idmlvdXMgd2hhdCB0aGUgc2VjdXJpdHkgY29udGV4dCBmb3IgdGhh dCBpbWFnZSBpczogaXMgaXQgcGFydCBvZiB0aGUgc2FtZSBBUEksIG9yIGFuIGFyYml0cmFyeSBp bWFnZSBvbiB0aGUgSW50ZXJuZXQuDQoNCg0KPj4gInNpdGVzIiBkb2VzIGhlbHAuIElmIGl0cyB2 YWx1ZSB3YXM6DQo+PiDCoCJzaXRlcyI6IFsiaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20iLCAiaHR0 cHM6Ly9pbWcuZXhhbXBsZS5jb20iXQ0KPj4gVGhlbiBubyBIVFRQIFVSSSBtYXRjaGVzIHNvIHRo ZSB0b2tlbiBpcyBuZXZlciBzZW50IGluIHRoZSBjbGVhci4NCg0KPiBZZXMsIGJ1dCBIVFRQIGFu ZCBXSUZJIGNhbiBjb21wcm9taXNlIHRva2VucyBldmVuIGlmIHNlbnQgdG8gdGhlDQo+IHByb3Bl ciBzaXRlcy4gUmlnaHQ/DQoNClllcywgYnV0IG9ubHkgaWYgdGhlIHNlcnZlciBleHBsaWNpdGx5 IGRlY2lkZWQgdGhhdCBwYXJ0aWN1bGFyIHRva2VuIHdhcyBzdWl0YWJsZSBmb3Igc2VuZGluZyBp biB0aGUgY2xlYXIgYW5kIGV4cGxpY2l0bHkgdG9sZCB0aGUgY2xpZW50IHNvIGJ5IGluY2x1ZGlu ZyBhbiBIVFRQIHN0cmluZyBpbiB0aGUgInNpdGVzIiBmaWVsZC4NCg0KDQpNYXJpdXMNCg== From James.H.Manger@team.telstra.com Tue May 11 17:37:41 2010 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 B27AC3A6C17 for ; Tue, 11 May 2010 17:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpdhXPwR-b1q for ; Tue, 11 May 2010 17:37:41 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id BEC7E3A6AA9 for ; Tue, 11 May 2010 17:37:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,211,1272808800"; d="scan'208";a="2409468" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 12 May 2010 10:37:29 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5979"; a="1852512" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccni.tcif.telstra.com.au with ESMTP; 12 May 2010 10:37:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Wed, 12 May 2010 10:37:29 +1000 From: "Manger, James H" To: Marius Scurtescu Date: Wed, 12 May 2010 10:37:28 +1000 Thread-Topic: [OAUTH-WG] sites with wildcard Thread-Index: AcrxTp4R75RGHWaDSkyk+W911icGYQAHCSkw Message-ID: <255B9BB34FB7D647A506DC292726F6E1126331480A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> 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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 12 May 2010 00:37:41 -0000 TWFyaXVzLA0KDQo+PiBTaG91bGQgaXQgc2VuZCB0aGUgdG9rZW4gd2hlbiBnZXR0aW5nIHRoZSBw aG90b3M/DQoNCj4gSSB3b3VsZCBzYXkgZGVmaW5pdGVseSBub3QuIElmIHRoZSBjbGllbnQgZ2V0 cyBiYWNrIGEgNDAzIHdpdGgNCj4gZGlzY292ZXJ5IGluZm8gdGhhdCBwb2ludHMgdG8gdGhlIHNh bWUgYXV0aHogc2VydmVyIGFuZCBhcHByb3ZlZA0KPiBzY29wZXMsIG9ubHkgdGhlbiBjb3VsZCB0 aGUgY2xpZW50IHJlLXRyeSB3aXRoIGEgdG9rZW4uDQoNCj4gV291bGQgdGhhdCB3b3JrPw0KDQpO by4gVGhhdCB3b3VsZCBiZSB0b3RhbGx5IGluc2VjdXJlLg0KDQpBbnkgc2l0ZSBjYW4gcmV0dXJu IGEgNDAzIGFuZCBsaXN0LCBzYXksIEdvb2dsZSBhcyBpdHMgYXV0aHogc2VydmVyIHNvIGFueSBz aXRlIChnb29kIG9yIGJhZCkgY291bGQgZ2V0IGEgY2xpZW50IHRvIHJldmVhbCBpdHMgR29vZ2xl IHRva2VuLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From Axel.Nennker@telekom.de Tue May 11 23:22:59 2010 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 4CC273A6C92 for ; Tue, 11 May 2010 23:22:59 -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 hU3QUTj3yQ+g for ; Tue, 11 May 2010 23:22:57 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id D488C3A6AD8 for ; Tue, 11 May 2010 23:22:29 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 12 May 2010 08:22:10 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 08:22:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 08:22:09 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <20100510054516.2957E3A6B0C@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt thread-index: AcrwBFKu+ANEbvvIR66deCjdPs8ImQBlv6Eg References: <20100510054516.2957E3A6B0C@core3.amsl.com> From: To: X-OriginalArrivalTime: 12 May 2010 06:22:10.0498 (UTC) FILETIME=[742F9220:01CAF19B] Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 06:22:59 -0000 I suggest a change to=20 "3.4. Client Credentials When requesting access from the authorization server, the client identifies itself using a set of client credentials. The client credentials include a client identifier and an OPTIONAL symmetric shared secret. The means through which the client obtains these credentials are beyond the scope of this specification, but usually involve registration with the authorization server." I don't like the "symmetric shared secret" and would like this to be "beyond the scope of this spec". I suggest to change that paragraph e.g. to: "3.4. Client Credentials When requesting access from the authorization server, the client authenticates itself using its credentials. The type of credentials is beyond the scope of this specification. The means through which=20 the client obtains these credentials are beyond the scope of this=20 specification, but usually involve registration with the=20 authorization server." -Axel Ps. If the client has an e.g. RSA-keypair then it could use the private key to sign the request and thereby authenticate itself. The public key would need to be exchanged before out-of-band. Or it could be a certificate that is e.g. issued by the authorization server or a party that the authorization server trusts. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, May 10, 2010 7:45 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-04.txt Pages : 51 Date : 2010-05-09 This specification describes the OAuth 2.0 protocol. OAuth provides a method for making authenticated HTTP requests using a token - an identifier used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From eran@hueniverse.com Tue May 11 23:26:11 2010 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 847353A6C8F for ; Tue, 11 May 2010 23:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 L6muUJBJrgas for ; Tue, 11 May 2010 23:26:10 -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 0FE3828C1BE for ; Tue, 11 May 2010 23:25:22 -0700 (PDT) Received: (qmail 7040 invoked from network); 12 May 2010 06:25:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 May 2010 06:25:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 11 May 2010 23:25:02 -0700 From: Eran Hammer-Lahav To: "Axel.Nennker@telekom.de" , "oauth@ietf.org" Date: Tue, 11 May 2010 23:25:10 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt Thread-Index: AcrwBFKu+ANEbvvIR66deCjdPs8ImQBlv6EgAAAazhA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> 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] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 06:26:11 -0000 But it is not beyond the scope. We define a parameter just for that called = client_secret. If you want to use something else, you need to define an ext= ension that replaces that with something else. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Axel.Nennker@telekom.de > Sent: Tuesday, May 11, 2010 11:22 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > I suggest a change to >=20 > "3.4. Client Credentials >=20 > When requesting access from the authorization server, the client > identifies itself using a set of client credentials. The client > credentials include a client identifier and an OPTIONAL symmetric > shared secret. The means through which the client obtains these > credentials are beyond the scope of this specification, but usually > involve registration with the authorization server." >=20 > I don't like the "symmetric shared secret" and would like this to be "bey= ond > the scope of this spec". >=20 > I suggest to change that paragraph e.g. to: >=20 > "3.4. Client Credentials >=20 > When requesting access from the authorization server, the client > authenticates itself using its credentials. The type of credentials > is beyond the scope of this specification. The means through which > the client obtains these credentials are beyond the scope of this > specification, but usually involve registration with the > authorization server." >=20 > -Axel >=20 > Ps. > If the client has an e.g. RSA-keypair then it could use the private key t= o sign > the request and thereby authenticate itself. > The public key would need to be exchanged before out-of-band. Or it could > be a certificate that is e.g. issued by the authorization server or a par= ty that > the authorization server trusts. >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Monday, May 10, 2010 7:45 AM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Open Authentication Protocol Working Gro= up > of the IETF. >=20 >=20 > Title : The OAuth 2.0 Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-04.txt > Pages : 51 > Date : 2010-05-09 >=20 > This specification describes the OAuth 2.0 protocol. OAuth provides a > method for making authenticated HTTP requests using a token - an identifi= er > used to denote an access grant with specific scope, duration, and other > attributes. Tokens are issued to third-party clients by an authorization= server > with the approval of the resource owner. OAuth defines multiple flows fo= r > obtaining a token to support a wide range of client types and user > experience. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From recordond@gmail.com Tue May 11 23:30:04 2010 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 637583A6AD8 for ; Tue, 11 May 2010 23:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.352, 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 1aWfLCFulZ4o for ; Tue, 11 May 2010 23:30:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D2DDE3A6AF0 for ; Tue, 11 May 2010 23:30:02 -0700 (PDT) Received: by gyh4 with SMTP id 4so3352094gyh.31 for ; Tue, 11 May 2010 23:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=crmCZ/95RsWI7P20FCwD4uPsETdkpJTn+gdPdLzo9vE=; b=TdyhW6AVatqbHqnD3Cxu3I0YgIoN8hPrw3bvgg0PkCUXZ/vGH/wrbNEUI0mIHX2rG+ NFkCd5LhFABdMnjoxaQvTWGCFuOHFYvsjLwHB/DVk/f5cD7Wvyg34pWJQu/DCnHwnrbK huVMGCDTHI91sObpd6qS3gQXxWrJyaJwQtNYk= 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=uQiK0motDBhYWmZsoEBjt5ChqOrAZhaEloxXEYcBoIQSi6y75lb+s2VFTqqRWF7SOq M4b2AdJuvDH/hcA/YY5cYgZIykPgdjZhRj1OCH2xHP6j26IQ8PEfwfGn4VbCVt6zCoBf jXeoCBKHvxJGSPPbg3iNjnKSrWbb0bXogZnE4= MIME-Version: 1.0 Received: by 10.101.182.34 with SMTP id j34mr3519218anp.262.1273645789722; Tue, 11 May 2010 23:29:49 -0700 (PDT) Received: by 10.100.248.11 with HTTP; Tue, 11 May 2010 23:29:49 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 May 2010 23:29:49 -0700 Message-ID: From: David Recordon To: "Axel.Nennker@telekom.de" , Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 06:30:04 -0000 Yes, the Client authenticating using a RSA key pair seems like it should be a different flow. On Tue, May 11, 2010 at 11:25 PM, Eran Hammer-Lahav w= rote: > But it is not beyond the scope. We define a parameter just for that calle= d client_secret. If you want to use something else, you need to define an e= xtension that replaces that with something else. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Axel.Nennker@telekom.de >> Sent: Tuesday, May 11, 2010 11:22 PM >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >> >> I suggest a change to >> >> "3.4. =A0Client Credentials >> >> =A0 =A0When requesting access from the authorization server, the client >> =A0 =A0identifies itself using a set of client credentials. =A0The clien= t >> =A0 =A0credentials include a client identifier and an OPTIONAL symmetric >> =A0 =A0shared secret. =A0The means through which the client obtains thes= e >> =A0 =A0credentials are beyond the scope of this specification, but usual= ly >> =A0 =A0involve registration with the authorization server." >> >> I don't like the "symmetric shared secret" and would like this to be "be= yond >> the scope of this spec". >> >> I suggest to change that paragraph e.g. to: >> >> "3.4. =A0Client Credentials >> >> =A0 =A0When requesting access from the authorization server, the client >> =A0 =A0authenticates itself using its credentials. The type of credentia= ls >> =A0 =A0is beyond the scope of this specification. The means through whic= h >> =A0 =A0the client obtains these credentials are beyond the scope of this >> =A0 =A0specification, but usually involve registration with the >> =A0 =A0authorization server." >> >> -Axel >> >> Ps. >> If the client has an e.g. RSA-keypair then it could use the private key = to sign >> the request and thereby authenticate itself. >> The public key would need to be exchanged before out-of-band. Or it coul= d >> be a certificate that is e.g. issued by the authorization server or a pa= rty that >> the authorization server trusts. >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Internet-Drafts@ietf.org >> Sent: Monday, May 10, 2010 7:45 AM >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Open Authentication Protocol Working Gr= oup >> of the IETF. >> >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The OAuth 2.0 Protocol >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : E. Hammer-Lahav, et al. >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-v2-04.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 51 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-09 >> >> This specification describes the OAuth 2.0 protocol. =A0OAuth provides a >> method for making authenticated HTTP requests using a token - an identif= ier >> used to denote an access grant with specific scope, duration, and other >> attributes. =A0Tokens are issued to third-party clients by an authorizat= ion server >> with the approval of the resource owner. =A0OAuth defines multiple flows= for >> obtaining a token to support a wide range of client types and user >> experience. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the Intern= et- >> Draft. >> _______________________________________________ >> 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 lshepard@facebook.com Tue May 11 23:33:43 2010 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 2940F28C17C for ; Tue, 11 May 2010 23:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 T+a4Gbkg8eSS for ; Tue, 11 May 2010 23:33:42 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 349A628C103 for ; Tue, 11 May 2010 23:33:42 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4C6X5SQ004299 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 May 2010 23:33:06 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub02.TheFacebook.com (192.168.18.105) with Microsoft SMTP Server (TLS) id 8.2.213.0; Tue, 11 May 2010 23:32:00 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Tue, 11 May 2010 23:32:00 -0700 From: Luke Shepard To: Marius Scurtescu Date: Tue, 11 May 2010 23:31:58 -0700 Thread-Topic: [OAUTH-WG] Strict equality matching of redirect_uri Thread-Index: AcrxnNNJ75xjd+NWSXSaNhzf5qjFDg== Message-ID: References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-12_01:2010-02-06, 2010-05-12, 2010-05-11 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri 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, 12 May 2010 06:33:43 -0000 FWIW, Facebook does not do strict equality matching on redirect_uri. We acc= ept any redirect_uri that has either: - its prefix is the registered url - or it is a special facebook.com/xd_proxy.php url, with an origin paramete= r that has a prefix on the registered url I think that the spec should leave the matching up to the server. On May 11, 2010, at 3:13 PM, Marius Scurtescu wrote: > On Tue, May 11, 2010 at 3:04 PM, Evan Gilbert wrote: >>=20 >> On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu >> wrote: >>>=20 >>> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav >>> wrote: >>>>=20 >>>>> -----Original Message----- >>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>>> Sent: Sunday, May 09, 2010 5:52 PM >>>>=20 >>>>>>> 3.5.1. Client Requests Authorization >>>>>>>=20 >>>>>>> If the client has previously registered a redirection URI with the >>>>>>> authorization server, the authorization server MUST verify that >>>>>>> the >>>>>>> redirection URI received matches the registered URI associated >>>>>>> with >>>>>>> the client identifier. >>>>>>>=20 >>>>>>> Does this mean equality? Or just the same base string? >>>>>>=20 >>>>>> Right now it depends on the server. >>>>>=20 >>>>> The spec should clarify that. Suggested wording: >>>>>=20 >>>>>=20 >>>>> If the client has previously registered a redirection URI with the >>>>> authorization >>>>> server, the authorization server MUST verify that the redirection URI >>>>> received matches the registered URI associated with the client >>>>> identifier. The >>>>> components of the redirection URI that must match the registered URI = is >>>>> authorization server dependant. >>>>=20 >>>> I don't see how that helps... I also don't see why we can't just profi= le >>>> this and decide on how the matching should be done. We have the state >>>> parameter to help too. >>>=20 >>> I also think the spec should specify how the matching should be done. >>>=20 >>> If left up to the authz server then a client that designs its OAuth 2 >>> implementation will have to assume that all authz servers will do >>> strict equality matching, otherwise it may not be able to interact >>> with some servers. >>>=20 >>> For example, if the client assumes that it can use load balancing by >>> varying the first part of the host name, and this may work with the >>> fist authz server it integrate with, later this client will not be >>> able to interact with an authz server which does strict matching on >>> host name. And changing the load balancing architecture once deployed >>> could be very hard. >>>=20 >>> Since there is a state parameter maybe it is enough to allow wild >>> cards only in the domain name of the callback URI. >>=20 >> I think this we should leave this matching undefined for now - since you >> have to preregister with every site, you will have provider-specific log= ic >> anyway. This will be much more important when we have a discovery mechan= ism >> for callback URLs. >=20 > If we leave undefined then that is the same as enforcing strict > equality matching. Then let's make that explicit. Are we OK with that? >=20 > A client that eventually wants to interact with several authz servers > will have to assume the "greatest common divisor", which is strict > matching. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From raffi@twitter.com Tue May 11 23:40:13 2010 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 BD0DF3A6C94 for ; Tue, 11 May 2010 23:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 2TtF83o2TJ1q for ; Tue, 11 May 2010 23:40:12 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 972EC3A6C9A for ; Tue, 11 May 2010 23:40:05 -0700 (PDT) Received: by pxi19 with SMTP id 19so3100513pxi.31 for ; Tue, 11 May 2010 23:39:52 -0700 (PDT) Received: by 10.140.255.14 with SMTP id c14mr4641691rvi.270.1273646392172; Tue, 11 May 2010 23:39:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.144.9 with HTTP; Tue, 11 May 2010 23:39:31 -0700 (PDT) In-Reply-To: References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Raffi Krikorian Date: Wed, 12 May 2010 07:39:31 +0100 Message-ID: To: Luke Shepard Content-Type: multipart/alternative; boundary=000e0cd108dcc6895604865fe878 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri 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, 12 May 2010 06:40:13 -0000 --000e0cd108dcc6895604865fe878 Content-Type: text/plain; charset=ISO-8859-1 twitter is working on a version where we will actually allow the specification of an explicit array of registered URIs, and we do strict matching against the elements of that array to see if any match. we thought of allowing just subdomain globbing and wildcards, but that seemed problematic for GAE like situations.... On Wed, May 12, 2010 at 7:31 AM, Luke Shepard wrote: > FWIW, Facebook does not do strict equality matching on redirect_uri. We > accept any redirect_uri that has either: > > - its prefix is the registered url > - or it is a special facebook.com/xd_proxy.php url, with an origin > parameter that has a prefix on the registered url > > I think that the spec should leave the matching up to the server. > > On May 11, 2010, at 3:13 PM, Marius Scurtescu wrote: > > > On Tue, May 11, 2010 at 3:04 PM, Evan Gilbert wrote: > >> > >> On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu < > mscurtescu@google.com> > >> wrote: > >>> > >>> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav < > eran@hueniverse.com> > >>> wrote: > >>>> > >>>>> -----Original Message----- > >>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >>>>> Sent: Sunday, May 09, 2010 5:52 PM > >>>> > >>>>>>> 3.5.1. Client Requests Authorization > >>>>>>> > >>>>>>> If the client has previously registered a redirection URI with the > >>>>>>> authorization server, the authorization server MUST verify that > >>>>>>> the > >>>>>>> redirection URI received matches the registered URI associated > >>>>>>> with > >>>>>>> the client identifier. > >>>>>>> > >>>>>>> Does this mean equality? Or just the same base string? > >>>>>> > >>>>>> Right now it depends on the server. > >>>>> > >>>>> The spec should clarify that. Suggested wording: > >>>>> > >>>>> > >>>>> If the client has previously registered a redirection URI with the > >>>>> authorization > >>>>> server, the authorization server MUST verify that the redirection URI > >>>>> received matches the registered URI associated with the client > >>>>> identifier. The > >>>>> components of the redirection URI that must match the registered URI > is > >>>>> authorization server dependant. > >>>> > >>>> I don't see how that helps... I also don't see why we can't just > profile > >>>> this and decide on how the matching should be done. We have the state > >>>> parameter to help too. > >>> > >>> I also think the spec should specify how the matching should be done. > >>> > >>> If left up to the authz server then a client that designs its OAuth 2 > >>> implementation will have to assume that all authz servers will do > >>> strict equality matching, otherwise it may not be able to interact > >>> with some servers. > >>> > >>> For example, if the client assumes that it can use load balancing by > >>> varying the first part of the host name, and this may work with the > >>> fist authz server it integrate with, later this client will not be > >>> able to interact with an authz server which does strict matching on > >>> host name. And changing the load balancing architecture once deployed > >>> could be very hard. > >>> > >>> Since there is a state parameter maybe it is enough to allow wild > >>> cards only in the domain name of the callback URI. > >> > >> I think this we should leave this matching undefined for now - since you > >> have to preregister with every site, you will have provider-specific > logic > >> anyway. This will be much more important when we have a discovery > mechanism > >> for callback URLs. > > > > If we leave undefined then that is the same as enforcing strict > > equality matching. Then let's make that explicit. Are we OK with that? > > > > A client that eventually wants to interact with several authz servers > > will have to assume the "greatest common divisor", which is strict > > matching. > > > > Marius > > _______________________________________________ > > 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 > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi --000e0cd108dcc6895604865fe878 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable twitter is working on a version where we will actually allow the specificat= ion of an explicit array of registered URIs, and we do strict matching agai= nst the elements of that array to see if any match. =A0we thought of allowi= ng just subdomain globbing and wildcards, but that seemed problematic for G= AE like situations....

On Wed, May 12, 2010 at 7:31 AM, Luke Shepar= d <lshepard@f= acebook.com> wrote:
FWIW, Facebook does not do strict equality matching on redirect_uri. We acc= ept any redirect_uri that has either:

- its prefix is the registered url
- or it is a special facebook.com/xd_proxy.php url, with an origin parameter that h= as a prefix on the registered url

I think that the spec should leave the matching up to the server.

On May 11, 2010, at 3:13 PM, Marius Scurtescu wrote:

> On Tue, May 11, 2010 at 3:04 PM, Evan Gilbert <uidude@google.com> wrote:
>>
>> On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu <mscurtescu@google.com>
>> wrote:
>>>
>>> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav <eran@hueniverse.com>
>>> wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com]
>>>>> Sent: Sunday, May 09, 2010 5:52 PM
>>>>
>>>>>>> 3.5.1. =A0Client Requests Authorization
>>>>>>>
>>>>>>> If the client has previously registered a redi= rection URI with the
>>>>>>> =A0 =A0authorization server, the authorization= server MUST verify that
>>>>>>> the
>>>>>>> =A0 =A0redirection URI received matches the re= gistered URI associated
>>>>>>> with
>>>>>>> =A0 =A0the client identifier.
>>>>>>>
>>>>>>> Does this mean equality? Or just the same base= string?
>>>>>>
>>>>>> Right now it depends on the server.
>>>>>
>>>>> The spec should clarify that. Suggested wording:
>>>>>
>>>>>
>>>>> If the client has previously registered a redirection = URI with the
>>>>> authorization
>>>>> server, the authorization server MUST verify that the = redirection URI
>>>>> received matches the registered URI associated with th= e client
>>>>> identifier. The
>>>>> components of the redirection URI that must match the = registered URI is
>>>>> authorization server dependant.
>>>>
>>>> I don't see how that helps... I also don't see why= we can't just profile
>>>> this and decide on how the matching should be done. We hav= e the state
>>>> parameter to help too.
>>>
>>> I also think the spec should specify how the matching should b= e done.
>>>
>>> If left up to the authz server then a client that designs its = OAuth 2
>>> implementation will have to assume that all authz servers will= do
>>> strict equality matching, otherwise it may not be able to inte= ract
>>> with some servers.
>>>
>>> For example, if the client assumes that it can use load balanc= ing by
>>> varying the first part of the host name, and this may work wit= h the
>>> fist authz server it integrate with, later this client will no= t be
>>> able to interact with an authz server which does strict matchi= ng on
>>> host name. And changing the load balancing architecture once d= eployed
>>> could be very hard.
>>>
>>> Since there is a state parameter maybe it is enough to allow w= ild
>>> cards only in the domain name of the callback URI.
>>
>> I think this we should leave this matching undefined for now - sin= ce you
>> have to preregister with every site, you will have provider-specif= ic logic
>> anyway. This will be much more important when we have a discovery = mechanism
>> for callback URLs.
>
> If we leave undefined then that is the same as enforcing strict
> equality matching. Then let's make that explicit. Are we OK with t= hat?
>
> A client that eventually wants to interact with several authz servers<= br> > will have to assume the "greatest common divisor", which is = strict
> matching.
>
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



--
Raffi Krikorian
Twit= ter Platform Team
http://twitter.co= m/raffi
--000e0cd108dcc6895604865fe878-- From Axel.Nennker@telekom.de Tue May 11 23:43:25 2010 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 B9AC53A6CA5 for ; Tue, 11 May 2010 23:43:25 -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 WPfsIrgzBdzk for ; Tue, 11 May 2010 23:43:24 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id BE3F63A6C9A for ; Tue, 11 May 2010 23:43:22 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 12 May 2010 08:43:10 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 08:43:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 08:43:09 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA3049F9F16@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt thread-index: AcrwBFKu+ANEbvvIR66deCjdPs8ImQBlv6EgAAAazhAAAIVPIA== References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: To: , X-OriginalArrivalTime: 12 May 2010 06:43:10.0618 (UTC) FILETIME=[63469FA0:01CAF19E] Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 06:43:25 -0000 I would rename "client_secret" to "client_credential" and "secret_type" to "credential_type".=20 The client_credential might be a shared secret denoted by e.g. "credential_type=3Dshared_secret". -Axel -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Wednesday, May 12, 2010 8:25 AM To: Nennker, Axel; oauth@ietf.org Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt But it is not beyond the scope. We define a parameter just for that called client_secret. If you want to use something else, you need to define an extension that replaces that with something else. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Axel.Nennker@telekom.de > Sent: Tuesday, May 11, 2010 11:22 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > I suggest a change to >=20 > "3.4. Client Credentials >=20 > When requesting access from the authorization server, the client > identifies itself using a set of client credentials. The client > credentials include a client identifier and an OPTIONAL symmetric > shared secret. The means through which the client obtains these > credentials are beyond the scope of this specification, but usually > involve registration with the authorization server." >=20 > I don't like the "symmetric shared secret" and would like this to be "beyond > the scope of this spec". >=20 > I suggest to change that paragraph e.g. to: >=20 > "3.4. Client Credentials >=20 > When requesting access from the authorization server, the client > authenticates itself using its credentials. The type of credentials > is beyond the scope of this specification. The means through which > the client obtains these credentials are beyond the scope of this > specification, but usually involve registration with the > authorization server." >=20 > -Axel >=20 > Ps. > If the client has an e.g. RSA-keypair then it could use the private key to sign > the request and thereby authenticate itself. > The public key would need to be exchanged before out-of-band. Or it could > be a certificate that is e.g. issued by the authorization server or a party that > the authorization server trusts. >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Monday, May 10, 2010 7:45 AM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Authentication Protocol Working Group > of the IETF. >=20 >=20 > Title : The OAuth 2.0 Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-04.txt > Pages : 51 > Date : 2010-05-09 >=20 > This specification describes the OAuth 2.0 protocol. OAuth provides a > method for making authenticated HTTP requests using a token - an identifier > used to denote an access grant with specific scope, duration, and other > attributes. Tokens are issued to third-party clients by an authorization server > with the approval of the resource owner. OAuth defines multiple flows for > obtaining a token to support a wide range of client types and user > experience. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Internet- > Draft. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Axel.Nennker@telekom.de Tue May 11 23:45:14 2010 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 7CF6F3A6CA7 for ; Tue, 11 May 2010 23:45:14 -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 5cXbDnpr2euN for ; Tue, 11 May 2010 23:45:13 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id F25F928C1A0 for ; Tue, 11 May 2010 23:45:11 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 12 May 2010 08:44:59 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 08:44:59 +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: Wed, 12 May 2010 08:44:58 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA3049F9F1A@S4DE9JSAAID.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt thread-index: AcrxnIbx/zDkXudYQTyWPJ1g9RDKAgAAebew References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: To: , X-OriginalArrivalTime: 12 May 2010 06:44:59.0308 (UTC) FILETIME=[A40F66C0:01CAF19E] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 06:45:14 -0000 But that gives us a flow for each type of client credential. I think it is better to talk about client_credentials and = credential_type in flow that abstracts for credential types. -Axel -----Original Message----- From: David Recordon [mailto:recordond@gmail.com]=20 Sent: Wednesday, May 12, 2010 8:30 AM To: Nennker, Axel; Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt Yes, the Client authenticating using a RSA key pair seems like it should be a different flow. On Tue, May 11, 2010 at 11:25 PM, Eran Hammer-Lahav = wrote: > But it is not beyond the scope. We define a parameter just for that = called client_secret. If you want to use something else, you need to = define an extension that replaces that with something else. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Axel.Nennker@telekom.de >> Sent: Tuesday, May 11, 2010 11:22 PM >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >> >> I suggest a change to >> >> "3.4. =A0Client Credentials >> >> =A0 =A0When requesting access from the authorization server, the = client >> =A0 =A0identifies itself using a set of client credentials. =A0The = client >> =A0 =A0credentials include a client identifier and an OPTIONAL = symmetric >> =A0 =A0shared secret. =A0The means through which the client obtains = these >> =A0 =A0credentials are beyond the scope of this specification, but = usually >> =A0 =A0involve registration with the authorization server." >> >> I don't like the "symmetric shared secret" and would like this to be = "beyond >> the scope of this spec". >> >> I suggest to change that paragraph e.g. to: >> >> "3.4. =A0Client Credentials >> >> =A0 =A0When requesting access from the authorization server, the = client >> =A0 =A0authenticates itself using its credentials. The type of = credentials >> =A0 =A0is beyond the scope of this specification. The means through = which >> =A0 =A0the client obtains these credentials are beyond the scope of = this >> =A0 =A0specification, but usually involve registration with the >> =A0 =A0authorization server." >> >> -Axel >> >> Ps. >> If the client has an e.g. RSA-keypair then it could use the private = key to sign >> the request and thereby authenticate itself. >> The public key would need to be exchanged before out-of-band. Or it = could >> be a certificate that is e.g. issued by the authorization server or a = party that >> the authorization server trusts. >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Internet-Drafts@ietf.org >> Sent: Monday, May 10, 2010 7:45 AM >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Open Authentication Protocol Working = Group >> of the IETF. >> >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The OAuth 2.0 Protocol >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : E. Hammer-Lahav, et al. >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-v2-04.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 51 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-09 >> >> This specification describes the OAuth 2.0 protocol. =A0OAuth = provides a >> method for making authenticated HTTP requests using a token - an = identifier >> used to denote an access grant with specific scope, duration, and = other >> attributes. =A0Tokens are issued to third-party clients by an = authorization server >> with the approval of the resource owner. =A0OAuth defines multiple = flows for >> obtaining a token to support a wide range of client types and user >> experience. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the = Internet- >> Draft. >> _______________________________________________ >> 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 May 11 23:47:09 2010 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 E2EBD3A6AE3 for ; Tue, 11 May 2010 23:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 shACe6mexPA6 for ; Tue, 11 May 2010 23:47:08 -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 A2B5F3A68C3 for ; Tue, 11 May 2010 23:47:08 -0700 (PDT) Received: (qmail 10940 invoked from network); 12 May 2010 06:46:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 May 2010 06:46:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 11 May 2010 23:46:58 -0700 From: Eran Hammer-Lahav To: "Axel.Nennker@telekom.de" , "oauth@ietf.org" Date: Tue, 11 May 2010 23:47:06 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt Thread-Index: AcrwBFKu+ANEbvvIR66deCjdPs8ImQBlv6EgAAAazhAAAIVPIAAANfrQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9F16@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <98B37F7D0484184B9DBDCC44B6C8EDA3049F9F16@S4DE9JSAAID.ost.t-com.de> 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] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 06:47:10 -0000 I wouldn't. The fact is that the current spec provides a symmetric secret for authentic= ating clients. Extending this to use something else is trivial. Since this = will be the majority of implementation (based on current deployment), I see= no reason to make the spec harder to read and implement for something that= is not even proposed. EHL > -----Original Message----- > From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] > Sent: Tuesday, May 11, 2010 11:43 PM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > I would rename "client_secret" to "client_credential" and "secret_type" > to "credential_type". > The client_credential might be a shared secret denoted by e.g. > "credential_type=3Dshared_secret". >=20 > -Axel >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Wednesday, May 12, 2010 8:25 AM > To: Nennker, Axel; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > But it is not beyond the scope. We define a parameter just for that calle= d > client_secret. If you want to use something else, you need to define an > extension that replaces that with something else. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Axel.Nennker@telekom.de > > Sent: Tuesday, May 11, 2010 11:22 PM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > > > I suggest a change to > > > > "3.4. Client Credentials > > > > When requesting access from the authorization server, the client > > identifies itself using a set of client credentials. The client > > credentials include a client identifier and an OPTIONAL symmetric > > shared secret. The means through which the client obtains these > > credentials are beyond the scope of this specification, but usually > > involve registration with the authorization server." > > > > I don't like the "symmetric shared secret" and would like this to be > "beyond > > the scope of this spec". > > > > I suggest to change that paragraph e.g. to: > > > > "3.4. Client Credentials > > > > When requesting access from the authorization server, the client > > authenticates itself using its credentials. The type of credentials > > is beyond the scope of this specification. The means through which > > the client obtains these credentials are beyond the scope of this > > specification, but usually involve registration with the > > authorization server." > > > > -Axel > > > > Ps. > > If the client has an e.g. RSA-keypair then it could use the private > key to sign > > the request and thereby authenticate itself. > > The public key would need to be exchanged before out-of-band. Or it > could > > be a certificate that is e.g. issued by the authorization server or a > party that > > the authorization server trusts. > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Internet-Drafts@ietf.org > > Sent: Monday, May 10, 2010 7:45 AM > > To: i-d-announce@ietf.org > > Cc: oauth@ietf.org > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Open Authentication Protocol Working > Group > > of the IETF. > > > > > > Title : The OAuth 2.0 Protocol > > Author(s) : E. Hammer-Lahav, et al. > > Filename : draft-ietf-oauth-v2-04.txt > > Pages : 51 > > Date : 2010-05-09 > > > > This specification describes the OAuth 2.0 protocol. OAuth provides a > > method for making authenticated HTTP requests using a token - an > identifier > > used to denote an access grant with specific scope, duration, and > other > > attributes. Tokens are issued to third-party clients by an > authorization server > > with the approval of the resource owner. OAuth defines multiple flows > for > > obtaining a token to support a wide range of client types and user > > experience. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > Internet- > > Draft. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From Axel.Nennker@telekom.de Wed May 12 01:50:45 2010 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 654C73A6A66 for ; Wed, 12 May 2010 01:50:45 -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 k1y8gNdBHNOp for ; Wed, 12 May 2010 01:50:44 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 790B63A6AFA for ; Wed, 12 May 2010 01:50:41 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 12 May 2010 10:50:25 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 10:50:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 10:50:23 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA3049FA0AA@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt thread-index: AcrwBFKu+ANEbvvIR66deCjdPs8ImQBlv6EgAAAazhAAAIVPIAAANfrQAAQbzSA= References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9F16@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474CD@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: To: , X-OriginalArrivalTime: 12 May 2010 08:50:25.0444 (UTC) FILETIME=[29FC9E40:01CAF1B0] Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 08:50:45 -0000 I challenge the claim that the spec gets harder to read. In fact the spec becomes cleaner if we move from one special case to a general description. Implementing other authn schemes while keeping the spec hardwired to shared-secrets might be trivial but those implementations will always be hacks. I think that the proposed changes (client_secret -> client_credential, secret_type -> credential_type) are simple and clear as can be. Whether other autn schemes are proposed or not is not that relevant.=20 I think that hardwiring "things" (authn schemes, digest algorithms) is always a bad idea. A standard should be simple to implement while beeing extensible without "hacks". -Axel -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Wednesday, May 12, 2010 8:47 AM To: Nennker, Axel; oauth@ietf.org Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt I wouldn't. The fact is that the current spec provides a symmetric secret for authenticating clients. Extending this to use something else is trivial. Since this will be the majority of implementation (based on current deployment), I see no reason to make the spec harder to read and implement for something that is not even proposed. EHL > -----Original Message----- > From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] > Sent: Tuesday, May 11, 2010 11:43 PM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > I would rename "client_secret" to "client_credential" and "secret_type" > to "credential_type". > The client_credential might be a shared secret denoted by e.g. > "credential_type=3Dshared_secret". >=20 > -Axel >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Wednesday, May 12, 2010 8:25 AM > To: Nennker, Axel; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > But it is not beyond the scope. We define a parameter just for that called > client_secret. If you want to use something else, you need to define an > extension that replaces that with something else. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Axel.Nennker@telekom.de > > Sent: Tuesday, May 11, 2010 11:22 PM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > > > I suggest a change to > > > > "3.4. Client Credentials > > > > When requesting access from the authorization server, the client > > identifies itself using a set of client credentials. The client > > credentials include a client identifier and an OPTIONAL symmetric > > shared secret. The means through which the client obtains these > > credentials are beyond the scope of this specification, but usually > > involve registration with the authorization server." > > > > I don't like the "symmetric shared secret" and would like this to be > "beyond > > the scope of this spec". > > > > I suggest to change that paragraph e.g. to: > > > > "3.4. Client Credentials > > > > When requesting access from the authorization server, the client > > authenticates itself using its credentials. The type of credentials > > is beyond the scope of this specification. The means through which > > the client obtains these credentials are beyond the scope of this > > specification, but usually involve registration with the > > authorization server." > > > > -Axel > > > > Ps. > > If the client has an e.g. RSA-keypair then it could use the private > key to sign > > the request and thereby authenticate itself. > > The public key would need to be exchanged before out-of-band. Or it > could > > be a certificate that is e.g. issued by the authorization server or a > party that > > the authorization server trusts. > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Internet-Drafts@ietf.org > > Sent: Monday, May 10, 2010 7:45 AM > > To: i-d-announce@ietf.org > > Cc: oauth@ietf.org > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Open Authentication Protocol Working > Group > > of the IETF. > > > > > > Title : The OAuth 2.0 Protocol > > Author(s) : E. Hammer-Lahav, et al. > > Filename : draft-ietf-oauth-v2-04.txt > > Pages : 51 > > Date : 2010-05-09 > > > > This specification describes the OAuth 2.0 protocol. OAuth provides a > > method for making authenticated HTTP requests using a token - an > identifier > > used to denote an access grant with specific scope, duration, and > other > > attributes. Tokens are issued to third-party clients by an > authorization server > > with the approval of the resource owner. OAuth defines multiple flows > for > > obtaining a token to support a wide range of client types and user > > experience. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > Internet- > > Draft. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From paul.madsen@gmail.com Wed May 12 03:57:51 2010 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 4CF303A6B2F for ; Wed, 12 May 2010 03:57:51 -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 KohiitQUrUwo for ; Wed, 12 May 2010 03:57:50 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 87F093A6B2E for ; Wed, 12 May 2010 03:57:49 -0700 (PDT) Received: by vws13 with SMTP id 13so586742vws.31 for ; Wed, 12 May 2010 03:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/lLvFwxBVAQfKOy5KTiji5LWNs7Q3RprzaTiaAbSFx4=; b=RTvfZq26mc0RoUGGJTEZmwLPEnWkCWtrQ8W6NJku3A9+ZZCj6eyS08bQmp1RNSgEfM Vnugq0EIQzYz6Toz9jDYODF1L2ee0zFxiCHhYFTV3CPvbz/WJFGhhVmbqM9neecS+b+W iaLx+n7D1+3luXbGwbtG+qPdQdWVwCRsVn1Ig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=gW0KVv9//Tkg8d6Q5xWwfPW4iyT1VbzkVZBtDUjavBbV3cF8fLvnJAoa24KLKaz+7e B0vfAevOxwQgxcS6I1oX8l71w3r22VuyZfzgXqI109frNh0J3Zb70bT+XwVSvLdFjyTX pTPI2VTIwrRLNjpqBf0/grhMGSg0W/n9oMq8o= Received: by 10.220.127.22 with SMTP id e22mr1120806vcs.242.1273661856342; Wed, 12 May 2010 03:57:36 -0700 (PDT) Received: from [192.168.0.175] (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id z22sm177626vco.10.2010.05.12.03.57.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 03:57:34 -0700 (PDT) Message-ID: <4BEA8999.7070205@gmail.com> Date: Wed, 12 May 2010 06:57:29 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 10:57:51 -0000 But client_secret is not defined specific to a given flow - its used by the web server, user name, and client credentials flows. I can find no mention of the client using the client_secret for crypto authentication - the text of 5.3 'Crypto Tokens Requests' is very specific to clients authenticating their resource requests, not their requests to the AS. Is the client_secret limited to be a bearer token? This earlier message [1] of Eran's suggests that a crypto authentication was in scope at one point "We are still very likely to have a PK-based method for obtaining *authorization* (a token)" [1] - http://www.ietf.org/mail-archive/web/oauth/current/msg00654.html On 5/12/2010 2:29 AM, David Recordon wrote: > Yes, the Client authenticating using a RSA key pair seems like it > should be a different flow. > > On Tue, May 11, 2010 at 11:25 PM, Eran Hammer-Lahav wrote: > >> But it is not beyond the scope. We define a parameter just for that called client_secret. If you want to use something else, you need to define an extension that replaces that with something else. >> >> EHL >> >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Axel.Nennker@telekom.de >>> Sent: Tuesday, May 11, 2010 11:22 PM >>> To: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >>> >>> I suggest a change to >>> >>> "3.4. Client Credentials >>> >>> When requesting access from the authorization server, the client >>> identifies itself using a set of client credentials. The client >>> credentials include a client identifier and an OPTIONAL symmetric >>> shared secret. The means through which the client obtains these >>> credentials are beyond the scope of this specification, but usually >>> involve registration with the authorization server." >>> >>> I don't like the "symmetric shared secret" and would like this to be "beyond >>> the scope of this spec". >>> >>> I suggest to change that paragraph e.g. to: >>> >>> "3.4. Client Credentials >>> >>> When requesting access from the authorization server, the client >>> authenticates itself using its credentials. The type of credentials >>> is beyond the scope of this specification. The means through which >>> the client obtains these credentials are beyond the scope of this >>> specification, but usually involve registration with the >>> authorization server." >>> >>> -Axel >>> >>> Ps. >>> If the client has an e.g. RSA-keypair then it could use the private key to sign >>> the request and thereby authenticate itself. >>> The public key would need to be exchanged before out-of-band. Or it could >>> be a certificate that is e.g. issued by the authorization server or a party that >>> the authorization server trusts. >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Internet-Drafts@ietf.org >>> Sent: Monday, May 10, 2010 7:45 AM >>> To: i-d-announce@ietf.org >>> Cc: oauth@ietf.org >>> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Open Authentication Protocol Working Group >>> of the IETF. >>> >>> >>> Title : The OAuth 2.0 Protocol >>> Author(s) : E. Hammer-Lahav, et al. >>> Filename : draft-ietf-oauth-v2-04.txt >>> Pages : 51 >>> Date : 2010-05-09 >>> >>> This specification describes the OAuth 2.0 protocol. OAuth provides a >>> method for making authenticated HTTP requests using a token - an identifier >>> used to denote an access grant with specific scope, duration, and other >>> attributes. Tokens are issued to third-party clients by an authorization server >>> with the approval of the resource owner. OAuth defines multiple flows for >>> obtaining a token to support a wide range of client types and user >>> experience. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the Internet- >>> Draft. >>> _______________________________________________ >>> 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 Wed May 12 08:57:07 2010 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 6A2B53A6D33 for ; Wed, 12 May 2010 08:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 BWtYv+6jqTp9 for ; Wed, 12 May 2010 08:57:05 -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 E1ED328C2CD for ; Wed, 12 May 2010 08:44:43 -0700 (PDT) Received: (qmail 1037 invoked from network); 12 May 2010 15:44:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 May 2010 15:44:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 12 May 2010 08:44:33 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Wed, 12 May 2010 08:44:43 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt Thread-Index: AcrxwfPwkfSJGfwFR4eSIkW5ykg+JAAJm5wQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEA8999.7070205@gmail.com> In-Reply-To: <4BEA8999.7070205@gmail.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] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 15:57:07 -0000 There is a bit of confusion here. We had clear consensus that the client credentials are only used to obtain = a token, not to access protected resources. Some flows use just the client = identifier, while others use both the identifier and shared secret. The ass= ertion flow doesn't use it at all. We had clear consensus that an asymmetric secret solution, whether it was f= or tokens or client credentials is out of scope. Adding support for a symme= tric token secret using HMAC was the compromise, since many people consider= the bearer token approach to be the most likely one to win wide adoption (= I'm representing consensus, not necessarily agreeing with it). Extensions are not hacks (unless they are poorly written). Profiles are not= hacks. An extension saying: "instead of including the 'client_secret', inc= lude a 'signature' parameter with your request" isn't a hack. We are still likely to see a PK-based solution in the form of an extension = flow (for example, the client makes a request where the client identifier i= s a domain name and the request is signed using the client's private key; t= he server verifies the request by getting the client's public key from its = host-meta document for the domain used in the client identifier). Such a PK= solution can be a new flow or an extension to existing flows. Either way, = it will be in a separate document. We are also likely to see a PK-based solution for token secrets, similar to= the OAuth RSA approach. However, it is far from clear which private key wi= ll be used to sign protected resources requests. The client's? A token-spec= ific PK? Is this going to be a combination of a token flow and protected re= source extension? I don't know because I don't have any actual use cases in= mind right now. But the spec was written to make sure It will not prevent this from being added later on. The current client identifier and client secret are what we have wide conse= nsus on. We are still discussing how to send these, but from the answers so= far, there is enough support to keep the parameters in (with or without su= pport for sending them using Basic as an alternative method). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul Madsen > Sent: Wednesday, May 12, 2010 3:57 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > But client_secret is not defined specific to a given flow - its used by t= he web > server, user name, and client credentials flows. >=20 > I can find no mention of the client using the client_secret for crypto > authentication - the text of 5.3 'Crypto Tokens Requests' is very specifi= c to > clients authenticating their resource requests, not their requests to the= AS. >=20 > Is the client_secret limited to be a bearer token? >=20 > This earlier message [1] of Eran's suggests that a crypto authentication = was in > scope at one point >=20 > "We are still very likely to have a PK-based method for obtaining > *authorization* (a token)" >=20 > [1] - http://www.ietf.org/mail-archive/web/oauth/current/msg00654.html >=20 > On 5/12/2010 2:29 AM, David Recordon wrote: > > Yes, the Client authenticating using a RSA key pair seems like it > > should be a different flow. > > > > On Tue, May 11, 2010 at 11:25 PM, Eran Hammer- > Lahav wrote: > > > >> But it is not beyond the scope. We define a parameter just for that ca= lled > client_secret. If you want to use something else, you need to define an > extension that replaces that with something else. > >> > >> EHL > >> > >> > >>> -----Original Message----- > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>> Behalf Of Axel.Nennker@telekom.de > >>> Sent: Tuesday, May 11, 2010 11:22 PM > >>> To: oauth@ietf.org > >>> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > >>> > >>> I suggest a change to > >>> > >>> "3.4. Client Credentials > >>> > >>> When requesting access from the authorization server, the client > >>> identifies itself using a set of client credentials. The client > >>> credentials include a client identifier and an OPTIONAL symmetric > >>> shared secret. The means through which the client obtains these > >>> credentials are beyond the scope of this specification, but usual= ly > >>> involve registration with the authorization server." > >>> > >>> I don't like the "symmetric shared secret" and would like this to be > >>> "beyond the scope of this spec". > >>> > >>> I suggest to change that paragraph e.g. to: > >>> > >>> "3.4. Client Credentials > >>> > >>> When requesting access from the authorization server, the client > >>> authenticates itself using its credentials. The type of credentia= ls > >>> is beyond the scope of this specification. The means through whic= h > >>> the client obtains these credentials are beyond the scope of this > >>> specification, but usually involve registration with the > >>> authorization server." > >>> > >>> -Axel > >>> > >>> Ps. > >>> If the client has an e.g. RSA-keypair then it could use the private > >>> key to sign the request and thereby authenticate itself. > >>> The public key would need to be exchanged before out-of-band. Or it > >>> could be a certificate that is e.g. issued by the authorization > >>> server or a party that the authorization server trusts. > >>> > >>> -----Original Message----- > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>> Behalf Of Internet-Drafts@ietf.org > >>> Sent: Monday, May 10, 2010 7:45 AM > >>> To: i-d-announce@ietf.org > >>> Cc: oauth@ietf.org > >>> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>> This draft is a work item of the Open Authentication Protocol > >>> Working Group of the IETF. > >>> > >>> > >>> Title : The OAuth 2.0 Protocol > >>> Author(s) : E. Hammer-Lahav, et al. > >>> Filename : draft-ietf-oauth-v2-04.txt > >>> Pages : 51 > >>> Date : 2010-05-09 > >>> > >>> This specification describes the OAuth 2.0 protocol. OAuth provides > >>> a method for making authenticated HTTP requests using a token - an > >>> identifier used to denote an access grant with specific scope, > >>> duration, and other attributes. Tokens are issued to third-party > >>> clients by an authorization server with the approval of the resource > >>> owner. OAuth defines multiple flows for obtaining a token to > >>> support a wide range of client types and user experience. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet- Draft. > >>> _______________________________________________ > >>> 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 mscurtescu@google.com Wed May 12 09:47:37 2010 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 D2FFF3A6955 for ; Wed, 12 May 2010 09:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.809 X-Spam-Level: X-Spam-Status: No, score=-105.809 tagged_above=-999 required=5 tests=[AWL=0.168, 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 hPSS+n2M6Fae for ; Wed, 12 May 2010 09:47:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C82F128C23D for ; Wed, 12 May 2010 09:28:14 -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 o4CGS0ln004439 for ; Wed, 12 May 2010 09:28:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273681683; bh=hD3AjE7832pLeQD9Me1hFayOZ7Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=eKdySICJ953C/HtYIBsD+v5KbrjR4MElbSUJFzEdRzY0eoKBVoU82bC4DWaD7CUKV IdE7Zv4O4QvZ1NCn/CC4g== 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=iD8D7C0Rz2gvTa13mhF3JdKIdBBsxmAzIox6asGlKjVtwbTi0GaG0nxD1xpu8LqN+ eDQXk87emz97rzWsV3Snw== Received: from pzk41 (pzk41.prod.google.com [10.243.19.169]) by wpaz1.hot.corp.google.com with ESMTP id o4CGRxGC022679 for ; Wed, 12 May 2010 09:27:59 -0700 Received: by pzk41 with SMTP id 41so126062pzk.10 for ; Wed, 12 May 2010 09:27:59 -0700 (PDT) Received: by 10.140.58.1 with SMTP id g1mr4990567rva.138.1273681676279; Wed, 12 May 2010 09:27:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Wed, 12 May 2010 09:27:36 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126331480A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1126331480A@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Wed, 12 May 2010 09:27:36 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] sites with wildcard 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, 12 May 2010 16:47:37 -0000 On Tue, May 11, 2010 at 5:37 PM, Manger, James H wrote: > Marius, > >>> Should it send the token when getting the photos? > >> I would say definitely not. If the client gets back a 403 with >> discovery info that points to the same authz server and approved >> scopes, only then could the client re-try with a token. > >> Would that work? > > No. That would be totally insecure. > > Any site can return a 403 and list, say, Google as its authz server so any site (good or bad) could get a client to reveal its Google token. Good point. Thanks for clarifying all my questions. Marius From mscurtescu@google.com Wed May 12 09:53:49 2010 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 AC82528C35C for ; Wed, 12 May 2010 09:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.209 X-Spam-Level: X-Spam-Status: No, score=-100.209 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 PWwGlKrm7JlM for ; Wed, 12 May 2010 09:53:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 6DA6E28C3FB for ; Wed, 12 May 2010 09:35:28 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o4CGZGT1022290 for ; Wed, 12 May 2010 09:35:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273682116; bh=R3zski78LrhCKkOoDz4Pznc/wI0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=dH2lacEjSa6sDqyhd56jd5MDO3AvJOlxL+swgaqNfbXfglop1gkKBBFAxzA7gJ4mJ J7zfGGpY7+Q030BBRhVIA== 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:content-transfer-encoding:x-system-of-record; b=ZdG2WhdsKJk94cGNc4/R5axdBXkj1PtHDuy9Q7Kmamgjzqu10b8DiXY7Iv/wRWLtG 9tleLEiUBunUtAC1kcS1Q== Received: from pvc30 (pvc30.prod.google.com [10.241.209.158]) by wpaz5.hot.corp.google.com with ESMTP id o4CGZEtD030897 for ; Wed, 12 May 2010 09:35:14 -0700 Received: by pvc30 with SMTP id 30so159657pvc.8 for ; Wed, 12 May 2010 09:35:14 -0700 (PDT) Received: by 10.141.188.26 with SMTP id q26mr5209758rvp.150.1273682114137; Wed, 12 May 2010 09:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Wed, 12 May 2010 09:34:54 -0700 (PDT) In-Reply-To: References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 12 May 2010 09:34:54 -0700 Message-ID: To: Raffi Krikorian Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri 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, 12 May 2010 16:53:49 -0000 If I understand correctly, Twitter does strict matching (against a list) and Facebook does prefix matching. If I am a client and want to integrate with Facebook only, I may take advantage of the prefix matching and rely on that. What if at some point in the future I now want to integrate with Twitter as well? I can't. At least not without rewriting my whole OAuth 2 infrastructure. Because of that, if I really want to be able to work with any OAuth 2 authz sever I can only assume strict matching. Do we want to tackle this problem or let clients figure it out (some of them the hard way)? Marius On Tue, May 11, 2010 at 11:39 PM, Raffi Krikorian wrote= : > twitter is working on a version where we will actually allow the > specification of an explicit array of registered URIs, and we do strict > matching against the elements of that array to see if any match. =A0we th= ought > of allowing just subdomain globbing and wildcards, but that seemed > problematic for GAE like situations.... > > On Wed, May 12, 2010 at 7:31 AM, Luke Shepard wro= te: >> >> FWIW, Facebook does not do strict equality matching on redirect_uri. We >> accept any redirect_uri that has either: >> >> - its prefix is the registered url >> - or it is a special facebook.com/xd_proxy.php url, with an origin >> parameter that has a prefix on the registered url >> >> I think that the spec should leave the matching up to the server. >> >> On May 11, 2010, at 3:13 PM, Marius Scurtescu wrote: >> >> > On Tue, May 11, 2010 at 3:04 PM, Evan Gilbert wrot= e: >> >> >> >> On Mon, May 10, 2010 at 1:16 PM, Marius Scurtescu >> >> >> >> wrote: >> >>> >> >>> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav >> >>> >> >>> wrote: >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> >>>>> Sent: Sunday, May 09, 2010 5:52 PM >> >>>> >> >>>>>>> 3.5.1. =A0Client Requests Authorization >> >>>>>>> >> >>>>>>> If the client has previously registered a redirection URI with t= he >> >>>>>>> =A0 =A0authorization server, the authorization server MUST verif= y that >> >>>>>>> the >> >>>>>>> =A0 =A0redirection URI received matches the registered URI assoc= iated >> >>>>>>> with >> >>>>>>> =A0 =A0the client identifier. >> >>>>>>> >> >>>>>>> Does this mean equality? Or just the same base string? >> >>>>>> >> >>>>>> Right now it depends on the server. >> >>>>> >> >>>>> The spec should clarify that. Suggested wording: >> >>>>> >> >>>>> >> >>>>> If the client has previously registered a redirection URI with the >> >>>>> authorization >> >>>>> server, the authorization server MUST verify that the redirection >> >>>>> URI >> >>>>> received matches the registered URI associated with the client >> >>>>> identifier. The >> >>>>> components of the redirection URI that must match the registered U= RI >> >>>>> is >> >>>>> authorization server dependant. >> >>>> >> >>>> I don't see how that helps... I also don't see why we can't just >> >>>> profile >> >>>> this and decide on how the matching should be done. We have the sta= te >> >>>> parameter to help too. >> >>> >> >>> I also think the spec should specify how the matching should be done= . >> >>> >> >>> If left up to the authz server then a client that designs its OAuth = 2 >> >>> implementation will have to assume that all authz servers will do >> >>> strict equality matching, otherwise it may not be able to interact >> >>> with some servers. >> >>> >> >>> For example, if the client assumes that it can use load balancing by >> >>> varying the first part of the host name, and this may work with the >> >>> fist authz server it integrate with, later this client will not be >> >>> able to interact with an authz server which does strict matching on >> >>> host name. And changing the load balancing architecture once deploye= d >> >>> could be very hard. >> >>> >> >>> Since there is a state parameter maybe it is enough to allow wild >> >>> cards only in the domain name of the callback URI. >> >> >> >> I think this we should leave this matching undefined for now - since >> >> you >> >> have to preregister with every site, you will have provider-specific >> >> logic >> >> anyway. This will be much more important when we have a discovery >> >> mechanism >> >> for callback URLs. >> > >> > If we leave undefined then that is the same as enforcing strict >> > equality matching. Then let's make that explicit. Are we OK with that? >> > >> > A client that eventually wants to interact with several authz servers >> > will have to assume the "greatest common divisor", which is strict >> > matching. >> > >> > Marius >> > _______________________________________________ >> > 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 > > > > -- > Raffi Krikorian > Twitter Platform Team > http://twitter.com/raffi > From prateek.mishra@oracle.com Wed May 12 09:57:32 2010 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 3E1F728C422 for ; Wed, 12 May 2010 09:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 0cj1NtHtsPaB for ; Wed, 12 May 2010 09:57:30 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7CD803A6CE9 for ; Wed, 12 May 2010 09:39:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4CGdc6e012097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 May 2010 16:39:40 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C9xqpR022700; Wed, 12 May 2010 16:39:37 GMT Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 235627951273682367; Wed, 12 May 2010 09:39:27 -0700 Received: from [141.144.122.241] (/141.144.122.241) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 09:39:26 -0700 Message-ID: <4BEAD9B3.2040609@oracle.com> Date: Wed, 12 May 2010 12:39:15 -0400 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEA8999.7070205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4BEAD9CC.020E:SCFMA922111,ss=1,fgs=0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 16:57:32 -0000 Eran, I want to support the idea of a minimal specification, that supports the basic use-case with no frills. Successful standards are usually small and with strong focus on a few key use-cases But the specification does need to point to or document some extensibilty points. Otherwise, implementations will hard-wire the exact form of credential described in the specification and profiles will be viewed as alternatives not as variants. Instead, it would be good if implementations were somewhat "pluggable" with respect to the security credential exchanges between 1) client (SP) and authorization service 2) client (SP) and resource server I realize this creates more work for the folks actually writing the specification (versus us lurkers) but it does increase the value of this effort by an order of magnitude. I guess I should take an action to explain how this might be accomplished in the present draft. - prateek > There is a bit of confusion here. > > We had clear consensus that the client credentials are only used to obtain a token, not to access protected resources. Some flows use just the client identifier, while others use both the identifier and shared secret. The assertion flow doesn't use it at all. > > We had clear consensus that an asymmetric secret solution, whether it was for tokens or client credentials is out of scope. Adding support for a symmetric token secret using HMAC was the compromise, since many people consider the bearer token approach to be the most likely one to win wide adoption (I'm representing consensus, not necessarily agreeing with it). > > Extensions are not hacks (unless they are poorly written). Profiles are not hacks. An extension saying: "instead of including the 'client_secret', include a 'signature' parameter with your request" isn't a hack. > > We are still likely to see a PK-based solution in the form of an extension flow (for example, the client makes a request where the client identifier is a domain name and the request is signed using the client's private key; the server verifies the request by getting the client's public key from its host-meta document for the domain used in the client identifier). Such a PK solution can be a new flow or an extension to existing flows. Either way, it will be in a separate document. > > We are also likely to see a PK-based solution for token secrets, similar to the OAuth RSA approach. However, it is far from clear which private key will be used to sign protected resources requests. The client's? A token-specific PK? Is this going to be a combination of a token flow and protected resource extension? I don't know because I don't have any actual use cases in mind right now. But the spec was written to make sure > It will not prevent this from being added later on. > > The current client identifier and client secret are what we have wide consensus on. We are still discussing how to send these, but from the answers so far, there is enough support to keep the parameters in (with or without support for sending them using Basic as an alternative method). > > EHL > > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Paul Madsen >> Sent: Wednesday, May 12, 2010 3:57 AM >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >> >> But client_secret is not defined specific to a given flow - its used by the web >> server, user name, and client credentials flows. >> >> I can find no mention of the client using the client_secret for crypto >> authentication - the text of 5.3 'Crypto Tokens Requests' is very specific to >> clients authenticating their resource requests, not their requests to the AS. >> >> Is the client_secret limited to be a bearer token? >> >> This earlier message [1] of Eran's suggests that a crypto authentication was in >> scope at one point >> >> "We are still very likely to have a PK-based method for obtaining >> *authorization* (a token)" >> >> [1] - http://www.ietf.org/mail-archive/web/oauth/current/msg00654.html >> >> On 5/12/2010 2:29 AM, David Recordon wrote: >> >>> Yes, the Client authenticating using a RSA key pair seems like it >>> should be a different flow. >>> >>> On Tue, May 11, 2010 at 11:25 PM, Eran Hammer- >>> >> Lahav wrote: >> >>>> But it is not beyond the scope. We define a parameter just for that called >>>> >> client_secret. If you want to use something else, you need to define an >> extension that replaces that with something else. >> >>>> EHL >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> Behalf Of Axel.Nennker@telekom.de >>>>> Sent: Tuesday, May 11, 2010 11:22 PM >>>>> To: oauth@ietf.org >>>>> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >>>>> >>>>> I suggest a change to >>>>> >>>>> "3.4. Client Credentials >>>>> >>>>> When requesting access from the authorization server, the client >>>>> identifies itself using a set of client credentials. The client >>>>> credentials include a client identifier and an OPTIONAL symmetric >>>>> shared secret. The means through which the client obtains these >>>>> credentials are beyond the scope of this specification, but usually >>>>> involve registration with the authorization server." >>>>> >>>>> I don't like the "symmetric shared secret" and would like this to be >>>>> "beyond the scope of this spec". >>>>> >>>>> I suggest to change that paragraph e.g. to: >>>>> >>>>> "3.4. Client Credentials >>>>> >>>>> When requesting access from the authorization server, the client >>>>> authenticates itself using its credentials. The type of credentials >>>>> is beyond the scope of this specification. The means through which >>>>> the client obtains these credentials are beyond the scope of this >>>>> specification, but usually involve registration with the >>>>> authorization server." >>>>> >>>>> -Axel >>>>> >>>>> Ps. >>>>> If the client has an e.g. RSA-keypair then it could use the private >>>>> key to sign the request and thereby authenticate itself. >>>>> The public key would need to be exchanged before out-of-band. Or it >>>>> could be a certificate that is e.g. issued by the authorization >>>>> server or a party that the authorization server trusts. >>>>> >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> Behalf Of Internet-Drafts@ietf.org >>>>> Sent: Monday, May 10, 2010 7:45 AM >>>>> To: i-d-announce@ietf.org >>>>> Cc: oauth@ietf.org >>>>> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> >> directories. >> >>>>> This draft is a work item of the Open Authentication Protocol >>>>> Working Group of the IETF. >>>>> >>>>> >>>>> Title : The OAuth 2.0 Protocol >>>>> Author(s) : E. Hammer-Lahav, et al. >>>>> Filename : draft-ietf-oauth-v2-04.txt >>>>> Pages : 51 >>>>> Date : 2010-05-09 >>>>> >>>>> This specification describes the OAuth 2.0 protocol. OAuth provides >>>>> a method for making authenticated HTTP requests using a token - an >>>>> identifier used to denote an access grant with specific scope, >>>>> duration, and other attributes. Tokens are issued to third-party >>>>> clients by an authorization server with the approval of the resource >>>>> owner. OAuth defines multiple flows for obtaining a token to >>>>> support a wide range of client types and user experience. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant mail reader >>>>> implementation to automatically retrieve the ASCII version of the >>>>> Internet- Draft. >>>>> _______________________________________________ >>>>> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Wed May 12 10:31:37 2010 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 E5E2E3A689C for ; Wed, 12 May 2010 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 4oL8DRNiEIrX for ; Wed, 12 May 2010 10:31: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 9CECF3A6A0A for ; Wed, 12 May 2010 10:08:31 -0700 (PDT) Received: (qmail 25592 invoked from network); 12 May 2010 17:08:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 May 2010 17:08:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 12 May 2010 10:08:21 -0700 From: Eran Hammer-Lahav To: Prateek Mishra Date: Wed, 12 May 2010 10:08:29 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt Thread-Index: Acrx8byRk7xp8X+US4m3y8lakvw69AAAd9jw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47638@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEA8999.7070205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEAD9B3.2040609@oracle.com> In-Reply-To: <4BEAD9B3.2040609@oracle.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] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 17:31:38 -0000 The spec should only directly enable extensibility where extensibility is a= requirement/use case. For example, we know we are going to have more flows= , so the spec should define the process to add new flows and register their= 'type' value. Same with other HMAC algorithms. However, making something extensible because it *might* be used in the futu= re just makes the protocol more complicated for no gain. If someone has spe= cific use cases around other client credentials, please share them so we ca= n make sure they are either supported or enabled as an extension. But sayin= g that we are sure to have other types of credentials so let's make sure th= e spec is ready for them is a no-starter. Also, it's not a bad thing that extending the protocol is a bit of a challe= nge. Extensions, by definition, hurt interop. There should be some burden i= n extending to make people reconsider and try to work with what they have. In other words, extensibility, like everything else, must be driven by use = cases and requirements. We spent months discussing why we need signatures a= nd ended up with good technical reasons and limited support to just those u= ses. And this is truly *not* aimed at anyone in particular: I'm getting tired of= people lecturing the group about what makes a good standard. There are ple= nty of examples of simple and complex, successful and failed standards out = there. What makes a standard successful is what makes fashion successful - = influential people (or companies) start using it. If you have a *technical*= argument for or against a feature, please make it, but enough with the lec= tures about why we are here, what makes standards successful, and other the= ories. EHL > -----Original Message----- > From: Prateek Mishra [mailto:prateek.mishra@oracle.com] > Sent: Wednesday, May 12, 2010 9:39 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > Eran, >=20 > I want to support the idea of a minimal specification, that supports the = basic > use-case with no frills. Successful standards are usually small and with = strong > focus on a few key use-cases >=20 > But the specification does need to point to or document some extensibilty > points. Otherwise, implementations will hard-wire the exact form of > credential described in the specification and profiles will be viewed as > alternatives not as variants. Instead, it would be good if implementation= s > were somewhat "pluggable" with respect to the security credential > exchanges between >=20 >=20 > 1) client (SP) and authorization service > 2) client (SP) and resource server >=20 > I realize this creates more work for the folks actually writing the speci= fication > (versus us lurkers) but it does increase the value of this effort by an o= rder of > magnitude. >=20 > I guess I should take an action to explain how this might be accomplished= in > the present draft. >=20 > - prateek >=20 >=20 > > There is a bit of confusion here. > > > > We had clear consensus that the client credentials are only used to obt= ain a > token, not to access protected resources. Some flows use just the client > identifier, while others use both the identifier and shared secret. The > assertion flow doesn't use it at all. > > > > We had clear consensus that an asymmetric secret solution, whether it w= as > for tokens or client credentials is out of scope. Adding support for a > symmetric token secret using HMAC was the compromise, since many > people consider the bearer token approach to be the most likely one to wi= n > wide adoption (I'm representing consensus, not necessarily agreeing with = it). > > > > Extensions are not hacks (unless they are poorly written). Profiles are= not > hacks. An extension saying: "instead of including the 'client_secret', in= clude a > 'signature' parameter with your request" isn't a hack. > > > > We are still likely to see a PK-based solution in the form of an extens= ion > flow (for example, the client makes a request where the client identifier= is a > domain name and the request is signed using the client's private key; the > server verifies the request by getting the client's public key from its h= ost- > meta document for the domain used in the client identifier). Such a PK > solution can be a new flow or an extension to existing flows. Either way,= it > will be in a separate document. > > > > We are also likely to see a PK-based solution for token secrets, > > similar to the OAuth RSA approach. However, it is far from clear which > private key will be used to sign protected resources requests. The client= 's? A > token-specific PK? Is this going to be a combination of a token flow and > protected resource extension? I don't know because I don't have any actua= l > use cases in mind right now. But the spec was written to make sure It wil= l not > prevent this from being added later on. > > > > The current client identifier and client secret are what we have wide > consensus on. We are still discussing how to send these, but from the > answers so far, there is enough support to keep the parameters in (with o= r > without support for sending them using Basic as an alternative method). > > > > EHL > > > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Paul Madsen > >> Sent: Wednesday, May 12, 2010 3:57 AM > >> To: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > >> > >> But client_secret is not defined specific to a given flow - its used > >> by the web server, user name, and client credentials flows. > >> > >> I can find no mention of the client using the client_secret for > >> crypto authentication - the text of 5.3 'Crypto Tokens Requests' is > >> very specific to clients authenticating their resource requests, not t= heir > requests to the AS. > >> > >> Is the client_secret limited to be a bearer token? > >> > >> This earlier message [1] of Eran's suggests that a crypto > >> authentication was in scope at one point > >> > >> "We are still very likely to have a PK-based method for obtaining > >> *authorization* (a token)" > >> > >> [1] - > >> http://www.ietf.org/mail-archive/web/oauth/current/msg00654.html > >> > >> On 5/12/2010 2:29 AM, David Recordon wrote: > >> > >>> Yes, the Client authenticating using a RSA key pair seems like it > >>> should be a different flow. > >>> > >>> On Tue, May 11, 2010 at 11:25 PM, Eran Hammer- > >>> > >> Lahav wrote: > >> > >>>> But it is not beyond the scope. We define a parameter just for that > >>>> called > >>>> > >> client_secret. If you want to use something else, you need to define > >> an extension that replaces that with something else. > >> > >>>> EHL > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>>> Behalf Of Axel.Nennker@telekom.de > >>>>> Sent: Tuesday, May 11, 2010 11:22 PM > >>>>> To: oauth@ietf.org > >>>>> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > >>>>> > >>>>> I suggest a change to > >>>>> > >>>>> "3.4. Client Credentials > >>>>> > >>>>> When requesting access from the authorization server, the clien= t > >>>>> identifies itself using a set of client credentials. The clien= t > >>>>> credentials include a client identifier and an OPTIONAL symmetr= ic > >>>>> shared secret. The means through which the client obtains thes= e > >>>>> credentials are beyond the scope of this specification, but usu= ally > >>>>> involve registration with the authorization server." > >>>>> > >>>>> I don't like the "symmetric shared secret" and would like this to > >>>>> be "beyond the scope of this spec". > >>>>> > >>>>> I suggest to change that paragraph e.g. to: > >>>>> > >>>>> "3.4. Client Credentials > >>>>> > >>>>> When requesting access from the authorization server, the clien= t > >>>>> authenticates itself using its credentials. The type of credent= ials > >>>>> is beyond the scope of this specification. The means through wh= ich > >>>>> the client obtains these credentials are beyond the scope of th= is > >>>>> specification, but usually involve registration with the > >>>>> authorization server." > >>>>> > >>>>> -Axel > >>>>> > >>>>> Ps. > >>>>> If the client has an e.g. RSA-keypair then it could use the > >>>>> private key to sign the request and thereby authenticate itself. > >>>>> The public key would need to be exchanged before out-of-band. Or > >>>>> it could be a certificate that is e.g. issued by the authorization > >>>>> server or a party that the authorization server trusts. > >>>>> > >>>>> -----Original Message----- > >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>>> Behalf Of Internet-Drafts@ietf.org > >>>>> Sent: Monday, May 10, 2010 7:45 AM > >>>>> To: i-d-announce@ietf.org > >>>>> Cc: oauth@ietf.org > >>>>> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt > >>>>> > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>>> > >> directories. > >> > >>>>> This draft is a work item of the Open Authentication Protocol > >>>>> Working Group of the IETF. > >>>>> > >>>>> > >>>>> Title : The OAuth 2.0 Protocol > >>>>> Author(s) : E. Hammer-Lahav, et al. > >>>>> Filename : draft-ietf-oauth-v2-04.txt > >>>>> Pages : 51 > >>>>> Date : 2010-05-09 > >>>>> > >>>>> This specification describes the OAuth 2.0 protocol. OAuth > >>>>> provides a method for making authenticated HTTP requests using a > >>>>> token - an identifier used to denote an access grant with specific > >>>>> scope, duration, and other attributes. Tokens are issued to > >>>>> third-party clients by an authorization server with the approval > >>>>> of the resource owner. OAuth defines multiple flows for obtaining > >>>>> a token to support a wide range of client types and user experience= . > >>>>> > >>>>> A URL for this Internet-Draft is: > >>>>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.txt > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> Below is the data which will enable a MIME compliant mail reader > >>>>> implementation to automatically retrieve the ASCII version of the > >>>>> Internet- Draft. > >>>>> _______________________________________________ > >>>>> 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 > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From uidude@google.com Wed May 12 11:28:52 2010 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 61F4E28C2AD for ; Wed, 12 May 2010 11:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.944 X-Spam-Level: X-Spam-Status: No, score=-104.944 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_05=-1.11, 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 i5uagORCSjXC for ; Wed, 12 May 2010 11:28:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 209C33A6BB1 for ; Wed, 12 May 2010 11:02:15 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o4CI24s1020797 for ; Wed, 12 May 2010 11:02:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273687324; bh=wCo47MBmgXe7UWlqu0kDhQpAY2s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=w37tuRr1OxrcuLxPbqPk3K1A3+vj8a+83bdQLOiWQDJrgk8Xz06uEVKoOCIVBaAzp 3KEVmtUTORn4kx/kGCsmQ== 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=Ot0KXke3psHJ7OBbuvrWusB+/dK/RvhA+qBDOtGXB75/7YjbYJI2NSgro6DGJrDhM EIgJ2D3e9cMNSmoUWXPjQ== Received: from qyk4 (qyk4.prod.google.com [10.241.83.132]) by wpaz24.hot.corp.google.com with ESMTP id o4CI23gA024528 for ; Wed, 12 May 2010 11:02:03 -0700 Received: by qyk4 with SMTP id 4so267219qyk.21 for ; Wed, 12 May 2010 11:02:03 -0700 (PDT) Received: by 10.224.44.218 with SMTP id b26mr5286287qaf.291.1273687310040; Wed, 12 May 2010 11:01:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Wed, 12 May 2010 11:01:29 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47132@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Wed, 12 May 2010 11:01:29 -0700 Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=00c09fa219c1ac10580486696fc0 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Provisional OAuth enhancements 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, 12 May 2010 18:28:52 -0000 --00c09fa219c1ac10580486696fc0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK, just started this experiment :) - Added a section on the OAuth IETF Wiki for proposed enhancements: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2ProvisionalEnhancements= . - First proposal is for "username" parameter: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter. If you support immediate mode you probably want to use this parameter or come up with an alternate approach for ensuring the same user is logged in. Please consider adding enhancements to this Wiki when we don't have implementation experience. Cheers, Evan On Tue, May 11, 2010 at 9:24 AM, Brian Eaton wrote: > On Mon, May 10, 2010 at 8:05 PM, Eran Hammer-Lahav > wrote: > > I don=92t see how moving the discussion/work on these features elsewher= e > will > > help reach consensus on them. > > I think the proposal is to keep discussion on the IETF mailing list, > but clearly separate things that are speculative from things that are > known to be practical. > > There have been a few cases where speculative things have nearly > gotten included in the core spec, which seems fairly dangerous to me. > > > But I=92m not going to stop anyone from playing with the wiki=85 (or pu= blish > > their own extension I-D). > > That's the idea. > --00c09fa219c1ac10580486696fc0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK, just started this experiment :)
- Added a section on the OAuth IETF= Wiki for proposed enhancements:=A0http://trac.tools.ietf.org/= wg/oauth/trac/wiki/OAuth2ProvisionalEnhancements.
- First proposal is for "username" parameter:=A0= http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter. = If you support immediate mode you probably want to use this parameter or co= me up with an alternate approach for ensuring the same user is logged in.

Please consider adding enhancements to this Wiki when w= e don't have implementation experience.

Cheers= ,
Evan

On Tue, May 11, 2010 at = 9:24 AM, Brian Eaton <beaton@google.com> wrote:
On Mon, May 10, 2010 at 8= :05 PM, Eran Hammer-Lahav <eran@h= ueniverse.com> wrote:
> I don=92t see how moving the discussion/work on these features elsewhe= re will
> help reach consensus on them.

I think the proposal is to keep discussion on the IETF mailing list,<= br> but clearly separate things that are speculative from things that are
known to be practical.

There have been a few cases where speculative things have nearly
gotten included in the core spec, which seems fairly dangerous to me.

> But I=92m not going to stop anyone from playing with the wiki=85 (or p= ublish
> their own extension I-D).

That's the idea.

--00c09fa219c1ac10580486696fc0-- From uidude@google.com Wed May 12 12:51:45 2010 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 E9B4F3A67F0 for ; Wed, 12 May 2010 12:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.739 X-Spam-Level: X-Spam-Status: No, score=-104.739 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_20=-0.74, 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 HWNkwbZ8CXWE for ; Wed, 12 May 2010 12:51:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0746B3A6818 for ; Wed, 12 May 2010 12:51:42 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o4CJpSCv025692 for ; Wed, 12 May 2010 12:51:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273693889; bh=EycAtd3R2g5wjDOhC0tw5mVN2j4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=icbiGD7ihtk9wPY/s7dTFWddhJrbjQTzAkFZmLBQBQrthQig8OWBDT/DTTKpgFG+V ZdSoMgB+j09fypb9QSF0Q== 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=og8giC7dxOsYn8JUYc67O28DzamEHoS+UfSY3s9AJD+1Gs3tsOk792rSuucdVo7bE mo7eO7TqMmrRy7zrGj+2w== Received: from gya1 (gya1.prod.google.com [10.243.49.1]) by hpaq7.eem.corp.google.com with ESMTP id o4CJpPSF026310 for ; Wed, 12 May 2010 12:51:26 -0700 Received: by gya1 with SMTP id 1so176702gya.34 for ; Wed, 12 May 2010 12:51:25 -0700 (PDT) Received: by 10.229.223.130 with SMTP id ik2mr1193525qcb.107.1273693885248; Wed, 12 May 2010 12:51:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Wed, 12 May 2010 12:51:05 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Wed, 12 May 2010 12:51:05 -0700 Message-ID: To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=00163630f39f95341804866af70e X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 19:51:46 -0000 --00163630f39f95341804866af70e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 4:30 PM, Evan Gilbert wrote: > I really like the idea behind the "sites" parameter > I continue to like the idea behind the "sites" parameter, but think it may be premature to add to the OAuth spec. Clients need to know the following in advance: 1. The scope to use to request access to a protected resource 2. The API endpoint to call to access the the protected resource Solving the question of what URL prefixes are valid to send the token to seems like it needs to follow answers for #1 and #2 (or at least #2). As an example, to support #2 we might want to return JSON configuration about all of the APIs that are available ({'contacts.get': 'http:/...', 'activities.post': 'http://...'}). This would supersede the need for the sites parameter. (note: These are the types of issues I'd prefer to start as provisional enhancements ) > I think this idea relates closely to scopes and probably needs to be boun= d > more tightly to the inbound scope parameter. Both identify a set of > protected resources that can be accessed with the token - one is the > requested resources, the other is the granted resources. In both cases yo= u > need to have a way to find a mapping from protected resource identifier -= > > API endpoint you can call. > > On Mon, May 10, 2010 at 5:18 AM, Richer, Justin P. wro= te: > >> +1 >> >> Any information that the client needs to care about should live outside >> the token. >> >> -- Justin >> >> ------------------------------ >> *From:* oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Era= n >> Hammer-Lahav [eran@hueniverse.com] >> *Sent:* Sunday, May 09, 2010 5:29 PM >> *To:* David Recordon; Marius Scurtescu >> >> *Cc:* OAuth WG >> *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid >> >> The idea of embedding this information into the token is wrong. This i= s >> clearly token metadata and that information belongs alongside the token, >> just like =91expires_in=92. >> >> >> >> EHL >> >> >> >> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behal= f >> Of *David Recordon >> *Sent:* Friday, May 07, 2010 11:06 AM >> *To:* Marius Scurtescu >> *Cc:* OAuth WG >> *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid >> >> >> >> Using SWT for your access tokens seems like a reasonable way to resolve >> this for servers which care. >> >> >> >> On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu >> wrote: >> >> Returning a scope parameter with issued tokens is not a bad idea. >> >> But this, and also the sites parameter suggested by James, can both >> potentially be solved with a transparent token format. Such a token >> can make explicit the: >> - expiry time >> - scopes >> - sites >> - etc. >> >> The Simple Web Token spec goes along these lines. SWT has a parameter >> called Audience, which I assumed would point to the client, but it >> could also represent "sites". >> >> Marius >> >> >> >> >> On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt >> wrote: >> > Additionally, I would propose to indicate the scope associated with a >> token >> > to the client using a scope response parameter. This is especially >> useful >> > (1) if the client did not pass a scope parameter but the server decide= d >> to >> > associate a scope based on its policy or (2) if the user decided to >> > authorize a subset of the requested scope only. >> > Regards, >> > Torsten. >> > >> > >> > >> > Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt >> > : >> > >> > what about an additional realm response value? >> > >> > If there is a binding between realm and token, the client can decide >> based >> > on the realm attribute discovered using a WWW-Authenticate response >> which >> > token to use. >> > >> > regards, >> > Torsten. >> > >> > Am 07.05.2010 07:06, schrieb Manger, James H: >> > >> > Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on >> clients >> > being told by the server about the sites at which the secret >> > (cookie/password/token) can be used (and, more importantly, where is >> must >> > not be used). This occurs without requiring service-specific knowledge >> in >> > the client app. OAuth aims to replace some of these uses. >> > >> > >> > >> > HTTP Basic authentication works safely from clients with no >> service-specific >> > knowledge because the client knows not to send the password it gets fr= om >> the >> > user to other sites. >> > >> > >> > >> > HTTP Digest authentication allows a password to used to across a set o= f >> > domains specified in a WWW-Authenticate response header, but the >> password >> > will not be used at arbitrary other sites. >> > >> > >> > >> > Cookies are sent in requests to the same site, sites with the same >> parent, >> > or only https sites, depending on details from the service when settin= g >> the >> > cookie. >> > >> > >> > >> > >> > >> > To date, OAuth has assumed every client app has lots of service-specif= ic >> > knowledge to make these choices. OAuth needs to remove the need for so >> much >> > service-specific knowledge to be as interoperable as other standard au= th >> > mechanism, otherwise it is a poor replacement. >> > >> > >> > >> > -- >> > >> > James Manger >> > >> > >> > >> > From: David Recordon [mailto:recordond@gmail.com] >> > Sent: Friday, 7 May 2010 2:05 PM >> > To: Manger, James H >> > Cc: OAuth WG >> > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid >> > >> > >> > >> > Hey James, >> > >> > Do you have a specific example in mind where this either has been an >> issue >> > or will be an issue? Most client implementations I've seen of OAuth (a= nd >> > technologies like OAuth) have a strong binding between the access >> token(s), >> > site they were issued by, and user they belong to. So I haven't heard = of >> > this being a problem in the wild... >> > >> > >> > >> > --David >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --00163630f39f95341804866af70e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Mon, May 10, 2010 at 4:30 P= M, Evan Gilbert <= uidude@google.com> wrote:
I really like the idea behind the "sites" parameter

I continue to like the idea behind the "= sites" parameter, but think it may be premature to add to the OAuth sp= ec.

Clients need to know the following in advance:
1. The scope to use to request access to a protected resource
2= . The API endpoint to call to access the the protected resource

Solving the question of what URL prefixes are valid to send = the token to seems like it needs to follow answers for #1 and #2 (or at lea= st #2).

As an example, to support #2 we might want= to return JSON configuration about all of the APIs that are available ({&#= 39;contacts.get': 'http:/...', 'activities.post': '= http://...'}). This would supersede the need for the sites parameter.

(note: These are the types of issues I'd prefer to = start as provisional enhancements)


I think this idea= relates closely to scopes and probably needs to be bound more tightly to t= he inbound scope parameter. Both identify a set of protected resources that= can be accessed with the token - one is the requested resources, the other= is the granted resources. In both cases you need to have a way to find a m= apping from protected resource identifier -> API endpoint you can call.= =A0

On Mon, May 10, 2010 at 5:18= AM, Richer, Justin P. <jricher@mitre.org> wrote:
+1
=A0
Any information that the = client needs to care about should live outside the token.
=A0
=A0-- Justin
=A0
From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On = Behalf Of Eran Hammer-Lahav [eran@hueniverse.com]
Sent: Sunday, May 09, 2010 5:29 PM
To: David Recordon; Marius Scurtescu

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

The ide= a of embedding this information into the token is wrong. This is clearly to= ken metadata and that information belongs alongside the token, just like =91expires_in=92.

= =A0

EHL

= =A0

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Recordon
Sent: Friday, May 07, 2010 11:06 AM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid

=A0

Using SWT for your access tokens seems like a reason= able way to resolve this for servers which care.

=A0

On Fri, May 7, 2010 at 11:01 AM, Marius Scurtescu &l= t;mscurtescu@goo= gle.com> wrote:

Returning a scope parameter with issued tokens is no= t a bad idea.

But this, and also the sites parameter suggested by James, can both
potentially be solved with a transparent token format. Such a token
can make explicit the:
- expiry time
- scopes
- sites
- etc.

The Simple Web Token spec goes along these lines. SWT has a parameter
called Audience, which I assumed would point to the client, but it
could also represent "sites".

Marius




On Thu, May 6, 2010 at 11:06 PM, Torsten Lodderstedt
<torsten@lo= dderstedt.net> wrote:
> Additionally, I would propose to indicate the scope associated with a = token
> to the client using a scope response parameter. This is especially use= ful
> (1) if the client did not pass a scope parameter but the server decide= d to
> associate a scope based on its policy or (2) if the user decided to > authorize a subset of the requested scope only.
> Regards,
> Torsten.
>
>
>
> Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt
> <torst= en@lodderstedt.net>:
>
> what about an additional realm response value?
>
> If there is a binding between realm and token, the client can decide b= ased
> on the realm attribute discovered using a WWW-Authenticate response wh= ich
> token to use.
>
> regards,
> Torsten.
>
> Am 07.05.2010 07:06, schrieb Manger, James H:
>
> Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on c= lients
> being told by the server about the sites at which the secret
> (cookie/password/token) can be used (and, more importantly, where is m= ust
> not be used). This occurs without requiring service-specific knowledge= in
> the client app. OAuth aims to replace some of these uses.
>
>
>
> HTTP Basic authentication works safely from clients with no service-sp= ecific
> knowledge because the client knows not to send the password it gets fr= om the
> user to other sites.
>
>
>
> HTTP Digest authentication allows a password to used to across a set o= f
> domains specified in a WWW-Authenticate response header, but the passw= ord
> will not be used at arbitrary other sites.
>
>
>
> Cookies are sent in requests to the same site, sites with the same par= ent,
> or only https sites, depending on details from the service when settin= g the
> cookie.
>
>
>
>
>
> To date, OAuth has assumed every client app has lots of service-specif= ic
> knowledge to make these choices. OAuth needs to remove the need for so= much
> service-specific knowledge to be as interoperable as other standard au= th
> mechanism, otherwise it is a poor replacement.
>
>
>
> --
>
> James Manger
>
>
>
> From: David Recordon [mailto:recordond@gmail.com]
> Sent: Friday, 7 May 2010 2:05 PM
> To: Manger, James H
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
>
>
>
> Hey James,
>
> Do you have a specific example in mind where this either has been an i= ssue
> or will be an issue? Most client implementations I've seen of OAut= h (and
> technologies like OAuth) have a strong binding between the access toke= n(s),
> site they were issued by, and user they belong to. So I haven't he= ard of
> this being a problem in the wild...
>
>
>
> --David
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0


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



--00163630f39f95341804866af70e-- From sayrer@gmail.com Wed May 12 16:19:27 2010 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 EDD023A6853 for ; Wed, 12 May 2010 16:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_05=-1.11, GB_I_LETTER=-2] 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 pHm7bjhEFNe4 for ; Wed, 12 May 2010 16:19:26 -0700 (PDT) Received: from mail-qy0-f184.google.com (mail-qy0-f184.google.com [209.85.221.184]) by core3.amsl.com (Postfix) with ESMTP id 313173A68F0 for ; Wed, 12 May 2010 16:19:24 -0700 (PDT) Received: by qyk14 with SMTP id 14so441570qyk.17 for ; Wed, 12 May 2010 16:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6IkH3uyHifbPosrd7+0UI5ZHE5eoNvLv+tS60Xl0nyk=; b=Sb/JcB842RuUssNFYTLG9U+W/lnw6G2Ol3yxqilWUkVMdhj4FvqwH4D5x0wpwetsax cZcHED7ul/PuCGV9hDY6f1IE124s1TVqgM9zvwTY62Ny2hCYqHnWwaBglQKPBv3AuDu9 eqX8ZQCWX3pDyFfSzdtj+n7Lw72OKI1Q2n1E8= 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=yFeFNowwgnVDmD/Cp6ba+ZC3XGYSY4cfWNBxZetjpWqbd912Q7RCH6eupykm+hWC1V k9PFamBA7nhzJT11UaWZp+dgKsu5AiooD83YaBPxXpQkAl7+4DJcOz6R7uF+H1shHyNJ n/OJ+dMDnXcq8+ec1oZcXyJuus0ycB3sVESJE= MIME-Version: 1.0 Received: by 10.229.187.77 with SMTP id cv13mr5338018qcb.3.1273706352220; Wed, 12 May 2010 16:19:12 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Wed, 12 May 2010 16:19:11 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47638@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEA8999.7070205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEAD9B3.2040609@oracle.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47638@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 12 May 2010 19:19:11 -0400 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" , Prateek Mishra Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 23:19:27 -0000 On Wed, May 12, 2010 at 1:08 PM, Eran Hammer-Lahav wrote: > > And this is truly *not* aimed at anyone in particular: I'm getting tired of people lecturing the group about what makes a good standard. Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff grouped into one document. There seems to be consensus to do that, but it still runs counter to the conventional wisdom. > What makes a standard successful is what makes fashion successful - influential people (or companies) start using it. You mean like SOAP? -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From eran@hueniverse.com Wed May 12 16:37:30 2010 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 747333A6908 for ; Wed, 12 May 2010 16:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 mASU129ctYhq for ; Wed, 12 May 2010 16:37:29 -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 9F11D3A6853 for ; Wed, 12 May 2010 16:37:29 -0700 (PDT) Received: (qmail 13239 invoked from network); 12 May 2010 23:37:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 May 2010 23:37:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 12 May 2010 16:37:12 -0700 From: Eran Hammer-Lahav To: Robert Sayre Date: Wed, 12 May 2010 16:37:23 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt Thread-Index: AcryKYw0XFUfm1oKS5eWExdHRUjknwAAmxEg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4779B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEA8999.7070205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEAD9B3.2040609@oracle.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47638@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" , Prateek Mishra Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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: Wed, 12 May 2010 23:37:30 -0000 > -----Original Message----- > From: Robert Sayre [mailto:sayrer@gmail.com] > Sent: Wednesday, May 12, 2010 4:19 PM > To: Eran Hammer-Lahav > Cc: Prateek Mishra; oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt >=20 > On Wed, May 12, 2010 at 1:08 PM, Eran Hammer-Lahav > wrote: > > > > And this is truly *not* aimed at anyone in particular: I'm getting tire= d of > people lecturing the group about what makes a good standard. >=20 > Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuf= f > grouped into one document. There seems to be consensus to do that, but it > still runs counter to the conventional wisdom. Can you point to specific parts that should not be grouped together? EHL From James.H.Manger@team.telstra.com Wed May 12 17:10:14 2010 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 64D743A6987 for ; Wed, 12 May 2010 17:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SLGLhsgxZeN for ; Wed, 12 May 2010 17:10:13 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 500283A6985 for ; Wed, 12 May 2010 17:10:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,218,1272808800"; d="scan'208";a="2845742" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 13 May 2010 10:09:54 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5980"; a="1845815" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 13 May 2010 10:09:54 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 13 May 2010 10:09:54 +1000 From: "Manger, James H" To: Evan Gilbert Date: Thu, 13 May 2010 10:09:52 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcryDI3HSMRV96/ESOCyJ9eNsbmBFwAH6DwQ Message-ID: <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112631B24FC@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@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 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 00:10:14 -0000 RXZhbiwNCg0KPiBDbGllbnRzIG5lZWQgdG8ga25vdyB0aGUgZm9sbG93aW5nIGluIGFkdmFuY2U6 DQo+IDEuIFRoZSBzY29wZSB0byB1c2UgdG8gcmVxdWVzdCBhY2Nlc3MgdG8gYSBwcm90ZWN0ZWQg cmVzb3VyY2UNCj4gMi4gVGhlIEFQSSBlbmRwb2ludCB0byBjYWxsIHRvIGFjY2VzcyB0aGUgdGhl IHByb3RlY3RlZCByZXNvdXJjZQ0KPg0KPiBTb2x2aW5nIHRoZSBxdWVzdGlvbiBvZiB3aGF0IFVS TCBwcmVmaXhlcyBhcmUgdmFsaWQgdG8gc2VuZCB0aGUgdG9rZW4NCj4gdG8gc2VlbXMgbGlrZSBp dCBuZWVkcyB0byBmb2xsb3cgYW5zd2VycyBmb3IgIzEgYW5kICMyIChvciBhdCBsZWFzdCAjMiku DQoNCkkgYWdyZWUgdGhhdCBhIGNsaWVudCBuZWVkcyAjMiB0byAqc3RhcnQqIHVzaW5nIGFuIEFQ SS4NClRoZSBpc3N1ZSBpcyB3aGF0IHRoZSBjbGllbnQgbmVlZHMgYXMgaXQgZm9sbG93cyByZWRp cmVjdHMgYW5kIGxpbmtzIHRocm91Z2ggdGhlIEFQSSBhbmQgYmV5b25kLg0KDQoNCj4gQXMgYW4g ZXhhbXBsZSwgdG8gc3VwcG9ydCAjMiB3ZSBtaWdodCB3YW50IHRvIHJldHVybiBKU09ODQo+IGNv bmZpZ3VyYXRpb24gYWJvdXQgYWxsIG9mIHRoZSBBUElzIHRoYXQgYXJlIGF2YWlsYWJsZQ0KPiAo eydjb250YWN0cy5nZXQnOiAnaHR0cDovLi4uJywgJ2FjdGl2aXRpZXMucG9zdCc6ICdodHRwOi8v Li4uJ30pLg0KPiBUaGlzIHdvdWxkIHN1cGVyc2VkZSB0aGUgbmVlZCBmb3IgdGhlIHNpdGVzIHBh cmFtZXRlci4NCg0KSSBkb24ndCBsaWtlIHRoaXMgc3BlY2lmaWMgaWRlYSBvZiBtaXhpbmcgQVBJ IGRpc2NvdmVyIHdpdGggdGhlIGNyZWRlbnRpYWwgZm9ybWF0LiBJdCBpcyBhIHdlYi1zdHlsZSBh cHByb2FjaCB0aG91Z2g6IHRoZSBjbGllbnQgZm9sbG93cyBsaW5rcyBpbiBhIHJlc3BvbnNlLiBT dWNoIGxpbmtzIGluIGEgcmVzcG9uc2Ugd2lsbCBub3Qgb25seSBvY2N1ciBhdCB0aGlzIGluaXRp YWwgcG9pbnQsIHRoZXkgY2FuIGFwcGVhciBhbnl3aGVyZSBpbiBhIHdlYi1zdHlsZSBBUEkuIFRo ZSBjbGllbnQgbmVlZHMgdG8ga25vdyB3aGF0IHRvIGRvIChzZW5kIHRva2VuIG9yIG5vdCkgYXQg ZWFjaCBwb2ludCB0aGF0IGEgbGluayBhcHBlYXJzIC0tICJzaXRlcyIgYW5zd2VycyB0aGlzLg0K DQoNCj4gSSB0aGluayB0aGlzIGlkZWEgcmVsYXRlcyBjbG9zZWx5IHRvIHNjb3BlcyBhbmQgcHJv YmFibHkgbmVlZHMgdG8gYmUgYm91bmQgbW9yZSB0aWdodGx5IHRvIHRoZSBpbmJvdW5kIHNjb3Bl IHBhcmFtZXRlci4gQm90aCBpZGVudGlmeSBhIHNldCBvZiBwcm90ZWN0ZWQgcmVzb3VyY2VzIHRo YXQgY2FuIGJlIGFjY2Vzc2VkIHdpdGggdGhlIHRva2VuIC0gb25lIGlzIHRoZSByZXF1ZXN0ZWQg cmVzb3VyY2VzLCB0aGUgb3RoZXIgaXMgdGhlIGdyYW50ZWQgcmVzb3VyY2VzLg0KDQpUaGlzIGlz IG5vdCB0cnVlLg0KRmFjZWJvb2sgc2NvcGVzLCBmb3IgaW5zdGFuY2UsIGFyZSBwZXJtaXNzaW9u cyBub3QgaWRlbnRpdGllcyBvZiBwcm90ZWN0ZWQgcmVzb3VyY2VzLiBJZiB5b3Ugd2FudCAoZ2Vu ZXJpYykgY2xpZW50cyB0byBiZSBhYmxlIHRvIGxpc3QgcmVxdWVzdGVkIHJlc291cmNlcyAoYnkg VVJJPykgdGhhdCBuZWVkcyBhIHNlcGFyYXRlIHByb3Bvc2FsLCBhbmQgcHJvYmFibHkgY2FuJ3Qg dXNlICJzY29wZXMiLg0KDQoNCj4gSW4gYm90aCBjYXNlcyB5b3UgbmVlZCB0byBoYXZlIGEgd2F5 IHRvIGZpbmQgYSBtYXBwaW5nDQo+IGZyb20gcHJvdGVjdGVkIHJlc291cmNlIGlkZW50aWZpZXIg LT4gQVBJIGVuZHBvaW50IHlvdSBjYW4gY2FsbC4NCg0KSXNuJ3QgYSAicHJvdGVjdGVkIHJlc291 cmNlIGlkZW50aWZpZXIiIHRoZSBVUkkgeW91IEdFVC9QT1NUL1BVVC9ERUxFVEUgdG8/DQoNCg0K DQpQLlMuIE9uICMxLCBhIGNsaWVudCBuZWVkcyBhbiBhdXRoeiBVUkkgdG8gc2VuZCBhIHVzZXIg dG8gLS0ga25vd2luZyB0aGUgc2NvcGUgYW5kIGEgYmFzZSBVUkkgaXMganVzdCBvbmUgd2F5IHRv IGJ1aWxkIHN1Y2ggYW4gYXV0aHogVVJJLCBiZWluZyBnaXZlbiB0aGUgYXV0aHogVVJJIGlzIGFu b3RoZXIuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From sayrer@gmail.com Wed May 12 17:41:49 2010 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 785A93A68D5 for ; Wed, 12 May 2010 17:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_40=-0.185, GB_I_LETTER=-2] 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 BYHxaE10sQwW for ; Wed, 12 May 2010 17:41:48 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 621AF3A688C for ; Wed, 12 May 2010 17:41:42 -0700 (PDT) Received: by qyk11 with SMTP id 11so841007qyk.13 for ; Wed, 12 May 2010 17:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Bq1BbajoDGqBO1zO+JXLYJRs0bjbQsgke6SWTVVtmIs=; b=N9Hd3CEpRxwfr2R+I7m8xPr21HBLUv0mhsaErqZOeOpBGcwMttd6nKRKfok2dIAPWs FVwuluA0Wqucz2L8N8JXpPro0SKuR0okm0MQw50RdAKfO6cGRx7VCDybaxYuaV/FYbEP Sxm983XBFJZD1AGjaCu9Pavo6ZpQlJccZMmCU= 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=oTwXqfDwutEUr75Bd/S0JIx85GcyXVgl33aCTSuxwXDUrp30/wBknchtFOx/+BlYiV sDofoYp7DVMy2JARCV8jpVoPpVOqtcJXrnFy0FIXgRrbqr8WefI2iO40a5BX4EDRMsPE nLjLKCglHyhXpuTi92K9MBOcVpCVi7VNQEf2M= MIME-Version: 1.0 Received: by 10.229.193.18 with SMTP id ds18mr868238qcb.151.1273711285219; Wed, 12 May 2010 17:41:25 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Wed, 12 May 2010 17:41:25 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB4779B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEA8999.7070205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEAD9B3.2040609@oracle.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47638@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4779B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 12 May 2010 20:41:25 -0400 Message-ID: From: Robert Sayre To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" , Prateek Mishra Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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, 13 May 2010 00:41:49 -0000 On Wed, May 12, 2010 at 7:37 PM, Eran Hammer-Lahav wrote: > >> >> Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff >> grouped into one document. There seems to be consensus to do that, but it >> still runs counter to the conventional wisdom. > > Can you point to specific parts that should not be grouped together? Sure, to give one example, I would make the device flow a separate spec immediately. That seems only distantly related to other things in the spec, and may not be really necessary by the time the standard matures. I mean, Facebook engineers have already said they felt comfortable shipping certain pieces of the spec because they seem stable. Why isn't the group hammering out nits in those pieces, writing test suites, and declaring victory? You can always add more later. Anyway, I've said my piece on this point quite enough. Many new readers will probably bring it up, though. That shouldn't be surprising. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From mscurtescu@google.com Wed May 12 19:06:43 2010 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 A02473A6908 for ; Wed, 12 May 2010 19:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.563 X-Spam-Level: X-Spam-Status: No, score=-100.563 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 70ANed3rgYsY for ; Wed, 12 May 2010 19:06:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 72E2A3A67AF for ; Wed, 12 May 2010 19:06:42 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o4D26Uld025160 for ; Wed, 12 May 2010 19:06:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273716390; bh=uPHBdfo2KKg1PuQkr4cCuYnu8/A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=mTnXw0bB3PV5iOzWk/epE93jOqwAE0gHqKhkJ08z9kE7pkqDviiUVHxcglL7oeEas 5ekWRyDNr0IuBiW+0PVHQ== 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:content-transfer-encoding:x-system-of-record; b=B01/wnipYrjMr/7Sk/P+d8BMYNumXK3+1EERVscEG1PwqO43BBF0vQnVmXT6gR1gh f+Kk1gqXhk5x21/ls2kNQ== Received: from pzk1 (pzk1.prod.google.com [10.243.19.129]) by hpaq13.eem.corp.google.com with ESMTP id o4D25trC020901 for ; Wed, 12 May 2010 19:06:29 -0700 Received: by pzk1 with SMTP id 1so390661pzk.8 for ; Wed, 12 May 2010 19:06:27 -0700 (PDT) Received: by 10.140.248.20 with SMTP id v20mr5572811rvh.235.1273716387151; Wed, 12 May 2010 19:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Wed, 12 May 2010 19:06:07 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47130@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47130@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 12 May 2010 19:06:07 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.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, 13 May 2010 02:06:43 -0000 On Mon, May 10, 2010 at 7:53 PM, Eran Hammer-Lahav wr= ote: > Propose text. Tried to write some text, but still not sure what the right solution is. redirect_uri matching is done in two flows: Web Server and User-Agent. In Web Server the matching issue can be avoided by always requiring redirect_uri on the initial request, and require authz servers not to match against a pre-registered one, and then do strict matching when the access token is requested. In User-Agent, matching must be done between pre-registered and the one sent with the request. Here I would suggest strict matching (which boils down to no requirement to send redirect_uri if it was pre-registered). For this flow, does anyone see the need for wild card domain matching or for path prefix matching? If we cannot get to an agreement, maybe the spec can at least advise clients to assume strict matching since this assures the largest compatibility? Does it help to propose text if there is no agreement? Marius > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Monday, May 10, 2010 1:16 PM >> To: Eran Hammer-Lahav >> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt >> >> On Sun, May 9, 2010 at 10:09 PM, Eran Hammer-Lahav >> wrote: >> > >> >> -----Original Message----- >> >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> >> Sent: Sunday, May 09, 2010 5:52 PM >> > >> >> >> 3.5.1. =A0Client Requests Authorization >> >> >> >> >> >> If the client has previously registered a redirection URI with the >> >> >> =A0 =A0authorization server, the authorization server MUST verify = that >> >> >> the >> >> >> =A0 =A0redirection URI received matches the registered URI associa= ted >> >> >> with >> >> >> =A0 =A0the client identifier. >> >> >> >> >> >> Does this mean equality? Or just the same base string? >> >> > >> >> > Right now it depends on the server. >> >> >> >> The spec should clarify that. Suggested wording: >> >> >> >> >> >> If the client has previously registered a redirection URI with the >> >> authorization server, the authorization server MUST verify that the >> >> redirection URI received matches the registered URI associated with >> >> the client identifier. The components of the redirection URI that >> >> must match the registered URI is authorization server dependant. >> > >> > I don't see how that helps... I also don't see why we can't just profi= le this >> and decide on how the matching should be done. We have the state >> parameter to help too. >> >> I also think the spec should specify how the matching should be done. >> >> If left up to the authz server then a client that designs its OAuth 2 >> implementation will have to assume that all authz servers will do strict >> equality matching, otherwise it may not be able to interact with some >> servers. >> >> For example, if the client assumes that it can use load balancing by var= ying >> the first part of the host name, and this may work with the fist authz s= erver it >> integrate with, later this client will not be able to interact with an a= uthz server >> which does strict matching on host name. And changing the load balancing >> architecture once deployed could be very hard. >> >> Since there is a state parameter maybe it is enough to allow wild cards = only in >> the domain name of the callback URI. >> >> Marius > From uidude@google.com Wed May 12 22:41:50 2010 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 5B4383A6A4B for ; Wed, 12 May 2010 22:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.743 X-Spam-Level: X-Spam-Status: No, score=-103.743 tagged_above=-999 required=5 tests=[AWL=-1.567, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqOUeHawh0Qh for ; Wed, 12 May 2010 22:41:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 26EB33A6961 for ; Wed, 12 May 2010 22:41:42 -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 o4D5fSCM020199 for ; Wed, 12 May 2010 22:41:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273729288; bh=iWawmiy8KukLzwSsl60LVgDTiLg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=eADmh5MJrz1drzEVpgK6cbKqcyrT1LlxFCBAv8lSF5/+hXDW+rcS/TOOI1iKItVjt +84tgofqt9l9TsD4/YdVQ== 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=ALkK5xSmt5yg5jxrNaDmv6KKz0mVtjwKfTiwdrkVnsPsBgfle+yhbPruHFgR8cPKu hRQPn7mAHgpMyFablXU4g== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by wpaz9.hot.corp.google.com with ESMTP id o4D5fFil014998 for ; Wed, 12 May 2010 22:41:27 -0700 Received: by qyk30 with SMTP id 30so1336236qyk.16 for ; Wed, 12 May 2010 22:41:26 -0700 (PDT) Received: by 10.229.250.73 with SMTP id mn9mr916496qcb.170.1273729284509; Wed, 12 May 2010 22:41:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Wed, 12 May 2010 22:41:04 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> From: Evan Gilbert Date: Wed, 12 May 2010 22:41:04 -0700 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016362845088b127b048673359d X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 05:41:50 -0000 --0016362845088b127b048673359d Content-Type: text/plain; charset=ISO-8859-1 Thanks for the response - feedback inline... On Wed, May 12, 2010 at 5:09 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Evan, > > > Clients need to know the following in advance: > > 1. The scope to use to request access to a protected resource > > 2. The API endpoint to call to access the the protected resource > > > > Solving the question of what URL prefixes are valid to send the token > > to seems like it needs to follow answers for #1 and #2 (or at least #2). > > I agree that a client needs #2 to *start* using an API. > The issue is what the client needs as it follows redirects and links > through the API and beyond. > > > As an example, to support #2 we might want to return JSON > > configuration about all of the APIs that are available > > ({'contacts.get': 'http:/...', 'activities.post': 'http://...'}). > > This would supersede the need for the sites parameter. > > I don't like this specific idea of mixing API discover with the credential > format. Seems like if it's OK to send a list of valid "sites" for a credential it should be OK to list the API endpoints. Also, this discovery could be in a separate process - doesn't have to be with the token response. The key point is that this discovery covers a lot of the same grounds as the sites parameter, and it's hard to define semantics around a sites parameter without understanding the semantics of scopes and API endpoints. > It is a web-style approach though: the client follows links in a response. > Such links in a response will not only occur at this initial point, they can > appear anywhere in a web-style API. The client needs to know what to do > (send token or not) at each point that a link appears -- "sites" answers > this. Clients need to more about these links (at least the response format). The mechanism they use to find out about these links - documentation, discovery, data returned with token request - could also provide the information about whether a token should be sent to a particular API. > > > > I think this idea relates closely to scopes and probably needs to be > bound more tightly to the inbound scope parameter. Both identify a set of > protected resources that can be accessed with the token - one is the > requested resources, the other is the granted resources. > > This is not true. > Facebook scopes, for instance, are permissions not identities of protected > resources. If you want (generic) clients to be able to list requested > resources (by URI?) that needs a separate proposal, and probably can't use > "scopes". > I was using "set of protected resources" to mean a permission. I should be more concrete about the use cases I see. Let's assume there's an API where there are two endpoints, each with an associated permission - contacts.list permission -> http://contacts.serviceprovider.com/contacts/list - calendar.get permission -> http://calendar.serviceprovider.com/calendar/get If the response to an authorization request includes the authorized scopes (contacts.list, calendar.get), then the "sites" parameter is redundant. > > > In both cases you need to have a way to find a mapping > > from protected resource identifier -> API endpoint you can call. > > Isn't a "protected resource identifier" the URI you GET/POST/PUT/DELETE to? > > > > P.S. On #1, a client needs an authz URI to send a user to -- knowing the > scope and a base URI is just one way to build such an authz URI, being given > the authz URI is another. > > -- > James Manger > --0016362845088b127b048673359d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the response - feedback inline...

On Wed, May 12, 2010 at 5:09 PM, Manger, James H <= ;James= .H.Manger@team.telstra.com> wrote:
Evan,

> Clients need to know the following in advance:
> 1. The scope to use to request access to a protected resource
> 2. The API endpoint to call to access the the protected resource
>
> Solving the question of what URL prefixes are valid to send the token<= br> > to seems like it needs to follow answers for #1 and #2 (or at least #2= ).

I agree that a client needs #2 to *start* using an API.
The issue is what the client needs as it follows redirects and links throug= h the API and beyond.


> As an example, to support #2 we might want to return JSON
> configuration about all of the APIs that are available
> ({'contacts.get': 'http:/...', 'activities.post= 9;: 'http://...'}).
> This would supersede the need for the sites parameter.

I don't like this specific idea of mixing API discover with the c= redential format.

Seems like if it's O= K to send a list of valid "sites" for a credential it should be O= K to list the API endpoints.

Also, this discovery could be in a separate process - d= oesn't have to be with the token response. The key point is that this d= iscovery covers a lot of the same grounds as the sites parameter, and it= 9;s hard =A0to define semantics around a sites parameter without understand= ing the semantics of scopes and API endpoints.
=A0
It is a web-style approach tho= ugh: the client follows links in a response. Such links in a response will = not only occur at this initial point, they can appear anywhere in a web-sty= le API. The client needs to know what to do (send token or not) at each poi= nt that a link appears -- "sites" answers this.
=A0
Clients need to more about these links (at least the res= ponse format). The mechanism they use to find out about these links -=A0doc= umentation, discovery, data returned with token request - could also provid= e the information about whether a token should be sent to a particular API.=
=A0


> I think this idea relates closely to scopes and probably needs to be b= ound more tightly to the inbound scope parameter. Both identify a set of pr= otected resources that can be accessed with the token - one is the requeste= d resources, the other is the granted resources.

This is not true.
Facebook scopes, for instance, are permissions not identities of protected = resources. If you want (generic) clients to be able to list requested resou= rces (by URI?) that needs a separate proposal, and probably can't use &= quot;scopes".

I was using "set of protected resourc= es" to mean a permission.=A0

I should be more concrete a= bout the use cases I see. Let's assume there's an API where there a= re two endpoints, each with an associated permission

If the response to an authorization request includes th= e authorized scopes (contacts.list, calendar.get), then the "sites&quo= t; parameter is redundant.




> In both cases you need to have a way to find a mapping
> from protected resource identifier -> API endpoint you can call.
Isn't a "protected resource identifier" the URI you GET= /POST/PUT/DELETE to?



P.S. On #1, a client needs an authz URI to send a user to -- knowing the sc= ope and a base URI is just one way to build such an authz URI, being given = the authz URI is another.

--
James Manger

--0016362845088b127b048673359d-- From James.H.Manger@team.telstra.com Wed May 12 23:53:00 2010 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 C78E03A6A88 for ; Wed, 12 May 2010 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.036 X-Spam-Level: ** X-Spam-Status: No, score=2.036 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRjr+-iL6-Cf for ; Wed, 12 May 2010 23:53:00 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 852A53A6A6C for ; Wed, 12 May 2010 23:52:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,220,1272808800"; d="scan'208";a="2529071" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 13 May 2010 16:52:47 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5980"; a="1942406" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipccni.tcif.telstra.com.au with ESMTP; 13 May 2010 16:52:47 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Thu, 13 May 2010 16:52:47 +1000 From: "Manger, James H" To: Evan Gilbert Date: Thu, 13 May 2010 16:52:46 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcryXvM7bJh8Sj+7TVChwyJ89yKu9wAAFiaA Message-ID: <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <4BE3A5DC.5030601@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> 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 Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 06:53:00 -0000 RXZhbiwNCg0KPiBUaGUga2V5IHBvaW50IGlzIHRoYXQgdGhpcyBkaXNjb3ZlcnkgY292ZXJzIGEg bG90IG9mIHRoZSBzYW1lIGdyb3VuZHMgYXMgdGhlIHNpdGVzIHBhcmFtZXRlciwgYW5kIGl0J3Mg aGFyZCAgdG8gZGVmaW5lIHNlbWFudGljcyBhcm91bmQgYSBzaXRlcyBwYXJhbWV0ZXIgd2l0aG91 dCB1bmRlcnN0YW5kaW5nIHRoZSBzZW1hbnRpY3Mgb2Ygc2NvcGVzIGFuZCBBUEkgZW5kcG9pbnRz Lg0KDQpJIHN0cm9uZ2x5IGRpc2FncmVlLiBUaGUgc2VtYW50aWNzIGFyZSBjcnlzdGFsIGNsZWFy Og0KICAiSGVyZSBpcyBhIHRva2VuLiBJdCBpcyBJTlNFQ1VSRSB0byBzZW5kIGl0IGFueXdoZXJl IG5vdCBpbiB0aGlzIGxpc3QuIg0KVGhlc2Ugc2VtYW50aWNzIGFyZSB1c2VmdWwgcmVnYXJkbGVz cyBvZiB3aGF0IHRoZSBBUEkgZG9lcywgaG93IHRoZSBjbGllbnQgaXMgdXNpbmcgaXQsIG9yIGhv dyBtdWNoIChvciBob3cgbGl0dGxlKSB0aGUgY2xpZW50IGtub3dzIGFib3V0IHRoZSBBUEkuDQoN Cg0KPiBDbGllbnRzIG5lZWQgdG8gW2tub3ddIG1vcmUgYWJvdXQgdGhlc2UgbGlua3MgKGF0IGxl YXN0IHRoZSByZXNwb25zZSBmb3JtYXQpLg0KDQpUaGF0IGtub3dsZWRnZSBjb21lcyBmcm9tIG90 aGVyIHN0YW5kYXJkcyAoSFRNTCwgQXRvbSwgd2lraSBvZiByZWwgdmFsdWVzLi4uKSBhbmQgaXMg dG90YWxseSBpbmRlcGVuZGVudCBvZiB3aGV0aGVyIGEgdG9rZW4gc2hvdWxkIG9yIHNob3VsZCBu b3QgYmUgc2VudC4NCg0KDQo+IFRoZSBtZWNoYW5pc20gdGhleSB1c2UgdG8gZmluZCBvdXQgYWJv dXQgdGhlc2UgbGlua3MgLcKgZG9jdW1lbnRhdGlvbiwgZGlzY292ZXJ5LCBkYXRhIHJldHVybmVk IHdpdGggdG9rZW4gcmVxdWVzdCAtIGNvdWxkIGFsc28gcHJvdmlkZSB0aGUgaW5mb3JtYXRpb24g YWJvdXQgd2hldGhlciBhIHRva2VuIHNob3VsZCBiZSBzZW50IHRvIGEgcGFydGljdWxhciBBUEku DQoNCkNvdWxkLCBidXQgc2hvdWxkbid0IGFuZCBkb2Vzbid0IGluIHByYWN0aXNlLg0KSXQgaXMg bXVjaCBtdWNoIGJldHRlciB0byBoYXZlIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBob3cgdG8gdXNl IGEgdG9rZW4gc2VjdXJlbHkgZGVsaXZlcmVkIGF0IHRoZSBzYW1lIHRpbWUgJiBwbGFjZSBhcyBy ZWNlaXZpbmcgdGhhdCB0b2tlbiwgYW5kIHdpdGggbWluaW1hbCBhc3N1bXB0aW9ucyBhYm91dCBo b3cgbXVjaCB0aGUgY2xpZW50IGFwcHMga25vd3MgYWJvdXQgdGhlIHNlcnZpY2UuDQoNCg0KPiBJ IHNob3VsZCBiZSBtb3JlIGNvbmNyZXRlIGFib3V0IHRoZSB1c2UgY2FzZXMgSSBzZWUuIExldCdz IGFzc3VtZSB0aGVyZSdzIGFuIEFQSSB3aGVyZSB0aGVyZSBhcmUgdHdvIGVuZHBvaW50cywgZWFj aCB3aXRoIGFuIGFzc29jaWF0ZWQgcGVybWlzc2lvbg0KPiAtIGNvbnRhY3RzLmxpc3QgcGVybWlz c2lvbiAtPiBodHRwOi8vY29udGFjdHMuc2VydmljZXByb3ZpZGVyLmNvbS9jb250YWN0cy9saXN0 DQo+IC0gY2FsZW5kYXIuZ2V0IHBlcm1pc3Npb24gLT4gaHR0cDovL2NhbGVuZGFyLnNlcnZpY2Vw cm92aWRlci5jb20vY2FsZW5kYXIvZ2V0DQo+DQo+IElmIHRoZSByZXNwb25zZSB0byBhbiBhdXRo b3JpemF0aW9uIHJlcXVlc3QgaW5jbHVkZXMgdGhlIGF1dGhvcml6ZWQgc2NvcGVzIChjb250YWN0 cy5saXN0LCBjYWxlbmRhci5nZXQpLCB0aGVuIHRoZSAic2l0ZXMiIHBhcmFtZXRlciBpcyByZWR1 bmRhbnQuDQoNCkknbGwgYWRtaXQgdGhhdCAic2l0ZXMiIGlzIHJlZHVuZGFudCBpZiBhIGNsaWVu dCBoYXMgKnBlcmZlY3QqIGtub3dsZWRnZSBhYm91dCBhIHNlcnZpY2UsIGJ1dCBzbyBpcyBwcmV0 dHkgbXVjaCBhbnkgc3RhbmRhcmQgYXQgdGhhdCBwb2ludC4NCg0KQ29uc2lkZXIgYSBnZW5lcmlj IHNlYXJjaCBzcGlkZXIgdG9vbCB0aGF0IHlvdSBwb2ludCBhdCBodHRwOi8vY2FsZW5kYXIuc2Vy dmljZXByb3ZpZGVyLmNvbS9jYWxlbmRhci9nZXQuIEl0IGNhbiBkbyBpdHMgam9iIHdpdGggbm8g a25vd2xlZGdlIGFib3V0IHdoYXQgImNhbGVuZGFyLmdldCIgbWVhbnMgLS0gYnV0IGl0IHN0aWxs IG5lZWRzIHRvIGtub3cgKGFzIGl0IHNwaWRlcnMgYWxvbmcpIHdoZW4gaXQgaXMgc2FmZSB0byBl eHBvc2UgdGhlIHRva2VuLg0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K From torsten@lodderstedt.net Thu May 13 03:12:54 2010 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 5B5DF3A6AFA for ; Thu, 13 May 2010 03:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 Slpr0GgZbbS2 for ; Thu, 13 May 2010 03:12:53 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by core3.amsl.com (Postfix) with ESMTP id 4069F3A6B18 for ; Thu, 13 May 2010 03:12:17 -0700 (PDT) Received: from p4fff22e2.dip.t-dialin.net ([79.255.34.226] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OCVOg-0003EK-Lp; Thu, 13 May 2010 12:12:06 +0200 Message-ID: <4BEBD074.7020007@lodderstedt.net> Date: Thu, 13 May 2010 12:12:04 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Robert Sayre References: <20100510054516.2957E3A6B0C@core3.amsl.com> <98B37F7D0484184B9DBDCC44B6C8EDA3049F9EDF@S4DE9JSAAID.ost.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343B3AB474C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEA8999.7070205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEAD9B3.2040609@oracle.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47638@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4779B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: Prateek Mishra , "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.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, 13 May 2010 10:12:54 -0000 Am 13.05.2010 02:41, schrieb Robert Sayre: > On Wed, May 12, 2010 at 7:37 PM, Eran Hammer-Lahav wrote: > >> >>> Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff >>> grouped into one document. There seems to be consensus to do that, but it >>> still runs counter to the conventional wisdom. >>> >> Can you point to specific parts that should not be grouped together? >> > Sure, to give one example, I would make the device flow a separate > spec immediately. That seems only distantly related to other things in > the spec, and may not be really necessary by the time the standard > matures. > Why does this hold for the device flow and not for other flows? For us (Deutsche Telekom), the device flow is one of the most important pieces of the spec since we want to use OAuth for a variety of autonomous devices with limited input capabilities (Set Top Boxes, TV Sets, handsets, ....). regards, Torsten. > I mean, Facebook engineers have already said they felt comfortable > shipping certain pieces of the spec because they seem stable. Why > isn't the group hammering out nits in those pieces, writing test > suites, and declaring victory? You can always add more later. > > Anyway, I've said my piece on this point quite enough. Many new > readers will probably bring it up, though. That shouldn't be > surprising. > > From torsten@lodderstedt.net Thu May 13 03:46:03 2010 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 697303A6CBA for ; Thu, 13 May 2010 03:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 IkdN-raRX7HF for ; Thu, 13 May 2010 03:46:02 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id A95463A6CCD for ; Thu, 13 May 2010 03:38:25 -0700 (PDT) Received: from p4fff22e2.dip.t-dialin.net ([79.255.34.226] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OCVny-0002LD-TA for oauth@ietf.org; Thu, 13 May 2010 12:38:14 +0200 Message-ID: <4BEBD694.3090800@lodderstedt.net> Date: Thu, 13 May 2010 12:38:12 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] User and Client identity in the Assertion Flow 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, 13 May 2010 10:46:03 -0000 In my perception, we reached consensus in the thread "Autonomous clients and resource owners (editorial)" that the assertion flow should support clients acting on behalf of users, not only autonomous clients. The specification currently states "This flow is suitable when the client is acting autonomously or on behalf of the end-user (based on the content of the assertion used).", which is fine with me. Im struggling to understand how the flow handles the two required identities, the client and the end-user. I basically see two options: 1) the assertion attests both identities. I'm not aware of any identity framework attesting two identities in a single assertion. 2) If we assume the assertion attests the end-user's identity only, there is the need for additional parameters used to authenticate the client. From my point of view, the situation is similar to the "Username and Password Flow". There, the specification defines two credential sets (username/password and client_id/client_secret) two prove both identities. Therefore, I would propose to add optional client_id/client_secret parameters (or an Authorization header) to pass the client credentials to the assertion flow if the assertion contains the end-user identity. Alternatively, one could add another flow to the spec, probably called "User Assertion Flow". Any thoughts? regards, Torsten. From torsten@lodderstedt.net Thu May 13 04:10:02 2010 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 B5A903A6C58 for ; Thu, 13 May 2010 04:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 7Pa0hNLjdf9P for ; Thu, 13 May 2010 04:10:00 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id D3D523A6CCF for ; Thu, 13 May 2010 04:05:44 -0700 (PDT) Received: from p4fff22e2.dip.t-dialin.net ([79.255.34.226] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OCWEP-0002wW-NO for oauth@ietf.org; Thu, 13 May 2010 13:05:33 +0200 Message-ID: <4BEBDCFB.7090503@lodderstedt.net> Date: Thu, 13 May 2010 13:05:31 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] in-app logout? 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, 13 May 2010 11:10:02 -0000 OAuth currently focues on the issuance and usage of tokens. What about refresh token revocation/deletion? Several mobile apps today use long-living tokens as a means to log in to services. They typically also offer a button to log-off/log-out, which cause the app to delete the token from the device. From my point of view, it would be beneficially if the client could also discard the refresh token at the authorization server. Otherwise the token is still valid, which might be intransparent to the user. I propose to add another request "delete" (or cancel or logoff or logout) which allows the client to delete the refresh token (and the end-user authorization it represents) at the authorization server. Parameters: client_id, client_secret (optional), refresh_token The request must check whether the token has been issued to the calling client. Otherwise the request is refused. Thoughts? regards, Torsten. From paul.madsen@gmail.com Thu May 13 04:10:13 2010 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 96B253A6C62 for ; Thu, 13 May 2010 04:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] 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 6M2qMLJ5owFt for ; Thu, 13 May 2010 04:10:12 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 728D33A67AB for ; Thu, 13 May 2010 04:05:54 -0700 (PDT) Received: by vws13 with SMTP id 13so969906vws.31 for ; Thu, 13 May 2010 04:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=7c5kBEGhPdAlXraXC79QwCgx6oNnFHFvAV7SLJZl0+8=; b=V+B9ALosSQC6f8Ub8VFHenNyRt3uwiZcYerdDwyh3n/OrVhOh3cg6UVC9POrScU07U DUas7GyYQIAqk5QVwqsSPVTPJgDeKMVKUV+QXrDQIhpMY7AYoINBuI0aia4CS26d+4N2 7saPjdAGf6FG1j0yo+sDc/G8JGur93uS1wu3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=o8gPqcyns6aA7yHERtQSkd+uKM3lIcHJLKuPoe8rekWTLpvWitLek6aFsOy488Sqvk lBii+zk5uc/gJ54x038I1asdC7yMgWtz+EimGHbPnLNuBZ0gvqnqVTocX4AJey/BhEXF rxBiYGHcV+zRsjOeS3oh0TNbKbLid08UogMVE= Received: by 10.220.157.136 with SMTP id b8mr2133766vcx.170.1273748740470; Thu, 13 May 2010 04:05:40 -0700 (PDT) Received: from [192.168.0.175] (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id s9sm5166303vcr.15.2010.05.13.04.05.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 May 2010 04:05:39 -0700 (PDT) Message-ID: <4BEBDCFA.3020501@gmail.com> Date: Thu, 13 May 2010 07:05:30 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <4BEBD694.3090800@lodderstedt.net> In-Reply-To: <4BEBD694.3090800@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow 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, 13 May 2010 11:10:13 -0000 Torsten, have you thought about the relevance of the for identifying the client? Identify if not authenticate. On 5/13/2010 6:38 AM, Torsten Lodderstedt wrote: > In my perception, we reached consensus in the thread "Autonomous > clients and resource owners (editorial)" that the assertion flow > should support clients acting on behalf of users, not only autonomous > clients. > > The specification currently states "This flow is suitable when the > client is acting autonomously or on behalf of the end-user (based on > the content of the assertion used).", which is fine with me. > > Im struggling to understand how the flow handles the two required > identities, the client and the end-user. I basically see two options: > > 1) the assertion attests both identities. I'm not aware of any > identity framework attesting two identities in a single assertion. > > 2) If we assume the assertion attests the end-user's identity only, > there is the need for additional parameters used to authenticate the > client. From my point of view, the situation is similar to the > "Username and Password Flow". There, the specification defines two > credential sets (username/password and client_id/client_secret) two > prove both identities. > > Therefore, I would propose to add optional client_id/client_secret > parameters (or an Authorization header) to pass the client credentials > to the assertion flow if the assertion contains the end-user identity. > Alternatively, one could add another flow to the spec, probably called > "User Assertion Flow". > > Any thoughts? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Thu May 13 04:30:51 2010 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 251163A6AFA for ; Thu, 13 May 2010 04:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 7rtljcpAswzG for ; Thu, 13 May 2010 04:30:48 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by core3.amsl.com (Postfix) with ESMTP id 0AB263A6C48 for ; Thu, 13 May 2010 04:26:12 -0700 (PDT) Received: from p4fff22e2.dip.t-dialin.net ([79.255.34.226] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OCWYD-0005qh-IQ; Thu, 13 May 2010 13:26:01 +0200 Message-ID: <4BEBE1C8.1010109@lodderstedt.net> Date: Thu, 13 May 2010 13:26:00 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Madsen References: <4BEBD694.3090800@lodderstedt.net> <4BEBDCFA.3020501@gmail.com> In-Reply-To: <4BEBDCFA.3020501@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow 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, 13 May 2010 11:30:51 -0000 Am 13.05.2010 13:05, schrieb Paul Madsen: > Torsten, have you thought about the relevance of the for > identifying the client? > > Identify if not authenticate. > Thanks for your advice. I would not expect the issuer to by the client in that game. In my opinion a client could be a website, which obtains an assertion from an authorization server, let's assume a SAML assertion, during login. So the authorization server would be the issuer of the SAML assertion. In the next step, the client wants to exchange that assertion for an access token needed to access services on behalf of the client. I would expect the OAuth authorization server to validate the following aspects: - What is the issuer of the assertion and do I accept assertions from that particular issuer? - Is that particular client allowed to swap such assertions? - Do I know the end-user identified by the SAML assertions Subject? regards, Torsten. > > On 5/13/2010 6:38 AM, Torsten Lodderstedt wrote: >> In my perception, we reached consensus in the thread "Autonomous >> clients and resource owners (editorial)" that the assertion flow >> should support clients acting on behalf of users, not only autonomous >> clients. >> >> The specification currently states "This flow is suitable when the >> client is acting autonomously or on behalf of the end-user (based on >> the content of the assertion used).", which is fine with me. >> >> Im struggling to understand how the flow handles the two required >> identities, the client and the end-user. I basically see two options: >> >> 1) the assertion attests both identities. I'm not aware of any >> identity framework attesting two identities in a single assertion. >> >> 2) If we assume the assertion attests the end-user's identity only, >> there is the need for additional parameters used to authenticate the >> client. From my point of view, the situation is similar to the >> "Username and Password Flow". There, the specification defines two >> credential sets (username/password and client_id/client_secret) two >> prove both identities. >> >> Therefore, I would propose to add optional client_id/client_secret >> parameters (or an Authorization header) to pass the client >> credentials to the assertion flow if the assertion contains the >> end-user identity. Alternatively, one could add another flow to the >> spec, probably called "User Assertion Flow". >> >> Any thoughts? >> >> regards, >> Torsten. >> >> _______________________________________________ >> 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 Thu May 13 07:10:42 2010 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 924253A6B39 for ; Thu, 13 May 2010 07:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.365 X-Spam-Level: ** X-Spam-Status: No, score=2.365 tagged_above=-999 required=5 tests=[AWL=-1.158, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, J_CHICKENPOX_66=0.6, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hIvRwggnXWG for ; Thu, 13 May 2010 07:10:41 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 454683A6B3C for ; Thu, 13 May 2010 07:10:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,222,1272808800"; d="scan'208";a="2539629" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 14 May 2010 00:10:23 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5980"; a="1887993" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbvi.tcif.telstra.com.au with ESMTP; 14 May 2010 00:10:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 14 May 2010 00:10:23 +1000 From: "Manger, James H" To: Torsten Lodderstedt , "OAuth WG (oauth@ietf.org)" Date: Fri, 14 May 2010 00:10:21 +1000 Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: AcryjNMY8DGP5186QnuNYxlU4kPGzgAEzdCQ Message-ID: <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> References: <4BEBDCFB.7090503@lodderstedt.net> In-Reply-To: <4BEBDCFB.7090503@lodderstedt.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] in-app logout? 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, 13 May 2010 14:10:42 -0000 VG9yc3RlbiwNCg0KPiBXaGF0IGFib3V0IHJlZnJlc2ggdG9rZW4gcmV2b2NhdGlvbi9kZWxldGlv bj8NCg0KSFRUUCBhbHJlYWR5IGhhcyBhIG1ldGhvZCB0byBkbyB0aGlzOiBERUxFVEUNCkl0IGp1 c3QgbmVlZHMgZWFjaCB0b2tlbiB0byBoYXZlIGEgVVJJLg0KDQpUb2tlbnMgKGFsbW9zdCkgYWxy ZWFkeSBoYXZlIFVSSXMgLS0gaXRzIGp1c3Qgbm90IGltbWVkaWF0ZWx5IG9idmlvdXMgYmVjYXVz ZSB0aGUgVVJJIGhhcyB0byBiZSBidWlsdCBmcm9tIGEgY29tbW9uIHRva2VuIGVuZHBvaW50IGFu ZCBhIHJlZnJlc2hfdG9rZW4uDQoNCkkgdGhpbmsgaXQgd291bGQgaW1wcm92ZSB0aGUgc3BlYyBp ZiByZWZyZXNoX3Rva2VuIHdhcyByZW5hbWVkIHRvLCBzYXksIHRva2VuX2lkOyBhbmQgaXRzIHZh bHVlIGRlZmluZWQgYXMgYSBVUkkgKHdoaWNoIGNhbiBiZSBhIHJlbGF0aXZlIFVSSSBzbyB0aGUg c3RyaW5nIG1heSBub3QgbmVlZCB0byBjaGFuZ2UgYXQgYWxsKS4NCg0KVG8gcmVmcmVzaCBhIHRv a2VuIHlvdSBQT1NUIHRvIHRoZSB0b2tlbidzIFVSSS4NClRvIGRlbGV0ZSBhIHRva2VuIHlvdSBz ZW5kIGEgREVMRVRFIHJlcXVlc3QgdG8gdGhlIHRva2VuJ3MgVVJJLg0KDQpJdCBkb2Vzbid0IGNh dXNlIG1ham9yIGNoYW5nZXMsIGJ1dCB0aGVyZSBhcmUgc29tZSBiZW5lZml0cy4NCkl0IGlzIGEg bW9yZSB3ZWItc3R5bGUgZGVzaWduLg0KSXQgbGVhdmVzIG9ubHkgMSB0eXBlIG9mIHRva2VuIGlu IHRoZSBzcGVjIC0tIGFuIGFjY2VzcyB0b2tlbiAtLSB3aGljaCBzaW1wbGlmaWVzIHRoZSB0ZXh0 IGFuZCBhaWRzIHVuZGVyc3RhbmRpbmcuDQpUaGVyZSBhcmUgbm8gYXJndW1lbnRzIGFib3V0IGxl bmd0aCwgYWxsb3dlZCBjaGFycyBldGMgYmVjYXVzZSBpdCBpcyBhIFVSSSAtLSBhIHdlbGwta25v d24gdHlwZSwgb2Z0ZW4gd2l0aCBuYXRpdmUgc3VwcG9ydC4NCkl0cyBvYnZpb3VzIGhvdyB0byBk ZWxldGUgdGhlIHRva2VuIGFzIHRoZXJlIGlzIGEgc3RhbmRhcmQgSFRUUCBtZXRob2QgREVMRVRF IHRvIGFwcGx5IHRvIHRoZSB0b2tlbiBVUkkuDQoNCklmIGEgcGFydGljdWxhciBzZXJ2aWNlIHN1 cHBvcnRlZCBhbiBhZGRpdGlvbmFsIHdheSB0byBkZWxldGUgaXRlbXMgaW4gaXRzIEFQSSAoZWcg UE9TVCB3aXRoIGEgbWV0aG9kPWRlbGV0ZSBxdWVyeSBwYXJhbWV0ZXIpIHRoYXQgY291bGQgYXBw bHkgdG8gdGhlIE9BdXRoIHBhcnQgYXMgd2VsbC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From cmortimore@salesforce.com Thu May 13 08:26:32 2010 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 C50563A6919 for ; Thu, 13 May 2010 08:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=-3.023, BAYES_50=0.001, 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 r5ATb7Egx22r for ; Thu, 13 May 2010 08:26:31 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by core3.amsl.com (Postfix) with SMTP id 2B70D3A692C for ; Thu, 13 May 2010 08:26:31 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKS+waHdOFuaI2UF6erxLcHPTqis4ID1sY@postini.com; Thu, 13 May 2010 08:26:21 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 13 May 2010 08:26:21 -0700 From: Chuck Mortimore To: Torsten Lodderstedt , "oauth@ietf.org" Date: Thu, 13 May 2010 08:26:20 -0700 Thread-Topic: [OAUTH-WG] User and Client identity in the Assertion Flow Thread-Index: AcryiXf5aXu+gfSlQKqwwlsG/jDf0wAJys9x Message-ID: In-Reply-To: <4BEBD694.3090800@lodderstedt.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C811682C563Acmortimoresalesforcecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow 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, 13 May 2010 15:26:33 -0000 --_000_C811682C563Acmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Our plan is to treat SAML assertions passed over the assertion flow as bear= er assertions, so I believe we have everything we need contained within the= assertion (issuer + audience + signature). That being said, if we want th= is to be an extensible flow, not all assertion formats will be so transpare= nt. I think this is a reasonable suggestion, as long as the clientid/secret are= entirely optional. Not in support of a second User Assertion Flow. -cmort On 5/13/10 3:38 AM, "Torsten Lodderstedt" wrote: In my perception, we reached consensus in the thread "Autonomous clients and resource owners (editorial)" that the assertion flow should support clients acting on behalf of users, not only autonomous clients. The specification currently states "This flow is suitable when the client is acting autonomously or on behalf of the end-user (based on the content of the assertion used).", which is fine with me. Im struggling to understand how the flow handles the two required identities, the client and the end-user. I basically see two options: 1) the assertion attests both identities. I'm not aware of any identity framework attesting two identities in a single assertion. 2) If we assume the assertion attests the end-user's identity only, there is the need for additional parameters used to authenticate the client. From my point of view, the situation is similar to the "Username and Password Flow". There, the specification defines two credential sets (username/password and client_id/client_secret) two prove both identities. Therefore, I would propose to add optional client_id/client_secret parameters (or an Authorization header) to pass the client credentials to the assertion flow if the assertion contains the end-user identity. Alternatively, one could add another flow to the spec, probably called "User Assertion Flow". Any thoughts? regards, Torsten. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C811682C563Acmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] User and Client identity in the Assertion Flow</TITLE= > </HEAD> <BODY> <FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:11pt'>Our plan is to = treat SAML assertions passed over the assertion flow as bearer assertions, = so I believe we have everything we need contained within the assertion (iss= uer + audience + signature).  That being said, if we want this to be a= n extensible flow, not all assertion formats will be so transparent. <BR> <BR> I think this is a reasonable suggestion, as long as the clientid/secret are= entirely optional.    Not in support of a second User Asser= tion Flow.<BR> <BR> -cmort<BR> <BR> <BR> On 5/13/10 3:38 AM, "Torsten Lodderstedt" <<a href=3D"torsten@= lodderstedt.net">torsten@lodderstedt.net</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'>In my perception, we reached consensus in the thread "Auton= omous clients<BR> and resource owners (editorial)" that the assertion flow should suppor= t<BR> clients acting on behalf of users, not only autonomous clients.<BR> <BR> The specification currently states "This flow is suitable when the<BR> client is acting autonomously or on behalf of the end-user (based on the<BR= > content of the assertion used).", which is fine with me.<BR> <BR> Im struggling to understand how the flow handles the two required<BR> identities, the client and the end-user. I basically see two options:<BR> <BR> 1) the assertion attests both identities. I'm not aware of any identity<BR> framework attesting two identities in a single assertion.<BR> <BR> 2) If we assume the assertion attests the end-user's identity only,<BR> there is the need for additional parameters used to authenticate the<BR> client. From my point of view, the situation is similar to the "Userna= me<BR> and Password Flow". There, the specification defines two credential se= ts<BR> (username/password and client_id/client_secret) two prove both identities.<= BR> <BR> Therefore, I would propose to add optional client_id/client_secret<BR> parameters (or an Authorization header) to pass the client credentials<BR> to the assertion flow if the assertion contains the end-user identity.<BR> Alternatively, one could add another flow to the spec, probably called<BR> "User Assertion Flow".<BR> <BR> Any thoughts?<BR> <BR> regards,<BR> Torsten.<BR> <BR> _______________________________________________<BR> OAuth mailing list<BR> <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.or= g/mailman/listinfo/oauth</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C811682C563Acmortimoresalesforcecom_-- From beaton@google.com Thu May 13 08:50:36 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839063A6B90 for <oauth@core3.amsl.com>; Thu, 13 May 2010 08:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.755 X-Spam-Level: X-Spam-Status: No, score=-105.755 tagged_above=-999 required=5 tests=[AWL=0.222, 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 2OUGZo3o5IFw for <oauth@core3.amsl.com>; Thu, 13 May 2010 08:50:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 830D53A68E1 for <oauth@ietf.org>; Thu, 13 May 2010 08:50:34 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o4DFoOtu000399 for <oauth@ietf.org>; Thu, 13 May 2010 08:50:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273765824; bh=W9KMaQnjw6VgIrlE25G8t729KXA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=JP5Ixsn6+yje4EB2UbRwwhfKtVE40F6OBlmTodQFL+uOGj5ZaoUsVwU1TKTavMb7W L7ipxUipNx31GTEUkRiKw== 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=BuUyYU5+k0tiDOiNrhIcknqO1GQS7Yz6ZghXn/GoCMIt3+mreTgDnlB+ZCoFt8kDZ szezazSt8NPkGYXIK2S9g== Received: from pvc22 (pvc22.prod.google.com [10.241.209.150]) by wpaz24.hot.corp.google.com with ESMTP id o4DFoMtp006472 for <oauth@ietf.org>; Thu, 13 May 2010 08:50:23 -0700 Received: by pvc22 with SMTP id 22so1048904pvc.37 for <oauth@ietf.org>; Thu, 13 May 2010 08:50:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.196.15 with SMTP id t15mr6510799wff.238.1273765822481; Thu, 13 May 2010 08:50:22 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Thu, 13 May 2010 08:50:22 -0700 (PDT) In-Reply-To: <C811682C.563A%cmortimore@salesforce.com> References: <4BEBD694.3090800@lodderstedt.net> <C811682C.563A%cmortimore@salesforce.com> Date: Thu, 13 May 2010 08:50:22 -0700 Message-ID: <AANLkTimYJ3TqH9swKm4B9DOiHoHjc6QCx9AJbwxXsGIZ@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Chuck Mortimore <cmortimore@salesforce.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 15:50:36 -0000 On Thu, May 13, 2010 at 8:26 AM, Chuck Mortimore <cmortimore@salesforce.com> wrote: > Our plan is to treat SAML assertions passed over the assertion flow as > bearer assertions, so I believe we have everything we need contained with= in > the assertion (issuer + audience + signature). =A0That being said, if we = want > this to be an extensible flow, not all assertion formats will be so > transparent. > > I think this is a reasonable suggestion, as long as the clientid/secret a= re > entirely optional. =A0=A0=A0Not in support of a second User Assertion Flo= w. Yes. This sounds right to me. Cheers, Brian From uidude@google.com Thu May 13 09:01:31 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609BF3A695E for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.825 X-Spam-Level: X-Spam-Status: No, score=-99.825 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, 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 LfzoFtFnQhH3 for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:01:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 353243A68B3 for <oauth@ietf.org>; Thu, 13 May 2010 09:01:08 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o4DG0qOb032346 for <oauth@ietf.org>; Thu, 13 May 2010 09:00:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273766453; bh=7kGlo/J12si9a823kmdTNcJRCcE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HbS+OflRrsttZKSqBQJZ13PdTg+eAczUKS73PgUMwaUKsLLMAFbGJBLvZnEbtYXH8 peSL+TpNd5F5T2fJYwTvw== 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=OVlCaEYQU1SuCe5WG3GYiWu0xzmIVVKux5wiL6XImREW3iKYP9zvB6A6IfRrtbBIa S7hXROz0DHsBVqojuldYA== Received: from yxe5 (yxe5.prod.google.com [10.190.2.5]) by wpaz5.hot.corp.google.com with ESMTP id o4DG0QtM023375 for <oauth@ietf.org>; Thu, 13 May 2010 09:00:51 -0700 Received: by yxe5 with SMTP id 5so401150yxe.3 for <oauth@ietf.org>; Thu, 13 May 2010 09:00:51 -0700 (PDT) Received: by 10.150.187.13 with SMTP id k13mr474090ybf.323.1273766448002; Thu, 13 May 2010 09:00:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.94.18 with HTTP; Thu, 13 May 2010 09:00:27 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <AANLkTincZ8_0-t2r_Ey9BestA_knMciYsxRLyHcOvSVO@mail.gmail.com> <g2xfd6741651005071106if93ba794q7e9739669eb22fc2@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> From: Evan Gilbert <uidude@google.com> Date: Thu, 13 May 2010 09:00:27 -0700 Message-ID: <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=000e0cd6ad8eab463c04867bdcd2 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 16:01:31 -0000 --000e0cd6ad8eab463c04867bdcd2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 12, 2010 at 11:52 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Evan, > > > The key point is that this discovery covers a lot of the same grounds as > the sites parameter, and it's hard to define semantics around a sites > parameter without understanding the semantics of scopes and API endpoints. > > I strongly disagree. The semantics are crystal clear: > "Here is a token. It is INSECURE to send it anywhere not in this list." > These semantics are useful regardless of what the API does, how the client > is using it, or how much (or how little) the client knows about the API. > To expand - it's hard to define *useful* semantics around a sites parameter without understanding the semantics of scopes and API endpoints. Yes, you can define crystal clear semantics, but these are not useful unless they work well with the way developers figure out the endpoints to call APIs. > > > > Clients need to [know] more about these links (at least the response > format). > > That knowledge comes from other standards (HTML, Atom, wiki of rel > values...) and is totally independent of whether a token should or should > not be sent. > In our use cases, clients almost always need to know more about the API: - How to call directly - we have no API endpoints that are only arrived at by links - Response format of the data > > > > The mechanism they use to find out about these links - documentation, > discovery, data returned with token request - could also provide the > information about whether a token should be sent to a particular API. > > Could, but shouldn't and doesn't in practise. > It is much much better to have the information about how to use a token > securely delivered at the same time & place as receiving that token, and > with minimal assumptions about how much the client apps knows about the > service. > So why wouldn't we return a list of specific API endpoints instead of a "sites" parameter? Developers are going to call the APIs endpoints that they know about. If there is a conflict between this and the sites parameter, what should they do? For example, if facebook returns a sites parameter " https://unknown.facebook.com/", do we think the developer is going to not try to use the access token on https://graph.facebook.com/<https://graph.facebook.com/*> ? Separating the concept of sites from API endpoints feels like a bad idea. Discovery / docs will give you a list of URLs where you should send tokens. The "sites" parameter will give you a list of URLs where you can send tokens. This is redundant, and will lead to developers / libraries not respecting the sites parameter. If developers / libraries don't respect it, then the service can't rely on it for enforcing security. Another note: Where do we anticipate clients storing the sites parameter in the User-Agent flow? Right now the access token can be set as an HTTP cookie by the client. Do we expect them to set a separate "sites" cookie and respect this on their server when making requests? This seems complicated. > > > I should be more concrete about the use cases I see. Let's assume there's > an API where there are two endpoints, each with an associated permission > > - contacts.list permission -> > http://contacts.serviceprovider.com/contacts/list > > - calendar.get permission -> > http://calendar.serviceprovider.com/calendar/get > > > > If the response to an authorization request includes the authorized > scopes (contacts.list, calendar.get), then the "sites" parameter is > redundant. > > I'll admit that "sites" is redundant if a client has *perfect* knowledge > about a service, but so is pretty much any standard at that point. > > Consider a generic search spider tool that you point at > http://calendar.serviceprovider.com/calendar/get. It can do its job with > no knowledge about what "calendar.get" means -- but it still needs to know > (as it spiders along) when it is safe to expose the token. > How does the generic search spider know to call to http://calendar.serviceprovider.com/calendar/get in the first place? > > > -- > James Manger > > --000e0cd6ad8eab463c04867bdcd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Wed, May 12, 2010 at 11:52 PM, Manger= , James H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Manger@team.telst= ra.com">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex;"> Evan,<br> <div class=3D"im"><br> > The key point is that this discovery covers a lot of the same grounds = as the sites parameter, and it's hard =A0to define semantics around a s= ites parameter without understanding the semantics of scopes and API endpoi= nts.<br> <br> </div>I strongly disagree. The semantics are crystal clear:<br> =A0"Here is a token. It is INSECURE to send it anywhere not in this l= ist."<br> These semantics are useful regardless of what the API does, how the client = is using it, or how much (or how little) the client knows about the API.<br= ></blockquote><div><br></div><div>To expand - it's hard to define *usef= ul* semantics=A0around a sites parameter without understanding the semantic= s of scopes and API endpoints. Yes, you can define crystal clear semantics,= but these are not useful unless they work well with the way developers fig= ure out the endpoints to call APIs.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> <br> <br> > Clients need to [know] more about these links (at least the response f= ormat).<br> <br> That knowledge comes from other standards (HTML, Atom, wiki of rel values..= .) and is totally independent of whether a token should or should not be se= nt.<br></blockquote><div><br></div><div>In our use cases, clients almost al= ways need to know more about the API:</div> <div>- How to call directly - we have no API endpoints that are only arrive= d at by links</div>- Response format of the data<div>=A0</div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex;"> <div class=3D"im"><br> <br> > The mechanism they use to find out about these links -=A0documentation= , discovery, data returned with token request - could also provide the info= rmation about whether a token should be sent to a particular API.<br> <br> </div>Could, but shouldn't and doesn't in practise.<br> It is much much better to have the information about how to use a token sec= urely delivered at the same time & place as receiving that token, and w= ith minimal assumptions about how much the client apps knows about the serv= ice.<br> </blockquote><div><br></div><div>So why wouldn't we return a list of sp= ecific API endpoints instead of a "sites" parameter?</div><div><b= r></div><div>Developers are going to call the APIs endpoints that they know= about. If there is a conflict between this and the sites parameter, what s= hould they do? For example, if facebook returns a sites parameter "<a = href=3D"https://unknown.facebook.com/">https://unknown.facebook.com/</a>&qu= ot;, do we think the developer is going to not try to use the access token = on=A0<span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><a href=3D"https://graph.= facebook.com/*" target=3D"_blank" style=3D"color: rgb(0, 0, 204); ">https:/= /graph.facebook.com/</a>=A0?=A0</span></div> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><br></span></div><div><sp= an class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; font= -size: 13px; border-collapse: collapse; ">Separating the concept of sites f= rom API endpoints feels like a bad idea. Discovery / docs will give you a l= ist of URLs where you should send tokens. The "sites" parameter w= ill give you a list of URLs where you can send tokens. This is redundant, a= nd will lead to developers / libraries not respecting the sites parameter. = If developers / libraries don't respect it, then the service can't = rely on it for enforcing security.</span></div> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><br></span></div><div><sp= an class=3D"Apple-style-span" style=3D"font-family: arial, sans-serif; font= -size: 13px; border-collapse: collapse; ">Another note: Where do we anticip= ate clients storing the sites parameter in the User-Agent flow? Right now t= he access token can be set as an HTTP cookie by the client. Do we expect th= em to set a separate "sites" cookie and respect this on their ser= ver when making requests? This seems complicated.</span></div> <div><span class=3D"Apple-style-span" style=3D"font-family: arial, sans-ser= if; font-size: 13px; border-collapse: collapse; "><br></span></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex;"> <div class=3D"im"><br> <br> > I should be more concrete about the use cases I see. Let's assume = there's an API where there are two endpoints, each with an associated p= ermission<br> > - contacts.list permission -> <a href=3D"http://contacts.servicepro= vider.com/contacts/list" target=3D"_blank">http://contacts.serviceprovider.= com/contacts/list</a><br> > - calendar.get permission -> <a href=3D"http://calendar.serviceprov= ider.com/calendar/get" target=3D"_blank">http://calendar.serviceprovider.co= m/calendar/get</a><br> ><br> > If the response to an authorization request includes the authorized sc= opes (contacts.list, calendar.get), then the "sites" parameter is= redundant.<br> <br> </div>I'll admit that "sites" is redundant if a client has *p= erfect* knowledge about a service, but so is pretty much any standard at th= at point.<br> <br> Consider a generic search spider tool that you point at <a href=3D"http://c= alendar.serviceprovider.com/calendar/get" target=3D"_blank">http://calendar= .serviceprovider.com/calendar/get</a>. It can do its job with no knowledge = about what "calendar.get" means -- but it still needs to know (as= it spiders along) when it is safe to expose the token.<br> </blockquote><div><br></div><div>How does the generic search spider know to= call to <a href=3D"http://calendar.serviceprovider.com/calendar/get">http:= //calendar.serviceprovider.com/calendar/get</a> in the first place?</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> <br> <br> --<br> <font color=3D"#888888">James Manger<br> <br> </font></blockquote></div><br> --000e0cd6ad8eab463c04867bdcd2-- From eran@hueniverse.com Thu May 13 09:02:20 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBC53A68B3 for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 K7HEVyJc4yj0 for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:02:19 -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 80BA43A6B12 for <oauth@ietf.org>; Thu, 13 May 2010 09:02:11 -0700 (PDT) Received: (qmail 30314 invoked from network); 13 May 2010 16:02:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 May 2010 16:02:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 13 May 2010 09:01:55 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: Thu, 13 May 2010 09:02:09 -0700 Thread-Topic: [OAUTH-WG] User and Client identity in the Assertion Flow Thread-Index: AcrytAQPy1v3fy9uT1e2XqKmkm66jwAAZhEw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB478CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BEBD694.3090800@lodderstedt.net> <C811682C.563A%cmortimore@salesforce.com> <AANLkTimYJ3TqH9swKm4B9DOiHoHjc6QCx9AJbwxXsGIZ@mail.gmail.com> In-Reply-To: <AANLkTimYJ3TqH9swKm4B9DOiHoHjc6QCx9AJbwxXsGIZ@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 16:02:20 -0000 Will be added to -05. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Thursday, May 13, 2010 8:50 AM > To: Chuck Mortimore > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow >=20 > On Thu, May 13, 2010 at 8:26 AM, Chuck Mortimore > <cmortimore@salesforce.com> wrote: > > Our plan is to treat SAML assertions passed over the assertion flow as > > bearer assertions, so I believe we have everything we need contained > > within the assertion (issuer + audience + signature). =A0That being > > said, if we want this to be an extensible flow, not all assertion > > formats will be so transparent. > > > > I think this is a reasonable suggestion, as long as the > > clientid/secret are entirely optional. =A0=A0=A0Not in support of a sec= ond User > Assertion Flow. >=20 > Yes. This sounds right to me. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu May 13 09:09:45 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A163A6926 for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-1.628, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] 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 akgu-irv0y4X for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:09:37 -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 B83DD3A685A for <oauth@ietf.org>; Thu, 13 May 2010 09:09:36 -0700 (PDT) Received: (qmail 4241 invoked from network); 13 May 2010 16:09:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 May 2010 16:08:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 13 May 2010 09:08:38 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Evan Gilbert <uidude@google.com>, "Manger, James H" <James.H.Manger@team.telstra.com> Date: Thu, 13 May 2010 09:08:51 -0700 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcrytY2ImorAcoLOTa690fK2MLAxCAAAHtjw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <AANLkTincZ8_0-t2r_Ey9BestA_knMciYsxRLyHcOvSVO@mail.gmail.com> <g2xfd6741651005071106if93ba794q7e9739669eb22fc2@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> In-Reply-To: <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 16:09:45 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are trying to match a mechanism designed for automatic discovery with a= system designed to require paperwork. It sounds like for your use cases, y= ou will not be using this optional parameter and just document how to use y= our API (i.e. hardcode your security setup and API format). The whole point of this is that the developer isn't involved. The library t= akes care of everything. All the developer does is ask to get a protected r= esource. The library will check if it already has a valid token for that re= source (based on the security restrictions provided by the sites parameter,= and the scope requirements - two very separate things). So yes - if your developers have plenty of stuff to hardcode already, this = adds little value. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= van Gilbert Sent: Thursday, May 13, 2010 9:00 AM To: Manger, James H Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Wed, May 12, 2010 at 11:52 PM, Manger, James H <James.H.Manger@team.tels= tra.com<mailto:James.H.Manger@team.telstra.com>> wrote: Evan, > The key point is that this discovery covers a lot of the same grounds as = the sites parameter, and it's hard to define semantics around a sites para= meter without understanding the semantics of scopes and API endpoints. I strongly disagree. The semantics are crystal clear: "Here is a token. It is INSECURE to send it anywhere not in this list." These semantics are useful regardless of what the API does, how the client = is using it, or how much (or how little) the client knows about the API. To expand - it's hard to define *useful* semantics around a sites parameter= without understanding the semantics of scopes and API endpoints. Yes, you = can define crystal clear semantics, but these are not useful unless they wo= rk well with the way developers figure out the endpoints to call APIs. > Clients need to [know] more about these links (at least the response form= at). That knowledge comes from other standards (HTML, Atom, wiki of rel values..= .) and is totally independent of whether a token should or should not be se= nt. In our use cases, clients almost always need to know more about the API: - How to call directly - we have no API endpoints that are only arrived at = by links - Response format of the data > The mechanism they use to find out about these links - documentation, dis= covery, data returned with token request - could also provide the informati= on about whether a token should be sent to a particular API. Could, but shouldn't and doesn't in practise. It is much much better to have the information about how to use a token sec= urely delivered at the same time & place as receiving that token, and with = minimal assumptions about how much the client apps knows about the service. So why wouldn't we return a list of specific API endpoints instead of a "si= tes" parameter? Developers are going to call the APIs endpoints that they know about. If th= ere is a conflict between this and the sites parameter, what should they do= ? For example, if facebook returns a sites parameter "https://unknown.faceb= ook.com/", do we think the developer is going to not try to use the access = token on https://graph.facebook.com/<https://graph.facebook.com/*> ? Separating the concept of sites from API endpoints feels like a bad idea. D= iscovery / docs will give you a list of URLs where you should send tokens. = The "sites" parameter will give you a list of URLs where you can send token= s. This is redundant, and will lead to developers / libraries not respectin= g the sites parameter. If developers / libraries don't respect it, then the= service can't rely on it for enforcing security. Another note: Where do we anticipate clients storing the sites parameter in= the User-Agent flow? Right now the access token can be set as an HTTP cook= ie by the client. Do we expect them to set a separate "sites" cookie and re= spect this on their server when making requests? This seems complicated. > I should be more concrete about the use cases I see. Let's assume there's= an API where there are two endpoints, each with an associated permission > - contacts.list permission -> http://contacts.serviceprovider.com/contact= s/list > - calendar.get permission -> http://calendar.serviceprovider.com/calendar= /get > > If the response to an authorization request includes the authorized scope= s (contacts.list, calendar.get), then the "sites" parameter is redundant. I'll admit that "sites" is redundant if a client has *perfect* knowledge ab= out a service, but so is pretty much any standard at that point. Consider a generic search spider tool that you point at http://calendar.ser= viceprovider.com/calendar/get. It can do its job with no knowledge about wh= at "calendar.get" means -- but it still needs to know (as it spiders along)= when it is safe to expose the token. How does the generic search spider know to call to http://calendar.servicep= rovider.com/calendar/get in the first place? -- James Manger --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.apple-style-span {mso-style-name:apple-style-span;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>You are t= rying to match a mechanism designed for automatic discovery with a system d= esigned to require paperwork. It sounds like for your use cases, you will n= ot be using this optional parameter and just document how to use your API (= i.e. hardcode your security setup and API format).<o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sa= ns-serif";color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>The whole point of this is that the developer isn’t involved. T= he library takes care of everything. All the developer does is ask to get a= protected resource. The library will check if it already has a valid token= for that resource (based on the security restrictions provided by the site= s parameter, and the scope requirements – two very separate things).<= o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;f= ont-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></= p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri= ","sans-serif";color:#1F497D'>So yes – if your developers have plenty= of stuff to hardcode already, this adds little value.<o:p></o:p></span></p= ><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri"= ,"sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNorm= al><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color= :#1F497D'>EHL<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font= -size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> <= /o:p></span></p><div style=3D'border:none;border-left:solid blue 1.5pt;padd= ing:0in 0in 0in 4.0pt'><div><div style=3D'border:none;border-top:solid #B5C= 4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D= 'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> oauth-bounces= @ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Evan Gilbert<= br><b>Sent:</b> Thursday, May 13, 2010 9:00 AM<br><b>To:</b> Manger, James = H<br><b>Cc:</b> OAuth WG<br><b>Subject:</b> Re: [OAUTH-WG] Indicating sites= where a token is valid<o:p></o:p></span></p></div></div><p class=3DMsoNorm= al><o:p> </o:p></p><p class=3DMsoNormal style=3D'margin-bottom:12.0pt'= ><o:p> </o:p></p><div><p class=3DMsoNormal>On Wed, May 12, 2010 at 11:= 52 PM, Manger, James H <<a href=3D"mailto:James.H.Manger@team.telstra.co= m">James.H.Manger@team.telstra.com</a>> wrote:<o:p></o:p></p><p class=3D= MsoNormal>Evan,<o:p></o:p></p><div><p class=3DMsoNormal style=3D'margin-bot= tom:12.0pt'><br>> The key point is that this discovery covers a lot of t= he same grounds as the sites parameter, and it's hard  to define seman= tics around a sites parameter without understanding the semantics of scopes= and API endpoints.<o:p></o:p></p></div><p class=3DMsoNormal>I strongly dis= agree. The semantics are crystal clear:<br> "Here is a token. It = is INSECURE to send it anywhere not in this list."<br>These semantics = are useful regardless of what the API does, how the client is using it, or = how much (or how little) the client knows about the API.<o:p></o:p></p><div= ><p class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>= To expand - it's hard to define *useful* semantics around a sites para= meter without understanding the semantics of scopes and API endpoints. Yes,= you can define crystal clear semantics, but these are not useful unless th= ey work well with the way developers figure out the endpoints to call APIs.= <o:p></o:p></p></div><div><p class=3DMsoNormal> <o:p></o:p></p></div><= blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=3DMsoNormal><br= ><br>> Clients need to [know] more about these links (at least the respo= nse format).<br><br>That knowledge comes from other standards (HTML, Atom, = wiki of rel values...) and is totally independent of whether a token should= or should not be sent.<o:p></o:p></p></blockquote><div><p class=3DMsoNorma= l><o:p> </o:p></p></div><div><p class=3DMsoNormal>In our use cases, cl= ients almost always need to know more about the API:<o:p></o:p></p></div><d= iv><p class=3DMsoNormal>- How to call directly - we have no API endpoints t= hat are only arrived at by links<o:p></o:p></p></div><p class=3DMsoNormal>-= Response format of the data<o:p></o:p></p><div><p class=3DMsoNormal> = <o:p></o:p></p></div><blockquote style=3D'border:none;border-left:solid #CC= CCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><d= iv><p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br><br>> The mec= hanism they use to find out about these links - documentation, discove= ry, data returned with token request - could also provide the information a= bout whether a token should be sent to a particular API.<o:p></o:p></p></di= v><p class=3DMsoNormal>Could, but shouldn't and doesn't in practise.<br>It = is much much better to have the information about how to use a token secure= ly delivered at the same time & place as receiving that token, and with= minimal assumptions about how much the client apps knows about the service= .<o:p></o:p></p></blockquote><div><p class=3DMsoNormal><o:p> </o:p></p= ></div><div><p class=3DMsoNormal>So why wouldn't we return a list of specif= ic API endpoints instead of a "sites" parameter?<o:p></o:p></p></= div><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMs= oNormal>Developers are going to call the APIs endpoints that they know abou= t. If there is a conflict between this and the sites parameter, what should= they do? For example, if facebook returns a sites parameter "<a href= =3D"https://unknown.facebook.com/">https://unknown.facebook.com/</a>",= do we think the developer is going to not try to use the access token on&n= bsp;<span class=3Dapple-style-span><span style=3D'font-size:10.0pt;font-fam= ily:"Arial","sans-serif"'><a href=3D"https://graph.facebook.com/*" target= =3D"_blank"><span style=3D'color:#0000CC'>https://graph.facebook.com/</span= ></a> ? </span></span><o:p></o:p></p></div><div><p class=3DMsoNor= mal><o:p> </o:p></p></div><div><p class=3DMsoNormal><span class=3Dappl= e-style-span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-seri= f"'>Separating the concept of sites from API endpoints feels like a bad ide= a. Discovery / docs will give you a list of URLs where you should send toke= ns. The "sites" parameter will give you a list of URLs where you = can send tokens. This is redundant, and will lead to developers / libraries= not respecting the sites parameter. If developers / libraries don't respec= t it, then the service can't rely on it for enforcing security.</span></spa= n><o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></div= ><div><p class=3DMsoNormal><span class=3Dapple-style-span><span style=3D'fo= nt-size:10.0pt;font-family:"Arial","sans-serif"'>Another note: Where do we = anticipate clients storing the sites parameter in the User-Agent flow? Righ= t now the access token can be set as an HTTP cookie by the client. Do we ex= pect them to set a separate "sites" cookie and respect this on th= eir server when making requests? This seems complicated.</span></span><o:p>= </o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><block= quote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in = 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=3DMsoNormal sty= le=3D'margin-bottom:12.0pt'><br><br>> I should be more concrete about th= e use cases I see. Let's assume there's an API where there are two endpoint= s, each with an associated permission<br>> - contacts.list permission -&= gt; <a href=3D"http://contacts.serviceprovider.com/contacts/list" target=3D= "_blank">http://contacts.serviceprovider.com/contacts/list</a><br>> - ca= lendar.get permission -> <a href=3D"http://calendar.serviceprovider.com/= calendar/get" target=3D"_blank">http://calendar.serviceprovider.com/calenda= r/get</a><br>><br>> If the response to an authorization request inclu= des the authorized scopes (contacts.list, calendar.get), then the "sit= es" parameter is redundant.<o:p></o:p></p></div><p class=3DMsoNormal>I= 'll admit that "sites" is redundant if a client has *perfect* kno= wledge about a service, but so is pretty much any standard at that point.<b= r><br>Consider a generic search spider tool that you point at <a href=3D"ht= tp://calendar.serviceprovider.com/calendar/get" target=3D"_blank">http://ca= lendar.serviceprovider.com/calendar/get</a>. It can do its job with no know= ledge about what "calendar.get" means -- but it still needs to kn= ow (as it spiders along) when it is safe to expose the token.<o:p></o:p></p= ></blockquote><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>How does the generic search spider know to call to <a hre= f=3D"http://calendar.serviceprovider.com/calendar/get">http://calendar.serv= iceprovider.com/calendar/get</a> in the first place?<o:p></o:p></p></div><d= iv><p class=3DMsoNormal> <o:p></o:p></p></div><blockquote style=3D'bor= der:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-l= eft:4.8pt;margin-right:0in'><p class=3DMsoNormal style=3D'margin-bottom:12.= 0pt'><br><br>--<br><span style=3D'color:#888888'>James Manger</span><o:p></= o:p></p></blockquote></div><p class=3DMsoNormal><o:p> </o:p></p></div>= </div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5P3PW5EX1MB01E_-- From torsten@lodderstedt.net Thu May 13 09:12:16 2010 Return-Path: <torsten@lodderstedt.net> 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 14BA53A6B12 for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 PEtU9crkjuvc for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:12:15 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 0D97D3A6B27 for <oauth@ietf.org>; Thu, 13 May 2010 09:12:14 -0700 (PDT) Received: from [79.255.34.226] (helo=[192.168.71.22]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OCb12-0000gj-2g; Thu, 13 May 2010 18:12:04 +0200 References: <4BEBD694.3090800@lodderstedt.net> <C811682C.563A%cmortimore@salesforce.com> <AANLkTimYJ3TqH9swKm4B9DOiHoHjc6QCx9AJbwxXsGIZ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB478CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: <31255129-569C-4D7B-8A9B-5478681A90DF@lodderstedt.net> From: Torsten Lodderstedt <torsten@lodderstedt.net> To: Eran Hammer-Lahav <eran@hueniverse.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB478CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Thu, 13 May 2010 18:11:43 +0200 X-Df-Sender: 141509 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 16:12:16 -0000 Thanks. Am 13.05.2010 um 18:02 schrieb Eran Hammer-Lahav <eran@hueniverse.com>: > Will be added to -05. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >> Of Brian Eaton >> Sent: Thursday, May 13, 2010 8:50 AM >> To: Chuck Mortimore >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] User and Client identity in the Assertion >> Flow >> >> On Thu, May 13, 2010 at 8:26 AM, Chuck Mortimore >> <cmortimore@salesforce.com> wrote: >>> Our plan is to treat SAML assertions passed over the assertion >>> flow as >>> bearer assertions, so I believe we have everything we need contained >>> within the assertion (issuer + audience + signature). That being >>> said, if we want this to be an extensible flow, not all assertion >>> formats will be so transparent. >>> >>> I think this is a reasonable suggestion, as long as the >>> clientid/secret are entirely optional. Not in support of a >>> second User >> Assertion Flow. >> >> Yes. This sounds right to me. >> >> 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 uidude@google.com Thu May 13 09:16:38 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A83E3A6877 for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.773 X-Spam-Level: X-Spam-Status: No, score=-103.773 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqs3jBF+2nkx for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:16:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DE6903A6926 for <oauth@ietf.org>; Thu, 13 May 2010 09:16:34 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o4DGGObB012153 for <oauth@ietf.org>; Thu, 13 May 2010 09:16:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273767384; bh=l2ZOUBKFBb7gtgwcdr9xKDAudgU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=xZu14Zhk3Yc/CE1jO6diTS07LhfMBO6ytAlyEyLJPaa64zduNGkdscUotJoiNK+Vj BczUBOzd/fJ+qbjntjRng== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=EVJzmfL/OpumgOjq8S3tUSd0o8c2/g/B43Y3boYL0BWx4LC/M8Z77w1+JAj8sYnax nWXo8NNZN/5NJqmNjaNmg== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by hpaq2.eem.corp.google.com with ESMTP id o4DGGMuG014594 for <oauth@ietf.org>; Thu, 13 May 2010 09:16:22 -0700 Received: by gwb11 with SMTP id 11so738580gwb.1 for <oauth@ietf.org>; Thu, 13 May 2010 09:16:21 -0700 (PDT) Received: by 10.150.55.9 with SMTP id d9mr568557yba.238.1273767376304; Thu, 13 May 2010 09:16:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.94.18 with HTTP; Thu, 13 May 2010 09:15:56 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert <uidude@google.com> Date: Thu, 13 May 2010 09:15:56 -0700 Message-ID: <AANLkTik0dKSLLVQDhodhFsO--bR43PvZKborWG1uK15t@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary=000e0cd70f4afdba1c04867c1386 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 16:16:38 -0000 --000e0cd70f4afdba1c04867c1386 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <eran@hueniverse.com>wro= te: > You are trying to match a mechanism designed for automatic discovery with= a > system designed to require paperwork. It sounds like for your use cases, = you > will not be using this optional parameter and just document how to use yo= ur > API (i.e. hardcode your security setup and API format). > I'm saying it should be a fully automatic discovery or use paperwork. Havin= g an API return valid URL prefixes to send the token to without having an API to determine the actual URLs you send tokens to seems odd. > > > The whole point of this is that the developer isn=92t involved. The libra= ry > takes care of everything. All the developer does is ask to get a protecte= d > resource. The library will check if it already has a valid token for that > resource (based on the security restrictions provided by the sites > parameter, and the scope requirements =96 two very separate things). > This is an incomplete mechanism for automatic discovery. How does the developer find out where to ask for the protected resource in the first place? > > > So yes =96 if your developers have plenty of stuff to hardcode already, t= his > adds little value. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Evan Gilbert > *Sent:* Thursday, May 13, 2010 9:00 AM > > *To:* Manger, James H > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid > > > > > > On Wed, May 12, 2010 at 11:52 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > > Evan, > > > > The key point is that this discovery covers a lot of the same grounds a= s > the sites parameter, and it's hard to define semantics around a sites > parameter without understanding the semantics of scopes and API endpoints= . > > I strongly disagree. The semantics are crystal clear: > "Here is a token. It is INSECURE to send it anywhere not in this list." > These semantics are useful regardless of what the API does, how the clien= t > is using it, or how much (or how little) the client knows about the API. > > > > To expand - it's hard to define *useful* semantics around a sites paramet= er > without understanding the semantics of scopes and API endpoints. Yes, you > can define crystal clear semantics, but these are not useful unless they > work well with the way developers figure out the endpoints to call APIs. > > > > > > > Clients need to [know] more about these links (at least the response > format). > > That knowledge comes from other standards (HTML, Atom, wiki of rel > values...) and is totally independent of whether a token should or should > not be sent. > > > > In our use cases, clients almost always need to know more about the API: > > - How to call directly - we have no API endpoints that are only arrived a= t > by links > > - Response format of the data > > > > > > > The mechanism they use to find out about these links - documentation, > discovery, data returned with token request - could also provide the > information about whether a token should be sent to a particular API. > > Could, but shouldn't and doesn't in practise. > It is much much better to have the information about how to use a token > securely delivered at the same time & place as receiving that token, and > with minimal assumptions about how much the client apps knows about the > service. > > > > So why wouldn't we return a list of specific API endpoints instead of a > "sites" parameter? > > > > Developers are going to call the APIs endpoints that they know about. If > there is a conflict between this and the sites parameter, what should the= y > do? For example, if facebook returns a sites parameter " > https://unknown.facebook.com/", do we think the developer is going to not > try to use the access token on https://graph.facebook.com/<https://graph.= facebook.com/*> > ? > > > > Separating the concept of sites from API endpoints feels like a bad idea. > Discovery / docs will give you a list of URLs where you should send token= s. > The "sites" parameter will give you a list of URLs where you can send > tokens. This is redundant, and will lead to developers / libraries not > respecting the sites parameter. If developers / libraries don't respect i= t, > then the service can't rely on it for enforcing security. > > > > Another note: Where do we anticipate clients storing the sites parameter = in > the User-Agent flow? Right now the access token can be set as an HTTP coo= kie > by the client. Do we expect them to set a separate "sites" cookie and > respect this on their server when making requests? This seems complicated= . > > > > > > > I should be more concrete about the use cases I see. Let's assume there= 's > an API where there are two endpoints, each with an associated permission > > - contacts.list permission -> > http://contacts.serviceprovider.com/contacts/list > > - calendar.get permission -> > http://calendar.serviceprovider.com/calendar/get > > > > If the response to an authorization request includes the authorized > scopes (contacts.list, calendar.get), then the "sites" parameter is > redundant. > > I'll admit that "sites" is redundant if a client has *perfect* knowledge > about a service, but so is pretty much any standard at that point. > > Consider a generic search spider tool that you point at > http://calendar.serviceprovider.com/calendar/get. It can do its job with > no knowledge about what "calendar.get" means -- but it still needs to kno= w > (as it spiders along) when it is safe to expose the token. > > > > How does the generic search spider know to call to > http://calendar.serviceprovider.com/calendar/get in the first place? > > > > > > -- > James Manger > > > --000e0cd70f4afdba1c04867c1386 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, May 13, 2010 at 9:08 AM, Eran Ha= mmer-Lahav <span dir=3D"ltr"><<a href=3D"mailto:eran@hueniverse.com" tar= get=3D"_blank">eran@hueniverse.com</a>></span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNorm= al"><span style=3D"font-size:11.0pt;color:#1F497D">You are trying to match = a mechanism designed for automatic discovery with a system designed to requ= ire paperwork. It sounds like for your use cases, you will not be using thi= s optional parameter and just document how to use your API (i.e. hardcode y= our security setup and API format).</span></p> </div></div></blockquote><div><br></div><div>I'm saying it should be a = fully automatic discovery or use paperwork. Having an API return valid URL = prefixes to send the token to without having an API to determine the actual= URLs you send tokens to seems odd.</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"p= urple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1= F497D">=A0</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">The w= hole point of this is that the developer isn=92t involved. The library take= s care of everything. All the developer does is ask to get a protected reso= urce. The library will check if it already has a valid token for that resou= rce (based on the security restrictions provided by the sites parameter, an= d the scope requirements =96 two very separate things).</span></p> </div></div></blockquote><div><br></div><div>This is an incomplete mechanis= m for automatic discovery. How does the developer find out where to ask for= the protected resource in the first place?</div><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNorm= al"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</span></p><p class= =3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">So yes =96 if= your developers have plenty of stuff to hardcode already, this adds little= value.</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F49= 7D">EHL</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;co= lor:#1F497D">=A0</span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;paddin= g:3.0pt 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.= 0pt">From:</span></b><span style=3D"font-size:10.0pt"> <a href=3D"mailto:oa= uth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a> [mailto:= <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a>] <b>On Behalf Of </b>Evan Gilbert<br> <b>Sent:</b> Thursday, May 13, 2010 9:00 AM</span></p><div><br><b>To:</b> M= anger, James H<br><b>Cc:</b> OAuth WG<br><b>Subject:</b> Re: [OAUTH-WG] Ind= icating sites where a token is valid</div><p></p></div></div> <p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal" style=3D"margin-bottom= :12.0pt">=A0</p><div><p class=3D"MsoNormal">On Wed, May 12, 2010 at 11:52 P= M, Manger, James H <<a href=3D"mailto:James.H.Manger@team.telstra.com" t= arget=3D"_blank">James.H.Manger@team.telstra.com</a>> wrote:</p> <div><div></div><div><p class=3D"MsoNormal">Evan,</p><div><p class=3D"MsoNo= rmal" style=3D"margin-bottom:12.0pt"><br>> The key point is that this di= scovery covers a lot of the same grounds as the sites parameter, and it'= ;s hard =A0to define semantics around a sites parameter without understandi= ng the semantics of scopes and API endpoints.</p> </div><p class=3D"MsoNormal">I strongly disagree. The semantics are crystal= clear:<br>=A0"Here is a token. It is INSECURE to send it anywhere not= in this list."<br>These semantics are useful regardless of what the A= PI does, how the client is using it, or how much (or how little) the client= knows about the API.</p> <div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">To exp= and - it's hard to define *useful* semantics=A0around a sites parameter= without understanding the semantics of scopes and API endpoints. Yes, you = can define crystal clear semantics, but these are not useful unless they wo= rk well with the way developers figure out the endpoints to call APIs.</p> </div><div><p class=3D"MsoNormal">=A0</p></div><blockquote style=3D"border:= none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:= 4.8pt;margin-right:0in"><p class=3D"MsoNormal"><br><br>> Clients need to= [know] more about these links (at least the response format).<br> <br>That knowledge comes from other standards (HTML, Atom, wiki of rel valu= es...) and is totally independent of whether a token should or should not b= e sent.</p></blockquote><div><p class=3D"MsoNormal">=A0</p></div><div><p cl= ass=3D"MsoNormal"> In our use cases, clients almost always need to know more about the API:</p= ></div><div><p class=3D"MsoNormal">- How to call directly - we have no API = endpoints that are only arrived at by links</p></div><p class=3D"MsoNormal"= > - Response format of the data</p><div><p class=3D"MsoNormal">=A0</p></div><= blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><p class=3D"MsoNorm= al" style=3D"margin-bottom:12.0pt"> <br><br>> The mechanism they use to find out about these links -=A0docum= entation, discovery, data returned with token request - could also provide = the information about whether a token should be sent to a particular API.</= p> </div><p class=3D"MsoNormal">Could, but shouldn't and doesn't in pr= actise.<br>It is much much better to have the information about how to use = a token securely delivered at the same time & place as receiving that t= oken, and with minimal assumptions about how much the client apps knows abo= ut the service.</p> </blockquote><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoN= ormal">So why wouldn't we return a list of specific API endpoints inste= ad of a "sites" parameter?</p></div><div><p class=3D"MsoNormal">= =A0</p> </div><div><p class=3D"MsoNormal">Developers are going to call the APIs end= points that they know about. If there is a conflict between this and the si= tes parameter, what should they do? For example, if facebook returns a site= s parameter "<a href=3D"https://unknown.facebook.com/" target=3D"_blan= k">https://unknown.facebook.com/</a>", do we think the developer is go= ing to not try to use the access token on=A0<span><span style=3D"font-size:= 10.0pt"><a href=3D"https://graph.facebook.com/*" target=3D"_blank"><span st= yle=3D"color:#0000CC">https://graph.facebook.com/</span></a>=A0?=A0</span><= /span></p> </div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">= <span><span style=3D"font-size:10.0pt">Separating the concept of sites from= API endpoints feels like a bad idea. Discovery / docs will give you a list= of URLs where you should send tokens. The "sites" parameter will= give you a list of URLs where you can send tokens. This is redundant, and = will lead to developers / libraries not respecting the sites parameter. If = developers / libraries don't respect it, then the service can't rel= y on it for enforcing security.</span></span></p> </div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">= <span><span style=3D"font-size:10.0pt">Another note: Where do we anticipate= clients storing the sites parameter in the User-Agent flow? Right now the = access token can be set as an HTTP cookie by the client. Do we expect them = to set a separate "sites" cookie and respect this on their server= when making requests? This seems complicated.</span></span></p> </div><div><p class=3D"MsoNormal">=A0</p></div><blockquote style=3D"border:= none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:= 4.8pt;margin-right:0in"><div><p class=3D"MsoNormal" style=3D"margin-bottom:= 12.0pt"> <br><br>> I should be more concrete about the use cases I see. Let's= assume there's an API where there are two endpoints, each with an asso= ciated permission<br>> - contacts.list permission -> <a href=3D"http:= //contacts.serviceprovider.com/contacts/list" target=3D"_blank">http://cont= acts.serviceprovider.com/contacts/list</a><br> > - calendar.get permission -> <a href=3D"http://calendar.serviceprov= ider.com/calendar/get" target=3D"_blank">http://calendar.serviceprovider.co= m/calendar/get</a><br>><br>> If the response to an authorization requ= est includes the authorized scopes (contacts.list, calendar.get), then the = "sites" parameter is redundant.</p> </div><p class=3D"MsoNormal">I'll admit that "sites" is redun= dant if a client has *perfect* knowledge about a service, but so is pretty = much any standard at that point.<br><br>Consider a generic search spider to= ol that you point at <a href=3D"http://calendar.serviceprovider.com/calenda= r/get" target=3D"_blank">http://calendar.serviceprovider.com/calendar/get</= a>. It can do its job with no knowledge about what "calendar.get"= means -- but it still needs to know (as it spiders along) when it is safe = to expose the token.</p> </blockquote><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoN= ormal">How does the generic search spider know to call to <a href=3D"http:/= /calendar.serviceprovider.com/calendar/get" target=3D"_blank">http://calend= ar.serviceprovider.com/calendar/get</a> in the first place?</p> </div><div><p class=3D"MsoNormal">=A0</p></div><blockquote style=3D"border:= none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:= 4.8pt;margin-right:0in"><p class=3D"MsoNormal" style=3D"margin-bottom:12.0p= t"><br> <br>--<br><span style=3D"color:#888888">James Manger</span></p></blockquote= ></div></div></div><p class=3D"MsoNormal">=A0</p></div></div></div></blockq= uote></div><br> --000e0cd70f4afdba1c04867c1386-- From eran@hueniverse.com Thu May 13 09:31:16 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196663A6921 for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] 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 dzFU4xNwjtUF for <oauth@core3.amsl.com>; Thu, 13 May 2010 09:31: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 EF0263A685A for <oauth@ietf.org>; Thu, 13 May 2010 09:31:05 -0700 (PDT) Received: (qmail 6859 invoked from network); 13 May 2010 16:30:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 May 2010 16:29:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 13 May 2010 09:29:53 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Evan Gilbert <uidude@google.com> Date: Thu, 13 May 2010 09:30:05 -0700 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcryuLF51pHq+a1rSxysZI/MeH1nwwAAITOg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTik0dKSLLVQDhodhFsO--bR43PvZKborWG1uK15t@mail.gmail.com> In-Reply-To: <AANLkTik0dKSLLVQDhodhFsO--bR43PvZKborWG1uK15t@mail.gmail.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_90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 16:31:16 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Today when I cut/paste a URI of an image using Basic auth, the browser know= s exactly what to do. I want to do the same with an OAuth-protected image. = Saying that there aren't standards API out there to benefit from this is in= correct. There are plenty. This is complete discovery for the authentication layer. The rest doesn't b= elong here, the same way this doesn't belong as part of the API specificati= on. EHL From: Evan Gilbert [mailto:uidude@google.com] Sent: Thursday, May 13, 2010 9:16 AM To: Eran Hammer-Lahav Cc: Manger, James H; OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <eran@hueniverse.com<mai= lto:eran@hueniverse.com>> wrote: You are trying to match a mechanism designed for automatic discovery with a= system designed to require paperwork. It sounds like for your use cases, y= ou will not be using this optional parameter and just document how to use y= our API (i.e. hardcode your security setup and API format). I'm saying it should be a fully automatic discovery or use paperwork. Havin= g an API return valid URL prefixes to send the token to without having an A= PI to determine the actual URLs you send tokens to seems odd. The whole point of this is that the developer isn't involved. The library t= akes care of everything. All the developer does is ask to get a protected r= esource. The library will check if it already has a valid token for that re= source (based on the security restrictions provided by the sites parameter,= and the scope requirements - two very separate things). This is an incomplete mechanism for automatic discovery. How does the devel= oper find out where to ask for the protected resource in the first place? So yes - if your developers have plenty of stuff to hardcode already, this = adds little value. EHL From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Evan Gilbert Sent: Thursday, May 13, 2010 9:00 AM To: Manger, James H Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Wed, May 12, 2010 at 11:52 PM, Manger, James H <James.H.Manger@team.tels= tra.com<mailto:James.H.Manger@team.telstra.com>> wrote: Evan, > The key point is that this discovery covers a lot of the same grounds as = the sites parameter, and it's hard to define semantics around a sites para= meter without understanding the semantics of scopes and API endpoints. I strongly disagree. The semantics are crystal clear: "Here is a token. It is INSECURE to send it anywhere not in this list." These semantics are useful regardless of what the API does, how the client = is using it, or how much (or how little) the client knows about the API. To expand - it's hard to define *useful* semantics around a sites parameter= without understanding the semantics of scopes and API endpoints. Yes, you = can define crystal clear semantics, but these are not useful unless they wo= rk well with the way developers figure out the endpoints to call APIs. > Clients need to [know] more about these links (at least the response form= at). That knowledge comes from other standards (HTML, Atom, wiki of rel values..= .) and is totally independent of whether a token should or should not be se= nt. In our use cases, clients almost always need to know more about the API: - How to call directly - we have no API endpoints that are only arrived at = by links - Response format of the data > The mechanism they use to find out about these links - documentation, dis= covery, data returned with token request - could also provide the informati= on about whether a token should be sent to a particular API. Could, but shouldn't and doesn't in practise. It is much much better to have the information about how to use a token sec= urely delivered at the same time & place as receiving that token, and with = minimal assumptions about how much the client apps knows about the service. So why wouldn't we return a list of specific API endpoints instead of a "si= tes" parameter? Developers are going to call the APIs endpoints that they know about. If th= ere is a conflict between this and the sites parameter, what should they do= ? For example, if facebook returns a sites parameter "https://unknown.faceb= ook.com/", do we think the developer is going to not try to use the access = token on https://graph.facebook.com/<https://graph.facebook.com/*> ? Separating the concept of sites from API endpoints feels like a bad idea. D= iscovery / docs will give you a list of URLs where you should send tokens. = The "sites" parameter will give you a list of URLs where you can send token= s. This is redundant, and will lead to developers / libraries not respectin= g the sites parameter. If developers / libraries don't respect it, then the= service can't rely on it for enforcing security. Another note: Where do we anticipate clients storing the sites parameter in= the User-Agent flow? Right now the access token can be set as an HTTP cook= ie by the client. Do we expect them to set a separate "sites" cookie and re= spect this on their server when making requests? This seems complicated. > I should be more concrete about the use cases I see. Let's assume there's= an API where there are two endpoints, each with an associated permission > - contacts.list permission -> http://contacts.serviceprovider.com/contact= s/list > - calendar.get permission -> http://calendar.serviceprovider.com/calendar= /get > > If the response to an authorization request includes the authorized scope= s (contacts.list, calendar.get), then the "sites" parameter is redundant. I'll admit that "sites" is redundant if a client has *perfect* knowledge ab= out a service, but so is pretty much any standard at that point. Consider a generic search spider tool that you point at http://calendar.ser= viceprovider.com/calendar/get. It can do its job with no knowledge about wh= at "calendar.get" means -- but it still needs to know (as it spiders along)= when it is safe to expose the token. How does the generic search spider know to call to http://calendar.servicep= rovider.com/calendar/get in the first place? -- James Manger --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Today whe= n I cut/paste a URI of an image using Basic auth, the browser knows exactly= what to do. I want to do the same with an OAuth-protected image. Saying th= at there aren’t standards API out there to benefit from this is incor= rect. There are plenty.<o:p></o:p></span></p><p class=3DMsoNormal><span sty= le=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o= :p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.= 0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This is complete disc= overy for the authentication layer. The rest doesn’t belong here, the= same way this doesn’t belong as part of the API specification.<o:p><= /o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-f= amily:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sa= ns-serif";color:#1F497D'>EHL<o:p></o:p></span></p><p class=3DMsoNormal><spa= n style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><div style=3D'border:none;border-left:solid = blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none;border= -top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b= ><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</= span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'= > Evan Gilbert [mailto:uidude@google.com] <br><b>Sent:</b> Thursday, May 13= , 2010 9:16 AM<br><b>To:</b> Eran Hammer-Lahav<br><b>Cc:</b> Manger, James = H; OAuth WG<br><b>Subject:</b> Re: [OAUTH-WG] Indicating sites where a toke= n is valid<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p> = ;</o:p></p><p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><o:p> <= /o:p></p><div><p class=3DMsoNormal>On Thu, May 13, 2010 at 9:08 AM, Eran Ha= mmer-Lahav <<a href=3D"mailto:eran@hueniverse.com" target=3D"_blank">era= n@hueniverse.com</a>> wrote:<o:p></o:p></p><div><div><p class=3DMsoNorma= l style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style= =3D'font-size:11.0pt;color:#1F497D'>You are trying to match a mechanism des= igned for automatic discovery with a system designed to require paperwork. = It sounds like for your use cases, you will not be using this optional para= meter and just document how to use your API (i.e. hardcode your security se= tup and API format).</span><o:p></o:p></p></div></div><div><p class=3DMsoNo= rmal><o:p> </o:p></p></div><div><p class=3DMsoNormal>I'm saying it sho= uld be a fully automatic discovery or use paperwork. Having an API return v= alid URL prefixes to send the token to without having an API to determine t= he actual URLs you send tokens to seems odd.<o:p></o:p></p></div><blockquot= e style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in = 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=3DMsoNormal st= yle=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'f= ont-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=3DMsoNo= rmal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span sty= le=3D'font-size:11.0pt;color:#1F497D'>The whole point of this is that the d= eveloper isn’t involved. The library takes care of everything. All th= e developer does is ask to get a protected resource. The library will check= if it already has a valid token for that resource (based on the security r= estrictions provided by the sites parameter, and the scope requirements = 211; two very separate things).</span><o:p></o:p></p></div></div></blockquo= te><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMso= Normal>This is an incomplete mechanism for automatic discovery. How does th= e developer find out where to ask for the protected resource in the first p= lace?<o:p></o:p></p></div><blockquote style=3D'border:none;border-left:soli= d #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0i= n'><div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-marg= in-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'> </= span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;m= so-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'>S= o yes – if your developers have plenty of stuff to hardcode already, = this adds little value.</span><o:p></o:p></p><p class=3DMsoNormal style=3D'= mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-siz= e:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=3DMsoNormal st= yle=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'f= ont-size:11.0pt;color:#1F497D'>EHL</span><o:p></o:p></p><p class=3DMsoNorma= l style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style= =3D'font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><div style= =3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><di= v><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0i= n 0in 0in'><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin= -bottom-alt:auto'><b><span style=3D'font-size:10.0pt'>From:</span></b><span= style=3D'font-size:10.0pt'> <a href=3D"mailto:oauth-bounces@ietf.org" targ= et=3D"_blank">oauth-bounces@ietf.org</a> [mailto:<a href=3D"mailto:oauth-bo= unces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a>] <b>On Behalf = Of </b>Evan Gilbert<br><b>Sent:</b> Thursday, May 13, 2010 9:00 AM</span><o= :p></o:p></p><div><p class=3DMsoNormal><br><b>To:</b> Manger, James H<br><b= >Cc:</b> OAuth WG<br><b>Subject:</b> Re: [OAUTH-WG] Indicating sites where = a token is valid<o:p></o:p></p></div></div></div><p class=3DMsoNormal style= =3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></= p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0p= t'> <o:p></o:p></p><div><p class=3DMsoNormal style=3D'mso-margin-top-a= lt:auto;mso-margin-bottom-alt:auto'>On Wed, May 12, 2010 at 11:52 PM, Mange= r, James H <<a href=3D"mailto:James.H.Manger@team.telstra.com" target=3D= "_blank">James.H.Manger@team.telstra.com</a>> wrote:<o:p></o:p></p><div>= <div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-botto= m-alt:auto'>Evan,<o:p></o:p></p><div><p class=3DMsoNormal style=3D'mso-marg= in-top-alt:auto;margin-bottom:12.0pt'><br>> The key point is that this d= iscovery covers a lot of the same grounds as the sites parameter, and it's = hard  to define semantics around a sites parameter without understandi= ng the semantics of scopes and API endpoints.<o:p></o:p></p></div><p class= =3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I= strongly disagree. The semantics are crystal clear:<br> "Here is= a token. It is INSECURE to send it anywhere not in this list."<br>The= se semantics are useful regardless of what the API does, how the client is = using it, or how much (or how little) the client knows about the API.<o:p><= /o:p></p><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-mar= gin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal s= tyle=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>To expand - it'= s hard to define *useful* semantics around a sites parameter without u= nderstanding the semantics of scopes and API endpoints. Yes, you can define= crystal clear semantics, but these are not useful unless they work well wi= th the way developers figure out the endpoints to call APIs.<o:p></o:p></p>= </div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin= -bottom-alt:auto'> <o:p></o:p></p></div><blockquote style=3D'border:no= ne;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.= 8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=3DMsoNo= rmal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br>&= gt; Clients need to [know] more about these links (at least the response fo= rmat).<br><br>That knowledge comes from other standards (HTML, Atom, wiki o= f rel values...) and is totally independent of whether a token should or sh= ould not be sent.<o:p></o:p></p></blockquote><div><p class=3DMsoNormal styl= e=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p><= /p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-mar= gin-bottom-alt:auto'>In our use cases, clients almost always need to know m= ore about the API:<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'm= so-margin-top-alt:auto;mso-margin-bottom-alt:auto'>- How to call directly -= we have no API endpoints that are only arrived at by links<o:p></o:p></p><= /div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-botto= m-alt:auto'>- Response format of the data<o:p></o:p></p><div><p class=3DMso= Normal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <= o:p></o:p></p></div><blockquote style=3D'border:none;border-left:solid #CCC= CCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;marg= in-right:0in;margin-bottom:5.0pt'><div><p class=3DMsoNormal style=3D'mso-ma= rgin-top-alt:auto;margin-bottom:12.0pt'><br><br>> The mechanism they use= to find out about these links - documentation, discovery, data return= ed with token request - could also provide the information about whether a = token should be sent to a particular API.<o:p></o:p></p></div><p class=3DMs= oNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Could,= but shouldn't and doesn't in practise.<br>It is much much better to have t= he information about how to use a token securely delivered at the same time= & place as receiving that token, and with minimal assumptions about ho= w much the client apps knows about the service.<o:p></o:p></p></blockquote>= <div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-botto= m-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'm= so-margin-top-alt:auto;mso-margin-bottom-alt:auto'>So why wouldn't we retur= n a list of specific API endpoints instead of a "sites" parameter= ?<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt= :auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class= =3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>D= evelopers are going to call the APIs endpoints that they know about. If the= re is a conflict between this and the sites parameter, what should they do?= For example, if facebook returns a sites parameter "<a href=3D"https:= //unknown.facebook.com/" target=3D"_blank">https://unknown.facebook.com/</a= >", do we think the developer is going to not try to use the access to= ken on <span style=3D'font-size:10.0pt'><a href=3D"https://graph.faceb= ook.com/*" target=3D"_blank"><span style=3D'color:#0000CC'>https://graph.fa= cebook.com/</span></a> ? </span><o:p></o:p></p></div><div><p clas= s=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>=  <o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'mso-margin-to= p-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:10.0pt'>Sep= arating the concept of sites from API endpoints feels like a bad idea. Disc= overy / docs will give you a list of URLs where you should send tokens. The= "sites" parameter will give you a list of URLs where you can sen= d tokens. This is redundant, and will lead to developers / libraries not re= specting the sites parameter. If developers / libraries don't respect it, t= hen the service can't rely on it for enforcing security.</span><o:p></o:p><= /p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-mar= gin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal s= tyle=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'= font-size:10.0pt'>Another note: Where do we anticipate clients storing the = sites parameter in the User-Agent flow? Right now the access token can be s= et as an HTTP cookie by the client. Do we expect them to set a separate &qu= ot;sites" cookie and respect this on their server when making requests= ? This seems complicated.</span><o:p></o:p></p></div><div><p class=3DMsoNor= mal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p= ></o:p></p></div><blockquote style=3D'border:none;border-left:solid #CCCCCC= 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-= right:0in;margin-bottom:5.0pt'><div><p class=3DMsoNormal style=3D'mso-margi= n-top-alt:auto;margin-bottom:12.0pt'><br><br>> I should be more concrete= about the use cases I see. Let's assume there's an API where there are two= endpoints, each with an associated permission<br>> - contacts.list perm= ission -> <a href=3D"http://contacts.serviceprovider.com/contacts/list" = target=3D"_blank">http://contacts.serviceprovider.com/contacts/list</a><br>= > - calendar.get permission -> <a href=3D"http://calendar.serviceprov= ider.com/calendar/get" target=3D"_blank">http://calendar.serviceprovider.co= m/calendar/get</a><br>><br>> If the response to an authorization requ= est includes the authorized scopes (contacts.list, calendar.get), then the = "sites" parameter is redundant.<o:p></o:p></p></div><p class=3DMs= oNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I'll a= dmit that "sites" is redundant if a client has *perfect* knowledg= e about a service, but so is pretty much any standard at that point.<br><br= >Consider a generic search spider tool that you point at <a href=3D"http://= calendar.serviceprovider.com/calendar/get" target=3D"_blank">http://calenda= r.serviceprovider.com/calendar/get</a>. It can do its job with no knowledge= about what "calendar.get" means -- but it still needs to know (a= s it spiders along) when it is safe to expose the token.<o:p></o:p></p></bl= ockquote><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-mar= gin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal s= tyle=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>How does the ge= neric search spider know to call to <a href=3D"http://calendar.serviceprovi= der.com/calendar/get" target=3D"_blank">http://calendar.serviceprovider.com= /calendar/get</a> in the first place?<o:p></o:p></p></div><div><p class=3DM= soNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> = ;<o:p></o:p></p></div><blockquote style=3D'border:none;border-left:solid #C= CCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;ma= rgin-right:0in;margin-bottom:5.0pt'><p class=3DMsoNormal style=3D'mso-margi= n-top-alt:auto;margin-bottom:12.0pt'><br><br>--<br><span style=3D'color:#88= 8888'>James Manger</span><o:p></o:p></p></blockquote></div></div></div><p c= lass=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:aut= o'> <o:p></o:p></p></div></div></div></blockquote></div><p class=3DMso= Normal><o:p> </o:p></p></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4P3PW5EX1MB01E_-- From eran@hueniverse.com Thu May 13 10:01:16 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3085B3A6C11 for <oauth@core3.amsl.com>; Thu, 13 May 2010 10:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_50=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 VA4WoUhDH3np for <oauth@core3.amsl.com>; Thu, 13 May 2010 10:01:15 -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 32A853A6921 for <oauth@ietf.org>; Thu, 13 May 2010 10:01:15 -0700 (PDT) Received: (qmail 21611 invoked from network); 13 May 2010 17:01:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 May 2010 17:01:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 13 May 2010 10:00:57 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 13 May 2010 10:01:11 -0700 Thread-Topic: Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vAC/+jNg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@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: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 17:01:16 -0000 Thanks to those who participated! Some conclusions: > 1. Server Response Format >=20 > After extensive debate, we have a large group in favor of using JSON as t= he > only response format (current draft). We also have a smaller group but wi= th > stronger feelings on the subject that JSON adds complexity with no obviou= s > value. >=20 > A. Form-encoded only (original draft) > B. JSON only (current draft) > C. JSON as default with form-encoded and XML available with an optional > request parameter It seems like we have weak consensus to go with C where the server must sup= port all three formats, and the client can use either one. This approach ad= dresses most of the concerns around client complexity / size. Only one pers= on strongly objected to C (without an explanation that can be addressed). S= umming up the results was hard because many people had no strong preference= between A and B but with each of the three options received about a third = of the votes. My guess is that if we held another vote asking if the spec should only sup= port form-encoded or all three - all three will get most of the votes (and = same if we made JSON the only option or all three). This is why C is really= the only way to move forward at this point. We can revisit this later if i= mplementation experience shows supporting all three in this manner is a pro= blem. I am going to add this to the specification as a point of reference for fut= ure discussions. > 2. Client Authentication (in flows) >=20 > How should the client authenticate when making token requests? The > current draft defines special request parameters for sending client > credentials. Some have argued that this is not the correct way, and that = the > client should be using existing HTTP authentication schemes to accomplish > that such as Basic. >=20 > A. Client authenticates by sending its credentials using special paramete= rs > (current draft) B. Client authenticated by using HTTP Basic (or other sch= emes > supported by the server such as Digest) Weak consensus to support both request parameters and HTTP Basic authentica= tion (with other schemes as optional). I will add a new section to the draf= t allowing replacing the parameters with an HTTP authentication header. The= flows text will remain the same. EHL =20 From prateek.mishra@oracle.com Thu May 13 10:16:14 2010 Return-Path: <prateek.mishra@oracle.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C9A3A6C7C for <oauth@core3.amsl.com>; Thu, 13 May 2010 10:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_40=-0.185, 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 X2Yz5TcD720v for <oauth@core3.amsl.com>; Thu, 13 May 2010 10:16:13 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 81E023A69D3 for <oauth@ietf.org>; Thu, 13 May 2010 10:15:32 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DHFCFd016637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Thu, 13 May 2010 17:15:15 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4DGM7gN027910 for <oauth@ietf.org>; Thu, 13 May 2010 17:15:09 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 262576071273770905; Thu, 13 May 2010 10:15:05 -0700 Received: from [10.149.158.70] (/10.149.158.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 10:15:05 -0700 Message-ID: <4BEC3398.6090300@oracle.com> Date: Thu, 13 May 2010 13:15:04 -0400 From: Prateek Mishra <prateek.mishra@oracle.com> Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "oauth@ietf.org" <oauth@ietf.org> References: <C811682C.563A%cmortimore@salesforce.com> In-Reply-To: <C811682C.563A%cmortimore@salesforce.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090207.4BEC33A9.019D:SCFMA4539811,ss=1,fgs=0 Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 17:16:14 -0000 SAML 2.0 assertions can represent a variety (very large) of relationships between the presenter, issuer, subject, means of confirmation and so on and so forth. So representing multiple identities - i am server foo but I am acting for joe - is not very difficult. We can profile these versus adding parameters to the flows. - prateek > Our plan is to treat SAML assertions passed over the assertion flow as > bearer assertions, so I believe we have everything we need contained > within the assertion (issuer + audience + signature). That being > said, if we want this to be an extensible flow, not all assertion > formats will be so transparent. > > I think this is a reasonable suggestion, as long as the > clientid/secret are entirely optional. Not in support of a second > User Assertion Flow. > > -cmort > > > On 5/13/10 3:38 AM, "Torsten Lodderstedt" <torsten@lodderstedt.net> wrote: > > In my perception, we reached consensus in the thread "Autonomous > clients > and resource owners (editorial)" that the assertion flow should > support > clients acting on behalf of users, not only autonomous clients. > > The specification currently states "This flow is suitable when the > client is acting autonomously or on behalf of the end-user (based > on the > content of the assertion used).", which is fine with me. > > Im struggling to understand how the flow handles the two required > identities, the client and the end-user. I basically see two options: > > 1) the assertion attests both identities. I'm not aware of any > identity > framework attesting two identities in a single assertion. > > 2) If we assume the assertion attests the end-user's identity only, > there is the need for additional parameters used to authenticate the > client. From my point of view, the situation is similar to the > "Username > and Password Flow". There, the specification defines two > credential sets > (username/password and client_id/client_secret) two prove both > identities. > > Therefore, I would propose to add optional client_id/client_secret > parameters (or an Authorization header) to pass the client credentials > to the assertion flow if the assertion contains the end-user identity. > Alternatively, one could add another flow to the spec, probably called > "User Assertion Flow". > > Any thoughts? > > regards, > Torsten. > > _______________________________________________ > 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 Thu May 13 10:18:25 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563663A6C87 for <oauth@core3.amsl.com>; Thu, 13 May 2010 10:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_05=-1.11] 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 oW2s3P5sZKKh for <oauth@core3.amsl.com>; Thu, 13 May 2010 10:18:23 -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 134B83A6B31 for <oauth@ietf.org>; Thu, 13 May 2010 10:17:06 -0700 (PDT) Received: (qmail 10451 invoked from network); 13 May 2010 17:16:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 May 2010 17:16:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 13 May 2010 10:16:55 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Prateek Mishra <prateek.mishra@oracle.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Thu, 13 May 2010 10:17:08 -0700 Thread-Topic: [OAUTH-WG] User and Client identity in the Assertion Flow Thread-Index: AcrywACFB69PszCTSMS7eG3dBtxn0AAABalQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B698820@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <C811682C.563A%cmortimore@salesforce.com> <4BEC3398.6090300@oracle.com> In-Reply-To: <4BEC3398.6090300@oracle.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] User and Client identity in the Assertion Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 17:18:25 -0000 The flow is not SAML-specific. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Prateek Mishra > Sent: Thursday, May 13, 2010 10:15 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] User and Client identity in the Assertion Flow >=20 > SAML 2.0 assertions can represent a variety (very large) of relationships > between the presenter, issuer, subject, means of confirmation and so on > and so forth. > So representing multiple identities - i am server foo but I am acting for= joe - is > not very difficult. >=20 > We can profile these versus adding parameters to the flows. >=20 > - prateek >=20 >=20 > > Our plan is to treat SAML assertions passed over the assertion flow as > > bearer assertions, so I believe we have everything we need contained > > within the assertion (issuer + audience + signature). That being > > said, if we want this to be an extensible flow, not all assertion > > formats will be so transparent. > > > > I think this is a reasonable suggestion, as long as the > > clientid/secret are entirely optional. Not in support of a second > > User Assertion Flow. > > > > -cmort > > > > > > On 5/13/10 3:38 AM, "Torsten Lodderstedt" <torsten@lodderstedt.net> > wrote: > > > > In my perception, we reached consensus in the thread "Autonomous > > clients > > and resource owners (editorial)" that the assertion flow should > > support > > clients acting on behalf of users, not only autonomous clients. > > > > The specification currently states "This flow is suitable when the > > client is acting autonomously or on behalf of the end-user (based > > on the > > content of the assertion used).", which is fine with me. > > > > Im struggling to understand how the flow handles the two required > > identities, the client and the end-user. I basically see two option= s: > > > > 1) the assertion attests both identities. I'm not aware of any > > identity > > framework attesting two identities in a single assertion. > > > > 2) If we assume the assertion attests the end-user's identity only, > > there is the need for additional parameters used to authenticate th= e > > client. From my point of view, the situation is similar to the > > "Username > > and Password Flow". There, the specification defines two > > credential sets > > (username/password and client_id/client_secret) two prove both > > identities. > > > > Therefore, I would propose to add optional client_id/client_secret > > parameters (or an Authorization header) to pass the client credenti= als > > to the assertion flow if the assertion contains the end-user identi= ty. > > Alternatively, one could add another flow to the spec, probably cal= led > > "User Assertion Flow". > > > > Any thoughts? > > > > regards, > > Torsten. > > > > _______________________________________________ > > 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 Thu May 13 10:58:51 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18D13A68FC for <oauth@core3.amsl.com>; Thu, 13 May 2010 10:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_50=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 U6Dg0reqJeu1 for <oauth@core3.amsl.com>; Thu, 13 May 2010 10:58:50 -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 691E73A6C6F for <oauth@ietf.org>; Thu, 13 May 2010 10:58:49 -0700 (PDT) Received: (qmail 31555 invoked from network); 13 May 2010 17:58:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 May 2010 17:58:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 13 May 2010 10:58:31 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Date: Thu, 13 May 2010 10:58:44 -0700 Thread-Topic: Comments on draft-ietf-oauth-v2-03.txt Thread-Index: AcrwdLKxFih7IRblQsKaGWxu0kloVACUBeeg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B698854@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BE85A86.2020701@lodderstedt.net> In-Reply-To: <4BE85A86.2020701@lodderstedt.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 WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 17:58:52 -0000 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, May 10, 2010 12:12 PM > >> 3.6.1.1. End-user Grants Authorization > >> > >> Why not call the "code" Parameter "verification_code"? It's called > >> verification code in the text. > >> > > Longer for no reason. > > >=20 > for the sake of clarity? Anyone with thoughts on this? > >> 3.6.2. Client Requests Access Token > >> > >> client_secret > >> REQUIRED if the client identifier has a matching secret. T= he > >> client secret as described in Section 3.4. > >> > >> 1) I'm having trouble to understand the meaning of "if the client > >> identifier has a matching secret". Is the assumption underneath that > >> authorization servers require this secrets from all clients they have = issued > a secret to? Yes. > >> What about client w/o a secret? Are they also allowed to use this flow= ? > >> Or is there envisioned a dependency > >> between the client type, clients credentials and the flows a > >> particular client is authorized to use? Yes, they are (I think this is the compromise on native apps). > >> I would have expected a clear policy which flows require > >> authentication and which not. Suggest text. > >> 3.7.2. Client Requests Access Token > >> > >> "authorization_declined" > >> > >> Why does the spec interpret a request as bad request if the user just > >> has declined the authorization? According to rfc2616 the semantics of > >> 400 is: "The request could not be understood by the server due to > >> malformed syntax". > >> > >> The calling client did not sent a malformed request, it cannot > >> foresee or influence this outcome. I would suggest to either use > >> status 403 or to return status code 200 for all syntactically correct > >> and authorized request and to use another return codes in the response > body to detail the requests outcome. > >> >=20 > Did you miss this question? No. Just ignored it because I need to go over all the HTTP status codes and= error messages and clean it all up. Its incomplete at best right now. > >> 7. Refreshing an Access Token > >> > >> I would suggest to add an optional "scope" parameter to this request. > >> This could be used to downgrade the scope associated with a token. > >> > > That would be the wrong way to do it given that people will expect to a= lso > be able to upgrade scope. > > >=20 > What would be the right way? Allow the client to include an access token when asking for additional scop= e (via a normal flow) so that resulting token will include the scope of bot= h new and old scopes. > >> 8.1. The Authorization Request Header > >> > >> I consider the name "Token" of the authentication schema much to > generic. > >> That was also the feedback of all colleagues I talked to about the > >> upcoming standard. Why not call it "OAuth2"? > >> > > It is meant to be generic. I consider OAuth to be the part of the proto= col > dealing with getting a token. There will be many new ways to get a token = in > the future. > > >=20 > That's interesting! I consider the authentication scheme the major > contribution of OAuth since it allows for a standardized way of service > interaction. So 3rd party software components can be integrated into a > companies infrastructure (incl. AS) w/o customization. Moreover, as you > pointed out, there will be many other ways to get tokens in the future. I'm not married to the name. I dislike 'OAuth2' because it is wrong to put = a version number in the name. We can potentially reuse 'OAuth' but I'm oppo= sed to using the 'oauth_version=3D2.0' parameter specified in OAuth 1.0. So= we can just update 1.0 (since it is now an RFC) to note that 1.0 uses the = oauth_ prefix for parameters and deprecate the oauth_version parameter. Or = something like that. I'm also open to new suggestions. But I think 'Token' is very descriptive (= but I agree it does depend on your view of what is OAuth - I think it is re= ally just the collection of flows). > > > >> 8.2.2. Form-Encoded Body Parameter > >> > >> I would suggest to drop this section/feature. > >> > >> General note: Would it make sense to add explicit format handling to > >> the OAuth API? If we envision authorization servers supporting more > >> than one token format (e.g. SAML, SWT, ...), the client should given > >> the option to request a certain format and responses returning access > >> tokens should indicate the format of this token. The OAuth > >> authorization header could also have an optional format attribute for = the > same purpose. > >> > > You mean token format? OAuth defined the token as opaque so that > would be counter-productive. > > >=20 > I dont't mean OAuth shall define token formats. I just ask for a way to > request tokens in a particular format and pass such meta data from AS to > resource server via the client. Why is that counter-productive? > Otherwise the resource server has to implement some token format > discovery. Yes it does. EHL From root@core3.amsl.com Thu May 13 12:15:16 2010 Return-Path: <root@core3.amsl.com> X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9F70C3A6CE5; Thu, 13 May 2010 12:15:06 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100513191510.9F70C3A6CE5@core3.amsl.com> Date: Thu, 13 May 2010 12:15:07 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 19:15:18 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-05.txt Pages : 55 Date : 2010-05-13 This specification describes the OAuth 2.0 protocol. OAuth provides a method for making authenticated HTTP requests using a token - an identifier used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-13121142.I-D@ietf.org> --NextPart-- From eran@hueniverse.com Thu May 13 12:29:16 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75813A6D1F for <oauth@core3.amsl.com>; Thu, 13 May 2010 12:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 8KK-uE2srvIA for <oauth@core3.amsl.com>; Thu, 13 May 2010 12:29:15 -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 1155E3A68DD for <oauth@ietf.org>; Thu, 13 May 2010 12:27:48 -0700 (PDT) Received: (qmail 5297 invoked from network); 13 May 2010 19:27:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 May 2010 19:27:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 13 May 2010 12:27:33 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: Thu, 13 May 2010 12:27:48 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-05.txt Thread-Index: Acry0Op6b2YqScdXTYmlDeSG8ctXlAAAS14A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B6988CA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100513191510.9F70C3A6CE5@core3.amsl.com> In-Reply-To: <20100513191510.9F70C3A6CE5@core3.amsl.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] I-D Action:draft-ietf-oauth-v2-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 19:29:16 -0000 Changes: o Corrected device example. o Added client credentials parameters to the assertion flow as OPTIONAL= . o Added the ability to send client credentials using an HTTP authentica= tion scheme. o Initial text for the "WWW-Authenticate" header (also added scope supp= ort). o Changed authorization endpoint to end-user endpoint. o In the device flow, changed the "user_uri" parameter to "verification= _uri" to avoid confusion with the end-user endpoint. o Added "format" request parameter and support for XML and form-encoded= responses. This will be the last draft update before our meeting next week to allow ev= eryone time to read it and prepare. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Thursday, May 13, 2010 12:15 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-05.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Open Authentication Protocol Working Gro= up > of the IETF. >=20 >=20 > Title : The OAuth 2.0 Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-05.txt > Pages : 55 > Date : 2010-05-13 >=20 > This specification describes the OAuth 2.0 protocol. OAuth provides a > method for making authenticated HTTP requests using a token - an identifi= er > used to denote an access grant with specific scope, duration, and other > attributes. Tokens are issued to third-party clients by an authorization= server > with the approval of the resource owner. OAuth defines multiple flows fo= r > obtaining a token to support a wide range of client types and user > experience. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. From Axel.Nennker@telekom.de Thu May 13 13:50:03 2010 Return-Path: <Axel.Nennker@telekom.de> 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 791123A68E6 for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 vox885MK86Mn for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:50:02 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 8D6613A6832 for <oauth@ietf.org>; Thu, 13 May 2010 13:49:56 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 13 May 2010 22:49:40 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 22:49:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 May 2010 22:49:37 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA3049FA5BA@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B698854@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt thread-index: AcrwdLKxFih7IRblQsKaGWxu0kloVACUBeegAAWsfrA= References: <4BE730CC.1090607@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET><4BE85A86.2020701@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B698854@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: <Axel.Nennker@telekom.de> To: <eran@hueniverse.com> X-OriginalArrivalTime: 13 May 2010 20:49:39.0404 (UTC) FILETIME=[CE2A18C0:01CAF2DD] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 20:50:03 -0000 Two snippets from the emails below: > > You mean token format? OAuth defined the token as opaque so that > would be counter-productive. My comment on that comment:=20 "opaque" for oauth could mean that oauth does not handle certain types of tokens specially. I think this is not an argument to reject the request that the client could ask for one token format. I think a client should be allowed to ask for a token format but oauth should not handle any format specially. Oauth should transport all tokens but the format is something agreed upon between client, authorization server and resource server. Requesting a token format is also a means to migrate from one token format to the next. >> I dont't mean OAuth shall define token formats. I just ask for a way to >> request tokens in a particular format and pass such meta data from AS to >> resource server via the client. Why is that counter-productive? >> Otherwise the resource server has to implement some token format >> discovery. > >Yes it does. > >EHL My comment on that comment: If we burden the resource server with token format discovery then why not burdon the authorization server with client_credential discovery? Currently if client_secrets are used the client maker has to register the client with the authorization server maintainer to get the client_secret and such. This agreement is beyond the scope of oauth. I think client and authorization server should be allowed to agree on any authentication scheme not just shared secrets. My request is to just rename client_secret to client_credential; both of them know what they agreed upon whether it is a shared secret or something else.=20 -Axel -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Thursday, May 13, 2010 7:59 PM To: Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, May 10, 2010 12:12 PM > >> 3.6.1.1. End-user Grants Authorization > >> > >> Why not call the "code" Parameter "verification_code"? It's called > >> verification code in the text. > >> > > Longer for no reason. > > >=20 > for the sake of clarity? Anyone with thoughts on this? > >> 3.6.2. Client Requests Access Token > >> > >> client_secret > >> REQUIRED if the client identifier has a matching secret. The > >> client secret as described in Section 3.4. > >> > >> 1) I'm having trouble to understand the meaning of "if the client > >> identifier has a matching secret". Is the assumption underneath that > >> authorization servers require this secrets from all clients they have issued > a secret to? Yes. > >> What about client w/o a secret? Are they also allowed to use this flow? > >> Or is there envisioned a dependency > >> between the client type, clients credentials and the flows a > >> particular client is authorized to use? Yes, they are (I think this is the compromise on native apps). > >> I would have expected a clear policy which flows require > >> authentication and which not. Suggest text. > >> 3.7.2. Client Requests Access Token > >> > >> "authorization_declined" > >> > >> Why does the spec interpret a request as bad request if the user just > >> has declined the authorization? According to rfc2616 the semantics of > >> 400 is: "The request could not be understood by the server due to > >> malformed syntax". > >> > >> The calling client did not sent a malformed request, it cannot > >> foresee or influence this outcome. I would suggest to either use > >> status 403 or to return status code 200 for all syntactically correct > >> and authorized request and to use another return codes in the response > body to detail the requests outcome. > >> >=20 > Did you miss this question? No. Just ignored it because I need to go over all the HTTP status codes and error messages and clean it all up. Its incomplete at best right now. > >> 7. Refreshing an Access Token > >> > >> I would suggest to add an optional "scope" parameter to this request. > >> This could be used to downgrade the scope associated with a token. > >> > > That would be the wrong way to do it given that people will expect to also > be able to upgrade scope. > > >=20 > What would be the right way? Allow the client to include an access token when asking for additional scope (via a normal flow) so that resulting token will include the scope of both new and old scopes. > >> 8.1. The Authorization Request Header > >> > >> I consider the name "Token" of the authentication schema much to > generic. > >> That was also the feedback of all colleagues I talked to about the > >> upcoming standard. Why not call it "OAuth2"? > >> > > It is meant to be generic. I consider OAuth to be the part of the protocol > dealing with getting a token. There will be many new ways to get a token in > the future. > > >=20 > That's interesting! I consider the authentication scheme the major > contribution of OAuth since it allows for a standardized way of service > interaction. So 3rd party software components can be integrated into a > companies infrastructure (incl. AS) w/o customization. Moreover, as you > pointed out, there will be many other ways to get tokens in the future. I'm not married to the name. I dislike 'OAuth2' because it is wrong to put a version number in the name. We can potentially reuse 'OAuth' but I'm opposed to using the 'oauth_version=3D2.0' parameter specified in OAuth 1.0. So we can just update 1.0 (since it is now an RFC) to note that 1.0 uses the oauth_ prefix for parameters and deprecate the oauth_version parameter. Or something like that. I'm also open to new suggestions. But I think 'Token' is very descriptive (but I agree it does depend on your view of what is OAuth - I think it is really just the collection of flows). > > > >> 8.2.2. Form-Encoded Body Parameter > >> > >> I would suggest to drop this section/feature. > >> > >> General note: Would it make sense to add explicit format handling to > >> the OAuth API? If we envision authorization servers supporting more > >> than one token format (e.g. SAML, SWT, ...), the client should given > >> the option to request a certain format and responses returning access > >> tokens should indicate the format of this token. The OAuth > >> authorization header could also have an optional format attribute for the > same purpose. > >> > > You mean token format? OAuth defined the token as opaque so that > would be counter-productive. > > >=20 > I dont't mean OAuth shall define token formats. I just ask for a way to > request tokens in a particular format and pass such meta data from AS to > resource server via the client. Why is that counter-productive? > Otherwise the resource server has to implement some token format > discovery. Yes it does. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From yarong@microsoft.com Thu May 13 13:50:53 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D693A68EB for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.666 X-Spam-Level: X-Spam-Status: No, score=-8.666 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 lUMogKx1BRWn for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:50:52 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5F5523A68DE for <oauth@ietf.org>; Thu, 13 May 2010 13:50:52 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 13 May 2010 13:50:41 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi; Thu, 13 May 2010 13:50:20 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Thread-Topic: Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vAC/+jNgAAhGIwA= Date: Thu, 13 May 2010 20:50:17 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 20:50:53 -0000 I went through and counted all the votes I could find in the mail archive (= I have reproduced the results below). 8 people explicitly stated a preferen= ce for A or B (of those 4 explicitly stated they don't want C). Only 3 peop= le voted for C as their first choice.=20 Even if we bunch together people who voted for C and people who could live = with C (but picked another option as their first choice) that is still only= 5 who expressed any level of preference for C versus 6 people who didn't p= ick C at all. Given these numbers I am at a loss to understand why you believe a consensu= s (weak or otherwise) exists for C. Could you please explain your reasoning= ? Thanks, Yaron Vivek Khurana - A or B but not C Yaron Goland - A then B but not C David Waite - A or B but doesn't like C Mike Moore - A (but not C) Dick Hardt - B James H Manger - B Torsten Lodderstedt - B but could live with C Joseph Smarr - B but could live with C Justin P. Richer - C Eran Hammer-Lahav - C David Recordon - C Mark Mcgloin - No preference > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Thursday, May 13, 2010 10:01 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > Thanks to those who participated! >=20 > Some conclusions: >=20 > > 1. Server Response Format > > > > After extensive debate, we have a large group in favor of using JSON > > as the only response format (current draft). We also have a smaller > > group but with stronger feelings on the subject that JSON adds > > complexity with no obvious value. > > > > A. Form-encoded only (original draft) > > B. JSON only (current draft) > > C. JSON as default with form-encoded and XML available with an > > optional request parameter >=20 > It seems like we have weak consensus to go with C where the server must > support all three formats, and the client can use either one. This approa= ch > addresses most of the concerns around client complexity / size. Only one > person strongly objected to C (without an explanation that can be > addressed). Summing up the results was hard because many people had no > strong preference between A and B but with each of the three options > received about a third of the votes. >=20 > My guess is that if we held another vote asking if the spec should only > support form-encoded or all three - all three will get most of the votes = (and > same if we made JSON the only option or all three). This is why C is real= ly the > only way to move forward at this point. We can revisit this later if > implementation experience shows supporting all three in this manner is a > problem. >=20 > I am going to add this to the specification as a point of reference for f= uture > discussions. >=20 > > 2. Client Authentication (in flows) > > > > How should the client authenticate when making token requests? The > > current draft defines special request parameters for sending client > > credentials. Some have argued that this is not the correct way, and > > that the client should be using existing HTTP authentication schemes > > to accomplish that such as Basic. > > > > A. Client authenticates by sending its credentials using special > > parameters (current draft) B. Client authenticated by using HTTP Basic > > (or other schemes supported by the server such as Digest) >=20 > Weak consensus to support both request parameters and HTTP Basic > authentication (with other schemes as optional). I will add a new section= to > the draft allowing replacing the parameters with an HTTP authentication > header. The flows text will remain the same. >=20 > EHL >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From yarong@microsoft.com Thu May 13 13:51:40 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7043A68F5 for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.704 X-Spam-Level: X-Spam-Status: No, score=-8.704 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] 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 sQHCe+a5GJDB for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:51:38 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id CA4323A6837 for <oauth@ietf.org>; Thu, 13 May 2010 13:51:38 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 13 May 2010 13:51:27 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Thu, 13 May 2010 13:51:29 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, Torsten Lodderstedt <torsten@lodderstedt.net> Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: AQHK8M2JqAP3Yhb/w06D/QdCD+DPKpJMuIJQgAAreACAAusloA== Date: Thu, 13 May 2010 20:51:25 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A42BFE4@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> <4BE8EF51.1070305@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A4296A0@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47465@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47465@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 20:51:40 -0000 But in federation scenarios the client credentials are an assertion. For example, Microsoft has a service called Dallas that lets entities purch= ase access to proprietary data feeds. A common scenario we run into with Da= llas is that a company will purchase access to a feed for its employees. Bu= t the company doesn't want to have to individually specify to Dallas who ca= n and cannot use the feed. Instead they want to agree on a key with Dallas = and use that key to sign assertions sent to Dallas saying "let this person = in". The OAuth flow would be: 1. A Dallas client of an employee of 'the company' issues a request to 'the= company's ticket issuer asking for a security token it can send to Dallas. 2. 'The Company's ticket issuer generates a signed assertion stating that t= he bearer has the right to use 'The Company's subscription to a particular = feed. 3. The Dallas client then forwards that security token to Dallas's ticket i= ssuer asking for an access token to actually talk to Dallas's front end. 4. Dallas validates the security token (e.g. checks the signature, makes su= re it has the right claims, etc.) and if successful then issues an access t= oken to the Dallas client. So in step 3 the client credential was a full-fledged security token of pot= entially arbitrary size. BTW, just to make sure I'm properly following along, we are talking about s= ection 3.9? Yaron > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Tuesday, May 11, 2010 4:37 PM > To: Yaron Goland; Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > No one was suggesting putting the assertion in the header. Just the clien= t > credentials... >=20 > EHL >=20 > > -----Original Message----- > > From: Yaron Goland [mailto:yarong@microsoft.com] > > Sent: Tuesday, May 11, 2010 4:24 PM > > To: Torsten Lodderstedt > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > > > Actually it's server side that's the problem. Many servers limit the > > size of the HTTP request headers they will accept. Apache 2.2, for > > example, uses the LimitRequestFieldSize Directive > > (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is > > 8190 bytes. IIS, I Believe, defaults to around 16K. But SAML > > assertions can easily clock in at 30 or 40k without even trying. > > > > So as a practical matter we need a way to allow clients to assert > > their right to a token using the request body so as to not need to > > artificially limit the size of the token that is being submitted. > > > > Yaron > > > > > -----Original Message----- > > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > > Sent: Monday, May 10, 2010 10:47 PM > > > To: Yaron Goland > > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > > > > > Am 11.05.2010 01:43, schrieb Yaron Goland: > > > > > > > >> --- > > > >> > > > >> 2. Client Authentication (in flows) > > > >> > > > >> How should the client authenticate when making token requests? > > > >> The current draft defines special request parameters for sending > > > >> client credentials. Some have argued that this is not the correct > > > >> way, and that the client should be using existing HTTP > > > >> authentication schemes to accomplish that such as Basic. > > > >> > > > >> A. Client authenticates by sending its credentials using special > > > >> parameters (current draft) B. Client authenticated by using HTTP > > > >> Basic (or other schemes supported by the server such as Digest) > > > >> > > > >> > > > > [Yaron Goland] A is needed at a minimum because there are physical > > > limitations to how many bytes can go into an authorization header. > > > > > > > > > > As far as I know, 4KB is the minimum size for headers that must be > > > supported by user agents, which should suffice from my point of view. > > > Moreover, other HTTP authentication mechanisms need much more than > > > 4KB, For example, SPNEGO authentication headers can be up to 12392 > > bytes. > > > > > > regards, > > > Torsten. > > > > > > >> _______________________________________________ > > > >> 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 > > > > > > > > > > >=20 From yarong@microsoft.com Thu May 13 13:52:21 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7923A68EB for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.941 X-Spam-Level: X-Spam-Status: No, score=-8.941 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] 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 d58wH0nLa5Mt for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:52:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 069A83A68F8 for <oauth@ietf.org>; Thu, 13 May 2010 13:52:19 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 13 May 2010 13:52:08 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Thu, 13 May 2010 13:52:09 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, "Manger, James H" <James.H.Manger@team.telstra.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Thread-Topic: sites with wildcard Thread-Index: AcrwTaPsC4ggYQawSQ6EnsB9Iie0cQATPiVwAAA9JoAAMWf8oAAASw0wAF1oGEA= Date: Thu, 13 May 2010 20:52:07 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A42BFF6@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A426BD7@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112632852F1@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C4A429748@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47460@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB47460@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] sites with wildcard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 20:52:22 -0000 V2h5IHdvdWxkIHRoZXJlIGJlIGFueSB1c2UgZXhwZXJpZW5jZSBhdCBhbGw/IA0KDQoxLiAgQW4g T0F1dGggY2xpZW50IGdldHMgYSByZWZyZXNoIHRva2VuIGluIHRoZSBjb250ZXh0IG9mIGh0dHA6 Ly9leGFtcGxlLmNvbQ0KMi4gV2hpbGUgaW50ZXJhY3Rpbmcgd2l0aCBodHRwOi8vZXhhbXBsZS5j b20gdGhlIE9BdXRoIGNsaWVudCBzZWVzIGEgbGluayB0byBodHRwOi8vZm9vLmNvbSBhbmQgaGFz IHJlYXNvbiB0byBiZWxpZXZlIHRoYXQgZm9vLmNvbSBpcyBhY3R1YWxseSBwYXJ0IG9mIGV4YW1w bGUuY29tIGJ1dCBpc24ndCBzdXJlLg0KMy4gU28gdGhlIE9BdXRoIGNsaWVudCBnb2VzIHRvIHRo ZSB0b2tlbiBpc3N1ZXIgaXQgdXNlcyBmb3IgaHR0cDovL2V4YW1wbGUuY29tIGFuZCBzdWJtaXRz IGl0cyByZWZyZXNoIHRva2VuIGFsb25nIHdpdGggYSBzY29wZSBwb2ludGluZyBhdCBodHRwOi8v Zm9vLmNvbS4NCjQuIEF0IHRoaXMgcG9pbnQgZWl0aGVyIGh0dHA6Ly9leGFtcGxlLmNvbSByZXR1 cm5zIGFuIGFjY2VzcyB0b2tlbiBmb3IgaHR0cDovL2Zvby5jb20gb3IgaXQgZG9lc24ndC4NCg0K VGhpcyBhcHByb2FjaCBkb2Vzbid0IHJlcXVpcmUgZGlzY292ZXJ5LCB1c2VyIGludGVyYWN0aW9u IG9yIGEgY2hhbmdlIHRvIHRoZSBleGlzdGluZyBwcm90b2NvbC4NCg0KCQlZYXJvbg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEVyYW4gSGFtbWVyLUxhaGF2IFttYWls dG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NCj4gU2VudDogVHVlc2RheSwgTWF5IDExLCAyMDEwIDQ6 MzYgUE0NCj4gVG86IFlhcm9uIEdvbGFuZDsgTWFuZ2VyLCBKYW1lcyBIOyBPQXV0aCBXRyAob2F1 dGhAaWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJFOiBzaXRlcyB3aXRoIHdpbGRjYXJkDQo+IA0KPiAN Cj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBvYXV0aC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ ID4gT2YgWWFyb24gR29sYW5kDQo+ID4gU2VudDogVHVlc2RheSwgTWF5IDExLCAyMDEwIDQ6Mjkg UE0NCj4gPiBUbzogTWFuZ2VyLCBKYW1lcyBIOyBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+ ID4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gc2l0ZXMgd2l0aCB3aWxkY2FyZA0KPiA+DQo+ID4g VGhhbmtzIGZvciBleHBsYWluaW5nLCBJIG5vdyBiZWxpZXZlIEkgdW5kZXJzdGFuZCB0aGUgdXNl IGNhc2UuDQo+ID4NCj4gPiBCdXQgSSB3b3VsZCBwb2ludCBvdXQgdGhhdCB0aGlzIGlzIHJlYWxs eSBhbiB1bnNvbHZlZCBwcm9ibGVtIGluDQo+ID4gZ2VuZXJhbCBhbmQgaWYgd2UgYXJlIHRvIHRh Y2tsZSBpdCB3ZSBoYXZlIHRvIGRlYWwgd2l0aCByZWFsIGNvbmNlcm5zDQo+ID4gc3VjaCBhcyDi gJMgd2hhdCBoYXBwZW5zIGlmIGluIHRoZSB0aW1lIHNpbmNlIHRoZSBzaXRlIGxpc3Qgd2FzIHBy b3ZpZGVkDQo+ID4gYW5kIHdoZW4gdGhlIHRva2VuIHdhcyB1c2VkIHRoZSBsaXN0IHdhcyBjaGFu Z2VkPyBJZiBhbiBhdHRhY2tlciBub3cNCj4gPiBjb250cm9scyBhIHByZXZpb3VzbHkgbGlzdGVk IHNpdGUgdGhlbiB0aGUgYXR0YWNrZXIgY2FuIGp1c3Qgc3dhbGxvdw0KPiA+IHRoZSBiZWFyZXIg dG9rZW4gYW5kIGRvIGJhZCB0aGluZ3MuIFNvIG5vdyB3ZSBoYXZlIHRvIHRoaW5rIGFib3V0DQo+ ID4gZXhwaXJhdGlvbiBpbmZvcm1hdGlvbiBvbiB0aGUgc2l0ZSBsaXN0IG9yIGEgcmV2b2NhdGlv biBtZWNoYW5pc20gb3Igc29tZQ0KPiBraW5kIG9mIG5lZ290aWF0aW9uLg0KPiANCj4gVG9rZW5z IGNhbiBiZSBzaG9ydCBsaXZlZCAtIHRoYXQncyB3aHkgd2UgaGF2ZSByZWZyZXNoIHRva2Vucy4g QW5kIGlmIHRoZXJlIGlzDQo+IGEgY2hhbmNlIG9mIHRoZSBzaXRlcyBsaXN0IGNoYW5naW5nLCB0 aGUgdG9rZW5zIHNob3VsZCBub3QgYmUgaXNzdWVkIHRvIG92ZXJsYXANCj4gd2l0aCBzdWNoIGEg Y2hhbmdlLiBCdXQgaW4gZ2VuZXJhbCwgdGhpcyBpcyByZWFsbHkgbm90IGEgcmVhbCBjb25jZXJu IGluIGFueQ0KPiBwcm9kdWN0aW9uIGVudmlyb25tZW50IHdoZXJlIHBlb3BsZSBsb3NlIGNvbnRy b2wgb3ZlciB0aGVpciBkb21haW4gbmFtZXMNCj4gaW4gc3VjaCBhIHRpbWVmcmFtZS4NCj4gDQo+ ID4gT25lIHdvbmRlcnMgaWYgaXQgd291bGRu4oCZdCBiZSBzaW1wbGVyIGZvciBjbGllbnRzIHRo YXQgYXJlIGluIGRvdWJ0IHRvDQo+ID4ganVzdCBtYWtlIGFub3RoZXIgdG9rZW4gcmVxdWVzdCB0 byB0aGUgb3JpZ2luYWwgc2VydmljZeKAmXMgdG9rZW4gaXNzdWVyDQo+ID4gd2l0aCBhIHNjb3Bl IGZvciB0aGUgZGVzaXJlZCBzaXRlLiBUaGF0IHdvcmtzIHdpdGggdGhlIGV4aXN0aW5nDQo+ID4g cHJvdG9jb2wgYW5kIG1pdGlnYXRlcyB0aGUgcHJldmlvdXMgYXR0YWNrLg0KPiANCj4gVGhhdCdz IGEgdmVyeSBiYWQgdXNlciBleHBlcmllbmNlIChoYXZpbmcgdG8gZ3JhbmQgYWNjZXNzIGFnYWlu IGZvciB0aGUgc2FtZQ0KPiBjbGllbnQpLCBhc3N1bWluZyB0aGVyZSBldmVuIGlzIGEgdXNlciB0 byBidWcgYWJvdXQgYXV0aG9yaXphdGlvbi4NCj4gDQo+IEVITA0K From eran@hueniverse.com Thu May 13 14:14:31 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89F13A6D39 for <oauth@core3.amsl.com>; Thu, 13 May 2010 14:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_50=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 BfW+7utwAoVs for <oauth@core3.amsl.com>; Thu, 13 May 2010 14:14:25 -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 4D94E3A6D21 for <oauth@ietf.org>; Thu, 13 May 2010 14:14:24 -0700 (PDT) Received: (qmail 10029 invoked from network); 13 May 2010 21:14:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 May 2010 21:14:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 13 May 2010 14:14:11 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Yaron Goland <yarong@microsoft.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 13 May 2010 14:14:24 -0700 Thread-Topic: Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vAC/+jNgAAhGIwAAAP6TwA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.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] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 21:14:31 -0000 There is clearly no consensus for either A or B. There was mostly no object= ion to C, and the reason given by most of those who objected was client com= plexity with the current proposal solves. Weak consensus means that the option has some support and little objection.= If those who had something against C still think the solution doesn't addr= ess their reason for voting against it, they are free (as always) to expres= s their objections again. Unlike other features of the spec which we can keep out while discussing it= , this one is critical and the spec is completely useless without. It is fa= r better to have support for three options (with the option of moving two t= o an extension document with the format parameter) than to pick one and the= n change it. I believe there was enough support for putting C in the draft. If you have = a problem with that, feel free to ask the chairs for a different resolution= . EHL > -----Original Message----- > From: Yaron Goland [mailto:yarong@microsoft.com] > Sent: Thursday, May 13, 2010 1:50 PM > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: RE: Open Issues: Group Survey (respond by 5/13) >=20 > I went through and counted all the votes I could find in the mail archive= (I > have reproduced the results below). 8 people explicitly stated a preferen= ce > for A or B (of those 4 explicitly stated they don't want C). Only 3 peopl= e voted > for C as their first choice. >=20 > Even if we bunch together people who voted for C and people who could liv= e > with C (but picked another option as their first choice) that is still on= ly 5 who > expressed any level of preference for C versus 6 people who didn't pick C= at > all. >=20 > Given these numbers I am at a loss to understand why you believe a > consensus (weak or otherwise) exists for C. Could you please explain your > reasoning? >=20 > Thanks, >=20 > Yaron >=20 > Vivek Khurana - A or B but not C > Yaron Goland - A then B but not C > David Waite - A or B but doesn't like C > Mike Moore - A (but not C) > Dick Hardt - B > James H Manger - B >=20 > Torsten Lodderstedt - B but could live with C Joseph Smarr - B but could = live > with C >=20 > Justin P. Richer - C > Eran Hammer-Lahav - C > David Recordon - C >=20 > Mark Mcgloin - No preference >=20 >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Thursday, May 13, 2010 10:01 AM > > To: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > > > Thanks to those who participated! > > > > Some conclusions: > > > > > 1. Server Response Format > > > > > > After extensive debate, we have a large group in favor of using JSON > > > as the only response format (current draft). We also have a smaller > > > group but with stronger feelings on the subject that JSON adds > > > complexity with no obvious value. > > > > > > A. Form-encoded only (original draft) B. JSON only (current draft) > > > C. JSON as default with form-encoded and XML available with an > > > optional request parameter > > > > It seems like we have weak consensus to go with C where the server > > must support all three formats, and the client can use either one. > > This approach addresses most of the concerns around client complexity > > / size. Only one person strongly objected to C (without an explanation > > that can be addressed). Summing up the results was hard because many > > people had no strong preference between A and B but with each of the > > three options received about a third of the votes. > > > > My guess is that if we held another vote asking if the spec should > > only support form-encoded or all three - all three will get most of > > the votes (and same if we made JSON the only option or all three). > > This is why C is really the only way to move forward at this point. We > > can revisit this later if implementation experience shows supporting > > all three in this manner is a problem. > > > > I am going to add this to the specification as a point of reference > > for future discussions. > > > > > 2. Client Authentication (in flows) > > > > > > How should the client authenticate when making token requests? The > > > current draft defines special request parameters for sending client > > > credentials. Some have argued that this is not the correct way, and > > > that the client should be using existing HTTP authentication schemes > > > to accomplish that such as Basic. > > > > > > A. Client authenticates by sending its credentials using special > > > parameters (current draft) B. Client authenticated by using HTTP > > > Basic (or other schemes supported by the server such as Digest) > > > > Weak consensus to support both request parameters and HTTP Basic > > authentication (with other schemes as optional). I will add a new > > section to the draft allowing replacing the parameters with an HTTP > > authentication header. The flows text will remain the same. > > > > EHL > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From sayrer@gmail.com Thu May 13 16:26:50 2010 Return-Path: <sayrer@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB4C3A6918 for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=-0.348, 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 JPr3BamtcT1P for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:26:50 -0700 (PDT) Received: from mail-qy0-f200.google.com (mail-qy0-f200.google.com [209.85.221.200]) by core3.amsl.com (Postfix) with ESMTP id 97AED3A68BC for <oauth@ietf.org>; Thu, 13 May 2010 16:26:48 -0700 (PDT) Received: by qyk38 with SMTP id 38so442649qyk.17 for <oauth@ietf.org>; Thu, 13 May 2010 16:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ae7gxTPzqkaWDIIiJmvJnLl7/F0LK3RWHX55dxqDq2s=; b=O71wpEx8rJYPUJxiCC2DGDKq0gpbhOOY2nl/vNk1nAGvNS/VkywSnU1ujhfjDoMuro iaHi4lenkH2WMSHeVNvgzr0az2BrKLoBTgN6ncuGc42d7qV5VeU1LaMSV6QZSv40vV+d TH1K0pIdwYdi4cf9TnPjlYnpxJxCXU4P3G/pQ= 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=FLYRanrDBTj+gGJOOGC57UqdqbScxTaLEhLf2gWzVTDsDgbLvWsrE6briIrR1QxcBp cAbEzdp5OYGBar8IdqZqSDx0Yv7DeB+YcIl7iSj9Q8J1r/pW3U42eXe1aOFD1WcVt5C3 agUNUQ+/BDcxI19lQ1u2I04UJDcKcr9vilp1I= MIME-Version: 1.0 Received: by 10.224.43.100 with SMTP id v36mr73022qae.201.1273793196205; Thu, 13 May 2010 16:26:36 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Thu, 13 May 2010 16:26:36 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 13 May 2010 19:26:36 -0400 Message-ID: <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> From: Robert Sayre <sayrer@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 23:26:51 -0000 On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > There is clearly no consensus for either A or B. There was mostly no objection to C, > and the reason given by most of those who objected was client complexity with the current proposal solves. My objection to C was that your examples were buggy. So, to be tediously explicit: B, then A. Not C. - Rob From eran@hueniverse.com Thu May 13 16:43:18 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46D43A6858 for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 EC90oR97dCdB for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:43:18 -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 D52A43A67D6 for <oauth@ietf.org>; Thu, 13 May 2010 16:43:17 -0700 (PDT) Received: (qmail 9741 invoked from network); 13 May 2010 23:43:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 May 2010 23:43:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 13 May 2010 16:43:07 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Robert Sayre <sayrer@gmail.com> Date: Thu, 13 May 2010 16:43:22 -0700 Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: Acry871AxrWfi4yNRSSTIQ+xy3o/RgAAkUlQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> In-Reply-To: <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.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 WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 23:43:18 -0000 Can you give a reason why you are objecting to C. EHL > -----Original Message----- > From: Robert Sayre [mailto:sayrer@gmail.com] > Sent: Thursday, May 13, 2010 4:27 PM > To: Eran Hammer-Lahav > Cc: Yaron Goland; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav > <eran@hueniverse.com> wrote: > > There is clearly no consensus for either A or B. There was mostly no > > objection to C, and the reason given by most of those who objected was > client complexity with the current proposal solves. >=20 > My objection to C was that your examples were buggy. So, to be tediously > explicit: >=20 > B, then A. Not C. >=20 > - Rob From sayrer@gmail.com Thu May 13 16:54:30 2010 Return-Path: <sayrer@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12DF3A6ABC for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_20=-0.74, GB_I_LETTER=-2] 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 5d1ywUSfJryB for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:54:30 -0700 (PDT) Received: from mail-qy0-f200.google.com (mail-qy0-f200.google.com [209.85.221.200]) by core3.amsl.com (Postfix) with ESMTP id 026703A67D6 for <oauth@ietf.org>; Thu, 13 May 2010 16:54:29 -0700 (PDT) Received: by qyk38 with SMTP id 38so477348qyk.17 for <oauth@ietf.org>; Thu, 13 May 2010 16:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4+gx8GnCyKN20HXyuRlD4oOgBrhQea4O377Va+sLlqE=; b=NU5kuLOx0KSZUYf/9aXs6bGDJQh58pZ3Iz4V+1p4sw+CDbhKpLeeFDrED3746FKq3T vsESUkFM27ZP3RQAiyAOA6yXTZTFNirduL9rX/TIcvGs9EW/ji2ZafP5dRAx4tRUsAZW x7ZB6ZUIqTYK0atAmYzfew8CGsG02STFrLv08= 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=S/QkJ+liGlz2pwm28qyMsjWawTs4EQkdqrR7BiICJLo2I7PTU2imAEffBT0kE+nO5d I0WW9eTj3hQgeMhKs4R8gfJTVoIvbu4DzDjMwgW6Uv62x+Y7MLSulJXDCyxoimuF0fog BDjOwy+6LgrLUHD0maw81JZR0vlR1jxMXFW2U= MIME-Version: 1.0 Received: by 10.224.88.40 with SMTP id y40mr69036qal.383.1273794857585; Thu, 13 May 2010 16:54:17 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Thu, 13 May 2010 16:54:17 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 13 May 2010 19:54:17 -0400 Message-ID: <AANLkTik3_xSmDVp0vEQDtHiXFGxnhR6xOgLDGEPCSFdm@mail.gmail.com> From: Robert Sayre <sayrer@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 23:54:30 -0000 On Thu, May 13, 2010 at 7:43 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > Can you give a reason why you are objecting to C. > As I just wrote: > My objection to C was that your examples were buggy. I don't think servers or clients will get XML, JSON, and form-encoded right without taking on a lot of 3rd party dependencies. Even if those dependencies are ok, three serialization formats will enlarge the QA matrix enough to hurt interoperability. The nature of this objection seems pretty obvious. - Rob -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From James.H.Manger@team.telstra.com Thu May 13 16:54:54 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40F53A6ABC for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.475 X-Spam-Level: * X-Spam-Status: No, score=1.475 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBZFFEidlzzm for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:54:54 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id AC4733A69C9 for <oauth@ietf.org>; Thu, 13 May 2010 16:54:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,225,1272808800"; d="scan'208";a="2558107" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 14 May 2010 09:54:43 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5981"; a="1959522" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbni.tcif.telstra.com.au with ESMTP; 14 May 2010 09:54:43 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 14 May 2010 09:54:43 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Evan Gilbert <uidude@google.com> Date: Fri, 14 May 2010 09:54:42 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcrytXxo4x83RRX6Tuaa6g1JfrbrKAAPsZzg Message-ID: <255B9BB34FB7D647A506DC292726F6E112634659EC@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <AANLkTincZ8_0-t2r_Ey9BestA_knMciYsxRLyHcOvSVO@mail.gmail.com> <g2xfd6741651005071106if93ba794q7e9739669eb22fc2@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> In-Reply-To: <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 23:54:54 -0000 RXZhbiwNCg0KPiB3ZSBoYXZlIG5vIEFQSSBlbmRwb2ludHMgdGhhdCBhcmUgb25seSBhcnJpdmVk IGF0IGJ5IGxpbmtzDQoNClRoaXMgZG9lc24ndCBzb3VuZCB2ZXJ5IHdlYi1mcmllbmRseS4gWW91 ciBBUElzIGRvbid0IGhhdmUgdG8gZm9sbG93IGEgd2ViLXN0eWxlLCBidXQgYW4gSUVURiBzcGVj IHNob3VsZCBzdXBwb3J0IHdlYi1zdHlsZSBBUElzLg0KDQpJIGFtIGEgYml0IHN1cnByaXNlZCB3 aXRoIHlvdXIgc3RhdGVtZW50IGFzIGEgd2hvbGUgbG90IG9mIEdvb2dsZSBBUElzIGRvIGhhdmUg QVBJIGVuZHBvaW50cyBhcnJpdmVkIGF0IGJ5IGxpbmtzLiBJIHRob3VnaHQgbW9zdCBHb29nbGUg RGF0YSBBUElzIGZvbGxvd2VkIHRoZSBBdG9tIFB1Ymxpc2hpbmcgUHJvdG9jb2wuIFRoaXMgdXNl cyBsaW5rcyBleHRlbnNpdmVseS4gRm9yIGluc3RhbmNlLCA8bGluayByZWw9ImVkaXQiIGhyZWY9 Ii4uLiIvPiB0ZWxscyB0aGUgY2xpZW50IHRoZSBBUEkgZW5kcG9pbnQgdG8gYXQgd2hpY2ggYW4g ZW50cnkgY2FuIGJlIHVwZGF0ZWQuDQoNClRoZXJlIGFyZSBsb3RzIGFuZCBsb3RzIG9mIDxsaW5r IHJlbD0iLi4uIiBocmVmPSIuLi4iLz4gcmVsYXRpb25zIGRlZmluZWQ6IGluIHRoZSBBdG9tIHNw ZWMsIGluIHRoZSBBUFAgc3BlYywgaW4gR0RhdGEgZG9jcyAobm90IHNwZWNpZmljIHRvIHBhcnRp Y3VsYXIgQVBJcykgZXRjLg0KDQpEZWZpbml0aW9ucyBvZiBub25lIG9mIHRoZXNlIGxpbmsgcmVs YXRpb25zIHN0YXRlIHRoYXQgdGhleSBNVVNUIG9yIE1VU1QgTk9UIGJlIHBhcnQgb2YgdGhlIHNh bWUgQVBJLg0KwqANCg0KDQo+IEFub3RoZXIgbm90ZTogV2hlcmUgZG8gd2UgYW50aWNpcGF0ZSBj bGllbnRzIHN0b3JpbmcgdGhlIHNpdGVzIHBhcmFtZXRlciBpbiB0aGUgVXNlci1BZ2VudCBmbG93 PyBSaWdodCBub3cgdGhlIGFjY2VzcyB0b2tlbiBjYW4gYmUgc2V0IGFzIGFuIEhUVFAgY29va2ll IGJ5IHRoZSBjbGllbnQuIERvIHdlIGV4cGVjdCB0aGVtIHRvIHNldCBhIHNlcGFyYXRlICJzaXRl cyIgY29va2llIGFuZCByZXNwZWN0IHRoaXMgb24gdGhlaXIgc2VydmVyIHdoZW4gbWFraW5nIHJl cXVlc3RzPyBUaGlzIHNlZW1zIGNvbXBsaWNhdGVkLg0KDQpQcmVzdW1hYmx5IHRoZSBjbGllbnQg bmVlZHMgdG8gc3RvcmUgdGhlIGFjY2VzcyB0b2tlbiwgdGhlIGV4cGlyeSBkYXRlLCBwZXJoYXBz IHRoZSBzY29wZXMgZXRjLiBFYXN5IHNvbHV0aW9uOiBzdG9yZSB0aGUgYmFzZTY0LWVuY29kaW5n IG9mIHRoZSBKU09OIHJlcHJlc2VudGF0aW9uIG9mIHRoZSB0b2tlbiBkZXRhaWxzLg0KDQoNCi0t DQpKYW1lcyBNYW5nZXINCg0K From sayrer@gmail.com Thu May 13 16:56:27 2010 Return-Path: <sayrer@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7099C3A697B for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_40=-0.185, GB_I_LETTER=-2] 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 TbA-qjaLvj9m for <oauth@core3.amsl.com>; Thu, 13 May 2010 16:56:26 -0700 (PDT) Received: from mail-qy0-f200.google.com (mail-qy0-f200.google.com [209.85.221.200]) by core3.amsl.com (Postfix) with ESMTP id CCD2D3A67D6 for <oauth@ietf.org>; Thu, 13 May 2010 16:56:25 -0700 (PDT) Received: by qyk38 with SMTP id 38so479830qyk.17 for <oauth@ietf.org>; Thu, 13 May 2010 16:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BWrPHGvEzbMknyEbp1SGUDImCZwvpbK8jZRvlIpYDpc=; b=meZwXxAMQ/kAgQWaYecsO9D/nyLhBvZyt+60Q89wcvEuAGhaeSiS13kPyPRO7Z4UOp /Qxh8OyhhxJ9S2ckKiyuBAPozOaPSf0Jxgn4Bzr2acdsrN6kuVL3vzJWfaLkE0JzlQPG 2faEMyPPzSJVDe4BVwbriSpzeHIHAd+dMgeds= 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=lGYVQsNZhv4xKpjR/iNm45eWoPT4JH3/d1VWmbEslLYh+4GgUG7De/kjNILhtGB6Xa bqG/k7ThmamDDThtkQyFsP9XGfmCHRT3YgXrNLFZo+fgGXk9PdKm7dUc21OmayxBo4DU 9CJY+bFFl0GTQAFDUU23xq+64IqaKW25moVhY= MIME-Version: 1.0 Received: by 10.224.71.161 with SMTP id h33mr92324qaj.161.1273794973592; Thu, 13 May 2010 16:56:13 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Thu, 13 May 2010 16:56:13 -0700 (PDT) In-Reply-To: <4BEBD074.7020007@lodderstedt.net> References: <20100510054516.2957E3A6B0C@core3.amsl.com> <AANLkTinTq_5R0gFqCM3Ctj5elpAjO3vA87WCGZhdrfOF@mail.gmail.com> <4BEA8999.7070205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB475C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BEAD9B3.2040609@oracle.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47638@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimy5RgYjLwIJIcG4sA9Alf1Ew1CoXlcXvSv1Vod@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4779B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTikld8irGPnlb82mrIc8UB9eO7fsEkN_saD9jBlC@mail.gmail.com> <4BEBD074.7020007@lodderstedt.net> Date: Thu, 13 May 2010 19:56:13 -0400 Message-ID: <AANLkTinSqXjUyPB_ZGaQhX4GgKEKSkd8Gu8nU5FLXzK1@mail.gmail.com> From: Robert Sayre <sayrer@gmail.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1 Cc: Prateek Mishra <prateek.mishra@oracle.com>, "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 13 May 2010 23:56:27 -0000 On Thu, May 13, 2010 at 6:12 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > >> >> Sure, to give one example, I would make the device flow a separate >> spec immediately. That seems only distantly related to other things in >> the spec, and may not be really necessary by the time the standard >> matures. >> > > Why does this hold for the device flow and not for other flows? For us > (Deutsche Telekom), the device flow is one of the most important pieces of > the spec since we want to use OAuth for a variety of autonomous devices with > limited input capabilities (Set Top Boxes, TV Sets, handsets, ....). I'm not saying the use case is invalid. Are you saying Deutsche Telekom can't implement the device flow if it is not finalized at precisely the same time as the other parts of OAuth? -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From uidude@google.com Thu May 13 17:02:57 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6853A6942 for <oauth@core3.amsl.com>; Thu, 13 May 2010 17:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.37 X-Spam-Level: X-Spam-Status: No, score=-100.37 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 UwTmm1tqWGQa for <oauth@core3.amsl.com>; Thu, 13 May 2010 17:02:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A47C73A6864 for <oauth@ietf.org>; Thu, 13 May 2010 17:02:55 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o4E02ifd005814 for <oauth@ietf.org>; Thu, 13 May 2010 17:02:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273795364; bh=RVgOqxnNNYvtmZUNxZOdncvbTn4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LJLSAlfAswZPPpIZqkDIpLUFEdXpXKZMGqZAbFuAaHTFt6jWN0SDplQtFBVYnGzLn im7DPpvnR66sFZCSwsnxQ== 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=RK1+5B53yb/l7CAjprwkvPBLu76gpTC+TghNszhfmkN9dE/D+3MMXe1zV3QYRP+GC BGsD6PiVFZF5OPqdBBkaQ== Received: from qyk17 (qyk17.prod.google.com [10.241.83.145]) by hpaq6.eem.corp.google.com with ESMTP id o4E02ccU009014 for <oauth@ietf.org>; Thu, 13 May 2010 17:02:43 -0700 Received: by qyk17 with SMTP id 17so2301493qyk.12 for <oauth@ietf.org>; Thu, 13 May 2010 17:02:43 -0700 (PDT) Received: by 10.224.123.3 with SMTP id n3mr90570qar.211.1273795363152; Thu, 13 May 2010 17:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.136 with HTTP; Thu, 13 May 2010 17:02:23 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112634659EC@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634659EC@WSMSG3153V.srv.dir.telstra.com> From: Evan Gilbert <uidude@google.com> Date: Thu, 13 May 2010 17:02:23 -0700 Message-ID: <AANLkTim91Jr6zKE_BYYtDDkqFFoyitxqiAh3QoU5owUP@mail.gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=00c09f8e5fb42322d2048682980d X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 00:02:57 -0000 --00c09f8e5fb42322d2048682980d Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 13, 2010 at 4:54 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Evan, > > > we have no API endpoints that are only arrived at by links > > This doesn't sound very web-friendly. Your APIs don't have to follow a > web-style, but an IETF spec should support web-style APIs. I didn't say that our endpoints can't be arrived at by links. I said our APIs all can be called directly and clients need to know how to call them directly. Clients need to have a way of finding out: 1. The available endpoint URLs, and 2. The scopes to ask for to access these URLs "sites" by itself is insufficient to be useful to our developers. > I am a bit surprised with your statement as a whole lot of Google APIs do > have API endpoints arrived at by links. I thought most Google Data APIs > followed the Atom Publishing Protocol. This uses links extensively. For > instance, <link rel="edit" href="..."/> tells the client the API endpoint to > at which an entry can be updated. > > There are lots and lots of <link rel="..." href="..."/> relations defined: > in the Atom spec, in the APP spec, in GData docs (not specific to particular > APIs) etc. > > Definitions of none of these link relations state that they MUST or MUST > NOT be part of the same API. > > > > > Another note: Where do we anticipate clients storing the sites parameter > in the User-Agent flow? Right now the access token can be set as an HTTP > cookie by the client. Do we expect them to set a separate "sites" cookie and > respect this on their server when making requests? This seems complicated. > > Presumably the client needs to store the access token, the expiry date, > perhaps the scopes etc. Easy solution: store the base64-encoding of the JSON > representation of the token details. > Currently the client side flow is really simple: 1. Set access token as a cookie, with 2. An expiration matching the expires_in time Are you suggesting the client parse the URL parameters, create a JSON block, base64 encode the block, and then write an HTTP cookie? > > -- > James Manger > > --00c09f8e5fb42322d2048682980d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, May 13, 2010 at 4:54 PM, Manger,= James H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Manger@team.telstr= a.com">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex;"> Evan,<br> <div class=3D"im"><br> > we have no API endpoints that are only arrived at by links<br> <br> </div>This doesn't sound very web-friendly. Your APIs don't have to= follow a web-style, but an IETF spec should support web-style APIs.</block= quote><div><br></div><div>I didn't say that our endpoints can't be = arrived at by links.=A0I said our APIs all can be called directly and clien= ts need to know how to call them directly.</div> <div><br></div><div>Clients need to have a way of finding out:</div><div>1.= The available endpoint URLs, and=A0</div><div>2. The scopes to ask for to = access these URLs</div><div><br></div><div>"sites" by itself is i= nsufficient to be useful to our developers.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex;"> <br> I am a bit surprised with your statement as a whole lot of Google APIs do h= ave API endpoints arrived at by links. I thought most Google Data APIs foll= owed the Atom Publishing Protocol. This uses links extensively. For instanc= e, <link rel=3D"edit" href=3D"..."/> tells the cl= ient the API endpoint to at which an entry can be updated.<br> <br> There are lots and lots of <link rel=3D"..." href=3D"...&= quot;/> relations defined: in the Atom spec, in the APP spec, in GData d= ocs (not specific to particular APIs) etc.<br> <br> Definitions of none of these link relations state that they MUST or MUST NO= T be part of the same API.<br> <div class=3D"im">=A0<br> <br> <br> > Another note: Where do we anticipate clients storing the sites paramet= er in the User-Agent flow? Right now the access token can be set as an HTTP= cookie by the client. Do we expect them to set a separate "sites"= ; cookie and respect this on their server when making requests? This seems = complicated.<br> <br> </div>Presumably the client needs to store the access token, the expiry dat= e, perhaps the scopes etc. Easy solution: store the base64-encoding of the = JSON representation of the token details.<br></blockquote><div><br>Currentl= y the client side flow is really simple:</div> <div>1. Set access token as a cookie, with</div><div>2. An expiration match= ing the expires_in time</div><div><br>Are you suggesting the client parse t= he URL parameters, create a JSON block, base64 encode the block, and then w= rite an HTTP cookie?=A0</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex;"> <br> <br> --<br> <font color=3D"#888888">James Manger<br> <br> </font></blockquote></div><br> --00c09f8e5fb42322d2048682980d-- From michael.d.adams@gmail.com Thu May 13 17:03:16 2010 Return-Path: <michael.d.adams@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381CB3A6C21 for <oauth@core3.amsl.com>; Thu, 13 May 2010 17:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 ClXNgnOhy-5R for <oauth@core3.amsl.com>; Thu, 13 May 2010 17:03:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 15C363A6864 for <oauth@ietf.org>; Thu, 13 May 2010 17:03:15 -0700 (PDT) Received: by gyh4 with SMTP id 4so989556gyh.31 for <oauth@ietf.org>; Thu, 13 May 2010 17:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=iNurqLG+6i9jrYNlUYLWsV8XhHJ/1wK4IFcJaJjlRCg=; b=h4z9hLWeLsAJjW83qD9mGLby5UAKs1uETjMFgSfaWG5bfrwdV4wUNDUzcS67gKXmxn FdelT2rLgJr+J5d3x62bk2/s95CLAMGpWmRHrz5i+QYoaNhfUtUcwUD+fKFkSuUT5wMu dd442qaXk6vf2MAH3uvYADbNqnbDiiP9Tyouo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; b=ubc9r4dMrV7CovmDzOff3HiSEgfJT02ma9s32lRif9gR5Z/G5J6/BDEdN/3TXZVYfj SK5gcuN+rFbevyzNmhKUY0bzbsYdZrnzvMG31BKJDVbAzl7EOiKxxU+vgcO+LWRB8FeD xytIXVRr0p7GASH/Rwc61ZfrCUza9cgoR0QPo= Received: by 10.101.132.37 with SMTP id j37mr258053ann.121.1273795382194; Thu, 13 May 2010 17:03:02 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.11.197 with HTTP; Thu, 13 May 2010 17:02:39 -0700 (PDT) From: Michael D Adams <mike@automattic.com> Date: Thu, 13 May 2010 17:02:39 -0700 X-Google-Sender-Auth: GxUB_eX_vPb0aAW2WF0i1isU-MQ Message-ID: <AANLkTin-KAo7M-IHupanLcOE1ZIzLQbO13imSNAONpYr@mail.gmail.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Three issues with format parameter in draft-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 00:05:16 -0000 Three things about draft-05's new format parameter. 1. Error Response: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.2 Presumably, the error response format should reflect the format parameter passed by the client. Proposed Text (wording taken from http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.1): If the token request is invalid or unauthorized, the authorization server constructs a response using the format requested by the client, which includes the common parameters set as well as additional flow-specific parameters. =A0The formatted parameters are sent to the client in the entity body of the HTTP response with a 400 status code (Bad Request). Also, I'm not sure what "the common parameters set" means. =A0Perhaps change both http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2= .2 and http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.3.2.1 to read "the common parameters listed here"? 2. Accept Header Could the functionality of the format parameter be replaced by an HTTP Accept header? =A0It's not as flexible (I suppose an AS could define multiple XML formats, for example), and probably can't be used conveniently in GET requests. =A0Currently, all requests defined in the spec that use the format parameter are POST requests, though. Accept: application/json Accept: application/xml Accept: application/x-www-form-urlencoded 3. Naming Conflict The assertion flow now has two format parameters :) =A0Renaming one or requiring the use of an Accept Header as above would solve this. --mdawaffe From michael.d.adams@gmail.com Thu May 13 18:06:25 2010 Return-Path: <michael.d.adams@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D093A6995 for <oauth@core3.amsl.com>; Thu, 13 May 2010 18:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.068 X-Spam-Level: X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[AWL=-0.555, 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 G8XN+75XYv+X for <oauth@core3.amsl.com>; Thu, 13 May 2010 18:06:24 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id B34533A695F for <oauth@ietf.org>; Thu, 13 May 2010 18:06:19 -0700 (PDT) Received: by ywh3 with SMTP id 3so1067124ywh.31 for <oauth@ietf.org>; Thu, 13 May 2010 18:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=l4N1ZyKtDE8a4+P8ZicCGNvAlBaXXM8gPGOQrZ9Jj0c=; b=DdH03YnX19uJ8TnF7rTv8GSms4uaCMvrXJ2v9DROZiaqyuI5RfLBgjI9jJ+eS6n5hV xtLai+idtuXadW313685OP209990QeFokUG7xaV4E4iOzHN4mwRPhiof6F2YjqfbCOqv 5fA1AMGY70+WZrWjKPRT6wsl3MUD+6tkF800M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=rcfAIIIozSKZfkoXJtUDyZLg4UnyVJJAODOyJ4NtmeSK1Q1/EL7wJncM0ICWj/PPgZ Qe/bShGY0PGdPZ1iZocj6z+e40tRDmDpKtcexXZtdpDF4s91pYMx+iQocXh5mdTRsATg m2t46Z/VwbQ8ww409pBF1M4uCtwVoBA4aN2O8= Received: by 10.150.193.10 with SMTP id q10mr1233221ybf.105.1273799167303; Thu, 13 May 2010 18:06:07 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.11.197 with HTTP; Thu, 13 May 2010 18:05:47 -0700 (PDT) From: Michael D Adams <mike@automattic.com> Date: Thu, 13 May 2010 18:05:47 -0700 X-Google-Sender-Auth: 6-4aODDdAAO6_XAPRW3mID-MdLQ Message-ID: <AANLkTilFBtkHw0UhFPSVG_1uZjZj9f1Fcbrsuw_LFRgQ@mail.gmail.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Requiring Cryptographic Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 01:06:25 -0000 I'm interested in the possibility of requiring clients to use cryptographic tokens. Context: I'm writing a WordPress plugin to handle OAuth 2.0 authentication. Small one-off WordPress sites (probably on a shared host) likely cannot use SSL. Such a site would necessarily be non-compliant because "the authorization server MUST require the use of a transport-layer mechanism such as TLS/SSL (or a secure channel with equivalent protections) when sending requests to the token endpoints". I understand that bearer tokens over SSL are "the way of the future", but I don't think they're the "way of the now", and the future is a ways off for small sites. OAuth 2.0 use case for WordPress site without SSL: Mars Edit, Windows Live Writer, and other desktop blog editors. (Ignore for the moment that the APIs WordPress offers to blog editors require XML POST bodies which are unsigned by core OAuth 2.0.) Tripartite Proposal: 1. Change the above "MUST" to a "SHOULD". 2. Somewhere in section 3. Obtaining an Access Token, add <<EOP During an access token request over an insecure channel, the authorization server MAY enforce the use of cryptographic tokens by requiring the client to set the secret_type parameter. If the secret_type parameter is not set for such a request to such an authorization server, the authorization server MUST issue a 400 Bad Request response with error code "unsupported_secret_type". EOP 3. In section 5. Accessing a Protected Resource, add <<EOP During a protected resource request using a over an insecure channel, the protected resource server MAY enforce the use of cryptographic tokens. If a bearer token is sent for such a request to such a protected resource server, the protected resource server MUST issue a 400 Bad Request response with an error code "invalid_signature". EOP The wording may not be the best. The idea is that these optional requirements imposed by the authorization/protected resource server should be discoverable by the client. Requiring cryptographic tokens *isn't* necessary for a WordPress plugin, just nice. For example, sending bearer tokens in the clear is no worse than sending WordPress's default auth cookies in the clear (except that one is for API calls and one is for user-agents). Saying that token endpoints "SHOULD" use SSL vs. "MUST" use SSL (part 1 of the above), though, would allow such sites to be conditionally compliant instead of non-compliant. --mdawaffe From gbrail@sonoasystems.com Thu May 13 18:57:00 2010 Return-Path: <gbrail@sonoasystems.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A4E3A67B3 for <oauth@core3.amsl.com>; Thu, 13 May 2010 18:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-0.464, 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 dTpbnKoDcuvf for <oauth@core3.amsl.com>; Thu, 13 May 2010 18:56:59 -0700 (PDT) Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by core3.amsl.com (Postfix) with ESMTP id 2AF783A67AD for <oauth@ietf.org>; Thu, 13 May 2010 18:56:59 -0700 (PDT) Received: by qyk28 with SMTP id 28so2212755qyk.27 for <oauth@ietf.org>; Thu, 13 May 2010 18:56:44 -0700 (PDT) Received: by 10.224.105.80 with SMTP id s16mr134922qao.337.1273802204668; Thu, 13 May 2010 18:56:44 -0700 (PDT) From: Greg Brail <gbrail@sonoasystems.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vADTDuPw Date: Thu, 13 May 2010 21:56:42 -0400 Message-ID: <2e28a7cd36dc27dbf7ebe6d0d99fa516@mail.gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 01:57:00 -0000 I'm sorry that I'm late on this but for what it's worth: Server Response Format: I prefer A (form-encoded only). It's the simplest solution that requires the least amount of client-side technology. JSON is too complex a spec for simply encoding a set of flat key-value parameters when where is already a well-established way to do this today in the HTTP spec. My second preference is B (JSON only). Client authentication: OAuth 1.0a was fine with authentication explicitly expressed in the headers and I think 2.0 should stay the same. More importantly, however -- I think that the spec should try to keep things simple rather than offer multiple choice on many different aspects of the implementation. The world is full of complicated specs and it's always easier to keep adding options than to choose one of several alternatives. Better to pick one that works well enough for everyone rather than to keep adding choices to satisfy special cases that may or may not be important in the future. So in either of those cases, if Eran or whoemever is so empowered were to choose, for example, "JSON only" and "HTTP basic only," then I would support both choices over a set of options even though in both cases neither is my first choice. greg -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Sunday, May 09, 2010 5:07 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) DEADLINE: 5/13 I would like to publish one more draft before our interim meeting in two weeks (5/20). Below are two open issues we have on the list. Please reply with your preference (or additional solutions) to each item. Issues with consensus will be incorporated into the next draft. Those without will be discussed at the meeting. EHL --- 1. Server Response Format After extensive debate, we have a large group in favor of using JSON as the only response format (current draft). We also have a smaller group but with stronger feelings on the subject that JSON adds complexity with no obvious value. A. Form-encoded only (original draft) B. JSON only (current draft) C. JSON as default with form-encoded and XML available with an optional request parameter --- 2. Client Authentication (in flows) How should the client authenticate when making token requests? The current draft defines special request parameters for sending client credentials. Some have argued that this is not the correct way, and that the client should be using existing HTTP authentication schemes to accomplish that such as Basic. A. Client authenticates by sending its credentials using special parameters (current draft) B. Client authenticated by using HTTP Basic (or other schemes supported by the server such as Digest) _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu May 13 19:02:17 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48ED3A6947 for <oauth@core3.amsl.com>; Thu, 13 May 2010 19:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 vmunq133oNBM for <oauth@core3.amsl.com>; Thu, 13 May 2010 19:02: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 C01C13A69CD for <oauth@ietf.org>; Thu, 13 May 2010 19:02:14 -0700 (PDT) Received: (qmail 13604 invoked from network); 14 May 2010 02:02:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 May 2010 02:02:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 13 May 2010 19:02:00 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Greg Brail <gbrail@sonoasystems.com>, OAuth WG <oauth@ietf.org> Date: Thu, 13 May 2010 19:02:13 -0700 Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: Acrvu4cfH3LKPgwRQV+7sW5YxUA1vADTDuPwAABgU8A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B698A21@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <2e28a7cd36dc27dbf7ebe6d0d99fa516@mail.gmail.com> In-Reply-To: <2e28a7cd36dc27dbf7ebe6d0d99fa516@mail.gmail.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] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 02:02:18 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Greg Brail > Sent: Thursday, May 13, 2010 6:57 PM >Eran or whoemever is so empowered were to choose No one is empowered to choose. We need to keep at it until we reach consens= us, but someone has to give. EHL =20 From James.H.Manger@team.telstra.com Thu May 13 20:25:34 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571BD3A69EB for <oauth@core3.amsl.com>; Thu, 13 May 2010 20:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.479 X-Spam-Level: * X-Spam-Status: No, score=1.479 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VRoCKbDl2pq for <oauth@core3.amsl.com>; Thu, 13 May 2010 20:25:33 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 2113A3A6917 for <oauth@ietf.org>; Thu, 13 May 2010 20:25:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,226,1272808800"; d="scan'208";a="3331724" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 14 May 2010 13:25:21 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5981"; a="1982731" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipccni.tcif.telstra.com.au with ESMTP; 14 May 2010 13:25:22 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 14 May 2010 13:25:21 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: OAuth WG <oauth@ietf.org> Date: Fri, 14 May 2010 13:25:20 +1000 Thread-Topic: Separate HTTP and HTTPS tokens Thread-Index: AcrzFRTVNlAGpVjvSXC+t4Oh+wir3w== Message-ID: <255B9BB34FB7D647A506DC292726F6E112634F5377@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OAUTH-WG] Separate HTTP and HTTPS tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 03:25:34 -0000 U29tZSBBUElzIChhbmQgY2VydGFpbmx5IGxvdHMgb2Ygd2ViIHNpdGVzKSB1c2UgYSBtaXggb2Yg SFRUUFMgYW5kIEhUVFAgcmVzb3VyY2VzLiBVc2luZyB0aGUgc2FtZSBiZWFyZXIgdG9rZW4gZm9y IGJvdGggc2V0cyBvZiByZXNvdXJjZXMgbGltaXRzIHNlY3VyaXR5IG9mIHRoZSBIVFRQUyBpbnRl cmFjdGlvbnMgdG8gdGhlIGluc2VjdXJpdHkgb2YgdGhlIEhUVFAgb25lcy4NCkEgYmV0dGVyIGFw cHJvYWNoIGlzIHRvIHVzZSBzZXBhcmF0ZSB0b2tlbnMuIEV4cG9zdXJlIG9mIGEgdG9rZW4gdXNl ZCBvbiBIVFRQIGRvZXMgbm90IGNvbXByb21pc2UgdGhlIGludGVyYWN0aW9ucyBvbiBIVFRQUy4N Cg0KVGhlcmUgaXMgbG90cyBvZiBleGlzdGluZyBwcmFjdGlzZSB3aXRoIHRoaXMgYXBwcm9hY2g6 IGlzc3VpbmcgMiBjb29raWVzIHdoZW4gYSB1c2VyIGxvZ3MgaW46IG9uZSBtYXJrZWQgInNlY3Vy ZSIgYW5kIHRoZSBvdGhlciBub3QuIEhUVFAgYW5kIEhUVFBTIGludGVyYWN0aW9ucyBjYW4gYWxs IGJlIHRpZWQgdG8gdGhlIHNhbWUgdXNlciwgYnV0IHRoZSBIVFRQIG9uZXMgZG9uJ3QgcmVkdWNl IHRoZSBzZWN1cml0eSBvZiB0aGUgSFRUUFMgb25lcy4NCg0KU3VnZ2VzdGVkIHNvbHV0aW9uIGlu IE9BdXRoOiByZXR1cm4gbXVsdGlwbGUgdG9rZW5zIGluIGEgdG9rZW4gcmVzcG9uc2UuDQoNCkNo YW5nZSB0aGUgdG9rZW4gcmVzcG9uc2UgZm9ybWF0IHRvIGFuIGFycmF5IG9mIGJsb2JzIHdpdGgg dG9rZW4gaW5mby4NCg0KWw0KICAgeyAiYWNjZXNzX3Rva2VuIjoiU2xBVjMyaGtLRyIsICJzaXRl cyI6WyJodHRwOi8vYXBpLmV4YW1wbGUub3JnIl0gfSwNCiAgIHsgImFjY2Vzc190b2tlbiI6Iklk ODdkNmREZCIsICJzaXRlcyI6WyJodHRwczovL2FwaS5leGFtcGxlLm9yZyJdIH0NCl0NCg0KRm9y IHRoZSBjb21tb24gY2FzZSBvZiBvbmx5IG5lZWRpbmcgMSB0b2tlbiB0aGUgYWRkZWQgY29tcGxl eGl0eSBpcyB0cml2aWFsOg0KKiBhdCB0aGUgc2VydmVyOiBicmFja2V0IHRoZSBKU09OIHZhbHVl IHdpdGggIlsiIGFuZCAiXSI7DQoqIGF0IHRoZSBjbGllbnQ6IHBpY2sgSlNPTi5wYXJzZShzKVsw XS4NCg0KSXQgZG9lcyBhZGQgc29tZSBjb21wbGV4aXR5IHRvIGdlbmVyaWMgY2xpZW50cywgYW5k IGxpYnJhcmllcy4NCg0KDQpUaGlzIG1lY2hhbmlzbSBhbGxvd3MgdG9rZW5zIHdpdGggYW5kIHdp dGhvdXQgc2VjcmV0cyB0byBiZSBkZWxpdmVyZWQgaW4gb25lIHJlcXVlc3QuDQoNClRoaXMgbWVj aGFuaXNtIGlzIGFsc28gdXNlZnVsIHdoZW4gbGVhc3QtcHJpdmlsZWdlIHRva2VucyBhcmUgd2Fu dGVkLiBGb3IgaW5zdGFuY2UsIG9uZSBhdXRob3JpemF0aW9uIGZsb3cgY2FuIGRlbGl2ZXIgZGlm ZmVyZW50IHRva2VucyB3aXRoIGRpZmZlcmVudCBzY29wZXMvcGVybWlzc2lvbnMgc28gb25seSB0 aGUgbWluaW11bSBhdXRob3JpdHkgaXMgZXhwb3NlZCBpbiBzcGVjaWZpYyBBUEkgY2FsbHMuDQoN ClRoaXMgbWVjaGFuaXNtIG1pZ2h0IGFsc28gYmUgdXNlZnVsIHdoZW4gc3VwcG9ydGluZyBkaWZm ZXJlbnQgYXV0aGVudGljYXRpb24gYWxnb3JpdGhtcyAoZWcgYmVhcmVyIHRva2VuLCBITUFDLVNI QTEsIENNQUMtQUVTMTI4Li4uKS4gVXNpbmcgdGhlIHNhbWUgc2VjcmV0IHdpdGggZHJhc3RpY2Fs bHkgZGlmZmVyZW50IGNyeXB0byBhbGdzIGlzIGdlbmVyYWxseSBiYWQgZm9ybS4gU2VwYXJhdGUg dG9rZW5zIGZvciBlYWNoIG1lY2hhbmlzbSBjYW4gYmUgcmV0dXJuZWQuDQoNClRoaXMgbWVjaGFu aXNtIG1pZ2h0IGJlIGhlbHBmdWwgZm9yIHNlcnZpY2VzIHdpdGggZGlzcGFyYXRlIGNvbGxlY3Rp b25zIG9mIHJlc291cmNlIHNlcnZlcnMuIEEgY29tcHJvbWlzZSBhdCBvbmUgaG9zdCBkb2Vzbid0 IGFmZmVjdCBhbm90aGVyIGlmIGRpZmZlcmVudCB0b2tlbnMgd2VyZSBpc3N1ZWQgZm9yIGVhY2gu DQoNClRoZXJlIGhhdmUgYmVlbiBvdGhlciBzdWdnZXN0aW9ucyBvZiByZXBlYXRlZCBjYWxsIHRv IHRoZSB0b2tlbiBlbmRwb2ludCB0byB1cGdyYWRlL2Rvd25ncmFkZSB0b2tlbnMuIFRoaXMgbWVj aGFuaXNtIGRvZXNuJ3QgcHJlY2x1ZGUgcmVwZWF0ZWQgY2FsbHMsIGJ1dCBpdCBjYW4gYXZvaWQg dGhlbSBpbiBzb21lIGNpcmN1bXN0YW5jZXMuDQoNCkFueSBzdXBwb3J0Pw0KKElmIHlvdSBkb24n dCBsaWtlIGl0LCBpcyBpdCBiZWNhdXNlIHlvdSBkb24ndCB0aGluayB0aGVyZSBhcmUgZW5vdWdo IGNhc2VzIHdoZXJlIEhUVFAgJiBIVFRQUyBhcmUgbWl4ZWQ/IE9yIGlzIGl0IHRoZSBzeW50YXg/ KQ0KDQotLSANCkphbWVzIE1hbmdlcg0KDQo= From lshepard@facebook.com Thu May 13 21:15:20 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABB73A695B for <oauth@core3.amsl.com>; Thu, 13 May 2010 21:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 Dtvy1jTs4ejg for <oauth@core3.amsl.com>; Thu, 13 May 2010 21:15:15 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id F26403A677E for <oauth@ietf.org>; Thu, 13 May 2010 21:15:14 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4E4EheK006683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <oauth@ietf.org>; Thu, 13 May 2010 21:14:45 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub02.TheFacebook.com (192.168.18.105) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 13 May 2010 21:13:16 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Thu, 13 May 2010 21:13:16 -0700 From: Luke Shepard <lshepard@facebook.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 13 May 2010 21:13:15 -0700 Thread-Topic: Details on the Facebook OAuth 2.0 implementation Thread-Index: AcrzG8bsxQGQJLRVRU6kcNRBQbjQXA== Message-ID: <87425D10-E2FE-4DFF-B4B8-55E0B5EEFAEB@facebook.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_87425D10E2FE4DFFB4B855E0B5EEFAEBfacebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-14_01:2010-02-06, 2010-05-13, 2010-05-13 signatures=0 Subject: [OAUTH-WG] Details on the Facebook OAuth 2.0 implementation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 04:15:20 -0000 --_000_87425D10E2FE4DFFB4B855E0B5EEFAEBfacebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey everyone, I wrote up a post giving detail about exactly what Facebook has and has not= implemented from the OAuth 2.0 spec (with plenty of supporting links): http://www.sociallipstick.com/?p=3D239 In summary: - Current as of v0 of the draft. I think we are mostly current with v4 (alt= hough I haven't looked through every one of the diffs) - Support the web_server, user_agent, and client_credentials flows - No support for signatures, immediate mode, client state parameter, or ref= resh tokens, but these all plan to add in the future - Support the proposed display parameter - Error support is not quite consistent and we are working to clean it up - We'd like to see support for a "display" parameter added to the spec (and= will write language for it) Our general attitude is this: we are strong supporters of OAuth 2.0 and we = want to see it become a core piece of internet infrastructure. To that end,= I plan to be active on this list and release periodic upgrades to stay in = sync with the spec. However, since it is far easier to add a feature than to change or remove i= t, we have shipped the most stable core and avoided the controversial or un= finished sections of the spec. When in doubt, we will likely not ship a fea= ture until it seems like it has stabilized. Eran has done a great job drivi= ng many of the open issues to a close. I'm sure I missed a bunch of detail so please let me know if you have any q= uestions! - Luke --_000_87425D10E2FE4DFFB4B855E0B5EEFAEBfacebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; ">Hey everyone,<br><br><div>= I wrote up a post giving detail about exactly what Facebook has and has not= implemented from the OAuth 2.0 spec (with plenty of supporting links):<br>= <br><a href=3D"http://www.sociallipstick.com/?p=3D239">http://www.sociallip= stick.com/?p=3D239</a><br><br>In summary:<br><br>- Current as of v0 of the = draft. I think we are mostly current with v4 (although I haven't looked thr= ough every one of the diffs)<br>- Support the web_server, user_agent, and c= lient_credentials flows<br>- No support for signatures, immediate mode, cli= ent state parameter, or refresh tokens, but these all plan to add in the fu= ture<br>- Support the proposed display parameter<br>- Error support is not = quite consistent and we are working to clean it up<br>- We'd like to see su= pport for a "display" parameter added to the spec (and will write language = for it)</div><div><br>Our general attitude is this: we are strong supporter= s of OAuth 2.0 and we want to see it become a core piece of internet infras= tructure. To that end, I plan to be active on this list and release periodi= c upgrades to stay in sync with the spec.<br><br>However, since it is far e= asier to add a feature than to change or remove it, we have shipped the mos= t stable core and avoided the controversial or unfinished sections of the s= pec. When in doubt, we will likely not ship a feature until it seems like i= t has stabilized. Eran has done a great job driving many of the open issues= to a close.<br><br>I'm sure I missed a bunch of detail so please let me kn= ow if you have any questions!<br>- Luke<br></div><div><br></div></body></ht= ml>= --_000_87425D10E2FE4DFFB4B855E0B5EEFAEBfacebookcom_-- From recordond@gmail.com Thu May 13 21:16:11 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0663A695B for <oauth@core3.amsl.com>; Thu, 13 May 2010 21:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_50=0.001, 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 ygSCnDHKpv27 for <oauth@core3.amsl.com>; Thu, 13 May 2010 21:16:10 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 76CBF3A677E for <oauth@ietf.org>; Thu, 13 May 2010 21:16:10 -0700 (PDT) Received: by gyh4 with SMTP id 4so1107095gyh.31 for <oauth@ietf.org>; Thu, 13 May 2010 21:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=N07zal/25LNAh1LMpzzVZ1iBcjin7i2oHIjoDdIYu7g=; b=cQoGIxz8XwGanP87oWCZbo9MTXbXP6tYHI4vNoo3oQZeuKg592eO4sLHFevmApzI6s TdHRt92F6WDFTsWbC5xR/uHvRbZ7CgLgGVpIVxNo91ZvmNcOAx5vyNfTd9uqj5QdqwDa SEmqpCbAgaiPwEnCdu+75gZ8xWH1hzxVOCbBo= 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=SltylS8ryMRYNDZV8NFn1+O/xgWkelvSFI7/2F+oJKkA5OcaGCNj1XA88VZbAccd1/ W0aHbmX8nLu6PXeooYpypp1OYnZ4Sr6EY6r1feItssL4crNOuzAru9eSEZHkNSuqGqUd lu8HHzZ6Kn186zoDk4lYkdgodWvfUGFBC0hsA= MIME-Version: 1.0 Received: by 10.231.154.19 with SMTP id m19mr89123ibw.98.1273810557836; Thu, 13 May 2010 21:15:57 -0700 (PDT) Received: by 10.231.176.4 with HTTP; Thu, 13 May 2010 21:15:57 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112634F5377@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112634F5377@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 13 May 2010 21:15:57 -0700 Message-ID: <AANLkTil3phNYPp_vkEDwlov3zAU-NHrw72OpnaK26ixo@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=0050450142ffcf9c9104868621b5 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Separate HTTP and HTTPS tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 04:16:11 -0000 --0050450142ffcf9c9104868621b5 Content-Type: text/plain; charset=ISO-8859-1 Why would we support bearer tokens over HTTP? Is someone planning to implement this? On Thu, May 13, 2010 at 8:25 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Some APIs (and certainly lots of web sites) use a mix of HTTPS and HTTP > resources. Using the same bearer token for both sets of resources limits > security of the HTTPS interactions to the insecurity of the HTTP ones. > A better approach is to use separate tokens. Exposure of a token used on > HTTP does not compromise the interactions on HTTPS. > > There is lots of existing practise with this approach: issuing 2 cookies > when a user logs in: one marked "secure" and the other not. HTTP and HTTPS > interactions can all be tied to the same user, but the HTTP ones don't > reduce the security of the HTTPS ones. > > Suggested solution in OAuth: return multiple tokens in a token response. > > Change the token response format to an array of blobs with token info. > > [ > { "access_token":"SlAV32hkKG", "sites":["http://api.example.org"] }, > { "access_token":"Id87d6dDd", "sites":["https://api.example.org"] } > ] > > For the common case of only needing 1 token the added complexity is > trivial: > * at the server: bracket the JSON value with "[" and "]"; > * at the client: pick JSON.parse(s)[0]. > > It does add some complexity to generic clients, and libraries. > > > This mechanism allows tokens with and without secrets to be delivered in > one request. > > This mechanism is also useful when least-privilege tokens are wanted. For > instance, one authorization flow can deliver different tokens with different > scopes/permissions so only the minimum authority is exposed in specific API > calls. > > This mechanism might also be useful when supporting different > authentication algorithms (eg bearer token, HMAC-SHA1, CMAC-AES128...). > Using the same secret with drastically different crypto algs is generally > bad form. Separate tokens for each mechanism can be returned. > > This mechanism might be helpful for services with disparate collections of > resource servers. A compromise at one host doesn't affect another if > different tokens were issued for each. > > There have been other suggestions of repeated call to the token endpoint to > upgrade/downgrade tokens. This mechanism doesn't preclude repeated calls, > but it can avoid them in some circumstances. > > Any support? > (If you don't like it, is it because you don't think there are enough cases > where HTTP & HTTPS are mixed? Or is it the syntax?) > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0050450142ffcf9c9104868621b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why would we support bearer tokens over HTTP? Is someone planning to implem= ent this?<div><br><br><div class=3D"gmail_quote">On Thu, May 13, 2010 at 8:= 25 PM, Manger, James H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Mang= er@team.telstra.com">James.H.Manger@team.telstra.com</a>></span> wrote:<= br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Some APIs (and certainly lots of web sites)= use a mix of HTTPS and HTTP resources. Using the same bearer token for bot= h sets of resources limits security of the HTTPS interactions to the insecu= rity of the HTTP ones.<br> A better approach is to use separate tokens. Exposure of a token used on HT= TP does not compromise the interactions on HTTPS.<br> <br> There is lots of existing practise with this approach: issuing 2 cookies wh= en a user logs in: one marked "secure" and the other not. HTTP an= d HTTPS interactions can all be tied to the same user, but the HTTP ones do= n't reduce the security of the HTTPS ones.<br> <br> Suggested solution in OAuth: return multiple tokens in a token response.<br= > <br> Change the token response format to an array of blobs with token info.<br> <br> [<br> =A0 { "access_token":"SlAV32hkKG", "sites":[= "<a href=3D"http://api.example.org" target=3D"_blank">http://api.examp= le.org</a>"] },<br> =A0 { "access_token":"Id87d6dDd", "sites":[&= quot;<a href=3D"https://api.example.org" target=3D"_blank">https://api.exam= ple.org</a>"] }<br> ]<br> <br> For the common case of only needing 1 token the added complexity is trivial= :<br> * at the server: bracket the JSON value with "[" and "]"= ;;<br> * at the client: pick JSON.parse(s)[0].<br> <br> It does add some complexity to generic clients, and libraries.<br> <br> <br> This mechanism allows tokens with and without secrets to be delivered in on= e request.<br> <br> This mechanism is also useful when least-privilege tokens are wanted. For i= nstance, one authorization flow can deliver different tokens with different= scopes/permissions so only the minimum authority is exposed in specific AP= I calls.<br> <br> This mechanism might also be useful when supporting different authenticatio= n algorithms (eg bearer token, HMAC-SHA1, CMAC-AES128...). Using the same s= ecret with drastically different crypto algs is generally bad form. Separat= e tokens for each mechanism can be returned.<br> <br> This mechanism might be helpful for services with disparate collections of = resource servers. A compromise at one host doesn't affect another if di= fferent tokens were issued for each.<br> <br> There have been other suggestions of repeated call to the token endpoint to= upgrade/downgrade tokens. This mechanism doesn't preclude repeated cal= ls, but it can avoid them in some circumstances.<br> <br> Any support?<br> (If you don't like it, is it because you don't think there are enou= gh cases where HTTP & HTTPS are mixed? Or is it the syntax?)<br> <font color=3D"#888888"><br> --<br> James Manger<br> <br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </font></blockquote></div><br></div> --0050450142ffcf9c9104868621b5-- From James.H.Manger@team.telstra.com Thu May 13 21:38:51 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D6D3A695B for <oauth@core3.amsl.com>; Thu, 13 May 2010 21:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.783 X-Spam-Level: * X-Spam-Status: No, score=1.783 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_56=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYTdgPzREssE for <oauth@core3.amsl.com>; Thu, 13 May 2010 21:38:50 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 9DA0B3A67D3 for <oauth@ietf.org>; Thu, 13 May 2010 21:38:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,226,1272808800"; d="scan'208";a="2590233" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 14 May 2010 14:38:40 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5981"; a="1981958" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcdni.tcif.telstra.com.au with ESMTP; 14 May 2010 14:38:40 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Fri, 14 May 2010 14:38:39 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: David Recordon <recordond@gmail.com> Date: Fri, 14 May 2010 14:38:37 +1000 Thread-Topic: [OAUTH-WG] Separate HTTP and HTTPS tokens Thread-Index: AcrzHCmV3Is9LmyvSuWZfKSBaHyc7QAAPydA Message-ID: <255B9BB34FB7D647A506DC292726F6E112634F5584@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112634F5377@WSMSG3153V.srv.dir.telstra.com> <AANLkTil3phNYPp_vkEDwlov3zAU-NHrw72OpnaK26ixo@mail.gmail.com> In-Reply-To: <AANLkTil3phNYPp_vkEDwlov3zAU-NHrw72OpnaK26ixo@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Separate HTTP and HTTPS tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 04:38:51 -0000 RGF2aWQsDQoNCj4gV2h5IHdvdWxkIHdlIHN1cHBvcnQgYmVhcmVyIHRva2VucyBvdmVyIEhUVFA/ DQo+IElzIHNvbWVvbmUgcGxhbm5pbmcgdG8gaW1wbGVtZW50IHRoaXM/DQoNCkJlY2F1c2UgdGhl IGNvb2tpZXMtb3Zlci1IVFRQIH5lcXVpdmFsZW50IGlzIHdpZGVseSB1c2VkLg0KVGhlIHNwZWMg ZG9lcyBzYXkgU0hPVUxEIE5PVCwgYnV0IGFsc28gZXhwbGljaXRseSB0YWxrcyBhYm91dCBob3cg dG8gZG8gaXQuDQp0aGUgc3BlYyBzdWdnZXN0cyBsaW1pdGVkIHNjb3BlIGFuZCBsaWZldGltZSAt LSBsaW1pdGVkIHNjb3BlIGltcGxpZXMgc2VwYXJhdGUgdG9rZW5zIGZvciBvdGhlciBzY29wZXMg KGVnIGZvciBIVFRQUykuDQoNCltzZWN0aW9uIDUgQWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291 cmNlXQ0KDQogICBBY2Nlc3MgdG9rZW5zIFNIT1VMRCBOT1QgYmUgc2VudCBpbiB0aGUgY2xlYXIg b3ZlciBhbiBpbnNlY3VyZSBjaGFubmVsLg0KDQogICBIb3dldmVyLCB3aGVuIGl0IGlzIG5lY2Vz c2FyeSB0byB0cmFuc21pdCBiZWFyZXIgdG9rZW5zIGluIHRoZSBjbGVhcg0KICAgd2l0aG91dCBh IHNlY3VyZSBjaGFubmVsLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgU0hPVUxEIGlzc3VlIGFjY2Vz cw0KICAgdG9rZW5zIHdpdGggbGltaXRlZCBzY29wZSBhbmQgbGlmZXRpbWUgdG8gcmVkdWNlIHRo ZSBwb3RlbnRpYWwgcmlzaw0KICAgZnJvbSBhIGNvbXByb21pc2VkIGFjY2VzcyB0b2tlbi4gIENs aWVudHMgU0hPVUxEIHJlcXVlc3QgYW5kIHV0aWxpemUNCiAgIGFuIGFjY2VzcyB0b2tlbiB3aXRo IGEgbWF0Y2hpbmcgc2VjcmV0IHdoZW4gbWFraW5nIHByb3RlY3RlZCByZXNvdXJjZQ0KICAgcmVx dWVzdHMgb3ZlciBhbiBpbnNlY3VyZSBjaGFubmVsIChlLmcuIGFuIEhUVFAgcmVxdWVzdCB3aXRo b3V0IHVzaW5nDQogICBUTFMvU1NMKS4NCg0KDQpFdmVuIGlmIHlvdSBvbmx5IHN1cHBvcnQgc2ln bmVkIHJlcXVlc3RzIG92ZXIgSFRUUCB5b3UgcHJvYmFibHkgc3RpbGwgd2FudCAyIHRva2Vuczog YSBiZWFyZXIgdG9rZW4gZm9yIEhUVFBTOyBhIHRva2VuK3NlY3JldCBmb3IgSFRUUC4NCg0KWw0K ICB7ICJhY2Nlc3NfdG9rZW4iOiJJZDg3ZDZkRGQiLCAic2l0ZXMiOlsiaHR0cHM6Ly9hcGkuZXhh bXBsZS5vcmciXSB9LA0KICB7ICJhY2Nlc3NfdG9rZW4iOiJTbEFWMzJoa0tHIiwgInNpdGVzIjpb Imh0dHA6Ly9hcGkuZXhhbXBsZS5vcmciXSwNCiAgICAgICBhY2Nlc3NfdG9rZW5fc2VjcmV0PSIz ODY1ODQ2MzM1MzQiIH0NCl0NCg0K From torsten@lodderstedt.net Thu May 13 22:46:07 2010 Return-Path: <torsten@lodderstedt.net> 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 9052B3A69D6 for <oauth@core3.amsl.com>; Thu, 13 May 2010 22:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.544 X-Spam-Level: X-Spam-Status: No, score=-0.544 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 yyeOh2b9W8a6 for <oauth@core3.amsl.com>; Thu, 13 May 2010 22:46:06 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 041363A6A21 for <oauth@ietf.org>; Thu, 13 May 2010 22:45:50 -0700 (PDT) Received: from tmo-105-57.customers.d1-online.com ([80.187.105.57] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OCniN-0004Ad-Bg; Fri, 14 May 2010 07:45:39 +0200 Message-ID: <4BECE370.4060004@lodderstedt.net> Date: Fri, 14 May 2010 07:45:20 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yaron Goland <yarong@microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A426BAB@TK5EX14MBXC117.redmond.corp.microsoft.com> <4BE8EF51.1070305@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C4A4296A0@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB47465@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFE4@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A42BFE4@TK5EX14MBXC117.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 05:46:07 -0000 from my understanding, the assertion you explained in your scenario represent the authorization of end-users (not client applications) to access feeds. Thus I see them as a kind of user credentials and would send them as request parameter. Authorization headers will be used for client authentication only. regards, Torsten. Am 13.05.2010 22:51, schrieb Yaron Goland: > But in federation scenarios the client credentials are an assertion. > > For example, Microsoft has a service called Dallas that lets entities purchase access to proprietary data feeds. A common scenario we run into with Dallas is that a company will purchase access to a feed for its employees. But the company doesn't want to have to individually specify to Dallas who can and cannot use the feed. Instead they want to agree on a key with Dallas and use that key to sign assertions sent to Dallas saying "let this person in". The OAuth flow would be: > > 1. A Dallas client of an employee of 'the company' issues a request to 'the company's ticket issuer asking for a security token it can send to Dallas. > 2. 'The Company's ticket issuer generates a signed assertion stating that the bearer has the right to use 'The Company's subscription to a particular feed. > 3. The Dallas client then forwards that security token to Dallas's ticket issuer asking for an access token to actually talk to Dallas's front end. > 4. Dallas validates the security token (e.g. checks the signature, makes sure it has the right claims, etc.) and if successful then issues an access token to the Dallas client. > > So in step 3 the client credential was a full-fledged security token of potentially arbitrary size. > > BTW, just to make sure I'm properly following along, we are talking about section 3.9? > > Yaron > > > >> -----Original Message----- >> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] >> Sent: Tuesday, May 11, 2010 4:37 PM >> To: Yaron Goland; Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >> >> No one was suggesting putting the assertion in the header. Just the client >> credentials... >> >> EHL >> >> >>> -----Original Message----- >>> From: Yaron Goland [mailto:yarong@microsoft.com] >>> Sent: Tuesday, May 11, 2010 4:24 PM >>> To: Torsten Lodderstedt >>> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >>> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >>> >>> Actually it's server side that's the problem. Many servers limit the >>> size of the HTTP request headers they will accept. Apache 2.2, for >>> example, uses the LimitRequestFieldSize Directive >>> (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is >>> 8190 bytes. IIS, I Believe, defaults to around 16K. But SAML >>> assertions can easily clock in at 30 or 40k without even trying. >>> >>> So as a practical matter we need a way to allow clients to assert >>> their right to a token using the request body so as to not need to >>> artificially limit the size of the token that is being submitted. >>> >>> Yaron >>> >>> >>>> -----Original Message----- >>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>>> Sent: Monday, May 10, 2010 10:47 PM >>>> To: Yaron Goland >>>> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >>>> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >>>> >>>> Am 11.05.2010 01:43, schrieb Yaron Goland: >>>> >>>>> >>>>>> --- >>>>>> >>>>>> 2. Client Authentication (in flows) >>>>>> >>>>>> How should the client authenticate when making token requests? >>>>>> The current draft defines special request parameters for sending >>>>>> client credentials. Some have argued that this is not the correct >>>>>> way, and that the client should be using existing HTTP >>>>>> authentication schemes to accomplish that such as Basic. >>>>>> >>>>>> A. Client authenticates by sending its credentials using special >>>>>> parameters (current draft) B. Client authenticated by using HTTP >>>>>> Basic (or other schemes supported by the server such as Digest) >>>>>> >>>>>> >>>>>> >>>>> [Yaron Goland] A is needed at a minimum because there are physical >>>>> >>>> limitations to how many bytes can go into an authorization header. >>>> >>>>> >>>> As far as I know, 4KB is the minimum size for headers that must be >>>> supported by user agents, which should suffice from my point of view. >>>> Moreover, other HTTP authentication mechanisms need much more than >>>> 4KB, For example, SPNEGO authentication headers can be up to 12392 >>>> >>> bytes. >>> >>>> regards, >>>> Torsten. >>>> >>>> >>>>>> _______________________________________________ >>>>>> 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 May 14 08:45:50 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE74C3A69D2 for <oauth@core3.amsl.com>; Fri, 14 May 2010 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.408 X-Spam-Level: X-Spam-Status: No, score=-100.408 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 EjjpK6DfAyzN for <oauth@core3.amsl.com>; Fri, 14 May 2010 08:45:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9BA133A68DF for <oauth@ietf.org>; Fri, 14 May 2010 08:45:49 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o4EFjZUA017397 for <oauth@ietf.org>; Fri, 14 May 2010 08:45:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273851936; bh=lzEO9RZkzajBmDbmwMOM+c+Dvhk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=w9xOHcu68vdP+vC18LChSYnXUAJZYbYdHKAgM0/rvq/VFEQ8E+a9mMfdPgxudeka2 /run375V2ZT6DwbFT9vdQ== 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=WeyuCdCytV/HqzN9Mwh+HleK7ngft3aZeGE8iBHIm594jFgeN4JUnfOQEg+Ks7X7y yJAUfPZu/rrJeqEbbwzgQ== Received: from pvg4 (pvg4.prod.google.com [10.241.210.132]) by kpbe14.cbf.corp.google.com with ESMTP id o4EFjXFW009685 for <oauth@ietf.org>; Fri, 14 May 2010 08:45:34 -0700 Received: by pvg4 with SMTP id 4so174813pvg.10 for <oauth@ietf.org>; Fri, 14 May 2010 08:45:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.210.21 with SMTP id i21mr888326wfg.16.1273851930491; Fri, 14 May 2010 08:45:30 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Fri, 14 May 2010 08:45:30 -0700 (PDT) In-Reply-To: <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <g2xfd6741651005071106if93ba794q7e9739669eb22fc2@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> Date: Fri, 14 May 2010 08:45:30 -0700 Message-ID: <AANLkTinPiCBvtnTW_m3bSUhB_OOK4ZD6JFjquECDMCi6@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 15:45:51 -0000 On Thu, May 13, 2010 at 9:00 AM, Evan Gilbert <uidude@google.com> wrote: >> Consider a generic search spider tool that you point at >> http://calendar.serviceprovider.com/calendar/get. It can do its job with no >> knowledge about what "calendar.get" means -- but it still needs to know (as >> it spiders along) when it is safe to expose the token. > > How does the generic search spider know to call to > http://calendar.serviceprovider.com/calendar/get in the first place? I'm a bit confused by this example. James, can you explain what you mean by "generic search spider tool"? From James.H.Manger@team.telstra.com Fri May 14 17:57:13 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8C23A6900 for <oauth@core3.amsl.com>; Fri, 14 May 2010 17:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.492 X-Spam-Level: * X-Spam-Status: No, score=1.492 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuPFr2BWYw6O for <oauth@core3.amsl.com>; Fri, 14 May 2010 17:57:12 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 96C3B3A68F6 for <oauth@ietf.org>; Fri, 14 May 2010 17:57:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,234,1272808800"; d="scan'208";a="2695958" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 15 May 2010 10:57:01 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5982"; a="1953823" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 15 May 2010 10:57:01 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Sat, 15 May 2010 10:57:01 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Brian Eaton <beaton@google.com> Date: Sat, 15 May 2010 10:56:59 +1000 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: AcrzfILQmFvu/NxMRtano6QubI26+gASKnzg Message-ID: <255B9BB34FB7D647A506DC292726F6E112634F5A93@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <g2xfd6741651005071106if93ba794q7e9739669eb22fc2@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <D24C564ACEAD16459EF2526E1D7D605D0C8D22ED62@IMCMBX3.MITRE.ORG> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> <AANLkTinPiCBvtnTW_m3bSUhB_OOK4ZD6JFjquECDMCi6@mail.gmail.com> In-Reply-To: <AANLkTinPiCBvtnTW_m3bSUhB_OOK4ZD6JFjquECDMCi6@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 15 May 2010 00:57:13 -0000 QnJpYW4sDQoNCj4+IENvbnNpZGVyIGEgZ2VuZXJpYyBzZWFyY2ggc3BpZGVyIHRvb2wgdGhhdCB5 b3UgcG9pbnQgYXQNCj4+IGh0dHA6Ly9jYWxlbmRhci5zZXJ2aWNlcHJvdmlkZXIuY29tL2NhbGVu ZGFyL2dldC4gSXQgY2FuIGRvIGl0cyBqb2Igd2l0aCBubw0KPj4ga25vd2xlZGdlIGFib3V0IHdo YXQgImNhbGVuZGFyLmdldCIgbWVhbnMgLS0gYnV0IGl0IHN0aWxsIG5lZWRzIHRvIGtub3cgKGFz DQo+PiBpdCBzcGlkZXJzIGFsb25nKSB3aGVuIGl0IGlzIHNhZmUgdG8gZXhwb3NlIHRoZSB0b2tl bi4NCg0KPiBJJ20gYSBiaXQgY29uZnVzZWQgYnkgdGhpcyBleGFtcGxlLg0KPg0KPiBKYW1lcywg Y2FuIHlvdSBleHBsYWluIHdoYXQgeW91IG1lYW4gYnkgImdlbmVyaWMgc2VhcmNoIHNwaWRlciB0 b29sIj8NCg0KQSB0b29sIHRoYXQgYnVpbGRzIGEgc2VhcmNoIGluZGV4Lg0KWW91IHBvaW50IGl0 IGEgVVJJOyBpdCBmZXRjaGVzIHRoZSBjb250ZW50OyBpbmRleGVzIGl0OyBmb2xsb3dzIGFueSBs aW5rcyBpbiB0aGUgY29udGVudCB0byBtb3JlIGNvbnRlbnQ7IGluZGV4ZXMgdGhhdDsgYW5kIGNv bnRpbnVlcy4NClRoZSB0b29sIHVuZGVyc3RhbmRzIEhUVFA7IGl0IGtub3dzIGhvdyB0byBmaW5k IGxpbmtzIGluIGNvbW1vbiBtZWRpYSB0eXBlcyAoPGEgaHJlZj0uLi4+LCA8bGluayAuLi4+LCBl dGMpOyBidXQgaXQgZG9lc24ndCBoYXZlIG11Y2ggQVBJLXNwZWNpZmljIGtub3dsZWRnZSAoaXQg ZG9lc24ndCBrbm93IG9yIGNhcmUgaWYgaXQgaXMgaW5kZXhpbmcgYSBjYWxlbmRhciwgYSBwZXJz b25hbCBibG9nLCBhIHNvY2lhbCBncmFwaCwgYSBkb2MgcmVwb3NpdG9yeSwgYWxsIG9mIHRoZSBh Ym92ZSBldGMpLg0KDQpJZiBzb21lIG9mIHRoZSBjb250ZW50IHJlcXVpcmVzIHVzZXIgY29uc2Vu dCB0byBhY2Nlc3MgKGllIHJldHVybnMgV1dXLUF1dGguOiBUb2tlbiB1c2VyLXVyaT0iLi4uIiks IHRoZSB0b29sIHBlcmZvcm1zIGFuIE9BdXRoIGZsb3cgYW5kIGNvbnRpbnVlcy4NCg0KVGhlIHRv b2wgbmVlZHMgc29tZSBydWxlIHNvIGl0IGRvZXNuJ3QgdHJ5IHRvIGluZGV4IHRoZSB3aG9sZSBJ bnRlcm5ldC4gRm9yIGV4YW1wbGU6IGluZGV4IGF0IG1vc3QgNTAwIHBhZ2VzOyBkb3dubG9hZCBu byBtb3JlIHRoYW4gMTBNQjsgZmluaXNoIGluIDUgbWluOyBvbmx5IGZvbGxvd2luZyBsaW5rcyB0 byBhIGRlcHRoIG9mIDM7IHN0YXkgd2l0aGluIGV4YW1wbGUuY29tLiBUaGlzIHJ1bGUgZG9lcyBu b3QgbmVjZXNzYXJpbHkgaGF2ZSBhbnl0aGluZyB0byBkbyB3aXRoIGFueSBzZWN1cml0eSBib3Vu ZGFyaWVzLg0KDQoNClRoZSBjcnVjaWFsIGZlYXR1cmVzIG9mIHRoZSB0b29sIGFyZSB0aGF0IGl0 IGtub3dzIGVub3VnaCBhYm91dCBIVFRQIGFuZCBkYXRhIGZvcm1hdHMgdG8gZm9sbG93IHJlZGly ZWN0cyAmIGxpbmtzOyBidXQgaXQgZG9lc24ndCBoYXZlIHNlcnZpY2Utc3BlY2lmaWMga25vd2xl ZGdlIHRvIGtub3cgdW5kZXJzdGFuZCBzZXJ2aWNlLXNwZWNpZmljIHNjb3BlcyAoZWcgImNhbGVu ZGFyLmdldCIpIG9yIHRoZSBib3VuZGFyaWVzIG9mIHNwZWNpZmljIEFQSXMuDQoNClRoZXJlIGFy ZSBsb3RzIG9mIHRvb2xzIGluIHRoaXMgY2F0ZWdvcnkuIEl0IG1hdGNoZXMgdGhlIGFyY2hpdGVj dHVyZSBvZiB0aGUgd2ViLg0KDQpPdGhlciBleGFtcGxlcyBvZiBzdWNoIHRvb2xzIG1pZ2h0IGJl Og0KKiBhIGJhY2t1cCB0b29sIC0tIHBvaW50IGl0IGF0IHlvdXIgYXRvbSBmZWVkcyBhbmQgaXQg Y29waWVzIHRoZSBjb250ZW50IChhbmQgdGhlIGxpbmtlZCBzdHlsZXNoZWV0cywgc2NyaXB0cywg aW1hZ2VzLi4uKQ0KKiBwZXJoYXBzIGNVUkwgLS0gZG8gYW55dGhpbmcgb24gdGhlIHdlYg0KKiBh IHdlYiBicm93c2VyDQoNCkkgaG9wZSB0aGlzIGNsZWFycyBzb21lIGNvbmZ1c2lvbi4NCg0KLS0N CkphbWVzIE1hbmdlcg0K From trac@tools.ietf.org Fri May 14 18:40:40 2010 Return-Path: <trac@tools.ietf.org> 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 EDC093A67FC for <oauth@core3.amsl.com>; Fri, 14 May 2010 18:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.071 X-Spam-Level: X-Spam-Status: No, score=-101.071 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_50=0.001, NO_RELAYS=-0.001, 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 4UF6Medm0EP5 for <oauth@core3.amsl.com>; Fri, 14 May 2010 18:40:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 553623A6802 for <oauth@ietf.org>; Fri, 14 May 2010 18:40:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from <trac@tools.ietf.org>) id 1OD6Md-0000ZP-Ex; Fri, 14 May 2010 18:40:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: james@manger.com.au X-Trac-Project: oauth Date: Sat, 15 May 2010 01:40:27 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/5 Message-ID: <059.db44ca9c6a99be8265550c67a11484c4@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: james@manger.com.au, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #5: Separate scheme names for bearer tokens, request signing, and delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 15 May 2010 01:40:41 -0000 #5: Separate scheme names for bearer tokens, request signing, and delegation ---------------------------------+------------------------------------------ Reporter: james@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: 2.0 Severity: - | Keywords: ---------------------------------+------------------------------------------ The same HTTP authentication scheme name "Token" is overloaded with 3 (or 4) distinct roles. This hinders the use of auth schemes names by client apps to choose how to authenticate to a server. It doesn't match existing usage of auth scheme names. A server should be able to indicate that a resource can be accessed: 1. When the request is signed (MACed) with a shared secret key; 2. When user consent has been obtained (at a given user-uri); 3. When a client credential has been swapped for a token (at a given token-uri); 4. When the request is accompanied by an authorization token. These indications should be independent. Because "Token" is overloaded, a "WWW-Authenticate: Token ..." HTTP header can only indicate all of these together. Suggested solution: use at least 3 different names in the various places "Token" is currently used -- perhaps "MAC", "Delegate" (or "OAuth"), and "Token". -- Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/5> oauth <http://tools.ietf.org/oauth/> From James.H.Manger@team.telstra.com Sun May 16 07:09:32 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF403A68DB for <oauth@core3.amsl.com>; Sun, 16 May 2010 07:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.496 X-Spam-Level: * X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEuZqFKoQYBy for <oauth@core3.amsl.com>; Sun, 16 May 2010 07:09:31 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 7CC163A6874 for <oauth@ietf.org>; Sun, 16 May 2010 07:09:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,242,1272808800"; d="scan'208";a="3029091" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 17 May 2010 00:09:16 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5983"; a="1976335" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccvi.tcif.telstra.com.au with ESMTP; 17 May 2010 00:09:17 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 17 May 2010 00:09:16 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Mon, 17 May 2010 00:09:09 +1000 Thread-Topic: Spec text for "sites" field Thread-Index: AcrwTaPsC4ggYQawSQ6EnsB9Iie0cQEknBPA Message-ID: <255B9BB34FB7D647A506DC292726F6E112634F5B35@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {97EB2563-F3C6-409C-A2C0-FEA234294AC8} x-cr-hashedpuzzle: FAw= ce4= oyc= uBk= AoZZ AxnK Cfyb DgCB EDNy EpCz Evc0 Frpm GeSr HX5k JwA+ LNik; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {97EB2563-F3C6-409C-A2C0-FEA234294AC8}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Sun, 16 May 2010 14:09:09 GMT; UwBwAGUAYwAgAHQAZQB4AHQAIABmAG8AcgAgACIAcwBpAHQAZQBzACIAIABmAGkAZQBsAGQA acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OAUTH-WG] Spec text for "sites" field X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 14:09:32 -0000 QmVsb3cgaXMgdGV4dCBhYm91dCB0aGUgInNpdGVzIiBmaWVsZCBpbiBzcGVjLXJlYWR5IGRldGFp bCB0byBtYWtlIGl0IGVhc2llciBmb3IgdGhlIGVkaXRvci4NClRoZXJlIGhhc24ndCBiZWVuIHVu YW5pbW91cyBzdXBwb3J0IGZvciB0aGlzIGZpZWxkIGFtb25nc3QgdGhlIGxvbmcgZGlzY3Vzc2lv bnMuIEhvd2V2ZXIsIG15IGZlZWxpbmcgaXMgdGhhdCBtb3N0IGhhdmUgcmVjb2duaXNlZCB0aGF0 IGl0IGlzIG5lZWRlZC4NCg0KDQpbZm9yIDMuMy4yLjEuIEFjY2VzcyBUb2tlbiBSZXNwb25zZV0N Cg0KW2FkZCB0byB0aGUgbGlzdCBvZiBjb21tb24gcGFyYW1ldGVyc10NCg0KwqAgc2l0ZXMNCsKg wqDCoCBPUFRJT05BTC4gSW5kaWNhdGVzIHRoZSBzaXRlcyB3aGVyZSB0aGUgdG9rZW4gY2FuIGJl IHVzZWQuDQoNCg0KW2FkZCBiZWxvdyB0aGUgbGlzdCBvZiBjb21tb24gcGFyYW1ldGVyc10NCg0K VGhlICJzaXRlcyIgZmllbGQgaW5kaWNhdGVzIHdoZXJlIHRoZSBpc3N1ZWQgdG9rZW4gY2FuIGJl IHVzZWQuIEl0cyB2YWx1ZSBpcyBhbiBhcnJheSBvZiBzdHJpbmdzLCB3aGVyZSBlYWNoIHN0cmlu ZyBvYmV5cyB0aGUgPHNpdGU+IHByb2R1Y3Rpb24uIElmIHRoZSAic2l0ZXMiIGZpZWxkIGlzIGFi c2VudCBpdCBNVVNUIGJlIHRyZWF0ZWQgYXMgdGhvdWdoIHRoZSBmaWVsZCB3YXMgcHJlc2VudCB3 aXRoIGEgc2luZ2xlIHN0cmluZyBjb25zaXN0aW5nIG9mIHRoZSBzY2hlbWUsIGhvc3QsIGFuZCBw b3J0IG9mIHRoZSBzaXRlIHRoYXQgaXNzdWVkIHRoZSB0b2tlbi4NCsKgDQrCoCBzaXRlICAgICA9 IHNjaGVtZSAiOi8vIiBbd2lsZGNhcmRdIGhvc3QgWyI6IiBwb3J0XQ0KICAgIDsgc2NoZW1lLCBo b3N0LCBhbmQgcG9ydCBhcmUgZGVmaW5lZCBpbiBbUkZDMzk4Nl0NCsKgIHdpbGRjYXJkID0gIiou Ig0KDQpUaGUgdG9rZW4gTVVTVCBOT1QgYmUgdXNlZCB3aXRoIGEgcmVxdWVzdCB0byBhIFVSSSB1 bmxlc3MgdGhlIFVSSSBtYXRjaGVzIGF0IGxlYXN0IG9uZSBzdHJpbmcgaW4gdGhlIOKAnHNpdGVz 4oCdIHZhbHVlLiBBIHRva2VuIFNIT1VMRCBiZSB1c2VkIHByZS1lbXB0aXZlbHkgd2hlbiB0aGUg VVJJIGRvZXMgbWF0Y2guIEFueSBzdHJpbmcgaW4gdGhlICJzaXRlcyIgdmFsdWUgdGhhdCBkb2Vz IG5vdCBvYmV5IHRoZSA8c2l0ZT4gcHJvZHVjdGlvbiBNVVNUIGJlIGlnbm9yZWQuIEEgVVJJIG1h dGNoZXMgYSBzdHJpbmcgaWYgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIGFyZSBhbGwgbWV0Og0K MS4gVGhlIHNjaGVtZSBvZiB0aGUgVVJJIGFuZCBzdHJpbmcgYXJlIGVxdWFsLCBpZ25vcmluZyBj YXNlLg0KMi4gVGhlIHBvcnQgbnVtYmVyIG9mIHRoZSBVUkkgYW5kIHN0cmluZyBhcmUgbnVtZXJp Y2FsbHkgZXF1YWwsIHVzaW5nIHRoZSBkZWZhdWx0IHBvcnQgbnVtYmVyIGZvciBhIHNjaGVtZSBp ZiBubyBwb3J0IGlzIHNwZWNpZmllZCAoZWcgNDQzIGZvciBodHRwcykuDQozLiBUaGUgd2lsZGNh cmQgaXMgYWJzZW50IGFuZCB0aGUgaG9zdCBvZiB0aGUgVVJJIGFuZCBzdHJpbmcgYXJlIGVxdWFs LCBpZ25vcmluZyBjYXNlOyBvciB0aGUgd2lsZGNhcmQgaXMgcHJlc2VudCBhbmQgYSAiLiIgZm9s bG93ZWQgYnkgdGhlIGhvc3Qgb2YgdGhlIHN0cmluZyBpcyBhIHN1ZmZpeCBvZiB0aGUgaG9zdCBv ZiB0aGUgVVJJLCBpZ25vcmluZyBjYXNlLg0KDQpUaGUgZm9sbG93aW5nIFVSSXMgbWF0Y2ggdGhl IGV4YW1wbGUgYmVsb3cgKHNvIHRoZSB0b2tlbiBzaG91bGQgYmUgdXNlZCk6DQrCoCBodHRwczov L2FwaS5leGFtcGxlLmNvbTo0NDMveHl6P3E9MQ0KwqAgSFRUUFM6Ly9XV1cuSU1HLkRBVEEuRVhB TVBMRS5DT00vNzg2ODU2LmpwZw0KDQpUaGUgZm9sbG93aW5nIFVSSXMgZG8gTk9UIG1hdGNoIHRo ZSBleGFtcGxlIGJlbG93IChzbyB0aGUgdG9rZW4gbXVzdCBub3QgYmUgdXNlZCk6DQrCoCBodHRw Oi8vYXBpLmV4YW1wbGUuY29tL2luZGV4Lmh0bWzCoCAod3Jvbmcgc2NoZW1lKQ0KwqAgaHR0cHM6 Ly9kYXRhLmV4YW1wbGUuY29tLzQyNTQuanNvbsKgIChob3N0IG5vdCBhIHN1Yi1kb21haW4pDQoN Cg0KW2FkZCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gdGhlIGV4YW1wbGUgSFRUUCByZXNwb25zZV0N Cg0KICAic2l0ZXMiOiBbImh0dHBzOi8vYXBpLmV4YW1wbGUuY29tIiwgImh0dHBzOi8vKi5kYXRh LmV4YW1wbGUuY29tIl0sDQoNCg0KW21heSBuZWVkIHRvIHJlZmVyZW5jZSB0aGUgQUJORiBSRkMg KGluc3RlYWQgb2YgaHR0cGJpcyBmb3IgQUJORj8pXQ0KDQogICBbUkZDNTIzNF0gICJBdWdtZW50 ZWQgQk5GIGZvciBTeW50YXggU3BlY2lmaWNhdGlvbnM6IEFCTkYiDQoNCltlbmQgb2Ygc3BlYyB0 ZXh0XQ0KDQoNClBvdGVudGlhbCBpc3N1ZXM6DQoqIEludGVybmF0aW9uYWxpemVkIGRvbWFpbiBu YW1lczogdGhlIHRleHQgYWJvdmUgaW1wbGllcyB0b0FTQ0lJIGRvbWFpbiBuYW1lcyBhcHBlYXIg aW4gInNpdGVzIiAoYnkgdXNpbmcgPGhvc3Q+IGZyb20gUkZDMzk4NiBVUkksIG5vdCA8aWhvc3Q+ IGZyb20gUkZDMzk4NyBJUkkpDQoqIDx3aWxkY2FyZD4gZG9lc24ndCBtYWtlIG11Y2ggc2Vuc2Ug aWYgPGhvc3Q+IGlzIGFuIElQIGFkZHJlc3NlcywgYnV0IGlzbid0IGhhcm1mdWwNCiogZHJhZnQt YWJhcnRoLW9yaWdpbiBvZmZlcnMgbW9yZSByaWdvcm91cyBydWxlcyBmb3Igc2NoZW1lL2hvc3Qv cG9ydCBvcmlnaW5zDQoqIGlnbm9yaW5nIHN0cmluZ3MgdGhhdCBkb24ndCBtYXRjaCA8c2l0ZT4g cHJvdmlkZXMgc29tZSByb29tIGZvciBleHRlbnNpYmlsaXR5LCB3aGlsZSBiZWluZyBmYWlsLXNh ZmUgZm9yIGVhcmxpZXIgY2xpZW50IGFwcHMNCg0KLS0gDQpKYW1lcyBNYW5nZXINCg0K From trac@tools.ietf.org Sun May 16 10:00:11 2010 Return-Path: <trac@tools.ietf.org> 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 4380A3A6A67 for <oauth@core3.amsl.com>; Sun, 16 May 2010 10:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.07 X-Spam-Level: X-Spam-Status: No, score=-101.07 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_50=0.001, NO_RELAYS=-0.001, 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 JzXfkIsdH4Be for <oauth@core3.amsl.com>; Sun, 16 May 2010 10:00:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 440BD3A6A5E for <oauth@ietf.org>; Sun, 16 May 2010 10:00:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from <trac@tools.ietf.org>) id 1ODhC5-0002m1-MH; Sun, 16 May 2010 10:00:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: eve@xmlgrrl.com X-Trac-Project: oauth Date: Sun, 16 May 2010 17:00:01 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/6 Message-ID: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eve@xmlgrrl.com, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #6: Make automated self-registration of unique clients possible X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 17:00:11 -0000 #6: Make automated self-registration of unique clients possible -----------------------------+---------------------------------------------- Reporter: eve@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Keywords: -----------------------------+---------------------------------------------- There are some cases where subsequent correlation of initially anonymous clients is desirable (just as there are some cases where humans can self- choose a username and password at a website). It would be helpful to have a standard, interoperable "pre-flow" that precedes normal token-getting flows for issuing a unique client_id and client_secret to walk-up clients. The alternative is documenting, or letting the client discover, statically allocated credentials that don't distinguish it from other clients. For at least the uses to which UMA is putting OAuth, and possibly for others as well, it would be useful to have enough context to distinguish clients uniquely outside of the context of the access token it is ultimately given. -- Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/6> oauth <http://tools.ietf.org/oauth/> From dick.hardt@gmail.com Sun May 16 10:34:29 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD6B3A6AC4 for <oauth@core3.amsl.com>; Sun, 16 May 2010 10:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 GD0SZICiRKyl for <oauth@core3.amsl.com>; Sun, 16 May 2010 10:34:28 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id C5F773A6ABA for <oauth@ietf.org>; Sun, 16 May 2010 10:34:27 -0700 (PDT) Received: by pzk38 with SMTP id 38so59905pzk.31 for <oauth@ietf.org>; Sun, 16 May 2010 10:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=eFjF5qMrOD2/ZiQjqNMZhpdzDE0meqf6L0hl/svvhLQ=; b=gzT65MdOCNqb8yTAXItMvip8KfVbP0jqopz8CQgOUE3PK63qTOqrQGl7hwOhQo1etM u+WZLZcaX4zajO2aI7GvuYEBNvcgtfeJtz7M3P6nw5bF6wCrMUS3we7t1w6juUaOoHQ8 wJFIOcX5MzlltWTxgscL8mCLdOeeM4s5sZrwE= 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=ZqmhsEetlKoZaaxgT15ngc8hRhPG0JRI1741fJDiox1kSHheOt9xaiBN/vsdWGVCDq 1KLJezrobSulSNVEbFs2ATNCChdyrQGoWjslQd/gnqtHuM8LknLmhe2QOn1g0SpMlsBM zdU4zPuwfIDmu11cYcohFbh760ibgD99mMcQo= MIME-Version: 1.0 Received: by 10.142.250.23 with SMTP id x23mr2780087wfh.214.1274031257213; Sun, 16 May 2010 10:34:17 -0700 (PDT) Received: by 10.142.87.17 with HTTP; Sun, 16 May 2010 10:34:17 -0700 (PDT) In-Reply-To: <AANLkTimbJ8pIVgDLBqag7FjVVrJr0magID52u6T9LUc3@mail.gmail.com> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTikbUvqQLCvOAsY9d2CDdg9222xX9zwIEWmNA4RW@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinSQpI4JX6_TVL4ZAI0oYSehKB9vEfQyZafggtM@mail.gmail.com> <AANLkTiktDsVRfYoY2ArgM0VSLkNhMv5oadcX1pHq6j_Q@mail.gmail.com> <AANLkTimbJ8pIVgDLBqag7FjVVrJr0magID52u6T9LUc3@mail.gmail.com> Date: Sun, 16 May 2010 10:34:17 -0700 Message-ID: <AANLkTilD6-wxXtwwDyR6E7I271qy2mbIEh7W_e0YRACT@mail.gmail.com> From: Dick Hardt <dick.hardt@gmail.com> To: John Panzer <jpanzer@google.com> Content-Type: multipart/alternative; boundary=001636ed683384dc820486b98415 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] modifying the scope of an access token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 17:34:29 -0000 --001636ed683384dc820486b98415 Content-Type: text/plain; charset=ISO-8859-1 John / David: is this a feature you would want to implement? If no one wants it, we can drop it. On Mon, May 10, 2010 at 11:52 PM, John Panzer <jpanzer@google.com> wrote: > (Note that in my use case, it's actually the client who wants to dispose of > its dangerous full-access token as quickly as possible, retaining only the > least-authority token it needs to continue its ongoing work. This would be > the case even if the token granting service is handing out tokens like free > candy.) > > On Mon, May 10, 2010 at 10:43 PM, David Recordon <recordond@gmail.com>wrote: > >> I'm wondering if this could be achieved by adding an optional scope >> parameter to the existing refresh request versus creating a new >> request type. Both because Dick's proposed text requires a refresh >> token and it seems like services worried about this sort of risk would >> not want to issue long lived access tokens. >> >> --David >> >> >> On Mon, May 10, 2010 at 10:39 PM, John Panzer <jpanzer@google.com> wrote: >> > Yes; a service that does a one time configuration step, requiring >> > extensive access, followed by an ongoing lower level of access (say, >> > read-only). Lowering access means it only needs to store low-risk >> > tokens in its data store, limiting exposure (and liability). >> > >> > On Monday, May 10, 2010, Eran Hammer-Lahav <eran@hueniverse.com> wrote: >> >> Are there actual use cases for this? Either way sounds like it belongs >> in an extension. >> >> >> >> EHL >> >> >> >>> -----Original Message----- >> >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> >>> Sent: Monday, May 10, 2010 12:49 PM >> >>> To: Eran Hammer-Lahav >> >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) >> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token >> >>> >> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav >> >>> <eran@hueniverse.com> wrote: >> >>> > This would only work for the client credentials flow (because you >> keep the >> >>> same authorization source). For all other flows you are breaking the >> >>> authorization boundaries. >> >>> >> >>> If the requested scope is a subset of the original scope associated >> with the >> >>> refresh token then it should be acceptable, right? >> >>> >> >>> This would allow a client to request a larger set of scopes, needed >> for all API >> >>> calls need for its function, but then get sub-scoped access tokens, >> particular >> >>> to each API. This will prevent an API from receiving a too powerful >> access >> >>> token. A compromised API could use access tokens to place calls >> against >> >>> other APIs, but not if it is narrowly scoped. >> >>> >> >>> Marius >> >>> >> >>> > >> >>> > What would be useful is to allow asking for more scope. For example, >> when >> >>> asking for a token (the last step of each flow), also include a valid >> token to >> >>> get a new token with the combined scope (new approval and previous). >> >>> > >> >>> > EHL >> >>> > >> >>> >> -----Original Message----- >> >>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >>> >> Behalf Of Dick Hardt >> >>> >> Sent: Sunday, May 09, 2010 7:19 PM >> >>> >> To: OAuth WG (oauth@ietf.org) >> >>> >> Subject: [OAUTH-WG] modifying the scope of an access token >> >>> >> >> >>> >> There has been some discussion about modifying the scope of the >> >>> >> access token during a refresh. Perhaps we can add another "method" >> to >> >>> >> what the AS MAY support that allows modifying the scope of an >> access >> >>> >> token. Type of request is "modify" and the scope parameter is >> >>> >> required to indicate the new scope required. Suggested copy below: >> >>> >> >> >>> >> type >> >>> >> REQUIRED. The parameter value MUST be set to modify >> >>> >> >> >>> >> client_id >> >>> >> REQUIRED. The client identifier as described in Section 3.4. >> >>> >> >> >>> >> client_secret >> >>> >> REQUIRED if the client was issued a secret. The client >> secret. >> >>> >> >> >>> >> refresh_token >> >>> >> REQUIRED. The refresh token associated with the access token >> to >> >>> >> be refreshed. >> >>> >> >> >>> >> scope >> >>> >> REQUIRED. The new scope of the access request expressed as a >> >>> >> list of space-delimited strings. The value of the scope parameter >> is >> >>> >> defined by the authorization server. If the value contains multiple >> >>> >> space-delimited strings, their order does not matter, and each >> string >> >>> >> adds additional access range to the requested scope. >> >>> >> >> >>> >> secret_type >> >>> >> OPTIONAL. The access token secret type as described by >> Section 8.3. >> >>> >> If omitted, the authorization server will issue a bearer token (an >> >>> >> access token without a matching secret) as described by Section >> 8.2. >> >>> >> >> >>> >> _______________________________________________ >> >>> >> 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 >> >>> > >> >> _______________ >> > >> > -- >> > -- >> > John Panzer / Google >> > jpanzer@google.com / abstractioneer.org / @jpanzer >> > _______________________________________________ >> > 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 > > --001636ed683384dc820486b98415 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John / David: is this a feature you would want to implement? If no one want= s it, we can drop it.<div><br><br><div class=3D"gmail_quote">On Mon, May 10= , 2010 at 11:52 PM, John Panzer <span dir=3D"ltr"><<a href=3D"mailto:jpa= nzer@google.com">jpanzer@google.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">(Note that in my use case, it's actuall= y the client who wants to dispose of its dangerous full-access token as qui= ckly as possible, retaining only the least-authority token it needs to cont= inue its ongoing work. =A0This would be the case even if the token granting= service is handing out tokens like free candy.)<div> <div></div><div class=3D"h5"><div> <br><div class=3D"gmail_quote">On Mon, May 10, 2010 at 10:43 PM, David Reco= rdon <span dir=3D"ltr"><<a href=3D"mailto:recordond@gmail.com" target=3D= "_blank">recordond@gmail.com</a>></span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> I'm wondering if this could be achieved by adding an optional scope<br> parameter to the existing refresh request versus creating a new<br> request type. Both because Dick's proposed text requires a refresh<br> token and it seems like services worried about this sort of risk would<br> not want to issue long lived access tokens.<br> <font color=3D"#888888"><br> --David<br> </font><div><div></div><div><br> <br> On Mon, May 10, 2010 at 10:39 PM, John Panzer <<a href=3D"mailto:jpanzer= @google.com" target=3D"_blank">jpanzer@google.com</a>> wrote:<br> > Yes; a service that does a one time configuration step, requiring<br> > extensive access, followed by an ongoing lower level of access (say,<b= r> > read-only). =A0Lowering access means it only needs to store low-risk<b= r> > tokens in its data store, limiting exposure (and liability).<br> ><br> > On Monday, May 10, 2010, Eran Hammer-Lahav <<a href=3D"mailto:eran@= hueniverse.com" target=3D"_blank">eran@hueniverse.com</a>> wrote:<br> >> Are there actual use cases for this? Either way sounds like it bel= ongs in an extension.<br> >><br> >> EHL<br> >><br> >>> -----Original Message-----<br> >>> From: Marius Scurtescu [mailto:<a href=3D"mailto:mscurtescu@go= ogle.com" target=3D"_blank">mscurtescu@google.com</a>]<br> >>> Sent: Monday, May 10, 2010 12:49 PM<br> >>> To: Eran Hammer-Lahav<br> >>> Cc: Dick Hardt; OAuth WG (<a href=3D"mailto:oauth@ietf.org" ta= rget=3D"_blank">oauth@ietf.org</a>)<br> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token= <br> >>><br> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav<br> >>> <<a href=3D"mailto:eran@hueniverse.com" target=3D"_blank">e= ran@hueniverse.com</a>> wrote:<br> >>> > This would only work for the client credentials flow (bec= ause you keep the<br> >>> same authorization source). For all other flows you are breaki= ng the<br> >>> authorization boundaries.<br> >>><br> >>> If the requested scope is a subset of the original scope assoc= iated with the<br> >>> refresh token then it should be acceptable, right?<br> >>><br> >>> This would allow a client to request a larger set of scopes, n= eeded for all API<br> >>> calls need for its function, but then get sub-scoped access to= kens, particular<br> >>> to each API. This will prevent an API from receiving a too pow= erful access<br> >>> token. A compromised API could use access tokens to place call= s against<br> >>> other APIs, but not if it is narrowly scoped.<br> >>><br> >>> Marius<br> >>><br> >>> ><br> >>> > What would be useful is to allow asking for more scope. F= or example, when<br> >>> asking for a token (the last step of each flow), also include = a valid token to<br> >>> get a new token with the combined scope (new approval and prev= ious).<br> >>> ><br> >>> > EHL<br> >>> ><br> >>> >> -----Original Message-----<br> >>> >> From: <a href=3D"mailto:oauth-bounces@ietf.org" targe= t=3D"_blank">oauth-bounces@ietf.org</a> [mailto:<a href=3D"mailto:oauth-bou= nces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a>] On<br> >>> >> Behalf Of Dick Hardt<br> >>> >> Sent: Sunday, May 09, 2010 7:19 PM<br> >>> >> To: OAuth WG (<a href=3D"mailto:oauth@ietf.org" targe= t=3D"_blank">oauth@ietf.org</a>)<br> >>> >> Subject: [OAUTH-WG] modifying the scope of an access = token<br> >>> >><br> >>> >> There has been some discussion about modifying the sc= ope of the<br> >>> >> access token during a refresh. Perhaps we can add ano= ther "method" to<br> >>> >> what the AS MAY support that allows modifying the sco= pe of an access<br> >>> >> token. Type of request is "modify" and the = scope parameter is<br> >>> >> required to indicate the new scope required. Suggeste= d copy below:<br> >>> >><br> >>> >> type<br> >>> >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set= to modify<br> >>> >><br> >>> >> client_id<br> >>> >> =A0 =A0 =A0 REQUIRED. The client identifier as descri= bed in Section 3.4.<br> >>> >><br> >>> >> client_secret<br> >>> >> =A0 =A0 =A0 REQUIRED if the client was issued a secre= t. The client secret.<br> >>> >><br> >>> >> refresh_token<br> >>> >> =A0 =A0 =A0 REQUIRED. The refresh token associated wi= th the access token to<br> >>> >> be refreshed.<br> >>> >><br> >>> >> scope<br> >>> >> =A0 =A0 =A0 REQUIRED. The new scope of the access req= uest expressed as a<br> >>> >> list of space-delimited strings. The value of the sco= pe parameter is<br> >>> >> defined by the authorization server. If the value con= tains multiple<br> >>> >> space-delimited strings, their order does not matter,= and each string<br> >>> >> adds additional access range to the requested scope.<= br> >>> >><br> >>> >> secret_type<br> >>> >> =A0 =A0 =A0 OPTIONAL. The access token secret type as= described by Section 8.3.<br> >>> >> If omitted, the authorization server will issue a bea= rer token (an<br> >>> >> access token without a matching secret) as described = by Section 8.2.<br> >>> >><br> >>> >> _______________________________________________<br> >>> >> OAuth mailing list<br> >>> >> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">O= Auth@ietf.org</a><br> >>> >> <a href=3D"https://www.ietf.org/mailman/listinfo/oaut= h" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> > _______________________________________________<br> >>> > OAuth mailing list<br> >>> > <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth= @ietf.org</a><br> >>> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> ><br> >> _______________<br> ><br> > --<br> > --<br> > John Panzer / Google<br> > <a href=3D"mailto:jpanzer@google.com" target=3D"_blank">jpanzer@google= .com</a> / <a href=3D"http://abstractioneer.org" target=3D"_blank">abstract= ioneer.org</a> / @jpanzer<br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a>= <br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/oauth</a><br> ><br> </div></div></blockquote></div><br></div> </div></div><br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --001636ed683384dc820486b98415-- From dick.hardt@gmail.com Sun May 16 10:35:48 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7009C3A6AD2 for <oauth@core3.amsl.com>; Sun, 16 May 2010 10:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 zV72IH5JZWpe for <oauth@core3.amsl.com>; Sun, 16 May 2010 10:35:47 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B2EA63A6ABA for <oauth@ietf.org>; Sun, 16 May 2010 10:35:45 -0700 (PDT) Received: by pwi1 with SMTP id 1so2426892pwi.31 for <oauth@ietf.org>; Sun, 16 May 2010 10:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1xKCw/OEW1gT9vzvujpFj/1uyTGo5p5BRtXdOKsBSLo=; b=h2O2FSOXQ/X7T5p0EP+qmC9qVWznnypGwonKH2FCSuT3Qd5NpsbzcCTqXzXu8/oJMv pDPToy7vhEq+kppzpxo2ROUgqfQZCdmp8eqL9M7osX+4U2YhsW+msZmH5eKu1bVFMCjb vrBeVAda6/rTtwBKz+pcyB6D639i9S4QZyEbk= 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=DDoZX4irAFskyIbOHnRxckxRP/zSLJ4ddHdbjE+ZnyesUdaBvkO+qgMWSYc2L6YJgX KuzBr/Cu8FXsFZLb6ltAHI8Mgec4NtaADjqxvCl5tcC18Rn79ucXDLaqSBvMH5m6RccN tmfMMi4vtNihM8GPqb+x7T31dlFzzbF9aiA0s= MIME-Version: 1.0 Received: by 10.142.248.38 with SMTP id v38mr2484712wfh.246.1274031334697; Sun, 16 May 2010 10:35:34 -0700 (PDT) Received: by 10.142.87.17 with HTTP; Sun, 16 May 2010 10:35:34 -0700 (PDT) In-Reply-To: <AANLkTiktDsVRfYoY2ArgM0VSLkNhMv5oadcX1pHq6j_Q@mail.gmail.com> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTikbUvqQLCvOAsY9d2CDdg9222xX9zwIEWmNA4RW@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinSQpI4JX6_TVL4ZAI0oYSehKB9vEfQyZafggtM@mail.gmail.com> <AANLkTiktDsVRfYoY2ArgM0VSLkNhMv5oadcX1pHq6j_Q@mail.gmail.com> Date: Sun, 16 May 2010 10:35:34 -0700 Message-ID: <AANLkTimqEfj29xTX0A8f7XulTjpPwoQgRI8yX1Gzgpns@mail.gmail.com> From: Dick Hardt <dick.hardt@gmail.com> To: David Recordon <recordond@gmail.com> Content-Type: multipart/alternative; boundary=00504502ce54232c390486b989d1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] modifying the scope of an access token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 17:35:48 -0000 --00504502ce54232c390486b989d1 Content-Type: text/plain; charset=ISO-8859-1 My design preference would be to have a new request type. A AS could then support or not support the feature, and it keeps refresh as refresh rather than overloading it. On Mon, May 10, 2010 at 10:43 PM, David Recordon <recordond@gmail.com>wrote: > I'm wondering if this could be achieved by adding an optional scope > parameter to the existing refresh request versus creating a new > request type. Both because Dick's proposed text requires a refresh > token and it seems like services worried about this sort of risk would > not want to issue long lived access tokens. > > --David > > > On Mon, May 10, 2010 at 10:39 PM, John Panzer <jpanzer@google.com> wrote: > > Yes; a service that does a one time configuration step, requiring > > extensive access, followed by an ongoing lower level of access (say, > > read-only). Lowering access means it only needs to store low-risk > > tokens in its data store, limiting exposure (and liability). > > > > On Monday, May 10, 2010, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > >> Are there actual use cases for this? Either way sounds like it belongs > in an extension. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>> Sent: Monday, May 10, 2010 12:49 PM > >>> To: Eran Hammer-Lahav > >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token > >>> > >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav > >>> <eran@hueniverse.com> wrote: > >>> > This would only work for the client credentials flow (because you > keep the > >>> same authorization source). For all other flows you are breaking the > >>> authorization boundaries. > >>> > >>> If the requested scope is a subset of the original scope associated > with the > >>> refresh token then it should be acceptable, right? > >>> > >>> This would allow a client to request a larger set of scopes, needed for > all API > >>> calls need for its function, but then get sub-scoped access tokens, > particular > >>> to each API. This will prevent an API from receiving a too powerful > access > >>> token. A compromised API could use access tokens to place calls against > >>> other APIs, but not if it is narrowly scoped. > >>> > >>> Marius > >>> > >>> > > >>> > What would be useful is to allow asking for more scope. For example, > when > >>> asking for a token (the last step of each flow), also include a valid > token to > >>> get a new token with the combined scope (new approval and previous). > >>> > > >>> > EHL > >>> > > >>> >> -----Original Message----- > >>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>> >> Behalf Of Dick Hardt > >>> >> Sent: Sunday, May 09, 2010 7:19 PM > >>> >> To: OAuth WG (oauth@ietf.org) > >>> >> Subject: [OAUTH-WG] modifying the scope of an access token > >>> >> > >>> >> There has been some discussion about modifying the scope of the > >>> >> access token during a refresh. Perhaps we can add another "method" > to > >>> >> what the AS MAY support that allows modifying the scope of an access > >>> >> token. Type of request is "modify" and the scope parameter is > >>> >> required to indicate the new scope required. Suggested copy below: > >>> >> > >>> >> type > >>> >> REQUIRED. The parameter value MUST be set to modify > >>> >> > >>> >> client_id > >>> >> REQUIRED. The client identifier as described in Section 3.4. > >>> >> > >>> >> client_secret > >>> >> REQUIRED if the client was issued a secret. The client secret. > >>> >> > >>> >> refresh_token > >>> >> REQUIRED. The refresh token associated with the access token > to > >>> >> be refreshed. > >>> >> > >>> >> scope > >>> >> REQUIRED. The new scope of the access request expressed as a > >>> >> list of space-delimited strings. The value of the scope parameter is > >>> >> defined by the authorization server. If the value contains multiple > >>> >> space-delimited strings, their order does not matter, and each > string > >>> >> adds additional access range to the requested scope. > >>> >> > >>> >> secret_type > >>> >> OPTIONAL. The access token secret type as described by Section > 8.3. > >>> >> If omitted, the authorization server will issue a bearer token (an > >>> >> access token without a matching secret) as described by Section 8.2. > >>> >> > >>> >> _______________________________________________ > >>> >> 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 > >>> > > >> _______________ > > > > -- > > -- > > John Panzer / Google > > jpanzer@google.com / abstractioneer.org / @jpanzer > > _______________________________________________ > > 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 > --00504502ce54232c390486b989d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My design preference would be to have a new request type. A AS could then s= upport or not support the feature, and it keeps refresh as refresh rather t= han overloading it.<br><br><div class=3D"gmail_quote">On Mon, May 10, 2010 = at 10:43 PM, David Recordon <span dir=3D"ltr"><<a href=3D"mailto:recordo= nd@gmail.com">recordond@gmail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">I'm wondering if this could be achieved= by adding an optional scope<br> parameter to the existing refresh request versus creating a new<br> request type. Both because Dick's proposed text requires a refresh<br> token and it seems like services worried about this sort of risk would<br> not want to issue long lived access tokens.<br> <font color=3D"#888888"><br> --David<br> </font><div><div></div><div class=3D"h5"><br> <br> On Mon, May 10, 2010 at 10:39 PM, John Panzer <<a href=3D"mailto:jpanzer= @google.com">jpanzer@google.com</a>> wrote:<br> > Yes; a service that does a one time configuration step, requiring<br> > extensive access, followed by an ongoing lower level of access (say,<b= r> > read-only). =A0Lowering access means it only needs to store low-risk<b= r> > tokens in its data store, limiting exposure (and liability).<br> ><br> > On Monday, May 10, 2010, Eran Hammer-Lahav <<a href=3D"mailto:eran@= hueniverse.com">eran@hueniverse.com</a>> wrote:<br> >> Are there actual use cases for this? Either way sounds like it bel= ongs in an extension.<br> >><br> >> EHL<br> >><br> >>> -----Original Message-----<br> >>> From: Marius Scurtescu [mailto:<a href=3D"mailto:mscurtescu@go= ogle.com">mscurtescu@google.com</a>]<br> >>> Sent: Monday, May 10, 2010 12:49 PM<br> >>> To: Eran Hammer-Lahav<br> >>> Cc: Dick Hardt; OAuth WG (<a href=3D"mailto:oauth@ietf.org">oa= uth@ietf.org</a>)<br> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token= <br> >>><br> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav<br> >>> <<a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com= </a>> wrote:<br> >>> > This would only work for the client credentials flow (bec= ause you keep the<br> >>> same authorization source). For all other flows you are breaki= ng the<br> >>> authorization boundaries.<br> >>><br> >>> If the requested scope is a subset of the original scope assoc= iated with the<br> >>> refresh token then it should be acceptable, right?<br> >>><br> >>> This would allow a client to request a larger set of scopes, n= eeded for all API<br> >>> calls need for its function, but then get sub-scoped access to= kens, particular<br> >>> to each API. This will prevent an API from receiving a too pow= erful access<br> >>> token. A compromised API could use access tokens to place call= s against<br> >>> other APIs, but not if it is narrowly scoped.<br> >>><br> >>> Marius<br> >>><br> >>> ><br> >>> > What would be useful is to allow asking for more scope. F= or example, when<br> >>> asking for a token (the last step of each flow), also include = a valid token to<br> >>> get a new token with the combined scope (new approval and prev= ious).<br> >>> ><br> >>> > EHL<br> >>> ><br> >>> >> -----Original Message-----<br> >>> >> From: <a href=3D"mailto:oauth-bounces@ietf.org">oauth= -bounces@ietf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org">oau= th-bounces@ietf.org</a>] On<br> >>> >> Behalf Of Dick Hardt<br> >>> >> Sent: Sunday, May 09, 2010 7:19 PM<br> >>> >> To: OAuth WG (<a href=3D"mailto:oauth@ietf.org">oauth= @ietf.org</a>)<br> >>> >> Subject: [OAUTH-WG] modifying the scope of an access = token<br> >>> >><br> >>> >> There has been some discussion about modifying the sc= ope of the<br> >>> >> access token during a refresh. Perhaps we can add ano= ther "method" to<br> >>> >> what the AS MAY support that allows modifying the sco= pe of an access<br> >>> >> token. Type of request is "modify" and the = scope parameter is<br> >>> >> required to indicate the new scope required. Suggeste= d copy below:<br> >>> >><br> >>> >> type<br> >>> >> =A0 =A0 =A0 REQUIRED. The parameter value MUST be set= to modify<br> >>> >><br> >>> >> client_id<br> >>> >> =A0 =A0 =A0 REQUIRED. The client identifier as descri= bed in Section 3.4.<br> >>> >><br> >>> >> client_secret<br> >>> >> =A0 =A0 =A0 REQUIRED if the client was issued a secre= t. The client secret.<br> >>> >><br> >>> >> refresh_token<br> >>> >> =A0 =A0 =A0 REQUIRED. The refresh token associated wi= th the access token to<br> >>> >> be refreshed.<br> >>> >><br> >>> >> scope<br> >>> >> =A0 =A0 =A0 REQUIRED. The new scope of the access req= uest expressed as a<br> >>> >> list of space-delimited strings. The value of the sco= pe parameter is<br> >>> >> defined by the authorization server. If the value con= tains multiple<br> >>> >> space-delimited strings, their order does not matter,= and each string<br> >>> >> adds additional access range to the requested scope.<= br> >>> >><br> >>> >> secret_type<br> >>> >> =A0 =A0 =A0 OPTIONAL. The access token secret type as= described by Section 8.3.<br> >>> >> If omitted, the authorization server will issue a bea= rer token (an<br> >>> >> access token without a matching secret) as described = by Section 8.2.<br> >>> >><br> >>> >> _______________________________________________<br> >>> >> OAuth mailing list<br> >>> >> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><= br> >>> >> <a href=3D"https://www.ietf.org/mailman/listinfo/oaut= h" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> > _______________________________________________<br> >>> > OAuth mailing list<br> >>> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> >>> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> ><br> >> _______________<br> ><br> > --<br> > --<br> > John Panzer / Google<br> > <a href=3D"mailto:jpanzer@google.com">jpanzer@google.com</a> / <a href= =3D"http://abstractioneer.org" target=3D"_blank">abstractioneer.org</a> / @= jpanzer<br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/oauth</a><br> ><br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br> --00504502ce54232c390486b989d1-- From dick.hardt@gmail.com Sun May 16 11:20:54 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE89B3A6BA5 for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 i7R1u+VrRX-x for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:20:50 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id E73013A6B9C for <oauth@ietf.org>; Sun, 16 May 2010 11:20:40 -0700 (PDT) Received: by pvg11 with SMTP id 11so1403663pvg.31 for <oauth@ietf.org>; Sun, 16 May 2010 11:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pSXG5WArcqjcMQLveb614wNd+UrVnUxbd4D6a7qTpDU=; b=QSunmab7URi8eA9PEHhAB0BFNFKLDKa9+77HtGSDwB+xZYWHUz0g8/Yc+ct/uBEMOA 3fRB8b2oxARtSxaDmgOE+UHgFcSRqYKhqlckQD0ZfC/im79vZFflVHBpFfVG4a1o+bUq EicFDfggJ7GdQMyuk1lfrcr8q/Kq3kIRk+Gcs= 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=D2KrIoARCs0joGbT9wBSlfb8QxSPhFaxLzdv84m6Pismi03PZy7yewb7sZ+gg0b1/A vjs3TSt9wxxCd98WjwUYVbmNvBmj0PGK1um42MfZgMSnJ5gtUmq6rqkYfpdj37DTmd6v 9YSL/MdKwB0hte2gEmYnzptvOBbSjs/zHmzII= MIME-Version: 1.0 Received: by 10.142.74.19 with SMTP id w19mr2660290wfa.20.1274034029689; Sun, 16 May 2010 11:20:29 -0700 (PDT) Received: by 10.142.87.17 with HTTP; Sun, 16 May 2010 11:20:29 -0700 (PDT) In-Reply-To: <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimfTF05EWxOdyJrUU3K3IN7kJ7RdDk3mBXN2f41@mail.gmail.com> <AANLkTilCID4z-NjAJLMQ2GHcWHm-21fWKPzXs-6y4tyZ@mail.gmail.com> <AANLkTil8-AEe0Jjid2aKuI4IADCZ_vamNng5USnMKz8E@mail.gmail.com> <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com> Date: Sun, 16 May 2010 11:20:29 -0700 Message-ID: <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com> From: Dick Hardt <dick.hardt@gmail.com> To: Luke Shepard <lshepard@facebook.com>, Allen Tom <atom@yahoo-inc.com>, Brian Eaton <beaton@google.com> Content-Type: multipart/alternative; boundary=001636d34bfec57b490486ba29c4 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 18:20:55 -0000 --001636d34bfec57b490486ba29c4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 11, 2010 at 11:31 PM, Luke Shepard <lshepard@facebook.com>wrote: > FWIW, Facebook does not do strict equality matching on redirect_uri. We > accept any redirect_uri that has either: > > - its prefix is the registered url > - or it is a special facebook.com/xd_proxy.php url, with an origin > parameter that has a prefix on the registered url > > I think that the spec should leave the matching up to the server. If the matching is left to an arbitrary, server defined algorithm, we lose interop since a client implementation may make assumptions on what may be allowed in the redirect_uri at one AS and then not be able to work with another AS that is more restrictive. As this is a security feature, I'd like to hear the options from the security oriented participants with experience here. Allen / Brian? --001636d34bfec57b490486ba29c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, May 11, 2010 at 11:31 PM, Luke S= hepard <span dir=3D"ltr"><<a href=3D"mailto:lshepard@facebook.com">lshep= ard@facebook.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> FWIW, Facebook does not do strict equality matching on redirect_uri. We acc= ept any redirect_uri that has either:<br> <br> - its prefix is the registered url<br> - or it is a special <a href=3D"http://facebook.com/xd_proxy.php" target=3D= "_blank">facebook.com/xd_proxy.php</a> url, with an origin parameter that h= as a prefix on the registered url<br> <br> I think that the spec should leave the matching up to the server.</blockquo= te><div><br></div><div>If the matching is left to an arbitrary, server defi= ned algorithm, we lose interop since a client implementation may make assum= ptions on what may be allowed in the redirect_uri at one AS and then not be= able to work with another AS that is more=A0restrictive. =A0</div> <div><br></div><div>As this is a security feature, I'd like to hear the= options from the security oriented participants with experience here.=A0</= div><div><br></div><div>Allen / Brian?</div></div> --001636d34bfec57b490486ba29c4-- From dick.hardt@gmail.com Sun May 16 11:28:07 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C5F3A6877 for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.348 X-Spam-Level: X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] 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 2I-IDXTzoSax for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:28:06 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id A8C383A68C6 for <oauth@ietf.org>; Sun, 16 May 2010 11:28:04 -0700 (PDT) Received: by pvg11 with SMTP id 11so1405206pvg.31 for <oauth@ietf.org>; Sun, 16 May 2010 11:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dVByximo1A6nsvPhaF9D9UjVF4UHvzlkU8ihwrxpztU=; b=j4oramRxcdck/vjmmngQHPehE71tOqDpc/zR+CYGq3MNLASIcolGLVDcGxImpdH6IF PvgvWOxyJlm6+pC0RFBDl9K6bGNXdm3ovU8a7SDaVencH59R4MowpChB6KTcmaxYn0ce YwZM4+IfpjO4ud+0wMsPUSCPmeVjc3jb0iz08= 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=XHEYQVyKk/YLzTJZxNYyvXdmZwAQIuIZTknK/KX4Vjm2RPvjFl44XGSizt21TRzMcm yjiHxvBYoKxAA4YFPMebjmATlSieNRZjqCMP4Pb0KeXUcf7ji8obBlDGjKDaa60lRovi CgF3GI7zFn9f77E5AjKsfztt0FTEJtrPibfNc= MIME-Version: 1.0 Received: by 10.142.67.35 with SMTP id p35mr2836861wfa.203.1274034470768; Sun, 16 May 2010 11:27:50 -0700 (PDT) Received: by 10.142.87.17 with HTTP; Sun, 16 May 2010 11:27:50 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 16 May 2010 11:27:50 -0700 Message-ID: <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com> From: Dick Hardt <dick.hardt@gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=001636e0a8f20fcf0b0486ba4462 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 18:28:07 -0000 --001636e0a8f20fcf0b0486ba4462 Content-Type: text/plain; charset=ISO-8859-1 James: An important capability of the refresh token is that it *can* be a self contained token in that is not an id, but a signed token that can be examined and acted upon on presentation. Torsten: enabling a client to revoke a refresh token looks like a useful mechanism. I anticipate it will be viewed as a vitamin feature rather than a painkiller and will fall by the wayside unless the security conscience rally to have it included. -- Dick On Thu, May 13, 2010 at 7:10 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Torsten, > > > What about refresh token revocation/deletion? > > HTTP already has a method to do this: DELETE > It just needs each token to have a URI. > > Tokens (almost) already have URIs -- its just not immediately obvious > because the URI has to be built from a common token endpoint and a > refresh_token. > > I think it would improve the spec if refresh_token was renamed to, say, > token_id; and its value defined as a URI (which can be a relative URI so the > string may not need to change at all). > > To refresh a token you POST to the token's URI. > To delete a token you send a DELETE request to the token's URI. > > It doesn't cause major changes, but there are some benefits. > It is a more web-style design. > It leaves only 1 type of token in the spec -- an access token -- which > simplifies the text and aids understanding. > There are no arguments about length, allowed chars etc because it is a URI > -- a well-known type, often with native support. > Its obvious how to delete the token as there is a standard HTTP method > DELETE to apply to the token URI. > > If a particular service supported an additional way to delete items in its > API (eg POST with a method=delete query parameter) that could apply to the > OAuth part as well. > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636e0a8f20fcf0b0486ba4462 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James: An important capability of the refresh token is that it *can* be a s= elf contained token in that is not an id, but a signed token that can be ex= amined and acted upon on presentation.<div><br></div><div>Torsten: enabling= a client to revoke a refresh token looks like a useful mechanism. I antici= pate it will be viewed as a vitamin feature rather than a painkiller and wi= ll fall by the wayside unless the security conscience rally to have it incl= uded.</div> <div><br></div><div>-- Dick<br><div><br><br><div class=3D"gmail_quote">On T= hu, May 13, 2010 at 7:10 AM, Manger, James H <span dir=3D"ltr"><<a href= =3D"mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com= </a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Torsten,<br> <div class=3D"im"><br> > What about refresh token revocation/deletion?<br> <br> </div>HTTP already has a method to do this: DELETE<br> It just needs each token to have a URI.<br> <br> Tokens (almost) already have URIs -- its just not immediately obvious becau= se the URI has to be built from a common token endpoint and a refresh_token= .<br> <br> I think it would improve the spec if refresh_token was renamed to, say, tok= en_id; and its value defined as a URI (which can be a relative URI so the s= tring may not need to change at all).<br> <br> To refresh a token you POST to the token's URI.<br> To delete a token you send a DELETE request to the token's URI.<br> <br> It doesn't cause major changes, but there are some benefits.<br> It is a more web-style design.<br> It leaves only 1 type of token in the spec -- an access token -- which simp= lifies the text and aids understanding.<br> There are no arguments about length, allowed chars etc because it is a URI = -- a well-known type, often with native support.<br> Its obvious how to delete the token as there is a standard HTTP method DELE= TE to apply to the token URI.<br> <br> If a particular service supported an additional way to delete items in its = API (eg POST with a method=3Ddelete query parameter) that could apply to th= e OAuth part as well.<br> <br> --<br> <font color=3D"#888888">James Manger<br> </font><div><div></div><div class=3D"h5">__________________________________= _____________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br></div></div> --001636e0a8f20fcf0b0486ba4462-- From dick.hardt@gmail.com Sun May 16 11:38:42 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1543A6B9C for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[AWL=-1.640, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] 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 vdXV-7rMc6Cw for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:38:39 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 2D40E3A6B06 for <oauth@ietf.org>; Sun, 16 May 2010 11:38:39 -0700 (PDT) Received: by pzk38 with SMTP id 38so75600pzk.31 for <oauth@ietf.org>; Sun, 16 May 2010 11:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qcPcbKbR2gVa0aTRWENunHcoF7FLHRK/H+A9jbY7+Fw=; b=pZZwmCHdPrJ5yHYOEUJdqbYyKNIX86hEo6CYA1jEvpxv57Sqhh9FTW8XjNu6o/hnWs oE3E8ZX5mYuBGpe3AobtJRxG7xbGKZ8HekBtl3BX2XBi5Ald6FwJMvGK79OhADTYV+ZZ B6CJE80VeZ+YK3n8kDM80Rt0Dt+Dn4tOt/O1Q= 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=XYbWp3V+ijYY7huIjXmzoWTivL1CrXb5mrILs19GJO+rEk0SFRKsAXgy1M7Y3ZqgyF u5zfXs7UvwPLNE2jZSUgeyZffP1khAewenVptZF4eLXNh8rDsjoU6lTdvh8AdY+7TAly aabKiSqAjiQDKfkzhIzT3wP46l++loHkv+KQE= MIME-Version: 1.0 Received: by 10.142.6.35 with SMTP id 35mr2768939wff.79.1274035106918; Sun, 16 May 2010 11:38:26 -0700 (PDT) Received: by 10.142.87.17 with HTTP; Sun, 16 May 2010 11:38:26 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTik0dKSLLVQDhodhFsO--bR43PvZKborWG1uK15t@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 16 May 2010 11:38:26 -0700 Message-ID: <AANLkTilsw-oR2gMi-FFZwXotl1xQaDKvszpvQLWcQO-V@mail.gmail.com> From: Dick Hardt <dick.hardt@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary=00504502b659fab16c0486ba699f Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 18:38:42 -0000 --00504502b659fab16c0486ba699f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not sure if you intended this, but you are mixing user present and user not present access control. I do NOT think we want OAuth protected images to be the same as Basic auth protected images. I do think OpenID protected images and Basic auth are similar. With OAuth today, the user has granted explicit permission at a particular resource, not any resource the user may have access to. -- Dick On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <eran@hueniverse.com>wro= te: > Today when I cut/paste a URI of an image using Basic auth, the browser > knows exactly what to do. I want to do the same with an OAuth-protected > image. Saying that there aren=92t standards API out there to benefit from= this > is incorrect. There are plenty. > > > > This is complete discovery for the authentication layer. The rest doesn= =92t > belong here, the same way this doesn=92t belong as part of the API > specification. > > > > EHL > > > > *From:* Evan Gilbert [mailto:uidude@google.com] > *Sent:* Thursday, May 13, 2010 9:16 AM > *To:* Eran Hammer-Lahav > *Cc:* Manger, James H; OAuth WG > > *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid > > > > > > On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <eran@hueniverse.com> > wrote: > > You are trying to match a mechanism designed for automatic discovery with= a > system designed to require paperwork. It sounds like for your use cases, = you > will not be using this optional parameter and just document how to use yo= ur > API (i.e. hardcode your security setup and API format). > > > > I'm saying it should be a fully automatic discovery or use paperwork. > Having an API return valid URL prefixes to send the token to without havi= ng > an API to determine the actual URLs you send tokens to seems odd. > > > > The whole point of this is that the developer isn=92t involved. The libra= ry > takes care of everything. All the developer does is ask to get a protecte= d > resource. The library will check if it already has a valid token for that > resource (based on the security restrictions provided by the sites > parameter, and the scope requirements =96 two very separate things). > > > > This is an incomplete mechanism for automatic discovery. How does the > developer find out where to ask for the protected resource in the first > place? > > > > So yes =96 if your developers have plenty of stuff to hardcode already, t= his > adds little value. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Evan Gilbert > *Sent:* Thursday, May 13, 2010 9:00 AM > > > *To:* Manger, James H > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Indicating sites where a token is valid > > > > > > On Wed, May 12, 2010 at 11:52 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > > Evan, > > > > The key point is that this discovery covers a lot of the same grounds a= s > the sites parameter, and it's hard to define semantics around a sites > parameter without understanding the semantics of scopes and API endpoints= . > > I strongly disagree. The semantics are crystal clear: > "Here is a token. It is INSECURE to send it anywhere not in this list." > These semantics are useful regardless of what the API does, how the clien= t > is using it, or how much (or how little) the client knows about the API. > > > > To expand - it's hard to define *useful* semantics around a sites paramet= er > without understanding the semantics of scopes and API endpoints. Yes, you > can define crystal clear semantics, but these are not useful unless they > work well with the way developers figure out the endpoints to call APIs. > > > > > > > Clients need to [know] more about these links (at least the response > format). > > That knowledge comes from other standards (HTML, Atom, wiki of rel > values...) and is totally independent of whether a token should or should > not be sent. > > > > In our use cases, clients almost always need to know more about the API: > > - How to call directly - we have no API endpoints that are only arrived a= t > by links > > - Response format of the data > > > > > > > The mechanism they use to find out about these links - documentation, > discovery, data returned with token request - could also provide the > information about whether a token should be sent to a particular API. > > Could, but shouldn't and doesn't in practise. > It is much much better to have the information about how to use a token > securely delivered at the same time & place as receiving that token, and > with minimal assumptions about how much the client apps knows about the > service. > > > > So why wouldn't we return a list of specific API endpoints instead of a > "sites" parameter? > > > > Developers are going to call the APIs endpoints that they know about. If > there is a conflict between this and the sites parameter, what should the= y > do? For example, if facebook returns a sites parameter " > https://unknown.facebook.com/", do we think the developer is going to not > try to use the access token on https://graph.facebook.com/<https://graph.= facebook.com/*> > ? > > > > Separating the concept of sites from API endpoints feels like a bad idea. > Discovery / docs will give you a list of URLs where you should send token= s. > The "sites" parameter will give you a list of URLs where you can send > tokens. This is redundant, and will lead to developers / libraries not > respecting the sites parameter. If developers / libraries don't respect i= t, > then the service can't rely on it for enforcing security. > > > > Another note: Where do we anticipate clients storing the sites parameter = in > the User-Agent flow? Right now the access token can be set as an HTTP coo= kie > by the client. Do we expect them to set a separate "sites" cookie and > respect this on their server when making requests? This seems complicated= . > > > > > > > I should be more concrete about the use cases I see. Let's assume there= 's > an API where there are two endpoints, each with an associated permission > > - contacts.list permission -> > http://contacts.serviceprovider.com/contacts/list > > - calendar.get permission -> > http://calendar.serviceprovider.com/calendar/get > > > > If the response to an authorization request includes the authorized > scopes (contacts.list, calendar.get), then the "sites" parameter is > redundant. > > I'll admit that "sites" is redundant if a client has *perfect* knowledge > about a service, but so is pretty much any standard at that point. > > Consider a generic search spider tool that you point at > http://calendar.serviceprovider.com/calendar/get. It can do its job with > no knowledge about what "calendar.get" means -- but it still needs to kno= w > (as it spiders along) when it is safe to expose the token. > > > > How does the generic search spider know to call to > http://calendar.serviceprovider.com/calendar/get in the first place? > > > > > > -- > James Manger > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00504502b659fab16c0486ba699f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not sure if you intended this, but you are mixing user present and user not= present access control.<div><br>I do NOT think we want OAuth protected ima= ges to be the same as Basic auth protected images. I do think OpenID protec= ted images and Basic auth are similar. With OAuth today, the user has grant= ed explicit permission at a particular resource, not any resource the user = may have access to.</div> <div><br></div><div>-- Dick</div><div><br><div class=3D"gmail_quote">On Thu= , May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <span dir=3D"ltr"><<a href= =3D"mailto:eran@hueniverse.com">eran@hueniverse.com</a>></span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex;"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNorm= al"><span style=3D"font-size:11.0pt;color:#1F497D">Today when I cut/paste a= URI of an image using Basic auth, the browser knows exactly what to do. I = want to do the same with an OAuth-protected image. Saying that there aren= =92t standards API out there to benefit from this is incorrect. There are p= lenty.</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F49= 7D">This is complete discovery for the authentication layer. The rest doesn= =92t belong here, the same way this doesn=92t belong as part of the API spe= cification.</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F49= 7D">EHL</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;co= lor:#1F497D">=A0</span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;paddin= g:3.0pt 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.= 0pt">From:</span></b><span style=3D"font-size:10.0pt"> Evan Gilbert [mailto= :<a href=3D"mailto:uidude@google.com" target=3D"_blank">uidude@google.com</= a>] <br> <b>Sent:</b> Thursday, May 13, 2010 9:16 AM<br><b>To:</b> Eran Hammer-Lahav= <br><b>Cc:</b> Manger, James H; OAuth WG</span></p><div><div></div><div cla= ss=3D"h5"><br><b>Subject:</b> Re: [OAUTH-WG] Indicating sites where a token= is valid</div> </div><p></p></div></div><div><div></div><div class=3D"h5"><p class=3D"MsoN= ormal">=A0</p><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0</p>= <div><p class=3D"MsoNormal">On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-La= hav <<a href=3D"mailto:eran@hueniverse.com" target=3D"_blank">eran@hueni= verse.com</a>> wrote:</p> <div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F4= 97D">You are trying to match a mechanism designed for automatic discovery w= ith a system designed to require paperwork. It sounds like for your use cas= es, you will not be using this optional parameter and just document how to = use your API (i.e. hardcode your security setup and API format).</span></p> </div></div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNo= rmal">I'm saying it should be a fully automatic discovery or use paperw= ork. Having an API return valid URL prefixes to send the token to without h= aving an API to determine the actual URLs you send tokens to seems odd.</p> </div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padd= ing:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p clas= s=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</span></= p><p class=3D"MsoNormal"> <span style=3D"font-size:11.0pt;color:#1F497D">The whole point of this is t= hat the developer isn=92t involved. The library takes care of everything. A= ll the developer does is ask to get a protected resource. The library will = check if it already has a valid token for that resource (based on the secur= ity restrictions provided by the sites parameter, and the scope requirement= s =96 two very separate things).</span></p> </div></div></blockquote><div><p class=3D"MsoNormal">=A0</p></div><div><p c= lass=3D"MsoNormal">This is an incomplete mechanism for automatic discovery.= How does the developer find out where to ask for the protected resource in= the first place?</p> </div><blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padd= ing:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p clas= s=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</span></= p><p class=3D"MsoNormal"> <span style=3D"font-size:11.0pt;color:#1F497D">So yes =96 if your developer= s have plenty of stuff to hardcode already, this adds little value.</span><= /p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">= =A0</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">EHL</= span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F49= 7D">=A0</span></p><div style=3D"border:none;border-left:solid blue 1.5pt;pa= dding:0in 0in 0in 4.0pt"> <div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt= 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">Fr= om:</span></b><span style=3D"font-size:10.0pt"> <a href=3D"mailto:oauth-bou= nces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a> [mailto:<a href= =3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org= </a>] <b>On Behalf Of </b>Evan Gilbert<br> <b>Sent:</b> Thursday, May 13, 2010 9:00 AM</span></p><div><p class=3D"MsoN= ormal"><br><b>To:</b> Manger, James H<br><b>Cc:</b> OAuth WG<br><b>Subject:= </b> Re: [OAUTH-WG] Indicating sites where a token is valid</p></div></div> </div><p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal" style=3D"margin-= bottom:12.0pt">=A0</p><div><p class=3D"MsoNormal">On Wed, May 12, 2010 at 1= 1:52 PM, Manger, James H <<a href=3D"mailto:James.H.Manger@team.telstra.= com" target=3D"_blank">James.H.Manger@team.telstra.com</a>> wrote:</p> <div><div><p class=3D"MsoNormal">Evan,</p><div><p class=3D"MsoNormal" style= =3D"margin-bottom:12.0pt"><br>> The key point is that this discovery cov= ers a lot of the same grounds as the sites parameter, and it's hard =A0= to define semantics around a sites parameter without understanding the sema= ntics of scopes and API endpoints.</p> </div><p class=3D"MsoNormal">I strongly disagree. The semantics are crystal= clear:<br>=A0"Here is a token. It is INSECURE to send it anywhere not= in this list."<br>These semantics are useful regardless of what the A= PI does, how the client is using it, or how much (or how little) the client= knows about the API.</p> <div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">To exp= and - it's hard to define *useful* semantics=A0around a sites parameter= without understanding the semantics of scopes and API endpoints. Yes, you = can define crystal clear semantics, but these are not useful unless they wo= rk well with the way developers figure out the endpoints to call APIs.</p> </div><div><p class=3D"MsoNormal">=A0</p></div><blockquote style=3D"border:= none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:= 4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><p class=3D"Ms= oNormal"> <br><br>> Clients need to [know] more about these links (at least the re= sponse format).<br><br>That knowledge comes from other standards (HTML, Ato= m, wiki of rel values...) and is totally independent of whether a token sho= uld or should not be sent.</p> </blockquote><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoN= ormal">In our use cases, clients almost always need to know more about the = API:</p></div><div><p class=3D"MsoNormal">- How to call directly - we have = no API endpoints that are only arrived at by links</p> </div><p class=3D"MsoNormal">- Response format of the data</p><div><p class= =3D"MsoNormal">=A0</p></div><blockquote style=3D"border:none;border-left:so= lid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.= 0pt;margin-right:0in;margin-bottom:5.0pt"> <div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br><br>> The= mechanism they use to find out about these links -=A0documentation, discov= ery, data returned with token request - could also provide the information = about whether a token should be sent to a particular API.</p> </div><p class=3D"MsoNormal">Could, but shouldn't and doesn't in pr= actise.<br>It is much much better to have the information about how to use = a token securely delivered at the same time & place as receiving that t= oken, and with minimal assumptions about how much the client apps knows abo= ut the service.</p> </blockquote><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoN= ormal">So why wouldn't we return a list of specific API endpoints inste= ad of a "sites" parameter?</p></div><div><p class=3D"MsoNormal">= =A0</p> </div><div><p class=3D"MsoNormal">Developers are going to call the APIs end= points that they know about. If there is a conflict between this and the si= tes parameter, what should they do? For example, if facebook returns a site= s parameter "<a href=3D"https://unknown.facebook.com/" target=3D"_blan= k">https://unknown.facebook.com/</a>", do we think the developer is go= ing to not try to use the access token on=A0<span style=3D"font-size:10.0pt= "><a href=3D"https://graph.facebook.com/*" target=3D"_blank"><span style=3D= "color:#0000CC">https://graph.facebook.com/</span></a>=A0?=A0</span></p> </div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">= <span style=3D"font-size:10.0pt">Separating the concept of sites from API e= ndpoints feels like a bad idea. Discovery / docs will give you a list of UR= Ls where you should send tokens. The "sites" parameter will give = you a list of URLs where you can send tokens. This is redundant, and will l= ead to developers / libraries not respecting the sites parameter. If develo= pers / libraries don't respect it, then the service can't rely on i= t for enforcing security.</span></p> </div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">= <span style=3D"font-size:10.0pt">Another note: Where do we anticipate clien= ts storing the sites parameter in the User-Agent flow? Right now the access= token can be set as an HTTP cookie by the client. Do we expect them to set= a separate "sites" cookie and respect this on their server when = making requests? This seems complicated.</span></p> </div><div><p class=3D"MsoNormal">=A0</p></div><blockquote style=3D"border:= none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:= 4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><p class= =3D"MsoNormal" style=3D"margin-bottom:12.0pt"> <br><br>> I should be more concrete about the use cases I see. Let's= assume there's an API where there are two endpoints, each with an asso= ciated permission<br>> - contacts.list permission -> <a href=3D"http:= //contacts.serviceprovider.com/contacts/list" target=3D"_blank">http://cont= acts.serviceprovider.com/contacts/list</a><br> > - calendar.get permission -> <a href=3D"http://calendar.serviceprov= ider.com/calendar/get" target=3D"_blank">http://calendar.serviceprovider.co= m/calendar/get</a><br>><br>> If the response to an authorization requ= est includes the authorized scopes (contacts.list, calendar.get), then the = "sites" parameter is redundant.</p> </div><p class=3D"MsoNormal">I'll admit that "sites" is redun= dant if a client has *perfect* knowledge about a service, but so is pretty = much any standard at that point.<br><br>Consider a generic search spider to= ol that you point at <a href=3D"http://calendar.serviceprovider.com/calenda= r/get" target=3D"_blank">http://calendar.serviceprovider.com/calendar/get</= a>. It can do its job with no knowledge about what "calendar.get"= means -- but it still needs to know (as it spiders along) when it is safe = to expose the token.</p> </blockquote><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoN= ormal">How does the generic search spider know to call to <a href=3D"http:/= /calendar.serviceprovider.com/calendar/get" target=3D"_blank">http://calend= ar.serviceprovider.com/calendar/get</a> in the first place?</p> </div><div><p class=3D"MsoNormal">=A0</p></div><blockquote style=3D"border:= none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:= 4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><p class=3D"Ms= oNormal" style=3D"margin-bottom:12.0pt"> <br><br>--<br><span style=3D"color:#888888">James Manger</span></p></blockq= uote></div></div></div><p class=3D"MsoNormal">=A0</p></div></div></div></bl= ockquote></div><p class=3D"MsoNormal">=A0</p></div></div></div></div></div>= <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --00504502b659fab16c0486ba699f-- From dick.hardt@gmail.com Sun May 16 11:44:41 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384B93A6B0F for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] 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 yLvwKt26RLS4 for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:44:40 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 2B1273A6B0B for <oauth@ietf.org>; Sun, 16 May 2010 11:44:39 -0700 (PDT) Received: by pzk38 with SMTP id 38so77046pzk.31 for <oauth@ietf.org>; Sun, 16 May 2010 11:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jKAzPuAz8NSYV3CSogCteowmkv9owDQ55mYUpf92Nhc=; b=Aywhpc4r2dCN0uWa9bVbMlN4fJLTup7y+Tb8rD6T2Gm6GHAS9l71mTqpruPCxZkqY4 +VByp91BL/reZDd2d0LijgvqTnKPj3n1ltSgq5cbe5FSkq3bfUh6jKX5B+/R3CTxn1/Q FpkHQasWpD4uUG5nRn9Wz3h3oPF7QlZVklj3Q= 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=Arh0BhjDcA4ck8bLwQ2SjHrv+2V9JhTF6G2sLj4t0hiFZzFrzYQouGh8w+3wgOHCke vJ+26W47axfzt0gtnrgc45IXER/T/wgmAtXnztUHdmR9yC7MU+bD8o+L9tBegGdT2dQ9 XsG9Xbm5ixEyhRvCgcW9R7tWfLqquZDqzfrks= MIME-Version: 1.0 Received: by 10.142.67.35 with SMTP id p35mr2849890wfa.203.1274035468677; Sun, 16 May 2010 11:44:28 -0700 (PDT) Received: by 10.142.87.17 with HTTP; Sun, 16 May 2010 11:44:28 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112634F5584@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112634F5377@WSMSG3153V.srv.dir.telstra.com> <AANLkTil3phNYPp_vkEDwlov3zAU-NHrw72OpnaK26ixo@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634F5584@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 16 May 2010 11:44:28 -0700 Message-ID: <AANLkTineTf6euI5U7RGgfru7rfNL7N-6iHGgwR34rvs-@mail.gmail.com> From: Dick Hardt <dick.hardt@gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=001636e0a8f28ab4590486ba7fa1 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Separate HTTP and HTTPS tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 18:44:41 -0000 --001636e0a8f28ab4590486ba7fa1 Content-Type: text/plain; charset=ISO-8859-1 Note that you could accomplish this functionality with the 'modify' proposal I posted where an access token with a different scope could be requested could be used to acquire a second token that has less privileges and would be appropriate over HTTP. To recap, 'modify' is like 'refresh' except the new scope is also passed as a parameter. -- Dick On Thu, May 13, 2010 at 9:38 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > David, > > > Why would we support bearer tokens over HTTP? > > Is someone planning to implement this? > > Because the cookies-over-HTTP ~equivalent is widely used. > The spec does say SHOULD NOT, but also explicitly talks about how to do it. > the spec suggests limited scope and lifetime -- limited scope implies > separate tokens for other scopes (eg for HTTPS). > > [section 5 Accessing a Protected Resource] > > Access tokens SHOULD NOT be sent in the clear over an insecure channel. > > However, when it is necessary to transmit bearer tokens in the clear > without a secure channel, authorization servers SHOULD issue access > tokens with limited scope and lifetime to reduce the potential risk > from a compromised access token. Clients SHOULD request and utilize > an access token with a matching secret when making protected resource > requests over an insecure channel (e.g. an HTTP request without using > TLS/SSL). > > > Even if you only support signed requests over HTTP you probably still want > 2 tokens: a bearer token for HTTPS; a token+secret for HTTP. > > [ > { "access_token":"Id87d6dDd", "sites":["https://api.example.org"] }, > { "access_token":"SlAV32hkKG", "sites":["http://api.example.org"], > access_token_secret="386584633534" } > ] > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636e0a8f28ab4590486ba7fa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Note that you could accomplish this functionality with the 'modify= ' proposal I posted where an access token with a different scope could = be requested could be used to acquire a second token that has less=A0privil= eges=A0and would be appropriate over HTTP.</div> <div><br></div><div>To recap, 'modify' is like 'refresh' ex= cept the new scope is also passed as a parameter.</div><div><br></div><div>= -- Dick<br><br><div class=3D"gmail_quote">On Thu, May 13, 2010 at 9:38 PM, = Manger, James H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Manger@team= .telstra.com">James.H.Manger@team.telstra.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">David,<br> <div class=3D"im"><br> > Why would we support bearer tokens over HTTP?<br> > Is someone planning to implement this?<br> <br> </div>Because the cookies-over-HTTP ~equivalent is widely used.<br> The spec does say SHOULD NOT, but also explicitly talks about how to do it.= <br> the spec suggests limited scope and lifetime -- limited scope implies separ= ate tokens for other scopes (eg for HTTPS).<br> <br> [section 5 Accessing a Protected Resource]<br> <br> =A0 Access tokens SHOULD NOT be sent in the clear over an insecure channel= .<br> <br> =A0 However, when it is necessary to transmit bearer tokens in the clear<b= r> =A0 without a secure channel, authorization servers SHOULD issue access<br= > =A0 tokens with limited scope and lifetime to reduce the potential risk<br= > =A0 from a compromised access token. =A0Clients SHOULD request and utilize= <br> =A0 an access token with a matching secret when making protected resource<= br> =A0 requests over an insecure channel (e.g. an HTTP request without using<= br> =A0 TLS/SSL).<br> <br> <br> Even if you only support signed requests over HTTP you probably still want = 2 tokens: a bearer token for HTTPS; a token+secret for HTTP.<br> <br> [<br> =A0{ "access_token":"Id87d6dDd", "sites":[&q= uot;<a href=3D"https://api.example.org" target=3D"_blank">https://api.examp= le.org</a>"] },<br> <div class=3D"im"> =A0{ "access_token":"SlAV32hkKG", &q= uot;sites":["<a href=3D"http://api.example.org" target=3D"_blank"= >http://api.example.org</a>"],<br> </div> =A0 =A0 =A0 access_token_secret=3D"386584633534" }<br> <div><div></div><div class=3D"h5">]<br> <br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br></div> --001636e0a8f28ab4590486ba7fa1-- From dick.hardt@gmail.com Sun May 16 11:58:42 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEB03A6A68 for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_50=0.001, 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 Jhyh8qDo3Nsf for <oauth@core3.amsl.com>; Sun, 16 May 2010 11:58:36 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 8B7303A6949 for <oauth@ietf.org>; Sun, 16 May 2010 11:58:36 -0700 (PDT) Received: by pzk38 with SMTP id 38so80402pzk.31 for <oauth@ietf.org>; Sun, 16 May 2010 11:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=C2zjPaaJf9KM5u/SiMXCGvQaJrrzYitBQmdwPuzwXeo=; b=N/zpLbX8yGc/CytbPBoM0IyJBcrRWbmICvPhG4MkrzefZ95Wb04ZDb/jJuyhe52vPG nYTyqp8WqreXIaF7o43EpMYYIjwJt4uUfceysPTtnTRWr8IcJjGlVjeZnet+UELE6N9A mOsAhN5MGzeZpmej7cl2E797oxJ2dgs430iLw= 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=rLWU93jnytAbrXzAOcEqI07f6+YskVq5qAN61PN2XKhugZEdRxmvz5QdrCiUNuIqeV b+xInorOmgH69J69YIQsHAjlG9xnMSExUsDkIdkvOWKAIIoPJ+T80j60jOJftuEX6CoE e49SQInCKStZfDfjBi0enKgjZRLQ3oys75jnQ= MIME-Version: 1.0 Received: by 10.143.27.41 with SMTP id e41mr2721721wfj.343.1274036305415; Sun, 16 May 2010 11:58:25 -0700 (PDT) Received: by 10.142.87.17 with HTTP; Sun, 16 May 2010 11:58:25 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112634F5B35@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112634F5B35@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 16 May 2010 11:58:25 -0700 Message-ID: <AANLkTimEA62XtY6LqkICqlvNYPJlDT42U6dMxuhP52U2@mail.gmail.com> From: Dick Hardt <dick.hardt@gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=00504502cd116a4ec10486bab17e Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Spec text for "sites" field X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 18:58:42 -0000 --00504502cd116a4ec10486bab17e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Looking over the previous threads, I don't think an important capability wa= s pointed out that we want to preserve: The AS may NOT need or want to know where an access token is used. In other words, the access token could be viewed as a claim that can presented to an arbitrary resource to gain access. This enables new resources to be deployed without having to *register* them at the AS. One way to deal with the security issues of a bearer token is to signing with a private key belonging to the client which prevents reuse of the access token by an unscrupulous PR as the signed request will be bound to that PR. The proposal below does not preclude this capability as written as the site= s parameter is optional, so I am not suggesting a change, but am pointing out the capability. -- Dick On Sun, May 16, 2010 at 7:09 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Below is text about the "sites" field in spec-ready detail to make it > easier for the editor. > There hasn't been unanimous support for this field amongst the long > discussions. However, my feeling is that most have recognised that it is > needed. > > > [for 3.3.2.1. Access Token Response] > > [add to the list of common parameters] > > sites > OPTIONAL. Indicates the sites where the token can be used. > > > [add below the list of common parameters] > > The "sites" field indicates where the issued token can be used. Its value > is an array of strings, where each string obeys the <site> production. If > the "sites" field is absent it MUST be treated as though the field was > present with a single string consisting of the scheme, host, and port of = the > site that issued the token. > > site =3D scheme "://" [wildcard] host [":" port] > ; scheme, host, and port are defined in [RFC3986] > wildcard =3D "*." > > The token MUST NOT be used with a request to a URI unless the URI matches > at least one string in the =93sites=94 value. A token SHOULD be used > pre-emptively when the URI does match. Any string in the "sites" value th= at > does not obey the <site> production MUST be ignored. A URI matches a stri= ng > if the following conditions are all met: > 1. The scheme of the URI and string are equal, ignoring case. > 2. The port number of the URI and string are numerically equal, using the > default port number for a scheme if no port is specified (eg 443 for http= s). > 3. The wildcard is absent and the host of the URI and string are equal, > ignoring case; or the wildcard is present and a "." followed by the host = of > the string is a suffix of the host of the URI, ignoring case. > > The following URIs match the example below (so the token should be used): > https://api.example.com:443/xyz?q=3D1 > HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg > > The following URIs do NOT match the example below (so the token must not = be > used): > http://api.example.com/index.html (wrong scheme) > https://data.example.com/4254.json (host not a sub-domain) > > > [add the following line to the example HTTP response] > > "sites": ["https://api.example.com", "https://*.data.example.com"], > > > [may need to reference the ABNF RFC (instead of httpbis for ABNF?)] > > [RFC5234] "Augmented BNF for Syntax Specifications: ABNF" > > [end of spec text] > > > Potential issues: > * Internationalized domain names: the text above implies toASCII domain > names appear in "sites" (by using <host> from RFC3986 URI, not <ihost> fr= om > RFC3987 IRI) > * <wildcard> doesn't make much sense if <host> is an IP addresses, but > isn't harmful > * draft-abarth-origin offers more rigorous rules for scheme/host/port > origins > * ignoring strings that don't match <site> provides some room for > extensibility, while being fail-safe for earlier client apps > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00504502cd116a4ec10486bab17e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Looking over the previous threads, I don't think an important capabilit= y was pointed out that we want to preserve:<div><br></div><div>The AS may N= OT need or want to know where an access token is used. In other words, the = access token could be viewed as a claim that can presented to an arbitrary = resource to gain access. =A0This enables new resources to be deployed witho= ut having to *register* them at the AS.</div> <div><br></div><div>One way to deal with the security issues of a bearer to= ken is to signing with a private key belonging to the client which prevents= reuse of the access token by an=A0unscrupulous=A0 PR as the signed request= will be bound to that PR.</div> <div><br></div><div>The proposal below does not preclude this capability as= written as the sites parameter is optional, so I am not suggesting a chang= e, but am pointing out the capability.</div><div><br></div><div>-- Dick<br> <br><div class=3D"gmail_quote">On Sun, May 16, 2010 at 7:09 AM, Manger, Jam= es H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Manger@team.telstra.co= m">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex;"> Below is text about the "sites" field in spec-ready detail to mak= e it easier for the editor.<br> There hasn't been unanimous support for this field amongst the long dis= cussions. However, my feeling is that most have recognised that it is neede= d.<br> <br> <br> [for 3.3.2.1. Access Token Response]<br> <br> [add to the list of common parameters]<br> <br> =A0 sites<br> =A0=A0=A0 OPTIONAL. Indicates the sites where the token can be used.<br> <br> <br> [add below the list of common parameters]<br> <br> The "sites" field indicates where the issued token can be used. I= ts value is an array of strings, where each string obeys the <site> p= roduction. If the "sites" field is absent it MUST be treated as t= hough the field was present with a single string consisting of the scheme, = host, and port of the site that issued the token.<br> =A0<br> =A0 site =A0 =A0 =3D scheme "://" [wildcard] host [":" = port]<br> =A0 =A0; scheme, host, and port are defined in [RFC3986]<br> =A0 wildcard =3D "*."<br> <br> The token MUST NOT be used with a request to a URI unless the URI matches a= t least one string in the =93sites=94 value. A token SHOULD be used pre-emp= tively when the URI does match. Any string in the "sites" value t= hat does not obey the <site> production MUST be ignored. A URI matche= s a string if the following conditions are all met:<br> 1. The scheme of the URI and string are equal, ignoring case.<br> 2. The port number of the URI and string are numerically equal, using the d= efault port number for a scheme if no port is specified (eg 443 for https).= <br> 3. The wildcard is absent and the host of the URI and string are equal, ign= oring case; or the wildcard is present and a "." followed by the = host of the string is a suffix of the host of the URI, ignoring case.<br> <br> The following URIs match the example below (so the token should be used):<b= r> =A0 <a href=3D"https://api.example.com:443/xyz?q=3D1" target=3D"_blank">htt= ps://api.example.com:443/xyz?q=3D1</a><br> =A0 <a href=3D"HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg" target=3D"_blan= k">HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg</a><br> <br> The following URIs do NOT match the example below (so the token must not be= used):<br> =A0 <a href=3D"http://api.example.com/index.html" target=3D"_blank">http://= api.example.com/index.html</a>=A0 (wrong scheme)<br> =A0 <a href=3D"https://data.example.com/4254.json" target=3D"_blank">https:= //data.example.com/4254.json</a>=A0 (host not a sub-domain)<br> <br> <br> [add the following line to the example HTTP response]<br> <br> =A0"sites": ["<a href=3D"https://api.example.com" target=3D= "_blank">https://api.example.com</a>", "https://*.<a href=3D"http= ://data.example.com" target=3D"_blank">data.example.com</a>"],<br> <br> <br> [may need to reference the ABNF RFC (instead of httpbis for ABNF?)]<br> <br> =A0 [RFC5234] =A0"Augmented BNF for Syntax Specifications: ABNF"= <br> <br> [end of spec text]<br> <br> <br> Potential issues:<br> * Internationalized domain names: the text above implies toASCII domain nam= es appear in "sites" (by using <host> from RFC3986 URI, not= <ihost> from RFC3987 IRI)<br> * <wildcard> doesn't make much sense if <host> is an IP add= resses, but isn't harmful<br> * draft-abarth-origin offers more rigorous rules for scheme/host/port origi= ns<br> * ignoring strings that don't match <site> provides some room for= extensibility, while being fail-safe for earlier client apps<br> <font color=3D"#888888"><br> --<br> James Manger<br> <br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </font></blockquote></div><br></div> --00504502cd116a4ec10486bab17e-- From trac@tools.ietf.org Sun May 16 12:10:19 2010 Return-Path: <trac@tools.ietf.org> 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 5A60E3A67A2 for <oauth@core3.amsl.com>; Sun, 16 May 2010 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 1CxApeFA9xgv for <oauth@core3.amsl.com>; Sun, 16 May 2010 12:10:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 98A953A6949 for <oauth@ietf.org>; Sun, 16 May 2010 12:10:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from <trac@tools.ietf.org>) id 1ODjE0-0000Iy-Go; Sun, 16 May 2010 12:10:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: recordond@gmail.com X-Trac-Project: oauth Date: Sun, 16 May 2010 19:10:08 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/6#comment:1 Message-ID: <064.d3ca6a75b75911d372c221cccd4fe562@tools.ietf.org> References: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: recordond@gmail.com, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #6: Make automated self-registration of unique clients possible X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 19:10:19 -0000 #6: Make automated self-registration of unique clients possible -----------------------------+---------------------------------------------- Reporter: eve@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Keywords: -----------------------------+---------------------------------------------- Comment(by recordond@…): I proposed http://openidconnect.com/#associations for OpenID Connect. While I think it could become part of OAuth 2.0, the spec is already getting way too long. -- Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/6#comment:1> oauth <http://tools.ietf.org/oauth/> From recordond@gmail.com Sun May 16 12:17:18 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8483A67B6 for <oauth@core3.amsl.com>; Sun, 16 May 2010 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.369, 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 8dhZw494Nl0C for <oauth@core3.amsl.com>; Sun, 16 May 2010 12:17:16 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id 991163A67A2 for <oauth@ietf.org>; Sun, 16 May 2010 12:17:16 -0700 (PDT) Received: by yxe12 with SMTP id 12so2118562yxe.32 for <oauth@ietf.org>; Sun, 16 May 2010 12:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2/W9QNsZAnNiG7764Wxi12WTPTO6gOly1s4rtdp6HDM=; b=noT2QQQ6pokAgZ39UlGT6iyD0PDF/nCkKegza+K5QMZfSbaolGIHkdAKEAHB/KoLa+ P4OoIFClm0fLG/xs67UgSLuRBlYCqyh8JQdjUM3+CRQD6ljilfbO9yiN/RIF9HC6qiGj wJlkflXPgxRpvyuC0DLmJXbGUgvTkOGnSNsoM= 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=MW6ei6qTSBcteIk2OftqOYUMVOBnaTZlY6xSSLB4f0J8oevISFewczZozP8jZtMU0t M8HYisfnwxHj8cLi6e7JJ33wULyqEaWk8bIOv12XMNxhNRJJdcyKtqz81jBXlRIVyEtI Nn2UQ8XVuxYdFtcCAQt0astq5uXoUkgQ3RLw0= MIME-Version: 1.0 Received: by 10.101.205.6 with SMTP id h6mr5069626anq.179.1274037425113; Sun, 16 May 2010 12:17:05 -0700 (PDT) Received: by 10.100.152.10 with HTTP; Sun, 16 May 2010 12:17:05 -0700 (PDT) In-Reply-To: <AANLkTimEA62XtY6LqkICqlvNYPJlDT42U6dMxuhP52U2@mail.gmail.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112634F5B35@WSMSG3153V.srv.dir.telstra.com> <AANLkTimEA62XtY6LqkICqlvNYPJlDT42U6dMxuhP52U2@mail.gmail.com> Date: Sun, 16 May 2010 12:17:05 -0700 Message-ID: <AANLkTinwBremccqiI3NTVQSswfQWq53RBlZ9QSlQ094P@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com>, Dick Hardt <dick.hardt@gmail.com> Content-Type: multipart/alternative; boundary=0016e68ee227278af30486baf4ac Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Spec text for "sites" field X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 19:17:18 -0000 --0016e68ee227278af30486baf4ac Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dick, that's a really good point! I'm glad you brought it up because I thin= k it got lost in the focus on this one use case. James, thanks for writing this up! I'm wondering if this could be first written and deployed as an extension and we see if and how it gets used in the wild. Otherwise I think a strong argument should be presented from a security perspective as to why it must be in the core spec itself versus documented as a security consideration. --David On Sun, May 16, 2010 at 11:58 AM, Dick Hardt <dick.hardt@gmail.com> wrote: > Looking over the previous threads, I don't think an important capability > was pointed out that we want to preserve: > > The AS may NOT need or want to know where an access token is used. In oth= er > words, the access token could be viewed as a claim that can presented to = an > arbitrary resource to gain access. This enables new resources to be > deployed without having to *register* them at the AS. > > One way to deal with the security issues of a bearer token is to signing > with a private key belonging to the client which prevents reuse of the > access token by an unscrupulous PR as the signed request will be bound t= o > that PR. > > The proposal below does not preclude this capability as written as the > sites parameter is optional, so I am not suggesting a change, but am > pointing out the capability. > > -- Dick > > > On Sun, May 16, 2010 at 7:09 AM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > >> Below is text about the "sites" field in spec-ready detail to make it >> easier for the editor. >> There hasn't been unanimous support for this field amongst the long >> discussions. However, my feeling is that most have recognised that it is >> needed. >> >> >> [for 3.3.2.1. Access Token Response] >> >> [add to the list of common parameters] >> >> sites >> OPTIONAL. Indicates the sites where the token can be used. >> >> >> [add below the list of common parameters] >> >> The "sites" field indicates where the issued token can be used. Its valu= e >> is an array of strings, where each string obeys the <site> production. I= f >> the "sites" field is absent it MUST be treated as though the field was >> present with a single string consisting of the scheme, host, and port of= the >> site that issued the token. >> >> site =3D scheme "://" [wildcard] host [":" port] >> ; scheme, host, and port are defined in [RFC3986] >> wildcard =3D "*." >> >> The token MUST NOT be used with a request to a URI unless the URI matche= s >> at least one string in the =93sites=94 value. A token SHOULD be used >> pre-emptively when the URI does match. Any string in the "sites" value t= hat >> does not obey the <site> production MUST be ignored. A URI matches a str= ing >> if the following conditions are all met: >> 1. The scheme of the URI and string are equal, ignoring case. >> 2. The port number of the URI and string are numerically equal, using th= e >> default port number for a scheme if no port is specified (eg 443 for htt= ps). >> 3. The wildcard is absent and the host of the URI and string are equal, >> ignoring case; or the wildcard is present and a "." followed by the host= of >> the string is a suffix of the host of the URI, ignoring case. >> >> The following URIs match the example below (so the token should be used)= : >> https://api.example.com:443/xyz?q=3D1 >> HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg >> >> The following URIs do NOT match the example below (so the token must not >> be used): >> http://api.example.com/index.html (wrong scheme) >> https://data.example.com/4254.json (host not a sub-domain) >> >> >> [add the following line to the example HTTP response] >> >> "sites": ["https://api.example.com", "https://*.data.example.com"], >> >> >> [may need to reference the ABNF RFC (instead of httpbis for ABNF?)] >> >> [RFC5234] "Augmented BNF for Syntax Specifications: ABNF" >> >> [end of spec text] >> >> >> Potential issues: >> * Internationalized domain names: the text above implies toASCII domain >> names appear in "sites" (by using <host> from RFC3986 URI, not <ihost> f= rom >> RFC3987 IRI) >> * <wildcard> doesn't make much sense if <host> is an IP addresses, but >> isn't harmful >> * draft-abarth-origin offers more rigorous rules for scheme/host/port >> origins >> * ignoring strings that don't match <site> provides some room for >> extensibility, while being fail-safe for earlier client apps >> >> -- >> James Manger >> >> _______________________________________________ >> 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 > > --0016e68ee227278af30486baf4ac Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dick, that's a really good point! I'm glad you brought it up becaus= e I think it got lost in the focus on this one use case.<br><br><div>James,= thanks for writing this up!</div><div><br></div><div>I'm wondering if = this could be first written and deployed as an extension and we see if and = how it gets used in the wild. Otherwise I think a strong argument should be= presented from a security perspective as to why it must be in the core spe= c itself versus documented as a security consideration.</div> <div><br></div><div>--David</div><div><br></div><div><br><div class=3D"gmai= l_quote">On Sun, May 16, 2010 at 11:58 AM, Dick Hardt <span dir=3D"ltr"><= ;<a href=3D"mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a>></span= > wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Looking over the previous threads, I don= 9;t think an important capability was pointed out that we want to preserve:= <div> <br></div><div>The AS may NOT need or want to know where an access token is= used. In other words, the access token could be viewed as a claim that can= presented to an arbitrary resource to gain access. =A0This enables new res= ources to be deployed without having to *register* them at the AS.</div> <div><br></div><div>One way to deal with the security issues of a bearer to= ken is to signing with a private key belonging to the client which prevents= reuse of the access token by an=A0unscrupulous=A0 PR as the signed request= will be bound to that PR.</div> <div><br></div><div>The proposal below does not preclude this capability as= written as the sites parameter is optional, so I am not suggesting a chang= e, but am pointing out the capability.</div><div><br></div><div><font color= =3D"#888888">-- Dick</font><div> <div></div><div class=3D"h5"><br> <br><div class=3D"gmail_quote">On Sun, May 16, 2010 at 7:09 AM, Manger, Jam= es H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Manger@team.telstra.co= m" target=3D"_blank">James.H.Manger@team.telstra.com</a>></span> wrote:<= br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Below is text about the "sites" field in spec-ready detail to mak= e it easier for the editor.<br> There hasn't been unanimous support for this field amongst the long dis= cussions. However, my feeling is that most have recognised that it is neede= d.<br> <br> <br> [for 3.3.2.1. Access Token Response]<br> <br> [add to the list of common parameters]<br> <br> =A0 sites<br> =A0=A0=A0 OPTIONAL. Indicates the sites where the token can be used.<br> <br> <br> [add below the list of common parameters]<br> <br> The "sites" field indicates where the issued token can be used. I= ts value is an array of strings, where each string obeys the <site> p= roduction. If the "sites" field is absent it MUST be treated as t= hough the field was present with a single string consisting of the scheme, = host, and port of the site that issued the token.<br> =A0<br> =A0 site =A0 =A0 =3D scheme "://" [wildcard] host [":" = port]<br> =A0 =A0; scheme, host, and port are defined in [RFC3986]<br> =A0 wildcard =3D "*."<br> <br> The token MUST NOT be used with a request to a URI unless the URI matches a= t least one string in the =93sites=94 value. A token SHOULD be used pre-emp= tively when the URI does match. Any string in the "sites" value t= hat does not obey the <site> production MUST be ignored. A URI matche= s a string if the following conditions are all met:<br> 1. The scheme of the URI and string are equal, ignoring case.<br> 2. The port number of the URI and string are numerically equal, using the d= efault port number for a scheme if no port is specified (eg 443 for https).= <br> 3. The wildcard is absent and the host of the URI and string are equal, ign= oring case; or the wildcard is present and a "." followed by the = host of the string is a suffix of the host of the URI, ignoring case.<br> <br> The following URIs match the example below (so the token should be used):<b= r> =A0 <a href=3D"https://api.example.com:443/xyz?q=3D1" target=3D"_blank">htt= ps://api.example.com:443/xyz?q=3D1</a><br> =A0 <a href=3D"HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg" target=3D"_blan= k">HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg</a><br> <br> The following URIs do NOT match the example below (so the token must not be= used):<br> =A0 <a href=3D"http://api.example.com/index.html" target=3D"_blank">http://= api.example.com/index.html</a>=A0 (wrong scheme)<br> =A0 <a href=3D"https://data.example.com/4254.json" target=3D"_blank">https:= //data.example.com/4254.json</a>=A0 (host not a sub-domain)<br> <br> <br> [add the following line to the example HTTP response]<br> <br> =A0"sites": ["<a href=3D"https://api.example.com" target=3D= "_blank">https://api.example.com</a>", "https://*.<a href=3D"http= ://data.example.com" target=3D"_blank">data.example.com</a>"],<br> <br> <br> [may need to reference the ABNF RFC (instead of httpbis for ABNF?)]<br> <br> =A0 [RFC5234] =A0"Augmented BNF for Syntax Specifications: ABNF"= <br> <br> [end of spec text]<br> <br> <br> Potential issues:<br> * Internationalized domain names: the text above implies toASCII domain nam= es appear in "sites" (by using <host> from RFC3986 URI, not= <ihost> from RFC3987 IRI)<br> * <wildcard> doesn't make much sense if <host> is an IP add= resses, but isn't harmful<br> * draft-abarth-origin offers more rigorous rules for scheme/host/port origi= ns<br> * ignoring strings that don't match <site> provides some room for= extensibility, while being fail-safe for earlier client apps<br> <font color=3D"#888888"><br> --<br> James Manger<br> <br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </font></blockquote></div><br></div></div></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --0016e68ee227278af30486baf4ac-- From lshepard@facebook.com Sun May 16 13:03:04 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483483A6833 for <oauth@core3.amsl.com>; Sun, 16 May 2010 13:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 D2L1qTIO4FCc for <oauth@core3.amsl.com>; Sun, 16 May 2010 13:03:02 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 7C15F3A67F5 for <oauth@ietf.org>; Sun, 16 May 2010 13:03:02 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4GK1p8G017947 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 16 May 2010 13:02:03 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Sun, 16 May 2010 13:01:31 -0700 From: Luke Shepard <lshepard@facebook.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Sun, 16 May 2010 13:01:28 -0700 Thread-Topic: [OAUTH-WG] modifying the scope of an access token Thread-Index: Acr1MpN70BoqPPrYS+6zr8xYoCkMBw== Message-ID: <57407F0C-85EC-482F-88B5-CE6E16D24845@facebook.com> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTikbUvqQLCvOAsY9d2CDdg9222xX9zwIEWmNA4RW@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinSQpI4JX6_TVL4ZAI0oYSehKB9vEfQyZafggtM@mail.gmail.com> <AANLkTiktDsVRfYoY2ArgM0VSLkNhMv5oadcX1pHq6j_Q@mail.gmail.com> <AANLkTimbJ8pIVgDLBqag7FjVVrJr0magID52u6T9LUc3@mail.gmail.com> <AANLkTilD6-wxXtwwDyR6E7I271qy2mbIEh7W_e0YRACT@mail.gmail.com> In-Reply-To: <AANLkTilD6-wxXtwwDyR6E7I271qy2mbIEh7W_e0YRACT@mail.gmail.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_57407F0C85EC482F88B5CE6E16D24845facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-14_02:2010-02-06, 2010-05-14, 2010-05-16 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] modifying the scope of an access token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 20:03:04 -0000 --_000_57407F0C85EC482F88B5CE6E16D24845facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, you want to give developers the option to reduce the abilities of their= token after it's already been issued? I have never heard a developer ask f= or this feature. Beyond the general principle of "least-authority", can you describe a speci= fic case where this would be useful? Are you talking about transferring tok= ens to a third party, or maintaining multiple tokens of different scopes wi= thin the same client? On May 16, 2010, at 10:34 AM, Dick Hardt wrote: John / David: is this a feature you would want to implement? If no one want= s it, we can drop it. On Mon, May 10, 2010 at 11:52 PM, John Panzer <jpanzer@google.com<mailto:jp= anzer@google.com>> wrote: (Note that in my use case, it's actually the client who wants to dispose of= its dangerous full-access token as quickly as possible, retaining only the= least-authority token it needs to continue its ongoing work. This would b= e the case even if the token granting service is handing out tokens like fr= ee candy.) On Mon, May 10, 2010 at 10:43 PM, David Recordon <recordond@gmail.com<mailt= o:recordond@gmail.com>> wrote: I'm wondering if this could be achieved by adding an optional scope parameter to the existing refresh request versus creating a new request type. Both because Dick's proposed text requires a refresh token and it seems like services worried about this sort of risk would not want to issue long lived access tokens. --David On Mon, May 10, 2010 at 10:39 PM, John Panzer <jpanzer@google.com<mailto:jp= anzer@google.com>> wrote: > Yes; a service that does a one time configuration step, requiring > extensive access, followed by an ongoing lower level of access (say, > read-only). Lowering access means it only needs to store low-risk > tokens in its data store, limiting exposure (and liability). > > On Monday, May 10, 2010, Eran Hammer-Lahav <eran@hueniverse.com<mailto:er= an@hueniverse.com>> wrote: >> Are there actual use cases for this? Either way sounds like it belongs i= n an extension. >> >> EHL >> >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurtescu@google.com<mailto:mscurtescu@= google.com>] >>> Sent: Monday, May 10, 2010 12:49 PM >>> To: Eran Hammer-Lahav >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token >>> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav >>> <eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote: >>> > This would only work for the client credentials flow (because you kee= p the >>> same authorization source). For all other flows you are breaking the >>> authorization boundaries. >>> >>> If the requested scope is a subset of the original scope associated wit= h the >>> refresh token then it should be acceptable, right? >>> >>> This would allow a client to request a larger set of scopes, needed for= all API >>> calls need for its function, but then get sub-scoped access tokens, par= ticular >>> to each API. This will prevent an API from receiving a too powerful acc= ess >>> token. A compromised API could use access tokens to place calls against >>> other APIs, but not if it is narrowly scoped. >>> >>> Marius >>> >>> > >>> > What would be useful is to allow asking for more scope. For example, = when >>> asking for a token (the last step of each flow), also include a valid t= oken to >>> get a new token with the combined scope (new approval and previous). >>> > >>> > EHL >>> > >>> >> -----Original Message----- >>> >> From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:= oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>] On >>> >> Behalf Of Dick Hardt >>> >> Sent: Sunday, May 09, 2010 7:19 PM >>> >> To: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) >>> >> Subject: [OAUTH-WG] modifying the scope of an access token >>> >> >>> >> There has been some discussion about modifying the scope of the >>> >> access token during a refresh. Perhaps we can add another "method" t= o >>> >> what the AS MAY support that allows modifying the scope of an access >>> >> token. Type of request is "modify" and the scope parameter is >>> >> required to indicate the new scope required. Suggested copy below: >>> >> >>> >> type >>> >> REQUIRED. The parameter value MUST be set to modify >>> >> >>> >> client_id >>> >> REQUIRED. The client identifier as described in Section 3.4. >>> >> >>> >> client_secret >>> >> REQUIRED if the client was issued a secret. The client secret. >>> >> >>> >> refresh_token >>> >> REQUIRED. The refresh token associated with the access token t= o >>> >> be refreshed. >>> >> >>> >> scope >>> >> REQUIRED. The new scope of the access request expressed as a >>> >> list of space-delimited strings. The value of the scope parameter is >>> >> defined by the authorization server. If the value contains multiple >>> >> space-delimited strings, their order does not matter, and each strin= g >>> >> adds additional access range to the requested scope. >>> >> >>> >> secret_type >>> >> OPTIONAL. The access token secret type as described by Section= 8.3. >>> >> If omitted, the authorization server will issue a bearer token (an >>> >> access token without a matching secret) as described by Section 8.2. >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org<mailto:OAuth@ietf.org> >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org<mailto:OAuth@ietf.org> >>> > https://www.ietf.org/mailman/listinfo/oauth >>> > >> _______________ > > -- > -- > John Panzer / Google > jpanzer@google.com<mailto:jpanzer@google.com> / abstractioneer.org<http:/= /abstractioneer.org/> / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt> --_000_57407F0C85EC482F88B5CE6E16D24845facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; "><div>So, you want to give = developers the option to reduce the abilities of their token after it's alr= eady been issued? I have never heard a developer ask for this feature.</div= ><div><br></div><div>Beyond the general principle of "least-authority", can= you describe a specific case where this would be useful? Are you talking a= bout transferring tokens to a third party, or maintaining multiple tokens o= f different scopes within the same client?</div><div><br></div><div><br></d= iv><div><br></div><div><div>On May 16, 2010, at 10:34 AM, Dick Hardt wrote:= </div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Joh= n / David: is this a feature you would want to implement? If no one wants i= t, we can drop it.<div><br><br><div class=3D"gmail_quote">On Mon, May 10, 2= 010 at 11:52 PM, John Panzer <span dir=3D"ltr"><<a href=3D"mailto:jpanze= r@google.com">jpanzer@google.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">(Note that in my use case, it's actually th= e client who wants to dispose of its dangerous full-access token as quickly= as possible, retaining only the least-authority token it needs to continue= its ongoing work.  This would be the case even if the token granting = service is handing out tokens like free candy.)<div> <div></div><div class=3D"h5"><div> <br><div class=3D"gmail_quote">On Mon, May 10, 2010 at 10:43 PM, David Reco= rdon <span dir=3D"ltr"><<a href=3D"mailto:recordond@gmail.com" target=3D= "_blank">recordond@gmail.com</a>></span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> I'm wondering if this could be achieved by adding an optional scope<br> parameter to the existing refresh request versus creating a new<br> request type. Both because Dick's proposed text requires a refresh<br> token and it seems like services worried about this sort of risk would<br> not want to issue long lived access tokens.<br> <font color=3D"#888888"><br> --David<br> </font><div><div></div><div><br> <br> On Mon, May 10, 2010 at 10:39 PM, John Panzer <<a href=3D"mailto:jpanzer= @google.com" target=3D"_blank">jpanzer@google.com</a>> wrote:<br> > Yes; a service that does a one time configuration step, requiring<br> > extensive access, followed by an ongoing lower level of access (say,<b= r> > read-only).  Lowering access means it only needs to store low-ris= k<br> > tokens in its data store, limiting exposure (and liability).<br> ><br> > On Monday, May 10, 2010, Eran Hammer-Lahav <<a href=3D"mailto:eran@= hueniverse.com" target=3D"_blank">eran@hueniverse.com</a>> wrote:<br> >> Are there actual use cases for this? Either way sounds like it bel= ongs in an extension.<br> >><br> >> EHL<br> >><br> >>> -----Original Message-----<br> >>> From: Marius Scurtescu [mailto:<a href=3D"mailto:mscurtescu@go= ogle.com" target=3D"_blank">mscurtescu@google.com</a>]<br> >>> Sent: Monday, May 10, 2010 12:49 PM<br> >>> To: Eran Hammer-Lahav<br> >>> Cc: Dick Hardt; OAuth WG (<a href=3D"mailto:oauth@ietf.org" ta= rget=3D"_blank">oauth@ietf.org</a>)<br> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token= <br> >>><br> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav<br> >>> <<a href=3D"mailto:eran@hueniverse.com" target=3D"_blank">e= ran@hueniverse.com</a>> wrote:<br> >>> > This would only work for the client credentials flow (bec= ause you keep the<br> >>> same authorization source). For all other flows you are breaki= ng the<br> >>> authorization boundaries.<br> >>><br> >>> If the requested scope is a subset of the original scope assoc= iated with the<br> >>> refresh token then it should be acceptable, right?<br> >>><br> >>> This would allow a client to request a larger set of scopes, n= eeded for all API<br> >>> calls need for its function, but then get sub-scoped access to= kens, particular<br> >>> to each API. This will prevent an API from receiving a too pow= erful access<br> >>> token. A compromised API could use access tokens to place call= s against<br> >>> other APIs, but not if it is narrowly scoped.<br> >>><br> >>> Marius<br> >>><br> >>> ><br> >>> > What would be useful is to allow asking for more scope. F= or example, when<br> >>> asking for a token (the last step of each flow), also include = a valid token to<br> >>> get a new token with the combined scope (new approval and prev= ious).<br> >>> ><br> >>> > EHL<br> >>> ><br> >>> >> -----Original Message-----<br> >>> >> From: <a href=3D"mailto:oauth-bounces@ietf.org" targe= t=3D"_blank">oauth-bounces@ietf.org</a> [mailto:<a href=3D"mailto:oauth-bou= nces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a>] On<br> >>> >> Behalf Of Dick Hardt<br> >>> >> Sent: Sunday, May 09, 2010 7:19 PM<br> >>> >> To: OAuth WG (<a href=3D"mailto:oauth@ietf.org" targe= t=3D"_blank">oauth@ietf.org</a>)<br> >>> >> Subject: [OAUTH-WG] modifying the scope of an access = token<br> >>> >><br> >>> >> There has been some discussion about modifying the sc= ope of the<br> >>> >> access token during a refresh. Perhaps we can add ano= ther "method" to<br> >>> >> what the AS MAY support that allows modifying the sco= pe of an access<br> >>> >> token. Type of request is "modify" and the scope para= meter is<br> >>> >> required to indicate the new scope required. Suggeste= d copy below:<br> >>> >><br> >>> >> type<br> >>> >>       REQUIRED. The parameter value MU= ST be set to modify<br> >>> >><br> >>> >> client_id<br> >>> >>       REQUIRED. The client identifier = as described in Section 3.4.<br> >>> >><br> >>> >> client_secret<br> >>> >>       REQUIRED if the client was issue= d a secret. The client secret.<br> >>> >><br> >>> >> refresh_token<br> >>> >>       REQUIRED. The refresh token asso= ciated with the access token to<br> >>> >> be refreshed.<br> >>> >><br> >>> >> scope<br> >>> >>       REQUIRED. The new scope of the a= ccess request expressed as a<br> >>> >> list of space-delimited strings. The value of the sco= pe parameter is<br> >>> >> defined by the authorization server. If the value con= tains multiple<br> >>> >> space-delimited strings, their order does not matter,= and each string<br> >>> >> adds additional access range to the requested scope.<= br> >>> >><br> >>> >> secret_type<br> >>> >>       OPTIONAL. The access token secre= t type as described by Section 8.3.<br> >>> >> If omitted, the authorization server will issue a bea= rer token (an<br> >>> >> access token without a matching secret) as described = by Section 8.2.<br> >>> >><br> >>> >> _______________________________________________<br> >>> >> OAuth mailing list<br> >>> >> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">O= Auth@ietf.org</a><br> >>> >> <a href=3D"https://www.ietf.org/mailman/listinfo/oaut= h" target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> > _______________________________________________<br> >>> > OAuth mailing list<br> >>> > <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth= @ietf.org</a><br> >>> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> ><br> >> _______________<br> ><br> > --<br> > --<br> > John Panzer / Google<br> > <a href=3D"mailto:jpanzer@google.com" target=3D"_blank">jpanzer@google= .com</a> / <a href=3D"http://abstractioneer.org/" target=3D"_blank">abstrac= tioneer.org</a> / @jpanzer<br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a>= <br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/oauth</a><br> ><br> </div></div></blockquote></div><br></div> </div></div><br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> <span><ATT00001..txt></span></blockquote></div><br></body></html>= --_000_57407F0C85EC482F88B5CE6E16D24845facebookcom_-- From josephholsten@gmail.com Sun May 16 13:41:45 2010 Return-Path: <josephholsten@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDE43A6922 for <oauth@core3.amsl.com>; Sun, 16 May 2010 13:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 SjbUFMtnG0NQ for <oauth@core3.amsl.com>; Sun, 16 May 2010 13:41:43 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 91F033A6916 for <oauth@ietf.org>; Sun, 16 May 2010 13:41:43 -0700 (PDT) Received: by pxi19 with SMTP id 19so2477579pxi.31 for <oauth@ietf.org>; Sun, 16 May 2010 13:41:30 -0700 (PDT) Received: by 10.114.19.35 with SMTP id 35mr3553951was.25.1274042490249; Sun, 16 May 2010 13:41:30 -0700 (PDT) Received: from [192.168.3.105] (adsl-63-202-13-187.dsl.snfc21.pacbell.net [63.202.13.187]) by mx.google.com with ESMTPS id f11sm42664643wai.11.2010.05.16.13.41.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 May 2010 13:41:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-1--617456317 From: Joseph Holsten <joseph@josephholsten.com> In-Reply-To: <57407F0C-85EC-482F-88B5-CE6E16D24845@facebook.com> Date: Sun, 16 May 2010 15:41:26 -0500 Message-Id: <580AA362-AFC3-4CEF-B356-DD8FCD125D1C@josephholsten.com> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTikbUvqQLCvOAsY9d2CDdg9222xX9zwIEWmNA4RW@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinSQpI4JX6_TVL4ZAI0oYSehKB9vEfQyZafggtM@mail.gmail.com> <AANLkTiktDsVRfYoY2ArgM0VSLkNhMv5oadcX1pHq6j_Q@mail.gmail.com> <AANLkTimbJ8pIVgDLBqag7FjVVrJr0magID52u6T9LUc3@mail.gmail.com> <AANLkTilD6-wxXtwwDyR6E7I271qy2mbIEh7W_e0YRACT@mail.gmail.com> <57407F0C-85EC-482F-88B5-CE6E16D24845@facebook.com> To: Luke Shepard <lshepard@facebook.com> X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] modifying the scope of an access token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 20:41:45 -0000 --Apple-Mail-1--617456317 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Narrowing scope is one of the most common tools of object-capability = systems. It makes it much cheaper to keep deputies from being confused. = Check out Ben Laurie, Mark Miller and Caja. But I sure don't care enough to implement. On May 16, 2010, at 3:01 PM, Luke Shepard wrote: > So, you want to give developers the option to reduce the abilities of = their token after it's already been issued? I have never heard a = developer ask for this feature. >=20 > Beyond the general principle of "least-authority", can you describe a = specific case where this would be useful? Are you talking about = transferring tokens to a third party, or maintaining multiple tokens of = different scopes within the same client? >=20 >=20 >=20 > On May 16, 2010, at 10:34 AM, Dick Hardt wrote: >=20 >> John / David: is this a feature you would want to implement? If no = one wants it, we can drop it. >>=20 >>=20 >> On Mon, May 10, 2010 at 11:52 PM, John Panzer <jpanzer@google.com> = wrote: >> (Note that in my use case, it's actually the client who wants to = dispose of its dangerous full-access token as quickly as possible, = retaining only the least-authority token it needs to continue its = ongoing work. This would be the case even if the token granting service = is handing out tokens like free candy.) >>=20 >> On Mon, May 10, 2010 at 10:43 PM, David Recordon = <recordond@gmail.com> wrote: >> I'm wondering if this could be achieved by adding an optional scope >> parameter to the existing refresh request versus creating a new >> request type. Both because Dick's proposed text requires a refresh >> token and it seems like services worried about this sort of risk = would >> not want to issue long lived access tokens. >>=20 >> --David >>=20 >>=20 >> On Mon, May 10, 2010 at 10:39 PM, John Panzer <jpanzer@google.com> = wrote: >> > Yes; a service that does a one time configuration step, requiring >> > extensive access, followed by an ongoing lower level of access = (say, >> > read-only). Lowering access means it only needs to store low-risk >> > tokens in its data store, limiting exposure (and liability). >> > >> > On Monday, May 10, 2010, Eran Hammer-Lahav <eran@hueniverse.com> = wrote: >> >> Are there actual use cases for this? Either way sounds like it = belongs in an extension. >> >> >> >> EHL >> >> >> >>> -----Original Message----- >> >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> >>> Sent: Monday, May 10, 2010 12:49 PM >> >>> To: Eran Hammer-Lahav >> >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org) >> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token >> >>> >> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav >> >>> <eran@hueniverse.com> wrote: >> >>> > This would only work for the client credentials flow (because = you keep the >> >>> same authorization source). For all other flows you are breaking = the >> >>> authorization boundaries. >> >>> >> >>> If the requested scope is a subset of the original scope = associated with the >> >>> refresh token then it should be acceptable, right? >> >>> >> >>> This would allow a client to request a larger set of scopes, = needed for all API >> >>> calls need for its function, but then get sub-scoped access = tokens, particular >> >>> to each API. This will prevent an API from receiving a too = powerful access >> >>> token. A compromised API could use access tokens to place calls = against >> >>> other APIs, but not if it is narrowly scoped. >> >>> >> >>> Marius >> >>> >> >>> > >> >>> > What would be useful is to allow asking for more scope. For = example, when >> >>> asking for a token (the last step of each flow), also include a = valid token to >> >>> get a new token with the combined scope (new approval and = previous). >> >>> > >> >>> > EHL >> >>> > >> >>> >> -----Original Message----- >> >>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On >> >>> >> Behalf Of Dick Hardt >> >>> >> Sent: Sunday, May 09, 2010 7:19 PM >> >>> >> To: OAuth WG (oauth@ietf.org) >> >>> >> Subject: [OAUTH-WG] modifying the scope of an access token >> >>> >> >> >>> >> There has been some discussion about modifying the scope of = the >> >>> >> access token during a refresh. Perhaps we can add another = "method" to >> >>> >> what the AS MAY support that allows modifying the scope of an = access >> >>> >> token. Type of request is "modify" and the scope parameter is >> >>> >> required to indicate the new scope required. Suggested copy = below: >> >>> >> >> >>> >> type >> >>> >> REQUIRED. The parameter value MUST be set to modify >> >>> >> >> >>> >> client_id >> >>> >> REQUIRED. The client identifier as described in Section = 3.4. >> >>> >> >> >>> >> client_secret >> >>> >> REQUIRED if the client was issued a secret. The client = secret. >> >>> >> >> >>> >> refresh_token >> >>> >> REQUIRED. The refresh token associated with the access = token to >> >>> >> be refreshed. >> >>> >> >> >>> >> scope >> >>> >> REQUIRED. The new scope of the access request expressed = as a >> >>> >> list of space-delimited strings. The value of the scope = parameter is >> >>> >> defined by the authorization server. If the value contains = multiple >> >>> >> space-delimited strings, their order does not matter, and each = string >> >>> >> adds additional access range to the requested scope. >> >>> >> >> >>> >> secret_type >> >>> >> OPTIONAL. The access token secret type as described by = Section 8.3. >> >>> >> If omitted, the authorization server will issue a bearer token = (an >> >>> >> access token without a matching secret) as described by = Section 8.2. >> >>> >> >> >>> >> _______________________________________________ >> >>> >> 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 >> >>> > >> >> _______________ >> > >> > -- >> > -- >> > John Panzer / Google >> > jpanzer@google.com / abstractioneer.org / @jpanzer >> > _______________________________________________ >> > 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 >>=20 >> <ATT00001..txt> >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1--617456317 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><div>Narrowing scope is one of the most common tools of = object-capability systems. It makes it much cheaper to keep deputies = from being confused. Check out Ben Laurie, Mark Miller and = Caja.</div><div><br></div><div>But I sure don't care enough to = implement.</div><br><div><div>On May 16, 2010, at 3:01 PM, Luke Shepard = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space; "><div>So, you want to = give developers the option to reduce the abilities of their token after = it's already been issued? I have never heard a developer ask for this = feature.</div><div><br></div><div>Beyond the general principle of = "least-authority", can you describe a specific case where this would be = useful? Are you talking about transferring tokens to a third party, or = maintaining multiple tokens of different scopes within the same = client?</div><div><br></div><div><br></div><div><br></div><div><div>On = May 16, 2010, at 10:34 AM, Dick Hardt wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite">John / = David: is this a feature you would want to implement? If no one wants = it, we can drop it.<div><br><br><div class=3D"gmail_quote">On Mon, May = 10, 2010 at 11:52 PM, John Panzer <span dir=3D"ltr"><<a = href=3D"mailto:jpanzer@google.com">jpanzer@google.com</a>></span> = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex;">(Note that in my use = case, it's actually the client who wants to dispose of its dangerous = full-access token as quickly as possible, retaining only the = least-authority token it needs to continue its ongoing work.  This = would be the case even if the token granting service is handing out = tokens like free candy.)<div> <div></div><div class=3D"h5"><div> <br><div class=3D"gmail_quote">On Mon, May 10, 2010 at 10:43 PM, David = Recordon <span dir=3D"ltr"><<a href=3D"mailto:recordond@gmail.com" = target=3D"_blank">recordond@gmail.com</a>></span> = wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; = margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; = border-left-width: 1px; border-left-color: rgb(204, 204, 204); = border-left-style: solid; padding-left: 1ex; position: static; z-index: = auto; "> I'm wondering if this could be achieved by adding an optional scope<br> parameter to the existing refresh request versus creating a new<br> request type. Both because Dick's proposed text requires a refresh<br> token and it seems like services worried about this sort of risk = would<br> not want to issue long lived access tokens.<br> <font color=3D"#888888"><br> --David<br> </font><div><div></div><div><br> <br> On Mon, May 10, 2010 at 10:39 PM, John Panzer <<a = href=3D"mailto:jpanzer@google.com" = target=3D"_blank">jpanzer@google.com</a>> wrote:<br> > Yes; a service that does a one time configuration step, = requiring<br> > extensive access, followed by an ongoing lower level of access = (say,<br> > read-only).  Lowering access means it only needs to store = low-risk<br> > tokens in its data store, limiting exposure (and liability).<br> ><br> > On Monday, May 10, 2010, Eran Hammer-Lahav <<a = href=3D"mailto:eran@hueniverse.com" = target=3D"_blank">eran@hueniverse.com</a>> wrote:<br> >> Are there actual use cases for this? Either way sounds like it = belongs in an extension.<br> >><br> >> EHL<br> >><br> >>> -----Original Message-----<br> >>> From: Marius Scurtescu [mailto:<a = href=3D"mailto:mscurtescu@google.com" = target=3D"_blank">mscurtescu@google.com</a>]<br> >>> Sent: Monday, May 10, 2010 12:49 PM<br> >>> To: Eran Hammer-Lahav<br> >>> Cc: Dick Hardt; OAuth WG (<a href=3D"mailto:oauth@ietf.org" = target=3D"_blank">oauth@ietf.org</a>)<br> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access = token<br> >>><br> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav<br> >>> <<a href=3D"mailto:eran@hueniverse.com" = target=3D"_blank">eran@hueniverse.com</a>> wrote:<br> >>> > This would only work for the client credentials flow = (because you keep the<br> >>> same authorization source). For all other flows you are = breaking the<br> >>> authorization boundaries.<br> >>><br> >>> If the requested scope is a subset of the original scope = associated with the<br> >>> refresh token then it should be acceptable, right?<br> >>><br> >>> This would allow a client to request a larger set of = scopes, needed for all API<br> >>> calls need for its function, but then get sub-scoped access = tokens, particular<br> >>> to each API. This will prevent an API from receiving a too = powerful access<br> >>> token. A compromised API could use access tokens to place = calls against<br> >>> other APIs, but not if it is narrowly scoped.<br> >>><br> >>> Marius<br> >>><br> >>> ><br> >>> > What would be useful is to allow asking for more = scope. For example, when<br> >>> asking for a token (the last step of each flow), also = include a valid token to<br> >>> get a new token with the combined scope (new approval and = previous).<br> >>> ><br> >>> > EHL<br> >>> ><br> >>> >> -----Original Message-----<br> >>> >> From: <a href=3D"mailto:oauth-bounces@ietf.org" = target=3D"_blank">oauth-bounces@ietf.org</a> [mailto:<a = href=3D"mailto:oauth-bounces@ietf.org" = target=3D"_blank">oauth-bounces@ietf.org</a>] On<br> >>> >> Behalf Of Dick Hardt<br> >>> >> Sent: Sunday, May 09, 2010 7:19 PM<br> >>> >> To: OAuth WG (<a href=3D"mailto:oauth@ietf.org" = target=3D"_blank">oauth@ietf.org</a>)<br> >>> >> Subject: [OAUTH-WG] modifying the scope of an = access token<br> >>> >><br> >>> >> There has been some discussion about modifying the = scope of the<br> >>> >> access token during a refresh. Perhaps we can add = another "method" to<br> >>> >> what the AS MAY support that allows modifying the = scope of an access<br> >>> >> token. Type of request is "modify" and the scope = parameter is<br> >>> >> required to indicate the new scope required. = Suggested copy below:<br> >>> >><br> >>> >> type<br> >>> >>       REQUIRED. The parameter value = MUST be set to modify<br> >>> >><br> >>> >> client_id<br> >>> >>       REQUIRED. The client = identifier as described in Section 3.4.<br> >>> >><br> >>> >> client_secret<br> >>> >>       REQUIRED if the client was = issued a secret. The client secret.<br> >>> >><br> >>> >> refresh_token<br> >>> >>       REQUIRED. The refresh token = associated with the access token to<br> >>> >> be refreshed.<br> >>> >><br> >>> >> scope<br> >>> >>       REQUIRED. The new scope of = the access request expressed as a<br> >>> >> list of space-delimited strings. The value of the = scope parameter is<br> >>> >> defined by the authorization server. If the value = contains multiple<br> >>> >> space-delimited strings, their order does not = matter, and each string<br> >>> >> adds additional access range to the requested = scope.<br> >>> >><br> >>> >> secret_type<br> >>> >>       OPTIONAL. The access token = secret type as described by Section 8.3.<br> >>> >> If omitted, the authorization server will issue a = bearer token (an<br> >>> >> access token without a matching secret) as = described by Section 8.2.<br> >>> >><br> >>> >> = _______________________________________________<br> >>> >> OAuth mailing list<br> >>> >> <a href=3D"mailto:OAuth@ietf.org" = target=3D"_blank">OAuth@ietf.org</a><br> >>> >> <a = href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> > _______________________________________________<br> >>> > OAuth mailing list<br> >>> > <a href=3D"mailto:OAuth@ietf.org" = target=3D"_blank">OAuth@ietf.org</a><br> >>> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> ><br> >> _______________<br> ><br> > --<br> > --<br> > John Panzer / Google<br> > <a href=3D"mailto:jpanzer@google.com" = target=3D"_blank">jpanzer@google.com</a> / <a = href=3D"http://abstractioneer.org/" = target=3D"_blank">abstractioneer.org</a> / @jpanzer<br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org" = target=3D"_blank">OAuth@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> ><br> </div></div></blockquote></div><br></div> </div></div><br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> = <span><ATT00001..txt></span></blockquote></div><br></div>___________= ____________________________________<br>OAuth mailing list<br><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br>https://www.ietf.org/= mailman/listinfo/oauth<br></blockquote></div><br></body></html>= --Apple-Mail-1--617456317-- From trac@tools.ietf.org Sun May 16 15:47:01 2010 Return-Path: <trac@tools.ietf.org> 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 E03F33A6B3B for <oauth@core3.amsl.com>; Sun, 16 May 2010 15:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 U+A5-i0cQkEx for <oauth@core3.amsl.com>; Sun, 16 May 2010 15:47:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BA6763A6B39 for <oauth@ietf.org>; Sun, 16 May 2010 15:47:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from <trac@tools.ietf.org>) id 1ODmbi-0007jI-5H; Sun, 16 May 2010 15:46:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: eve@xmlgrrl.com, recordond@gmail.com X-Trac-Project: oauth Date: Sun, 16 May 2010 22:46:50 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/6#comment:2 Message-ID: <064.f9cb2b4dee272925dd988e9b25f52417@tools.ietf.org> References: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eve@xmlgrrl.com, recordond@gmail.com, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #6: Make automated self-registration of unique clients possible X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 22:47:02 -0000 #6: Make automated self-registration of unique clients possible -----------------------------+---------------------------------------------- Reporter: eve@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Keywords: -----------------------------+---------------------------------------------- Comment(by eve@…): (I agree the spec is getting pretty long. I wonder if it's possible to do some factoring-out of common text, e.g. regarding common features of flows, to mitigate this. The length is actually making me waver a bit on my previously shared opinion about including all the currently known flows into the core protocol document...) Thanks for pointing to this piece of the OpenID Connect proposal. I tend to think that a whole "discovery" solution would be an appropriate modularity boundary, so maybe this piece of the proposal could be combined with some of the stuff we're having to define in UMA, into a new Discovery 2.0 proposal or something. -- Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/6#comment:2> oauth <http://tools.ietf.org/oauth/> From dick.hardt@gmail.com Sun May 16 15:49:33 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE973A6B41 for <oauth@core3.amsl.com>; Sun, 16 May 2010 15:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=-1.173, BAYES_50=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 EkNmY0CmF5GG for <oauth@core3.amsl.com>; Sun, 16 May 2010 15:49:32 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 335BB3A6B40 for <oauth@ietf.org>; Sun, 16 May 2010 15:49:32 -0700 (PDT) Received: by pxi19 with SMTP id 19so2509005pxi.31 for <oauth@ietf.org>; Sun, 16 May 2010 15:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=lttwFwWR+6/mRN2aKQqnX2h78qxWPD2hSdvAmuXV1yE=; b=vALu4aurqgci4Fcb5imHz6eOr1KoAHVHGuQB+T7uCS6qscECBAqBBbVbL3fKmbgxa8 HInSI2h7j3wbmb6PQPa0tUcs3z4fgfQOnWhejPXI1wIA1+D2mmSQLFds1ns4FwXTvrtU p/SIzkcDIhVSBO3OAgt+bru2sRpkRpPml55Yg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=qQCx7y6OI9Q9fU5BZsQrwiKAlCkF53yNVenxxJ5xBt9uCiWiHAKDPGT/qRIwsFwVfN QyjctRKv0OBiyzVVAkNBlCOOygOet+Y43v9PaMmKUX+9b18TdRoQoivwlM4RHkdzZ0es ag4EVqB3Owzh8S/4nbA0DlNDXo19qRzkPTiQY= Received: by 10.114.23.15 with SMTP id 15mr3617779waw.45.1274050161018; Sun, 16 May 2010 15:49:21 -0700 (PDT) Received: from [10.0.1.8] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id r20sm43526603wam.17.2010.05.16.15.49.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 May 2010 15:49:20 -0700 (PDT) From: Dick Hardt <dick.hardt@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 16 May 2010 15:49:19 -0700 Message-Id: <0D60C162-2060-434C-BEB6-96B53E09ED43@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: [OAUTH-WG] proposed text to remove identifier from token definitions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 22:49:33 -0000 Below is proposed text where a token is referred to as an identifier.=20 Here is the definition of identifier from RFC 4949: $ identifier (I) A data object -- often, a printable, non-blank character string -- that definitively represents a specific identity of a system entity, distinguishing that identity from all others. (Compare: identity.) Many tokens in practice don't fit this definition. Here is suggested new = language: Abstract This specification describes the OAuth 2.0 protocol. OAuth provides a method for making authenticated HTTP requests using a token - a string used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience. access token A token used by the client to make authenticated requests on = behalf of the resource owner. Access tokens may have a matching secret = and are usually opaque to the client. refresh token A token used by the client to replace an expired access token with a new access token without having to involve the resource owner. A refresh token is used when the access token is valid for a shorter time period than the duration of the access grant approved by the resource owner. token A string that represents the authorization granted to a client. = The string may contain the authorization information and be signed, or = the string may be an identifier that is used to retrieve the = authorization information. From dick.hardt@gmail.com Sun May 16 15:53:12 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B164D3A6B3D for <oauth@core3.amsl.com>; Sun, 16 May 2010 15:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_05=-1.11, J_CHICKENPOX_72=0.6] 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 AntlRcv5GGeS for <oauth@core3.amsl.com>; Sun, 16 May 2010 15:53:11 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id E04433A688A for <oauth@ietf.org>; Sun, 16 May 2010 15:53:11 -0700 (PDT) Received: by pxi19 with SMTP id 19so2509993pxi.31 for <oauth@ietf.org>; Sun, 16 May 2010 15:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=m6Ws3wLaV5SXJfpoP2viFnMc675xF4hU9NPCMGL/pxA=; b=K3I9xxTvprbPSHbFS7OAdzaG70bEeBXRMEbaLrVZ/ywTyyI10sdClox/+AK5Vqs3uZ zvkjxcS303HzNtj4dDfJzABfQbVEgWl3NvGr4EDBYe+hnmM6CnWoWSZ3FXCpzp9EubMV JOGc1zW/zF5wn6LXEchs864pkuD/v/CRrw0eM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gyPu7izUx3oTNWtbTVuUYS3CdTkv2ouEG5S6o65VuY/MesLZU8CdsXc9Qs4kh6BYlL acgSXwjjseaitEVJgCEJcoL+VpdHCKe3v3X9VvUvvRF56cGxEWir7btKBzAfX6bz3hSK 8ioW4fCeKiRWVS96KDcduRk4gfR2xMq+KdPKs= Received: by 10.142.122.6 with SMTP id u6mr2807037wfc.183.1274050380462; Sun, 16 May 2010 15:53:00 -0700 (PDT) Received: from [10.0.1.8] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id d16sm43554484wam.12.2010.05.16.15.52.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 May 2010 15:53:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <064.f9cb2b4dee272925dd988e9b25f52417@tools.ietf.org> Date: Sun, 16 May 2010 15:52:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F15DBF6-1607-4248-A74F-3D88FFD88829@gmail.com> References: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@tools.ietf.org> <064.f9cb2b4dee272925dd988e9b25f52417@tools.ietf.org> To: "oauth issue tracker" <trac@tools.ietf.org> X-Mailer: Apple Mail (2.1078) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #6: Make automated self-registration of unique clients possible X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 16 May 2010 22:53:12 -0000 On 2010-05-16, at 3:46 PM, oauth issue tracker wrote: > #6: Make automated self-registration of unique clients possible > = -----------------------------+--------------------------------------------= -- > Reporter: eve@=85 | Owner: =20 > Type: enhancement | Status: new > Priority: major | Milestone: =20 > Component: authentication | Version: =20 > Severity: - | Keywords: =20 > = -----------------------------+--------------------------------------------= -- >=20 > Comment(by eve@=85): >=20 > (I agree the spec is getting pretty long. I wonder if it's possible to = do > some factoring-out of common text, e.g. regarding common features of > flows, to mitigate this. The length is actually making me waver a bit = on > my previously shared opinion about including all the currently known = flows > into the core protocol document...) IMHO: Reading one long document is better than reading two or more = shorter documents that combined are the same size or longer. I think the = current factoring in the document lets someone read only the flows they = need. If need be, we could clarify that in the copy. I had that in WRAP. -- Dick From James.H.Manger@team.telstra.com Sun May 16 17:22:22 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B463A6BD6 for <oauth@core3.amsl.com>; Sun, 16 May 2010 17:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_66=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPrzozxE4hi5 for <oauth@core3.amsl.com>; Sun, 16 May 2010 17:22:21 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 044523A6BC7 for <oauth@ietf.org>; Sun, 16 May 2010 17:21:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,243,1272808800"; d="scan'208";a="3436514" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 17 May 2010 10:21:00 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5984"; a="2039035" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbni.tcif.telstra.com.au with ESMTP; 17 May 2010 10:21:00 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Mon, 17 May 2010 10:21:00 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Mon, 17 May 2010 10:20:58 +1000 Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: Acr1JX9zDm4io8hSRBObfwGiS1GhAAALvS3A Message-ID: <255B9BB34FB7D647A506DC292726F6E112634F5EA3@WSMSG3153V.srv.dir.telstra.com> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com> In-Reply-To: <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 00:22:22 -0000 RGljaywNCg0KPiBKYW1lczogQW4gaW1wb3J0YW50IGNhcGFiaWxpdHkgb2YgdGhlIHJlZnJlc2gg dG9rZW4gaXMgdGhhdCBpdCAqY2FuKiBiZSBhIHNlbGYgY29udGFpbmVkIHRva2VuIGluIHRoYXQg aXMgbm90IGFuIGlkLCBidXQgYSBzaWduZWQgdG9rZW4gdGhhdCBjYW4gYmUgZXhhbWluZWQgYW5k IGFjdGVkIHVwb24gb24gcHJlc2VudGF0aW9uLg0KDQpEZWZpbmluZyByZWZyZXNoX3Rva2VuIGFz IGEgVVJJIGRvZXMgbm90IHByZXZlbnQgaXQgYmVpbmcgYSBzZWxmLWNvbnRhaW5lZCBzaWduZWQg dG9rZW4uDQoNClRoZSBvbmx5IGxpbWl0YXRpb24gaW1wbGllZCBpcyBhIFVSSSBzaXplIGxpbWl0 LiBBIGZldyBLQiwgaG93ZXZlciwgaXMgbm90IHRoYXQgb25lcm91cyBhIGxpbWl0IC0tIGl0IGlz IHN1ZmZpY2llbnQgdG8gaG9sZCBhIDQwOTYtYml0IFJTQSBzaWduYXR1cmUgd2l0aCBhIGNvdXBs ZSBvZiBLQiBvdmVyIGZvciBwZXJtaXNzaW9ucyBldGMuKS4NCg0KDQotLQ0KSmFtZXMgTWFuZ2Vy IA0KDQoNCg0KT24gVGh1LCBNYXkgMTMsIDIwMTAgYXQgNzoxMCBBTSwgTWFuZ2VyLCBKYW1lcyBI IDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPiB3cm90ZToNClRvcnN0ZW4sDQoNCj4g V2hhdCBhYm91dCByZWZyZXNoIHRva2VuIHJldm9jYXRpb24vZGVsZXRpb24/DQpIVFRQIGFscmVh ZHkgaGFzIGEgbWV0aG9kIHRvIGRvIHRoaXM6IERFTEVURQ0KSXQganVzdCBuZWVkcyBlYWNoIHRv a2VuIHRvIGhhdmUgYSBVUkkuDQoNClRva2VucyAoYWxtb3N0KSBhbHJlYWR5IGhhdmUgVVJJcyAt LSBpdHMganVzdCBub3QgaW1tZWRpYXRlbHkgb2J2aW91cyBiZWNhdXNlIHRoZSBVUkkgaGFzIHRv IGJlIGJ1aWx0IGZyb20gYSBjb21tb24gdG9rZW4gZW5kcG9pbnQgYW5kIGEgcmVmcmVzaF90b2tl bi4NCg0KSSB0aGluayBpdCB3b3VsZCBpbXByb3ZlIHRoZSBzcGVjIGlmIHJlZnJlc2hfdG9rZW4g d2FzIHJlbmFtZWQgdG8sIHNheSwgdG9rZW5faWQ7IGFuZCBpdHMgdmFsdWUgZGVmaW5lZCBhcyBh IFVSSSAod2hpY2ggY2FuIGJlIGEgcmVsYXRpdmUgVVJJIHNvIHRoZSBzdHJpbmcgbWF5IG5vdCBu ZWVkIHRvIGNoYW5nZSBhdCBhbGwpLg0KDQpUbyByZWZyZXNoIGEgdG9rZW4geW91IFBPU1QgdG8g dGhlIHRva2VuJ3MgVVJJLg0KVG8gZGVsZXRlIGEgdG9rZW4geW91IHNlbmQgYSBERUxFVEUgcmVx dWVzdCB0byB0aGUgdG9rZW4ncyBVUkkuDQoNCkl0IGRvZXNuJ3QgY2F1c2UgbWFqb3IgY2hhbmdl cywgYnV0IHRoZXJlIGFyZSBzb21lIGJlbmVmaXRzLg0KSXQgaXMgYSBtb3JlIHdlYi1zdHlsZSBk ZXNpZ24uDQpJdCBsZWF2ZXMgb25seSAxIHR5cGUgb2YgdG9rZW4gaW4gdGhlIHNwZWMgLS0gYW4g YWNjZXNzIHRva2VuIC0tIHdoaWNoIHNpbXBsaWZpZXMgdGhlIHRleHQgYW5kIGFpZHMgdW5kZXJz dGFuZGluZy4NClRoZXJlIGFyZSBubyBhcmd1bWVudHMgYWJvdXQgbGVuZ3RoLCBhbGxvd2VkIGNo YXJzIGV0YyBiZWNhdXNlIGl0IGlzIGEgVVJJIC0tIGEgd2VsbC1rbm93biB0eXBlLCBvZnRlbiB3 aXRoIG5hdGl2ZSBzdXBwb3J0Lg0KSXRzIG9idmlvdXMgaG93IHRvIGRlbGV0ZSB0aGUgdG9rZW4g YXMgdGhlcmUgaXMgYSBzdGFuZGFyZCBIVFRQIG1ldGhvZCBERUxFVEUgdG8gYXBwbHkgdG8gdGhl IHRva2VuIFVSSS4NCg0KSWYgYSBwYXJ0aWN1bGFyIHNlcnZpY2Ugc3VwcG9ydGVkIGFuIGFkZGl0 aW9uYWwgd2F5IHRvIGRlbGV0ZSBpdGVtcyBpbiBpdHMgQVBJIChlZyBQT1NUIHdpdGggYSBtZXRo b2Q9ZGVsZXRlIHF1ZXJ5IHBhcmFtZXRlcikgdGhhdCBjb3VsZCBhcHBseSB0byB0aGUgT0F1dGgg cGFydCBhcyB3ZWxsLg0KDQo= From dick.hardt@gmail.com Sun May 16 17:27:02 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6CD3A6BBE for <oauth@core3.amsl.com>; Sun, 16 May 2010 17:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_40=-0.185] 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 c0hwDDY4lo-T for <oauth@core3.amsl.com>; Sun, 16 May 2010 17:27:02 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 0A1A03A682E for <oauth@ietf.org>; Sun, 16 May 2010 17:27:01 -0700 (PDT) Received: by pvg11 with SMTP id 11so1493704pvg.31 for <oauth@ietf.org>; Sun, 16 May 2010 17:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Zgspe4TgQrNN9OA2dNMhy3IaqyMlmX547p3aclX6gC4=; b=ZwMrH7A5s2XJAomPpgBm03uW/9az/zOmjOLIg4/cZ2RFt9QsLFq6lIrLWYKnqMx0PY UOECvMQ7gEahM+tK8CZvQHEws+bzhmkCfDUDkfEFyXJ3thl2eyBYz+mWH2pqoR2qAzTR 5wq7sHgkJfOZ6CvaKuFGrQnR/o5QQXTbebWEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=F2yZR+PgNzybkHLns29xnk67JMP07ncDtxuwWe2EY2LYrf0+raYh1Mw8TwlIPhmPQ0 47V19lN3jjRiizxifjSP5NSj1o3VVgi/XuCRV/lLmxSvjPD5oz0zo9hd+xICpF52kkUM dD9/wb67Uz2+NfvMf7kafl5NFCyfY4YMFUUhc= Received: by 10.115.133.17 with SMTP id k17mr3731549wan.24.1274056010710; Sun, 16 May 2010 17:26:50 -0700 (PDT) Received: from [10.0.1.8] (c-67-180-195-167.hsd1.ca.comcast.net [67.180.195.167]) by mx.google.com with ESMTPS id c14sm44230446waa.1.2010.05.16.17.26.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 May 2010 17:26:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112634F5EA3@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 16 May 2010 17:26:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7934BAC5-7FA8-48E7-82A5-A4A17DE9146E@gmail.com> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634F5EA3@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 00:27:02 -0000 On 2010-05-16, at 5:20 PM, Manger, James H wrote: > Dick, >=20 >> James: An important capability of the refresh token is that it *can* = be a self contained token in that is not an id, but a signed token that = can be examined and acted upon on presentation. >=20 > Defining refresh_token as a URI does not prevent it being a = self-contained signed token. >=20 > The only limitation implied is a URI size limit. A few KB, however, is = not that onerous a limit -- it is sufficient to hold a 4096-bit RSA = signature with a couple of KB over for permissions etc.). Agreed, a token could be a self contained token. A design objective was = allowing existing systems to use existing tokens. -- Dick From James.H.Manger@team.telstra.com Sun May 16 17:39:29 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D3E3A6A97 for <oauth@core3.amsl.com>; Sun, 16 May 2010 17:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.808 X-Spam-Level: * X-Spam-Status: No, score=1.808 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_56=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5TdgoX77RIY for <oauth@core3.amsl.com>; Sun, 16 May 2010 17:39:28 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id A38573A68E3 for <oauth@ietf.org>; Sun, 16 May 2010 17:39:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,243,1272808800"; d="scan'208";a="2658425" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 17 May 2010 10:39:18 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5984"; a="2045734" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccni.tcif.telstra.com.au with ESMTP; 17 May 2010 10:39:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Mon, 17 May 2010 10:39:18 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Mon, 17 May 2010 10:39:14 +1000 Thread-Topic: [OAUTH-WG] Separate HTTP and HTTPS tokens Thread-Index: Acr1J9ZuzTyTGcqZTWWBbVx0JBPasAALxjDA Message-ID: <255B9BB34FB7D647A506DC292726F6E112634F5F52@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112634F5377@WSMSG3153V.srv.dir.telstra.com> <AANLkTil3phNYPp_vkEDwlov3zAU-NHrw72OpnaK26ixo@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634F5584@WSMSG3153V.srv.dir.telstra.com> <AANLkTineTf6euI5U7RGgfru7rfNL7N-6iHGgwR34rvs-@mail.gmail.com> In-Reply-To: <AANLkTineTf6euI5U7RGgfru7rfNL7N-6iHGgwR34rvs-@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Separate HTTP and HTTPS tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 00:39:29 -0000 RGljaywNCg0KPiBOb3RlIHRoYXQgeW91IGNvdWxkIGFjY29tcGxpc2ggdGhpcyBmdW5jdGlvbmFs aXR5IHdpdGggdGhlICdtb2RpZnknIHByb3Bvc2FsIEkgcG9zdGVkIHdoZXJlIGFuIGFjY2VzcyB0 b2tlbiB3aXRoIGEgZGlmZmVyZW50IHNjb3BlIGNvdWxkIGJlIHJlcXVlc3RlZCBjb3VsZCBiZSB1 c2VkIHRvIGFjcXVpcmUgYSBzZWNvbmQgdG9rZW4gdGhhdCBoYXMgbGVzc8KgcHJpdmlsZWdlc8Kg YW5kIHdvdWxkIGJlIGFwcHJvcHJpYXRlIG92ZXIgSFRUUC4NCj4NCj4gVG8gcmVjYXAsICdtb2Rp ZnknIGlzIGxpa2UgJ3JlZnJlc2gnIGV4Y2VwdCB0aGUgbmV3IHNjb3BlIGlzIGFsc28gcGFzc2Vk IGFzIGEgcGFyYW1ldGVyLg0KDQoNClRoZSAnbW9kaWZ5JyBwcm9wb3NhbCByZXF1aXJlcyB0aGUg Y2xpZW50IGFwcCB0byB1bmRlcnN0YW5kIHRoZSBzZXJ2ZXItc3BlY2lmaWMgc2NvcGUgdmFsdWVz Lg0KDQpPdGhlcndpc2UgYSBnZW5lcmljIGNsaWVudCBhcHAgd291bGQsIHNheToNCjEuIGdldCBh IHRva2VuIGZvciBIVFRQUyByZXF1ZXN0czsNCjIuIG1ha2UgYW4gSFRUUCByZXF1ZXN0ICh3aXRo b3V0IHRoZSB0b2tlbik7DQozLiByZWNlaXZlIDQwMSBXV1ctQXV0aC46IFRva2VuIC4uLjsNCjQu IGhhdmUgdG8gZGVjaWRlIGlmIHRoZSBleGlzdGluZyB0b2tlbiBjYW4gYmUgbW9kaWZpZWQsIG9y IG1vcmUgdXNlci1jb25zZW50IGlzIHJlcXVpcmVkLg0KNS4gbWFrZSBhICdtb2RpZnknIHJlcXVl c3Q7DQo2LiByZS10cnkgdGhlIEhUVFAgcmVxdWVzdCAod2l0aCB0aGUgbmV3IHRva2VuKS4NCg0K VGhhdCBpcyBwb3NzaWJsZSAtLSBpZiB3ZSBkZWZpbmUgbW9yZSBmbGFncyBhbmQgbG9naWMgZm9y IE9BdXRoJ3MgV1dXLUF1dGggcmVzcG9uc2UgaGVhZGVyIChmb3Igc3RlcCA0IGFib3ZlKS4NClJl dHVybmluZyBhbiBhcnJheSBvZiB0b2tlbnMgaXMgYmV0dGVyIGluIGNvbW1vbiBzaXR1YXRpb25z IC0tIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgdGhlICdtb2RpZnknIHByb3Bvc2FsIGlz IGFsc28gYWRvcHRlZC4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCg0KT24gVGh1LCBNYXkgMTMs IDIwMTAgYXQgOTozOCBQTSwgTWFuZ2VyLCBKYW1lcyBIIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tPiB3cm90ZToNCkRhdmlkLA0KDQouLi4NCkV2ZW4gaWYgeW91IG9ubHkgc3VwcG9y dCBzaWduZWQgcmVxdWVzdHMgb3ZlciBIVFRQIHlvdSBwcm9iYWJseSBzdGlsbCB3YW50IDIgdG9r ZW5zOiBhIGJlYXJlciB0b2tlbiBmb3IgSFRUUFM7IGEgdG9rZW4rc2VjcmV0IGZvciBIVFRQLg0K DQpbDQrCoHsgImFjY2Vzc190b2tlbiI6IklkODdkNmREZCIsICJzaXRlcyI6WyJodHRwczovL2Fw aS5leGFtcGxlLm9yZyJdIH0sDQrCoHsgImFjY2Vzc190b2tlbiI6IlNsQVYzMmhrS0ciLCAic2l0 ZXMiOlsiaHR0cDovL2FwaS5leGFtcGxlLm9yZyJdLA0KwqAgwqAgwqAgYWNjZXNzX3Rva2VuX3Nl Y3JldD0iMzg2NTg0NjMzNTM0IiB9DQpdDQoNCg== From gffletch@aol.com Sun May 16 17:57:55 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3793A6864 for <oauth@core3.amsl.com>; Sun, 16 May 2010 17:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 7pcbfB9FH5KM for <oauth@core3.amsl.com>; Sun, 16 May 2010 17:57:53 -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 520763A67F6 for <oauth@ietf.org>; Sun, 16 May 2010 17:57:52 -0700 (PDT) Received: from mtaout-da05.r1000.mx.aol.com (mtaout-da05.r1000.mx.aol.com [172.29.51.133]) by imr-ma01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o4H0vSmO025080; Sun, 16 May 2010 20:57:28 -0400 Received: from palantir.local (unknown [10.172.32.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 66F37E00008F; Sun, 16 May 2010 20:57:27 -0400 (EDT) Message-ID: <4BF09475.1040408@aol.com> Date: Sun, 16 May 2010 20:57:25 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> References: <6EAD60BF-4C6B-4F0A-8C1A-13DD3DD2B21E@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E3A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTikbUvqQLCvOAsY9d2CDdg9222xX9zwIEWmNA4RW@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB4712E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinSQpI4JX6_TVL4ZAI0oYSehKB9vEfQyZafggtM@mail.gmail.com> <AANLkTiktDsVRfYoY2ArgM0VSLkNhMv5oadcX1pHq6j_Q@mail.gmail.com> <AANLkTimbJ8pIVgDLBqag7FjVVrJr0magID52u6T9LUc3@mail.gmail.com> <AANLkTilD6-wxXtwwDyR6E7I271qy2mbIEh7W_e0YRACT@mail.gmail.com> In-Reply-To: <AANLkTilD6-wxXtwwDyR6E7I271qy2mbIEh7W_e0YRACT@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------090202090807000006000309" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:457925056:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33854bf094773f9d X-AOL-IP: 10.172.32.85 Subject: Re: [OAUTH-WG] modifying the scope of an access token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 00:57:55 -0000 This is a multi-part message in MIME format. --------------090202090807000006000309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm definitely interesting in the ability to change the scope "dynamically", replacing an existing access token with a new access token. We use something very similar today in the AOL service APIs. One question in regards to your proposal. If the client asks for a scope that the user hasn't approved... how would that flow work (using either the modify endpoint or the existing token endpoint)? It seems like the client needs to send the user back to the authorize endpoint with the new scope in order for the user to give consent. It would also be good if the host could identify which scope is needed when the client performs some action that is not authorized. Thanks, George On 5/16/10 1:34 PM, Dick Hardt wrote: > John / David: is this a feature you would want to implement? If no one > wants it, we can drop it. > > > On Mon, May 10, 2010 at 11:52 PM, John Panzer <jpanzer@google.com > <mailto:jpanzer@google.com>> wrote: > > (Note that in my use case, it's actually the client who wants to > dispose of its dangerous full-access token as quickly as possible, > retaining only the least-authority token it needs to continue its > ongoing work. This would be the case even if the token granting > service is handing out tokens like free candy.) > > On Mon, May 10, 2010 at 10:43 PM, David Recordon > <recordond@gmail.com <mailto:recordond@gmail.com>> wrote: > > I'm wondering if this could be achieved by adding an optional > scope > parameter to the existing refresh request versus creating a new > request type. Both because Dick's proposed text requires a refresh > token and it seems like services worried about this sort of > risk would > not want to issue long lived access tokens. > > --David > > > On Mon, May 10, 2010 at 10:39 PM, John Panzer > <jpanzer@google.com <mailto:jpanzer@google.com>> wrote: > > Yes; a service that does a one time configuration step, > requiring > > extensive access, followed by an ongoing lower level of > access (say, > > read-only). Lowering access means it only needs to store > low-risk > > tokens in its data store, limiting exposure (and liability). > > > > On Monday, May 10, 2010, Eran Hammer-Lahav > <eran@hueniverse.com <mailto:eran@hueniverse.com>> wrote: > >> Are there actual use cases for this? Either way sounds like > it belongs in an extension. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: Marius Scurtescu [mailto:mscurtescu@google.com > <mailto:mscurtescu@google.com>] > >>> Sent: Monday, May 10, 2010 12:49 PM > >>> To: Eran Hammer-Lahav > >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org > <mailto:oauth@ietf.org>) > >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token > >>> > >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav > >>> <eran@hueniverse.com <mailto:eran@hueniverse.com>> wrote: > >>> > This would only work for the client credentials flow > (because you keep the > >>> same authorization source). For all other flows you are > breaking the > >>> authorization boundaries. > >>> > >>> If the requested scope is a subset of the original scope > associated with the > >>> refresh token then it should be acceptable, right? > >>> > >>> This would allow a client to request a larger set of > scopes, needed for all API > >>> calls need for its function, but then get sub-scoped > access tokens, particular > >>> to each API. This will prevent an API from receiving a too > powerful access > >>> token. A compromised API could use access tokens to place > calls against > >>> other APIs, but not if it is narrowly scoped. > >>> > >>> Marius > >>> > >>> > > >>> > What would be useful is to allow asking for more scope. > For example, when > >>> asking for a token (the last step of each flow), also > include a valid token to > >>> get a new token with the combined scope (new approval and > previous). > >>> > > >>> > EHL > >>> > > >>> >> -----Original Message----- > >>> >> From: oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org > <mailto:oauth-bounces@ietf.org>] On > >>> >> Behalf Of Dick Hardt > >>> >> Sent: Sunday, May 09, 2010 7:19 PM > >>> >> To: OAuth WG (oauth@ietf.org <mailto:oauth@ietf.org>) > >>> >> Subject: [OAUTH-WG] modifying the scope of an access token > >>> >> > >>> >> There has been some discussion about modifying the > scope of the > >>> >> access token during a refresh. Perhaps we can add > another "method" to > >>> >> what the AS MAY support that allows modifying the scope > of an access > >>> >> token. Type of request is "modify" and the scope > parameter is > >>> >> required to indicate the new scope required. Suggested > copy below: > >>> >> > >>> >> type > >>> >> REQUIRED. The parameter value MUST be set to modify > >>> >> > >>> >> client_id > >>> >> REQUIRED. The client identifier as described in > Section 3.4. > >>> >> > >>> >> client_secret > >>> >> REQUIRED if the client was issued a secret. The > client secret. > >>> >> > >>> >> refresh_token > >>> >> REQUIRED. The refresh token associated with the > access token to > >>> >> be refreshed. > >>> >> > >>> >> scope > >>> >> REQUIRED. The new scope of the access request > expressed as a > >>> >> list of space-delimited strings. The value of the scope > parameter is > >>> >> defined by the authorization server. If the value > contains multiple > >>> >> space-delimited strings, their order does not matter, > and each string > >>> >> adds additional access range to the requested scope. > >>> >> > >>> >> secret_type > >>> >> OPTIONAL. The access token secret type as > described by Section 8.3. > >>> >> If omitted, the authorization server will issue a > bearer token (an > >>> >> access token without a matching secret) as described by > Section 8.2. > >>> >> > >>> >> _______________________________________________ > >>> >> OAuth mailing list > >>> >> OAuth@ietf.org <mailto:OAuth@ietf.org> > >>> >> https://www.ietf.org/mailman/listinfo/oauth > >>> > _______________________________________________ > >>> > OAuth mailing list > >>> > OAuth@ietf.org <mailto:OAuth@ietf.org> > >>> > https://www.ietf.org/mailman/listinfo/oauth > >>> > > >> _______________ > > > > -- > > -- > > John Panzer / Google > > jpanzer@google.com <mailto:jpanzer@google.com> / > abstractioneer.org <http://abstractioneer.org> / @jpanzer > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090202090807000006000309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Helvetica, Arial, sans-serif">I'm definitely interesting in the ability to change the scope "dynamically", replacing an existing access token with a new access token. We use something very similar today in the AOL service APIs. <br> <br> One question in regards to your proposal. If the client asks for a scope that the user hasn't approved... how would that flow work (using either the modify endpoint or the existing token endpoint)? It seems like the client needs to send the user back to the authorize endpoint with the new scope in order for the user to give consent.<br> <br> It would also be good if the host could identify which scope is needed when the client performs some action that is not authorized.<br> <br> Thanks,<br> George<br> </font><br> On 5/16/10 1:34 PM, Dick Hardt wrote: <blockquote cite="mid:AANLkTilD6-wxXtwwDyR6E7I271qy2mbIEh7W_e0YRACT@mail.gmail.com" type="cite">John / David: is this a feature you would want to implement? If no one wants it, we can drop it. <div><br> <br> <div class="gmail_quote">On Mon, May 10, 2010 at 11:52 PM, John Panzer <span dir="ltr"><<a moz-do-not-send="true" href="mailto:jpanzer@google.com">jpanzer@google.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(Note that in my use case, it's actually the client who wants to dispose of its dangerous full-access token as quickly as possible, retaining only the least-authority token it needs to continue its ongoing work.  This would be the case even if the token granting service is handing out tokens like free candy.) <div> <div class="h5"> <div><br> <div class="gmail_quote">On Mon, May 10, 2010 at 10:43 PM, David Recordon <span dir="ltr"><<a moz-do-not-send="true" href="mailto:recordond@gmail.com" target="_blank">recordond@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm wondering if this could be achieved by adding an optional scope<br> parameter to the existing refresh request versus creating a new<br> request type. Both because Dick's proposed text requires a refresh<br> token and it seems like services worried about this sort of risk would<br> not want to issue long lived access tokens.<br> <font color="#888888"><br> --David<br> </font> <div> <div><br> <br> On Mon, May 10, 2010 at 10:39 PM, John Panzer <<a moz-do-not-send="true" href="mailto:jpanzer@google.com" target="_blank">jpanzer@google.com</a>> wrote:<br> > Yes; a service that does a one time configuration step, requiring<br> > extensive access, followed by an ongoing lower level of access (say,<br> > read-only).  Lowering access means it only needs to store low-risk<br> > tokens in its data store, limiting exposure (and liability).<br> ><br> > On Monday, May 10, 2010, Eran Hammer-Lahav <<a moz-do-not-send="true" href="mailto:eran@hueniverse.com" target="_blank">eran@hueniverse.com</a>> wrote:<br> >> Are there actual use cases for this? Either way sounds like it belongs in an extension.<br> >><br> >> EHL<br> >><br> >>> -----Original Message-----<br> >>> From: Marius Scurtescu [mailto:<a moz-do-not-send="true" href="mailto:mscurtescu@google.com" target="_blank">mscurtescu@google.com</a>]<br> >>> Sent: Monday, May 10, 2010 12:49 PM<br> >>> To: Eran Hammer-Lahav<br> >>> Cc: Dick Hardt; OAuth WG (<a moz-do-not-send="true" href="mailto:oauth@ietf.org" target="_blank">oauth@ietf.org</a>)<br> >>> Subject: Re: [OAUTH-WG] modifying the scope of an access token<br> >>><br> >>> On Sun, May 9, 2010 at 10:17 PM, Eran Hammer-Lahav<br> >>> <<a moz-do-not-send="true" href="mailto:eran@hueniverse.com" target="_blank">eran@hueniverse.com</a>> wrote:<br> >>> > This would only work for the client credentials flow (because you keep the<br> >>> same authorization source). For all other flows you are breaking the<br> >>> authorization boundaries.<br> >>><br> >>> If the requested scope is a subset of the original scope associated with the<br> >>> refresh token then it should be acceptable, right?<br> >>><br> >>> This would allow a client to request a larger set of scopes, needed for all API<br> >>> calls need for its function, but then get sub-scoped access tokens, particular<br> >>> to each API. This will prevent an API from receiving a too powerful access<br> >>> token. A compromised API could use access tokens to place calls against<br> >>> other APIs, but not if it is narrowly scoped.<br> >>><br> >>> Marius<br> >>><br> >>> ><br> >>> > What would be useful is to allow asking for more scope. For example, when<br> >>> asking for a token (the last step of each flow), also include a valid token to<br> >>> get a new token with the combined scope (new approval and previous).<br> >>> ><br> >>> > EHL<br> >>> ><br> >>> >> -----Original Message-----<br> >>> >> From: <a moz-do-not-send="true" href="mailto:oauth-bounces@ietf.org" target="_blank">oauth-bounces@ietf.org</a> [mailto:<a moz-do-not-send="true" href="mailto:oauth-bounces@ietf.org" target="_blank">oauth-bounces@ietf.org</a>] On<br> >>> >> Behalf Of Dick Hardt<br> >>> >> Sent: Sunday, May 09, 2010 7:19 PM<br> >>> >> To: OAuth WG (<a moz-do-not-send="true" href="mailto:oauth@ietf.org" target="_blank">oauth@ietf.org</a>)<br> >>> >> Subject: [OAUTH-WG] modifying the scope of an access token<br> >>> >><br> >>> >> There has been some discussion about modifying the scope of the<br> >>> >> access token during a refresh. Perhaps we can add another "method" to<br> >>> >> what the AS MAY support that allows modifying the scope of an access<br> >>> >> token. Type of request is "modify" and the scope parameter is<br> >>> >> required to indicate the new scope required. Suggested copy below:<br> >>> >><br> >>> >> type<br> >>> >>       REQUIRED. The parameter value MUST be set to modify<br> >>> >><br> >>> >> client_id<br> >>> >>       REQUIRED. The client identifier as described in Section 3.4.<br> >>> >><br> >>> >> client_secret<br> >>> >>       REQUIRED if the client was issued a secret. The client secret.<br> >>> >><br> >>> >> refresh_token<br> >>> >>       REQUIRED. The refresh token associated with the access token to<br> >>> >> be refreshed.<br> >>> >><br> >>> >> scope<br> >>> >>       REQUIRED. The new scope of the access request expressed as a<br> >>> >> list of space-delimited strings. The value of the scope parameter is<br> >>> >> defined by the authorization server. If the value contains multiple<br> >>> >> space-delimited strings, their order does not matter, and each string<br> >>> >> adds additional access range to the requested scope.<br> >>> >><br> >>> >> secret_type<br> >>> >>       OPTIONAL. The access token secret type as described by Section 8.3.<br> >>> >> If omitted, the authorization server will issue a bearer token (an<br> >>> >> access token without a matching secret) as described by Section 8.2.<br> >>> >><br> >>> >> _______________________________________________<br> >>> >> OAuth mailing list<br> >>> >> <a moz-do-not-send="true" href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br> >>> >> <a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> > _______________________________________________<br> >>> > OAuth mailing list<br> >>> > <a moz-do-not-send="true" href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br> >>> > <a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >>> ><br> >> _______________<br> ><br> > --<br> > --<br> > John Panzer / Google<br> > <a moz-do-not-send="true" href="mailto:jpanzer@google.com" target="_blank">jpanzer@google.com</a> / <a moz-do-not-send="true" href="http://abstractioneer.org" target="_blank">abstractioneer.org</a> / @jpanzer<br> > _______________________________________________<br> > OAuth mailing list<br> > <a moz-do-not-send="true" href="mailto:OAuth@ietf.org" target="_blank">OAuth@ietf.org</a><br> > <a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> ><br> </div> </div> </blockquote> </div> <br> </div> </div> </div> <br> _______________________________________________<br> OAuth mailing list<br> <a moz-do-not-send="true" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth" target="_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> <br> </blockquote> </div> <br> </div> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </body> </html> --------------090202090807000006000309-- From James.H.Manger@team.telstra.com Sun May 16 18:24:41 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9735A3A6C15 for <oauth@core3.amsl.com>; Sun, 16 May 2010 18:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.128 X-Spam-Level: ** X-Spam-Status: No, score=2.128 tagged_above=-999 required=5 tests=[AWL=-0.795, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQUaQgUK49vh for <oauth@core3.amsl.com>; Sun, 16 May 2010 18:24:40 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id D447C3A6C30 for <oauth@ietf.org>; Sun, 16 May 2010 18:23:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,243,1272808800"; d="scan'208";a="2666600" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 17 May 2010 11:22:56 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5984"; a="1982903" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbvi.tcif.telstra.com.au with ESMTP; 17 May 2010 11:22:57 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Mon, 17 May 2010 11:22:56 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Mon, 17 May 2010 11:22:55 +1000 Thread-Topic: [OAUTH-WG] Spec text for "sites" field Thread-Index: Acr1KcVZmUiLNK9rSRGaip3R/rhBCAAL6CuA Message-ID: <255B9BB34FB7D647A506DC292726F6E1126360FA91@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112634F5B35@WSMSG3153V.srv.dir.telstra.com> <AANLkTimEA62XtY6LqkICqlvNYPJlDT42U6dMxuhP52U2@mail.gmail.com> In-Reply-To: <AANLkTimEA62XtY6LqkICqlvNYPJlDT42U6dMxuhP52U2@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Spec text for "sites" field X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 01:24:41 -0000 RGljaywNCg0KPiBPbmUgd2F5IHRvIGRlYWwgd2l0aCB0aGUgc2VjdXJpdHkgaXNzdWVzIG9mIGEg YmVhcmVyIHRva2VuIGlzIHRvIHNpZ25pbmcgd2l0aCBhIHByaXZhdGUga2V5IGJlbG9uZ2luZyB0 byB0aGUgY2xpZW50IHdoaWNoIHByZXZlbnRzIHJldXNlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYnkg YW4gdW5zY3J1cHVsb3VzIFBSIGFzIHRoZSBzaWduZWQgcmVxdWVzdCB3aWxsIGJlIGJvdW5kIHRv IHRoYXQgUFIuDQoNClRoaXMgaXMgbm8gbG9uZ2VyIGEgYmVhcmVyIHRva2VuLiBJdCBpcyBhIHRv a2VuIGJvdW5kIHRvIGEgcHVibGljIGtleSAoZWcgbGlrZSBhbiBYLjUwOSBjZXJ0aWZpY2F0ZSwg b3IgKG1vcmUgbGlrZWx5KSBhIFNBTUwgYXNzZXJ0aW9uIHdpdGggPFN1YmplY3RDb25maXJtYXRp b24+Li4uaG9sZGVyLW9mLWtleTwvLi4+KS4NCg0KSSBjYW4gc2VlIHRoYXQgc3VjaCBub24tYmVh cmVyIHRva2VucyBkb24ndCBuZWNlc3NhcmlseSBuZWVkIGEgInNpdGVzIiBmaWVsZCB0byBlbnN1 cmUgdGhlaXIgc2VjdXJpdHkuICJzaXRlcyIgaXMgcmVxdWlyZWQgdG8ga2VlcCBiZWFyZXIgdG9r ZW5zIHNlY3VyZS4gSGVuY2UsIHRoZSB0b2tlbiByZXNwb25zZSBuZWVkcyB0byB0ZWxsIHRoZSBj bGllbnQgYSBiaXQgbW9yZSBhYm91dCB0aGUgbmF0dXJlIG9mIHRoZSB0b2tlbi4NCg0KDQo+IFRo ZSBwcm9wb3NhbCBiZWxvdyBkb2VzIG5vdCBwcmVjbHVkZSB0aGlzIGNhcGFiaWxpdHkgYXMgd3Jp dHRlbiBhcyB0aGUgc2l0ZXMgcGFyYW1ldGVyIGlzIG9wdGlvbmFsLCBzbyBJIGFtIG5vdCBzdWdn ZXN0aW5nIGEgY2hhbmdlLCBidXQgYW0gcG9pbnRpbmcgb3V0IHRoZSBjYXBhYmlsaXR5Lg0KDQpU aGUgInNpdGVzIiBwYXJhbWV0ZXIgRE9FUyBwcmVjbHVkZSB0aGlzIGNhcGFiaWxpdHkuIEl0IHNh eXMgIk9QVElPTkFMIiwgYnV0IHRoaXMgYWN0dWFsbHkgbWVhbnMgImEgZGVmYXVsdCB2YWx1ZSBp cyBkZWZpbmVkIi4gVGhlIGRlZmF1bHQgaXMgdGhhdCB0aGUgdG9rZW4gY2FuIG9ubHkgYmUgdXNl ZCBhdCB0aGUgc2l0ZSB0aGF0IGlzc3VlZCBpdCwgd2hpY2ggaXMgbm90IHdoYXQgeW91IHdhbnQu DQoNClN1Z2dlc3RlZCBzb2x1dGlvbjogZGVmaW5lIGEgc3BlY2lhbCBzdHJpbmcgIioiIHRoYXQs IHdoZW4gcHJlc2VudCBpbiB0aGUgInNpdGVzIiBhcnJheSwgbWVhbnMgdGhlIHRva2VuIGNhbiBi ZSB1c2VkIGFueXdoZXJlIHdpdGhvdXQgY29tcHJvbWlzaW5nIGl0cyBzZWN1cml0eSAoZWcgInNp dGVzIjpbIioiXSkuIA0KDQpBbHRlcm5hdGl2ZSAyOiBzZXQgInNpdGVzIjpudWxsIHdoZW4gYSB0 b2tlbiBjYW4gYmUgdXNlZCBhbnl3aGVyZS4NCkFsdGVybmF0aXZlIDM6IGRvbid0IGRlZmluZSBh IGRlZmF1bHQ7IGFic2VuY2Ugb2YgInNpdGVzIiBtZWFucyB0aGUgdG9rZW4gY2FuIGJlIHVzZWQg YW55d2hlcmU7ICJzaXRlcyIgaXMgcmVxdWlyZWQgZXZlbiBpZiB0aGUgdG9rZW4gY2FuIG9ubHkg YmUgdXNlZCBhdCB0aGUgc2l0ZSB0aGF0IGlzc3VlZCBpdCAoZWcgRmFjZWJvb2sgbmVlZHMgdG8g YWRkICJzaXRlcyI6WyJodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbSJdKS4gVGhpcyBhbHRlcm5h dGl2ZSBpcyBub3QgcXVpdGUgc28gZmFpbC1zYWZlIChmb3JnZXR0aW5nICJzaXRlcyIgaXMgaW5z ZWN1cmUpLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KRnJvbTogRGljayBIYXJkdCBbbWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tXSANClNlbnQ6IE1vbmRheSwgMTcgTWF5IDIwMTAgNDo1OCBB TQ0KVG86IE1hbmdlciwgSmFtZXMgSA0KQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNwZWMgdGV4dCBmb3IgInNpdGVzIiBmaWVsZA0KDQpMb29r aW5nIG92ZXIgdGhlIHByZXZpb3VzIHRocmVhZHMsIEkgZG9uJ3QgdGhpbmsgYW4gaW1wb3J0YW50 IGNhcGFiaWxpdHkgd2FzIHBvaW50ZWQgb3V0IHRoYXQgd2Ugd2FudCB0byBwcmVzZXJ2ZToNCg0K VGhlIEFTIG1heSBOT1QgbmVlZCBvciB3YW50IHRvIGtub3cgd2hlcmUgYW4gYWNjZXNzIHRva2Vu IGlzIHVzZWQuIEluIG90aGVyIHdvcmRzLCB0aGUgYWNjZXNzIHRva2VuIGNvdWxkIGJlIHZpZXdl ZCBhcyBhIGNsYWltIHRoYXQgY2FuIHByZXNlbnRlZCB0byBhbiBhcmJpdHJhcnkgcmVzb3VyY2Ug dG8gZ2FpbiBhY2Nlc3MuIMKgVGhpcyBlbmFibGVzIG5ldyByZXNvdXJjZXMgdG8gYmUgZGVwbG95 ZWQgd2l0aG91dCBoYXZpbmcgdG8gKnJlZ2lzdGVyKiB0aGVtIGF0IHRoZSBBUy4NCg0KT25lIHdh eSB0byBkZWFsIHdpdGggdGhlIHNlY3VyaXR5IGlzc3VlcyBvZiBhIGJlYXJlciB0b2tlbiBpcyB0 byBzaWduaW5nIHdpdGggYSBwcml2YXRlIGtleSBiZWxvbmdpbmcgdG8gdGhlIGNsaWVudCB3aGlj aCBwcmV2ZW50cyByZXVzZSBvZiB0aGUgYWNjZXNzIHRva2VuIGJ5IGFuwqB1bnNjcnVwdWxvdXPC oCBQUiBhcyB0aGUgc2lnbmVkIHJlcXVlc3Qgd2lsbCBiZSBib3VuZCB0byB0aGF0IFBSLg0KDQpU aGUgcHJvcG9zYWwgYmVsb3cgZG9lcyBub3QgcHJlY2x1ZGUgdGhpcyBjYXBhYmlsaXR5IGFzIHdy aXR0ZW4gYXMgdGhlIHNpdGVzIHBhcmFtZXRlciBpcyBvcHRpb25hbCwgc28gSSBhbSBub3Qgc3Vn Z2VzdGluZyBhIGNoYW5nZSwgYnV0IGFtIHBvaW50aW5nIG91dCB0aGUgY2FwYWJpbGl0eS4NCg0K LS0gRGljaw0K From James.H.Manger@team.telstra.com Sun May 16 20:56:20 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646023A6C9B for <oauth@core3.amsl.com>; Sun, 16 May 2010 20:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.529 X-Spam-Level: * X-Spam-Status: No, score=1.529 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsgfuHkTlYXX for <oauth@core3.amsl.com>; Sun, 16 May 2010 20:56:19 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 587CB3A6C96 for <oauth@ietf.org>; Sun, 16 May 2010 20:56:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,244,1272808800"; d="scan'208";a="3071585" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 17 May 2010 13:56:06 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5984"; a="1996991" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcavi.tcif.telstra.com.au with ESMTP; 17 May 2010 13:56:07 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Mon, 17 May 2010 13:56:06 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: David Recordon <recordond@gmail.com> Date: Mon, 17 May 2010 13:56:05 +1000 Thread-Topic: [OAUTH-WG] Spec text for "sites" field Thread-Index: Acr1LGIgkpWTkzVIQcKrnLFD3Zm48wAM0Blw Message-ID: <255B9BB34FB7D647A506DC292726F6E1126360FEDA@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263284E5B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112634F5B35@WSMSG3153V.srv.dir.telstra.com> <AANLkTimEA62XtY6LqkICqlvNYPJlDT42U6dMxuhP52U2@mail.gmail.com> <AANLkTinwBremccqiI3NTVQSswfQWq53RBlZ9QSlQ094P@mail.gmail.com> In-Reply-To: <AANLkTinwBremccqiI3NTVQSswfQWq53RBlZ9QSlQ094P@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Spec text for "sites" field X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 03:56:20 -0000 RGF2aWQsDQoNCj4gSSB0aGluayBhIHN0cm9uZyBhcmd1bWVudCBzaG91bGQgYmUgcHJlc2VudGVk IGZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSBhcyB0byB3aHkgaXQgWyJzaXRlcyJdIG11c3Qg YmUgaW4gdGhlIGNvcmUgc3BlYyBpdHNlbGYgdmVyc3VzIGRvY3VtZW50ZWQgYXMgYSBzZWN1cml0 eSBjb25zaWRlcmF0aW9uLg0KDQoxLiBVc2luZyByZWRpcmVjdHMgYW5kIGxpbmtzIHRvIHBvaW50 cyBhY3Jvc3MgdGhlIHdlYiBpcyBjb3JlIGJlaGF2aW91ciBmb3IgbWFueSB3ZWIgY2xpZW50cyBh bmQgc2VydmVycy4NCjIuIEJlYXJlciB0b2tlbnMgYXJlIGEgY29yZSBmZWF0dXJlIG9mIE9BdXRo Mi4NCjMuIENvbWJpbmluZyAxICYgMiBpcyBvbmx5IHNhZmUgd2hlbiBhIGNsaWVudCBjYW4gcmVj b2duaXplIHdoZW4gYSBsaW5rIGdvZXMgYmV5b25kIGFuIEFQSSAoYmV5b25kIHRoZSBzZWN1cml0 eSBjb250ZXh0IGEgYmVhcmVyIHRva2VuIHdhcyBpbnRlbmRlZCBmb3IpLg0KNGEuIFJlZGlyZWN0 cyBhbmQgbGlua3MgdGhlbXNlbHZlcyBkb24ndCBpbmNsdWRlIG1ldGFkYXRhIGFib3V0IHdoZXRo ZXIgb3Igbm90IHRoZXkgbGVhdmUgYW4gQVBJLg0KNGIuIFJlbHlpbmcgb24gcGVyLXNlcnZpY2Ug cGVyLXJlc3BvbnNlIHBlci1saW5rIGRvY3VtZW50YXRpb24gdG8gZGV0ZXJtaW5lIHRoZSBib3Vu ZGFyaWVzIG9mIGFuIEFQSSBpcyByZWFsbHkgbGltaXRpbmcgKGFuZCBpcyBub3QgcHJvdmlkZWQg aW4gcHJhY3Rpc2UpLiBJdCBjcmlwcGxlcyBpbnRlcm9wIGJldHdlZW4gY2xpZW50cyBhbmQgc2Vy dmVycy4NCjRjLiBBICJzaXRlcyIgdmFsdWUgcHJvdmlkZXMgdGhlIG5lY2Vzc2FyeSBkZXRhaWxz IGFib3V0IHdoZXJlIGl0IGlzIHVuc2FmZSB0byB1c2UgYSBiZWFyZXIgdG9rZW4uDQoNClRoZSB3 ZWIgKGl0IHNlZW1zIHRvIG1lKSBpcyBzdWJzdGFudGlhbGx5IGJ1aWx0IG9uIGNsaWVudHMgYmVp bmcgYWJsZSB0byBpbnRlcm9wIHdpdGggc2VydmVycyBldmVuIHdoZW4gdGhlIGNsaWVudCBoYXMg bGltaXRlZCBzZXJ2ZXItc3BlY2lmaWMga25vd2xlZGdlIChlZyB3ZWIgYnJvd3NlcnMgYXJlIHRo ZSB1bHRpbWF0ZSBjbGllbnQsIGJyb3dzaW5nIHRoZSB3ZWIgd2l0aCBhbG1vc3Qgbm8gcHJlLWNv bmZpZ3VyZWQga25vd2xlZGdlIGFib3V0IHNwZWNpZmljIHNpdGVzKS4NClN1Y2ggY2xpZW50cyBh cmUgY29yZSB0byB0aGUgd2ViOyBzaG91bGQgYmUgY29yZSB0byBPQXV0aDI7IGFuZCByZXF1aXJl ICJzaXRlcyIuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From trac@tools.ietf.org Sun May 16 22:37:45 2010 Return-Path: <trac@tools.ietf.org> 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 004D83A6CE7 for <oauth@core3.amsl.com>; Sun, 16 May 2010 22:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 x7n2vzmUNYov for <oauth@core3.amsl.com>; Sun, 16 May 2010 22:37:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5978C3A686D for <oauth@ietf.org>; Sun, 16 May 2010 22:36:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from <trac@tools.ietf.org>) id 1ODszl-0000WF-Da; Sun, 16 May 2010 22:36:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" <trac@tools.ietf.org> X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: james@manger.com.au X-Trac-Project: oauth Date: Mon, 17 May 2010 05:36:05 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/5#comment:1 Message-ID: <068.038e7ff3773d8d93dc65cd5a772f9fbb@tools.ietf.org> References: <059.db44ca9c6a99be8265550c67a11484c4@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <059.db44ca9c6a99be8265550c67a11484c4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: james@manger.com.au, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #5: Separate scheme names for bearer tokens, request signing, and delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 05:37:45 -0000 #5: Separate scheme names for bearer tokens, request signing, and delegation ---------------------------------+------------------------------------------ Reporter: james@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: v2 | Version: 2.0 Severity: - | Keywords: ---------------------------------+------------------------------------------ Changes (by james@…): * component: authentication => v2 -- Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/5#comment:1> oauth <http://tools.ietf.org/oauth/> From eve@xmlgrrl.com Mon May 17 07:03:30 2010 Return-Path: <eve@xmlgrrl.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A79C28B797 for <oauth@core3.amsl.com>; Mon, 17 May 2010 07:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.907 X-Spam-Level: * X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_DOMAIN_NOVOWEL=0.5, J_CHICKENPOX_72=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] 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 Vp7Q4xkrzxLm for <oauth@core3.amsl.com>; Mon, 17 May 2010 07:03:29 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 86B7A3A67C0 for <oauth@ietf.org>; Mon, 17 May 2010 07:03:20 -0700 (PDT) Received: from [10.10.1.46] (ip67-152-86-163.z86-152-67.customer.algx.net [67.152.86.163]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o4HE380P017520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 May 2010 07:03:10 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Eve Maler <eve@xmlgrrl.com> In-Reply-To: <8F15DBF6-1607-4248-A74F-3D88FFD88829@gmail.com> Date: Mon, 17 May 2010 07:03:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <CB23386B-504C-47D3-AB23-A4B98E5EDCE3@xmlgrrl.com> References: <055.9fb7c0e846fc7c9e0cd7acd9189d21e8@tools.ietf.org> <064.f9cb2b4dee272925dd988e9b25f52417@tools.ietf.org> <8F15DBF6-1607-4248-A74F-3D88FFD88829@gmail.com> To: Dick Hardt <dick.hardt@gmail.com> X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] [oauth] #6: Make automated self-registration of unique clients possible X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 14:03:30 -0000 On 16 May 2010, at 3:52 PM, Dick Hardt wrote: >> Comment(by eve@=85): >>=20 >> (I agree the spec is getting pretty long. I wonder if it's possible = to do >> some factoring-out of common text, e.g. regarding common features of >> flows, to mitigate this. The length is actually making me waver a bit = on >> my previously shared opinion about including all the currently known = flows >> into the core protocol document...) >=20 > IMHO: Reading one long document is better than reading two or more = shorter documents that combined are the same size or longer. I think the = current factoring in the document lets someone read only the flows they = need. If need be, we could clarify that in the copy. I had that in WRAP. Actually, reading V2-05 carefully yesterday, I found that it had indeed = already factored out everything that could be, and that it's pretty much = the right length and organization for its current purpose. So never = mind. :) Eve Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog From prateek.mishra@oracle.com Mon May 17 07:08:50 2010 Return-Path: <prateek.mishra@oracle.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8393A68CB for <oauth@core3.amsl.com>; Mon, 17 May 2010 07:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.995 X-Spam-Level: X-Spam-Status: No, score=-4.995 tagged_above=-999 required=5 tests=[AWL=1.604, 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 1s+OY7ngfjY0 for <oauth@core3.amsl.com>; Mon, 17 May 2010 07:08:49 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BB1C43A6883 for <oauth@ietf.org>; Mon, 17 May 2010 07:08:49 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HE8brF026864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 May 2010 14:08:39 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4H8N1xB000587; Mon, 17 May 2010 14:08:37 GMT Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 246857691274105292; Mon, 17 May 2010 07:08:12 -0700 Received: from [192.168.1.4] (/209.6.179.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 07:08:11 -0700 Message-ID: <4BF14DAF.1030503@oracle.com> Date: Mon, 17 May 2010 10:07:43 -0400 From: Prateek Mishra <prateek.mishra@oracle.com> Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <20100513191510.9F70C3A6CE5@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6988CA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B6988CA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4BF14DE7.01BA:SCFMA922111,ss=1,fgs=0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 14:08:50 -0000 Where is the meeting and at what time? [quote] > This will be the last draft update before our meeting next week to allow everyone time to read it and prepare. > > EHL > > [\quote] From kris.selden@gmail.com Fri May 14 13:29:38 2010 Return-Path: <kris.selden@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEAA3A6902 for <oauth@core3.amsl.com>; Fri, 14 May 2010 13:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 rUxeqpF7tIMa for <oauth@core3.amsl.com>; Fri, 14 May 2010 13:29:37 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 189C63A6403 for <oauth@ietf.org>; Fri, 14 May 2010 13:29:37 -0700 (PDT) Received: by pxi19 with SMTP id 19so1731569pxi.31 for <oauth@ietf.org>; Fri, 14 May 2010 13:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=jUviMd0xDwd4vACRd1NwUWCYb2yk88VDR5MGM1Z8aTM=; b=RXXM+92mot9CHhJky5QpZMR2jIDEz974Jf4C055k65L7PAXczrusq0h31hAKd7dPU2 BhmMzjkNOKXBxfppwt9AsSOOLYtKn9lPYfL0COATXyQLaCXus3CwDPuAW3jOiH3SmAkc gdZ70sZmfyuzKhdiF5Kde06ETZc7I3Q79Hb4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=HCe8SU/pkD9hYPXiPJdrwwGqqzX+bXjUU3iWewCFwCTv04/yEU7TjtmuOd0lYa82xT 7l0UZFPtw7BoY9Mrk2hvubD9tO8/JANKq+KE3441VzMVCrMtSPvnav8z0X1qP0LeUfz+ A5PfwA28CXA/bFsCPulhb8hE2CcUtxh4drCAk= Received: by 10.114.54.1 with SMTP id c1mr1538988waa.61.1273868965084; Fri, 14 May 2010 13:29:25 -0700 (PDT) Received: from [172.16.2.2] (c-76-121-106-185.hsd1.wa.comcast.net [76.121.106.185]) by mx.google.com with ESMTPS id c14sm22817300waa.1.2010.05.14.13.29.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 13:29:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Kris Selden <kris.selden@gmail.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 14 May 2010 13:29:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Mon, 17 May 2010 08:28:00 -0700 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 14 May 2010 21:02:58 -0000 The only reason I've heard was interoperability but it is always stated = as patently obvious without a given reasoning. My assumption is this is = concern of OAuth 2 client library authors who don't want to depend on 3 = parsing libraries but want to state they can inter-operate with any = OAuth 2 provider. I have a suggestion to mitigate the client library dependency issue, an = argument for why C is more "interoperable" (even why the server should = be not be required to support all 3 formats), comments on encoding, and = percent encoding issues with OAuth 1. Basically, what OAuth providers return are key/value pairs and this = discussion is really an issue of serialization. Instead of depending on libraries, client providers could have a = interface for serialization that takes a mime type and string and = returns a structure of key value pairs. That way if I've already chosen = libyajl (which it is, even though it is UTF8 only) as my favorite JSON = library, I can plug it in. Chances are your client library is going to still be more bloated than = me just writing to a testable spec for the flows I need. Maybe even = unusable simply because I'm using an API from an application on an = evented server and your library uses blocking I/O for making the = requests. On to why C is more interoperable and why as a consumer having it just = be one format, doesn't help me unless I'm only using JSON APIs, it only = helps the OAuth 2 client library developer. Let's say API A supports JSON, API B supports XML and API C supports = both (as many APIs do, oh no the horror of the QA matrix). If I'm consuming API A, be nice if the OAuth 2 endpoint used JSON. If = I'm consuming API B would be nice if the endpoint supported XML. If I = needed both A and B, I need 2 parsers anyways, so what the endpoint did = doesn't matter but I would pick JSON. If A and C I would want JSON. If B = and C I would want XML. On the server side, would be nice if a service could match the OAuth = endpoint format. I don't really see a need to support all 3 since in = order to use my JSON only API you need a JSON parser anyway. There is little point to an API support multiple formats as many do if = the OAuth endpoints require JSON only. If my service is just a REST storage API, accepting binary files like = images, I just want whatever the simplest to parse in which case I would = like form-encoded. I really don't see why people think that format is = complicated, been in use a long time, there is lots of library support, = and is more trivial to write your own parser than both JSON and XML. The problem with application/x-www-form-urlencoded that was complicated = in OAuth 1, had to do with signature base strings because some = characters could be optionally encoded and various libraries did this. = Here we are talking about key/value pair serialization that HTML forms = have been using for a long time. The percent encoding is of bytes and = the bytes character set is defined by the charset in the response = header. Would not matter if some characters were optionally percent = encoded, they would still be decoded. While a lot of clients may not have an application/x-www-form-urlencoded = parser, this problem is way overblown. Most have a percent-encoding = decoder, needed just to parse URLs. Splitting on & and =3D then = replacing + with space is trivial. This can easily be done in = JavaScript, which is where I suspect some of the JSON only momentum is = coming from. Not all JSON libraries handle the NULL position UTF detection in the RFC = 4627, some just assume UTF8 only. I'm guessing supporting the other = Unicode transfer encodings isn't all that popular since UTF8 is a = superset of ASCII. Even though JSON maybe the way of the future, more SDKs like the iPhone = come with a XML parser and you'd need to find a third party JSON parser = or roll your own. As for the QA matrix, APIs that have handled multiple formats, have one = output structure that is serialized to different formats which helps = mitigate testing complexity. Test the one output, then test that that = structure can be serialized to the supported formats. You may make that = one structure JSON, then have a filter that can translate it to XML. For OAuth, I think it would increase interoperability if the output was = considered key/value string pairs and multiple serialization formats = were available, requested through the Accept header. Or I guess you can make it so OAuth is only for JSON APIs because JSON = is the future. Though I seem to remember that being said about XML not = long ago. Maybe I'm getting old. I guess I shouldn't use RSS and Atom = feeds because they are so last year. I'm for option C plus relaxing the all 3 formats support to recommended = but not required. On May 13, 2010, at 4:43 PM, Eran Hammer-Lahav wrote: > Can you give a reason why you are objecting to C. >=20 > EHL >=20 >> -----Original Message----- >> From: Robert Sayre [mailto:sayrer@gmail.com] >> Sent: Thursday, May 13, 2010 4:27 PM >> To: Eran Hammer-Lahav >> Cc: Yaron Goland; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >>=20 >> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav >> <eran@hueniverse.com> wrote: >>> There is clearly no consensus for either A or B. There was mostly no >>> objection to C, and the reason given by most of those who objected = was >> client complexity with the current proposal solves. >>=20 >> My objection to C was that your examples were buggy. So, to be = tediously >> explicit: >>=20 >> B, then A. Not C. >>=20 >> - Rob > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From uidude@google.com Mon May 17 08:33:38 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE553A6D2F for <oauth@core3.amsl.com>; Mon, 17 May 2010 08:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.431 X-Spam-Level: X-Spam-Status: No, score=-100.431 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 eospM79Mhazb for <oauth@core3.amsl.com>; Mon, 17 May 2010 08:33:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4C55428C184 for <oauth@ietf.org>; Mon, 17 May 2010 08:29:58 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o4HFTjYW031381 for <oauth@ietf.org>; Mon, 17 May 2010 08:29:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274110186; bh=iga5GOoA5Il6GTFBRa93LwNbJD0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=h/tMYVwnBPu8dSgNKPFrQMt1AxccN6UCN8a11twBQg4ZKaIll+0hMgdcrFOlv42eT mzGiliCWbVs1RFJbPlCVg== 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=pqR94XgRhYyNUKGz1dnni5Bka2at2JVBm/ZO/FgP4OBb6ITXaDsSgjRYo8PJ+pG6L RRB3R1zMa3gCy/Ku3G97g== Received: from qyk12 (qyk12.prod.google.com [10.241.83.140]) by wpaz21.hot.corp.google.com with ESMTP id o4HFTi6e011199 for <oauth@ietf.org>; Mon, 17 May 2010 08:29:44 -0700 Received: by qyk12 with SMTP id 12so563459qyk.15 for <oauth@ietf.org>; Mon, 17 May 2010 08:29:44 -0700 (PDT) Received: by 10.224.26.154 with SMTP id e26mr2892924qac.247.1274110180729; Mon, 17 May 2010 08:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.215 with HTTP; Mon, 17 May 2010 08:29:20 -0700 (PDT) In-Reply-To: <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimfTF05EWxOdyJrUU3K3IN7kJ7RdDk3mBXN2f41@mail.gmail.com> <AANLkTilCID4z-NjAJLMQ2GHcWHm-21fWKPzXs-6y4tyZ@mail.gmail.com> <AANLkTil8-AEe0Jjid2aKuI4IADCZ_vamNng5USnMKz8E@mail.gmail.com> <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com> <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com> From: Evan Gilbert <uidude@google.com> Date: Mon, 17 May 2010 08:29:20 -0700 Message-ID: <AANLkTikdi_ajhCxdJ5DGHtarnUm4icNTODKEQgcP3rqN@mail.gmail.com> To: Dick Hardt <dick.hardt@gmail.com> Content-Type: multipart/alternative; boundary=00c09f899686ba9e890486cbe488 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 15:33:38 -0000 --00c09f899686ba9e890486cbe488 Content-Type: text/plain; charset=ISO-8859-1 I'd like to get a standard for redirect URI matching, but think this may not be feasible - we are leaving the callback URI registration mechanism undefined and I've heard a number of different mechanisms that companies want to support. I think we should leave the matching undefined, possibly with a SHOULD for the most common matching mechanism (URL prefix?) I'm not hugely worried about incompatibilities between different AS on this front: 1. Clients will push us strongly towards compatible implementations. 2. Clients can always set up a redirector if needed for a specific AS (as an aside - we need a document detailing how to build a redirector properly without becoming an open redirector). On Sun, May 16, 2010 at 11:20 AM, Dick Hardt <dick.hardt@gmail.com> wrote: > > > On Tue, May 11, 2010 at 11:31 PM, Luke Shepard <lshepard@facebook.com>wrote: > >> FWIW, Facebook does not do strict equality matching on redirect_uri. We >> accept any redirect_uri that has either: >> >> - its prefix is the registered url >> - or it is a special facebook.com/xd_proxy.php url, with an origin >> parameter that has a prefix on the registered url >> >> I think that the spec should leave the matching up to the server. > > > If the matching is left to an arbitrary, server defined algorithm, we lose > interop since a client implementation may make assumptions on what may be > allowed in the redirect_uri at one AS and then not be able to work with > another AS that is more restrictive. > > As this is a security feature, I'd like to hear the options from the > security oriented participants with experience here. > > Allen / Brian? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00c09f899686ba9e890486cbe488 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to get a standard for redirect URI matching, but think this ma= y not be feasible -=A0we are leaving the callback URI registration mechanis= m undefined and I've heard a number of different mechanisms that compan= ies want to support.<div> <br></div><div>I think we should leave the matching undefined, possibly wit= h a SHOULD for the most common matching mechanism (URL prefix?)<br><div><br= >I'm not hugely worried about incompatibilities between different AS on= this front:</div> <div>1. Clients will push us strongly towards compatible implementations.</= div><div>2. Clients can always set up a redirector if needed for a specific= AS (as an aside - we need a document detailing how to build a redirector p= roperly without becoming an open redirector).<div> <div><br><div><br><div class=3D"gmail_quote">On Sun, May 16, 2010 at 11:20 = AM, Dick Hardt <span dir=3D"ltr"><<a href=3D"mailto:dick.hardt@gmail.com= ">dick.hardt@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex;"> <br><br><div class=3D"gmail_quote"><div class=3D"im">On Tue, May 11, 2010 a= t 11:31 PM, Luke Shepard <span dir=3D"ltr"><<a href=3D"mailto:lshepard@f= acebook.com" target=3D"_blank">lshepard@facebook.com</a>></span> wrote:<= br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> FWIW, Facebook does not do strict equality matching on redirect_uri. We acc= ept any redirect_uri that has either:<br> <br> - its prefix is the registered url<br> - or it is a special <a href=3D"http://facebook.com/xd_proxy.php" target=3D= "_blank">facebook.com/xd_proxy.php</a> url, with an origin parameter that h= as a prefix on the registered url<br> <br> I think that the spec should leave the matching up to the server.</blockquo= te><div><br></div></div><div>If the matching is left to an arbitrary, serve= r defined algorithm, we lose interop since a client implementation may make= assumptions on what may be allowed in the redirect_uri at one AS and then = not be able to work with another AS that is more=A0restrictive. =A0</div> <div><br></div><div>As this is a security feature, I'd like to hear the= options from the security oriented participants with experience here.=A0</= div><div><br></div><div>Allen / Brian?</div></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div></div></div></div></div> --00c09f899686ba9e890486cbe488-- From mscurtescu@google.com Mon May 17 08:55:22 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94453A6A43 for <oauth@core3.amsl.com>; Mon, 17 May 2010 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.513 X-Spam-Level: X-Spam-Status: No, score=-104.513 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_50=0.001, 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 6zNOXUMKUi09 for <oauth@core3.amsl.com>; Mon, 17 May 2010 08:55:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 98CF03A6A75 for <oauth@ietf.org>; Mon, 17 May 2010 08:53:50 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o4HFreq9005549 for <oauth@ietf.org>; Mon, 17 May 2010 08:53:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274111620; bh=Z9ea/gkkp8dPR2uqqEPe9czEBD0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=jJ2Lm6/BNlDiFaj7HXkWr6N3ODZcl3N+2fTi9f4OGYrCoNrn0tcYSLrbjCkMsQrvs TfG/EYc+wZfJuUfDjzHdw== 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:content-transfer-encoding:x-system-of-record; b=QPBIR56/iN8kZIjEf4+c24TRqmI2xb0OvXg4c5bF97VO16joMIRw5uKgMWPnRNgf/ S6KiVYPHa0Pq5pCpF364w== Received: from pwi3 (pwi3.prod.google.com [10.241.219.3]) by wpaz24.hot.corp.google.com with ESMTP id o4HFrRt2009272 for <oauth@ietf.org>; Mon, 17 May 2010 08:53:39 -0700 Received: by pwi3 with SMTP id 3so1490871pwi.36 for <oauth@ietf.org>; Mon, 17 May 2010 08:53:39 -0700 (PDT) Received: by 10.141.13.11 with SMTP id q11mr3819564rvi.75.1274111619257; Mon, 17 May 2010 08:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.125.21 with HTTP; Mon, 17 May 2010 08:53:19 -0700 (PDT) In-Reply-To: <AANLkTikdi_ajhCxdJ5DGHtarnUm4icNTODKEQgcP3rqN@mail.gmail.com> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimfTF05EWxOdyJrUU3K3IN7kJ7RdDk3mBXN2f41@mail.gmail.com> <AANLkTilCID4z-NjAJLMQ2GHcWHm-21fWKPzXs-6y4tyZ@mail.gmail.com> <AANLkTil8-AEe0Jjid2aKuI4IADCZ_vamNng5USnMKz8E@mail.gmail.com> <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com> <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com> <AANLkTikdi_ajhCxdJ5DGHtarnUm4icNTODKEQgcP3rqN@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Mon, 17 May 2010 08:53:19 -0700 Message-ID: <AANLkTikZGYRUe84a5fb-QoXSdJL-hmCzFO3vUP_6Zc7r@mail.gmail.com> To: Evan Gilbert <uidude@google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 15:55:22 -0000 On Mon, May 17, 2010 at 8:29 AM, Evan Gilbert <uidude@google.com> wrote: > I'd like to get a standard for redirect URI matching, but think this may = not > be feasible -=A0we are leaving the callback URI registration mechanism > undefined and I've heard a number of different mechanisms that companies > want to support. > I think we should leave the matching undefined, possibly with a SHOULD fo= r > the most common matching mechanism (URL prefix?) > > I'm not hugely worried about incompatibilities between different AS on th= is > front: > 1. Clients will push us strongly towards compatible implementations. > 2. Clients can always set up a redirector if needed for a specific AS (as= an > aside - we need a document detailing how to build a redirector properly > without becoming an open redirector). Isn't this saying that clients can always implement strict matching and live with that? Why not require it then? Marius From yarong@microsoft.com Mon May 17 09:46:13 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251323A6A45 for <oauth@core3.amsl.com>; Mon, 17 May 2010 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.556 X-Spam-Level: X-Spam-Status: No, score=-8.556 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 YvAoXAT0Y-iZ for <oauth@core3.amsl.com>; Mon, 17 May 2010 09:46:12 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C8F533A6903 for <oauth@ietf.org>; Mon, 17 May 2010 09:45:58 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 May 2010 09:45:51 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Mon, 17 May 2010 09:45:50 -0700 From: Yaron Goland <yarong@microsoft.com> To: Dick Hardt <dick.hardt@gmail.com>, "Manger, James H" <James.H.Manger@team.telstra.com> Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: AQHK8ozxzUROSzNgzEuStjakYvEI+5JP3EqAgAT+7wCAAGKqAIAAAaEAgACcEAA= Date: Mon, 17 May 2010 16:45:48 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A43095C@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634F5EA3@WSMSG3153V.srv.dir.telstra.com> <7934BAC5-7FA8-48E7-82A5-A4A17DE9146E@gmail.com> In-Reply-To: <7934BAC5-7FA8-48E7-82A5-A4A17DE9146E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 16:46:13 -0000 Note that in some very popular browsers and some proxies the maximum safe U= RL size is more like 2k. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dick Hardt > Sent: Sunday, May 16, 2010 5:27 PM > To: Manger, James H > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] in-app logout? >=20 >=20 > On 2010-05-16, at 5:20 PM, Manger, James H wrote: >=20 > > Dick, > > > >> James: An important capability of the refresh token is that it *can* b= e a > self contained token in that is not an id, but a signed token that can be > examined and acted upon on presentation. > > > > Defining refresh_token as a URI does not prevent it being a self-contai= ned > signed token. > > > > The only limitation implied is a URI size limit. A few KB, however, is = not that > onerous a limit -- it is sufficient to hold a 4096-bit RSA signature with= a couple > of KB over for permissions etc.). >=20 > Agreed, a token could be a self contained token. A design objective was > allowing existing systems to use existing tokens. >=20 > -- Dick >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From esachs@google.com Mon May 17 10:11:27 2010 Return-Path: <esachs@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD233A6A9D for <oauth@core3.amsl.com>; Mon, 17 May 2010 10:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.952 X-Spam-Level: X-Spam-Status: No, score=-98.952 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_FONT_LOW_CONTRAST=0.124, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 VDPC+GIi7+te for <oauth@core3.amsl.com>; Mon, 17 May 2010 10:11:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 373B13A6A91 for <oauth@ietf.org>; Mon, 17 May 2010 10:11:03 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o4HHAmLT011350 for <oauth@ietf.org>; Mon, 17 May 2010 10:10:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274116249; bh=6CQmik96YRPMX9YsKwFdlvJovlM=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=VMgNdyVDIJav5zaXcaZTpns8BKjNNAa0D2Uh+IRsV/626TiQSD6VdGYgN/Sa6Zg92 TRlqMut54H7dUZtM9w83A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=nKsbybUGaeKReSvOuqurKCsFmtaaRrU1yPZMvG+9bSwO91dgBCGliplx4AN99MNYR Irnehm/BU95CezBNFoIcQ== Received: from qyk32 (qyk32.prod.google.com [10.241.83.160]) by kpbe15.cbf.corp.google.com with ESMTP id o4HHAA43003651 for <oauth@ietf.org>; Mon, 17 May 2010 10:10:47 -0700 Received: by qyk32 with SMTP id 32so697793qyk.0 for <oauth@ietf.org>; Mon, 17 May 2010 10:10:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.72.143 with SMTP id m15mr2981237qaj.231.1274116246995; Mon, 17 May 2010 10:10:46 -0700 (PDT) Received: by 10.229.78.152 with HTTP; Mon, 17 May 2010 10:10:46 -0700 (PDT) Date: Mon, 17 May 2010 10:10:46 -0700 Message-ID: <AANLkTik-naPkTqOViLgRFW5LFghwPsSEgRTWbHfkC0ml@mail.gmail.com> From: Eric Sachs <esachs@google.com> To: oauth-wrap-wg@googlegroups.com, OAuth WG <oauth@ietf.org>, oauth@googlegroups.com, oauth-sasl-xmpp <oauth-sasl-xmpp@google.com> Content-Type: multipart/alternative; boundary=00c09f88cfaf4e04640486cd4eea X-System-Of-Record: true Subject: [OAUTH-WG] =?windows-1252?q?Google=92s_Experimental_OAuth-WRAP_su?= =?windows-1252?q?pport?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 17:11:28 -0000 --00c09f88cfaf4e04640486cd4eea Content-Type: text/plain; charset=ISO-8859-1 Google currently supports the use of the OAuth1.0/1.0a and OpenID/OAuth Hybrid protocols for accessing Google APIs (see documentation<http://code.google.com/apis/accounts/>). Google is committed to providing support for OAuth2<http://www.google.com/url?q=http%3A%2F%2Fwiki.oauth.net%2FOAuth-2&sa=D&sntz=1&usg=AFQjCNHM6Pduh__AaGWa0f2IWYlrYFK-8Q>in the future. As a milestone towards that goal, Google has implemented support for the OAuth-WRAP<http://www.google.com/url?q=http%3A%2F%2Fwiki.oauth.net%2FOAuth-WRAP&sa=D&sntz=1&usg=AFQjCNHjecqdM82DH202s--ZaYBkf9rVMg>protocol which was a big influence on the design of OAuth2. You can find documentation at this site: https://sites.google.com/site/oauthgoog/Home/oauth-wrap-support While Google does not plan to formally announce our OAuth-WRAP support, we are making it available on an experimental basis to show our progress towards support for OAuth2. Since OAuth-WRAP and OAuth2 share many of the same design characteristics, we are also hoping that some developers will leverage our experimental support to build prototypes of new types of applications that were very hard to create using OAuth1, but which are much easier on OAuth-WRAP and OAuth2. Eric Sachs Product Manager, Google --00c09f88cfaf4e04640486cd4eea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div><span class=3D"Apple-style-span" style=3D"font-family: Times; font-siz= e: medium; "><span style=3D"font-size: 11pt; font-family: Arial; color: rgb= (0, 0, 0); background-color: transparent; font-weight: normal; font-style: = normal; text-decoration: none; vertical-align: baseline; white-space: pre-w= rap; ">Google currently supports the use of the OAuth1.0/1.0a and OpenID/OA= uth Hybrid protocols for accessing Google APIs (see </span></span><span cla= ss=3D"Apple-style-span" style=3D"font-family: Times; font-size: medium; "><= a href=3D"http://code.google.com/apis/accounts/" style=3D"color: rgb(85, 26= , 139); outline-style: none; outline-width: initial; outline-color: initial= ; "><span style=3D"font-size: 11pt; font-family: Arial; color: rgb(0, 0, 15= 3); background-color: transparent; font-weight: normal; font-style: normal;= text-decoration: underline; vertical-align: baseline; white-space: pre-wra= p; ">documentation</span></a></span><span class=3D"Apple-style-span" style= =3D"font-family: Times; font-size: medium; "><span style=3D"font-size: 11pt= ; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; f= ont-weight: normal; font-style: normal; text-decoration: none; vertical-ali= gn: baseline; white-space: pre-wrap; ">). =A0Google is committed =A0to prov= iding support for </span></span><span class=3D"Apple-style-span" style=3D"f= ont-family: Times; font-size: medium; "><a href=3D"http://www.google.com/ur= l?q=3Dhttp%3A%2F%2Fwiki.oauth.net%2FOAuth-2&sa=3DD&sntz=3D1&usg= =3DAFQjCNHM6Pduh__AaGWa0f2IWYlrYFK-8Q" style=3D"color: rgb(78, 125, 191); o= utline-style: none; outline-width: initial; outline-color: initial; "><span= style=3D"font-size: 11pt; font-family: Arial; color: rgb(0, 0, 153); backg= round-color: transparent; font-weight: normal; font-style: normal; text-dec= oration: underline; vertical-align: baseline; white-space: pre-wrap; ">OAut= h2</span></a></span><span class=3D"Apple-style-span" style=3D"font-family: = Times; font-size: medium; "><span style=3D"font-size: 11pt; font-family: Ar= ial; color: rgb(0, 0, 0); background-color: transparent; font-weight: norma= l; font-style: normal; text-decoration: none; vertical-align: baseline; whi= te-space: pre-wrap; "> in the future. =A0As a milestone towards that goal, = Google has implemented support for the </span></span><span class=3D"Apple-s= tyle-span" style=3D"font-family: Times; font-size: medium; "><a href=3D"htt= p://www.google.com/url?q=3Dhttp%3A%2F%2Fwiki.oauth.net%2FOAuth-WRAP&sa= =3DD&sntz=3D1&usg=3DAFQjCNHjecqdM82DH202s--ZaYBkf9rVMg" style=3D"co= lor: rgb(78, 125, 191); outline-style: none; outline-width: initial; outlin= e-color: initial; "><span style=3D"font-size: 11pt; font-family: Arial; col= or: rgb(0, 0, 153); background-color: transparent; font-weight: normal; fon= t-style: normal; text-decoration: underline; vertical-align: baseline; whit= e-space: pre-wrap; ">OAuth-WRAP</span></a></span><span class=3D"Apple-style= -span" style=3D"font-family: Times; font-size: medium; "><span style=3D"fon= t-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: tr= ansparent; font-weight: normal; font-style: normal; text-decoration: none; = vertical-align: baseline; white-space: pre-wrap; "> protocol which was a bi= g influence on the design of OAuth2. You can find documentation at this si= te:</span></span><span class=3D"Apple-style-span" style=3D"font-family: Tim= es; font-size: medium; "><br> </span></div><blockquote class=3D"webkit-indent-blockquote" style=3D"margin= : 0 0 0 40px; border: none; padding: 0px;"><div><span class=3D"Apple-style-= span" style=3D"font-family: Times; font-size: medium; "><span class=3D"Appl= e-style-span" style=3D"font-family: arial; font-size: small; "><div> <a href=3D"https://sites.google.com/site/oauthgoog/Home/oauth-wrap-support"= >https://sites.google.com/site/oauthgoog/Home/oauth-wrap-support</a></div><= /span></span></div></blockquote><div><span class=3D"Apple-style-span" style= =3D"font-family: Times; font-size: medium; "><span class=3D"Apple-style-spa= n" style=3D"font-family: arial; font-size: small; "><div> <br></div></span></span><span class=3D"Apple-style-span" style=3D"font-fami= ly: Times; font-size: medium; "><span style=3D"font-size: 11pt; font-family= : Arial; color: rgb(0, 0, 0); background-color: transparent; font-weight: n= ormal; font-style: normal; text-decoration: none; vertical-align: baseline;= white-space: pre-wrap; ">While Google does not plan to formally announce o= ur OAuth-WRAP support, we are making it available on an experimental basis = to show our progress towards support for OAuth2. =A0Since OAuth-WRAP and OA= uth2 share many of the same design characteristics, we are also hoping that= some developers will leverage our experimental support to build prototypes= of new types of applications that were very hard to create using OAuth1, b= ut which are much easier on OAuth-WRAP and OAuth2.</span></span></div> <div><span class=3D"Apple-style-span" style=3D"font-family: Times; font-siz= e: medium; "><span style=3D"font-size: 11pt; font-family: Arial; color: rgb= (0, 0, 0); background-color: transparent; font-weight: normal; font-style: = normal; text-decoration: none; vertical-align: baseline; white-space: pre-w= rap; "><br> </span></span></div><div><span class=3D"Apple-style-span" style=3D"font-fam= ily: Times; font-size: medium; "><span style=3D"font-size: 11pt; font-famil= y: Arial; color: rgb(0, 0, 0); background-color: transparent; font-weight: = normal; font-style: normal; text-decoration: none; vertical-align: baseline= ; white-space: pre-wrap; ">Eric Sachs</span></span></div> <div><span class=3D"Apple-style-span" style=3D"font-family: Times; font-siz= e: medium; "><span style=3D"font-size: 11pt; font-family: Arial; color: rgb= (0, 0, 0); background-color: transparent; font-weight: normal; font-style: = normal; text-decoration: none; vertical-align: baseline; white-space: pre-w= rap; ">Product Manager, Google</span></span></div> --00c09f88cfaf4e04640486cd4eea-- From beaton@google.com Mon May 17 10:49:44 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B5A3A69D8 for <oauth@core3.amsl.com>; Mon, 17 May 2010 10:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.468 X-Spam-Level: X-Spam-Status: No, score=-104.468 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_50=0.001, 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 MOQ3sOzQV+ra for <oauth@core3.amsl.com>; Mon, 17 May 2010 10:49:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 88D9B3A68DC for <oauth@ietf.org>; Mon, 17 May 2010 10:49:43 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o4HHnYvf009258 for <oauth@ietf.org>; Mon, 17 May 2010 10:49:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274118575; bh=uUaqrYdteQPYqK3+wbQMyv/CHvw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Q+/YXXnErd+IREYTV0yY728uaJQrJAaT0lF0E4oPsVFMObDAI4K+Ac7dLsGdvSbPx 9tD+2mSjnjMKy40FBhNUw== 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=ZsihNcXbUVG9lW+oTH9C0K+b6qu8LociRxiGx7u8TYWnfkjf9A/RhoXclR84dfJ26 1iBI3XRQjAuS92YSLcKAA== Received: from pxi8 (pxi8.prod.google.com [10.243.27.8]) by kpbe19.cbf.corp.google.com with ESMTP id o4HHnA5G005885 for <oauth@ietf.org>; Mon, 17 May 2010 10:49:33 -0700 Received: by pxi8 with SMTP id 8so2375260pxi.16 for <oauth@ietf.org>; Mon, 17 May 2010 10:49:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.21.19 with SMTP id y19mr3656951wfi.259.1274118573314; Mon, 17 May 2010 10:49:33 -0700 (PDT) Received: by 10.143.136.7 with HTTP; Mon, 17 May 2010 10:49:33 -0700 (PDT) In-Reply-To: <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com> References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimfTF05EWxOdyJrUU3K3IN7kJ7RdDk3mBXN2f41@mail.gmail.com> <AANLkTilCID4z-NjAJLMQ2GHcWHm-21fWKPzXs-6y4tyZ@mail.gmail.com> <AANLkTil8-AEe0Jjid2aKuI4IADCZ_vamNng5USnMKz8E@mail.gmail.com> <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com> <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com> Date: Mon, 17 May 2010 10:49:33 -0700 Message-ID: <AANLkTikcUkd55549ZgVtzZ5EpkcKOveCULh7igqasqcO@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: Dick Hardt <dick.hardt@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 17:49:44 -0000 On Sun, May 16, 2010 at 11:20 AM, Dick Hardt <dick.hardt@gmail.com> wrote: > If the matching is left to an arbitrary, server defined algorithm, we los= e > interop since a client implementation may make assumptions on what may be > allowed in the redirect_uri at one AS and then not be able to work with > another AS that is more=A0restrictive. > As this is a security feature, I'd like to hear the options from the > security oriented participants with experience here. > Allen / Brian? We can do a session at IIW on this if people want. There are a few different use-cases to consider: - installed applications using the js profile or the web app profile It doesn't matter what you do, you can't authenticate the installed application. My recommendation here is to do something like what we've done with OAuth for installed apps [1]. - registered web apps with a secure client-secret You can allow *any* callback URL on the redirect. The callback URL is authenticated using the client-secret. We should all do strict equality matching when exchanging the verification code for refresh token and access token. - js profile, or web app profile where you don't completely trust the registration or the security of the client-secret We've got lots of service-provider specific behavior here. Unfortunately most service providers don't seem to be willing to change (or in some cases even document) what they are doing. So we're doomed unless we can get consensus from service providers that there needs to be consensus. =3D) Logic I've seen includes: - regular expressions - any callback URL on the fully-qualified hostname - any callback URL on a domain name. - fixed callback URL path, arbitrary callback URL query - fixed callback URL path, fixed callback URL query, one query parameter (wrap_state, or whatever we called it =3D) allowed to vary - any callback URL path under a particular directory I tried to summarize the risks in the security considerations I wrote up a few weeks ago. Check out the section on "Authentication Techniques" and "Web App Delegation Profile - Security Considerations". Cheers, Brian [1] http://code.google.com/apis/accounts/docs/OAuthForInstalledApps.html [2] http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations From yarong@microsoft.com Mon May 17 14:58:09 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2115D3A67FF for <oauth@core3.amsl.com>; Mon, 17 May 2010 14:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.519 X-Spam-Level: X-Spam-Status: No, score=-8.519 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 13XR7-A7WgXf for <oauth@core3.amsl.com>; Mon, 17 May 2010 14:58:07 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 39F2F3A685A for <oauth@ietf.org>; Mon, 17 May 2010 14:58:04 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 May 2010 14:57:56 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.11]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi; Mon, 17 May 2010 14:57:55 -0700 From: Yaron Goland <yarong@microsoft.com> To: Kris Selden <kris.selden@gmail.com>, Eran Hammer-Lahav <eran@hueniverse.com> Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: AQHK8vPryc3Stn6LIkOF1NSUvaPezpJQe5UAgAFcHQCABAdEsA== Date: Mon, 17 May 2010 21:57:53 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> In-Reply-To: <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 21:58:09 -0000 My concerns with C are twofold. First, it's unclear to me how we will successfully reason about OAuth's dat= a model when the three proposed formats all have mutually incompatible data= models? | Forms | JSON | XML Nesting | NO | YES | YES Multi-Value Fields | NO | YES| NO[1] Typing | NO | YES | NO[2] Namespaces | NO | NO | NO Objects | NO | YES | YES[3] [1] There is no formal definition in XML for multi-value fields although on= e can build them using nested elements [2] XML does have XML schema but most parsers don't natively support it [3] XML actually has two different kinds of objects, elements and attribute= s. Will we dumb down JSON and XML to the point where they match Forms? In othe= r words, per Kris's mail, is OAuth's data model just name/value pairs? That= can work but then it calls into question why the heck we bothered supporti= ng JSON or XML in the first place if we are essentially just using them as = Forms? It seems almost cruel to dangle the richer data models of JSON and X= ML in front of people and then pull them back with a restriction that we on= ly do name/value pairs. Will we support JSON's data model? In which case do we intend to add typing= , arrays, etc. to forms and ban attributes and namespaces from XML? Will we support XML's data model? In which case do we intend to add name sp= acing and attributes to forms and JSON while banning all types but string a= long with arrays in JSON? Or maybe we'll simply assert the existence of three different worlds where = every extension is defined in a completely different context independently = of each other? So every extension to OAuth has to, in essence, be defined t= hree separate times? Second, as a burden on server implementers we are requiring that they posse= ss and test three different parsers. I think this is unnecessarily onerous = and all but guaranteed to lead to interoperability issues as server impleme= nters will focus primarily on the particular syntaxes they think will see t= he most use and give less attention to other others. This is an inevitable = trade off given the difficulties of fully testing even basic formats. Thanks, Yaron > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Kris Selden > Sent: Friday, May 14, 2010 1:29 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > The only reason I've heard was interoperability but it is always stated a= s > patently obvious without a given reasoning. My assumption is this is conc= ern > of OAuth 2 client library authors who don't want to depend on 3 parsing > libraries but want to state they can inter-operate with any OAuth 2 provi= der. >=20 > I have a suggestion to mitigate the client library dependency issue, an > argument for why C is more "interoperable" (even why the server should be > not be required to support all 3 formats), comments on encoding, and > percent encoding issues with OAuth 1. >=20 > Basically, what OAuth providers return are key/value pairs and this discu= ssion > is really an issue of serialization. >=20 > Instead of depending on libraries, client providers could have a interfac= e for > serialization that takes a mime type and string and returns a structure o= f key > value pairs. That way if I've already chosen libyajl (which it is, even t= hough it > is UTF8 only) as my favorite JSON library, I can plug it in. >=20 > Chances are your client library is going to still be more bloated than me= just > writing to a testable spec for the flows I need. Maybe even unusable simp= ly > because I'm using an API from an application on an evented server and you= r > library uses blocking I/O for making the requests. >=20 > On to why C is more interoperable and why as a consumer having it just be > one format, doesn't help me unless I'm only using JSON APIs, it only help= s > the OAuth 2 client library developer. >=20 > Let's say API A supports JSON, API B supports XML and API C supports both > (as many APIs do, oh no the horror of the QA matrix). >=20 > If I'm consuming API A, be nice if the OAuth 2 endpoint used JSON. If I'm > consuming API B would be nice if the endpoint supported XML. If I needed > both A and B, I need 2 parsers anyways, so what the endpoint did doesn't > matter but I would pick JSON. If A and C I would want JSON. If B and C I = would > want XML. >=20 > On the server side, would be nice if a service could match the OAuth > endpoint format. I don't really see a need to support all 3 since in orde= r to > use my JSON only API you need a JSON parser anyway. >=20 > There is little point to an API support multiple formats as many do if th= e > OAuth endpoints require JSON only. >=20 > If my service is just a REST storage API, accepting binary files like ima= ges, I > just want whatever the simplest to parse in which case I would like form- > encoded. I really don't see why people think that format is complicated, > been in use a long time, there is lots of library support, and is more tr= ivial to > write your own parser than both JSON and XML. >=20 > The problem with application/x-www-form-urlencoded that was complicated > in OAuth 1, had to do with signature base strings because some characters > could be optionally encoded and various libraries did this. Here we are t= alking > about key/value pair serialization that HTML forms have been using for a = long > time. The percent encoding is of bytes and the bytes character set is def= ined > by the charset in the response header. Would not matter if some character= s > were optionally percent encoded, they would still be decoded. >=20 > While a lot of clients may not have an application/x-www-form-urlencoded > parser, this problem is way overblown. Most have a percent-encoding > decoder, needed just to parse URLs. Splitting on & and =3D then replacing= + > with space is trivial. This can easily be done in JavaScript, which is wh= ere I > suspect some of the JSON only momentum is coming from. >=20 > Not all JSON libraries handle the NULL position UTF detection in the RFC = 4627, > some just assume UTF8 only. I'm guessing supporting the other Unicode > transfer encodings isn't all that popular since UTF8 is a superset of ASC= II. >=20 > Even though JSON maybe the way of the future, more SDKs like the iPhone > come with a XML parser and you'd need to find a third party JSON parser o= r > roll your own. >=20 > As for the QA matrix, APIs that have handled multiple formats, have one > output structure that is serialized to different formats which helps miti= gate > testing complexity. Test the one output, then test that that structure ca= n be > serialized to the supported formats. You may make that one structure JSON= , > then have a filter that can translate it to XML. >=20 > For OAuth, I think it would increase interoperability if the output was > considered key/value string pairs and multiple serialization formats were > available, requested through the Accept header. >=20 > Or I guess you can make it so OAuth is only for JSON APIs because JSON is= the > future. Though I seem to remember that being said about XML not long ago. > Maybe I'm getting old. I guess I shouldn't use RSS and Atom feeds because > they are so last year. >=20 > I'm for option C plus relaxing the all 3 formats support to recommended b= ut > not required. >=20 > On May 13, 2010, at 4:43 PM, Eran Hammer-Lahav wrote: >=20 > > Can you give a reason why you are objecting to C. > > > > EHL > > > >> -----Original Message----- > >> From: Robert Sayre [mailto:sayrer@gmail.com] > >> Sent: Thursday, May 13, 2010 4:27 PM > >> To: Eran Hammer-Lahav > >> Cc: Yaron Goland; OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > >> > >> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav > >> <eran@hueniverse.com> wrote: > >>> There is clearly no consensus for either A or B. There was mostly no > >>> objection to C, and the reason given by most of those who objected > >>> was > >> client complexity with the current proposal solves. > >> > >> My objection to C was that your examples were buggy. So, to be > >> tediously > >> explicit: > >> > >> B, then A. Not C. > >> > >> - Rob > > _______________________________________________ > > 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 From Hannes.Tschofenig@gmx.net Mon May 17 15:15:46 2010 Return-Path: <Hannes.Tschofenig@gmx.net> 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 0B2463A68E7 for <oauth@core3.amsl.com>; Mon, 17 May 2010 15:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 dY775p42qLoq for <oauth@core3.amsl.com>; Mon, 17 May 2010 15:15:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1B5993A68DE for <oauth@ietf.org>; Mon, 17 May 2010 15:14:45 -0700 (PDT) Received: (qmail invoked by alias); 17 May 2010 22:14:35 -0000 Received: from w229.z065106072.sjc-ca.dsl.cnc.net (EHLO [10.2.3.155]) [65.106.72.229] by mail.gmx.net (mp066) with SMTP; 18 May 2010 00:14:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/oZw8GZtboBxdtHNpg709di4cOTftNlI6oclLOWv LI2RCjWfpjtWhM Message-ID: <4BF1BFC9.6080500@gmx.net> Date: Tue, 18 May 2010 01:14:33 +0300 From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Reminder: OAuth Interim Meeting, 20th May X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 22:15:46 -0000 This is a reminder of the OAuth interim meeting, which happens this Thursday, 20th May. The meeting venue is at Yahoo 701 First Ave Sunnyvale, CA 94089. Here is the info: http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting Be advised to read the latest OAuth specification to benefit from the discussions: http://tools.ietf.org/wg/oauth/draft-ietf-oauth-v2/ Ciao Hannes & Blaine From James.H.Manger@team.telstra.com Mon May 17 16:31:49 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73B23A6B21 for <oauth@core3.amsl.com>; Mon, 17 May 2010 16:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.532 X-Spam-Level: * X-Spam-Status: No, score=1.532 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2TC1OD6L9sj for <oauth@core3.amsl.com>; Mon, 17 May 2010 16:31:48 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id BD0683A6B28 for <oauth@ietf.org>; Mon, 17 May 2010 16:31:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,250,1272808800"; d="scan'208";a="3120820" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 18 May 2010 09:31:30 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5985"; a="2029226" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 18 May 2010 09:31:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 18 May 2010 09:31:30 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Yaron Goland <yarong@microsoft.com> Date: Tue, 18 May 2010 09:31:29 +1000 Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: AQHK8ozxzUROSzNgzEuStjakYvEI+5JP3EqAgAT+7wCAAGKqAIAAAaEAgACcEACAAG7RkA== Message-ID: <255B9BB34FB7D647A506DC292726F6E112636107C3@WSMSG3153V.srv.dir.telstra.com> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634F5EA3@WSMSG3153V.srv.dir.telstra.com> <7934BAC5-7FA8-48E7-82A5-A4A17DE9146E@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A43095C@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A43095C@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 17 May 2010 23:31:49 -0000 WWFyb24sDQoNCj4gTm90ZSB0aGF0IGluIHNvbWUgdmVyeSBwb3B1bGFyIGJyb3dzZXJzIGFuZCBz b21lIHByb3hpZXMgdGhlIG1heGltdW0gc2FmZSBVUkwgc2l6ZSBpcyBtb3JlIGxpa2UgMmsuDQoN CjJLQiBpcyBzdWZmaWNpZW50IGZvciBhIDQwOTYtYml0IFJTQSBzaWduYXR1cmUgPSA0MDk2IC8g OCAqIDQgLyAzID0gNjgzIGJhc2U2NCBjaGFycyAtLSB3aXRoIDEuM0tCIG92ZXIgZm9yIHBlcm1p c3Npb25zIGV0Yy4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9h dXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYNCj4gT2YgRGljayBIYXJkdA0KPiBTZW50OiBTdW5kYXksIE1heSAxNiwgMjAxMCA1OjI3 IFBNDQo+IFRvOiBNYW5nZXIsIEphbWVzIEgNCj4gQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9y ZykNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gaW4tYXBwIGxvZ291dD8NCj4gDQo+IA0KPiBP biAyMDEwLTA1LTE2LCBhdCA1OjIwIFBNLCBNYW5nZXIsIEphbWVzIEggd3JvdGU6DQo+IA0KPiA+ IERpY2ssDQo+ID4NCj4gPj4gSmFtZXM6IEFuIGltcG9ydGFudCBjYXBhYmlsaXR5IG9mIHRoZSBy ZWZyZXNoIHRva2VuIGlzIHRoYXQgaXQgKmNhbiogYmUgYQ0KPiBzZWxmIGNvbnRhaW5lZCB0b2tl biBpbiB0aGF0IGlzIG5vdCBhbiBpZCwgYnV0IGEgc2lnbmVkIHRva2VuIHRoYXQgY2FuIGJlDQo+ IGV4YW1pbmVkIGFuZCBhY3RlZCB1cG9uIG9uIHByZXNlbnRhdGlvbi4NCj4gPg0KPiA+IERlZmlu aW5nIHJlZnJlc2hfdG9rZW4gYXMgYSBVUkkgZG9lcyBub3QgcHJldmVudCBpdCBiZWluZyBhIHNl bGYtY29udGFpbmVkDQo+IHNpZ25lZCB0b2tlbi4NCj4gPg0KPiA+IFRoZSBvbmx5IGxpbWl0YXRp b24gaW1wbGllZCBpcyBhIFVSSSBzaXplIGxpbWl0LiBBIGZldyBLQiwgaG93ZXZlciwgaXMgbm90 IHRoYXQNCj4gb25lcm91cyBhIGxpbWl0IC0tIGl0IGlzIHN1ZmZpY2llbnQgdG8gaG9sZCBhIDQw OTYtYml0IFJTQSBzaWduYXR1cmUgd2l0aCBhIGNvdXBsZQ0KPiBvZiBLQiBvdmVyIGZvciBwZXJt aXNzaW9ucyBldGMuKS4NCj4gDQo+IEFncmVlZCwgYSB0b2tlbiBjb3VsZCBiZSBhIHNlbGYgY29u dGFpbmVkIHRva2VuLiBBIGRlc2lnbiBvYmplY3RpdmUgd2FzDQo+IGFsbG93aW5nIGV4aXN0aW5n IHN5c3RlbXMgdG8gdXNlIGV4aXN0aW5nIHRva2Vucy4NCj4gDQo+IC0tIERpY2sNCg0K From eran@hueniverse.com Mon May 17 23:18:51 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725CC3A6C13 for <oauth@core3.amsl.com>; Mon, 17 May 2010 23:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_50=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 dg+uOMKA-iRe for <oauth@core3.amsl.com>; Mon, 17 May 2010 23:18: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 F0A213A6C22 for <oauth@ietf.org>; Mon, 17 May 2010 23:18:29 -0700 (PDT) Received: (qmail 7305 invoked from network); 18 May 2010 06:18:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 May 2010 06:18:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 17 May 2010 23:18:17 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: Mon, 17 May 2010 23:18:22 -0700 Thread-Topic: Reminder: OAuth Interim Meeting, 20th May Thread-Index: Acr2UbHILtO+1xnUSGeb9p7JSmDbdQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B69912F@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] Reminder: OAuth Interim Meeting, 20th May X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 06:18:51 -0000 The focus of the meeting is to make progress on the draft. We should not be= spending any time explaining OAuth, or giving introductions to newcomers. = Reading the latest draft -05 is required for any meaningful participation. = I would like to spend some time going over the draft section by section and= adding notes. My goal is to have a full list of comments on the draft with= all open issues listed. If you are having a problem finding parking, please use the valet service i= n front of building B (across the street from building E where we will be m= eeting). For planning purposes only, please email me if you plan to attend. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Monday, May 17, 2010 3:15 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Reminder: OAuth Interim Meeting, 20th May >=20 > This is a reminder of the OAuth interim meeting, which happens this > Thursday, 20th May. The meeting venue is at Yahoo 701 First Ave Sunnyvale= , > CA 94089. >=20 > Here is the info: > http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting >=20 > Be advised to read the latest OAuth specification to benefit from the > discussions: > http://tools.ietf.org/wg/oauth/draft-ietf-oauth-v2/ >=20 > Ciao > Hannes & Blaine > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon May 17 23:27:49 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1FB3A6C22 for <oauth@core3.amsl.com>; Mon, 17 May 2010 23:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=-1.687, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] 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 WH3mTDubBEdb for <oauth@core3.amsl.com>; Mon, 17 May 2010 23:27:38 -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 522373A6C92 for <oauth@ietf.org>; Mon, 17 May 2010 23:21:12 -0700 (PDT) Received: (qmail 26802 invoked from network); 18 May 2010 06:21:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 May 2010 06:20:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 17 May 2010 23:20:05 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Mon, 17 May 2010 23:20:10 -0700 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: Acr1JvrIjbWgkniMS1CtQjTRcupV4QBKx1Ag Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B699130@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTik0dKSLLVQDhodhFsO--bR43PvZKborWG1uK15t@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilsw-oR2gMi-FFZwXotl1xQaDKvszpvQLWcQO-V@mail.gmail.com> In-Reply-To: <AANLkTilsw-oR2gMi-FFZwXotl1xQaDKvszpvQLWcQO-V@mail.gmail.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_90C41DD21FB7C64BB94121FBBC2E72343B3B699130P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 06:27:49 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B699130P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why can't an image be protected with both Basic and OAuth? In this case the= browser is the OAuth client. EHL From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Sunday, May 16, 2010 11:38 AM To: Eran Hammer-Lahav Cc: Evan Gilbert; OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid Not sure if you intended this, but you are mixing user present and user not= present access control. I do NOT think we want OAuth protected images to be the same as Basic auth = protected images. I do think OpenID protected images and Basic auth are sim= ilar. With OAuth today, the user has granted explicit permission at a parti= cular resource, not any resource the user may have access to. -- Dick On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <eran@hueniverse.com<mai= lto:eran@hueniverse.com>> wrote: Today when I cut/paste a URI of an image using Basic auth, the browser know= s exactly what to do. I want to do the same with an OAuth-protected image. = Saying that there aren't standards API out there to benefit from this is in= correct. There are plenty. This is complete discovery for the authentication layer. The rest doesn't b= elong here, the same way this doesn't belong as part of the API specificati= on. EHL From: Evan Gilbert [mailto:uidude@google.com<mailto:uidude@google.com>] Sent: Thursday, May 13, 2010 9:16 AM To: Eran Hammer-Lahav Cc: Manger, James H; OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <eran@hueniverse.com<mai= lto:eran@hueniverse.com>> wrote: You are trying to match a mechanism designed for automatic discovery with a= system designed to require paperwork. It sounds like for your use cases, y= ou will not be using this optional parameter and just document how to use y= our API (i.e. hardcode your security setup and API format). I'm saying it should be a fully automatic discovery or use paperwork. Havin= g an API return valid URL prefixes to send the token to without having an A= PI to determine the actual URLs you send tokens to seems odd. The whole point of this is that the developer isn't involved. The library t= akes care of everything. All the developer does is ask to get a protected r= esource. The library will check if it already has a valid token for that re= source (based on the security restrictions provided by the sites parameter,= and the scope requirements - two very separate things). This is an incomplete mechanism for automatic discovery. How does the devel= oper find out where to ask for the protected resource in the first place? So yes - if your developers have plenty of stuff to hardcode already, this = adds little value. EHL From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Evan Gilbert Sent: Thursday, May 13, 2010 9:00 AM To: Manger, James H Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Wed, May 12, 2010 at 11:52 PM, Manger, James H <James.H.Manger@team.tels= tra.com<mailto:James.H.Manger@team.telstra.com>> wrote: Evan, > The key point is that this discovery covers a lot of the same grounds as = the sites parameter, and it's hard to define semantics around a sites para= meter without understanding the semantics of scopes and API endpoints. I strongly disagree. The semantics are crystal clear: "Here is a token. It is INSECURE to send it anywhere not in this list." These semantics are useful regardless of what the API does, how the client = is using it, or how much (or how little) the client knows about the API. To expand - it's hard to define *useful* semantics around a sites parameter= without understanding the semantics of scopes and API endpoints. Yes, you = can define crystal clear semantics, but these are not useful unless they wo= rk well with the way developers figure out the endpoints to call APIs. > Clients need to [know] more about these links (at least the response form= at). That knowledge comes from other standards (HTML, Atom, wiki of rel values..= .) and is totally independent of whether a token should or should not be se= nt. In our use cases, clients almost always need to know more about the API: - How to call directly - we have no API endpoints that are only arrived at = by links - Response format of the data > The mechanism they use to find out about these links - documentation, dis= covery, data returned with token request - could also provide the informati= on about whether a token should be sent to a particular API. Could, but shouldn't and doesn't in practise. It is much much better to have the information about how to use a token sec= urely delivered at the same time & place as receiving that token, and with = minimal assumptions about how much the client apps knows about the service. So why wouldn't we return a list of specific API endpoints instead of a "si= tes" parameter? Developers are going to call the APIs endpoints that they know about. If th= ere is a conflict between this and the sites parameter, what should they do= ? For example, if facebook returns a sites parameter "https://unknown.faceb= ook.com/", do we think the developer is going to not try to use the access = token on https://graph.facebook.com/<https://graph.facebook.com/*> ? Separating the concept of sites from API endpoints feels like a bad idea. D= iscovery / docs will give you a list of URLs where you should send tokens. = The "sites" parameter will give you a list of URLs where you can send token= s. This is redundant, and will lead to developers / libraries not respectin= g the sites parameter. If developers / libraries don't respect it, then the= service can't rely on it for enforcing security. Another note: Where do we anticipate clients storing the sites parameter in= the User-Agent flow? Right now the access token can be set as an HTTP cook= ie by the client. Do we expect them to set a separate "sites" cookie and re= spect this on their server when making requests? This seems complicated. > I should be more concrete about the use cases I see. Let's assume there's= an API where there are two endpoints, each with an associated permission > - contacts.list permission -> http://contacts.serviceprovider.com/contact= s/list > - calendar.get permission -> http://calendar.serviceprovider.com/calendar= /get > > If the response to an authorization request includes the authorized scope= s (contacts.list, calendar.get), then the "sites" parameter is redundant. I'll admit that "sites" is redundant if a client has *perfect* knowledge ab= out a service, but so is pretty much any standard at that point. Consider a generic search spider tool that you point at http://calendar.ser= viceprovider.com/calendar/get. It can do its job with no knowledge about wh= at "calendar.get" means -- but it still needs to know (as it spiders along)= when it is safe to expose the token. How does the generic search spider know to call to http://calendar.servicep= rovider.com/calendar/get in the first place? -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B699130P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Why can&#= 8217;t an image be protected with both Basic and OAuth? In this case the br= owser is the OAuth client.<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'= ><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:= 11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>EHL<o:p></o:p></sp= an></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style= =3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><di= v><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0i= n 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-fam= ily:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;= font-family:"Tahoma","sans-serif"'> Dick Hardt [mailto:dick.hardt@gmail.com= ] <br><b>Sent:</b> Sunday, May 16, 2010 11:38 AM<br><b>To:</b> Eran Hammer-= Lahav<br><b>Cc:</b> Evan Gilbert; OAuth WG<br><b>Subject:</b> Re: [OAUTH-WG= ] Indicating sites where a token is valid<o:p></o:p></span></p></div></div>= <p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Not sure if = you intended this, but you are mixing user present and user not present acc= ess control.<o:p></o:p></p><div><p class=3DMsoNormal><br>I do NOT think we = want OAuth protected images to be the same as Basic auth protected images. = I do think OpenID protected images and Basic auth are similar. With OAuth t= oday, the user has granted explicit permission at a particular resource, no= t any resource the user may have access to.<o:p></o:p></p></div><div><p cla= ss=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>-- Dick= <o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p><div><p= class=3DMsoNormal>On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <<= a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com</a>> wrote:<o:= p></o:p></p><div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto= ;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'= >Today when I cut/paste a URI of an image using Basic auth, the browser kno= ws exactly what to do. I want to do the same with an OAuth-protected image.= Saying that there aren’t standards API out there to benefit from thi= s is incorrect. There are plenty.</span><o:p></o:p></p><p class=3DMsoNormal= style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style= =3D'font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=3D= MsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><spa= n style=3D'font-size:11.0pt;color:#1F497D'>This is complete discovery for t= he authentication layer. The rest doesn’t belong here, the same way t= his doesn’t belong as part of the API specification.</span><o:p></o:p= ></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-botto= m-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'> </span><o:= p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margi= n-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'>EHL</span= ><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-m= argin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'> = ;</span><o:p></o:p></p><div style=3D'border:none;border-left:solid blue 1.5= pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none;border-top:sol= id #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal style=3D'm= so-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style=3D'font-s= ize:10.0pt'>From:</span></b><span style=3D'font-size:10.0pt'> Evan Gilbert = [mailto:<a href=3D"mailto:uidude@google.com" target=3D"_blank">uidude@googl= e.com</a>] <br><b>Sent:</b> Thursday, May 13, 2010 9:16 AM<br><b>To:</b> Er= an Hammer-Lahav<br><b>Cc:</b> Manger, James H; OAuth WG</span><o:p></o:p></= p><div><div><p class=3DMsoNormal><br><b>Subject:</b> Re: [OAUTH-WG] Indicat= ing sites where a token is valid<o:p></o:p></p></div></div></div></div><div= ><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bott= om-alt:auto'> <o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-= top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p><div><p class=3DMso= Normal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Thu,= May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <<a href=3D"mailto:eran@huen= iverse.com" target=3D"_blank">eran@hueniverse.com</a>> wrote:<o:p></o:p>= </p><div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-mar= gin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'>You are= trying to match a mechanism designed for automatic discovery with a system= designed to require paperwork. It sounds like for your use cases, you will= not be using this optional parameter and just document how to use your API= (i.e. hardcode your security setup and API format).</span><o:p></o:p></p><= /div></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-m= argin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal= style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I'm saying it= should be a fully automatic discovery or use paperwork. Having an API retu= rn valid URL prefixes to send the token to without having an API to determi= ne the actual URLs you send tokens to seems odd.<o:p></o:p></p></div><block= quote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in = 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom= :5.0pt'><div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso= -margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'>&nb= sp;</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:a= uto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F49= 7D'>The whole point of this is that the developer isn’t involved. The= library takes care of everything. All the developer does is ask to get a p= rotected resource. The library will check if it already has a valid token f= or that resource (based on the security restrictions provided by the sites = parameter, and the scope requirements – two very separate things).</s= pan><o:p></o:p></p></div></div></blockquote><div><p class=3DMsoNormal style= =3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></= p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-marg= in-bottom-alt:auto'>This is an incomplete mechanism for automatic discovery= . How does the developer find out where to ask for the protected resource i= n the first place?<o:p></o:p></p></div><blockquote style=3D'border:none;bor= der-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;ma= rgin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=3DM= soNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span= style=3D'font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p cl= ass=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto= '><span style=3D'font-size:11.0pt;color:#1F497D'>So yes – if your dev= elopers have plenty of stuff to hardcode already, this adds little value.</= span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;m= so-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F497D'>&= nbsp;</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt= :auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color:#1F= 497D'>EHL</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top= -alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;color= :#1F497D'> </span><o:p></o:p></p><div style=3D'border:none;border-left= :solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none= ;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNo= rmal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span = style=3D'font-size:10.0pt'>From:</span></b><span style=3D'font-size:10.0pt'= > <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces= @ietf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_= blank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Evan Gilbert<br><b>S= ent:</b> Thursday, May 13, 2010 9:00 AM</span><o:p></o:p></p><div><p class= =3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><= br><b>To:</b> Manger, James H<br><b>Cc:</b> OAuth WG<br><b>Subject:</b> Re:= [OAUTH-WG] Indicating sites where a token is valid<o:p></o:p></p></div></d= iv></div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-b= ottom-alt:auto'> <o:p></o:p></p><p class=3DMsoNormal style=3D'mso-marg= in-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p><div><p class=3D= MsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On W= ed, May 12, 2010 at 11:52 PM, Manger, James H <<a href=3D"mailto:James.H= .Manger@team.telstra.com" target=3D"_blank">James.H.Manger@team.telstra.com= </a>> wrote:<o:p></o:p></p><div><div><p class=3DMsoNormal style=3D'mso-m= argin-top-alt:auto;mso-margin-bottom-alt:auto'>Evan,<o:p></o:p></p><div><p = class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><b= r>> The key point is that this discovery covers a lot of the same ground= s as the sites parameter, and it's hard  to define semantics around a = sites parameter without understanding the semantics of scopes and API endpo= ints.<o:p></o:p></p></div><p class=3DMsoNormal style=3D'mso-margin-top-alt:= auto;mso-margin-bottom-alt:auto'>I strongly disagree. The semantics are cry= stal clear:<br> "Here is a token. It is INSECURE to send it anywh= ere not in this list."<br>These semantics are useful regardless of wha= t the API does, how the client is using it, or how much (or how little) the= client knows about the API.<o:p></o:p></p><div><p class=3DMsoNormal style= =3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></= p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-marg= in-bottom-alt:auto'>To expand - it's hard to define *useful* semantics = ;around a sites parameter without understanding the semantics of scopes and= API endpoints. Yes, you can define crystal clear semantics, but these are = not useful unless they work well with the way developers figure out the end= points to call APIs.<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D= 'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><= /div><blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;paddi= ng:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;ma= rgin-bottom:5.0pt'><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;ms= o-margin-bottom-alt:auto'><br><br>> Clients need to [know] more about th= ese links (at least the response format).<br><br>That knowledge comes from = other standards (HTML, Atom, wiki of rel values...) and is totally independ= ent of whether a token should or should not be sent.<o:p></o:p></p></blockq= uote><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-= bottom-alt:auto'> <o:p></o:p></p></div><div><p class=3DMsoNormal style= =3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>In our use cases, c= lients almost always need to know more about the API:<o:p></o:p></p></div><= div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom= -alt:auto'>- How to call directly - we have no API endpoints that are only = arrived at by links<o:p></o:p></p></div><p class=3DMsoNormal style=3D'mso-m= argin-top-alt:auto;mso-margin-bottom-alt:auto'>- Response format of the dat= a<o:p></o:p></p><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;= mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><blockquote style=3D= 'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;marg= in-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'>= <br><br>> The mechanism they use to find out about these links - do= cumentation, discovery, data returned with token request - could also provi= de the information about whether a token should be sent to a particular API= .<o:p></o:p></p></div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto= ;mso-margin-bottom-alt:auto'>Could, but shouldn't and doesn't in practise.<= br>It is much much better to have the information about how to use a token = securely delivered at the same time & place as receiving that token, an= d with minimal assumptions about how much the client apps knows about the s= ervice.<o:p></o:p></p></blockquote><div><p class=3DMsoNormal style=3D'mso-m= argin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><= div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom= -alt:auto'>So why wouldn't we return a list of specific API endpoints inste= ad of a "sites" parameter?<o:p></o:p></p></div><div><p class=3DMs= oNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> = <o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:= auto;mso-margin-bottom-alt:auto'>Developers are going to call the APIs endp= oints that they know about. If there is a conflict between this and the sit= es parameter, what should they do? For example, if facebook returns a sites= parameter "<a href=3D"https://unknown.facebook.com/" target=3D"_blank= ">https://unknown.facebook.com/</a>", do we think the developer is goi= ng to not try to use the access token on <span style=3D'font-size:10.0= pt'><a href=3D"https://graph.facebook.com/*" target=3D"_blank"><span style= =3D'color:#0000CC'>https://graph.facebook.com/</span></a> ? </spa= n><o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-al= t:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class= =3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><= span style=3D'font-size:10.0pt'>Separating the concept of sites from API en= dpoints feels like a bad idea. Discovery / docs will give you a list of URL= s where you should send tokens. The "sites" parameter will give y= ou a list of URLs where you can send tokens. This is redundant, and will le= ad to developers / libraries not respecting the sites parameter. If develop= ers / libraries don't respect it, then the service can't rely on it for enf= orcing security.</span><o:p></o:p></p></div><div><p class=3DMsoNormal style= =3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></= p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-marg= in-bottom-alt:auto'><span style=3D'font-size:10.0pt'>Another note: Where do= we anticipate clients storing the sites parameter in the User-Agent flow? = Right now the access token can be set as an HTTP cookie by the client. Do w= e expect them to set a separate "sites" cookie and respect this o= n their server when making requests? This seems complicated.</span><o:p></o= :p></p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso= -margin-bottom-alt:auto'> <o:p></o:p></p></div><blockquote style=3D'bo= rder:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-= left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p c= lass=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><br= ><br>> I should be more concrete about the use cases I see. Let's assume= there's an API where there are two endpoints, each with an associated perm= ission<br>> - contacts.list permission -> <a href=3D"http://contacts.= serviceprovider.com/contacts/list" target=3D"_blank">http://contacts.servic= eprovider.com/contacts/list</a><br>> - calendar.get permission -> <a = href=3D"http://calendar.serviceprovider.com/calendar/get" target=3D"_blank"= >http://calendar.serviceprovider.com/calendar/get</a><br>><br>> If th= e response to an authorization request includes the authorized scopes (cont= acts.list, calendar.get), then the "sites" parameter is redundant= .<o:p></o:p></p></div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto= ;mso-margin-bottom-alt:auto'>I'll admit that "sites" is redundant= if a client has *perfect* knowledge about a service, but so is pretty much= any standard at that point.<br><br>Consider a generic search spider tool t= hat you point at <a href=3D"http://calendar.serviceprovider.com/calendar/ge= t" target=3D"_blank">http://calendar.serviceprovider.com/calendar/get</a>. = It can do its job with no knowledge about what "calendar.get" mea= ns -- but it still needs to know (as it spiders along) when it is safe to e= xpose the token.<o:p></o:p></p></blockquote><div><p class=3DMsoNormal style= =3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></= p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-marg= in-bottom-alt:auto'>How does the generic search spider know to call to <a h= ref=3D"http://calendar.serviceprovider.com/calendar/get" target=3D"_blank">= http://calendar.serviceprovider.com/calendar/get</a> in the first place?<o:= p></o:p></p></div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:aut= o;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><blockquote style= =3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;m= argin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p = class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><b= r><br>--<br><span style=3D'color:#888888'>James Manger</span><o:p></o:p></p= ></blockquote></div></div></div><p class=3DMsoNormal style=3D'mso-margin-to= p-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></d= iv></blockquote></div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto= ;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div><= /div><p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>______________= _________________________________<br>OAuth mailing list<br><a href=3D"mailt= o:OAuth@ietf.org">OAuth@ietf.org</a><br><a href=3D"https://www.ietf.org/mai= lman/listinfo/oauth" target=3D"_blank">https://www.ietf.org/mailman/listinf= o/oauth</a><o:p></o:p></p></div><p class=3DMsoNormal><o:p> </o:p></p><= /div></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B699130P3PW5EX1MB01E_-- From eran@hueniverse.com Mon May 17 23:31:25 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F70728C170 for <oauth@core3.amsl.com>; Mon, 17 May 2010 23:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-0.709, 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 G0tJmz9pyGP7 for <oauth@core3.amsl.com>; Mon, 17 May 2010 23:31:23 -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 0A4CB3A6C84 for <oauth@ietf.org>; Mon, 17 May 2010 23:26:48 -0700 (PDT) Received: (qmail 8863 invoked from network); 18 May 2010 06:26:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 May 2010 06:26:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 17 May 2010 23:26:41 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Yaron Goland <yarong@microsoft.com> Date: Mon, 17 May 2010 23:26:45 -0700 Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: AQHK8vPryc3Stn6LIkOF1NSUvaPezpJQe5UAgAFcHQCABAdEsIAA4Jcw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B699132@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.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 WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 06:31:25 -0000 Now, this is useful. I think this raises a very good point. Unless we expect the server response= to always be just key/value pairs (regardless of the chosen serialization)= , we cannot support multiple formats. If we decide on limiting to a flat ke= y/value pairs, the value of multiple formats is significantly reduced (but = still somewhat useful). EHL > -----Original Message----- > From: Yaron Goland [mailto:yarong@microsoft.com] > Sent: Monday, May 17, 2010 2:58 PM > To: Kris Selden; Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > My concerns with C are twofold. >=20 > First, it's unclear to me how we will successfully reason about OAuth's d= ata > model when the three proposed formats all have mutually incompatible data > models? >=20 > | Forms | JSON | XML > Nesting | NO | YES | YES > Multi-Value Fields | NO | YES| NO[1] > Typing | NO | YES | NO[2] > Namespaces | NO | NO | NO > Objects | NO | YES | YES[3] >=20 > [1] There is no formal definition in XML for multi-value fields although = one > can build them using nested elements [2] XML does have XML schema but > most parsers don't natively support it [3] XML actually has two different= kinds > of objects, elements and attributes. >=20 > Will we dumb down JSON and XML to the point where they match Forms? In > other words, per Kris's mail, is OAuth's data model just name/value pairs= ? > That can work but then it calls into question why the heck we bothered > supporting JSON or XML in the first place if we are essentially just usin= g them > as Forms? It seems almost cruel to dangle the richer data models of JSON = and > XML in front of people and then pull them back with a restriction that we > only do name/value pairs. >=20 > Will we support JSON's data model? In which case do we intend to add > typing, arrays, etc. to forms and ban attributes and namespaces from XML? >=20 > Will we support XML's data model? In which case do we intend to add name > spacing and attributes to forms and JSON while banning all types but stri= ng > along with arrays in JSON? >=20 > Or maybe we'll simply assert the existence of three different worlds wher= e > every extension is defined in a completely different context independentl= y > of each other? So every extension to OAuth has to, in essence, be defined > three separate times? >=20 > Second, as a burden on server implementers we are requiring that they > possess and test three different parsers. I think this is unnecessarily o= nerous > and all but guaranteed to lead to interoperability issues as server > implementers will focus primarily on the particular syntaxes they think w= ill > see the most use and give less attention to other others. This is an inev= itable > trade off given the difficulties of fully testing even basic formats. >=20 > Thanks, >=20 > Yaron >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Kris Selden > > Sent: Friday, May 14, 2010 1:29 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > > > The only reason I've heard was interoperability but it is always > > stated as patently obvious without a given reasoning. My assumption is > > this is concern of OAuth 2 client library authors who don't want to > > depend on 3 parsing libraries but want to state they can inter-operate = with > any OAuth 2 provider. > > > > I have a suggestion to mitigate the client library dependency issue, > > an argument for why C is more "interoperable" (even why the server > > should be not be required to support all 3 formats), comments on > > encoding, and percent encoding issues with OAuth 1. > > > > Basically, what OAuth providers return are key/value pairs and this > > discussion is really an issue of serialization. > > > > Instead of depending on libraries, client providers could have a > > interface for serialization that takes a mime type and string and > > returns a structure of key value pairs. That way if I've already > > chosen libyajl (which it is, even though it is UTF8 only) as my favorit= e JSON > library, I can plug it in. > > > > Chances are your client library is going to still be more bloated than > > me just writing to a testable spec for the flows I need. Maybe even > > unusable simply because I'm using an API from an application on an > > evented server and your library uses blocking I/O for making the reques= ts. > > > > On to why C is more interoperable and why as a consumer having it just > > be one format, doesn't help me unless I'm only using JSON APIs, it > > only helps the OAuth 2 client library developer. > > > > Let's say API A supports JSON, API B supports XML and API C supports > > both (as many APIs do, oh no the horror of the QA matrix). > > > > If I'm consuming API A, be nice if the OAuth 2 endpoint used JSON. If > > I'm consuming API B would be nice if the endpoint supported XML. If I > > needed both A and B, I need 2 parsers anyways, so what the endpoint > > did doesn't matter but I would pick JSON. If A and C I would want > > JSON. If B and C I would want XML. > > > > On the server side, would be nice if a service could match the OAuth > > endpoint format. I don't really see a need to support all 3 since in > > order to use my JSON only API you need a JSON parser anyway. > > > > There is little point to an API support multiple formats as many do if > > the OAuth endpoints require JSON only. > > > > If my service is just a REST storage API, accepting binary files like > > images, I just want whatever the simplest to parse in which case I > > would like form- encoded. I really don't see why people think that > > format is complicated, been in use a long time, there is lots of > > library support, and is more trivial to write your own parser than both= JSON > and XML. > > > > The problem with application/x-www-form-urlencoded that was > > complicated in OAuth 1, had to do with signature base strings because > > some characters could be optionally encoded and various libraries did > > this. Here we are talking about key/value pair serialization that HTML > > forms have been using for a long time. The percent encoding is of > > bytes and the bytes character set is defined by the charset in the > > response header. Would not matter if some characters were optionally > percent encoded, they would still be decoded. > > > > While a lot of clients may not have an > > application/x-www-form-urlencoded parser, this problem is way > > overblown. Most have a percent-encoding decoder, needed just to parse > > URLs. Splitting on & and =3D then replacing + with space is trivial. > > This can easily be done in JavaScript, which is where I suspect some of= the > JSON only momentum is coming from. > > > > Not all JSON libraries handle the NULL position UTF detection in the > > RFC 4627, some just assume UTF8 only. I'm guessing supporting the > > other Unicode transfer encodings isn't all that popular since UTF8 is a > superset of ASCII. > > > > Even though JSON maybe the way of the future, more SDKs like the > > iPhone come with a XML parser and you'd need to find a third party > > JSON parser or roll your own. > > > > As for the QA matrix, APIs that have handled multiple formats, have > > one output structure that is serialized to different formats which > > helps mitigate testing complexity. Test the one output, then test that > > that structure can be serialized to the supported formats. You may > > make that one structure JSON, then have a filter that can translate it = to > XML. > > > > For OAuth, I think it would increase interoperability if the output > > was considered key/value string pairs and multiple serialization > > formats were available, requested through the Accept header. > > > > Or I guess you can make it so OAuth is only for JSON APIs because JSON > > is the future. Though I seem to remember that being said about XML not > long ago. > > Maybe I'm getting old. I guess I shouldn't use RSS and Atom feeds > > because they are so last year. > > > > I'm for option C plus relaxing the all 3 formats support to > > recommended but not required. > > > > On May 13, 2010, at 4:43 PM, Eran Hammer-Lahav wrote: > > > > > Can you give a reason why you are objecting to C. > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: Robert Sayre [mailto:sayrer@gmail.com] > > >> Sent: Thursday, May 13, 2010 4:27 PM > > >> To: Eran Hammer-Lahav > > >> Cc: Yaron Goland; OAuth WG (oauth@ietf.org) > > >> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > > >> > > >> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav > > >> <eran@hueniverse.com> wrote: > > >>> There is clearly no consensus for either A or B. There was mostly > > >>> no objection to C, and the reason given by most of those who > > >>> objected was > > >> client complexity with the current proposal solves. > > >> > > >> My objection to C was that your examples were buggy. So, to be > > >> tediously > > >> explicit: > > >> > > >> B, then A. Not C. > > >> > > >> - Rob > > > _______________________________________________ > > > 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 uidude@google.com Tue May 18 09:26:05 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9508F3A6C9C for <oauth@core3.amsl.com>; Tue, 18 May 2010 09:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.311 X-Spam-Level: X-Spam-Status: No, score=-100.311 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 26S++xkyNrMS for <oauth@core3.amsl.com>; Tue, 18 May 2010 09:26:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7B34A28C117 for <oauth@ietf.org>; Tue, 18 May 2010 09:18:18 -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 o4IGI64S013889 for <oauth@ietf.org>; Tue, 18 May 2010 09:18:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274199487; bh=ztlol6l/YurzWltu87ZRv6QCt9c=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=uD5rIhMRsutEfcMglupAq/lAsTrjiLi8La/aIM8pKyjMP6aI0K1BoB2VzILaFjPQr sYrV+U05aBMAOf/Kk2ucg== 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=DnmfAOGsWK/JxSITLJKh9kPsRfgvWvbeHU0Rbam/mepbbMKif6JQE949e4ifHrZft iUO76k02VCmu+Ut5gcL4g== Received: from vws8 (vws8.prod.google.com [10.241.21.136]) by wpaz1.hot.corp.google.com with ESMTP id o4IGHxNE022567 for <oauth@ietf.org>; Tue, 18 May 2010 09:18:05 -0700 Received: by vws8 with SMTP id 8so2352432vws.36 for <oauth@ietf.org>; Tue, 18 May 2010 09:18:05 -0700 (PDT) Received: by 10.229.221.72 with SMTP id ib8mr1536851qcb.0.1274199485212; Tue, 18 May 2010 09:18:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.215 with HTTP; Tue, 18 May 2010 09:11:19 -0700 (PDT) In-Reply-To: <AANLkTikZGYRUe84a5fb-QoXSdJL-hmCzFO3vUP_6Zc7r@mail.gmail.com> References: <4BE730CC.1090607@lodderstedt.net> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimfTF05EWxOdyJrUU3K3IN7kJ7RdDk3mBXN2f41@mail.gmail.com> <AANLkTilCID4z-NjAJLMQ2GHcWHm-21fWKPzXs-6y4tyZ@mail.gmail.com> <AANLkTil8-AEe0Jjid2aKuI4IADCZ_vamNng5USnMKz8E@mail.gmail.com> <DEBACE14-0DC8-44F9-92EF-AA3F8F522041@facebook.com> <AANLkTinYP_Ee9-Znge9G5lgCnq-dmVG_8y0MZvOJDJcf@mail.gmail.com> <AANLkTikdi_ajhCxdJ5DGHtarnUm4icNTODKEQgcP3rqN@mail.gmail.com> <AANLkTikZGYRUe84a5fb-QoXSdJL-hmCzFO3vUP_6Zc7r@mail.gmail.com> From: Evan Gilbert <uidude@google.com> Date: Tue, 18 May 2010 09:11:19 -0700 Message-ID: <AANLkTimSYSoeWKAgN-YJjf-E7s26uoTmGsX2QVPcm4q8@mail.gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: multipart/alternative; boundary=001636310003b06a240486e0af18 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Strict equality matching of redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 16:26:05 -0000 --001636310003b06a240486e0af18 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 17, 2010 at 8:53 AM, Marius Scurtescu <mscurtescu@google.com>wrote: > On Mon, May 17, 2010 at 8:29 AM, Evan Gilbert <uidude@google.com> wrote: > > I'd like to get a standard for redirect URI matching, but think this may > not > > be feasible - we are leaving the callback URI registration mechanism > > undefined and I've heard a number of different mechanisms that companies > > want to support. > > I think we should leave the matching undefined, possibly with a SHOULD > for > > the most common matching mechanism (URL prefix?) > > > > I'm not hugely worried about incompatibilities between different AS on > this > > front: > > 1. Clients will push us strongly towards compatible implementations. > > 2. Clients can always set up a redirector if needed for a specific AS (as > an > > aside - we need a document detailing how to build a redirector properly > > without becoming an open redirector). > > Isn't this saying that clients can always implement strict matching > and live with that? Why not require it then? > No, don't think so. Clients will use redirect behavior that works with their current provider, and deal with strict matching when/if it comes up. I'm pretty sure that norms will evolve, but also pretty sure that we won't agree right now. > > Marius > --001636310003b06a240486e0af18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Mon, May 17, 2010 at 8:53 AM, Marius = Scurtescu <span dir=3D"ltr"><<a href=3D"mailto:mscurtescu@google.com">ms= curtescu@google.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;= "> <div class=3D"im">On Mon, May 17, 2010 at 8:29 AM, Evan Gilbert <<a href= =3D"mailto:uidude@google.com">uidude@google.com</a>> wrote:<br> > I'd like to get a standard for redirect URI matching, but think th= is may not<br> > be feasible -=A0we are leaving the callback URI registration mechanism= <br> > undefined and I've heard a number of different mechanisms that com= panies<br> > want to support.<br> > I think we should leave the matching undefined, possibly with a SHOULD= for<br> > the most common matching mechanism (URL prefix?)<br> ><br> > I'm not hugely worried about incompatibilities between different A= S on this<br> > front:<br> > 1. Clients will push us strongly towards compatible implementations.<b= r> > 2. Clients can always set up a redirector if needed for a specific AS = (as an<br> > aside - we need a document detailing how to build a redirector properl= y<br> > without becoming an open redirector).<br> <br> </div>Isn't this saying that clients can always implement strict matchi= ng<br> and live with that? Why not require it then?<br></blockquote><div><br></div= ><div>No, don't think so.</div><div><br></div><div>Clients will use red= irect behavior that works with their current provider, and deal with strict= matching when/if it comes up.</div> <div><br>I'm pretty sure that norms will evolve, but also pretty sure t= hat we won't agree right now.</div><div>=A0</div><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex;"> <font color=3D"#888888"><br> Marius<br> </font></blockquote></div><br> --001636310003b06a240486e0af18-- From eran@hueniverse.com Tue May 18 13:02:15 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9DCD3A6C60 for <oauth@core3.amsl.com>; Tue, 18 May 2010 13:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_40=-0.185] 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 K5qnNV53kx5C for <oauth@core3.amsl.com>; Tue, 18 May 2010 13:02:15 -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 B90C43A6C63 for <oauth@ietf.org>; Tue, 18 May 2010 13:02:13 -0700 (PDT) Received: (qmail 11776 invoked from network); 18 May 2010 20:02:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 May 2010 20:02:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 18 May 2010 13:01:58 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: OAuth WG <oauth@ietf.org> Importance: high X-Priority: 1 Date: Tue, 18 May 2010 13:01:50 -0700 Thread-Topic: URGENT: Please let me know if you are coming to the OAuth meeting Thursday Thread-Index: Acr2xPPut2xudeY8ukCi7dft5toO9g== Message-ID: <C818403E.34467%eran@hueniverse.com> Accept-Language: en-US Content-Language: en 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 Subject: [OAUTH-WG] URGENT: Please let me know if you are coming to the OAuth meeting Thursday X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 20:02:16 -0000 We will be having an interim OAuth meeting at Yahoo! (Sunnyvale, CA) on Thursday 5/20 9am-4pm. I need to know if you plan to attend by EOD today. Please reply just to me to reduce list spam. EHL From kristoffer.gronowski@ericsson.com Tue May 18 13:43:55 2010 Return-Path: <kristoffer.gronowski@ericsson.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD87028C218 for <oauth@core3.amsl.com>; Tue, 18 May 2010 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.302 X-Spam-Level: ** X-Spam-Status: No, score=2.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_INXPNS=2.3] 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 Soaw89LkUimL for <oauth@core3.amsl.com>; Tue, 18 May 2010 13:43:50 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 0735B28C1F6 for <oauth@ietf.org>; Tue, 18 May 2010 13:40:35 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o4IKeRxm031756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <oauth@ietf.org>; Tue, 18 May 2010 15:40:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 18 May 2010 16:40:27 -0400 From: Kristoffer Gronowski <kristoffer.gronowski@ericsson.com> To: "oauth@ietf.org" <oauth@ietf.org> Date: Tue, 18 May 2010 16:40:26 -0400 Thread-Topic: draft-ietf-oauth-v2-05.txt editorial and clarification Thread-Index: Acr2yliA5zLeLKqEQvyEN+uiKU4TnA== Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F105396B6EAE@EUSAACMS0701.eamcs.ericsson.se> 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_C0AC8FAB6849AB4FADACCC70A949E2F105396B6EAEEUSAACMS0701e_" MIME-Version: 1.0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-05.txt editorial and clarification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 20:43:55 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F105396B6EAEEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! I am in the middle of implementing both the client and server side and note= d some things. Tried to check a while back to see that the issues was not raised earlier b= ut if I happen to raise a sensitive issue discussed earlier, let me know. First two minor comments on the spec. Page 30 code param is not stated if it is required or optional. A qualified= guess would be that it should be required. Page 38 & 39 two parameters named "format" one optional one required. Page 43 Contradicting statement: Access tokens SHOULD NOT be sent in the cl= ear... while the next paragraph talks about how to do it. It could be ok to keep this option but it should probably be balanced bette= r. The problem is not writing the server but the client side. One big issue is that there is no way of querying what flows a server suppo= rts. This might result in expensive and non portable library implementation= s. There could be multiple solutions: * A new rest request that can answer what flows are supported. * Use of a HTTP header (such as Accept) * Standardized response with and error code 404 or even better 501 with a l= ist of the ones supported In the response format issue I would put my vote on HTTP POST body due to l= ess library dependency. It should at least be the default and the client ne= eds to understand and make use of it in many of the flows anyway. JSON would be my second pick due to the ease of integration on browsers and= JavaScript. If possible remove XML. All this options adds to complexity and IMO will raise the cost of implemen= tation and significant need for bake off between different systems. Another point that could simplify is to only allow for parameters in the Au= thorization header for access (Scrap URI param and FORM). This has proven to be a large source of wasted implementation time with Oau= th 1.0 from the client side since the spec was too open. A developer needs to probe for every community he tries to integrate to. BR Stoffe P.s. Sorry but can't attend and discuss the proposals on Thursday due to Go= ogle IO, but will try to show up at the next meeting. --_000_C0AC8FAB6849AB4FADACCC70A949E2F105396B6EAEEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <!-- converted from rtf --> <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:= #800000 2px solid; } --></style> </head> <body> <font face=3D"Arial, sans-serif" size=3D"2"> <div>Hi!</div> <div> </div> <div>I am in the middle of implementing both the client and server side and= noted some things.</div> <div>Tried to check a while back to see that the issues was not raised earl= ier but if I happen to raise a sensitive issue discussed earlier, let me kn= ow.</div> <div> </div> <div>First two minor comments on the spec.</div> <div>Page 30 code param is not stated if it is required or optional. A qual= ified guess would be that it should be required.</div> <div>Page 38 & 39 two parameters named "format" one optional = one required.</div> <div> </div> <div>Page 43 Contradicting statement: Access tokens SHOULD NOT be sent in t= he clear… while the next paragraph talks about how to do it.</div> <div>It could be ok to keep this option but it should probably be balanced = better. The problem is not writing the server but the client side.</div> <div> </div> <div>One big issue is that there is no way of querying what flows a server = supports. This might result in expensive and non portable library implement= ations.</div> <div>There could be multiple solutions:</div> <div>* A new rest request that can answer what flows are supported.</div> <div>* Use of a HTTP header (such as Accept)</div> <div>* Standardized response with and error code 404 or even better 501 wit= h a list of the ones supported</div> <div> </div> <div>In the response format issue I would put my vote on HTTP POST body due= to less library dependency. It should at least be the default and the clie= nt needs to understand and make use of it in many of the flows anyway.</div= > <div>JSON would be my second pick due to the ease of integration on browser= s and JavaScript. If possible remove XML.</div> <div> </div> <div>All this options adds to complexity and IMO will raise the cost of imp= lementation and significant need for bake off between different systems.</d= iv> <div>Another point that could simplify is to only allow for parameters in t= he Authorization header for access (Scrap URI param and FORM).</div> <div>This has proven to be a large source of wasted implementation time wit= h Oauth 1.0 from the client side since the spec was too open.</div> <div>A developer needs to probe for every community he tries to integrate t= o.</div> <div> </div> <div>BR Stoffe</div> <div> </div> <div>P.s. Sorry but can't attend and discuss the proposals on Thursday due = to Google IO, but will try to show up at the next meeting.  </div> <div> </div> </font> </body> </html> --_000_C0AC8FAB6849AB4FADACCC70A949E2F105396B6EAEEUSAACMS0701e_-- From danbri@danbri.org Tue May 18 13:45:17 2010 Return-Path: <danbri@danbri.org> 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 B975728C0E2 for <oauth@core3.amsl.com>; Tue, 18 May 2010 13:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Ff5z716eCsEh for <oauth@core3.amsl.com>; Tue, 18 May 2010 13:45:15 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2332128C237 for <oauth@ietf.org>; Tue, 18 May 2010 13:42:28 -0700 (PDT) Received: by wyb32 with SMTP id 32so175226wyb.31 for <oauth@ietf.org>; Tue, 18 May 2010 13:42:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.154.76 with SMTP id g54mr4462248wek.211.1274215338424; Tue, 18 May 2010 13:42:18 -0700 (PDT) Received: by 10.216.169.67 with HTTP; Tue, 18 May 2010 13:42:17 -0700 (PDT) In-Reply-To: <C818403E.34467%eran@hueniverse.com> References: <C818403E.34467%eran@hueniverse.com> Date: Tue, 18 May 2010 22:42:17 +0200 Message-ID: <AANLkTimiE21zpeM6653eAQ_UtV-W7zztefZS28CBoCjZ@mail.gmail.com> From: Dan Brickley <danbri@danbri.org> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] URGENT: Please let me know if you are coming to the OAuth meeting Thursday X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 20:45:17 -0000 On Tue, May 18, 2010 at 10:01 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > We will be having an interim OAuth meeting at Yahoo! (Sunnyvale, CA) on > Thursday 5/20 9am-4pm. > > I need to know if you plan to attend by EOD today. Please reply just to me > to reduce list spam. Is there a calendar of upcoming meetings somewhere? Dan From stpeter@stpeter.im Tue May 18 13:56:37 2010 Return-Path: <stpeter@stpeter.im> 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 EB1063A67A7 for <oauth@core3.amsl.com>; Tue, 18 May 2010 13:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 7ZeJebyVrwBM for <oauth@core3.amsl.com>; Tue, 18 May 2010 13:56:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A50BE3A67A2 for <oauth@ietf.org>; Tue, 18 May 2010 13:56:36 -0700 (PDT) Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 64A0740E3E for <oauth@ietf.org>; Tue, 18 May 2010 14:56:28 -0600 (MDT) Message-ID: <4BF2FEFB.10709@stpeter.im> Date: Tue, 18 May 2010 14:56:27 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <C818403E.34467%eran@hueniverse.com> <AANLkTimiE21zpeM6653eAQ_UtV-W7zztefZS28CBoCjZ@mail.gmail.com> In-Reply-To: <AANLkTimiE21zpeM6653eAQ_UtV-W7zztefZS28CBoCjZ@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020702050707040306060002" Subject: Re: [OAUTH-WG] URGENT: Please let me know if you are coming to the OAuth meeting Thursday X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 20:56:38 -0000 This is a cryptographically signed message in MIME format. --------------ms020702050707040306060002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/18/10 2:42 PM, Dan Brickley wrote: > On Tue, May 18, 2010 at 10:01 PM, Eran Hammer-Lahav <eran@hueniverse.co= m> wrote: >> We will be having an interim OAuth meeting at Yahoo! (Sunnyvale, CA) o= n >> Thursday 5/20 9am-4pm. >> >> I need to know if you plan to attend by EOD today. Please reply just t= o me >> to reduce list spam. >=20 > Is there a calendar of upcoming meetings somewhere? This is a (rare) in-person interim meeting. Presumably the next in-person meeting will be at IETF 78 in Maastricht: http://www.ietf.org/meeting/78/index.html Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020702050707040306060002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUxODIwNTYyN1owIwYJKoZIhvcNAQkEMRYEFJFUMlpMi6cpWRw6MjTM farAkaVHMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAhg4YEJhkZkqTvjDl6umkcY+j6HkxrDS/hmT5ipvs SHcWBQQE7DsMp7PDmEH9AeGZO3Ex2azKUzj5sAOoDvNCVld0LJwlLNdnW7ANBKWf6Mh16KtY e1t+x+jtiNn3NQ2dkgxBi/1oArwWTa4YiB/lh3ebWDWJjPLDHMtiRYUOSgAHwoPEunU6Db/R y2gT4+7B7Det8vsy4X2Swk+S0F4ZQnoU+3ZBCbwKXRYFhWWbNN4XDNDzLXbu1ZXOQANqXvUC g+efM/31sXNRToocGeMQEKXoxd6iPGRbkRlGz+4nWM6Tvw1N3w99jolFXQ5ohc/fe9c9uxHz 9YIsAiVpqapqqwAAAAAAAA== --------------ms020702050707040306060002-- From James.H.Manger@team.telstra.com Tue May 18 16:56:26 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A119B3A6A55 for <oauth@core3.amsl.com>; Tue, 18 May 2010 16:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.834 X-Spam-Level: * X-Spam-Status: No, score=1.834 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_66=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPvLYHGfwBOE for <oauth@core3.amsl.com>; Tue, 18 May 2010 16:56:25 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 23FC83A6765 for <oauth@ietf.org>; Tue, 18 May 2010 16:56:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,258,1272808800"; d="scan'208";a="2880583" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 19 May 2010 09:56:16 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5986"; a="2095640" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccvi.tcif.telstra.com.au with ESMTP; 19 May 2010 09:56:16 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 19 May 2010 09:56:16 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Wed, 19 May 2010 09:56:14 +1000 Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: Acr1V6V5RHG4XS9qSOu+PuQk5E2IDQBiV+Tw Message-ID: <255B9BB34FB7D647A506DC292726F6E11263720D85@WSMSG3153V.srv.dir.telstra.com> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634F5EA3@WSMSG3153V.srv.dir.telstra.com> <7934BAC5-7FA8-48E7-82A5-A4A17DE9146E@gmail.com> In-Reply-To: <7934BAC5-7FA8-48E7-82A5-A4A17DE9146E@gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 18 May 2010 23:56:26 -0000 RGljaywNCg0KSSBtYXkgaGF2ZSBtaXNpbnRlcnByZXRlZCB5b3UgZGVzaWduIG9iamVjdGl2ZSBv ZiAiYWxsb3dpbmcgZXhpc3Rpbmcgc3lzdGVtcyB0byB1c2UgZXhpc3RpbmcgdG9rZW5zIiBhcyBt ZWFuaW5nOiB0aGUgcmVmcmVzaF90b2tlbiBmaWVsZCBzaG91bGRuJ3QgYmUgZGVmaW5lZCBhcyBh IFVSSSBhcyBzb21lIGV4aXN0aW5nIHRva2VucyBhcmUgdG9vIGJpZyB0byBmaXQgaW4gVVJJcy4N Cg0KSWYgdGhlIHNpemUgb2YgZXhpc3RpbmcgdG9rZW5zIGlzIGFuIGlzc3VlIHRoZW4gdGhlIHVz ZXItYWdlbnQgZmxvdyB3aWxsIG5vdCB3b3JrIC0tIHNpbmNlIGl0IHJldHVybnMgYW4gYWNjZXNz X3Rva2VuIChhbmQsIG9wdGlvbmFsbHksIGEgcmVmcmVzaF90b2tlbiBhcyB3ZWxsKSBpbiBhIFVS SSBmcmFnbWVudC4NCg0KQW4gZXhpc3RpbmcgdG9rZW4gYWx3YXlzIG5lZWRzIHRvIGJlIGV4dHJh Y3RlZCBmcm9tIGEgcmVxdWVzdDogdHlwaWNhbGx5IGZyb20gYSBGT1JNLWVuY29kZWQgc3RyaW5n IG9mIHBhcmFtZXRlcnMuIERlZmluaW5nIHJlZnJlc2hfdG9rZW4gYXMgYSBVUkkgZG9lc24ndCBy ZWFsbHkgY2hhbmdlIHRoaXM6IGFuIGV4aXN0aW5nIHRva2VuIGNhbiBzdGlsbCBiZSBleHRyYWN0 ZWQgZnJvbSBhIHF1ZXJ5IHBhcmFtZXRlciBpbiBzdWNoIGEgVVJJLiBJIGJlbGlldmUgdGhpcyBz dGlsbCBtZWV0cyBhIGRlc2lnbiBvYmplY3RpdmUgb2YgYWxsb3dpbmcgZXhpc3Rpbmcgc3lzdGVt cyB0byB1c2UgZXhpc3RpbmcgdG9rZW5zLg0KDQoNClNvIEkgc3VnZ2VzdCByZW5hbWluZyByZWZy ZXNoX3Rva2VuIHRvLCBzYXksIHRva2VuX3VyaSwgYW5kIGRlZmluaW5nIGl0IHRvIGJlIGEgVVJJ Lg0KDQoNClAuUy4gQW4gYXV0aHogc2VydmljZSBjb3VsZCBldmVuIGNob29zZSB0aGUgZm9sbG93 aW5nIHNvIGEgcmVmcmVzaCByZXF1ZXN0IGxvb2tzIG11Y2ggbGlrZSB0aGUgY3VycmVudCBkcmFm dCBpZiBpdCByZWFsbHkgbmVlZGVkIHRoYXQuDQogICJ0b2tlbl91cmkiOiAiL3Rva2VuP3JlZnJl c2hfdG9rZW49OHhMT3hCdFpwOCINCg0KDQotLSANCkphbWVzIE1hbmdlcg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaWNrIEhhcmR0IFttYWlsdG86ZGljay5oYXJkdEBn bWFpbC5jb21dIA0KU2VudDogTW9uZGF5LCAxNyBNYXkgMjAxMCAxMDoyNyBBTQ0KVG86IE1hbmdl ciwgSmFtZXMgSA0KQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIGluLWFwcCBsb2dvdXQ/DQoNCg0KT24gMjAxMC0wNS0xNiwgYXQgNToyMCBQTSwg TWFuZ2VyLCBKYW1lcyBIIHdyb3RlOg0KDQo+IERpY2ssDQo+IA0KPj4gSmFtZXM6IEFuIGltcG9y dGFudCBjYXBhYmlsaXR5IG9mIHRoZSByZWZyZXNoIHRva2VuIGlzIHRoYXQgaXQgKmNhbiogYmUg YSBzZWxmIGNvbnRhaW5lZCB0b2tlbiBpbiB0aGF0IGlzIG5vdCBhbiBpZCwgYnV0IGEgc2lnbmVk IHRva2VuIHRoYXQgY2FuIGJlIGV4YW1pbmVkIGFuZCBhY3RlZCB1cG9uIG9uIHByZXNlbnRhdGlv bi4NCj4gDQo+IERlZmluaW5nIHJlZnJlc2hfdG9rZW4gYXMgYSBVUkkgZG9lcyBub3QgcHJldmVu dCBpdCBiZWluZyBhIHNlbGYtY29udGFpbmVkIHNpZ25lZCB0b2tlbi4NCj4gDQo+IFRoZSBvbmx5 IGxpbWl0YXRpb24gaW1wbGllZCBpcyBhIFVSSSBzaXplIGxpbWl0LiBBIGZldyBLQiwgaG93ZXZl ciwgaXMgbm90IHRoYXQgb25lcm91cyBhIGxpbWl0IC0tIGl0IGlzIHN1ZmZpY2llbnQgdG8gaG9s ZCBhIDQwOTYtYml0IFJTQSBzaWduYXR1cmUgd2l0aCBhIGNvdXBsZSBvZiBLQiBvdmVyIGZvciBw ZXJtaXNzaW9ucyBldGMuKS4NCg0KQWdyZWVkLCBhIHRva2VuIGNvdWxkIGJlIGEgc2VsZiBjb250 YWluZWQgdG9rZW4uIEEgZGVzaWduIG9iamVjdGl2ZSB3YXMgYWxsb3dpbmcgZXhpc3Rpbmcgc3lz dGVtcyB0byB1c2UgZXhpc3RpbmcgdG9rZW5zLg0KDQotLSBEaWNrDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFuZ2VyLCBKYW1lcyBIDQpTZW50OiBG cmlkYXksIDE0IE1heSAyMDEwIDEyOjEwIEFNDQpUbzogVG9yc3RlbiBMb2RkZXJzdGVkdDsgT0F1 dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gaW4tYXBwIGxv Z291dD8NCg0KVG9yc3RlbiwNCg0KPiBXaGF0IGFib3V0IHJlZnJlc2ggdG9rZW4gcmV2b2NhdGlv bi9kZWxldGlvbj8NCg0KSFRUUCBhbHJlYWR5IGhhcyBhIG1ldGhvZCB0byBkbyB0aGlzOiBERUxF VEUNCkl0IGp1c3QgbmVlZHMgZWFjaCB0b2tlbiB0byBoYXZlIGEgVVJJLg0KDQpUb2tlbnMgKGFs bW9zdCkgYWxyZWFkeSBoYXZlIFVSSXMgLS0gaXRzIGp1c3Qgbm90IGltbWVkaWF0ZWx5IG9idmlv dXMgYmVjYXVzZSB0aGUgVVJJIGhhcyB0byBiZSBidWlsdCBmcm9tIGEgY29tbW9uIHRva2VuIGVu ZHBvaW50IGFuZCBhIHJlZnJlc2hfdG9rZW4uDQoNCkkgdGhpbmsgaXQgd291bGQgaW1wcm92ZSB0 aGUgc3BlYyBpZiByZWZyZXNoX3Rva2VuIHdhcyByZW5hbWVkIHRvLCBzYXksIHRva2VuX2lkOyBh bmQgaXRzIHZhbHVlIGRlZmluZWQgYXMgYSBVUkkgKHdoaWNoIGNhbiBiZSBhIHJlbGF0aXZlIFVS SSBzbyB0aGUgc3RyaW5nIG1heSBub3QgbmVlZCB0byBjaGFuZ2UgYXQgYWxsKS4NCg0KVG8gcmVm cmVzaCBhIHRva2VuIHlvdSBQT1NUIHRvIHRoZSB0b2tlbidzIFVSSS4NClRvIGRlbGV0ZSBhIHRv a2VuIHlvdSBzZW5kIGEgREVMRVRFIHJlcXVlc3QgdG8gdGhlIHRva2VuJ3MgVVJJLg0KDQpJdCBk b2Vzbid0IGNhdXNlIG1ham9yIGNoYW5nZXMsIGJ1dCB0aGVyZSBhcmUgc29tZSBiZW5lZml0cy4N Ckl0IGlzIGEgbW9yZSB3ZWItc3R5bGUgZGVzaWduLg0KSXQgbGVhdmVzIG9ubHkgMSB0eXBlIG9m IHRva2VuIGluIHRoZSBzcGVjIC0tIGFuIGFjY2VzcyB0b2tlbiAtLSB3aGljaCBzaW1wbGlmaWVz IHRoZSB0ZXh0IGFuZCBhaWRzIHVuZGVyc3RhbmRpbmcuDQpUaGVyZSBhcmUgbm8gYXJndW1lbnRz IGFib3V0IGxlbmd0aCwgYWxsb3dlZCBjaGFycyBldGMgYmVjYXVzZSBpdCBpcyBhIFVSSSAtLSBh IHdlbGwta25vd24gdHlwZSwgb2Z0ZW4gd2l0aCBuYXRpdmUgc3VwcG9ydC4NCkl0cyBvYnZpb3Vz IGhvdyB0byBkZWxldGUgdGhlIHRva2VuIGFzIHRoZXJlIGlzIGEgc3RhbmRhcmQgSFRUUCBtZXRo b2QgREVMRVRFIHRvIGFwcGx5IHRvIHRoZSB0b2tlbiBVUkkuDQoNCklmIGEgcGFydGljdWxhciBz ZXJ2aWNlIHN1cHBvcnRlZCBhbiBhZGRpdGlvbmFsIHdheSB0byBkZWxldGUgaXRlbXMgaW4gaXRz IEFQSSAoZWcgUE9TVCB3aXRoIGEgbWV0aG9kPWRlbGV0ZSBxdWVyeSBwYXJhbWV0ZXIpIHRoYXQg Y291bGQgYXBwbHkgdG8gdGhlIE9BdXRoIHBhcnQgYXMgd2VsbC4NCg0KLS0NCkphbWVzIE1hbmdl cg0K From eran@hueniverse.com Wed May 19 14:56:45 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6AD3A689B for <oauth@core3.amsl.com>; Wed, 19 May 2010 14:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.072 X-Spam-Level: X-Spam-Status: No, score=-1.072 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_50=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 v3cWJfp3PCsa for <oauth@core3.amsl.com>; Wed, 19 May 2010 14:56:44 -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 F1B513A6AB6 for <oauth@ietf.org>; Wed, 19 May 2010 14:56:38 -0700 (PDT) Received: (qmail 9508 invoked from network); 19 May 2010 21:56:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 May 2010 21:56:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 19 May 2010 14:56:22 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: OAuth WG <oauth@ietf.org> Date: Wed, 19 May 2010 14:56:21 -0700 Thread-Topic: WG Meeting Information 5/20 Thread-Index: Acr3nh3HH4VPsMPIZkiahCdZR561hw== Message-ID: <C819AC95.34585%eran@hueniverse.com> Accept-Language: en-US Content-Language: en 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 Subject: [OAUTH-WG] WG Meeting Information 5/20 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 19 May 2010 21:56:45 -0000 The interim working meeting will be held tomorrow in Sunnyvale, CA, hosted by Yahoo!: 701 1st Ave Building E classroom 9 Sunnyvale, CA We will start at 9am with a lunch bread at 12:30 and a snack break at 3pm. Parking is available next to building E, but if you cannot find parking, please use the valet service in front of buildings A/D in the main entrance= . If you are having any problems getting in, please call my cell 408-596-1974= . We will start by creating an agenda. I would like us to go through the entire specification (draft -05) and list all open issues and comments. We will also discuss other items not in the draft. We are working on providing a WebEx session and details will be provided on the list. EHL From recordond@gmail.com Wed May 19 15:14:24 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC423A6A6D for <oauth@core3.amsl.com>; Wed, 19 May 2010 15:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.94 X-Spam-Level: X-Spam-Status: No, score=-0.94 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_50=0.001, 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 0owJrMPkEsSQ for <oauth@core3.amsl.com>; Wed, 19 May 2010 15:14:22 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 295093A6AB2 for <oauth@ietf.org>; Wed, 19 May 2010 15:14:17 -0700 (PDT) Received: by iwn42 with SMTP id 42so3597505iwn.31 for <oauth@ietf.org>; Wed, 19 May 2010 15:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=rYFg0obqfdagJ+V7tqrjQBpJK8GmYenjGBsKemmixqg=; b=vmN52fkxGKCVbJENbB5inn+cYzXFe73NmYmXiISy2acITv0RkJ+aov5gKhEoptb4EP EJvg7sTjwIWBI0m0VMQzZIKZlL72/1PvD6goaAmqTEMQz+/dYXcwpeRkzZHKfU7yzgHF /gPOBOcWuG0JrRSmAMEsen/8lfvic2hsQooak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ShM/o8jPwV0AVOtpMbo6w4TO2W2EhTzBVnUywbwI+aUHrjRoA6Eabr7ikMO2SknWm8 lwDsLMmA9l5Q1TgtZh+bwwpmDf0+HsbX0rRkMsX31dwcRQQ+dOoixYKEOr3yN+ZvwqaB Af6FvGxVs5A4fg2BGaj0MlFzaSLE4OQMwquIU= MIME-Version: 1.0 Received: by 10.231.156.1 with SMTP id u1mr4424096ibw.46.1274307245953; Wed, 19 May 2010 15:14:05 -0700 (PDT) Received: by 10.231.192.6 with HTTP; Wed, 19 May 2010 15:14:05 -0700 (PDT) Date: Wed, 19 May 2010 15:14:05 -0700 Message-ID: <AANLkTim5w390VPzovXNp9QSau07kuFHKZEUZeTfh7lBo@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: multipart/alternative; boundary=001636c931e4bad2850486f9c60a Subject: [OAUTH-WG] 37signals ships draft 5 of the web server and user agent flows X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 19 May 2010 22:14:24 -0000 --001636c931e4bad2850486f9c60a Content-Type: text/plain; charset=ISO-8859-1 Sweet! http://groups.google.com/group/37signals-api/browse_thread/thread/86b0da52134c1b7e > OAuth 2 is a standard way for third-party apps to get authorized access to > a user's account without needing to copy/paste API keys or ask users for > sensitive usernames and passwords. > We've added OAuth 2 directly to 37signals ID, so your apps can authorize a > 37signals ID once then access any of its accounts on any product. > The typical flow for a web app: 1. Your app requests authorization by redirecting your user to Launchpad: https://launchpad.37signals.com/authorization/new?type=web_server&cli. > .. 2. We authenticate their 37signals ID and ask whether it's ok to give > access to your app. Example of what this screen looks like: > https://launchpad.37signals.com/authorization/new?type=web_server&cli... 3. We redirect the user back to your app with a time-limited verification > code. 4. Your app makes a backchannel request to redeem the verification code > for an access token: POST > https://launchpad.37signals.com/authorization/token 5. We authenticate your app and issue an access token. 6. Your app uses the token to authorize API requests to any of the > 37signals ID's accounts. > To get info about the 37signals ID you authorized and the accounts you have > access to, make an authorized request to > https://launchpad.37signals.com/authorization.json (or > /authorization.xml). > OAuth 2 implementation notes: * Start by reading the draft spec at > http://tools.ietf.org/html/draft-ietf-oauth-v2 and trying the client > libraries at http://wiki.oauth.net/OAuth-2 * We implement draft 5 and will update our implementation as the final > spec converges, so be prepared for changes along the way. * We support the web_server and user_agent flows, not the > client_credentials or device flows. * We issue refresh tokens. Use them to request a new access token when > yours expires (2 week lifetime, currently). * We return more verbose errors than what's given in the spec to help with > client development. We'll move these to a separate parameter later. > Register your app at https://integrate.37signals.com to get started! -- Jeremy Kemper 37signals --001636c931e4bad2850486f9c60a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Sweet!</div><div><br></div><a href=3D"http://groups.google.com/group/3= 7signals-api/browse_thread/thread/86b0da52134c1b7e">http://groups.google.co= m/group/37signals-api/browse_thread/thread/86b0da52134c1b7e</a><div>=A0</di= v> <blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0= px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-= left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex= ; "> OAuth 2 is a standard way for third-party apps to get authorized access to = a user's account without needing to copy/paste API keys or ask users fo= r sensitive usernames and passwords.</blockquote><blockquote class=3D"gmail= _quote" style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; ma= rgin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, = 204); border-left-style: solid; padding-left: 1ex; "> <br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px= ; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-wi= dth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; = padding-left: 1ex; "> We've added OAuth 2 directly to 37signals ID, so your apps can authoriz= e a 37signals ID once then access any of its accounts on any product.=A0</b= lockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margi= n-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1p= x; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding= -left: 1ex; "> <br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px= ; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-wi= dth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; = padding-left: 1ex; "> The typical flow for a web app:=A0</blockquote><blockquote class=3D"gmail_q= uote" style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; marg= in-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 20= 4); border-left-style: solid; padding-left: 1ex; "> =A0=A01. Your app requests authorization by redirecting your user to Launch= pad:=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: = 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left= -width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: soli= d; padding-left: 1ex; "> =A0=A0 =A0 =A0<a href=3D"https://launchpad.37signals.com/authorization/new?= type=3Dweb_server&cli.">https://launchpad.37signals.com/authorization/n= ew?type=3Dweb_server&cli.</a>..=A0</blockquote><blockquote class=3D"gma= il_quote" style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204= , 204); border-left-style: solid; padding-left: 1ex; "> =A0=A02. We authenticate their 37signals ID and ask whether it's ok to = give access to your app.=A0</blockquote><blockquote class=3D"gmail_quote" s= tyle=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left= : 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bor= der-left-style: solid; padding-left: 1ex; "> =A0=A0 =A0 =A0Example of what this screen looks like: <a href=3D"https://la= unchpad.37signals.com/authorization/new?type=3Dweb_server&cli.">https:/= /launchpad.37signals.com/authorization/new?type=3Dweb_server&cli.</a>..= =A0</blockquote> <blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0= px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-= left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex= ; "> =A0=A03. We redirect the user back to your app with a time-limited verifica= tion code.=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin= -top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; borde= r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style= : solid; padding-left: 1ex; "> =A0=A04. Your app makes a backchannel request to redeem the verification co= de for an access token: POST <a href=3D"https://launchpad.37signals.com/aut= horization/token">https://launchpad.37signals.com/authorization/token</a>= =A0</blockquote> <blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0= px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-= left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex= ; "> =A0=A05. We authenticate your app and issue an access token.=A0</blockquote= ><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: = 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border= -left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1e= x; "> =A0=A06. Your app uses the token to authorize API requests to any of the 37= signals ID's accounts.=A0</blockquote><blockquote class=3D"gmail_quote"= style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-le= ft: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); b= order-left-style: solid; padding-left: 1ex; "> <br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px= ; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-wi= dth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; = padding-left: 1ex; "> To get info about the 37signals ID you authorized and the accounts you have= access to, make an authorized request to <a href=3D"https://launchpad.37si= gnals.com/authorization.json">https://launchpad.37signals.com/authorization= .json</a> (or /authorization.xml).=A0</blockquote> <blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0= px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-= left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex= ; "> <br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px= ; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-wi= dth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; = padding-left: 1ex; "> OAuth 2 implementation notes:=A0</blockquote><blockquote class=3D"gmail_quo= te" style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204)= ; border-left-style: solid; padding-left: 1ex; "> =A0=A0* Start by reading the draft spec at <a href=3D"http://tools.ietf.org= /html/draft-ietf-oauth-v2">http://tools.ietf.org/html/draft-ietf-oauth-v2</= a> and trying the client libraries at <a href=3D"http://wiki.oauth.net/OAut= h-2">http://wiki.oauth.net/OAuth-2</a>=A0</blockquote> <blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0= px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-= left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex= ; "> =A0=A0* We implement draft 5 and will update our implementation as the fina= l spec converges, so be prepared for changes along the way.=A0</blockquote>= <blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0= px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-= left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex= ; "> =A0=A0* We support the web_server and user_agent flows, not the client_cred= entials or device flows.=A0</blockquote><blockquote class=3D"gmail_quote" s= tyle=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left= : 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bor= der-left-style: solid; padding-left: 1ex; "> =A0=A0* We issue refresh tokens. Use them to request a new access token whe= n yours expires (2 week lifetime, currently).=A0</blockquote><blockquote cl= ass=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0px; margin-bot= tom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rg= b(204, 204, 204); border-left-style: solid; padding-left: 1ex; "> =A0=A0* We return more verbose errors than what's given in the spec to = help with client development. We'll move these to a separate parameter = later.=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top= : 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-le= ft-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: so= lid; padding-left: 1ex; "> <br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0px= ; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-wi= dth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; = padding-left: 1ex; "> Register your app at <a href=3D"https://integrate.37signals.com">https://in= tegrate.37signals.com</a> to get started!=A0</blockquote><blockquote class= =3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0px; margin-bottom= : 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(2= 04, 204, 204); border-left-style: solid; padding-left: 1ex; "> --=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin-top: 0p= x; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-w= idth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid;= padding-left: 1ex; "> Jeremy Kemper=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"mar= gin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; bo= rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st= yle: solid; padding-left: 1ex; "> 37signals</blockquote> --001636c931e4bad2850486f9c60a-- From mscurtescu@google.com Wed May 19 17:43:40 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BB83A69E6 for <oauth@core3.amsl.com>; Wed, 19 May 2010 17:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.483 X-Spam-Level: X-Spam-Status: No, score=-104.483 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_50=0.001, 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 EC5JhGvXfKOe for <oauth@core3.amsl.com>; Wed, 19 May 2010 17:43:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 776943A63C9 for <oauth@ietf.org>; Wed, 19 May 2010 17:43:38 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o4K0hOCV021166 for <oauth@ietf.org>; Wed, 19 May 2010 17:43:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274316208; bh=jVcVS+M+NETkc45R2QxkE5PA9ws=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=T6WCdzcxecvxPYdXxdW7ubKviZ+DxFT4Ah9x7OtThAv2d0EnOh/lrPNrywijdArnq 8dm5esxLtsNzls3InX83A== 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:content-transfer-encoding:x-system-of-record; b=cuBidma+TYorksi9XckqL4i7MbBwO7ozfbjjRoDWNOmHzyxiY1uCN77gBOASW+M2p TVzqwlumh1XCH+h5OWt9Q== Received: from pxi8 (pxi8.prod.google.com [10.243.27.8]) by wpaz13.hot.corp.google.com with ESMTP id o4K0hMYi024253 for <oauth@ietf.org>; Wed, 19 May 2010 17:43:23 -0700 Received: by pxi8 with SMTP id 8so3413569pxi.30 for <oauth@ietf.org>; Wed, 19 May 2010 17:43:22 -0700 (PDT) Received: by 10.140.58.7 with SMTP id g7mr6939541rva.37.1274316202218; Wed, 19 May 2010 17:43:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Wed, 19 May 2010 17:43:02 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B699132@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B699132@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 19 May 2010 17:43:02 -0700 Message-ID: <AANLkTinlwZpM4PBHSR1t1whWR2p38PHq9VpcJw4p77vs@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 00:43:40 -0000 On Mon, May 17, 2010 at 11:26 PM, Eran Hammer-Lahav <eran@hueniverse.com> w= rote: > Now, this is useful. Yes, it is very useful. One minor correction, forms do support multi-value fields. Also, XML supports name spaces. > I think this raises a very good point. Unless we expect the server respon= se to always be just key/value pairs (regardless of the chosen serializatio= n), we cannot support multiple formats. If we decide on limiting to a flat = key/value pairs, the value of multiple formats is significantly reduced (bu= t still somewhat useful). Since we cannot have pure JSON I think we have to limit to flat key/value pairs. Only direct responses are JSON, form/url encoded still has to be used: - direct requests - through browser requests - through browser responses - through browser fragment responses Considering the above, and also that: - JSON will complicate library implementations because of dependencies - clients using libraries are completely isolated from direct response form= ats I still don't see the point of using JSON. Even if a client implements everything from scratch and already uses JSON (so no dependency problems) it still has to also support form-encoded as well. Frameworks may help to some extent with query parameters (but if that's the case, then most likely the framework can help with all form-encoded cases), but there still are the other two cases. Can we still discuss this tomorrow? Marius > > EHL > >> -----Original Message----- >> From: Yaron Goland [mailto:yarong@microsoft.com] >> Sent: Monday, May 17, 2010 2:58 PM >> To: Kris Selden; Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >> >> My concerns with C are twofold. >> >> First, it's unclear to me how we will successfully reason about OAuth's = data >> model when the three proposed formats all have mutually incompatible dat= a >> models? >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Forms | JSON =A0| XML >> Nesting =A0 =A0 =A0 =A0 =A0 =A0| =A0NO =A0 | YES =A0 | YES >> Multi-Value Fields | =A0NO =A0 | YES| NO[1] >> Typing =A0 =A0 =A0 =A0 =A0 =A0 | =A0NO =A0 | YES =A0 | NO[2] >> Namespaces =A0 =A0 =A0 =A0 | =A0NO =A0 | NO =A0 =A0| NO >> Objects =A0 =A0 =A0 =A0 =A0 =A0| =A0NO =A0 | YES =A0 | YES[3] >> >> [1] There is no formal definition in XML for multi-value fields although= one >> can build them using nested elements [2] XML does have XML schema but >> most parsers don't natively support it [3] XML actually has two differen= t kinds >> of objects, elements and attributes. >> >> Will we dumb down JSON and XML to the point where they match Forms? In >> other words, per Kris's mail, is OAuth's data model just name/value pair= s? >> That can work but then it calls into question why the heck we bothered >> supporting JSON or XML in the first place if we are essentially just usi= ng them >> as Forms? It seems almost cruel to dangle the richer data models of JSON= and >> XML in front of people and then pull them back with a restriction that w= e >> only do name/value pairs. >> >> Will we support JSON's data model? In which case do we intend to add >> typing, arrays, etc. to forms and ban attributes and namespaces from XML= ? >> >> Will we support XML's data model? In which case do we intend to add name >> spacing and attributes to forms and JSON while banning all types but str= ing >> along with arrays in JSON? >> >> Or maybe we'll simply assert the existence of three different worlds whe= re >> every extension is defined in a completely different context independent= ly >> of each other? So every extension to OAuth has to, in essence, be define= d >> three separate times? >> >> Second, as a burden on server implementers we are requiring that they >> possess and test three different parsers. I think this is unnecessarily = onerous >> and all but guaranteed to lead to interoperability issues as server >> implementers will focus primarily on the particular syntaxes they think = will >> see the most use and give less attention to other others. This is an ine= vitable >> trade off given the difficulties of fully testing even basic formats. >> >> =A0 =A0 =A0 Thanks, >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yaron >> >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Kris Selden >> > Sent: Friday, May 14, 2010 1:29 PM >> > To: Eran Hammer-Lahav >> > Cc: OAuth WG (oauth@ietf.org) >> > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >> > >> > The only reason I've heard was interoperability but it is always >> > stated as patently obvious without a given reasoning. My assumption is >> > this is concern of OAuth 2 client library authors who don't want to >> > depend on 3 parsing libraries but want to state they can inter-operate= with >> any OAuth 2 provider. >> > >> > I have a suggestion to mitigate the client library dependency issue, >> > an argument for why C is more "interoperable" (even why the server >> > should be not be required to support all 3 formats), comments on >> > encoding, and percent encoding issues with OAuth 1. >> > >> > Basically, what OAuth providers return are key/value pairs and this >> > discussion is really an issue of serialization. >> > >> > Instead of depending on libraries, client providers could have a >> > interface for serialization that takes a mime type and string and >> > returns a structure of key value pairs. That way if I've already >> > chosen libyajl (which it is, even though it is UTF8 only) as my favori= te JSON >> library, I can plug it in. >> > >> > Chances are your client library is going to still be more bloated than >> > me just writing to a testable spec for the flows I need. Maybe even >> > unusable simply because I'm using an API from an application on an >> > evented server and your library uses blocking I/O for making the reque= sts. >> > >> > On to why C is more interoperable and why as a consumer having it just >> > be one format, doesn't help me unless I'm only using JSON APIs, it >> > only helps the OAuth 2 client library developer. >> > >> > Let's say API A supports JSON, API B supports XML and API C supports >> > both (as many APIs do, oh no the horror of the QA matrix). >> > >> > If I'm consuming API A, be nice if the OAuth 2 endpoint used JSON. If >> > I'm consuming API B would be nice if the endpoint supported XML. If I >> > needed both A and B, I need 2 parsers anyways, so what the endpoint >> > did doesn't matter but I would pick JSON. If A and C I would want >> > JSON. If B and C I would want XML. >> > >> > On the server side, would be nice if a service could match the OAuth >> > endpoint format. I don't really see a need to support all 3 since in >> > order to use my JSON only API you need a JSON parser anyway. >> > >> > There is little point to an API support multiple formats as many do if >> > the OAuth endpoints require JSON only. >> > >> > If my service is just a REST storage API, accepting binary files like >> > images, I just want whatever the simplest to parse in which case I >> > would like form- encoded. I really don't see why people think that >> > format is complicated, been in use a long time, there is lots of >> > library support, and is more trivial to write your own parser than bot= h JSON >> and XML. >> > >> > The problem with application/x-www-form-urlencoded that was >> > complicated in OAuth 1, had to do with signature base strings because >> > some characters could be optionally encoded and various libraries did >> > this. Here we are talking about key/value pair serialization that HTML >> > forms have been using for a long time. The percent encoding is of >> > bytes and the bytes character set is defined by the charset in the >> > response header. Would not matter if some characters were optionally >> percent encoded, they would still be decoded. >> > >> > While a lot of clients may not have an >> > application/x-www-form-urlencoded parser, this problem is way >> > overblown. Most have a percent-encoding decoder, needed just to parse >> > URLs. Splitting on & and =3D then replacing + with space is trivial. >> > This can easily be done in JavaScript, which is where I suspect some o= f the >> JSON only momentum is coming from. >> > >> > Not all JSON libraries handle the NULL position UTF detection in the >> > RFC 4627, some just assume UTF8 only. I'm guessing supporting the >> > other Unicode transfer encodings isn't all that popular since UTF8 is = a >> superset of ASCII. >> > >> > Even though JSON maybe the way of the future, more SDKs like the >> > iPhone come with a XML parser and you'd need to find a third party >> > JSON parser or roll your own. >> > >> > As for the QA matrix, APIs that have handled multiple formats, have >> > one output structure that is serialized to different formats which >> > helps mitigate testing complexity. Test the one output, then test that >> > that structure can be serialized to the supported formats. You may >> > make that one structure JSON, then have a filter that can translate it= to >> XML. >> > >> > For OAuth, I think it would increase interoperability if the output >> > was considered key/value string pairs and multiple serialization >> > formats were available, requested through the Accept header. >> > >> > Or I guess you can make it so OAuth is only for JSON APIs because JSON >> > is the future. Though I seem to remember that being said about XML not >> long ago. >> > Maybe I'm getting old. I guess I shouldn't use RSS and Atom feeds >> > because they are so last year. >> > >> > I'm for option C plus relaxing the all 3 formats support to >> > recommended but not required. >> > >> > On May 13, 2010, at 4:43 PM, Eran Hammer-Lahav wrote: >> > >> > > Can you give a reason why you are objecting to C. >> > > >> > > EHL >> > > >> > >> -----Original Message----- >> > >> From: Robert Sayre [mailto:sayrer@gmail.com] >> > >> Sent: Thursday, May 13, 2010 4:27 PM >> > >> To: Eran Hammer-Lahav >> > >> Cc: Yaron Goland; OAuth WG (oauth@ietf.org) >> > >> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >> > >> >> > >> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav >> > >> <eran@hueniverse.com> wrote: >> > >>> There is clearly no consensus for either A or B. There was mostly >> > >>> no objection to C, and the reason given by most of those who >> > >>> objected was >> > >> client complexity with the current proposal solves. >> > >> >> > >> My objection to C was that your examples were buggy. So, to be >> > >> tediously >> > >> explicit: >> > >> >> > >> B, then A. Not C. >> > >> >> > >> - Rob >> > > _______________________________________________ >> > > 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 mscurtescu@google.com Wed May 19 18:13:14 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7D43A6817 for <oauth@core3.amsl.com>; Wed, 19 May 2010 18:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.453 X-Spam-Level: X-Spam-Status: No, score=-104.453 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_50=0.001, 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 wNt9QDDoYH4N for <oauth@core3.amsl.com>; Wed, 19 May 2010 18:13:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 290993A689B for <oauth@ietf.org>; Wed, 19 May 2010 18:13:12 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o4K1D4bp029442 for <oauth@ietf.org>; Wed, 19 May 2010 18:13:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274317985; bh=dR6nGiR4CPtXH9qJ+ZpfCcQHR6k=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=Sn1/SUm67CDprmXdADOcrA9ep50o560NNm/URy+fEqWW/IUVGQMpIL6FHW4GCldGb jzbdnFjFH+IGHxGI7HV+Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=dJTIpLOy3jckEgduoH9vkC4XldF8Pg4Aqtgemc4busjWxZ8tdeZbDWpAn5eYqTcIw 4ELPEl9F7QtfTPc34qNMA== Received: from pwj7 (pwj7.prod.google.com [10.241.219.71]) by kpbe18.cbf.corp.google.com with ESMTP id o4K1D3ec030919 for <oauth@ietf.org>; Wed, 19 May 2010 18:13:03 -0700 Received: by pwj7 with SMTP id 7so71239pwj.23 for <oauth@ietf.org>; Wed, 19 May 2010 18:13:03 -0700 (PDT) Received: by 10.141.100.16 with SMTP id c16mr6912369rvm.29.1274317983325; Wed, 19 May 2010 18:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Wed, 19 May 2010 18:12:43 -0700 (PDT) From: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 19 May 2010 18:12:43 -0700 Message-ID: <AANLkTilcv8e_Qz7SFA9KVxmWPGe7TbspeGDgff0uUIRO@mail.gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] Native Apps support X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 01:13:14 -0000 I think there are a few open issues around Native App support. While all flows can be used by native apps I am referring only to the ones that involve a browser: - web server - user-agent - device For the web server flow to support native apps we need to clarify: - un-registered clients, I think this is supported, just double checking - optional redirect_uri, if missing then the authorization server should present a default result page, see next - standard way to add verification code and state to window title when authz server uses default result page For the device flow to support native apps: - require authorization servers to accept GET requests to verification_uri with user_code added as a query parameter using "user_code" as parameter name The user-agent flow I think works as is, but it has several limitations, I can get into details. The only advantage over web server is the fact that it does not need a direct call to swap the verification code, minor IMO. I would suggest that the spec does not recommend this flow to be used with native apps. Marius From James.H.Manger@team.telstra.com Wed May 19 18:33:21 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A023A67CC for <oauth@core3.amsl.com>; Wed, 19 May 2010 18:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.542 X-Spam-Level: * X-Spam-Status: No, score=1.542 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLL+s6zWggJ7 for <oauth@core3.amsl.com>; Wed, 19 May 2010 18:33:20 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 3AAF43A6AE2 for <oauth@ietf.org>; Wed, 19 May 2010 18:33:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,267,1272808800"; d="scan'208";a="2885550" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 20 May 2010 11:33:11 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5987"; a="2221608" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccni.tcif.telstra.com.au with ESMTP; 20 May 2010 11:33:11 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Thu, 20 May 2010 11:33:11 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 20 May 2010 11:33:09 +1000 Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: Acr3tYANhdRahVCGTR2ja6uzRtucDQAAllwg Message-ID: <255B9BB34FB7D647A506DC292726F6E112637B8285@WSMSG3153V.srv.dir.telstra.com> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B699132@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinlwZpM4PBHSR1t1whWR2p38PHq9VpcJw4p77vs@mail.gmail.com> In-Reply-To: <AANLkTinlwZpM4PBHSR1t1whWR2p38PHq9VpcJw4p77vs@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 01:33:21 -0000 TWFyaXVzLA0KDQo+IE9ubHkgZGlyZWN0IHJlc3BvbnNlcyBhcmUgSlNPTiwgZm9ybS91cmwgZW5j b2RlZA0KPiBzdGlsbCBoYXMgdG8gYmUgdXNlZDoNCj4gLSBkaXJlY3QgcmVxdWVzdHMNCj4gLSB0 aHJvdWdoIGJyb3dzZXIgcmVxdWVzdHMNCj4gLSB0aHJvdWdoIGJyb3dzZXIgcmVzcG9uc2VzDQo+ IC0gdGhyb3VnaCBicm93c2VyIGZyYWdtZW50IHJlc3BvbnNlcw0KDQpBIGJldHRlciBzb2x1dGlv biB3b3VsZCBiZSB0byBjaGFuZ2UgdGhlIGxhc3QgdHdvICh0b2tlbiBpbmZvIGRlbGl2ZXJlZCBp biBhIGNhbGxiYWNrIFVSSXMpIHNvIGEgc2luZ2xlIHBhcmFtZXRlciAoaW4gdGhlIHF1ZXJ5IG9y IGZyYWdtZW50KSBob2xkcyBhbGwgdGhlIHRva2VuIGluZm8gLS0gYXMgYSBiYXNlNjR1cmwtZW5j b2RlZCBKU09OIHZhbHVlLg0KDQpUaGF0IGlzIG1vcmUgY29tcGxpY2F0ZWQgaWYgeW91IGFyZSBv bmx5IGRlbGl2ZXJpbmcgYSBzaW5nbGUgcXVhbnRpdHkgKGVnIGp1c3QgYW4gYWNjZXNzX3Rva2Vu KS4gSG93ZXZlciwgdGhlIGRpZmZlcmVuY2UgZGltaW5pc2hlcyBhcyBtb3JlIGFuZCBtb3JlIGZl YXR1cmVzIGFyZSBhZGRlZDogZXhwaXJlc19pbiwgc2NvcGUsIHNpdGVzLCByZWZyZXNoX3Rva2Vu LCBhY2Nlc3NfdG9rZW5fc2VjcmV0LCByZWFsbSwgYXV0aF9zY2hlbWUsIHdoYXRldmVyLWNvbWVz LW91dC1vZi1PcGVuSUQtQ29ubmVjdCBldGMuDQoNCkEgc2luZ2xlIHBhcmFtZXRlciBmb3IgdG9r ZW4gaW5mbyBpbiBjYWxsYmFjayBVUklzIGFsc28gcmVkdWNlcyB0aGUgcmlzayBvZiBjbGFzaGlu ZyB3aXRoIGNsaWVudC1zcGVjaWZpYyBwYXJhbWV0ZXJzIGluIGNhbGxiYWNrIFVSSXMgYXMgdGhp bmdzIGFyZSBhZGRlZCBpbiB0aGUgZnV0dXJlIChlZyB0aGUgZWFybGllciBkZWJhdGUgYWJvdXQg bm8gb2F1dGhfIHByZWZpeCkuDQoNCkl0IGVsaW1pbmF0ZXMgdGhlIG5lZWQgdG8gZm9yY2UgYWxs IHNlbWFudGljcyB0byBmaXQgaW4gYSBmbGF0IGtleS92YWx1ZSBtb2RlbC4gVGhpcyBjYW4gb25s eSBnZXQgaGFyZGVyIGFzIGZlYXR1cmVzIGFyZSBhZGRlZCwgb3IgZXh0ZW5zaW9ucyBhcmUgc3Vw cG9ydGVkLiBUaGUgT3BlbklEIDIuMCBhcHByb2FjaCBvZiBuYW1lc3BhY2VzIGFuZCBwYXJhbWV0 ZXIgbmFtZSBwcmVmaXhlcyBpcyBub3QgcHJldHR5LiBKU09OIGRvZXMgbm90IHNvbHZlIHRoaXMs IGJ1dCBpdHMgc3RydWN0dXJlIGhlbHBzLg0KDQpJIHdvdWxkbid0IGJlIHN1cnByaXNlZCBpZiwg aW4gc29tZSBzY2VuYXJpb3MsIHRoZSB0b2tlbiBpbmZvIGdldHMgdG9vIGJpZyB0byBmaXQgaW4g YSBVUkkuIEluIHRoYXQgY2FzZSBldmVuIHRoZSB1c2VyLWFnZW50IGZsb3cgd2lsbCBuZWVkIHRv IG1ha2UgYSBkaXJlY3QgcmVxdWVzdCB0byBnZXQgdGhlIHRva2VuIGluZm8sIHdoaWNoIGlzIG1v cmUgbGlrZWx5IHRvIGJlIGRlbGl2ZXJlZCBhcyBKU09OLiBPcGVuSUQgYW5kIFNBTUwgaGF2ZSBm b3VuZCB0aGV5IG5lZWQgdGhpcyAoZWcgYXJ0ZWZhY3QgZmxvd3MpLg0KDQoNClBsZWFzZSBjb25z aWRlciB0aGlzIGFzIGFuIG9wZW4gaXNzdWUgZm9yIHRvZGF5J3MgbWVldGluZzogYSBzaW5nbGUg cGFyYW1ldGVyIGhvbGRpbmcgYSBiYXNlNjR1cmwtZW5jb2RlIEpTT04gdmFsdWUgZm9yIHBhY2th Z2luZyB0b2tlbiBpbmZvIGluIGEgY2FsbGJhY2sgVVJJLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From eran@hueniverse.com Wed May 19 22:11:11 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3A13A6C89 for <oauth@core3.amsl.com>; Wed, 19 May 2010 22:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 NQvMwnKwkPsj for <oauth@core3.amsl.com>; Wed, 19 May 2010 22:11: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 3349F3A6C9B for <oauth@ietf.org>; Wed, 19 May 2010 22:10:47 -0700 (PDT) Received: (qmail 21413 invoked from network); 20 May 2010 05:10:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 May 2010 05:10:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 19 May 2010 22:10:39 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 19 May 2010 22:10:50 -0700 Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: Acr3tXbMAk91Sqe0QROZ1E+wNYP5ogAJVEmA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B699794@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B699132@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinlwZpM4PBHSR1t1whWR2p38PHq9VpcJw4p77vs@mail.gmail.com> In-Reply-To: <AANLkTinlwZpM4PBHSR1t1whWR2p38PHq9VpcJw4p77vs@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 05:11:12 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, May 19, 2010 5:43 PM > To: Eran Hammer-Lahav > Cc: Yaron Goland; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) >=20 > On Mon, May 17, 2010 at 11:26 PM, Eran Hammer-Lahav > <eran@hueniverse.com> wrote: > > Now, this is useful. >=20 > Yes, it is very useful. >=20 > One minor correction, forms do support multi-value fields. Also, XML > supports name spaces. >=20 >=20 > > I think this raises a very good point. Unless we expect the server resp= onse > to always be just key/value pairs (regardless of the chosen serialization= ), we > cannot support multiple formats. If we decide on limiting to a flat key/v= alue > pairs, the value of multiple formats is significantly reduced (but still > somewhat useful). >=20 > Since we cannot have pure JSON I think we have to limit to flat key/value > pairs. Only direct responses are JSON, form/url encoded still has to be u= sed: > - direct requests > - through browser requests > - through browser responses > - through browser fragment responses >=20 > Considering the above, and also that: > - JSON will complicate library implementations because of dependencies > - clients using libraries are completely isolated from direct response fo= rmats >=20 > I still don't see the point of using JSON. >=20 > Even if a client implements everything from scratch and already uses JSON > (so no dependency problems) it still has to also support form-encoded as > well. Frameworks may help to some extent with query parameters (but if > that's the case, then most likely the framework can help with all form- > encoded cases), but there still are the other two cases. >=20 > Can we still discuss this tomorrow? I have a feeling it will come up :-) EHL =20 > Marius >=20 >=20 > > > > EHL > > > >> -----Original Message----- > >> From: Yaron Goland [mailto:yarong@microsoft.com] > >> Sent: Monday, May 17, 2010 2:58 PM > >> To: Kris Selden; Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > >> > >> My concerns with C are twofold. > >> > >> First, it's unclear to me how we will successfully reason about > >> OAuth's data model when the three proposed formats all have mutually > >> incompatible data models? > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Forms | JSON =A0| XML Nesting= =A0 =A0 =A0 =A0 =A0 =A0| =A0NO =A0 | > >> YES =A0 | YES Multi-Value Fields | =A0NO =A0 | YES| NO[1] Typing > >> | =A0NO =A0 | YES =A0 | NO[2] Namespaces =A0 =A0 =A0 =A0 | =A0NO =A0 |= NO =A0 =A0| NO > >> Objects =A0 =A0 =A0 =A0 =A0 =A0| =A0NO =A0 | YES =A0 | YES[3] > >> > >> [1] There is no formal definition in XML for multi-value fields > >> although one can build them using nested elements [2] XML does have > >> XML schema but most parsers don't natively support it [3] XML > >> actually has two different kinds of objects, elements and attributes. > >> > >> Will we dumb down JSON and XML to the point where they match Forms? > >> In other words, per Kris's mail, is OAuth's data model just name/value > pairs? > >> That can work but then it calls into question why the heck we > >> bothered supporting JSON or XML in the first place if we are > >> essentially just using them as Forms? It seems almost cruel to dangle > >> the richer data models of JSON and XML in front of people and then > >> pull them back with a restriction that we only do name/value pairs. > >> > >> Will we support JSON's data model? In which case do we intend to add > >> typing, arrays, etc. to forms and ban attributes and namespaces from > XML? > >> > >> Will we support XML's data model? In which case do we intend to add > >> name spacing and attributes to forms and JSON while banning all types > >> but string along with arrays in JSON? > >> > >> Or maybe we'll simply assert the existence of three different worlds > >> where every extension is defined in a completely different context > >> independently of each other? So every extension to OAuth has to, in > >> essence, be defined three separate times? > >> > >> Second, as a burden on server implementers we are requiring that they > >> possess and test three different parsers. I think this is > >> unnecessarily onerous and all but guaranteed to lead to > >> interoperability issues as server implementers will focus primarily > >> on the particular syntaxes they think will see the most use and give > >> less attention to other others. This is an inevitable trade off given = the > difficulties of fully testing even basic formats. > >> > >> =A0 =A0 =A0 Thanks, > >> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yaron > >> > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> > Behalf Of Kris Selden > >> > Sent: Friday, May 14, 2010 1:29 PM > >> > To: Eran Hammer-Lahav > >> > Cc: OAuth WG (oauth@ietf.org) > >> > Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) > >> > > >> > The only reason I've heard was interoperability but it is always > >> > stated as patently obvious without a given reasoning. My assumption > >> > is this is concern of OAuth 2 client library authors who don't want > >> > to depend on 3 parsing libraries but want to state they can > >> > inter-operate with > >> any OAuth 2 provider. > >> > > >> > I have a suggestion to mitigate the client library dependency > >> > issue, an argument for why C is more "interoperable" (even why the > >> > server should be not be required to support all 3 formats), > >> > comments on encoding, and percent encoding issues with OAuth 1. > >> > > >> > Basically, what OAuth providers return are key/value pairs and this > >> > discussion is really an issue of serialization. > >> > > >> > Instead of depending on libraries, client providers could have a > >> > interface for serialization that takes a mime type and string and > >> > returns a structure of key value pairs. That way if I've already > >> > chosen libyajl (which it is, even though it is UTF8 only) as my > >> > favorite JSON > >> library, I can plug it in. > >> > > >> > Chances are your client library is going to still be more bloated > >> > than me just writing to a testable spec for the flows I need. Maybe > >> > even unusable simply because I'm using an API from an application > >> > on an evented server and your library uses blocking I/O for making t= he > requests. > >> > > >> > On to why C is more interoperable and why as a consumer having it > >> > just be one format, doesn't help me unless I'm only using JSON > >> > APIs, it only helps the OAuth 2 client library developer. > >> > > >> > Let's say API A supports JSON, API B supports XML and API C > >> > supports both (as many APIs do, oh no the horror of the QA matrix). > >> > > >> > If I'm consuming API A, be nice if the OAuth 2 endpoint used JSON. > >> > If I'm consuming API B would be nice if the endpoint supported XML. > >> > If I needed both A and B, I need 2 parsers anyways, so what the > >> > endpoint did doesn't matter but I would pick JSON. If A and C I > >> > would want JSON. If B and C I would want XML. > >> > > >> > On the server side, would be nice if a service could match the > >> > OAuth endpoint format. I don't really see a need to support all 3 > >> > since in order to use my JSON only API you need a JSON parser anyway= . > >> > > >> > There is little point to an API support multiple formats as many do > >> > if the OAuth endpoints require JSON only. > >> > > >> > If my service is just a REST storage API, accepting binary files > >> > like images, I just want whatever the simplest to parse in which > >> > case I would like form- encoded. I really don't see why people > >> > think that format is complicated, been in use a long time, there is > >> > lots of library support, and is more trivial to write your own > >> > parser than both JSON > >> and XML. > >> > > >> > The problem with application/x-www-form-urlencoded that was > >> > complicated in OAuth 1, had to do with signature base strings > >> > because some characters could be optionally encoded and various > >> > libraries did this. Here we are talking about key/value pair > >> > serialization that HTML forms have been using for a long time. The > >> > percent encoding is of bytes and the bytes character set is defined > >> > by the charset in the response header. Would not matter if some > >> > characters were optionally > >> percent encoded, they would still be decoded. > >> > > >> > While a lot of clients may not have an > >> > application/x-www-form-urlencoded parser, this problem is way > >> > overblown. Most have a percent-encoding decoder, needed just to > >> > parse URLs. Splitting on & and =3D then replacing + with space is tr= ivial. > >> > This can easily be done in JavaScript, which is where I suspect > >> > some of the > >> JSON only momentum is coming from. > >> > > >> > Not all JSON libraries handle the NULL position UTF detection in > >> > the RFC 4627, some just assume UTF8 only. I'm guessing supporting > >> > the other Unicode transfer encodings isn't all that popular since > >> > UTF8 is a > >> superset of ASCII. > >> > > >> > Even though JSON maybe the way of the future, more SDKs like the > >> > iPhone come with a XML parser and you'd need to find a third party > >> > JSON parser or roll your own. > >> > > >> > As for the QA matrix, APIs that have handled multiple formats, have > >> > one output structure that is serialized to different formats which > >> > helps mitigate testing complexity. Test the one output, then test > >> > that that structure can be serialized to the supported formats. You > >> > may make that one structure JSON, then have a filter that can > >> > translate it to > >> XML. > >> > > >> > For OAuth, I think it would increase interoperability if the output > >> > was considered key/value string pairs and multiple serialization > >> > formats were available, requested through the Accept header. > >> > > >> > Or I guess you can make it so OAuth is only for JSON APIs because > >> > JSON is the future. Though I seem to remember that being said about > >> > XML not > >> long ago. > >> > Maybe I'm getting old. I guess I shouldn't use RSS and Atom feeds > >> > because they are so last year. > >> > > >> > I'm for option C plus relaxing the all 3 formats support to > >> > recommended but not required. > >> > > >> > On May 13, 2010, at 4:43 PM, Eran Hammer-Lahav wrote: > >> > > >> > > Can you give a reason why you are objecting to C. > >> > > > >> > > EHL > >> > > > >> > >> -----Original Message----- > >> > >> From: Robert Sayre [mailto:sayrer@gmail.com] > >> > >> Sent: Thursday, May 13, 2010 4:27 PM > >> > >> To: Eran Hammer-Lahav > >> > >> Cc: Yaron Goland; OAuth WG (oauth@ietf.org) > >> > >> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by > >> > >> 5/13) > >> > >> > >> > >> On Thu, May 13, 2010 at 5:14 PM, Eran Hammer-Lahav > >> > >> <eran@hueniverse.com> wrote: > >> > >>> There is clearly no consensus for either A or B. There was > >> > >>> mostly no objection to C, and the reason given by most of those > >> > >>> who objected was > >> > >> client complexity with the current proposal solves. > >> > >> > >> > >> My objection to C was that your examples were buggy. So, to be > >> > >> tediously > >> > >> explicit: > >> > >> > >> > >> B, then A. Not C. > >> > >> > >> > >> - Rob > >> > > _______________________________________________ > >> > > 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 uidude@google.com Thu May 20 06:54:09 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7BD3A6BF3 for <oauth@core3.amsl.com>; Thu, 20 May 2010 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.282 X-Spam-Level: X-Spam-Status: No, score=-100.282 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 G2u+fmfxBIL5 for <oauth@core3.amsl.com>; Thu, 20 May 2010 06:54:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5F0463A6BBC for <oauth@ietf.org>; Thu, 20 May 2010 06:54:04 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o4KDrrJY017539 for <oauth@ietf.org>; Thu, 20 May 2010 06:53:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274363634; bh=BEHl+17V+9a1K58yD7Qo3KCRjg4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=UX7C+0Xef5qBfWfHe60scjoq8qnmCCYj+tiO86+7jj0/MBmdhsmHNG+u3qnkxX+1F N7kYp0rdjanaqXkFMH5/A== 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=EZjgKGhNFQxKTgefPPXkQ3sGYn65NDfRT0YFwfaDvfh2C1RltbXsx0ol0F3dt27S4 bp2uieubF6Mp2YMEwuueg== Received: from qyk15 (qyk15.prod.google.com [10.241.83.143]) by wpaz5.hot.corp.google.com with ESMTP id o4KDrpKZ016350 for <oauth@ietf.org>; Thu, 20 May 2010 06:53:52 -0700 Received: by qyk15 with SMTP id 15so11611410qyk.6 for <oauth@ietf.org>; Thu, 20 May 2010 06:53:51 -0700 (PDT) Received: by 10.224.140.131 with SMTP id i3mr61004qau.39.1274363631392; Thu, 20 May 2010 06:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.215 with HTTP; Thu, 20 May 2010 06:53:31 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112637B8285@WSMSG3153V.srv.dir.telstra.com> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B698808@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B699132@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinlwZpM4PBHSR1t1whWR2p38PHq9VpcJw4p77vs@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112637B8285@WSMSG3153V.srv.dir.telstra.com> From: Evan Gilbert <uidude@google.com> Date: Thu, 20 May 2010 06:53:31 -0700 Message-ID: <AANLkTikSRG5UWCRvFjtVyqJ-GoHigwW0CVFC1NMJGj3i@mail.gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=000e0cd56450905999048706e766 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 13:54:10 -0000 --000e0cd56450905999048706e766 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 19, 2010 at 6:33 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Marius, > > > Only direct responses are JSON, form/url encoded > > still has to be used: > > - direct requests > > - through browser requests > > - through browser responses > > - through browser fragment responses > > A better solution would be to change the last two (token info delivered in > a callback URIs) so a single parameter (in the query or fragment) holds all > the token info -- as a base64url-encoded JSON value. > This is really problematic - All implementers will have to properly parse form fields *and* parse JSON (and Base64 decode to boot). - JavaScript clients are likely to have XSS holes. If clients don't execute something like this code (from gadgets.json<http://www.google.com/codesearch/p?hl=en#MSH8LMSqi38/trunk/features/core/json.js&q=io.js%20package:%22http://svn.apache.org/repos/asf/incubator/shindig/%22&d=2>), then they will be exposing themself to XSS. if (/^[\],:{}\s]*$/.test(text.replace(/\\["\\\/b-u]/g, '@'). replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g, ']'). replace(/(?:^|:|,)(?:\s*\[)+/g, ''))) { return eval('(' + text + ')'); } - Developers will not be able to read source directly I'm a fan of Base64 encoding JSON for the purposes of creating a canonicalized string for signing. But this is not a good default transport. > > That is more complicated if you are only delivering a single quantity (eg > just an access_token). However, the difference diminishes as more and more > features are added: expires_in, scope, sites, refresh_token, > access_token_secret, realm, auth_scheme, > whatever-comes-out-of-OpenID-Connect etc. > > A single parameter for token info in callback URIs also reduces the risk of > clashing with client-specific parameters in callback URIs as things are > added in the future (eg the earlier debate about no oauth_ prefix). > > It eliminates the need to force all semantics to fit in a flat key/value > model. This can only get harder as features are added, or extensions are > supported. The OpenID 2.0 approach of namespaces and parameter name prefixes > is not pretty. JSON does not solve this, but its structure helps. > > I wouldn't be surprised if, in some scenarios, the token info gets too big > to fit in a URI. In that case even the user-agent flow will need to make a > direct request to get the token info, which is more likely to be delivered > as JSON. OpenID and SAML have found they need this (eg artefact flows). > > > Please consider this as an open issue for today's meeting: a single > parameter holding a base64url-encode JSON value for packaging token info in > a callback URI. > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd56450905999048706e766 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Wed, May 19, 2010 at 6:33 PM, Manger,= James H <span dir=3D"ltr"><<a href=3D"mailto:James.H.Manger@team.telstr= a.com">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex;"> Marius,<br> <div class=3D"im"><br> > Only direct responses are JSON, form/url encoded<br> > still has to be used:<br> > - direct requests<br> > - through browser requests<br> > - through browser responses<br> > - through browser fragment responses<br> <br> </div>A better solution would be to change the last two (token info deliver= ed in a callback URIs) so a single parameter (in the query or fragment) hol= ds all the token info -- as a base64url-encoded JSON value.<br></blockquote= > <div><br></div><div>This is really problematic</div><div>- All implementers= will have to properly parse form fields *and* parse JSON (and Base64 decod= e to boot).</div><div>- JavaScript clients are likely to have XSS holes. If= clients don't execute something like this code (from <a href=3D"http:/= /www.google.com/codesearch/p?hl=3Den#MSH8LMSqi38/trunk/features/core/json.j= s&q=3Dio.js%20package:%22http://svn.apache.org/repos/asf/incubator/shin= dig/%22&d=3D2">gadgets.json</a>), then they will be exposing themself t= o XSS.</div> <div><span class=3D"Apple-style-span" style=3D"font-family: monospace; font= -size: medium; "><pre style=3D"margin-top: 0px; margin-right: 0px; margin-b= ottom: 0px; margin-left: 0px; line-height: 1.25; "><span id=3D"l156"> <spa= n class=3D"stx-keyword" style=3D"color: rgb(0, 0, 136); ">if</span> (/^[\],= :{}\s]*$/.test(text.replace(/\\["\\\/b-u]/g, <span class=3D"stx-string= " style=3D"color: rgb(0, 136, 0); ">'@'</span>). </span><span id=3D"l157"> replace(/"[^"\\\n\r]*"|tr= ue|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g, <span class=3D"stx-strin= g" style=3D"color: rgb(0, 136, 0); ">']'</span>). </span><span id=3D"l158"> replace(/(?:^|:|,)(?:\s*\[)+/g, <span cl= ass=3D"stx-string" style=3D"color: rgb(0, 136, 0); ">''</span>))) { </span><span id=3D"l159"> <span class=3D"stx-keyword" style=3D"color= : rgb(0, 0, 136); ">return</span> eval(<span class=3D"stx-string" style=3D"= color: rgb(0, 136, 0); ">'('</span> + text + <span class=3D"stx-str= ing" style=3D"color: rgb(0, 136, 0); ">')'</span>); </span><span id=3D"l160"> }</span></pre></span>- Developers will not b= e able to read source directly</div><div><br></div><div>I'm a fan of Ba= se64 encoding JSON for the purposes of creating a canonicalized string for = signing. But this is not a good default transport.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex;"> <br> That is more complicated if you are only delivering a single quantity (eg j= ust an access_token). However, the difference diminishes as more and more f= eatures are added: expires_in, scope, sites, refresh_token, access_token_se= cret, realm, auth_scheme, whatever-comes-out-of-OpenID-Connect etc.<br> <br> A single parameter for token info in callback URIs also reduces the risk of= clashing with client-specific parameters in callback URIs as things are ad= ded in the future (eg the earlier debate about no oauth_ prefix).<br> <br> It eliminates the need to force all semantics to fit in a flat key/value mo= del. This can only get harder as features are added, or extensions are supp= orted. The OpenID 2.0 approach of namespaces and parameter name prefixes is= not pretty. JSON does not solve this, but its structure helps.<br> <br> I wouldn't be surprised if, in some scenarios, the token info gets too = big to fit in a URI. In that case even the user-agent flow will need to mak= e a direct request to get the token info, which is more likely to be delive= red as JSON. OpenID and SAML have found they need this (eg artefact flows).= <br> <br> <br> Please consider this as an open issue for today's meeting: a single par= ameter holding a base64url-encode JSON value for packaging token info in a = callback URI.<br> <br> --<br> <font color=3D"#888888">James Manger<br> </font><div><div></div><div class=3D"h5">__________________________________= _____________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br> --000e0cd56450905999048706e766-- From Hannes.Tschofenig@gmx.net Thu May 20 08:53:18 2010 Return-Path: <Hannes.Tschofenig@gmx.net> 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 424833A6A34 for <oauth@core3.amsl.com>; Thu, 20 May 2010 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 EmsLPm8Al5nm for <oauth@core3.amsl.com>; Thu, 20 May 2010 08:53:16 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D55373A6943 for <oauth@ietf.org>; Thu, 20 May 2010 08:53:15 -0700 (PDT) Received: (qmail invoked by alias); 20 May 2010 15:53:07 -0000 Received: from lo5.cfw-b-gci.corp.yahoo.com (EHLO [10.101.30.80]) [209.131.62.144] by mail.gmx.net (mp055) with SMTP; 20 May 2010 17:53:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18TQ7d7Xh4Ta+LHPgLLZSjwLaKmcRxsAqIKdeK28Q Y3p37H7Rl9WG0b Message-ID: <4BF55AE6.6030707@gmx.net> Date: Thu, 20 May 2010 18:53:10 +0300 From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Remote participation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 15:53:18 -0000 Note: it takes us a bit to get setup here in the meeting venue but in any case here is the info for the remote participants Jabber: oauth@jabber.ietf.org Webex: > From: messenger@webex.com > Date: May 19, 2010 10:05:03 AM PDT > To: amorris@amsl.com > Subject: Meeting scheduled: OAuth Interim Meeting > Reply-To: messenger@webex.com > > > You are the host for this online meeting. > > Topic: OAuth Interim Meeting > Date: Thursday, May 20, 2010 > Time: 8:15 am, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 966 781 251 > Meeting Password: (This meeting does not require a password.) > > ------------------------------------------------------- > To start the online meeting > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=133969152&UID=483233937&RT=MiM0 > 2. If you are not logged in, log in to your account. > > ------------------------------------------------------- > Audio conference information > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. > Call-in toll-free number (US/Canada): 1-866-699-3239 > Call-in toll number (US/Canada): 1-408-792-6300 > Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=133969152&tollFree=1 > Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf > > Access code:966 781 251 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > To add this meeting to your calendar program (for example Microsoft Outlook), click this link: > https://workgreen.webex.com/workgreen/j.php?ED=133969152&UID=483233937&ICS=MS&LD=1&RD=2&ST=1&SHA2=aQOhia26yMlDsn9NLip6Mfw4EWycRWxt3ILLrY0aadc= > > To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://workgreen.webex.com/workgreen/systemdiagnosis.php > > http://www.webex.com > > > > From dick.hardt@gmail.com Thu May 20 09:06:07 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCAB3A6A28 for <oauth@core3.amsl.com>; Thu, 20 May 2010 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] 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 C0CsFEkauF74 for <oauth@core3.amsl.com>; Thu, 20 May 2010 09:06:06 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 777EA3A6AD6 for <oauth@ietf.org>; Thu, 20 May 2010 09:06:04 -0700 (PDT) Received: by ewy8 with SMTP id 8so3089830ewy.28 for <oauth@ietf.org>; Thu, 20 May 2010 09:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=cVYXPqxUfdq1j6db7zgRZCmRVPZS3iwa1XPwiouP46E=; b=Qx1B7RdOewN2ZFjsaVh9K8uWQcTHB/q6vH0uJ9Ns+Fjw8jtX7RrwiPmiiu+AYVzxUR +0M2NcwQZtZAB0n59wQrTkMP0yc8NlVA8qdvAwbO2R+WZOJM/HIQEyUfaCAEyEQhpP2w oO++E17FKKMBcO/+CoMaGJ/UUhYeGreSWPEFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=VtMfyhIQOVwQYw7vgZoPA7pmgpgcRDpz9K2iyFY/yBj85xJw0SuvzwpZn1FaYS6Lbp P3TA9dTmTUJ6b5DneZDGzAeTAXu+D/wVJUsMj3YZoNJG+6IGhwxsD+Aupf+kT7y2ZDBL 6Au3G5XlBZPNuw1N6LRfkhhwdjrnN2Y0zMajc= Received: by 10.213.54.4 with SMTP id o4mr4544425ebg.34.1274371554463; Thu, 20 May 2010 09:05:54 -0700 (PDT) Received: from wlan-guest-45.corp.yahoo.com (lo5.cfw-b-gci.corp.yahoo.com [209.131.62.144]) by mx.google.com with ESMTPS id 15sm22930ewy.0.2010.05.20.09.05.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 May 2010 09:05:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-4--288396635 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B699130@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 20 May 2010 09:05:46 -0700 Message-Id: <4353B564-4718-4323-A223-8F9D93A27F4B@gmail.com> References: <255B9BB34FB7D647A506DC292726F6E11263073D6D@WSMSG3153V.srv.dir.telstra.com> <AANLkTilkUA9i-WZPv8PqPsxiJf5_1SuiCb_GOTdcwtPX@mail.gmail.com> <AANLkTilNNyKvpbzCYfc__AvY1rJKqXE7KN8VL-m_CF-L@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112633D9594@WSMSG3153V.srv.dir.telstra.com> <AANLkTim0PNhUJAi1ZuDjB8feKh2Sb_OMoNz7AlDTYO6P@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112634655A4@WSMSG3153V.srv.dir.telstra.com> <AANLkTil7gTRNmqTAwsvFEdMLmlgeakpy8o1wyPTcTbLF@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3AB478D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTik0dKSLLVQDhodhFsO--bR43PvZKborWG1uK15t@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6987D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilsw-oR2gMi-FFZwXotl1xQaDKvszpvQLWcQO-V@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B699130@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1078) Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 16:06:08 -0000 --Apple-Mail-4--288396635 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The image can be protected by both. Do you expect OAuth to be used with = user present in the browser? On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote: > Why can=92t an image be protected with both Basic and OAuth? In this = case the browser is the OAuth client. > =20 > EHL > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Sunday, May 16, 2010 11:38 AM > To: Eran Hammer-Lahav > Cc: Evan Gilbert; OAuth WG > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > =20 > Not sure if you intended this, but you are mixing user present and = user not present access control. >=20 > I do NOT think we want OAuth protected images to be the same as Basic = auth protected images. I do think OpenID protected images and Basic auth = are similar. With OAuth today, the user has granted explicit permission = at a particular resource, not any resource the user may have access to. > =20 > -- Dick > =20 > On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav = <eran@hueniverse.com> wrote: > Today when I cut/paste a URI of an image using Basic auth, the browser = knows exactly what to do. I want to do the same with an OAuth-protected = image. Saying that there aren=92t standards API out there to benefit = from this is incorrect. There are plenty. > =20 > This is complete discovery for the authentication layer. The rest = doesn=92t belong here, the same way this doesn=92t belong as part of the = API specification. > =20 > EHL > =20 > From: Evan Gilbert [mailto:uidude@google.com]=20 > Sent: Thursday, May 13, 2010 9:16 AM > To: Eran Hammer-Lahav > Cc: Manger, James H; OAuth WG >=20 > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > =20 > =20 >=20 > On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav = <eran@hueniverse.com> wrote: > You are trying to match a mechanism designed for automatic discovery = with a system designed to require paperwork. It sounds like for your use = cases, you will not be using this optional parameter and just document = how to use your API (i.e. hardcode your security setup and API format). > =20 > I'm saying it should be a fully automatic discovery or use paperwork. = Having an API return valid URL prefixes to send the token to without = having an API to determine the actual URLs you send tokens to seems odd. > =20 > The whole point of this is that the developer isn=92t involved. The = library takes care of everything. All the developer does is ask to get a = protected resource. The library will check if it already has a valid = token for that resource (based on the security restrictions provided by = the sites parameter, and the scope requirements =96 two very separate = things). > =20 > This is an incomplete mechanism for automatic discovery. How does the = developer find out where to ask for the protected resource in the first = place? > =20 > So yes =96 if your developers have plenty of stuff to hardcode = already, this adds little value. > =20 > EHL > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Evan Gilbert > Sent: Thursday, May 13, 2010 9:00 AM >=20 > To: Manger, James H > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Indicating sites where a token is valid > =20 > =20 >=20 > On Wed, May 12, 2010 at 11:52 PM, Manger, James H = <James.H.Manger@team.telstra.com> wrote: > Evan, >=20 > > The key point is that this discovery covers a lot of the same = grounds as the sites parameter, and it's hard to define semantics = around a sites parameter without understanding the semantics of scopes = and API endpoints. >=20 > I strongly disagree. The semantics are crystal clear: > "Here is a token. It is INSECURE to send it anywhere not in this = list." > These semantics are useful regardless of what the API does, how the = client is using it, or how much (or how little) the client knows about = the API. > =20 > To expand - it's hard to define *useful* semantics around a sites = parameter without understanding the semantics of scopes and API = endpoints. Yes, you can define crystal clear semantics, but these are = not useful unless they work well with the way developers figure out the = endpoints to call APIs. > =20 >=20 >=20 > > Clients need to [know] more about these links (at least the response = format). >=20 > That knowledge comes from other standards (HTML, Atom, wiki of rel = values...) and is totally independent of whether a token should or = should not be sent. > =20 > In our use cases, clients almost always need to know more about the = API: > - How to call directly - we have no API endpoints that are only = arrived at by links > - Response format of the data > =20 >=20 >=20 > > The mechanism they use to find out about these links - = documentation, discovery, data returned with token request - could also = provide the information about whether a token should be sent to a = particular API. >=20 > Could, but shouldn't and doesn't in practise. > It is much much better to have the information about how to use a = token securely delivered at the same time & place as receiving that = token, and with minimal assumptions about how much the client apps knows = about the service. > =20 > So why wouldn't we return a list of specific API endpoints instead of = a "sites" parameter? > =20 > Developers are going to call the APIs endpoints that they know about. = If there is a conflict between this and the sites parameter, what should = they do? For example, if facebook returns a sites parameter = "https://unknown.facebook.com/", do we think the developer is going to = not try to use the access token on https://graph.facebook.com/ ?=20 > =20 > Separating the concept of sites from API endpoints feels like a bad = idea. Discovery / docs will give you a list of URLs where you should = send tokens. The "sites" parameter will give you a list of URLs where = you can send tokens. This is redundant, and will lead to developers / = libraries not respecting the sites parameter. If developers / libraries = don't respect it, then the service can't rely on it for enforcing = security. > =20 > Another note: Where do we anticipate clients storing the sites = parameter in the User-Agent flow? Right now the access token can be set = as an HTTP cookie by the client. Do we expect them to set a separate = "sites" cookie and respect this on their server when making requests? = This seems complicated. > =20 >=20 >=20 > > I should be more concrete about the use cases I see. Let's assume = there's an API where there are two endpoints, each with an associated = permission > > - contacts.list permission -> = http://contacts.serviceprovider.com/contacts/list > > - calendar.get permission -> = http://calendar.serviceprovider.com/calendar/get > > > > If the response to an authorization request includes the authorized = scopes (contacts.list, calendar.get), then the "sites" parameter is = redundant. >=20 > I'll admit that "sites" is redundant if a client has *perfect* = knowledge about a service, but so is pretty much any standard at that = point. >=20 > Consider a generic search spider tool that you point at = http://calendar.serviceprovider.com/calendar/get. It can do its job with = no knowledge about what "calendar.get" means -- but it still needs to = know (as it spiders along) when it is safe to expose the token. > =20 > How does the generic search spider know to call to = http://calendar.serviceprovider.com/calendar/get in the first place? > =20 >=20 >=20 > -- > James Manger >=20 > =20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 --Apple-Mail-4--288396635 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><base href=3D"x-msg://44/"></head><body style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; ">The image can be protected by both. Do you expect = OAuth to be used with user present in the browser?<div><br><div><div>On = 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-size: medium; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" = vlink=3D"purple"><div class=3D"WordSection1"><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(31, 73, 125); ">Why can=92t an image be protected with both Basic = and OAuth? In this case the browser is the OAuth = client.<o:p></o:p></span></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: = rgb(31, 73, 125); "><o:p> </o:p></span></div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; color: rgb(31, 73, 125); ">EHL<o:p></o:p></span></div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; color: rgb(31, 73, 125); = "><o:p> </o:p></span></div><div style=3D"border-top-style: none; = border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: blue; border-left-width: 1.5pt; padding-top: 0in; = padding-right: 0in; padding-bottom: 0in; padding-left: 4pt; "><div><div = style=3D"border-right-style: none; border-bottom-style: none; = border-left-style: none; border-width: initial; border-color: initial; = border-top-style: solid; border-top-color: rgb(181, 196, 223); = border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; = padding-bottom: 0in; padding-left: 0in; "><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span = style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; = ">From:</span></b><span style=3D"font-size: 10pt; font-family: Tahoma, = sans-serif; "><span class=3D"Apple-converted-space"> </span>Dick = Hardt [mailto:dick.hardt@gmail.com]<span = class=3D"Apple-converted-space"> </span><br><b>Sent:</b><span = class=3D"Apple-converted-space"> </span>Sunday, May 16, 2010 11:38 = AM<br><b>To:</b><span class=3D"Apple-converted-space"> </span>Eran = Hammer-Lahav<br><b>Cc:</b><span = class=3D"Apple-converted-space"> </span>Evan Gilbert; OAuth = WG<br><b>Subject:</b><span = class=3D"Apple-converted-space"> </span>Re: [OAUTH-WG] Indicating = sites where a token is valid<o:p></o:p></span></div></div></div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "><o:p> </o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">Not sure if you = intended this, but you are mixing user present and user not present = access control.<o:p></o:p></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><br>I do NOT think we = want OAuth protected images to be the same as Basic auth protected = images. I do think OpenID protected images and Basic auth are similar. = With OAuth today, the user has granted explicit permission at a = particular resource, not any resource the user may have access = to.<o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "><o:p> </o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">-- = Dick<o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "><o:p> </o:p></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">On Thu, May 13, 2010 = at 9:30 AM, Eran Hammer-Lahav <<a href=3D"mailto:eran@hueniverse.com" = style=3D"color: blue; text-decoration: underline; = ">eran@hueniverse.com</a>> wrote:<o:p></o:p></div><div><div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "><span style=3D"font-size: 11pt; color: rgb(31, 73, 125); = ">Today when I cut/paste a URI of an image using Basic auth, the browser = knows exactly what to do. I want to do the same with an OAuth-protected = image. Saying that there aren=92t standards API out there to benefit = from this is incorrect. There are plenty.</span><o:p></o:p></div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "><span style=3D"font-size: 11pt; color: rgb(31, 73, 125); = "> </span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); ">This is complete = discovery for the authentication layer. The rest doesn=92t belong here, = the same way this doesn=92t belong as part of the API = specification.</span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); = "> </span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); = ">EHL</span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); = "> </span><o:p></o:p></div><div style=3D"border-top-style: none; = border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: blue; border-left-width: 1.5pt; padding-top: 0in; = padding-right: 0in; padding-bottom: 0in; padding-left: 4pt; "><div><div = style=3D"border-right-style: none; border-bottom-style: none; = border-left-style: none; border-width: initial; border-color: initial; = border-top-style: solid; border-top-color: rgb(181, 196, 223); = border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; = padding-bottom: 0in; padding-left: 0in; "><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span = style=3D"font-size: 10pt; ">From:</span></b><span style=3D"font-size: = 10pt; "><span class=3D"Apple-converted-space"> </span>Evan Gilbert = [mailto:<a href=3D"mailto:uidude@google.com" target=3D"_blank" = style=3D"color: blue; text-decoration: underline; = ">uidude@google.com</a>]<span = class=3D"Apple-converted-space"> </span><br><b>Sent:</b><span = class=3D"Apple-converted-space"> </span>Thursday, May 13, 2010 9:16 = AM<br><b>To:</b><span class=3D"Apple-converted-space"> </span>Eran = Hammer-Lahav<br><b>Cc:</b><span = class=3D"Apple-converted-space"> </span>Manger, James H; OAuth = WG</span><o:p></o:p></div><div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "><br><b>Subject:</b><span = class=3D"Apple-converted-space"> </span>Re: [OAUTH-WG] Indicating = sites where a token is = valid<o:p></o:p></div></div></div></div></div><div><div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "> <o:p></o:p></div><p class=3D"MsoNormal" = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 12pt; "> <o:p></o:p></p><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">On Thu, May 13, 2010 = at 9:08 AM, Eran Hammer-Lahav <<a href=3D"mailto:eran@hueniverse.com" = target=3D"_blank" style=3D"color: blue; text-decoration: underline; = ">eran@hueniverse.com</a>> wrote:<o:p></o:p></div><div><div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "><span style=3D"font-size: 11pt; color: rgb(31, 73, 125); = ">You are trying to match a mechanism designed for automatic discovery = with a system designed to require paperwork. It sounds like for your use = cases, you will not be using this optional parameter and just document = how to use your API (i.e. hardcode your security setup and API = format).</span><o:p></o:p></div></div></div><div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "> <o:p></o:p></div></div><div><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">I'm saying it should = be a fully automatic discovery or use paperwork. Having an API return = valid URL prefixes to send the token to without having an API to = determine the actual URLs you send tokens to seems = odd.<o:p></o:p></div></div><blockquote style=3D"border-top-style: none; = border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: rgb(204, 204, 204); border-left-width: 1pt; = padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: = 6pt; margin-left: 4.8pt; margin-top: 5pt; margin-right: 0in; = margin-bottom: 5pt; "><div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); = "> </span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); ">The whole point of = this is that the developer isn=92t involved. The library takes care of = everything. All the developer does is ask to get a protected resource. = The library will check if it already has a valid token for that resource = (based on the security restrictions provided by the sites parameter, and = the scope requirements =96 two very separate = things).</span><o:p></o:p></div></div></div></blockquote><div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "> <o:p></o:p></div></div><div><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">This is an incomplete = mechanism for automatic discovery. How does the developer find out where = to ask for the protected resource in the first = place?<o:p></o:p></div></div><blockquote style=3D"border-top-style: = none; border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: rgb(204, 204, 204); border-left-width: 1pt; = padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: = 6pt; margin-left: 4.8pt; margin-top: 5pt; margin-right: 0in; = margin-bottom: 5pt; "><div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); = "> </span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); ">So yes =96 if your = developers have plenty of stuff to hardcode already, this adds little = value.</span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); = "> </span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); = ">EHL</span><o:p></o:p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 11pt; color: rgb(31, 73, 125); = "> </span><o:p></o:p></div><div style=3D"border-top-style: none; = border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: blue; border-left-width: 1.5pt; padding-top: 0in; = padding-right: 0in; padding-bottom: 0in; padding-left: 4pt; "><div><div = style=3D"border-right-style: none; border-bottom-style: none; = border-left-style: none; border-width: initial; border-color: initial; = border-top-style: solid; border-top-color: rgb(181, 196, 223); = border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; = padding-bottom: 0in; padding-left: 0in; "><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span = style=3D"font-size: 10pt; ">From:</span></b><span style=3D"font-size: = 10pt; "><span class=3D"Apple-converted-space"> </span><a = href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank" style=3D"color: = blue; text-decoration: underline; ">oauth-bounces@ietf.org</a><span = class=3D"Apple-converted-space"> </span>[mailto:<a = href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank" style=3D"color: = blue; text-decoration: underline; ">oauth-bounces@ietf.org</a>]<span = class=3D"Apple-converted-space"> </span><b>On Behalf Of<span = class=3D"Apple-converted-space"> </span></b>Evan = Gilbert<br><b>Sent:</b><span = class=3D"Apple-converted-space"> </span>Thursday, May 13, 2010 9:00 = AM</span><o:p></o:p></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><br><b>To:</b><span = class=3D"Apple-converted-space"> </span>Manger, James = H<br><b>Cc:</b><span class=3D"Apple-converted-space"> </span>OAuth = WG<br><b>Subject:</b><span = class=3D"Apple-converted-space"> </span>Re: [OAUTH-WG] Indicating = sites where a token is valid<o:p></o:p></div></div></div></div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "> <o:p></o:p></div><p class=3D"MsoNormal" = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 12pt; "> <o:p></o:p></p><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">On Wed, May 12, 2010 = at 11:52 PM, Manger, James H <<a = href=3D"mailto:James.H.Manger@team.telstra.com" target=3D"_blank" = style=3D"color: blue; text-decoration: underline; = ">James.H.Manger@team.telstra.com</a>> = wrote:<o:p></o:p></div><div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = ">Evan,<o:p></o:p></div><div><p class=3D"MsoNormal" style=3D"margin-right:= 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 12pt; "><br>> The key point is = that this discovery covers a lot of the same grounds as the sites = parameter, and it's hard  to define semantics around a sites = parameter without understanding the semantics of scopes and API = endpoints.<o:p></o:p></p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">I strongly disagree. = The semantics are crystal clear:<br> "Here is a token. It is = INSECURE to send it anywhere not in this list."<br>These semantics are = useful regardless of what the API does, how the client is using it, or = how much (or how little) the client knows about the = API.<o:p></o:p></div><div><div style=3D"margin-right: 0in; margin-left: = 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: = 0in; margin-bottom: 0.0001pt; "> <o:p></o:p></div></div><div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; ">To expand - it's hard to define *useful* = semantics around a sites parameter without understanding the = semantics of scopes and API endpoints. Yes, you can define crystal clear = semantics, but these are not useful unless they work well with the way = developers figure out the endpoints to call = APIs.<o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "> <o:p></o:p></div></div><blockquote style=3D"border-top-style: = none; border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: rgb(204, 204, 204); border-left-width: 1pt; = padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: = 6pt; margin-left: 4.8pt; margin-top: 5pt; margin-right: 0in; = margin-bottom: 5pt; "><div style=3D"margin-right: 0in; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; = margin-bottom: 0.0001pt; "><br><br>> Clients need to [know] more = about these links (at least the response format).<br><br>That knowledge = comes from other standards (HTML, Atom, wiki of rel values...) and is = totally independent of whether a token should or should not be = sent.<o:p></o:p></div></blockquote><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "> <o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">In our use cases, = clients almost always need to know more about the = API:<o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">- How to call = directly - we have no API endpoints that are only arrived at by = links<o:p></o:p></div></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">- Response format of = the data<o:p></o:p></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "> <o:p></o:p></div></div><blockquote style=3D"border-top-style: = none; border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: rgb(204, 204, 204); border-left-width: 1pt; = padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: = 6pt; margin-left: 4.8pt; margin-top: 5pt; margin-right: 0in; = margin-bottom: 5pt; "><div><p class=3D"MsoNormal" style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 12pt; "><br><br>> The = mechanism they use to find out about these links - documentation, = discovery, data returned with token request - could also provide the = information about whether a token should be sent to a particular = API.<o:p></o:p></p></div><div style=3D"margin-right: 0in; margin-left: = 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: = 0in; margin-bottom: 0.0001pt; ">Could, but shouldn't and doesn't in = practise.<br>It is much much better to have the information about how to = use a token securely delivered at the same time & place as receiving = that token, and with minimal assumptions about how much the client apps = knows about the service.<o:p></o:p></div></blockquote><div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "> <o:p></o:p></div></div><div><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">So why wouldn't we = return a list of specific API endpoints instead of a "sites" = parameter?<o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "> <o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">Developers are going = to call the APIs endpoints that they know about. If there is a conflict = between this and the sites parameter, what should they do? For example, = if facebook returns a sites parameter "<a = href=3D"https://unknown.facebook.com/" target=3D"_blank" style=3D"color: = blue; text-decoration: underline; ">https://unknown.facebook.com/</a>", = do we think the developer is going to not try to use the access token = on <span style=3D"font-size: 10pt; "><a = href=3D"https://graph.facebook.com/*" target=3D"_blank" style=3D"color: = blue; text-decoration: underline; "><span style=3D"color: rgb(0, 0, = 204); = ">https://graph.facebook.com/</span></a> ? </span><o:p></o:p></d= iv></div><div><div style=3D"margin-right: 0in; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; = margin-bottom: 0.0001pt; "> <o:p></o:p></div></div><div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "><span style=3D"font-size: 10pt; ">Separating the concept of = sites from API endpoints feels like a bad idea. Discovery / docs will = give you a list of URLs where you should send tokens. The "sites" = parameter will give you a list of URLs where you can send tokens. This = is redundant, and will lead to developers / libraries not respecting the = sites parameter. If developers / libraries don't respect it, then the = service can't rely on it for enforcing = security.</span><o:p></o:p></div></div><div><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "> <o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span = style=3D"font-size: 10pt; ">Another note: Where do we anticipate clients = storing the sites parameter in the User-Agent flow? Right now the access = token can be set as an HTTP cookie by the client. Do we expect them to = set a separate "sites" cookie and respect this on their server when = making requests? This seems = complicated.</span><o:p></o:p></div></div><div><div style=3D"margin-right:= 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "> <o:p></o:p></div></div><blockquote style=3D"border-top-style: = none; border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: rgb(204, 204, 204); border-left-width: 1pt; = padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: = 6pt; margin-left: 4.8pt; margin-top: 5pt; margin-right: 0in; = margin-bottom: 5pt; "><div><p class=3D"MsoNormal" style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 12pt; "><br><br>> I should be = more concrete about the use cases I see. Let's assume there's an API = where there are two endpoints, each with an associated = permission<br>> - contacts.list permission -><span = class=3D"Apple-converted-space"> </span><a = href=3D"http://contacts.serviceprovider.com/contacts/list" = target=3D"_blank" style=3D"color: blue; text-decoration: underline; = ">http://contacts.serviceprovider.com/contacts/list</a><br>> - = calendar.get permission -><span = class=3D"Apple-converted-space"> </span><a = href=3D"http://calendar.serviceprovider.com/calendar/get" = target=3D"_blank" style=3D"color: blue; text-decoration: underline; = ">http://calendar.serviceprovider.com/calendar/get</a><br>><br>> = If the response to an authorization request includes the authorized = scopes (contacts.list, calendar.get), then the "sites" parameter is = redundant.<o:p></o:p></p></div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">I'll admit that = "sites" is redundant if a client has *perfect* knowledge about a = service, but so is pretty much any standard at that = point.<br><br>Consider a generic search spider tool that you point = at<span class=3D"Apple-converted-space"> </span><a = href=3D"http://calendar.serviceprovider.com/calendar/get" = target=3D"_blank" style=3D"color: blue; text-decoration: underline; = ">http://calendar.serviceprovider.com/calendar/get</a>. It can do its = job with no knowledge about what "calendar.get" means -- but it still = needs to know (as it spiders along) when it is safe to expose the = token.<o:p></o:p></div></blockquote><div><div style=3D"margin-right: = 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "> <o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; ">How does the generic = search spider know to call to<span = class=3D"Apple-converted-space"> </span><a = href=3D"http://calendar.serviceprovider.com/calendar/get" = target=3D"_blank" style=3D"color: blue; text-decoration: underline; = ">http://calendar.serviceprovider.com/calendar/get</a><span = class=3D"Apple-converted-space"> </span>in the first = place?<o:p></o:p></div></div><div><div style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 0.0001pt; = "> <o:p></o:p></div></div><blockquote style=3D"border-top-style: = none; border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: rgb(204, 204, 204); border-left-width: 1pt; = padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: = 6pt; margin-left: 4.8pt; margin-top: 5pt; margin-right: 0in; = margin-bottom: 5pt; "><p class=3D"MsoNormal" style=3D"margin-right: 0in; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-top: 0in; margin-bottom: 12pt; "><br><br>--<br><span = style=3D"color: rgb(136, 136, 136); ">James = Manger</span><o:p></o:p></p></blockquote></div></div></div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; = "> <o:p></o:p></div></div></div></div></blockquote></div><div = style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; "> <o:p></o:p></div></div></div></div></div></div><p = class=3D"MsoNormal" style=3D"margin-right: 0in; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; = margin-bottom: 12pt; = "><br>_______________________________________________<br>OAuth mailing = list<br><a href=3D"mailto:OAuth@ietf.org" style=3D"color: blue; = text-decoration: underline; ">OAuth@ietf.org</a><br><a = href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank" = style=3D"color: blue; text-decoration: underline; = ">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></p></div><div= style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: = 0.0001pt; = "><o:p> </o:p></div></div></div></div></div></span></blockquote></div= ><br></div></body></html>= --Apple-Mail-4--288396635-- From mscurtescu@google.com Thu May 20 09:12:24 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B8D3A6935 for <oauth@core3.amsl.com>; Thu, 20 May 2010 09:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.426 X-Spam-Level: X-Spam-Status: No, score=-104.426 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_50=0.001, 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 SAKcXJ7IZfzn for <oauth@core3.amsl.com>; Thu, 20 May 2010 09:12:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BEAE43A69F6 for <oauth@ietf.org>; Thu, 20 May 2010 09:12:20 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o4KGC9vW002832 for <oauth@ietf.org>; Thu, 20 May 2010 09:12:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274371931; bh=ybUKQjY00S95o3PbyxCZgftMz4c=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=SvcbmohK/hTWqVCniDMxS/fw4FyrGej0fOahKoDoLnXSlW9bDK6PyDNzkbUZukehs B+8TeVo7aBt1N24d96bzw== 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:content-transfer-encoding:x-system-of-record; b=IReUYL/NWUG7mHRTiHsxfaBueYoLplq7IKsqcGEvTH/sKLUFEShFam6R4IzJpcbU4 gHrZrWJAR4ElHYYfoeW+Q== Received: from pxi12 (pxi12.prod.google.com [10.243.27.12]) by wpaz17.hot.corp.google.com with ESMTP id o4KGC8MX013629 for <oauth@ietf.org>; Thu, 20 May 2010 09:12:08 -0700 Received: by pxi12 with SMTP id 12so4421315pxi.14 for <oauth@ietf.org>; Thu, 20 May 2010 09:12:08 -0700 (PDT) Received: by 10.141.106.11 with SMTP id i11mr185570rvm.242.1274371926548; Thu, 20 May 2010 09:12:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Thu, 20 May 2010 09:11:46 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112637B8285@WSMSG3153V.srv.dir.telstra.com> References: <ADB082E11CEB5D49A3CC03E49DCECE02378CB8A679@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimiSqQjOsxDMxFGjIkP3xDQVHge6OJUPu9CYxHf@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B699132@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinlwZpM4PBHSR1t1whWR2p38PHq9VpcJw4p77vs@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E112637B8285@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 20 May 2010 09:11:46 -0700 Message-ID: <AANLkTin6LlrnLNAmubR2ez21ZbukcNv_Ag7jB_oUHDbY@mail.gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 16:12:25 -0000 On Wed, May 19, 2010 at 6:33 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote: > Marius, > >> Only direct responses are JSON, form/url encoded >> still has to be used: >> - direct requests >> - through browser requests >> - through browser responses >> - through browser fragment responses > > A better solution would be to change the last two (token info delivered i= n a callback URIs) so a single parameter (in the query or fragment) holds a= ll the token info -- as a base64url-encoded JSON value. I don't think the last one can be changed, parsing JSON in JavaScript can be tricky, Evan shows that in his reply. Also Evan points out that decoding Base64 is yet one more thing, much more complicated than percent decoding. > That is more complicated if you are only delivering a single quantity (eg= just an access_token). However, the difference diminishes as more and more= features are added: expires_in, scope, sites, refresh_token, access_token_= secret, realm, auth_scheme, whatever-comes-out-of-OpenID-Connect etc. > > A single parameter for token info in callback URIs also reduces the risk = of clashing with client-specific parameters in callback URIs as things are = added in the future (eg the earlier debate about no oauth_ prefix). If we could have JSON for all requests and responses, then maybe that will help. But I guess that's too hackish. If not, then not sure. Requests have just as many parameters as responses. > It eliminates the need to force all semantics to fit in a flat key/value = model. This can only get harder as features are added, or extensions are su= pported. The OpenID 2.0 approach of namespaces and parameter name prefixes = is not pretty. JSON does not solve this, but its structure helps. > > I wouldn't be surprised if, in some scenarios, the token info gets too bi= g to fit in a URI. In that case even the user-agent flow will need to make = a direct request to get the token info, which is more likely to be delivere= d as JSON. OpenID and SAML have found they need this (eg artefact flows). In this case the user-agent flow becomes the web server flow, which does this already, no? Marius > > > Please consider this as an open issue for today's meeting: a single param= eter holding a base64url-encode JSON value for packaging token info in a ca= llback URI. > > -- > James Manger > From eran@hueniverse.com Thu May 20 09:56:17 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D233A68C2 for <oauth@core3.amsl.com>; Thu, 20 May 2010 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[AWL=-1.670, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] 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 2vy93vU7xeVb for <oauth@core3.amsl.com>; Thu, 20 May 2010 09:56:02 -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 1BDB73A6847 for <oauth@ietf.org>; Thu, 20 May 2010 09:56:01 -0700 (PDT) Received: (qmail 27837 invoked from network); 20 May 2010 16:55:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 May 2010 16:54:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 20 May 2010 09:54:56 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Thu, 20 May 2010 09:54:55 -0700 Thread-Topic: [OAUTH-WG] Indicating sites where a token is valid Thread-Index: Acr4Nlbxr8cdqfiDTBW1fpPE3Db7iQABtUlu Message-ID: <C81AB76F.345FF%eran@hueniverse.com> In-Reply-To: <4353B564-4718-4323-A223-8F9D93A27F4B@gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C81AB76F345FFeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Indicating sites where a token is valid X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 20 May 2010 16:56:17 -0000 --_000_C81AB76F345FFeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes. The user is delegating access to the browser. EHL On 5/20/10 9:05 AM, "Dick Hardt" <dick.hardt@gmail.com> wrote: The image can be protected by both. Do you expect OAuth to be used with use= r present in the browser? On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote: Why can't an image be protected with both Basic and OAuth? In this case the= browser is the OAuth client. EHL From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Sunday, May 16, 2010 11:38 AM To: Eran Hammer-Lahav Cc: Evan Gilbert; OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid Not sure if you intended this, but you are mixing user present and user not= present access control. I do NOT think we want OAuth protected images to be the same as Basic auth = protected images. I do think OpenID protected images and Basic auth are sim= ilar. With OAuth today, the user has granted explicit permission at a parti= cular resource, not any resource the user may have access to. -- Dick On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: Today when I cut/paste a URI of an image using Basic auth, the browser know= s exactly what to do. I want to do the same with an OAuth-protected image. = Saying that there aren't standards API out there to benefit from this is in= correct. There are plenty. This is complete discovery for the authentication layer. The rest doesn't b= elong here, the same way this doesn't belong as part of the API specificati= on. EHL From: Evan Gilbert [mailto:uidude@google.com] Sent: Thursday, May 13, 2010 9:16 AM To: Eran Hammer-Lahav Cc: Manger, James H; OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Thu, May 13, 2010 at 9:08 AM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: You are trying to match a mechanism designed for automatic discovery with a= system designed to require paperwork. It sounds like for your use cases, y= ou will not be using this optional parameter and just document how to use y= our API (i.e. hardcode your security setup and API format). I'm saying it should be a fully automatic discovery or use paperwork. Havin= g an API return valid URL prefixes to send the token to without having an A= PI to determine the actual URLs you send tokens to seems odd. The whole point of this is that the developer isn't involved. The library t= akes care of everything. All the developer does is ask to get a protected r= esource. The library will check if it already has a valid token for that re= source (based on the security restrictions provided by the sites parameter,= and the scope requirements - two very separate things). This is an incomplete mechanism for automatic discovery. How does the devel= oper find out where to ask for the protected resource in the first place? So yes - if your developers have plenty of stuff to hardcode already, this = adds little value. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= van Gilbert Sent: Thursday, May 13, 2010 9:00 AM To: Manger, James H Cc: OAuth WG Subject: Re: [OAUTH-WG] Indicating sites where a token is valid On Wed, May 12, 2010 at 11:52 PM, Manger, James H <James.H.Manger@team.tels= tra.com> wrote: Evan, > The key point is that this discovery covers a lot of the same grounds as = the sites parameter, and it's hard to define semantics around a sites para= meter without understanding the semantics of scopes and API endpoints. I strongly disagree. The semantics are crystal clear: "Here is a token. It is INSECURE to send it anywhere not in this list." These semantics are useful regardless of what the API does, how the client = is using it, or how much (or how little) the client knows about the API. To expand - it's hard to define *useful* semantics around a sites parameter= without understanding the semantics of scopes and API endpoints. Yes, you = can define crystal clear semantics, but these are not useful unless they wo= rk well with the way developers figure out the endpoints to call APIs. > Clients need to [know] more about these links (at least the response form= at). That knowledge comes from other standards (HTML, Atom, wiki of rel values..= .) and is totally independent of whether a token should or should not be se= nt. In our use cases, clients almost always need to know more about the API: - How to call directly - we have no API endpoints that are only arrived at = by links - Response format of the data > The mechanism they use to find out about these links - documentation, dis= covery, data returned with token request - could also provide the informati= on about whether a token should be sent to a particular API. Could, but shouldn't and doesn't in practise. It is much much better to have the information about how to use a token sec= urely delivered at the same time & place as receiving that token, and with = minimal assumptions about how much the client apps knows about the service. So why wouldn't we return a list of specific API endpoints instead of a "si= tes" parameter? Developers are going to call the APIs endpoints that they know about. If th= ere is a conflict between this and the sites parameter, what should they do= ? For example, if facebook returns a sites parameter "https://unknown.faceb= ook.com/", do we think the developer is going to not try to use the access = token on https://graph.facebook.com/ <https://graph.facebook.com/*> ? Separating the concept of sites from API endpoints feels like a bad idea. D= iscovery / docs will give you a list of URLs where you should send tokens. = The "sites" parameter will give you a list of URLs where you can send token= s. This is redundant, and will lead to developers / libraries not respectin= g the sites parameter. If developers / libraries don't respect it, then the= service can't rely on it for enforcing security. Another note: Where do we anticipate clients storing the sites parameter in= the User-Agent flow? Right now the access token can be set as an HTTP cook= ie by the client. Do we expect them to set a separate "sites" cookie and re= spect this on their server when making requests? This seems complicated. > I should be more concrete about the use cases I see. Let's assume there's= an API where there are two endpoints, each with an associated permission > - contacts.list permission -> http://contacts.serviceprovider.com/contact= s/list > - calendar.get permission -> http://calendar.serviceprovider.com/calendar= /get > > If the response to an authorization request includes the authorized scope= s (contacts.list, calendar.get), then the "sites" parameter is redundant. I'll admit that "sites" is redundant if a client has *perfect* knowledge ab= out a service, but so is pretty much any standard at that point. Consider a generic search spider tool that you point at http://calendar.ser= viceprovider.com/calendar/get. It can do its job with no knowledge about wh= at "calendar.get" means -- but it still needs to know (as it spiders along)= when it is safe to expose the token. How does the generic search spider know to call to http://calendar.servicep= rovider.com/calendar/get in the first place? -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C81AB76F345FFeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] Indicating sites where a token is valid Yes. The user is delegating access to the browser.

EHL


On 5/20/10 9:05 AM, "Dick Hardt" <dick.hardt@gmail.com> wrote:

The image can be protected by both. Do you = expect OAuth to be used with user present in the browser?

On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote:

Why can’t an image be protected with = both Basic and OAuth? In this case the browser is the OAuth client.
 
EHL
 
From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Sunday, May 16, 2010 11:38 AM
To: Eran Hammer-Lahav
Cc: Evan Gilbert; OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
Not sure if you intended this, but you are mixing user present and user not= present access control.

I do NOT think we want OAuth protected images to be the same as Basic auth = protected images. I do think OpenID protected images and Basic auth are sim= ilar. With OAuth today, the user has granted explicit permission at a parti= cular resource, not any resource the user may have access to.
 
-- Dick
 
On Thu, May 13, 2010 at 9:30 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrot= e:
Today when I cut/paste a URI of an im= age using Basic auth, the browser knows exactly what to do. I want to do th= e same with an OAuth-protected image. Saying that there aren’t standa= rds API out there to benefit from this is incorrect. There are plenty.
 
This is complete discovery for the authentication layer. The rest doesnR= 17;t belong here, the same way this doesn’t belong as part of the API= specification.
 
EHL
 
From: Evan Gi= lbert [mailto:uidude@= google.com]
Sent: Thursday, May 13, 2010 9:16 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; OAuth WG

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

On Thu, May 13, 2010 at 9:08 AM, Eran= Hammer-Lahav <e= ran@hueniverse.com> wrote:
You are trying to match a mechanism designed for automatic discovery with = a system designed to require paperwork. It sounds like for your use cases, = you will not be using this optional parameter and just document how to use = your API (i.e. hardcode your security setup and API format).
I'm saying it should be a fully automatic discovery or use paperwork. Havin= g an API return valid URL prefixes to send the token to without having an A= PI to determine the actual URLs you send tokens to seems odd.

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

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

So yes – if your developers have plenty of stuff to hardcode already,= this adds little value.
 
EHL
 
From: oauth-bounces@ietf.org<= /a> [mailto:oauth-bounces@ietf.org] On Behalf Of Evan Gilbert
Sent: Thursday, May 13, 2010 9:00 AM

To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
 
 

On Wed, May 12, 2010 at 11:52 PM, Man= ger, James H <James.H.Manger@team.telstra.com> wrote:
Evan,

> The key point is that this discovery covers a lot of the same grounds = as the sites parameter, and it's hard  to define semantics around a si= tes parameter without understanding the semantics of scopes and API endpoin= ts.
I strongly disagree. The semantics are crystal clear:
 "Here is a token. It is INSECURE to send it anywhere not in this= list."
These semantics are useful regardless of what the API does, how the client = is using it, or how much (or how little) the client knows about the API.  
To expand - it's hard to define *useful* semantics around a sites parameter= without understanding the semantics of scopes and API endpoints. Yes, you = can define crystal clear semantics, but these are not useful unless they wo= rk well with the way developers figure out the endpoints to call APIs.
 


> Clients need to [know] more about these links (at least the response f= ormat).

That knowledge comes from other standards (HTML, Atom, wiki of rel values..= .) and is totally independent of whether a token should or should not be se= nt.

In our use cases, clients almost always need to know more about the API: - How to call directly - we have no API endpoints that are only arrived at = by links
- Response format of the data
 


> The mechanism they use to find out about these links - documentation, = discovery, data returned with token request - could also provide the inform= ation about whether a token should be sent to a particular API.
Could, but shouldn't and doesn't in practise.
It is much much better to have the information about how to use a token sec= urely delivered at the same time & place as receiving that token, and w= ith minimal assumptions about how much the client apps knows about the serv= ice.

So why wouldn't we return a list of specific API endpoints instead of a &qu= ot;sites" parameter?
 
Developers are going to call the APIs endpoints that they know about. If th= ere is a conflict between this and the sites parameter, what should they do= ? For example, if facebook returns a sites parameter "https://unknown.facebook.= com/", do we think the developer is going to not try to use= the access token on https://graph.facebook.com/ <https://graph.facebook.com/*> <= /FONT> ?

Separating the conce= pt of sites from API endpoints feels like a bad idea. Discovery / docs will= give you a list of URLs where you should send tokens. The "sites"= ; parameter will give you a list of URLs where you can send tokens. This is= redundant, and will lead to developers / libraries not respecting the site= s parameter. If developers / libraries don't respect it, then the service c= an't rely on it for enforcing security.
Another note: Where = do we anticipate clients storing the sites parameter in the User-Agent flow= ? Right now the access token can be set as an HTTP cookie by the client. Do= we expect them to set a separate "sites" cookie and respect this= on their server when making requests? This seems complicated.


> I should be more concrete about the use cases I see. Let's assume ther= e's an API where there are two endpoints, each with an associated permissio= n
> - contacts.list permission -> http://contacts.servicepro= vider.com/contacts/list
> - calendar.get permission -> http://calendar.servi= ceprovider.com/calendar/get
>
> If the response to an authorization request includes the authorized sc= opes (contacts.list, calendar.get), then the "sites" parameter is= redundant.
I'll admit that "sites" is redundant if a client has *perfect* kn= owledge about a service, but so is pretty much any standard at that point.<= BR>
Consider a generic search spider tool that you point at http://ca= lendar.serviceprovider.com/calendar/get. It can do its job with = no knowledge about what "calendar.get" means -- but it still need= s to know (as it spiders along) when it is safe to expose the token.

How does the generic search spider know to call to = http://calenda= r.serviceprovider.com/calendar/get in the first place?
 


--
James Manger



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth
To: OAuth WG Date: Thu, 20 May 2010 12:24:54 -0500 Thread-Topic: New Version Notification for draft-zeltsan-use-cases-oauth-00 Thread-Index: Acr2UFETnrXT/9MPT/6KUWgYmb7KBQB8CLVA Message-ID: <5710F82C0E73B04FA559560098BF95B124F859C32C@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [OAUTH-WG] FW: New Version Notification for draft-zeltsan-use-cases-oauth-00 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, 20 May 2010 17:28:24 -0000 This is a link to the draft on the use cases that I presented at today's me= eting. http://www.ietf.org/id/draft-zeltsan-use-cases-oauth-00.txt Zachary -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, May 18, 2010 2:07 AM To: Zeltsan, Zachary (Zachary) Subject: New Version Notification for draft-zeltsan-use-cases-oauth-00=20 A new version of I-D, draft-zeltsan-use-cases-oauth-00.txt has been success= fully submitted by Zachary Zeltsan and posted to the IETF repository. Filename: draft-zeltsan-use-cases-oauth Revision: 00 Title: OAuth Use Cases Creation_date: 2010-05-18 WG ID: Independent Submission Number_of_pages: 14 Abstract: This document lists the OAuth use cases. The document's objective is to identify the use cases that will be a base for deriving the OAuth requirements. The provided list is based on the Internet-Drafts and other OAuth-related documents that have been discussed by the participants of the oauth working group. = =20 The IETF Secretariat. From leah.culver@gmail.com Thu May 20 11:42:58 2010 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 293613A684F for ; Thu, 20 May 2010 11:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 X71WwRJGYw77 for ; Thu, 20 May 2010 11:42:57 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 282E73A6844 for ; Thu, 20 May 2010 11:42:54 -0700 (PDT) Received: by pwi1 with SMTP id 1so64991pwi.31 for ; Thu, 20 May 2010 11:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=7uKs6miXh0Yl2q1JqHGV7jp0VAHPEeBttqCzX//rQik=; b=Qi5gZjUsuPzvb9bdXudTESTe0cEE6eApqxESf94vkih7BLVCBNeXuxJbryffmLm/bf cZfSMJv61XE5wr9tmQrNYUdL3CfMzjQRS5PddW/dw2Oz8rzW6j4TqdZMC5VCk79O1mgm LuBlJKZuMySCYHjruO2z93vBZTAVp3yGPQ8NY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=FcjmA4T7/l4snCFnzE/WR2wgPUfurPUheGBxm9lVwA2Sa9TugKFWKryYAdZNRF5bDj YtVvsr8JbHCZQXNCGNV0ZmhaDPe41ipjRxaqXohBGw9VQ/uuUTKHnIN7BlEQlZBWOGXb wokyc1xVtwCGcNAeRNY/wreINFIFIz2Wk+Gc8= Received: by 10.140.252.3 with SMTP id z3mr309801rvh.285.1274380964943; Thu, 20 May 2010 11:42:44 -0700 (PDT) Received: from [10.85.37.219] ([166.205.137.243]) by mx.google.com with ESMTPS id h11sm132433rvm.9.2010.05.20.11.42.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 May 2010 11:42:43 -0700 (PDT) Message-Id: <3597B5B0-33FF-4529-B81D-399BCCC57D67@gmail.com> From: Leah Culver To: "oauth@ietf.org" Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7E18) Date: Thu, 20 May 2010 11:42:20 -0700 X-Mailer: iPhone Mail (7E18) Subject: [OAUTH-WG] Figure titles 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, 20 May 2010 18:42:58 -0000 For extra readability can we add titles to the figures in the Internet- Drafts? I think it would make it easier to skim sections, such as the various flows. Here are my suggestions for titles for draft-ietf-oauth-v2-05: Figure 1 - Generic flow between client and server Figure 2 - Obtaining a new access token to access protected resources Figure 3 - User-Agent flow Figure 4 - Web server flow Figure 5 - Device flow Figure 6 - Username and password flow Figure 7 - Client credentials flow Figure 8 - Assertion flow Figure 9 - Obtaining a new access token using a refresh token Figures 2 and 9 are fairly similar but 9 focuses on obtaining the access token. Thoughts? Leah From yarong@microsoft.com Thu May 20 12:20:38 2010 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 E0C593A68E1 for ; Thu, 20 May 2010 12:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.486 X-Spam-Level: X-Spam-Status: No, score=-8.486 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 hBHJ9KpKhPgf for ; Thu, 20 May 2010 12:20:32 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 388323A6AC7 for ; Thu, 20 May 2010 12:20:01 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 May 2010 12:19:54 -0700 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.31]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Thu, 20 May 2010 12:19:54 -0700 From: Yaron Goland To: "oauth@ietf.org" Thread-Topic: Questions about sections 3.2/3.3 Thread-Index: Acr4TV5Gu7PqT32USNegznSs4LRTdw== Date: Thu, 20 May 2010 19:19:53 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C578D67E6TK5EX14MBXC113r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Questions about sections 3.2/3.3 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, 20 May 2010 19:20:39 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C578D67E6TK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was reading through the spec and had some questions about 3.2 and 3.3 tha= t I list below. Thanks, Yaron Section 3.2/3.3 - Handling requests without supported transport layer secur= ity Although optional in section 3.2 and mandatory in section 3.3 both sections= have a similar challenge - what happens if someone makes a request without= the transport layer security required by the endpoint? What HTTP error is = to be returned? 401? 403? A further complication is that both sections explicitly allow for transport= layer security solutions other than TLS/SSL. Doesn't this mean that we nee= d to extend section 6.1's definition of the www-authenticate response heade= r to also specify what transport layer security mechanisms are supported? Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what version of = TLS/SSL? The specification currently states: ...the authorization server MUST require the use of a transport-layer mechanism such as TLS/SSL (or a secure channel with equivalent protections) when sending requests to the token endpoints. To me this text implies that an OAuth server could be conformant and not im= plement TLS/SSL but instead implement some other transport-layer security m= echanism (say a VPN protocol). From an interoperability perspective that se= ems problematic since it means clients can't know what transport-layer solu= tion the token endpoint will support. Wouldn't it be reasonable to put in a= requirement that all OAuth endpoints MUST support RFC 5246 and RFC 5746? In other words the language could read: "...the authorization server MUST r= equire the use of a transport-layer mechanism when sending requests to the = token endpoints. Specifically, authorization servers MUST support version 1= .2 of TLS as defined in RFC 5246 and extended in RFC 5746 and MAY support o= ther equivalent secure channel mechanisms". Section 3.3.1 - What error is returned if clients provide credentials in bo= th the header and the body? Section 3.3.1 explicitly prohibits submitting client credentials using mult= iple schemes but it doesn't define what error to return if this requirement= is violated. Given the requirement in section 3.3.2.2 to include the "erro= r" field wouldn't it be useful to define URIs that map to specific errors d= efined in the specification? For example, "If the client does include multi= ple client credential schemes then, per section 3.3.2.2, a 400 Bad Request = response MUST be sent with an error code of urn:ietf:rfc:X:multiple-client-= credentials". Section 3.3.1 - How exactly are client credentials passed via HTTP Basic au= thentication? Although section 3.3.1 states that HTTP basic authentication is to be suppo= rted, it doesn't specify how. I realize the mapping is pretty obvious but s= tandards are one area where it pays off to be pedantic. Would it be useful = to add language such as?: "The authorization server MUST accept the client credentials using both the= request parameters and the HTTP Basic authentication scheme as defined in = [RFC2617]. When using HTTP Basic the client id MUST be mapped to the HTTP B= asic userid and the client secret MUST be mapped to the HTTP Basic password= . The realm value can either be discovered by sending an unauthenticated re= quest and examining the returned realm value in the www-Authenticate header= or by reading the authorization service's documentation." --_000_7C01E631FF4B654FA1E783F1C0265F8C578D67E6TK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was reading th= rough the spec and had some questions about 3.2 and 3.3 that I list below.<= o:p>

      &nbs= p;         Thanks,

         &n= bsp;            = ;          Yaron

Section 3.2/3.3 – Handling requests without supported transport = layer security

 

Although optional in section 3.2 and mandatory in section= 3.3 both sections have a similar challenge – what happens if someone= makes a request without the transport layer security required by the endpo= int? What HTTP error is to be returned? 401? 403?

 

A further complicati= on is that both sections explicitly allow for transport layer security solu= tions other than TLS/SSL. Doesn’t this mean that we need to extend se= ction 6.1’s definition of the www-authenticate response header to als= o specify what transport layer security mechanisms are supported?

 

Section 3.3 – Is T= LS/SSL mandatory or optional? And if so, what version of TLS/SSL?

 

The sp= ecification currently states:

 = ;

   …the

   authorization server MUST require the use of a t= ransport-layer

   mechanism suc= h as TLS/SSL (or a secure channel with equivalent

   protections) when sending requests to the token endpo= ints.

 

To me this text implies that an OAuth server could be conformant an= d not implement TLS/SSL but instead implement some other transport-layer se= curity mechanism (say a VPN protocol). From an interoperability perspective= that seems problematic since it means clients can’t know what transp= ort-layer solution the token endpoint will support. Wouldn’t it be re= asonable to put in a requirement that all OAuth endpoints MUST support RFC = 5246 and RFC 5746?

 

In other words the language could read: “…= ;the authorization server MUST require the use of a transport-layer mechani= sm when sending requests to the token endpoints. Specifically, authorizatio= n servers MUST support version 1.2 of TLS as defined in RFC 5246 and extend= ed in RFC 5746 and MAY support other equivalent secure channel mechanisms&#= 8221;.  

 

S= ection 3.3.1 – What error is returned if clients provide credentials = in both the header and the body?

&= nbsp;

Section 3.3.1 explicitly prohibits subm= itting client credentials using multiple schemes but it doesn’t defin= e what error to return if this requirement is violated. Given the requireme= nt in section 3.3.2.2 to include the “error” field wouldn’= ;t it be useful to define URIs that map to specific errors defined in the s= pecification? For example, “If the client does include multiple clien= t credential schemes then, per section 3.3.2.2, a 400 Bad Request response = MUST be sent with an error code of urn:ietf:rfc:X:multiple-client-credentia= ls”.

 

Sect= ion 3.3.1 – How exactly are client credentials passed via HTTP Basic = authentication?

 

Although section 3.3.1 states that HTTP basic authentica= tion is to be supported, it doesn’t specify how. I realize the mappin= g is pretty obvious but standards are one area where it pays off to be peda= ntic. Would it be useful to add language such as?:

 

“The authoriza= tion server MUST accept the client credentials using both the request param= eters and the HTTP Basic authentication scheme as defined in [RFC2617]. Whe= n using HTTP Basic the client id MUST be mapped to the HTTP Basic userid an= d the client secret MUST be mapped to the HTTP Basic password. The realm va= lue can either be discovered by sending an unauthenticated request and exam= ining the returned realm value in the www-Authenticate header or by reading= the authorization service’s documentation.”

 

= --_000_7C01E631FF4B654FA1E783F1C0265F8C578D67E6TK5EX14MBXC113r_-- From zachary.zeltsan@alcatel-lucent.com Thu May 20 15:56:09 2010 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 9C9113A6879 for ; Thu, 20 May 2010 15:56:09 -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, 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 12Xmv0qJNVr2 for ; Thu, 20 May 2010 15:56:06 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E6C873A6875 for ; Thu, 20 May 2010 15:56:05 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o4KMtwcx011474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 May 2010 17:55:58 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o4KMtwG2024509 for ; Thu, 20 May 2010 17:55:58 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 20 May 2010 17:55:57 -0500 From: "Zeltsan, Zachary (Zachary)" To: OAuth WG Date: Thu, 20 May 2010 17:51:16 -0500 Thread-Topic: Draft on the OAuth use cases Thread-Index: Acr4bvQuY06MUKOZQzCe7N9dLC4Fbg== Message-ID: <5710F82C0E73B04FA559560098BF95B124F859C32F@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: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124F859C32FUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [OAUTH-WG] Draft on the OAuth use cases 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, 20 May 2010 22:56:09 -0000 --_000_5710F82C0E73B04FA559560098BF95B124F859C32FUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the IETF 77 the need for documenting the OAuth use cases was discussed a= nd I volunteered writing a draft. The draft has been published at http://www.ietf.org/id/draft-zeltsan-use-cases-oauth-00.txt. At today's interim meeting its presentation did not generate any controvers= y. Please provide your comments on the draft and consider a proposal of making= it a work item. Zachary Zeltsan --_000_5710F82C0E73B04FA559560098BF95B124F859C32FUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
At the IETF 77 the need for documenting the OAuth use cases was discus= sed and I volunteered writing a draft. The draft has been published at
At today’s interim meeting its presentation did not generate any= controversy.
 
Please provide your comments on the draft and consider a proposal of m= aking it a work item.
 
Zachary Zeltsan
  --_000_5710F82C0E73B04FA559560098BF95B124F859C32FUSNAVSXCHMBSA_-- From balfanz@google.com Thu May 20 16:39:40 2010 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 1EB623A6879 for ; Thu, 20 May 2010 16:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.376 X-Spam-Level: X-Spam-Status: No, score=-99.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tag77Sw+jjW2 for ; Thu, 20 May 2010 16:39:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C193C3A67BD for ; Thu, 20 May 2010 16:39:37 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o4KNdPhV027494 for ; Thu, 20 May 2010 16:39:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274398766; bh=YQAAw3aF2AovfXkxsfwnkAfCAbg=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=GKJu0p5yqHzj+yfu3zBeEVn/smUjSpFboDXpCNqmpLLPWvGqGVFu61nPx3IyO7ma6 QAZUKXqyGR0k2GKim5GIw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=Hpaq0CMT2wxl0K921jwk/c5UraG0XDbMsh6z0kzHso7nIGe1C2fxj0ZPhycE7Rk2o J+K+ZQ86K5kFle9GUAkpQ== Received: from iwn4 (iwn4.prod.google.com [10.241.68.68]) by wpaz13.hot.corp.google.com with ESMTP id o4KNdNGD024452 for ; Thu, 20 May 2010 16:39:24 -0700 Received: by iwn4 with SMTP id 4so471075iwn.23 for ; Thu, 20 May 2010 16:39:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.147.18 with SMTP id j18mr654507ibv.12.1274398763699; Thu, 20 May 2010 16:39:23 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Thu, 20 May 2010 16:39:23 -0700 (PDT) Date: Thu, 20 May 2010 16:39:23 -0700 Message-ID: From: Dirk Balfanz To: OAuth WG Content-Type: multipart/alternative; boundary=001485ec0e589ccf2704870f1579 X-System-Of-Record: true Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 20 May 2010 23:39:40 -0000 --001485ec0e589ccf2704870f1579 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, at today's interim meeting, we were discussing Brian Eaton's proposal for OAuth signatures. He was proposing a mechanism that would (1) do away with base string canonicalization, (2) allow for symmetric and public keys, and (3) allow for extensibility. He got homework from the group to prove the feasibility of his proposal by showing a couple of implementations. In this post, I would like to introduce another improvement of the OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would work both with the signing mechanism in the current spec, as well as with Brian's signature mechanism). The goal of my proposal is twofold: - it simplifies the spec. It will become more readable and therefore easier to implement - it separates out the mechanisms for delegated authorization and for integrity protection into two independent pieces, which can be put together by Servers and/or Clients like LEGO blocks. Summary: - use the client secret instead of the token secret for signing PR access requests. Long version of the proposal: - remove all references to access tokens that are not bearer tokens from the spec. - stop calling the access tokens "bearer tokens". Call them just "access tokens". - remove all references to token secrets from the spec - remove all parts of the spec that are of the kind "if bearer_token then X, else Y", and replace them with X. - delete section 5.3 - add a section called "Request Authentication" that goes something like this: "Servers may require that requests be authenticated by the Client, so that presentation of the access token alone is not sufficient to access a Protected Resource. This has several use cases, including, but not limited to, the following: - Non-repudiation: high-security deployments may require that requests be authenticated (signed) in a non-repudiateable way[1] - Access to protected resources is not protected by SSL, so that access tokens may leak. - End-to-end-integrity: even if SSL _is_ used, network infrastructure may strip SSL protection before the request reaches the protected resource. The protected resource, however, may require end-to-end integrity. If the Server requires that the Client authenticate PR access requests, then the Client uses the following mechanism to sign their HTTP requests: [...]" Then, we basically drop the old Section 5.3 here (except we use the client secret instead of the access token secret). Eventually, instead of Section 5.3, we may have Brian's new signature scheme section here, which would add the option of public-key crypto[1], etc. What do you guys think? Dirk. [1] Technically speaking, the goal of non-repudiation can only be achieved once we have public-key crypto. --001485ec0e589ccf2704870f1579 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys,=A0

at today's interim meeting, we were disc= ussing Brian Eaton's proposal for OAuth signatures. He was proposing a = mechanism that would (1) do away with base string canonicalization, (2) all= ow for symmetric and public keys, and (3) allow for extensibility.=A0

He got homework from the group to prove the feasibility= of his proposal by showing a couple of implementations.=A0

<= /div>
In this post, I would like to introduce another improvement of th= e OAuth 2 signing mechanism, one which is orthogonal to Brian's proposa= l (i.e., it would work both with the signing mechanism in the current spec,= as well as with Brian's signature mechanism). The goal of my proposal = is twofold:

- it simplifies the spec. It will become more readable = and therefore easier to implement
- it separates out the mechanis= ms for delegated authorization and for integrity protection into two indepe= ndent pieces, which can be put together by Servers and/or Clients like LEGO= blocks.

Summary:

- use the client secr= et instead of the token secret for signing PR access requests.
Long version of the proposal:

- remov= e all references to access tokens that are not bearer tokens from the spec.=
- stop calling the access tokens "bearer tokens". Call them = just "access tokens".=A0
- remove all references to tok= en secrets from the spec
- remove all parts of the spec that are = of the kind "if bearer_token then X, else Y", and replace them wi= th X.
- delete section 5.3
- add a section called "Request Au= thentication" that goes something like this:

= "Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a P= rotected Resource. =A0This has several use cases, including, but not limite= d to, the following:

- Non-repudiation: high-security deployments may requir= e that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that acc= ess tokens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure = may strip SSL protection before the request reaches the protected resource.= The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR = access requests, then the Client uses the following mechanism to sign their= HTTP requests: [...]"

Then, we basically dro= p the old Section 5.3 here (except we use the client secret instead of the = access token secret). Eventually, instead of Section 5.3, we may have Brian= 's new signature scheme section here, which would add the option of pub= lic-key crypto[1], etc.

What do you guys think?

Dirk.<= /div>

[1] Technically speaking, the goal of non-repudiat= ion can only be achieved once we have public-key crypto.

--001485ec0e589ccf2704870f1579-- From recordond@gmail.com Thu May 20 17:48:13 2010 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 BF51F3A6826 for ; Thu, 20 May 2010 17:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.913 X-Spam-Level: X-Spam-Status: No, score=-0.913 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_50=0.001, 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 tKRISZYmqLDK for ; Thu, 20 May 2010 17:48:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D2EE53A68C7 for ; Thu, 20 May 2010 17:45:05 -0700 (PDT) Received: by iwn42 with SMTP id 42so523712iwn.31 for ; Thu, 20 May 2010 17:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=eMZylznVimFM8v4yITrC92AfZ5GhjkJ21VYwC9krnuI=; b=P/jpcmrvp7Ci2jBr/TPATVPAJDsyuxknbLcvpAhVkwXVVj+hkhmqp8Dh1JnarEKe0n miE+mhMa89em9yZphaXcrRNr2dzvesfRi6cRkp+JCuDRdfBEk5MBj7MshayV61gizs/b 3vl0FEJcbM0Kah3/+fTHfdLtIvb8mKkGkNaRM= 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=uz0+29Id8Zgh9VWuBBuxSJoZcksPkv8JnsxD+WHy7owXTl3j6dGoLhSvTyCVr/g2l8 9PX16XIYH89H6vrg/drtxqH+7x7tNI41+XNkszJneh0A6ZDnDBSwukhjrbBMSg+vWNRA x33ixAmvVhHBNshbqh2QHwPHIBsmdccj7rAw4= MIME-Version: 1.0 Received: by 10.231.158.130 with SMTP id f2mr886653ibx.40.1274402696578; Thu, 20 May 2010 17:44:56 -0700 (PDT) Received: by 10.231.192.6 with HTTP; Thu, 20 May 2010 17:44:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 May 2010 17:44:56 -0700 Message-ID: From: David Recordon To: Dirk Balfanz Content-Type: multipart/alternative; boundary=001636c5a2f507c81d0487100064 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Fri, 21 May 2010 00:48:13 -0000 --001636c5a2f507c81d0487100064 Content-Type: text/plain; charset=ISO-8859-1 We're able to use the client secret for signing requests instead of a token secret, but my understanding is that this exists because of deployers who do not wish for their protected resources to have access to client secrets. --David On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz wrote: > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away with > base string canonicalization, (2) allow for symmetric and public keys, and > (3) allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal by > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it > would work both with the signing mechanism in the current spec, as well as > with Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easier > to implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put together > by Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from > the spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then > X, else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like > this: > > "Servers may require that requests be authenticated by the Client, so that > presentation of the access token alone is not sufficient to access a > Protected Resource. This has several use cases, including, but not limited > to, the following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access > tokens may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. The > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, > then the Client uses the following mechanism to sign their HTTP requests: > [...]" > > Then, we basically drop the old Section 5.3 here (except we use the client > secret instead of the access token secret). Eventually, instead of Section > 5.3, we may have Brian's new signature scheme section here, which would add > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieved > once we have public-key crypto. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001636c5a2f507c81d0487100064 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We're able to use the client secret for signing requests instead of a t= oken secret, but my understanding is that this exists because of deployers = who do not wish for their protected resources to have access to client secr= ets.

--David


On Thu,= May 20, 2010 at 4:39 PM, Dirk Balfanz <balfanz@google.com> wrote:
Hi guys,=A0

at today's interim meeting, we were disc= ussing Brian Eaton's proposal for OAuth signatures. He was proposing a = mechanism that would (1) do away with base string canonicalization, (2) all= ow for symmetric and public keys, and (3) allow for extensibility.=A0

He got homework from the group to prove the feasibility= of his proposal by showing a couple of implementations.=A0

<= /div>
In this post, I would like to introduce another improvement of th= e OAuth 2 signing mechanism, one which is orthogonal to Brian's proposa= l (i.e., it would work both with the signing mechanism in the current spec,= as well as with Brian's signature mechanism). The goal of my proposal = is twofold:

- it simplifies the spec. It will become more readable = and therefore easier to implement
- it separates out the mechanis= ms for delegated authorization and for integrity protection into two indepe= ndent pieces, which can be put together by Servers and/or Clients like LEGO= blocks.

Summary:

- use the client secr= et instead of the token secret for signing PR access requests.
Long version of the proposal:

- remov= e all references to access tokens that are not bearer tokens from the spec.=
- stop calling the access tokens "bearer tokens". Call them = just "access tokens".=A0
- remove all references to tok= en secrets from the spec
- remove all parts of the spec that are = of the kind "if bearer_token then X, else Y", and replace them wi= th X.
- delete section 5.3
- add a section called "Request Au= thentication" that goes something like this:

= "Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a P= rotected Resource. =A0This has several use cases, including, but not limite= d to, the following:

- Non-repudiation: high-security deployments may requir= e that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that acc= ess tokens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure = may strip SSL protection before the request reaches the protected resource.= The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR = access requests, then the Client uses the following mechanism to sign their= HTTP requests: [...]"

Then, we basically dro= p the old Section 5.3 here (except we use the client secret instead of the = access token secret). Eventually, instead of Section 5.3, we may have Brian= 's new signature scheme section here, which would add the option of pub= lic-key crypto[1], etc.

What do you guys think?

Dirk.<= /div>

[1] Technically speaking, the goal of non-repudiat= ion can only be achieved once we have public-key crypto.


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


--001636c5a2f507c81d0487100064-- From James.H.Manger@team.telstra.com Thu May 20 20:42:09 2010 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 454293A6A5A for ; Thu, 20 May 2010 20:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.544 X-Spam-Level: * X-Spam-Status: No, score=1.544 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGjwJvNFiHhv for ; Thu, 20 May 2010 20:42:08 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 120133A7CFD for ; Thu, 20 May 2010 19:33:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,274,1272808800"; d="scan'208";a="3406194" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 May 2010 12:33:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5988"; a="2212652" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcbvi.tcif.telstra.com.au with ESMTP; 21 May 2010 12:33:33 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Fri, 21 May 2010 12:33:33 +1000 From: "Manger, James H" To: Marius Scurtescu Date: Fri, 21 May 2010 12:33:31 +1000 Thread-Topic: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) Thread-Index: Acr4NzUWY2FTmG8xQB+BiXl0erTnUgARvBng Message-ID: <255B9BB34FB7D647A506DC292726F6E112638877F9@WSMSG3153V.srv.dir.telstra.com> References: <7C01E631FF4B654FA1E783F1C0265F8C4A42BFCC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B69895B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B6989D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <09A6EF98-7406-43D8-9B1C-C16E38CA35D1@gmail.com> <7C01E631FF4B654FA1E783F1C0265F8C4A4312FC@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B699132@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112637B8285@WSMSG3153V.srv.dir.telstra.com> 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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13) 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, 21 May 2010 03:42:09 -0000 TWFyaXVzLA0KDQoNCj4+IEkgd291bGRuJ3QgYmUgc3VycHJpc2VkIGlmLCBpbiBzb21lIHNjZW5h cmlvcywgdGhlIHRva2VuIGluZm8gZ2V0cyB0b28gYmlnIHRvIGZpdCBpbiBhIFVSSS4gSW4gdGhh dCBjYXNlIGV2ZW4gdGhlIHVzZXItYWdlbnQgZmxvdyB3aWxsIG5lZWQgdG8gbWFrZSBhIGRpcmVj dCByZXF1ZXN0IHRvIGdldCB0aGUgdG9rZW4gaW5mbywgd2hpY2ggaXMgbW9yZSBsaWtlbHkgdG8g YmUgZGVsaXZlcmVkIGFzIEpTT04uIE9wZW5JRCBhbmQgU0FNTCBoYXZlIGZvdW5kIHRoZXkgbmVl ZCB0aGlzIChlZyBhcnRlZmFjdCBmbG93cykuDQoNCj4gSW4gdGhpcyBjYXNlIHRoZSB1c2VyLWFn ZW50IGZsb3cgYmVjb21lcyB0aGUgd2ViIHNlcnZlciBmbG93LCB3aGljaA0KPiBkb2VzIHRoaXMg YWxyZWFkeSwgbm8/DQoNClRoZSBoYXNzbGUgaXMgdGhhdCB0aGUgY2xpZW50IGNob29zZXMgdHlw ZT11c2VyX2FnZW50IGF0IHRoZSBzdGFydCBzbyB0aGUgYXV0aHogc2VydmVyIGNhbm5vdCBjaGFu Z2UgdGhpcyB0byBhIHdlYl9zZXJ2ZXIgZmxvdyBsYXRlciBpZiB0aGUgcmVzcG9uc2UgZG9lc24n dCBmaXQgaW4gdGhlIHJlZGlyZWN0IFVSSS4NCg0KVGhlIHNwZWMgc2hvdWxkIGNoYW5nZSB0aGlz IC0tIGFsbG93aW5nIHRoZSBhdXRoeiBzZXJ2ZXIgdG8gY2hvb3NlIHRvIHJlc3BvbmQgd2l0aCB0 b2tlbiBkZXRhaWxzIGluIHRoZSByZWRpcmVjdCBVUkkgb3Igd2l0aCB0b2tlbiBkZXRhaWxzIGF2 YWlsYWJsZSBhdCBhIHRva2VuIFVSSS4NCldoZW4gaXQgaXMgdGhlIHNlcnZlcidzIGNob2ljZSwg dGhlIGNsaWVudCBuZWVkcyB0byBoYW5kbGUgYm90aCBwb3NzaWJpbGl0aWVzLg0KDQoNCg0KDQpP biB0aGUgb3RoZXIgaXNzdWVzOg0KDQo+IHBhcnNpbmcgSlNPTiBpbiBKYXZhU2NyaXB0IGNhbiBi ZSB0cmlja3kNCg0KVGhpcyBpcyBub3QgdHJ1ZS4NCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0 aGUgY3VycmVudCB2ZXJzaW9ucyBvZiBGaXJlZm94LCBJRSwgT3BlcmEsIENocm9tZSwgYW5kIFNh ZmFyaSBhbGwgc3VwcG9ydCBKU09OLnBhcnNlKCkuDQpJbiBvbGRlciBicm93c2VycyB5b3UgbWF5 IG5lZWQgdG8gdXNlIGV2YWwoKSwgYnV0IHRoZSBKU09OIFJGQyAoYW5kIEV2YW4ncyBlbWFpbCkg c2hvdyBob3cgdG8gbWFrZSB0aGF0IHNhZmUgd2l0aCAzIGxpbmVzIG9mIGNvZGU7IG9yIHVzZSBq c29uMi5qcyAoYXZhaWxhYmxlIGZyb20ganNvbi5vcmcpIHRoYXQgaW1wbGVtZW50cyBKU09OLnBh cnNlKCkgZm9yIG9sZGVyIGJyb3dzZXJzLg0KDQoNCj4gZGVjb2RpbmcgQmFzZTY0IGlzIHlldCBv bmUgbW9yZSB0aGluZywgbXVjaCBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gcGVyY2VudCBkZWNvZGlu Zy4NCg0KQmFzZTY0IGlzIHNvIHdpZGVseSB1c2VkIHRoYXQgSSBkb24ndCBjb25zaWRlciBpdCB1 bnJlYXNvbmFibGUgdG8gcmVxdWlyZS4NCkJhc2U2NHVybCBpcyBsZXNzIGNvbW1vbiwgYnV0IGp1 c3QgYXMgc2ltcGxlLg0KSSBkb24ndCB0aGluayBpdCBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYXQg JS1kZWNvZGluZy4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From atom@yahoo-inc.com Thu May 20 20:46:45 2010 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 807EE3A6E93 for ; Thu, 20 May 2010 20:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.115 X-Spam-Level: X-Spam-Status: No, score=-14.115 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] 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 mC1DYJIWO8yW for ; Thu, 20 May 2010 20:46:40 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id ABBF13A71D4 for ; Thu, 20 May 2010 19:38:10 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o4L2aSme028439; Thu, 20 May 2010 19:36:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: return-path:x-originalarrivaltime; b=SISd9X7Sevpn9/EU9vR4loWLigg8NMAPBCdbfzU+86G7D9gl264uOW7jRZn5OSjf Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 May 2010 19:36:09 -0700 Received: from 10.72.181.200 ([10.72.181.200]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 21 May 2010 02:35:58 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 20 May 2010 19:35:56 -0700 From: Allen Tom To: David Recordon , Dirk Balfanz , OAuth WG Message-ID: Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr4jlbfKT01gNeYeECvYg7uhHGAzw== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3357228956_35233385" X-OriginalArrivalTime: 21 May 2010 02:36:09.0840 (UTC) FILETIME=[5F1F1F00:01CAF88E] Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Fri, 21 May 2010 03:46:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3357228956_35233385 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Dirk- We at Yahoo would be very much against using the client secret for signing requests to Protected Resources, since this would require that the client secret be distributed to the PR endpoints. For security reasons, one of the design goals for WRAP was to keep the client secret a secret between only the AS and the Client =AD deliberately separating the authentication of the client (on the AS) from the serving of the protected resource. >From your post, it=B9s not quite clear what the disadvantage is with using th= e Access Token secret for generating signatures. (forgive me if this was already discussed today - I was very zonked out after 3 days of IIW) Thanks Allen On 5/20/10 5:44 PM, "David Recordon" wrote: > We're able to use the client secret for signing requests instead of a tok= en > secret, but my understanding is that this exists because of deployers who= do > not wish for their protected resources to have access to client secrets. >=20 > --David >=20 >=20 > On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz wrote: >> Hi guys,=A0 >>=20 >> at today's interim meeting, we were discussing Brian Eaton's proposal fo= r >> OAuth signatures. He was proposing a mechanism that would (1) do away wi= th >> base string canonicalization, (2) allow for symmetric and public keys, a= nd >> (3) allow for extensibility.=A0 >>=20 >> He got homework from the group to prove the feasibility of his proposal = by >> showing a couple of implementations.=A0 >>=20 >> In this post, I would like to introduce another improvement of the OAuth= 2 >> signing mechanism, one which is orthogonal to Brian's proposal (i.e., it >> would work both with the signing mechanism in the current spec, as well = as >> with Brian's signature mechanism). The goal of my proposal is twofold: >>=20 >> - it simplifies the spec. It will become more readable and therefore eas= ier >> to implement >> - it separates out the mechanisms for delegated authorization and for >> integrity protection into two independent pieces, which can be put toget= her >> by Servers and/or Clients like LEGO blocks. >>=20 >> Summary: >>=20 >> - use the client secret instead of the token secret for signing PR acces= s >> requests. >>=20 >> Long version of the proposal: >>=20 >> - remove all references to access tokens that are not bearer tokens from= the >> spec. >> - stop calling the access tokens "bearer tokens". Call them just "access >> tokens".=A0 >> - remove all references to token secrets from the spec >> - remove all parts of the spec that are of the kind "if bearer_token the= n X, >> else Y", and replace them with X. >> - delete section 5.3 >> - add a section called "Request Authentication" that goes something like >> this: >>=20 >> "Servers may require that requests be authenticated by the Client, so th= at >> presentation of the access token alone is not sufficient to access a >> Protected Resource. =A0This has several use cases, including, but not limi= ted >> to, the following: >>=20 >> - Non-repudiation: high-security deployments may require that requests b= e >> authenticated (signed) in a non-repudiateable way[1] >> - Access to protected resources is not protected by SSL, so that access >> tokens may leak.=A0 >> - End-to-end-integrity: even if SSL _is_ used, network infrastructure ma= y >> strip SSL protection before the request reaches the protected resource. = The >> protected resource, however, may require end-to-end integrity. >>=20 >> If the Server requires that the Client authenticate PR access requests, = then >> the Client uses the following mechanism to sign their HTTP requests: [..= .]" >>=20 >> Then, we basically drop the old Section 5.3 here (except we use the clie= nt >> secret instead of the access token secret). Eventually, instead of Secti= on >> 5.3, we may have Brian's new signature scheme section here, which would = add >> the option of public-key crypto[1], etc. >>=20 >> What do you guys think? >>=20 >> Dirk. >>=20 >> [1] Technically speaking, the goal of non-repudiation can only be achiev= ed >> once we have public-key crypto. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --B_3357228956_35233385 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2= Hi Dirk-

We at Yahoo would be very much against using the client secret for signing = requests to Protected Resources, since this would require that the client se= cret be distributed to the PR endpoints. For security reasons, one of the de= sign goals for WRAP was to keep the client secret a secret between only the = AS and the Client – deliberately separating the authentication of the = client (on the AS) from the serving of the protected resource.

>From your post, it’s not quite clear what the disadvantage is with us= ing the Access Token secret for generating signatures.

(forgive me if this was already discussed today - I was very zonked = out after 3 days of IIW)

Thanks
Allen



On 5/20/10 5:44 PM, "David Recordon" <recordond@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>We're able to use the client secret for signing = requests instead of a token secret, but my understanding is that this exists= because of deployers who do not wish for their protected resources to have = access to client secrets.

--David


On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz <balfanz@google.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Hi guys,=A0

at today's interim meeting, we were discussing Brian Eaton's proposal for O= Auth signatures. He was proposing a mechanism that would (1) do away with ba= se string canonicalization, (2) allow for symmetric and public keys, and (3)= allow for extensibility.=A0

He got homework from the group to prove the feasibility of his proposal by = showing a couple of implementations.=A0

In this post, I would like to introduce another improvement of the OAuth 2 = signing mechanism, one which is orthogonal to Brian's proposal (i.e., it wou= ld work both with the signing mechanism in the current spec, as well as with= Brian's signature mechanism). The goal of my proposal is twofold:

- it simplifies the spec. It will become more readable and therefore easier= to implement
- it separates out the mechanisms for delegated authorization and for integ= rity protection into two independent pieces, which can be put together by Se= rvers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access r= equests.

Long version of the proposal:

- remove all references to access tokens that are not bearer tokens from th= e spec.
- stop calling the access tokens "bearer tokens". Call them just = "access tokens".=A0
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token t= hen X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes somethi= ng like this:

"Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a Pr= otected Resource. =A0This has several use cases, including, but not limited to= , the following:

- Non-repudiation: high-security deployments may require that requests be a= uthenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that access tok= ens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure may s= trip SSL protection before the request reaches the protected resource. The p= rotected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR access requests, the= n the Client uses the following mechanism to sign their HTTP requests: [...]= "

Then, we basically drop the old Section 5.3 here (except we use the client = secret instead of the access token secret). Eventually, instead of Section 5= .3, we may have Brian's new signature scheme section here, which would add t= he option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only be achieved = once we have public-key crypto.


_______________________________________________
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
--B_3357228956_35233385-- From James.H.Manger@team.telstra.com Thu May 20 21:26:04 2010 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 6CC573A8224 for ; Thu, 20 May 2010 21:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.546 X-Spam-Level: * X-Spam-Status: No, score=1.546 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+wy-Ttd4Qk7 for ; Thu, 20 May 2010 21:26:03 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 4031E3A7AD4 for ; Thu, 20 May 2010 20:14:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,275,1272808800"; d="scan'208";a="3409819" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 May 2010 13:14:08 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5988"; a="2214835" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbvi.tcif.telstra.com.au with ESMTP; 21 May 2010 13:14:08 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Fri, 21 May 2010 13:14:08 +1000 From: "Manger, James H" To: Dirk Balfanz , OAuth WG Date: Fri, 21 May 2010 13:14:07 +1000 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr4dbfcvBdETmo/SG28p1t8Ym7jngAGHe2g Message-ID: <255B9BB34FB7D647A506DC292726F6E112638878E4@WSMSG3153V.srv.dir.telstra.com> References: 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 factoring out request signing in OAuth 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: Fri, 21 May 2010 04:26:04 -0000 RGlyaywNCg0KQSBnb29kIGFwcHJvYWNoIHdvdWxkIGJlIHRvIGRlZmluZSBhIGdlbmVyaWMgbWVj aGFuaXNtIChzYXkgIk1BQyIpIGZvciBzaWduaW5nIGEgcmVxdWVzdCB3aXRoIGEgc2VjcmV0IGtl eS4gRGVmaW5lIGl0IHRvIHRha2UgdHdvIGlkZW50aXRpZXM6IGFuIGlkZW50aXR5IGFzc29jaWF0 ZWQgd2l0aCB0aGUga2V5IChhdXRoZW50aWNhdGlvbiBpZGVudGl0eSk7IGFuZCBhbm90aGVyICh+ aWRlbnRpdHkgdG8gYWN0IGFzIC8gYXV0aG9yaXphdGlvbiBpZGVudGl0eSAvIHRva2VuKS4gVGhp cyBtZWNoYW5pc20gbmVlZHMgemVybyBkZXBlbmRlbmNlIG9uIE9BdXRoLg0KW1NlZSBzZWN0aW9u IDIgIklkZW50aXR5IENvbmNlcHRzIiBpbiBSRkM0NDIyICJTaW1wbGUgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyaXR5IExheWVyIChTQVNMKSJdDQoNClRoZW4gZGVmaW5lIGhvdyBhbiBPQXV0aDIg ZmxvdyBjYW4gdGVsbCBhIGNsaWVudCB0byB1c2UgdGhlIE1BQyBzY2hlbWUsIHdpdGggdGhlIE9B dXRoMiBhY2Nlc3NfdG9rZW4gYXMgdGhlICJvdGhlciBpZGVudGl0eSIgKGFuZCB0aGUgY2xpZW50 X3NlY3JldCBhcyB0aGUgc2lnbmluZyBrZXkpLg0KDQpFeGFtcGxlczoNCg0KT0F1dGgyIGZsb3cg cmVzdWx0cyBpbiB0aGUgZm9sbG93aW5nIGFjY2VzcyB0b2tlbiByZXNwb25zZToNCiAgeyAic2No ZW1lIjoiTUFDIiwgImFjY2Vzc190b2tlbiI6ImVmd3RoZmV5dGYyZTMiIH0NClRoZSBjbGllbnQg dGhlbiBzZW5kcyByZXF1ZXN0cyB0byBwcm90ZWN0ZWQgcmVzb3VyY2Ugd2l0aDoNCiAgQXV0aG9y aXphdGlvbjogTUFDIGFjY2Vzc190b2tlbj1lZnd0aGZleXRmMmUzOyBrZXlpZD08Y2xpZW50X2lk Pjsgc2lnPTxzaWduYXR1cmUgdXNpbmcgY2xpZW50X3NlY3JldD4gLi4uDQoNCkEgZGlmZmVyZW50 IHNlcnZpY2Ugd2FudHMgdG8gaXNzdWUgdG9rZW5zIGFuZCBzZWNyZXRzLiBJdHMgT0F1dGgyIGFj Y2VzcyB0b2tlbiByZXNwb25zZSBpczoNCiAgeyAic2NoZW1lIjoiTUFDIiwgImFjY2Vzc190b2tl biI6ImVmd3RoZmV5dGYyZTMiLCAia2V5aWQiOiIzMjY1NDYyMjIzIiwgInNlY3JldCI6ImhqZ0dK RjY2R0hGIiB9DQpUaGUgY2xpZW50IHRoZW4gc2VuZHMgcmVxdWVzdHMgdG8gcHJvdGVjdGVkIHJl c291cmNlIHdpdGg6DQogIEF1dGhvcml6YXRpb246IE1BQyBhY2Nlc3NfdG9rZW49ZWZ3dGhmZXl0 ZjJlMzsga2V5aWQ9MzI2NTQ2MjIyMzsgc2lnPTxzaWduYXR1cmUgdXNpbmcgaGpnR0pGNjZHSEY+ IC4uLg0KDQpBIHRoaXJkIHNlcnZpY2Ugd2FudHMgdG8gdXNlIGJlYXJlciB0b2tlbnMuIEl0cyBh Y2Nlc3MgdG9rZW4gcmVzcG9uc2UgaXM6DQogIHsgInNjaGVtZSI6IlRva2VuIiwgImFjY2Vzc190 b2tlbiI6ImVmd3RoZmV5dGYyZTMiIH0NClRoZSBjbGllbnQgdGhlbiBzZW5kcyByZXF1ZXN0cyB0 byBwcm90ZWN0ZWQgcmVzb3VyY2Ugd2l0aDoNCiAgQXV0aG9yaXphdGlvbjogVG9rZW4gYWNjZXNz X3Rva2VuPWVmd3RoZmV5dGYyZTMNCg0KDQpUaGUgaWRlYSBpcyB0aGF0IHRoZSBhY2Nlc3MgdG9r ZW4gcmVzcG9uc2UgYWN0cyBhIGJpdCBsaWtlIGEgV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25zZSBo ZWFkZXIgKHRlbGxpbmcgdGhlIGNsaWVudCBob3cgdG8gbWFrZSBhdXRoZW50aWMgcmVxdWVzdHMp LCBhbmQgcHJvdmlkZXMgc29tZSBvZiB0aGUgY3JlZGVudGlhbHMgdG8gdXNlLg0KSWYgYSBzZXJ2 ZXIgaW5kaWNhdGVzIGFuIGF1dGggc2NoZW1lIHRoYXQgbmVlZHMgYSBzZWNyZXQgYnV0IGRvZXNu J3QgcHJvdmlkZSBpdCwgdGhlbiB0aGUgY2xpZW50IGtub3dzIHRvIHVzZSBpdHMgb3duIGNsaWVu dF9zZWNyZXQuDQoNCg0KDQotLQ0KSmFtZXMgTWFuZ2VyIA0KDQoNCg0KRnJvbTogb2F1dGgtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBEaXJrIEJhbGZhbnoNClNlbnQ6IEZyaWRheSwgMjEgTWF5IDIwMTAgOTozOSBBTQ0KVG86IE9B dXRoIFdHDQpTdWJqZWN0OiBbT0FVVEgtV0ddIHByb3Bvc2FsIGZvciBmYWN0b3Jpbmcgb3V0IHJl cXVlc3Qgc2lnbmluZyBpbiBPQXV0aCAyDQoNCi4uLg0KSW4gdGhpcyBwb3N0LCBJIHdvdWxkIGxp a2UgdG8gaW50cm9kdWNlIGFub3RoZXIgaW1wcm92ZW1lbnQgb2YgdGhlIE9BdXRoIDIgc2lnbmlu ZyBtZWNoYW5pc20sIG9uZSB3aGljaCBpcyBvcnRob2dvbmFsIHRvIEJyaWFuJ3MgcHJvcG9zYWwg KGkuZS4sIGl0IHdvdWxkIHdvcmsgYm90aCB3aXRoIHRoZSBzaWduaW5nIG1lY2hhbmlzbSBpbiB0 aGUgY3VycmVudCBzcGVjLCBhcyB3ZWxsIGFzIHdpdGggQnJpYW4ncyBzaWduYXR1cmUgbWVjaGFu aXNtKS4gVGhlIGdvYWwgb2YgbXkgcHJvcG9zYWwgaXMgdHdvZm9sZDoNCg0KLSBpdCBzaW1wbGlm aWVzIHRoZSBzcGVjLiBJdCB3aWxsIGJlY29tZSBtb3JlIHJlYWRhYmxlIGFuZCB0aGVyZWZvcmUg ZWFzaWVyIHRvIGltcGxlbWVudA0KLSBpdCBzZXBhcmF0ZXMgb3V0IHRoZSBtZWNoYW5pc21zIGZv ciBkZWxlZ2F0ZWQgYXV0aG9yaXphdGlvbiBhbmQgZm9yIGludGVncml0eSBwcm90ZWN0aW9uIGlu dG8gdHdvIGluZGVwZW5kZW50IHBpZWNlcywgd2hpY2ggY2FuIGJlIHB1dCB0b2dldGhlciBieSBT ZXJ2ZXJzIGFuZC9vciBDbGllbnRzIGxpa2UgTEVHTyBibG9ja3MuDQoNClN1bW1hcnk6DQoNCi0g dXNlIHRoZSBjbGllbnQgc2VjcmV0IGluc3RlYWQgb2YgdGhlIHRva2VuIHNlY3JldCBmb3Igc2ln bmluZyBQUiBhY2Nlc3MgcmVxdWVzdHMuDQouLi4NCg== From chasen@ironmoney.com Thu May 20 22:38:43 2010 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 80E0C3A7DEA for ; Thu, 20 May 2010 22:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.541 X-Spam-Level: X-Spam-Status: No, score=0.541 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 WH2bnWj3D5ZW for ; Thu, 20 May 2010 22:38:42 -0700 (PDT) Received: from mail-qy0-f200.google.com (mail-qy0-f200.google.com [209.85.221.200]) by core3.amsl.com (Postfix) with ESMTP id B6EC63A7E19 for ; Thu, 20 May 2010 21:05:30 -0700 (PDT) Received: by qyk38 with SMTP id 38so886664qyk.17 for ; Thu, 20 May 2010 21:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.232.6 with SMTP id js6mr284470qcb.14.1274414721103; Thu, 20 May 2010 21:05:21 -0700 (PDT) Received: by 10.229.226.8 with HTTP; Thu, 20 May 2010 21:05:21 -0700 (PDT) In-Reply-To: References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 20 May 2010 21:05:21 -0700 Message-ID: From: Chasen Le Hara To: OAuth WG Content-Type: multipart/alternative; boundary=0016363b90f6bf799c048712cc8d Subject: Re: [OAUTH-WG] in-app logout? 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, 21 May 2010 05:38:43 -0000 --0016363b90f6bf799c048712cc8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 16, 2010 at 11:27 AM, Dick Hardt wrote: > Torsten: enabling a client to revoke a refresh token looks like a useful > mechanism. I anticipate it will be viewed as a vitamin feature rather tha= n a > painkiller and will fall by the wayside unless the security conscience ra= lly > to have it included. > I=E2=80=99d like to put in another vote for this mechanism. I=E2=80=99m about to add a =E2=80=9Cin-app logout=E2=80=9D to an iPhone app= that uses OAuth; while I can delete the token from the device, a standard way for deleting the token from the web service would be helpful in preventing future uses of the toke= n (for example, if the device is restored from a backup and the token was stored in the backup files). -Chasen --0016363b90f6bf799c048712cc8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 16, 2010 at 11:27 AM, Dick Hardt <dick.hardt@gmail.com> wrote:=
Torsten: enabling a client to revoke a refresh token looks like a usef= ul mechanism. I anticipate it will be viewed as a vitamin feature rather th= an a painkiller and will fall by the wayside unless the security conscience= rally to have it included.

I=E2=80=99d like to put i= n another vote for this mechanism.

I=E2=80=99m abo= ut to add a =E2=80=9Cin-app logout=E2=80=9D to an iPhone app that uses OAut= h; while I can delete the token from the device, a standard way for deletin= g the token from the web service would be helpful in preventing future uses= of the token (for example, if the device is restored from a backup and the= token was stored in the backup files).
-Chasen
--0016363b90f6bf799c048712cc8d-- From eran@hueniverse.com Fri May 21 02:08:38 2010 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 A5CB83A7B09 for ; Fri, 21 May 2010 02:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.061 X-Spam-Level: X-Spam-Status: No, score=-1.061 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_50=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 wYg-6RccAd8a for ; Fri, 21 May 2010 02:08: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 004463A7BFA for ; Thu, 20 May 2010 23:33:59 -0700 (PDT) Received: (qmail 22929 invoked from network); 21 May 2010 06:33:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 May 2010 06:33:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 20 May 2010 23:33:52 -0700 From: Eran Hammer-Lahav To: Dirk Balfanz , OAuth WG Date: Thu, 20 May 2010 23:34:08 -0700 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr4dbZ30BuzjX82SFSQapO6K8wuGwANhvKg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CD9BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 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 Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Fri, 21 May 2010 09:08:38 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dirk Balfanz > Sent: Thursday, May 20, 2010 4:39 PM > To: OAuth WG > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 >=20 > Hi guys, >=20 > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away > with base string canonicalization, (2) allow for symmetric and public key= s, and > (3) allow for extensibility. It doesn't get rid of the base string canonicalization; it just moves the p= ieces around with different benefits and tradeoffs. It might be a better re= arrangement since it moves the complexity from the client to the server, bu= t your characterization is misleading. I'll wait for Brian to post his prop= osal to the list before an in-depth discussion. EHL From hubertlvg@gmail.com Fri May 21 04:11:38 2010 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 5A0F23A729B for ; Fri, 21 May 2010 04:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Hsa+3C2bjjg8 for ; Fri, 21 May 2010 04:11:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 410703A72EF for ; Fri, 21 May 2010 00:35:47 -0700 (PDT) Received: by wwb24 with SMTP id 24so462217wwb.31 for ; Fri, 21 May 2010 00:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZtHJDX+BX0y5r9R92v/0f4A+UyOCw5AbTPD+epOU/UY=; b=wWmicQk2dIQzRS7LxPKdv8b+WSommDWlxXKkt1Z4ePcQNeVSoHXWXgXLC0dPeQe/Dj Nolc3JRoy0r0PbkXrndDAcBhDag+MQ2P4gp3mw6mhGgIlUwQRl2PmaXQnyVqTB6kUf8Y WUB79F/tWQgC3o9WChKd+7j9Hxd+fHm3HToUs= 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=eroKLCs5/d8THlsWb9LtsccyK7RnbZKnH2+RnGtkLa2/PyDBA8FmE8sx4krl1z2MQv jAA4qG8SCyDgneMTALIbZ9PgNgEC7DpBfU7lp7i0fIMqu+IrQ8llezPUDgCTQkMHPM8e MK2v710Tl7hZtKod4u4N7+B16ZSJ9GyLNgyIA= MIME-Version: 1.0 Received: by 10.216.153.207 with SMTP id f57mr546247wek.115.1274427337651; Fri, 21 May 2010 00:35:37 -0700 (PDT) Received: by 10.216.182.212 with HTTP; Fri, 21 May 2010 00:35:37 -0700 (PDT) In-Reply-To: References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 21 May 2010 09:35:37 +0200 Message-ID: From: Hubert Le Van Gong To: Chasen Le Hara Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] in-app logout? 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, 21 May 2010 11:11:39 -0000 I agree token management is important. It actually can (and sometimes must) go farther than token deletion/revocation. For instance, adding the possibility for the resource owner (or others with appropriate rights) of "inspecting" released tokens etc. Kind of like what UMA is getting at. At the protocol level we already have a request message to obtain a token, it would seem logical to have one to delete/revoke it. In our OAuth implementation we adopted a RESTful approach where tokens were represented as URIs. In that case token management (which ) is "just" a matter of using standard HTTP operations. However, there are security issues that needs to be dealt with in terms of who can perform such operation. This is especially the case with large deployments or when the OAuth protocol is only one part of a more complex product. All this to say that I don't think HTTP delete is the general solution for this and would advocate for a Delete_token request. Hubert On Fri, May 21, 2010 at 6:05 AM, Chasen Le Hara wrot= e: > On Sun, May 16, 2010 at 11:27 AM, Dick Hardt wrote= : >> >> Torsten: enabling a client to revoke a refresh token looks like a useful >> mechanism. I anticipate it will be viewed as a vitamin feature rather th= an a >> painkiller and will fall by the wayside unless the security conscience r= ally >> to have it included. > > I=92d like to put in another vote for this mechanism. > I=92m about to add a =93in-app logout=94 to an iPhone app that uses OAuth= ; while I > can delete the token from the device, a standard way for deleting the tok= en > from the web service would be helpful in preventing future uses of the to= ken > (for example, if the device is restored from a backup and the token was > stored in the backup files). > -Chasen > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From lr@lukasrosenstock.net Fri May 21 09:54:32 2010 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 16E373A7029 for ; Fri, 21 May 2010 09:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] 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 oHlKstnEpD0u for ; Fri, 21 May 2010 09:54:30 -0700 (PDT) Received: from mail-qy0-f200.google.com (mail-qy0-f200.google.com [209.85.221.200]) by core3.amsl.com (Postfix) with ESMTP id 7A0CF3A839C for ; Fri, 21 May 2010 07:26:57 -0700 (PDT) Received: by qyk38 with SMTP id 38so1527655qyk.17 for ; Fri, 21 May 2010 07:26:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.145 with SMTP id cc17mr405273qcb.35.1274452007757; Fri, 21 May 2010 07:26:47 -0700 (PDT) Received: by 10.229.250.202 with HTTP; Fri, 21 May 2010 07:26:47 -0700 (PDT) In-Reply-To: References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 21 May 2010 16:26:47 +0200 Message-ID: From: Lukas Rosenstock To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0016364ecbf234a6f604871b7b74 Subject: Re: [OAUTH-WG] in-app logout? 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, 21 May 2010 16:54:32 -0000 --0016364ecbf234a6f604871b7b74 Content-Type: text/plain; charset=ISO-8859-1 Why not simply add this functionality to the token endpoint? The same place that was used to fetch the access token first or refresh it could be used to revoke the same token with another request. The only requirement would be to define something like type=revoke. I feel that is much easier than making the token a URL which supports DELETE. However, any mechanism will break implementations that rely on minimal or no communication between authorization server and protected resource, because all protected resources have to be informed. Regards, Lukas 2010/5/16 Dick Hardt > James: An important capability of the refresh token is that it *can* be a > self contained token in that is not an id, but a signed token that can be > examined and acted upon on presentation. > > Torsten: enabling a client to revoke a refresh token looks like a useful > mechanism. I anticipate it will be viewed as a vitamin feature rather than a > painkiller and will fall by the wayside unless the security conscience rally > to have it included. > > -- Dick > > > On Thu, May 13, 2010 at 7:10 AM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > >> Torsten, >> >> > What about refresh token revocation/deletion? >> >> HTTP already has a method to do this: DELETE >> It just needs each token to have a URI. >> >> Tokens (almost) already have URIs -- its just not immediately obvious >> because the URI has to be built from a common token endpoint and a >> refresh_token. >> >> I think it would improve the spec if refresh_token was renamed to, say, >> token_id; and its value defined as a URI (which can be a relative URI so the >> string may not need to change at all). >> >> To refresh a token you POST to the token's URI. >> To delete a token you send a DELETE request to the token's URI. >> >> It doesn't cause major changes, but there are some benefits. >> It is a more web-style design. >> It leaves only 1 type of token in the spec -- an access token -- which >> simplifies the text and aids understanding. >> There are no arguments about length, allowed chars etc because it is a URI >> -- a well-known type, often with native support. >> Its obvious how to delete the token as there is a standard HTTP method >> DELETE to apply to the token URI. >> >> If a particular service supported an additional way to delete items in its >> API (eg POST with a method=delete query parameter) that could apply to the >> OAuth part as well. >> >> -- >> James Manger >> _______________________________________________ >> 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 > > -- http://lukasrosenstock.net/ --0016364ecbf234a6f604871b7b74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why not simply add this functionality to the token endpoint?
The same p= lace that was used to fetch the access token first or refresh it could be u= sed to revoke the same token with another request. The only requirement wou= ld be to define something like type=3Drevoke.
I feel that is much easier than making the token a URL which supports = DELETE.

However, any mechanism will break implemen= tations that rely on minimal or no communication between authorization serv= er and protected resource, because all protected resources have to be infor= med.

Regards,
=A0Lukas

2010/5/16 Dick Hardt <dick.hardt@gmail.com>
James: An important capability of the refresh token is that it *can* be a s= elf contained token in that is not an id, but a signed token that can be ex= amined and acted upon on presentation.

Torsten: enabling= a client to revoke a refresh token looks like a useful mechanism. I antici= pate it will be viewed as a vitamin feature rather than a painkiller and wi= ll fall by the wayside unless the security conscience rally to have it incl= uded.

-- Dick


On T= hu, May 13, 2010 at 7:10 AM, Manger, James H <James.H.Mange= r@team.telstra.com> wrote:
Torsten,

> What about refresh token revocation/deletion?

HTTP already has a method to do this: DELETE
It just needs each token to have a URI.

Tokens (almost) already have URIs -- its just not immediately obvious becau= se the URI has to be built from a common token endpoint and a refresh_token= .

I think it would improve the spec if refresh_token was renamed to, say, tok= en_id; and its value defined as a URI (which can be a relative URI so the s= tring may not need to change at all).

To refresh a token you POST to the token's URI.
To delete a token you send a DELETE request to the token's URI.

It doesn't cause major changes, but there are some benefits.
It is a more web-style design.
It leaves only 1 type of token in the spec -- an access token -- which simp= lifies the text and aids understanding.
There are no arguments about length, allowed chars etc because it is a URI = -- a well-known type, often with native support.
Its obvious how to delete the token as there is a standard HTTP method DELE= TE to apply to the token URI.

If a particular service supported an additional way to delete items in its = API (eg POST with a method=3Ddelete query parameter) that could apply to th= e OAuth part as well.

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


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




--
http://lukasrosenstock.net/
--0016364ecbf234a6f604871b7b74-- From mscurtescu@google.com Fri May 21 11:29:10 2010 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 825373A68FD for ; Fri, 21 May 2010 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.77 X-Spam-Level: X-Spam-Status: No, score=-104.77 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_20=-0.74, 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 s5+5Y0Wpckkr for ; Fri, 21 May 2010 11:29:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 776613A702B for ; Fri, 21 May 2010 09:23:31 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o4LGNNjO019826 for ; Fri, 21 May 2010 09:23:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274459003; bh=I8nbyNWhkNyIRQH+fFCoZ6WzEjE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=u9zlewlg+Q5eX+eJjNmnr1tZ3xIw1MZOhetXgFmJXHNmkXRVb4AwB52EC4Psxou+p snjlsXdjXNLPSQ0+nDfjQ== 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=AUj7M4gOkmobzcRnJN2OzMUkDRkWX0e0tfI/SlP6u/eagWpFd+uoUf13fPSObZ5xE HuVqxPaUPS/V4gIDOXw1g== Received: from pvg12 (pvg12.prod.google.com [10.241.210.140]) by wpaz29.hot.corp.google.com with ESMTP id o4LGNMdf020144 for ; Fri, 21 May 2010 09:23:22 -0700 Received: by pvg12 with SMTP id 12so544336pvg.27 for ; Fri, 21 May 2010 09:23:22 -0700 (PDT) Received: by 10.140.56.14 with SMTP id e14mr1351152rva.158.1274459002206; Fri, 21 May 2010 09:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Fri, 21 May 2010 09:23:02 -0700 (PDT) In-Reply-To: <3597B5B0-33FF-4529-B81D-399BCCC57D67@gmail.com> References: <3597B5B0-33FF-4529-B81D-399BCCC57D67@gmail.com> From: Marius Scurtescu Date: Fri, 21 May 2010 09:23:02 -0700 Message-ID: To: Leah Culver Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Figure titles 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, 21 May 2010 18:29:10 -0000 +1 On Thu, May 20, 2010 at 11:42 AM, Leah Culver wrote: > For extra readability can we add titles to the figures in the > Internet-Drafts? I think it would make it easier to skim sections, such as > the various flows. > > Here are my suggestions for titles for draft-ietf-oauth-v2-05: > > Figure 1 - Generic flow between client and server > Figure 2 - Obtaining a new access token to access protected resources > Figure 3 - User-Agent flow > Figure 4 - Web server flow > Figure 5 - Device flow > Figure 6 - Username and password flow > Figure 7 - Client credentials flow > Figure 8 - Assertion flow > Figure 9 - Obtaining a new access token using a refresh token > > Figures 2 and 9 are fairly similar but 9 focuses on obtaining the access > token. > > Thoughts? > Leah_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From balfanz@google.com Fri May 21 11:39:19 2010 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 3B5063A635F for ; Fri, 21 May 2010 11:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 H2o8LhdpEmn2 for ; Fri, 21 May 2010 11:39:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8162F3A6DAB for ; Fri, 21 May 2010 09:10:34 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o4LFdjcm010132 for ; Fri, 21 May 2010 08:39:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274456385; bh=4xIh6KB7sYZhLldpvtAfKlX7IoE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Vx5q4LydkjbPvONpeV3MUMFdRkL5Vir9FcqCwdQvzyG5Ub3mq9cznPhdClwa5fGU5 F2v0dIfL/9Sf4/I5PVbfA== 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=jmvyfLcRGBfvKdyJ2PoTSluFpt7pcmkt7faOa4BT8u+ePenOhijaco572ZwyQJxXJ g+VyUFMmc0cI2FFLY2KGw== Received: from iwn42 (iwn42.prod.google.com [10.241.68.106]) by kpbe12.cbf.corp.google.com with ESMTP id o4LFdO2C016705 for ; Fri, 21 May 2010 08:39:44 -0700 Received: by iwn42 with SMTP id 42so1302706iwn.17 for ; Fri, 21 May 2010 08:39:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.146.140 with SMTP id h12mr1642987ibv.58.1274456384047; Fri, 21 May 2010 08:39:44 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Fri, 21 May 2010 08:39:43 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CD9BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CD9BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 21 May 2010 08:39:43 -0700 Message-ID: From: Dirk Balfanz To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64ec4d20d899104871c8061 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Fri, 21 May 2010 18:39:19 -0000 --0016e64ec4d20d899104871c8061 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 20, 2010 at 11:34 PM, Eran Hammer-Lahav wrote: > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Dirk Balfanz > > Sent: Thursday, May 20, 2010 4:39 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > > > Hi guys, > > > > at today's interim meeting, we were discussing Brian Eaton's proposal for > > OAuth signatures. He was proposing a mechanism that would (1) do away > > with base string canonicalization, (2) allow for symmetric and public > keys, and > > (3) allow for extensibility. > > It doesn't get rid of the base string canonicalization; it just moves the > pieces around with different benefits and tradeoffs. It might be a better > rearrangement since it moves the complexity from the client to the server, > but your characterization is misleading. I'll wait for Brian to post his > proposal to the list before an in-depth discussion. > Sorry - I didn't mean to jump to conclusions about Brian's proposal. Do you agree, though, that my refactoring proposal is orthogonal to whether we'll agree to Brian's new signature scheme? Dirk. > > EHL > --0016e64ec4d20d899104871c8061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 20, 2010 at 11:34 PM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:


> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Dirk Balfanz
> Sent: Thursday, May 20, 2010 4:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away<= br> > with base string canonicalization, (2) allow for symmetric and public = keys, and
> (3) allow for extensibility.

It doesn't get rid of the base string canonicalization; it just m= oves the pieces around with different benefits and tradeoffs. It might be a= better rearrangement since it moves the complexity from the client to the = server, but your characterization is misleading. I'll wait for Brian to= post his proposal to the list before an in-depth discussion.

Sorry - I didn't mean to jump to concl= usions about Brian's proposal. Do you agree, though, that my refactorin= g proposal is orthogonal to whether we'll agree to Brian's new sign= ature scheme?

Dirk.
=A0

EHL

--0016e64ec4d20d899104871c8061-- From balfanz@google.com Fri May 21 11:43:34 2010 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 708A33A6889 for ; Fri, 21 May 2010 11:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.376 X-Spam-Level: X-Spam-Status: No, score=-99.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 E-P1144W6TvW for ; Fri, 21 May 2010 11:43:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A39473A6D86 for ; Fri, 21 May 2010 09:09:40 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o4LFc5e1006426 for ; Fri, 21 May 2010 08:38:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274456287; bh=GUj8V8/OpZcycBxbEUiNg+L3CdQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=MWsvTAUn6/lwAj2sHlRL0FtD+ect6LpdanPhrOQgOSqczJnVrkYTQSbZLkmKiTSVX qYOEMtsE0Y3s3FwBD0hvw== 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=ot0EHyiY2NngXEXZuDYg/sHGxP9nUVbVM37B2l62DWeGSjq2NUTWNHnHhloJ7vxr8 RpXRCB92WDzFLNWZrSEPQ== Received: from iwn4 (iwn4.prod.google.com [10.241.68.68]) by kpbe19.cbf.corp.google.com with ESMTP id o4LFc49O029991 for ; Fri, 21 May 2010 08:38:04 -0700 Received: by iwn4 with SMTP id 4so1263595iwn.23 for ; Fri, 21 May 2010 08:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.185.86 with SMTP id cn22mr1092495ibb.69.1274456284167; Fri, 21 May 2010 08:38:04 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Fri, 21 May 2010 08:38:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 08:38:04 -0700 Message-ID: From: Dirk Balfanz To: Allen Tom Content-Type: multipart/alternative; boundary=005045013e22197e0c04871c7aa3 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Fri, 21 May 2010 18:43:34 -0000 --005045013e22197e0c04871c7aa3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2010 at 7:35 PM, Allen Tom wrote: > Hi Dirk- > > We at Yahoo would be very much against using the client secret for signin= g > requests to Protected Resources, since this would require that the client > secret be distributed to the PR endpoints. For security reasons, one of t= he > design goals for WRAP was to keep the client secret a secret between only > the AS and the Client =96 deliberately separating the authentication of t= he > client (on the AS) from the serving of the protected resource. > I understand - and I'm not taking that away: you still have access tokens, which are the short-lived secrets that you expose to your PR endpoints. Yahoo! would presumably rely on SSL for request integrity instead, or use "Request Authentication" only with public-key signatures. > > From your post, it=92s not quite clear what the disadvantage is with usin= g > the Access Token secret for generating signatures. > Well, there is the problem that the spec itself is a bit awkward right now with the access tokens-vs.-bearer tokens language all over the place. There are things in there that I think are unnecessary, like secret type, access token secret, etc. (the access token itself is supposed to be that secret). Then, there is the issue of "re-factoring" the spec. The access token serve= s the function of delegated authorization. I give you an access token, now yo= u have certain privileges that I delegated to you. We decided to use this "capability" model for OAuth instead of ACLs, and I think it proves powerful. So what's signing for, then? It's for authenticating who is currently using the access token, which has some use cases that I'm trying to call out in my proposal. But that's a different function, so it should b= e served by a separate mechanism (frankly, I'd be happy if that was in a completely different spec, but I think that train has left the station). Finally, why client secret (or client private key) instead of token secret? Because I believe that actually better reflects what the signing is for - authenticating who is currently using the token. Two of the three use cases I outlined above can't be met with access token secrets: Access token secrets are known to the Server infrastructure, and therefore you don't get non-repudiation and end-to-end integrity, you only get protection from leaked access tokens. Does this make sense? Dirk. > > (forgive me if this was already discussed today - I was *very* zonked out > after 3 days of IIW) > > Thanks > Allen > > > > > On 5/20/10 5:44 PM, "David Recordon" wrote: > > We're able to use the client secret for signing requests instead of a tok= en > secret, but my understanding is that this exists because of deployers who= do > not wish for their protected resources to have access to client secrets. > > --David > > > On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz wrote: > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away wit= h > base string canonicalization, (2) allow for symmetric and public keys, an= d > (3) allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal b= y > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth = 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it > would work both with the signing mechanism in the current spec, as well a= s > with Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easi= er > to implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put togeth= er > by Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from > the spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then > X, else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like > this: > > "Servers may require that requests be authenticated by the Client, so tha= t > presentation of the access token alone is not sufficient to access a > Protected Resource. This has several use cases, including, but not limit= ed > to, the following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access > tokens may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. T= he > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, > then the Client uses the following mechanism to sign their HTTP requests: > [...]" > > Then, we basically drop the old Section 5.3 here (except we use the clien= t > secret instead of the access token secret). Eventually, instead of Sectio= n > 5.3, we may have Brian's new signature scheme section here, which would a= dd > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieve= d > once we have public-key crypto. > > > _______________________________________________ > 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 > > --005045013e22197e0c04871c7aa3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, May 20, 2010 at 7:35 PM, Allen T= om <atom@yahoo-i= nc.com> wrote:
Hi Dirk-

We at Yahoo would be very much against using the client secret for signing = requests to Protected Resources, since this would require that the client s= ecret be distributed to the PR endpoints. For security reasons, one of the = design goals for WRAP was to keep the client secret a secret between only t= he AS and the Client =96 deliberately separating the authentication of the = client (on the AS) from the serving of the protected resource.

I understand - and I&#= 39;m not taking that away: you still have access tokens, which are the shor= t-lived secrets that you expose to your PR endpoints. Yahoo! would presumab= ly rely on SSL for request integrity instead, or use "Request Authenti= cation" only with public-key signatures.=A0

>From your post, it=92s not quite clear what the disadvantage is with using = the Access Token secret for generating signatures.
<= /blockquote>

Well, there is the problem that the spec it= self is a bit awkward right now with the access tokens-vs.-bearer tokens la= nguage all over the place. There are things in there that I think are unnec= essary, like secret type, access token secret, etc. (the access token itsel= f is supposed to be that secret).=A0

Then, there is the issue of "re-factoring" th= e spec. The access token serves the function of delegated authorization. I = give you an access token, now you have certain privileges that I delegated = to you. We decided to use this "capability" model for OAuth inste= ad of ACLs, and I think it proves powerful. So what's signing for, then= ? It's for authenticating who is currently using the access token, whic= h has some use cases that I'm trying to call out in my proposal. But th= at's a different function, so it should be served by a separate mechani= sm (frankly, I'd be happy if that was in a completely different spec, b= ut I think that train has left the station).

Finally, why client secret (or client private key) inst= ead of token secret? Because I believe that actually better reflects what t= he signing is for - authenticating who is currently using the token. Two of= the three use cases I outlined above can't be met with access token se= crets: Access token secrets are known to the Server infrastructure, and the= refore you don't get non-repudiation and end-to-end integrity, you only= get protection from leaked access tokens.

Does this make sense?

Dirk.
=A0

(forgive me if this was already discussed today - I was very zonked = out after 3 days of IIW)

Thanks
Allen




On 5/20/10 5:44 PM, "David Recordon" <recordond@gmail.com> wrote:

We're able to use the client secret for signing requests instead of = a token secret, but my understanding is that this exists because of deploye= rs who do not wish for their protected resources to have access to client s= ecrets.

--David


On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz <balfanz@google.com> wrote:
Hi guys,=A0

at today's interim meeting, we were discussing Brian Eaton's propos= al for OAuth signatures. He was proposing a mechanism that would (1) do awa= y with base string canonicalization, (2) allow for symmetric and public key= s, and (3) allow for extensibility.=A0

He got homework from the group to prove the feasibility of his proposal by = showing a couple of implementations.=A0

In this post, I would like to introduce another improvement of the OAuth 2 = signing mechanism, one which is orthogonal to Brian's proposal (i.e., i= t would work both with the signing mechanism in the current spec, as well a= s with Brian's signature mechanism). The goal of my proposal is twofold= :

- it simplifies the spec. It will become more readable and therefore easier= to implement
- it separates out the mechanisms for delegated authorization and for integ= rity protection into two independent pieces, which can be put together by S= ervers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access r= equests.

Long version of the proposal:

- remove all references to access tokens that are not bearer tokens from th= e spec.
- stop calling the access tokens "bearer tokens". Call them just = "access tokens".=A0
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token t= hen X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes somethi= ng like this:

"Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a P= rotected Resource. =A0This has several use cases, including, but not limite= d to, the following:

- Non-repudiation: high-security deployments may require that requests be a= uthenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that access tok= ens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure may s= trip SSL protection before the request reaches the protected resource. The = protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR access requests, the= n the Client uses the following mechanism to sign their HTTP requests: [...= ]"

Then, we basically drop the old Section 5.3 here (except we use the client = secret instead of the access token secret). Eventually, instead of Section = 5.3, we may have Brian's new signature scheme section here, which would= add the option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only be achieved = once we have public-key crypto.


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



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

--005045013e22197e0c04871c7aa3-- From bellin@twitter.com Fri May 21 11:50:25 2010 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 DD8D03A6834 for ; Fri, 21 May 2010 11:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 TcynYrKnrGi0 for ; Fri, 21 May 2010 11:50:24 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C2C3B28C740 for ; Fri, 21 May 2010 10:40:04 -0700 (PDT) Received: by pwi1 with SMTP id 1so614470pwi.31 for ; Fri, 21 May 2010 10:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.252.10 with SMTP id z10mr1445205rvh.45.1274463595628; Fri, 21 May 2010 10:39:55 -0700 (PDT) Received: by 10.140.132.4 with HTTP; Fri, 21 May 2010 10:39:55 -0700 (PDT) Date: Fri, 21 May 2010 10:39:55 -0700 Message-ID: From: Brian Ellin To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cd10730e58b2204871e2d30 Subject: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow 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, 21 May 2010 18:50:26 -0000 --000e0cd10730e58b2204871e2d30 Content-Type: text/plain; charset=ISO-8859-1 We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter. @anywhere is a pure javascript layer that developers can drop in to add Twitter features to their website. With the User-Agent flow, we issue short lived access tokens that refresh as they expire. It works great for in-page stuff, but many developers are also building server-side integrations and would love to have different longer lived access tokens on their server. This is a common pattern that other connect-like services built on top of OAuth 2.0 will also find necessary. So, why not just use the access token issued by the User-Agent flow on the client server? Overloading the use of that token is not desirable for a couple of reasons: 1) The client server may not be using ssl, and as such the browser cannot securely transfer the access token to the server. 2) The access token lifetime policy for the User-Agent flow may not be desirable on the server. Specifically, the server may need a token that lasts for, say, two weeks instead of 15 minutes. Additionally, the token on the server may have access to different resources that are not desirable to transmit to or through the browser. In short, it is desirable to get two different access tokens from a single user authorization triggered by the User-Agent flow. Proposal: Make it possible to get a Web Server flow verification code from the User-Agent client authorization request [1]. Specifically, add a new optional parameter named "web_server_code" which when set to "true" returns a Web Server flow verification "code" field in the User-Agent authorization response. The verification code can then be sent by the javascript layer to the client server, where it is then used to request an access token [2]. Love to hear your feedback. 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2 -- Brian Ellin Product Manager, Twitter Platform http://twitter.com/brianellin --000e0cd10730e58b2204871e2d30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter.= =A0@anywhere is a pure javascript layer that developers can drop in to add= Twitter features to their website. =A0With the User-Agent flow, we issue s= hort lived access tokens that refresh as they expire. =A0It works great for= in-page stuff, but many developers are also building server-side integrati= ons and would love to have different longer lived access tokens on their se= rver. =A0This is a common pattern that other connect-like services built on= top of OAuth 2.0 will also find necessary.

So, why not just use the access token issued by the Use= r-Agent flow on the client server? =A0Overloading the use of that token is = not desirable for a couple of reasons:

1) The clie= nt server may not be using ssl, and as such the browser cannot securely tra= nsfer the access token to the server.

2) The access token lifetime policy for the User-Agent = flow may not be=A0desirable=A0on the server. =A0Specifically, the server ma= y need a token that lasts for, say, two weeks instead of 15 minutes. =A0Add= itionally, the token on the server may have access to different resources t= hat are not=A0desirable=A0to transmit to or through the browser.

In short, it is=A0desirable=A0to get two different acce= ss tokens from a single user authorization triggered by the User-Agent flow= .

Proposal:

Make it possi= ble to get a Web Server flow verification code from the User-Agent client a= uthorization request [1]. Specifically, add a new optional parameter named = "web_server_code" which when set to "true" returns a We= b Server flow verification "code" field in the User-Agent authori= zation response. =A0The verification code can then be sent by the javascrip= t layer to the client server, where it is then used to request an access to= ken [2].

Love to hear your feedback.

1:= =A0http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1
--=A0 --000e0cd10730e58b2204871e2d30-- From atom@yahoo-inc.com Fri May 21 12:36:43 2010 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 31F403A6899 for ; Fri, 21 May 2010 12:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.073 X-Spam-Level: X-Spam-Status: No, score=-14.073 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] 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 rXUxuD1ibXDf for ; Fri, 21 May 2010 12:36:40 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 694243A6EAD for ; Fri, 21 May 2010 09:18:11 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o4LFlRsE029543; Fri, 21 May 2010 08:47:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: return-path:x-originalarrivaltime; b=JmbQDLlW1i9WvW0Vdl/DzI8/yjl0QN/Khe4n4pNqAgJjo7KgXBwCttpHI13azyjY Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 May 2010 08:47:27 -0700 Received: from 10.72.245.19 ([10.72.245.19]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 21 May 2010 15:47:20 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 21 May 2010 08:47:20 -0700 From: Allen Tom To: Chasen Le Hara , OAuth WG Message-ID: Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: Acr4/OWKYROV68v5IU+kME9p3XlFPg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3357276441_35861805" X-OriginalArrivalTime: 21 May 2010 15:47:27.0920 (UTC) FILETIME=[EA433300:01CAF8FC] Subject: Re: [OAUTH-WG] in-app logout? 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, 21 May 2010 19:36:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3357276441_35861805 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1 There are many examples in production of token authentication schemes that have a =B3revoke token=B2 API for clients to voluntarily revoke their own credentials. =20 Examples: Google=B9s AuthSubRevokeToken: http://code.google.com/apis/accounts/docs/AuthSub.html#AuthSubRevokeToken OAuth Session Extension (for OAuth 1.0a): http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html#anc= h or10 Allen On 5/20/10 9:05 PM, "Chasen Le Hara" wrote: > On Sun, May 16, 2010 at 11:27 AM, Dick Hardt wrote= : >> Torsten: enabling a client to revoke a refresh token looks like a useful >> mechanism. I anticipate it will be viewed as a vitamin feature rather th= an a >> painkiller and will fall by the wayside unless the security conscience r= ally >> to have it included. >=20 > I=B9d like to put in another vote for this mechanism. >=20 > I=B9m about to add a =B3in-app logout=B2 to an iPhone app that uses OAuth; whil= e I > can delete the token from the device, a standard way for deleting the tok= en > from the web service would be helpful in preventing future uses of the to= ken > (for example, if the device is restored from a backup and the token was s= tored > in the backup files). > -Chasen >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --B_3357276441_35861805 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] in-app logout? +1

There are many examples in production of token authentication schemes that = have a “revoke token” API for clients to voluntarily revoke thei= r own credentials.  

Examples:

Google’s AuthSubRevokeToken:
http://code.google.com/apis/accounts/docs/AuthSub.html#AuthSubRevok= eToken

OAuth Session Extension (for OAuth 1.0a):
http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/= 1/spec.html#anchor10

Allen

On 5/20/10 9:05 PM, "Chasen Le Hara" <chasen@ironmoney.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>On Sun, May 16, 2010 at 11:27 AM, Dick Hardt <= ;dick.hardt@gmail.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Torsten: enabling a client to revoke a refresh t= oken looks like a useful mechanism. I anticipate it will be viewed as a vita= min feature rather than a painkiller and will fall by the wayside unless the= security conscience rally to have it included.
=
I’d like to put in another vote for this mechanism.

I’m about to add a “in-app logout” to an iPhone app that = uses OAuth; while I can delete the token from the device, a standard way for= deleting the token from the web service would be helpful in preventing futu= re uses of the token (for example, if the device is restored from a backup a= nd the token was stored in the backup files).
-Chasen

___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
--B_3357276441_35861805-- From beau.lebens@gmail.com Fri May 21 12:56:00 2010 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 1234C3A684C for ; Fri, 21 May 2010 12:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.523 X-Spam-Level: * X-Spam-Status: No, score=1.523 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] 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 HX9+RXKaZA6X for ; Fri, 21 May 2010 12:55:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3BF643A6A01 for ; Fri, 21 May 2010 10:05:18 -0700 (PDT) Received: by vws12 with SMTP id 12so1000801vws.31 for ; Fri, 21 May 2010 10:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=71+bwhCLzavRoGemmlsZkFEt9uFGQp0xU7r8JPUKfHU=; b=Btc2BgEFh8fg4W9osyrNDmjJVs4K1vmq1AwGADhuFfpP5Y5NX8nS9e5tQCEG7r8cCi qLreRrfJlzf5/UhcQJa0vlZ5HkuBJHyjbqswnk/ptWgeBCssrcYbB+lPhLoTsDljIHuN F++Sx0ClqaGBcwje6lDd1kryBGUunTi7XVgto= 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:cc:content-type :content-transfer-encoding; b=Brpvf8h8SoIsdu0z3/wBIa0ctMsHwEMg6N++lAc62GUOT7FH6Ebu+bf3aMjkT/YWGV LvipB78oA1ZuySJelfmQshV1jdUAXAKJfRku5P96V2Dkyo4gIHmDllHs2/wPpiDk0Q6F qEh1Tp3/nCos3sitezIMS5wTo12GaJZ/+njdw= MIME-Version: 1.0 Received: by 10.229.187.6 with SMTP id cu6mr477632qcb.64.1274461508264; Fri, 21 May 2010 10:05:08 -0700 (PDT) Sender: beau.lebens@gmail.com Received: by 10.229.230.78 with HTTP; Fri, 21 May 2010 10:05:08 -0700 (PDT) In-Reply-To: References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 21 May 2010 10:05:08 -0700 X-Google-Sender-Auth: VQTziytz4NoHwoslNx_XFTHty2E Message-ID: From: Beau Lebens To: Lukas Rosenstock Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] in-app logout? 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, 21 May 2010 19:56:00 -0000 Could this just be implemented through support for a scope change where scope=3Dnone or revoke or something? On Friday, May 21, 2010, Lukas Rosenstock wrote: > Why not simply add this functionality to the token endpoint?The same plac= e that was used to fetch the access token first or refresh it could be used= to revoke the same token with another request. The only requirement would = be to define something like type=3Drevoke. > I feel that is much easier than making the token a URL which supports DEL= ETE. > However, any mechanism will break implementations that rely on minimal or= no communication between authorization server and protected resource, beca= use all protected resources have to be informed. > > Regards,=C2=A0Lukas > > 2010/5/16 Dick Hardt > > James: An important capability of the refresh token is that it *can* be a= self contained token in that is not an id, but a signed token that can be = examined and acted upon on presentation. > Torsten: enabling a client to revoke a refresh token looks like a useful = mechanism. I anticipate it will be viewed as a vitamin feature rather than = a painkiller and will fall by the wayside unless the security conscience ra= lly to have it included. > > > -- Dick > > > On Thu, May 13, 2010 at 7:10 AM, Manger, James H wrote: > Torsten, > >> What about refresh token revocation/deletion? > > HTTP already has a method to do this: DELETE > It just needs each token to have a URI. > > Tokens (almost) already have URIs -- its just not immediately obvious bec= ause the URI has to be built from a common token endpoint and a refresh_tok= en. > > I think it would improve the spec if refresh_token was renamed to, say, t= oken_id; and its value defined as a URI (which can be a relative URI so the= string may not need to change at all). > > To refresh a token you POST to the token's URI. > To delete a token you send a DELETE request to the token's URI. > > It doesn't cause major changes, but there are some benefits. > It is a more web-style design. > It leaves only 1 type of token in the spec -- an access token -- which si= mplifies the text and aids understanding. > There are no arguments about length, allowed chars etc because it is a UR= I -- a well-known type, often with native support. > Its obvious how to delete the token as there is a standard HTTP method DE= LETE to apply to the token URI. > > If a particular service supported an additional way to delete items in it= s API (eg POST with a method=3Ddelete query parameter) that could apply to = the OAuth part as well. > > -- > James Manger > _______________________________________________ > 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 > > > > -- > http://lukasrosenstock.net/ > > From bellin@twitter.com Fri May 21 13:53:28 2010 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 3C1613A6861 for ; Fri, 21 May 2010 13:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 L3-HBwq6mBfE for ; Fri, 21 May 2010 13:53:27 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 255093A6852 for ; Fri, 21 May 2010 13:53:22 -0700 (PDT) Received: by mail-px0-f172.google.com with SMTP id 19so687490pxi.31 for ; Fri, 21 May 2010 13:53:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.214.24 with SMTP id r24mr1551228rvq.273.1274474781387; Fri, 21 May 2010 13:46:21 -0700 (PDT) Received: by 10.140.132.4 with HTTP; Fri, 21 May 2010 13:46:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 13:46:21 -0700 Message-ID: From: Brian Ellin To: Marius Scurtescu Content-Type: multipart/alternative; boundary=000e0cd1a8cc9eb788048720c8c7 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow 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, 21 May 2010 20:53:28 -0000 --000e0cd1a8cc9eb788048720c8c7 Content-Type: text/plain; charset=ISO-8859-1 Marius, I don't understand. Will you elaborate on how specifically that would work? Brian On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu wrote: > Why not use the web server flow in this case? > > I think it should work with un-registered clients as well (no client > secret). > > Marius > > > > On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrote: > > We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter. > > @anywhere is a pure javascript layer that developers can drop in to add > > Twitter features to their website. With the User-Agent flow, we issue > short > > lived access tokens that refresh as they expire. It works great for > in-page > > stuff, but many developers are also building server-side integrations and > > would love to have different longer lived access tokens on their server. > > This is a common pattern that other connect-like services built on top > of > > OAuth 2.0 will also find necessary. > > So, why not just use the access token issued by the User-Agent flow on > the > > client server? Overloading the use of that token is not desirable for a > > couple of reasons: > > 1) The client server may not be using ssl, and as such the browser cannot > > securely transfer the access token to the server. > > 2) The access token lifetime policy for the User-Agent flow may not > > be desirable on the server. Specifically, the server may need a token > that > > lasts for, say, two weeks instead of 15 minutes. Additionally, the token > on > > the server may have access to different resources that are > not desirable to > > transmit to or through the browser. > > In short, it is desirable to get two different access tokens from a > single > > user authorization triggered by the User-Agent flow. > > Proposal: > > Make it possible to get a Web Server flow verification code from the > > User-Agent client authorization request [1]. Specifically, add a new > > optional parameter named "web_server_code" which when set to "true" > returns > > a Web Server flow verification "code" field in the User-Agent > authorization > > response. The verification code can then be sent by the javascript layer > to > > the client server, where it is then used to request an access token [2]. > > Love to hear your feedback. > > 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1 > > 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2 > > -- > > Brian Ellin > > Product Manager, Twitter Platform > > http://twitter.com/brianellin > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- Brian Ellin Twitter Platform Team http://twitter.com/brianellin --000e0cd1a8cc9eb788048720c8c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marius,

I don't understand. =A0Will you elaborate on= how specifically that would work?

Brian


On Fri, May 21, 2010 at 12:3= 5 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
Why not use the web server flow in this cas= e?

I think it should work with un-registered clients as well (no client secret= ).

Marius



On Fri, May 21, 2010 at 10:39 AM, Brian Ellin <bellin@twitter.com> wrote:
> We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter.=
> =A0@anywhere is a pure javascript layer that developers can drop in to= add
> Twitter features to their website. =A0With the User-Agent flow, we iss= ue short
> lived access tokens that refresh as they expire. =A0It works great for= in-page
> stuff, but many developers are also building server-side integrations = and
> would love to have different longer lived access tokens on their serve= r.
> =A0This is a common pattern that other connect-like services built on = top of
> OAuth 2.0 will also find necessary.
> So, why not just use the access token issued by the User-Agent flow on= the
> client server? =A0Overloading the use of that token is not desirable f= or a
> couple of reasons:
> 1) The client server may not be using ssl, and as such the browser can= not
> securely transfer the access token to the server.
> 2) The access token lifetime policy for the User-Agent flow may not > be=A0desirable=A0on the server. =A0Specifically, the server may need a= token that
> lasts for, say, two weeks instead of 15 minutes. =A0Additionally, the = token on
> the server may have access to different resources that are not=A0desir= able=A0to
> transmit to or through the browser.
> In short, it is=A0desirable=A0to get two different access tokens from = a single
> user authorization triggered by the User-Agent flow.
> Proposal:
> Make it possible to get a Web Server flow verification code from the > User-Agent client authorization request [1]. Specifically, add a new > optional parameter named "web_server_code" which when set to= "true" returns
> a Web Server flow verification "code" field in the User-Agen= t authorization
> response. =A0The verification code can then be sent by the javascript = layer to
> the client server, where it is then used to request an access token [2= ].
> Love to hear your feedback.
> 1:=A0http://tools.ietf.org/html/draft-ietf-oauth-v2= -05#section-3.5.1
> 2:=A0http://tools.ietf.org/html/draft-ietf-oauth-v2= -05#section-3.6.2
> --
> Brian Ellin
> Product Manager, Twitter Platform
> http://twi= tter.com/brianellin
>
> ________________________= _______________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>



--
Brian Ellin=
Twitter Platform Team
http= ://twitter.com/brianellin
--000e0cd1a8cc9eb788048720c8c7-- From balfanz@google.com Fri May 21 14:02:44 2010 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 615D23A6992 for ; Fri, 21 May 2010 14:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.376 X-Spam-Level: X-Spam-Status: No, score=-99.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 zL5of2pO30qF for ; Fri, 21 May 2010 14:02:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A0C293A69B1 for ; Fri, 21 May 2010 14:02:35 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o4LKTXel002731 for ; Fri, 21 May 2010 13:29:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274473773; bh=RuHD6q9CfLasuqHH4Un3ZgGhKy4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=No7QkD34e11K5Rzh2/Zr7vz8Pd0TqdfbCHJ2erdZ0/djwx/i9A8HAv1vKd5D5KBgg ubnJpTbNY5hJp+JInss1w== 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=gWd4zdsPktDA8PW6JhPzHWV9a2+VYXs0zmuAlEaG0ocgMhn2rKkSGwwN88aNLXzfW EzW3lxsIrXQnus4Ueiw9g== Received: from iwn6 (iwn6.prod.google.com [10.241.68.70]) by wpaz21.hot.corp.google.com with ESMTP id o4LKTVSK011566 for ; Fri, 21 May 2010 13:29:32 -0700 Received: by iwn6 with SMTP id 6so1620646iwn.19 for ; Fri, 21 May 2010 13:29:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.185.6 with SMTP id cm6mr1475379ibb.72.1274473771066; Fri, 21 May 2010 13:29:31 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Fri, 21 May 2010 13:29:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 13:29:30 -0700 Message-ID: From: Dirk Balfanz To: "Richer, Justin P." Content-Type: multipart/alternative; boundary=0050450171ee66655d0487208c54 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Fri, 21 May 2010 21:02:44 -0000 --0050450171ee66655d0487208c54 Content-Type: text/plain; charset=ISO-8859-1 That would be fine with me, but I think people really like to have signatures as a part of core OAuth. I don't feel strongly about it either way. One nit-pick, though: the other spec (which, in my proposal, is simply a new section in the OAuth spec), wouldn't be about "signed tokens". The way I see it, there should be only one kind of token - you can't use it to sign things, you simply include it in your requests. Whether those requests come in the clear, over SSL, or are otherwise signed, is a different question. The token shouldn't have anything to do with request signing: In the case of SSL, for example, the requests are signed (using a shared secret negotiated during the SSL handshake), but the token has nothing to do with that signature. In the case where we don't use SSL, yet still want to sign the requests, the same should be true: the signature on the request should have nothing to do with the token - the token and the signature serve two different purposes. Fortunately, we have a secret we can use for the signature: the OAuth client secret (and hopefully, in a future rev of the spec, the client private key) - so it makes sense to make this request signing be at least a companion spec to OAuth, if not a section of the spec itself. Dirk. On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. wrote: > I have a slightly more radical proposal. What if we factor out the signed > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given > the same attention by the group and all that like Eran was talking about > yesterday. What this would take is taking out all reference to signing and > making core OAuth just about bare tokens, then have a separate spec that > details what to call your shared secret parameters, how to get them, and how > to sign with them. This makes the core spec a lot simpler (as detailed > below) but makes the overall use case of using signed tokens more > complicated to follow, as it'd be split in two. > > -- justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > Balfanz [balfanz@google.com] > Sent: Thursday, May 20, 2010 7:39 PM > To: OAuth WG > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away with > base string canonicalization, (2) allow for symmetric and public keys, and > (3) allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal by > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it > would work both with the signing mechanism in the current spec, as well as > with Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easier > to implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put together > by Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from > the spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then > X, else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like > this: > > "Servers may require that requests be authenticated by the Client, so that > presentation of the access token alone is not sufficient to access a > Protected Resource. This has several use cases, including, but not limited > to, the following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access > tokens may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. The > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, > then the Client uses the following mechanism to sign their HTTP requests: > [...]" > > Then, we basically drop the old Section 5.3 here (except we use the client > secret instead of the access token secret). Eventually, instead of Section > 5.3, we may have Brian's new signature scheme section here, which would add > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieved > once we have public-key crypto. > > --0050450171ee66655d0487208c54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That would be fine with me, but I think people really like to have signatur= es as a part of core OAuth. I don't feel strongly about it either way.<= div>
One nit-pick, though: the other spec (which, in my propo= sal, is simply a new section in the OAuth spec), wouldn't be about &quo= t;signed tokens". The way I see it, there should be only one kind of t= oken - you can't use it to sign things, you simply include it in your r= equests. Whether those requests come in the clear, over SSL, or are otherwi= se signed, is a different question. The token shouldn't have anything t= o do with request signing: In the case of SSL, for example, the requests ar= e signed (using a shared secret negotiated during the SSL handshake), but t= he token has nothing to do with that signature. In the case where we don= 9;t use SSL, yet still want to sign the requests, the same should be true: = the signature on the request should have nothing to do with the token - the= token and the signature serve two different purposes.=A0

Fortunately, we have a secret we can use for the signat= ure: the OAuth client secret (and hopefully, in a future rev of the spec, t= he client private key) - so it makes sense to make this request signing be = at least a companion spec to OAuth, if not a section of the spec itself.

Dirk.

On Fri, May 21,= 2010 at 11:27 AM, Richer, Justin P. <jricher@mitre.org> wrote:
I have a slightly more radical proposal. What if we factor out the signed t= oken use case into a parallel spec? The OAuth 2.0 Signed Token spec, given = the same attention by the group and all that like Eran was talking about ye= sterday. What this would take is taking out all reference to signing and ma= king core OAuth just about bare tokens, then have a separate spec that deta= ils what to call your shared secret parameters, how to get them, and how to= sign with them. This makes the core spec a lot simpler (as detailed below)= but makes the overall use case of using signed tokens more complicated to = follow, as it'd be split in two.

=A0-- justin
________________________________________
From: oauth-bounces@ietf.org = [oauth-bounces@ietf.org] On B= ehalf Of Dirk Balfanz [balfanz@google= .com]
Sent: Thursday, May 20, 2010 7:39 PM
To: OAuth WG
Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2
Hi guys,

at today's interim meeting, we were discussing Brian Eaton's propos= al for OAuth signatures. He was proposing a mechanism that would (1) do awa= y with base string canonicalization, (2) allow for symmetric and public key= s, and (3) allow for extensibility.

He got homework from the group to prove the feasibility of his proposal by = showing a couple of implementations.

In this post, I would like to introduce another improvement of the OAuth 2 = signing mechanism, one which is orthogonal to Brian's proposal (i.e., i= t would work both with the signing mechanism in the current spec, as well a= s with Brian's signature mechanism). The goal of my proposal is twofold= :

- it simplifies the spec. It will become more readable and therefore easier= to implement
- it separates out the mechanisms for delegated authorization and for integ= rity protection into two independent pieces, which can be put together by S= ervers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access r= equests.

Long version of the proposal:

- remove all references to access tokens that are not bearer tokens from th= e spec.
- stop calling the access tokens "bearer tokens". Call them just = "access tokens".
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token t= hen X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes somethi= ng like this:

"Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a P= rotected Resource. =A0This has several use cases, including, but not limite= d to, the following:

- Non-repudiation: high-security deployments may require that requests be a= uthenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that access tok= ens may leak.
- End-to-end-integrity: even if SSL _is_ used, network infrastructure may s= trip SSL protection before the request reaches the protected resource. The = protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR access requests, the= n the Client uses the following mechanism to sign their HTTP requests: [...= ]"

Then, we basically drop the old Section 5.3 here (except we use the client = secret instead of the access token secret). Eventually, instead of Section = 5.3, we may have Brian's new signature scheme section here, which would= add the option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only be achieved = once we have public-key crypto.


--0050450171ee66655d0487208c54-- From mscurtescu@google.com Fri May 21 15:04:44 2010 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 453223A6407 for ; Fri, 21 May 2010 15:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 JPs4wkJRGiE1 for ; Fri, 21 May 2010 15:04:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 943463A68B1 for ; Fri, 21 May 2010 15:04:42 -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 o4LJctIG015922 for ; Fri, 21 May 2010 12:38:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274470736; bh=+FpTPSdcSviE87p/H0nYXWDIzfo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=aRriBSwphtGbIrIFkM32O8flPM3pTqeA0fUYXp3+0rBjDn1eLekktsfwOV4tdyPBI 77lgpleo0QX1ZlRrDKw1Q== 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:content-transfer-encoding:x-system-of-record; b=JDrW8rltCvI2frzeBUgHaChNAmiXyMNji8I9bB4v6+oTOHVPefPGuppqJmwyfArzj JT11572OKM4fiCXHdFWrg== Received: from pvh11 (pvh11.prod.google.com [10.241.210.203]) by wpaz1.hot.corp.google.com with ESMTP id o4LJcrtx019508 for ; Fri, 21 May 2010 12:38:54 -0700 Received: by pvh11 with SMTP id 11so1197195pvh.2 for ; Fri, 21 May 2010 12:38:53 -0700 (PDT) Received: by 10.140.247.19 with SMTP id u19mr1506322rvh.226.1274470524119; Fri, 21 May 2010 12:35:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Fri, 21 May 2010 12:35:04 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Fri, 21 May 2010 12:35:04 -0700 Message-ID: To: Brian Ellin 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: make it possible to get a verification code in the user-agent flow 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, 21 May 2010 22:04:44 -0000 Why not use the web server flow in this case? I think it should work with un-registered clients as well (no client secret= ). Marius On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrote: > We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter. > =A0@anywhere is a pure javascript layer that developers can drop in to ad= d > Twitter features to their website. =A0With the User-Agent flow, we issue = short > lived access tokens that refresh as they expire. =A0It works great for in= -page > stuff, but many developers are also building server-side integrations and > would love to have different longer lived access tokens on their server. > =A0This is a common pattern that other connect-like services built on top= of > OAuth 2.0 will also find necessary. > So, why not just use the access token issued by the User-Agent flow on th= e > client server? =A0Overloading the use of that token is not desirable for = a > couple of reasons: > 1) The client server may not be using ssl, and as such the browser cannot > securely transfer the access token to the server. > 2) The access token lifetime policy for the User-Agent flow may not > be=A0desirable=A0on the server. =A0Specifically, the server may need a to= ken that > lasts for, say, two weeks instead of 15 minutes. =A0Additionally, the tok= en on > the server may have access to different resources that are not=A0desirabl= e=A0to > transmit to or through the browser. > In short, it is=A0desirable=A0to get two different access tokens from a s= ingle > user authorization triggered by the User-Agent flow. > Proposal: > Make it possible to get a Web Server flow verification code from the > User-Agent client authorization request [1]. Specifically, add a new > optional parameter named "web_server_code" which when set to "true" retur= ns > a Web Server flow verification "code" field in the User-Agent authorizati= on > response. =A0The verification code can then be sent by the javascript lay= er to > the client server, where it is then used to request an access token [2]. > Love to hear your feedback. > 1:=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1 > 2:=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2 > -- > Brian Ellin > Product Manager, Twitter Platform > http://twitter.com/brianellin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From beaton@google.com Fri May 21 15:30:14 2010 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 2C5833A68CD for ; Fri, 21 May 2010 15:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.283 X-Spam-Level: X-Spam-Status: No, score=-100.283 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 8GpUB+TqVF88 for ; Fri, 21 May 2010 15:30:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1DC423A6847 for ; Fri, 21 May 2010 15:30:12 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o4LMU3fC012887 for ; Fri, 21 May 2010 15:30:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274481004; bh=+2GDC8Y+/GYycDb/SWLniVrOLOk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=TYOnKVyxPpzhXSS8B35wGFmvsOPml2+5VELhuzTlFqyUgH++PS8tetdJAiKz1wZp4 BaXTE9SkpdGhxffdRe6BA== 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=JbpvNNm7KOHOGGb2Wg57SIRvjjm3DditdeY4gajRZ93KzbxkTjQ5oAWYRuC39yPCW +qZ31RyFnOPeVRPqPmnxw== Received: from pzk13 (pzk13.prod.google.com [10.243.19.141]) by kpbe13.cbf.corp.google.com with ESMTP id o4LMTtPY013207 for ; Fri, 21 May 2010 15:30:02 -0700 Received: by pzk13 with SMTP id 13so1284440pzk.13 for ; Fri, 21 May 2010 15:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.1.19 with SMTP id 19mr1496619wfa.111.1274481001833; Fri, 21 May 2010 15:30:01 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Fri, 21 May 2010 15:30:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 15:30:01 -0700 Message-ID: From: Brian Eaton To: Brian Ellin 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: make it possible to get a verification code in the user-agent flow 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, 21 May 2010 22:30:14 -0000 On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrote: > =A0This is a common pattern that other connect-like services built on top= of > OAuth 2.0 will also find necessary. > So, why not just use the access token issued by the User-Agent flow on th= e > client server? =A0Overloading the use of that token is not desirable for = a > couple of reasons: > 1) The client server may not be using ssl, and as such the browser cannot > securely transfer the access token to the server. > 2) The access token lifetime policy for the User-Agent flow may not > be=A0desirable=A0on the server. =A0Specifically, the server may need a to= ken that > lasts for, say, two weeks instead of 15 minutes. =A0Additionally, the tok= en on > the server may have access to different resources that are not=A0desirabl= e=A0to > transmit to or through the browser. I think I like this. At the OAuth 2 interim meeting yesterday, I mentioned that the security characteristics of the user-agent flow could be improved. In particular, refresh tokens issued through the user-agent flow are a problem. Imagine this scenario: - RP receives refresh tokens from many users. - RP is compromised. The refresh token database leaks. The only way to recover from this scenario is to revoke all of the refresh tokens and ask users to reapprove. The web server flow doesn't have the same weakness. For the web server flow, you can change the client secret of the RP web site instead. The stolen refresh tokens are then useless. To understand why rotating client secrets doesn't work for the user-agent flow, consider this attack: - attacker steals refresh token - client secret is changed - attacker starts the user-agent flow - attacker replays the stolen refresh token - RP accepts the stolen refresh token and uses it on the attacker's behalf So maybe the user-agent flow should *never* return a refresh token on the URL. Instead, it should return an access token, plus an optional verification code. Cheers, Brian From cmortimore@salesforce.com Fri May 21 17:28:02 2010 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 E62493A6875 for ; Fri, 21 May 2010 17:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.832 X-Spam-Level: X-Spam-Status: No, score=-4.832 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 Ceimgdi+jgqo for ; Fri, 21 May 2010 17:27:57 -0700 (PDT) Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by core3.amsl.com (Postfix) with SMTP id 043603A6855 for ; Fri, 21 May 2010 17:27:56 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKS/clBmn4otVynfJUixQPsHGd5bA++TTd@postini.com; Fri, 21 May 2010 17:27:51 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Fri, 21 May 2010 17:27:50 -0700 From: Chuck Mortimore To: Brian Eaton , Brian Ellin Date: Fri, 21 May 2010 17:27:48 -0700 Thread-Topic: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow Thread-Index: Acr5Php8jQNypVtPRRmVwtMmoUT84gAB4BkV Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C81C73145F2Dcmortimoresalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow 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, 22 May 2010 00:28:03 -0000 --_000_C81C73145F2Dcmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 At the moment we don't intend to issue refresh tokens on the user-agent flo= w. This would likely change our mind. -cmort On 5/21/10 3:30 PM, "Brian Eaton" wrote: On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrote: > This is a common pattern that other connect-like services built on top o= f > OAuth 2.0 will also find necessary. > So, why not just use the access token issued by the User-Agent flow on th= e > client server? Overloading the use of that token is not desirable for a > couple of reasons: > 1) The client server may not be using ssl, and as such the browser cannot > securely transfer the access token to the server. > 2) The access token lifetime policy for the User-Agent flow may not > be desirable on the server. Specifically, the server may need a token th= at > lasts for, say, two weeks instead of 15 minutes. Additionally, the token= on > the server may have access to different resources that are not desirable = to > transmit to or through the browser. I think I like this. At the OAuth 2 interim meeting yesterday, I mentioned that the security characteristics of the user-agent flow could be improved. In particular, refresh tokens issued through the user-agent flow are a problem. Imagine this scenario: - RP receives refresh tokens from many users. - RP is compromised. The refresh token database leaks. The only way to recover from this scenario is to revoke all of the refresh tokens and ask users to reapprove. The web server flow doesn't have the same weakness. For the web server flow, you can change the client secret of the RP web site instead. The stolen refresh tokens are then useless. To understand why rotating client secrets doesn't work for the user-agent flow, consider this attack: - attacker steals refresh token - client secret is changed - attacker starts the user-agent flow - attacker replays the stolen refresh token - RP accepts the stolen refresh token and uses it on the attacker's behalf So maybe the user-agent flow should *never* return a refresh token on the URL. Instead, it should return an access token, plus an optional verification code. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C81C73145F2Dcmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Proposal: make it possible to get a verification code= in the user-agent flow +1

At the moment we don’t intend to issue refresh tokens on the user-age= nt flow.    This would likely change our mind.

-cmort


On 5/21/10 3:30 PM, "Brian Eaton" <beaton@google.com> wrote:

On Fri, May 21, 2010 at 10:39 AM, Brian Ellin <bellin@twitter.com> wrote:
> =A0This is a common pattern that other connect-like services built on = top of
> OAuth 2.0 will also find necessary.
> So, why not just use the access token issued by the User-Agent flow on= the
> client server? =A0Overloading the use of that token is not desirable f= or a
> couple of reasons:
> 1) The client server may not be using ssl, and as such the browser can= not
> securely transfer the access token to the server.
> 2) The access token lifetime policy for the User-Agent flow may not > be=A0desirable=A0on the server. =A0Specifically, the server may need a= token that
> lasts for, say, two weeks instead of 15 minutes. =A0Additionally, the = token on
> the server may have access to different resources that are not=A0desir= able=A0to
> transmit to or through the browser.

I think I like this.

At the OAuth 2 interim meeting yesterday, I mentioned that the
security characteristics of the user-agent flow could be improved.  In=
particular, refresh tokens issued through the user-agent flow are a
problem.  Imagine this scenario:

- RP receives refresh tokens from many users.
- RP is compromised.   The refresh token database leaks.

The only way to recover from this scenario is to revoke all of the
refresh tokens and ask users to reapprove.

The web server flow doesn't have the same weakness.  For the web
server flow, you can change the client secret of the RP web site
instead.  The stolen refresh tokens are then useless.

To understand why rotating client secrets doesn't work for the
user-agent flow, consider this attack:
- attacker steals refresh token
- client secret is changed
- attacker starts the user-agent flow
- attacker replays the stolen refresh token
- RP accepts the stolen refresh token and uses it on the attacker's behalf<= BR>
So maybe the user-agent flow should *never* return a refresh token on
the URL.  Instead, it should return an access token, plus an optional<= BR> verification code.

Cheers,
Brian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C81C73145F2Dcmortimoresalesforcecom_-- From mscurtescu@google.com Fri May 21 17:51:23 2010 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 023EE3A6855 for ; Fri, 21 May 2010 17:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.168 X-Spam-Level: X-Spam-Status: No, score=-100.168 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 b4dZcOPlLylu for ; Fri, 21 May 2010 17:51:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9FF963A6A09 for ; Fri, 21 May 2010 17:50:58 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o4M0ong6023455 for ; Fri, 21 May 2010 17:50:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274489451; bh=gQ3y2hqSkKCX1KdilP5CN5poHbE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZICGXQdypLDyhza0NgdcGsOP9wkWRMURAtrIvd3Gt4u/Th/mWYah8cfgE6QCCdyKY mruAPE4Zx8P+j6YxB35nA== 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:content-transfer-encoding:x-system-of-record; b=wNm7MvO0KWBi1NC7qoYXOBev3pvpZ1xv6H/Yaoe2gwCQz2q3emVeFNfRi9exrk0AX xl7uKJc8x6d3Vz1BIlZxQ== Received: from pzk41 (pzk41.prod.google.com [10.243.19.169]) by kpbe12.cbf.corp.google.com with ESMTP id o4M0okEN032283 for ; Fri, 21 May 2010 17:50:48 -0700 Received: by pzk41 with SMTP id 41so830686pzk.10 for ; Fri, 21 May 2010 17:50:47 -0700 (PDT) Received: by 10.140.58.7 with SMTP id g7mr1752208rva.37.1274489447829; Fri, 21 May 2010 17:50:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Fri, 21 May 2010 17:50:27 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Fri, 21 May 2010 17:50:27 -0700 Message-ID: To: Brian Ellin 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: make it possible to get a verification code in the user-agent flow 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, 22 May 2010 00:51:23 -0000 On Fri, May 21, 2010 at 1:46 PM, Brian Ellin wrote: > Marius, > I don't understand. =A0Will you elaborate on how specifically that would = work? Maybe I am missing something, but I was suggesting that the JavaScript code starts a web server flow at the end of which it has a verification code. It passes this verification code down to the client server, the client server swaps it for an access token and a refresh token and passes the access token to the JavaScript client. When the access token expires the client JavaScript has two options, ask the client server for a refresh or do an immediate request to that authz server. If you want that the client server and client JavaScript have tokens with totally different scopes, then you probably want to send the user for approval twice. If you just want the client JavaScript to have a token with a lesser scope (and avoid a second approval), then we should probably look into down-scoping, which currently is not supported. Would that work? Marius > Brian > > On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu > wrote: >> >> Why not use the web server flow in this case? >> >> I think it should work with un-registered clients as well (no client >> secret). >> >> Marius >> >> >> >> On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrote= : >> > We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter. >> > =A0@anywhere is a pure javascript layer that developers can drop in to= add >> > Twitter features to their website. =A0With the User-Agent flow, we iss= ue >> > short >> > lived access tokens that refresh as they expire. =A0It works great for >> > in-page >> > stuff, but many developers are also building server-side integrations >> > and >> > would love to have different longer lived access tokens on their serve= r. >> > =A0This is a common pattern that other connect-like services built on = top >> > of >> > OAuth 2.0 will also find necessary. >> > So, why not just use the access token issued by the User-Agent flow on >> > the >> > client server? =A0Overloading the use of that token is not desirable f= or a >> > couple of reasons: >> > 1) The client server may not be using ssl, and as such the browser >> > cannot >> > securely transfer the access token to the server. >> > 2) The access token lifetime policy for the User-Agent flow may not >> > be=A0desirable=A0on the server. =A0Specifically, the server may need a= token >> > that >> > lasts for, say, two weeks instead of 15 minutes. =A0Additionally, the >> > token on >> > the server may have access to different resources that are >> > not=A0desirable=A0to >> > transmit to or through the browser. >> > In short, it is=A0desirable=A0to get two different access tokens from = a >> > single >> > user authorization triggered by the User-Agent flow. >> > Proposal: >> > Make it possible to get a Web Server flow verification code from the >> > User-Agent client authorization request [1]. Specifically, add a new >> > optional parameter named "web_server_code" which when set to "true" >> > returns >> > a Web Server flow verification "code" field in the User-Agent >> > authorization >> > response. =A0The verification code can then be sent by the javascript >> > layer to >> > the client server, where it is then used to request an access token [2= ]. >> > Love to hear your feedback. >> > 1:=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1 >> > 2:=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2 >> > -- >> > Brian Ellin >> > Product Manager, Twitter Platform >> > http://twitter.com/brianellin >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > > > > > -- > Brian Ellin > Twitter Platform Team > http://twitter.com/brianellin > From jpanzer@google.com Fri May 21 21:15:58 2010 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 2CE833A6B32 for ; Fri, 21 May 2010 21:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.906 X-Spam-Level: X-Spam-Status: No, score=-103.906 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_50=0.001, 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 DMMPFdvViqcR for ; Fri, 21 May 2010 21:15:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id F017C3A6B1C for ; Fri, 21 May 2010 21:15:55 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o4M4Flbd013025 for ; Fri, 21 May 2010 21:15:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274501749; bh=F111jJaeociDNm8JESalz81GQ4s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=YOAM+5eDHTEqGFC47FWkcp0TfIWQBAPz2ZyldcQoGDAFf3JzFcNfY7ctbnKware59 1vn3kVvGqAo+FG+umb8Dw== 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=Mj25/hBUrgBFWHokkSJoOA9Wpsb4KbFpq3B350o8Ggi7Pbnc1lU4mEWNCQWYxXd1r amZ5XJHarM0tsIO2g9zhw== Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by hpaq13.eem.corp.google.com with ESMTP id o4M4FjSl002359 for ; Fri, 21 May 2010 21:15:46 -0700 Received: by vws13 with SMTP id 13so1583486vws.0 for ; Fri, 21 May 2010 21:15:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.136 with SMTP id k8mr1636519vcs.198.1274501745483; Fri, 21 May 2010 21:15:45 -0700 (PDT) Received: by 10.220.16.208 with HTTP; Fri, 21 May 2010 21:15:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 21:15:45 -0700 Message-ID: From: John Panzer To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sat, 22 May 2010 04:15:58 -0000 Dirk: How would sub-delegation of an access token work in your proposal? In other words I hand my AT to a sub-contractor. Who may call on Apis that do not require a signature from them; or they may, and therefore need their own relationship with the service. But it's up to the service and could depend in the API and access needed. Seems like separation of concerns makes this easier. On Friday, May 21, 2010, Dirk Balfanz wrote: > That would be fine with me, but I think people really like to have signat= ures as a part of core OAuth. I don't feel strongly about it either way. > One nit-pick, though: the other spec (which, in my proposal, is simply a= new section in the OAuth spec), wouldn't be about "signed tokens". The way= I see it, there should be only one kind of token - you can't use it to sig= n things, you simply include it in your requests. Whether those requests co= me in the clear, over SSL, or are otherwise signed, is a different question= . The token shouldn't have anything to do with request signing: In the case= of SSL, for example, the requests are signed (using a shared secret negoti= ated during the SSL handshake), but the token has nothing to do with that s= ignature. In the case where we don't use SSL, yet still want to sign the re= quests, the same should be true: the signature on the request should have n= othing to do with the token - the token and the signature serve two differe= nt purposes. > > Fortunately, we have a secret we can use for the signature: the OAuth cli= ent secret (and hopefully, in a future rev of the spec, the client private = key) - so it makes sense to make this request signing be at least a compani= on spec to OAuth, if not a section of the spec itself. > > Dirk. > > On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. w= rote: > > I have a slightly more radical proposal. What if we factor out the signed= token use case into a parallel spec? The OAuth 2.0 Signed Token spec, give= n the same attention by the group and all that like Eran was talking about = yesterday. What this would take is taking out all reference to signing and = making core OAuth just about bare tokens, then have a separate spec that de= tails what to call your shared secret parameters, how to get them, and how = to sign with them. This makes the core spec a lot simpler (as detailed belo= w) but makes the overall use case of using signed tokens more complicated t= o follow, as it'd be split in two. > > =A0-- justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk B= alfanz [balfanz@google.com] > Sent: Thursday, May 20, 2010 7:39 PM > To: OAuth WG > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for= OAuth signatures. He was proposing a mechanism that would (1) do away with= base string canonicalization, (2) allow for symmetric and public keys, and= (3) allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal b= y showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth = 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it = would work both with the signing mechanism in the current spec, as well as = with Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easi= er to implement > - it separates out the mechanisms for delegated authorization and for int= egrity protection into two independent pieces, which can be put together by= Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access= requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from = the spec. > - stop calling the access tokens "bearer tokens". Call them just "access = tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then= X, else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like = this: > > "Servers may require that requests be authenticated by the Client, so tha= t presentation of the access token alone is not sufficient to access a Prot= ected Resource. =A0This has several use cases, including, but not limited t= o, the following: > > - Non-repudiation: high-security deployments may require that requests be= authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access t= okens may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may= strip SSL protection before the request reaches the protected resource. Th= e protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, t= hen the Client uses the following mechanism to sign their HTTP requests: [.= ..]" > > Then, we basically drop the old Section 5.3 here (except we use the clien= t secret instead of the access token secret). Eventually, instead of Sectio= n 5.3, we may have Brian's new signature scheme section here, which would a= dd the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieve= d once we have public-key crypto. > > > > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From justinsm@microsoft.com Fri May 21 22:23:19 2010 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 E90BA3A6B66 for ; Fri, 21 May 2010 22:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.238 X-Spam-Level: X-Spam-Status: No, score=-9.238 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 0oZFcbhM+Bot for ; Fri, 21 May 2010 22:21:52 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 802C53A6B6C for ; Fri, 21 May 2010 22:21:38 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 May 2010 22:21:31 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.129]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Fri, 21 May 2010 22:21:30 -0700 From: Justin Smith To: Dirk Balfanz , "Richer, Justin P." Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: AQHK+SRQpk1rhBaJYEGd9pXfR9mStJJc5b+Q Date: Sat, 22 May 2010 05:20:10 +0000 Deferred-Delivery: Sat, 22 May 2010 05:21:00 +0000 Message-ID: <191F411E00E19F4E943ECDB6D65C60851FA58269@TK5EX14MBXC115.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_191F411E00E19F4E943ECDB6D65C60851FA58269TK5EX14MBXC115r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sat, 22 May 2010 05:23:20 -0000 --_000_191F411E00E19F4E943ECDB6D65C60851FA58269TK5EX14MBXC115r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the idea of simplifying the core spec, but the devil is in the detai= ls. In practice it seems onerous to ask the AS and the PR to know both the key = used to sign the token as well as the key used to sign the request (regardl= ess of if the request signing key is the same as the client_secret). I'm also not sure the bearer token / access token language works even with = the existing section 5.3. As Dirk points out, choosing to "sign" the reques= t is independent of the AS issued token. Does anyone think it is necessary = to keep the bearer / access token language as is? FWIW, I'm in favor of moving the request signing into a companion spec. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= irk Balfanz Sent: Friday, May 21, 2010 1:29 PM To: Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth= 2 That would be fine with me, but I think people really like to have signatur= es as a part of core OAuth. I don't feel strongly about it either way. One nit-pick, though: the other spec (which, in my proposal, is simply a ne= w section in the OAuth spec), wouldn't be about "signed tokens". The way I = see it, there should be only one kind of token - you can't use it to sign t= hings, you simply include it in your requests. Whether those requests come = in the clear, over SSL, or are otherwise signed, is a different question. T= he token shouldn't have anything to do with request signing: In the case of= SSL, for example, the requests are signed (using a shared secret negotiate= d during the SSL handshake), but the token has nothing to do with that sign= ature. In the case where we don't use SSL, yet still want to sign the reque= sts, the same should be true: the signature on the request should have noth= ing to do with the token - the token and the signature serve two different = purposes. Fortunately, we have a secret we can use for the signature: the OAuth clien= t secret (and hopefully, in a future rev of the spec, the client private ke= y) - so it makes sense to make this request signing be at least a companion= spec to OAuth, if not a section of the spec itself. Dirk. On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. > wrote: I have a slightly more radical proposal. What if we factor out the signed t= oken use case into a parallel spec? The OAuth 2.0 Signed Token spec, given = the same attention by the group and all that like Eran was talking about ye= sterday. What this would take is taking out all reference to signing and ma= king core OAuth just about bare tokens, then have a separate spec that deta= ils what to call your shared secret parameters, how to get them, and how to= sign with them. This makes the core spec a lot simpler (as detailed below)= but makes the overall use case of using signed tokens more complicated to = follow, as it'd be split in two. -- justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] On Behalf Of Dirk Balfanz [balfanz= @google.com] Sent: Thursday, May 20, 2010 7:39 PM To: OAuth WG Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Hi guys, at today's interim meeting, we were discussing Brian Eaton's proposal for O= Auth signatures. He was proposing a mechanism that would (1) do away with b= ase string canonicalization, (2) allow for symmetric and public keys, and (= 3) allow for extensibility. He got homework from the group to prove the feasibility of his proposal by = showing a couple of implementations. In this post, I would like to introduce another improvement of the OAuth 2 = signing mechanism, one which is orthogonal to Brian's proposal (i.e., it wo= uld work both with the signing mechanism in the current spec, as well as wi= th Brian's signature mechanism). The goal of my proposal is twofold: - it simplifies the spec. It will become more readable and therefore easier= to implement - it separates out the mechanisms for delegated authorization and for integ= rity protection into two independent pieces, which can be put together by S= ervers and/or Clients like LEGO blocks. Summary: - use the client secret instead of the token secret for signing PR access r= equests. Long version of the proposal: - remove all references to access tokens that are not bearer tokens from th= e spec. - stop calling the access tokens "bearer tokens". Call them just "access to= kens". - remove all references to token secrets from the spec - remove all parts of the spec that are of the kind "if bearer_token then X= , else Y", and replace them with X. - delete section 5.3 - add a section called "Request Authentication" that goes something like th= is: "Servers may require that requests be authenticated by the Client, so that = presentation of the access token alone is not sufficient to access a Protec= ted Resource. This has several use cases, including, but not limited to, t= he following: - Non-repudiation: high-security deployments may require that requests be a= uthenticated (signed) in a non-repudiateable way[1] - Access to protected resources is not protected by SSL, so that access tok= ens may leak. - End-to-end-integrity: even if SSL _is_ used, network infrastructure may s= trip SSL protection before the request reaches the protected resource. The = protected resource, however, may require end-to-end integrity. If the Server requires that the Client authenticate PR access requests, the= n the Client uses the following mechanism to sign their HTTP requests: [...= ]" Then, we basically drop the old Section 5.3 here (except we use the client = secret instead of the access token secret). Eventually, instead of Section = 5.3, we may have Brian's new signature scheme section here, which would add= the option of public-key crypto[1], etc. What do you guys think? Dirk. [1] Technically speaking, the goal of non-repudiation can only be achieved = once we have public-key crypto. --_000_191F411E00E19F4E943ECDB6D65C60851FA58269TK5EX14MBXC115r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like th= e idea of simplifying the core spec, but the devil is in the details. =

 

In practice it seems onerous to ask the AS and th= e PR to know both the key used to sign the token as well as the key used to= sign the request (regardless of if the request signing key is the same as = the client_secret).

 

I’m also not sure= the bearer token / access token language works even with the existing sect= ion 5.3. As Dirk points out, choosing to “sign” the request is = independent of the AS issued token. Does anyone think it is necessary to ke= ep the bearer / access token language as is?

 

FWIW, I’m in favor of moving the request signing into a companion sp= ec.

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces= @ietf.org] On Behalf Of Dirk Balfanz
Sent: Friday, May 21,= 2010 1:29 PM
To: Richer, Justin P.
Cc: OAuth WG
= Subject: Re: [OAUTH-WG] proposal for factoring out request signing in O= Auth 2

 

That would be fine with me, but I think people really like = to have signatures as a part of core OAuth. I don't feel strongly about it = either way.

 

One nit-pick, though: the other spec (which, = in my proposal, is simply a new section in the OAuth spec), wouldn't be abo= ut "signed tokens". The way I see it, there should be only one ki= nd of token - you can't use it to sign things, you simply include it in you= r requests. Whether those requests come in the clear, over SSL, or are othe= rwise signed, is a different question. The token shouldn't have anything to= do with request signing: In the case of SSL, for example, the requests are= signed (using a shared secret negotiated during the SSL handshake), but th= e token has nothing to do with that signature. In the case where we don't u= se SSL, yet still want to sign the requests, the same should be true: the s= ignature on the request should have nothing to do with the token - the toke= n and the signature serve two different purposes. 

 

Fortunately, we have a secret we can use for the signature: the OAuth = client secret (and hopefully, in a future rev of the spec, the client priva= te key) - so it makes sense to make this request signing be at least a comp= anion spec to OAuth, if not a section of the spec itself.

 

Dirk.

On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. <jricher@mitre.org> wrote:

<= p class=3DMsoNormal>I have a slightly more radical proposal. What if we fac= tor out the signed token use case into a parallel spec? The OAuth 2.0 Signe= d Token spec, given the same attention by the group and all that like Eran = was talking about yesterday. What this would take is taking out all referen= ce to signing and making core OAuth just about bare tokens, then have a sep= arate spec that details what to call your shared secret parameters, how to = get them, and how to sign with them. This makes the core spec a lot simpler= (as detailed below) but makes the overall use case of using signed tokens = more complicated to follow, as it'd be split in two.

 -- justin=
________________________________________
From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk Balfanz [balfanz@google.com]

Sent: Thursday, May 2= 0, 2010 7:39 PM
To: OAuth WG
Subject: [OAUTH-WG] proposal for factori= ng out request signing in OAuth 2

Hi guys,

at today's interim= meeting, we were discussing Brian Eaton's proposal for OAuth signatures. H= e was proposing a mechanism that would (1) do away with base string canonic= alization, (2) allow for symmetric and public keys, and (3) allow for exten= sibility.

He got homework from the group to prove the feasibility of= his proposal by showing a couple of implementations.

In this post, = I would like to introduce another improvement of the OAuth 2 signing mechan= ism, one which is orthogonal to Brian's proposal (i.e., it would work both = with the signing mechanism in the current spec, as well as with Brian's sig= nature mechanism). The goal of my proposal is twofold:

- it simplifi= es the spec. It will become more readable and therefore easier to implement=
- it separates out the mechanisms for delegated authorization and for i= ntegrity protection into two independent pieces, which can be put together = by Servers and/or Clients like LEGO blocks.

Summary:

- use th= e client secret instead of the token secret for signing PR access requests.=

Long version of the proposal:

- remove all references to acc= ess tokens that are not bearer tokens from the spec.
- stop calling the = access tokens "bearer tokens". Call them just "access tokens= ".
- remove all references to token secrets from the spec
- remo= ve all parts of the spec that are of the kind "if bearer_token then X,= else Y", and replace them with X.
- delete section 5.3
- add a = section called "Request Authentication" that goes something like = this:

"Servers may require that requests be authenticated by th= e Client, so that presentation of the access token alone is not sufficient = to access a Protected Resource.  This has several use cases, including= , but not limited to, the following:

- Non-repudiation: high-securit= y deployments may require that requests be authenticated (signed) in a non-= repudiateable way[1]
- Access to protected resources is not protected by= SSL, so that access tokens may leak.
- End-to-end-integrity: even if SS= L _is_ used, network infrastructure may strip SSL protection before the req= uest reaches the protected resource. The protected resource, however, may r= equire end-to-end integrity.

If the Server requires that the Client = authenticate PR access requests, then the Client uses the following mechani= sm to sign their HTTP requests: [...]"

Then, we basically drop = the old Section 5.3 here (except we use the client secret instead of the ac= cess token secret). Eventually, instead of Section 5.3, we may have Brian's= new signature scheme section here, which would add the option of public-ke= y crypto[1], etc.

What do you guys think?

Dirk.

[1] Te= chnically speaking, the goal of non-repudiation can only be achieved once w= e have public-key crypto.

 

= --_000_191F411E00E19F4E943ECDB6D65C60851FA58269TK5EX14MBXC115r_-- From balfanz@google.com Fri May 21 22:58:59 2010 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 54B7B3A6930 for ; Fri, 21 May 2010 22:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.376 X-Spam-Level: X-Spam-Status: No, score=-99.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gWJ389EG0qPC for ; Fri, 21 May 2010 22:58:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 80C393A6B84 for ; Fri, 21 May 2010 22:58:54 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o4M5wgCc011766 for ; Fri, 21 May 2010 22:58:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274507923; bh=M2/NmIv8dSU/p9QyC4FmZnrMekQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=cF0QpJbBfBRNzNA3a8I73L5z7vZQhULFxMZEQ8n8xjtEaEGAVUHy47YrndubYds0H E/KP6yyUcVK5+4qxziHQg== 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=WfaJFmCXi++wWNzzHDfIl9QC8TLU5hbsVCFohS8uReLnMBVqK1pB3rxeInK5TlnXg IES8vf2qrhLeLdH2YeYfA== Received: from iwn4 (iwn4.prod.google.com [10.241.68.68]) by wpaz17.hot.corp.google.com with ESMTP id o4M5weLx012427 for ; Fri, 21 May 2010 22:58:41 -0700 Received: by iwn4 with SMTP id 4so2032456iwn.23 for ; Fri, 21 May 2010 22:58:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.185.86 with SMTP id cn22mr1713954ibb.69.1274507920577; Fri, 21 May 2010 22:58:40 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Fri, 21 May 2010 22:58:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 22:58:40 -0700 Message-ID: From: Dirk Balfanz To: John Panzer Content-Type: multipart/alternative; boundary=005045013e22de97040487287ff8 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sat, 22 May 2010 05:58:59 -0000 --005045013e22de97040487287ff8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 21, 2010 at 9:15 PM, John Panzer wrote: > Dirk: How would sub-delegation of an access token work in your > proposal? In other words I hand my AT to a sub-contractor. Who may > call on Apis that do not require a signature from them; or they may, > and therefore need their own relationship with the service. But it's > up to the service and could depend in the API and access needed. > Seems like separation of concerns makes this easier. > Yes, my proposal allows the PR to decide whether or not they allow such sub-delegation. You could imagine servers that don't care - whoever shows up with the bearer token has access. You could imagine servers that don't allow sub-delegation at all - and they would use this signature scheme as a way to enforce it. And you could imagine servers somewhere in the middle - they accept tokens from a sub-delegatee as long as the original Client has told the Server that they're sub-delegating to that particular sub-delegatee. Only the first of those is possible with token-secret-signatures. All three are possible with client-secret signatures. Dirk. > > On Friday, May 21, 2010, Dirk Balfanz wrote: > > That would be fine with me, but I think people really like to have > signatures as a part of core OAuth. I don't feel strongly about it either > way. > > One nit-pick, though: the other spec (which, in my proposal, is simply a > new section in the OAuth spec), wouldn't be about "signed tokens". The way I > see it, there should be only one kind of token - you can't use it to sign > things, you simply include it in your requests. Whether those requests come > in the clear, over SSL, or are otherwise signed, is a different question. > The token shouldn't have anything to do with request signing: In the case of > SSL, for example, the requests are signed (using a shared secret negotiated > during the SSL handshake), but the token has nothing to do with that > signature. In the case where we don't use SSL, yet still want to sign the > requests, the same should be true: the signature on the request should have > nothing to do with the token - the token and the signature serve two > different purposes. > > > > Fortunately, we have a secret we can use for the signature: the OAuth > client secret (and hopefully, in a future rev of the spec, the client > private key) - so it makes sense to make this request signing be at least a > companion spec to OAuth, if not a section of the spec itself. > > > > Dirk. > > > > On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. > wrote: > > > > I have a slightly more radical proposal. What if we factor out the signed > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given > the same attention by the group and all that like Eran was talking about > yesterday. What this would take is taking out all reference to signing and > making core OAuth just about bare tokens, then have a separate spec that > details what to call your shared secret parameters, how to get them, and how > to sign with them. This makes the core spec a lot simpler (as detailed > below) but makes the overall use case of using signed tokens more > complicated to follow, as it'd be split in two. > > > > -- justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > Balfanz [balfanz@google.com] > > Sent: Thursday, May 20, 2010 7:39 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > > > Hi guys, > > > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away with > base string canonicalization, (2) allow for symmetric and public keys, and > (3) allow for extensibility. > > > > He got homework from the group to prove the feasibility of his proposal > by showing a couple of implementations. > > > > In this post, I would like to introduce another improvement of the OAuth > 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it > would work both with the signing mechanism in the current spec, as well as > with Brian's signature mechanism). The goal of my proposal is twofold: > > > > - it simplifies the spec. It will become more readable and therefore > easier to implement > > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put together > by Servers and/or Clients like LEGO blocks. > > > > Summary: > > > > - use the client secret instead of the token secret for signing PR access > requests. > > > > Long version of the proposal: > > > > - remove all references to access tokens that are not bearer tokens from > the spec. > > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > > - remove all references to token secrets from the spec > > - remove all parts of the spec that are of the kind "if bearer_token then > X, else Y", and replace them with X. > > - delete section 5.3 > > - add a section called "Request Authentication" that goes something like > this: > > > > "Servers may require that requests be authenticated by the Client, so > that presentation of the access token alone is not sufficient to access a > Protected Resource. This has several use cases, including, but not limited > to, the following: > > > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > > - Access to protected resources is not protected by SSL, so that access > tokens may leak. > > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. The > protected resource, however, may require end-to-end integrity. > > > > If the Server requires that the Client authenticate PR access requests, > then the Client uses the following mechanism to sign their HTTP requests: > [...]" > > > > Then, we basically drop the old Section 5.3 here (except we use the > client secret instead of the access token secret). Eventually, instead of > Section 5.3, we may have Brian's new signature scheme section here, which > would add the option of public-key crypto[1], etc. > > > > What do you guys think? > > > > Dirk. > > > > [1] Technically speaking, the goal of non-repudiation can only be > achieved once we have public-key crypto. > > > > > > > > > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > --005045013e22de97040487287ff8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 21, 2010 at 9:15 PM, John Pa= nzer <jpanzer@go= ogle.com> wrote:
Dirk: How would sub-delegation of an access token work in your
proposal? =A0In other words I hand my AT to a sub-contractor. =A0Who may call on Apis that do not require a signature from them; or they may,
and therefore need their own relationship with the service. But it's up to the service and could depend in the API and access needed.
Seems like separation of concerns makes this easier.
<= br>
Yes, my proposal allows the PR to decide whether or not they = allow such sub-delegation. You could imagine servers that don't care - = whoever shows up with the bearer token has access. You could imagine server= s that don't allow sub-delegation at all - and they would use this sign= ature scheme as a way to enforce it. And you could imagine servers somewher= e in the middle - they accept tokens from a sub-delegatee as long as the or= iginal Client has told the Server that they're sub-delegating to that p= articular sub-delegatee. Only the first of those is possible with token-sec= ret-signatures. All three are possible with client-secret signatures.

Dirk.
=A0

On Friday, May 21, 2010, Dirk Balfanz <balfanz@google.com> wrote:
> That would be fine with me, but I think people really like to have sig= natures as a part of core OAuth. I don't feel strongly about it either = way.
> =A0One nit-pick, though: the other spec (which, in my proposal, is sim= ply a new section in the OAuth spec), wouldn't be about "signed to= kens". The way I see it, there should be only one kind of token - you = can't use it to sign things, you simply include it in your requests. Wh= ether those requests come in the clear, over SSL, or are otherwise signed, = is a different question. The token shouldn't have anything to do with r= equest signing: In the case of SSL, for example, the requests are signed (u= sing a shared secret negotiated during the SSL handshake), but the token ha= s nothing to do with that signature. In the case where we don't use SSL= , yet still want to sign the requests, the same should be true: the signatu= re on the request should have nothing to do with the token - the token and = the signature serve two different purposes.
>
> Fortunately, we have a secret we can use for the signature: the OAuth = client secret (and hopefully, in a future rev of the spec, the client priva= te key) - so it makes sense to make this request signing be at least a comp= anion spec to OAuth, if not a section of the spec itself.
>
> Dirk.
>
> On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. <jricher@mitre.org> wrote:
>
> I have a slightly more radical proposal. What if we factor out the sig= ned token use case into a parallel spec? The OAuth 2.0 Signed Token spec, g= iven the same attention by the group and all that like Eran was talking abo= ut yesterday. What this would take is taking out all reference to signing a= nd making core OAuth just about bare tokens, then have a separate spec that= details what to call your shared secret parameters, how to get them, and h= ow to sign with them. This makes the core spec a lot simpler (as detailed b= elow) but makes the overall use case of using signed tokens more complicate= d to follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oauth-bounces@ietf.org= [oauth-bounces@ietf.org]= On Behalf Of Dirk Balfanz [balfanz@g= oogle.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for OAuth signatures. He was proposing a mechanism that would (1) d= o away with base string canonicalization, (2) allow for symmetric and publi= c keys, and (3) allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2 signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would work both with the signing mechanism in the current spec, as w= ell as with Brian's signature mechanism). The goal of my proposal is tw= ofold:
>
> - it simplifies the spec. It will become more readable and therefore e= asier to implement
> - it separates out the mechanisms for delegated authorization and for = integrity protection into two independent pieces, which can be put together= by Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X, else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that presentation of the access token alone is not sufficient to acces= s a Protected Resource. =A0This has several use cases, including, but not l= imited to, the following:
>
> - Non-repudiation: high-security deployments may require that requests= be authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may strip SSL protection before the request reaches the protected resource.= The protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then the Client uses the following mechanism to sign their HTTP requests:= [...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient secret instead of the access token secret). Eventually, instead of Sec= tion 5.3, we may have Brian's new signature scheme section here, which = would add the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved once we have public-key crypto.
>
>
>
>

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

--005045013e22de97040487287ff8-- From hubertlvg@gmail.com Sat May 22 00:13:32 2010 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 C97123A6BC2 for ; Sat, 22 May 2010 00:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_50=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] 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 0ap9rtb5SDW0 for ; Sat, 22 May 2010 00:13:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D8CE93A6B97 for ; Sat, 22 May 2010 00:13:29 -0700 (PDT) Received: by wyf19 with SMTP id 19so987231wyf.31 for ; Sat, 22 May 2010 00:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GqTKgV7BdriH9b6rrBFnyJ66niCvSaNj9f2TrJhrRL8=; b=LwFWYblKgMkxQjyez1NIk1wB2kvkWwSTueg6UrHhgDiLMzU+Z6B4rP4dIMdkdzPwMv WHfB+9qPQntoVLPkwDP/srl0/D4RdW4HRhbaWo0SOPfRdbeIeN8AP6+d3EcILxPlU4T3 CQFjgtuEphvPXVzE/CNTdxqlYxp360RxxAmQQ= 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=x83K0DENL6OJEnjeB6DoA55QpMEJMwvCLuAJxnzB3H7+sHPrvHmXwfu/ZDu5cn2RCf 3J961JdH34vHDkT2Ee7YWGj+pJGTMRKddvjzxPK7v1LsQy32X8vDU2AewNXCEHfarLt2 0EClKjhFfDNFJ7ezYy4wZAW48wZb3pBmPXQXY= MIME-Version: 1.0 Received: by 10.216.183.11 with SMTP id p11mr1313554wem.226.1274512399175; Sat, 22 May 2010 00:13:19 -0700 (PDT) Received: by 10.216.182.212 with HTTP; Sat, 22 May 2010 00:13:19 -0700 (PDT) In-Reply-To: References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> Date: Sat, 22 May 2010 09:13:19 +0200 Message-ID: From: Hubert Le Van Gong To: Beau Lebens Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] in-app logout? 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, 22 May 2010 07:13:32 -0000 IMHO this would look more like a hack than proper protocol design. We need a delete/revoke operation that's the pendant to the other token operations = (i.e. crud ops). Hubert On Fri, May 21, 2010 at 7:05 PM, Beau Lebens wr= ote: > Could this just be implemented through support for a scope change > where scope=3Dnone or revoke or something? > > On Friday, May 21, 2010, Lukas Rosenstock wrote: >> Why not simply add this functionality to the token endpoint?The same pla= ce that was used to fetch the access token first or refresh it could be use= d to revoke the same token with another request. The only requirement would= be to define something like type=3Drevoke. >> I feel that is much easier than making the token a URL which supports DE= LETE. >> However, any mechanism will break implementations that rely on minimal o= r no communication between authorization server and protected resource, bec= ause all protected resources have to be informed. >> >> Regards,=A0Lukas >> >> 2010/5/16 Dick Hardt >> >> James: An important capability of the refresh token is that it *can* be = a self contained token in that is not an id, but a signed token that can be= examined and acted upon on presentation. >> Torsten: enabling a client to revoke a refresh token looks like a useful= mechanism. I anticipate it will be viewed as a vitamin feature rather than= a painkiller and will fall by the wayside unless the security conscience r= ally to have it included. >> >> >> -- Dick >> >> >> On Thu, May 13, 2010 at 7:10 AM, Manger, James H wrote: >> Torsten, >> >>> What about refresh token revocation/deletion? >> >> HTTP already has a method to do this: DELETE >> It just needs each token to have a URI. >> >> Tokens (almost) already have URIs -- its just not immediately obvious be= cause the URI has to be built from a common token endpoint and a refresh_to= ken. >> >> I think it would improve the spec if refresh_token was renamed to, say, = token_id; and its value defined as a URI (which can be a relative URI so th= e string may not need to change at all). >> >> To refresh a token you POST to the token's URI. >> To delete a token you send a DELETE request to the token's URI. >> >> It doesn't cause major changes, but there are some benefits. >> It is a more web-style design. >> It leaves only 1 type of token in the spec -- an access token -- which s= implifies the text and aids understanding. >> There are no arguments about length, allowed chars etc because it is a U= RI -- a well-known type, often with native support. >> Its obvious how to delete the token as there is a standard HTTP method D= ELETE to apply to the token URI. >> >> If a particular service supported an additional way to delete items in i= ts API (eg POST with a method=3Ddelete query parameter) that could apply to= the OAuth part as well. >> >> -- >> James Manger >> _______________________________________________ >> 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 >> >> >> >> -- >> http://lukasrosenstock.net/ >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Sat May 22 01:59:36 2010 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 0D75C3A6C0E for ; Sat, 22 May 2010 01:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 8adYaOzZ8eJ0 for ; Sat, 22 May 2010 01:59:34 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 1AA623A6C0D for ; Sat, 22 May 2010 01:59:33 -0700 (PDT) Received: from p4fff3bf8.dip.t-dialin.net ([79.255.59.248] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OFkYI-0006Zw-41; Sat, 22 May 2010 10:59:26 +0200 Message-ID: <4BF79CEB.9020502@lodderstedt.net> Date: Sat, 22 May 2010 10:59:23 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dirk Balfanz References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060303080805080200070406" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sat, 22 May 2010 08:59:36 -0000 This is a multi-part message in MIME format. --------------060303080805080200070406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Assume "client secret" means the secret issued by the OAuth AS to its clients, I think this client secret should be used to authenticate clients to the AS only. All other authentication (e.g. against PR) can be based on that trust anchor. I don't mind using the secret to sign AS requests. But here at Deutsche Telekom, we don't want to sign PR requests with the client secret because this requires a strong coupling between AS and PR. Our aim is to operate PR's and AS as independently as possible. I think the token secret is fine for signing PR requests and proving legitimate token ownership. It is issued after the client has succefully authenticated on the AS and thus transitively asserts its identity to the PR. Moreover, the secret can be passed from AS to PR as (encrypted) part of the access token. So the coupling between AS and PR is loose. That pattern is well-known from Kerberos and proven in the wild. One could use another PR-specific client-secret to sign PR requests. But that's out of OAuth2-scope, from my point of view. regards, Torsten. Am 21.05.2010 01:39, schrieb Dirk Balfanz: > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal > for OAuth signatures. He was proposing a mechanism that would (1) do > away with base string canonicalization, (2) allow for symmetric and > public keys, and (3) allow for extensibility. > > He got homework from the group to prove the feasibility of his > proposal by showing a couple of implementations. > > In this post, I would like to introduce another improvement of the > OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal > (i.e., it would work both with the signing mechanism in the current > spec, as well as with Brian's signature mechanism). The goal of my > proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore > easier to implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put > together by Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR > access requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens > from the spec. > - stop calling the access tokens "bearer tokens". Call them just > "access tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token > then X, else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something > like this: > > "Servers may require that requests be authenticated by the Client, so > that presentation of the access token alone is not sufficient to > access a Protected Resource. This has several use cases, including, > but not limited to, the following: > > - Non-repudiation: high-security deployments may require that requests > be authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that > access tokens may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure > may strip SSL protection before the request reaches the protected > resource. The protected resource, however, may require end-to-end > integrity. > > If the Server requires that the Client authenticate PR access > requests, then the Client uses the following mechanism to sign their > HTTP requests: [...]" > > Then, we basically drop the old Section 5.3 here (except we use the > client secret instead of the access token secret). Eventually, instead > of Section 5.3, we may have Brian's new signature scheme section here, > which would add the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be > achieved once we have public-key crypto. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------060303080805080200070406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Assume "client secret" means the secret issued by the OAuth AS to its clients, I think this client secret should be used to authenticate clients to the AS only. All other authentication (e.g. against PR) can be based on that trust anchor. I don't mind using the secret to sign AS requests. But here at Deutsche Telekom, we don't want to sign PR requests with the client secret because this requires a strong coupling between AS and PR. Our aim is to operate PR's and AS as independently as possible.

I think the token secret is fine for signing PR requests and proving legitimate token ownership. It is issued after the client has succefully authenticated on the AS and thus transitively asserts its identity to the PR. Moreover, the secret can be passed from AS to PR as (encrypted) part of the access token. So the coupling between AS and PR is loose. That pattern is well-known from Kerberos and proven in the wild.

One could use another PR-specific client-secret to sign PR requests. But that's out of OAuth2-scope, from my point of view.

regards,
Torsten.

Am 21.05.2010 01:39, schrieb Dirk Balfanz:
Hi guys, 

at today's interim meeting, we were discussing Brian Eaton's proposal for OAuth signatures. He was proposing a mechanism that would (1) do away with base string canonicalization, (2) allow for symmetric and public keys, and (3) allow for extensibility. 

He got homework from the group to prove the feasibility of his proposal by showing a couple of implementations. 

In this post, I would like to introduce another improvement of the OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would work both with the signing mechanism in the current spec, as well as with Brian's signature mechanism). The goal of my proposal is twofold:

- it simplifies the spec. It will become more readable and therefore easier to implement
- it separates out the mechanisms for delegated authorization and for integrity protection into two independent pieces, which can be put together by Servers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access requests.

Long version of the proposal:

- remove all references to access tokens that are not bearer tokens from the spec.
- stop calling the access tokens "bearer tokens". Call them just "access tokens". 
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token then X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes something like this:

"Servers may require that requests be authenticated by the Client, so that presentation of the access token alone is not sufficient to access a Protected Resource.  This has several use cases, including, but not limited to, the following:

- Non-repudiation: high-security deployments may require that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that access tokens may leak. 
- End-to-end-integrity: even if SSL _is_ used, network infrastructure may strip SSL protection before the request reaches the protected resource. The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR access requests, then the Client uses the following mechanism to sign their HTTP requests: [...]"

Then, we basically drop the old Section 5.3 here (except we use the client secret instead of the access token secret). Eventually, instead of Section 5.3, we may have Brian's new signature scheme section here, which would add the option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only be achieved once we have public-key crypto.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------060303080805080200070406-- From peaceable_whale@hotmail.com Sat May 22 02:34:53 2010 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 D19823A6C36 for ; Sat, 22 May 2010 02:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 7RbYLlB92Z09 for ; Sat, 22 May 2010 02:34:52 -0700 (PDT) Received: from col0-omc1-s10.col0.hotmail.com (col0-omc1-s10.col0.hotmail.com [65.55.34.20]) by core3.amsl.com (Postfix) with ESMTP id B97A83A6C33 for ; Sat, 22 May 2010 02:34:52 -0700 (PDT) Received: from COL122-DS8 ([65.55.34.7]) by col0-omc1-s10.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 May 2010 02:32:34 -0700 X-Originating-IP: [119.247.132.253] X-Originating-Email: [peaceable_whale@hotmail.com] Message-ID: From: "Franklin Tse" To: Date: Sat, 22 May 2010 17:32:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-OriginalArrivalTime: 22 May 2010 09:32:34.0601 (UTC) FILETIME=[B59CD990:01CAF991] Subject: [OAUTH-WG] Some editorial issues in draft-ietf-oauth-v2-05 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, 22 May 2010 09:35:45 -0000 SGVsbG8sDQoNCkkgbm90aWNlZCBzb21lIGVkaXRvcmlhbCBpc3N1ZXMgaW4gZHJhZnQtaWV0Zi1v YXV0aC12Mi0wNSBhbmQgSSBob3BlIHRoZXkgY2FuIGJlIGZpeGVkIGluIHRoZSBuZXh0IGRyYWZ0 IDopDQoNCjEuIFNlY3Rpb24gMiwgTGFzdCBwYXJhZ3JhcGg6DQoNCiAgICAiVGhpcyBzcGVjaWZp Y2F0aW9uIGRlZmluZXMgdGhlIHVzZSBvZiBPQXV0aCBvdmVyIEhUVFAgW1JGQzI2MTZdIChvciBI VFRQIG92ZXIgVExTIDEuMCBhcyBkZWZpbmVkIGJ5IFtSRkMyODE4XS4iDQoNCkEgY2xvc2luZyBi cmFja2V0IGlzIG1pc3NpbmcgYWZ0ZXIgIltSRkMyODE4XSIuDQoNCjIuIFNlY3Rpb24gMi4xOg0K DQpUaGUgZGVzY3JpcHRpb24gb2YgImJlYXJlciB0b2tlbiIgd2FzIHBsYWNlZCBvbiB0aGUgc2Ft ZSBsaW5lLiBJdCBzaG91bGQgYmUgb24gdGhlIG5leHQgbGluZS4gSWYgdGhpcyBpcyBjYXVzZWQg YnkgcGFnZS1icmVhayBjb25zdHJhaW50LCBwZXJoYXBzIHRoZSBkZXNjcmlwdGlvbiBvZiAiZW5k LXVzZXIiIHNob3VsZCBiZSBvbiB0aGUgc2FtZSBsaW5lIGFzIGl0IGlzIHRoZSBzaG9ydGVzdC4N Cg0KMy4gVGhlIHVzZSBvZiB0aGUgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIg Y29udGVudCB0eXBlIGluIHJlcXVlc3RzDQoNCkkgbm90aWNlZCB0aGF0IGFsbCBleGFtcGxlcyBv ZiBjbGllbnQgcmVxdWVzdHMgYXJlIGRvbmUgd2l0aCBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVy bGVuY29kZWQgY29udGVudCBhbmQgSSBhc3N1bWUgdGhhdCBhdXRob3JpemF0aW9uIHNlcnZlcnMg T05MWSBhY2NlcHQgcmVxdWVzdHMgYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIGNv bnRlbnQuIEhvd2V2ZXIsIHRoaXMgc2VlbXMgbm90IHdyaXR0ZW4gZXhwbGljaXRseSBvciBjbGVh cmx5IGluIHRoZSBzcGVjaWZpY2F0aW9uLiBXaXRoIHJlc3BvbnNlIGZvcm1hdCBjYW4gYmUgaW4g SlNPTiBvciBYTUwgaW4gYWRkaXRpb24gdG8gZm9ybSwgY29uZnVzaW9uIG1heSBiZSBjYXVzZWQu DQoNCjQuIFRoZSB1c2Ugb2YgW1czQy5SRUMtaHRtbDQwLTE5OTgwNDI0XToNCg0KVGhlIEhUTUwg NC4wIFNwZWNpZmljYXRpb24sIGh0dHA6Ly93d3cudzMub3JnL1RSLzE5OTgvUkVDLWh0bWw0MC0x OTk4MDQyNCwgYXBwZWFycyB0byBiZSBvYnNvbGV0ZSBieSB0aGUgSFRNTCA0LjAxIFNwZWNpZmlj YXRpb24gYXQgaHR0cDovL3d3dy53My5vcmcvVFIvMTk5OS9SRUMtaHRtbDQwMS0xOTk5MTIyNC8u IEkgdGhpbmsgYWxsIHJlZmVyZW5jZXMgdG8gSFRNTCA0LjAgc2hvdWxkIGJlIHVwZGF0ZWQgdG8g dXNlIEhUTUwgNC4wMS4gVGhlIGRyYWZ0IG1heSBhbHNvIHBvaW50IG91dCB0aGF0IHRoZSBkZWZp bml0aW9uIG9mIGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCBpcyBsb2NhdGVkIGlu IFNlY3Rpb24gMTcuMTMuNC4xIG9mIFtXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjRdLg0KDQpBbiBl eGFtcGxlIGF0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5vdHRpbmdoYW0taHR0 cC1saW5rLWhlYWRlci0xMCNzZWN0aW9uLTkuMQ0KDQpSZWdhcmRzLA0KRnJhbmtsaW4gVHNlIA== From jricher@mitre.org Sat May 22 05:08:45 2010 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 E76913A6CC2 for ; Sat, 22 May 2010 05:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_50=0.001, 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 fz5N1q5lhpq1 for ; Sat, 22 May 2010 05:08:44 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id B78023A6CB2 for ; Sat, 22 May 2010 05:08:44 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4LIUiV2014949 for ; Fri, 21 May 2010 14:30:44 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4LIUi5F014942; Fri, 21 May 2010 14:30:44 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 21 May 2010 14:30:44 -0400 From: "Richer, Justin P." To: Dirk Balfanz , OAuth WG Date: Fri, 21 May 2010 14:27:24 -0400 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr4dbWDj+nMDy6TTqWPCApNuWCL5gAnYzSe Message-ID: References: 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 Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sat, 22 May 2010 12:08:46 -0000 I have a slightly more radical proposal. What if we factor out the signed t= oken use case into a parallel spec? The OAuth 2.0 Signed Token spec, given = the same attention by the group and all that like Eran was talking about ye= sterday. What this would take is taking out all reference to signing and ma= king core OAuth just about bare tokens, then have a separate spec that deta= ils what to call your shared secret parameters, how to get them, and how to= sign with them. This makes the core spec a lot simpler (as detailed below)= but makes the overall use case of using signed tokens more complicated to = follow, as it'd be split in two. -- justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk Bal= fanz [balfanz@google.com] Sent: Thursday, May 20, 2010 7:39 PM To: OAuth WG Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Hi guys, at today's interim meeting, we were discussing Brian Eaton's proposal for O= Auth signatures. He was proposing a mechanism that would (1) do away with b= ase string canonicalization, (2) allow for symmetric and public keys, and (= 3) allow for extensibility. He got homework from the group to prove the feasibility of his proposal by = showing a couple of implementations. In this post, I would like to introduce another improvement of the OAuth 2 = signing mechanism, one which is orthogonal to Brian's proposal (i.e., it wo= uld work both with the signing mechanism in the current spec, as well as wi= th Brian's signature mechanism). The goal of my proposal is twofold: - it simplifies the spec. It will become more readable and therefore easier= to implement - it separates out the mechanisms for delegated authorization and for integ= rity protection into two independent pieces, which can be put together by S= ervers and/or Clients like LEGO blocks. Summary: - use the client secret instead of the token secret for signing PR access r= equests. Long version of the proposal: - remove all references to access tokens that are not bearer tokens from th= e spec. - stop calling the access tokens "bearer tokens". Call them just "access to= kens". - remove all references to token secrets from the spec - remove all parts of the spec that are of the kind "if bearer_token then X= , else Y", and replace them with X. - delete section 5.3 - add a section called "Request Authentication" that goes something like th= is: "Servers may require that requests be authenticated by the Client, so that = presentation of the access token alone is not sufficient to access a Protec= ted Resource. This has several use cases, including, but not limited to, t= he following: - Non-repudiation: high-security deployments may require that requests be a= uthenticated (signed) in a non-repudiateable way[1] - Access to protected resources is not protected by SSL, so that access tok= ens may leak. - End-to-end-integrity: even if SSL _is_ used, network infrastructure may s= trip SSL protection before the request reaches the protected resource. The = protected resource, however, may require end-to-end integrity. If the Server requires that the Client authenticate PR access requests, the= n the Client uses the following mechanism to sign their HTTP requests: [...= ]" Then, we basically drop the old Section 5.3 here (except we use the client = secret instead of the access token secret). Eventually, instead of Section = 5.3, we may have Brian's new signature scheme section here, which would add= the option of public-key crypto[1], etc. What do you guys think? Dirk. [1] Technically speaking, the goal of non-repudiation can only be achieved = once we have public-key crypto. From mscurtescu@google.com Sat May 22 11:34:46 2010 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 21D6D3A6D86 for ; Sat, 22 May 2010 11:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_40=-0.185, 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 TZUbL2hfCCei for ; Sat, 22 May 2010 11:34:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id F25803A6D84 for ; Sat, 22 May 2010 11:34:44 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o4MIYZJm012273 for ; Sat, 22 May 2010 11:34:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274553275; bh=9QaVAFSC239Ka32c1QboQh37vjA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=HEn8V3VtrzVRRy4ufSRmAwtakDEp9HIrTQLnc0ujG0WPD0NrfDjev/mqTrQqyV3kt +PEkbvh/J6ZlCy0NdVoqw== 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:content-transfer-encoding:x-system-of-record; b=LuEqV5ht2k0qIfUr9mH2baCO4PM0JlbZ4kSoX4L6UiLeoIsbgZFSVjPzjvazLBLl9 jyD4ahDc7HM0C27SIJ2+Q== Received: from pwj4 (pwj4.prod.google.com [10.241.219.68]) by wpaz21.hot.corp.google.com with ESMTP id o4MIYX5t031377 for ; Sat, 22 May 2010 11:34:34 -0700 Received: by pwj4 with SMTP id 4so235618pwj.8 for ; Sat, 22 May 2010 11:34:33 -0700 (PDT) Received: by 10.140.251.8 with SMTP id y8mr2451003rvh.231.1274553273206; Sat, 22 May 2010 11:34:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Sat, 22 May 2010 11:34:13 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Sat, 22 May 2010 11:34:13 -0700 Message-ID: To: Brian Eaton 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: make it possible to get a verification code in the user-agent flow 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, 22 May 2010 18:34:46 -0000 On Fri, May 21, 2010 at 3:30 PM, Brian Eaton wrote: > So maybe the user-agent flow should *never* return a refresh token on > the URL. =A0Instead, it should return an access token, plus an optional > verification code. How is this verification code used after that? I assume it is passed down from the client JavaScript to the client web server, right? The client JavaScript still cannot get fresh access tokens without an immediate call, so the verification code is no help there. Is the only optimization the fact that the client web server does not have to send the user for a separate approval? If so, aren't immediate calls solving this already? Marius From eran@hueniverse.com Sat May 22 23:07:40 2010 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 BC2F63A6AAE for ; Sat, 22 May 2010 23:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_50=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 tWk3iQHZggBm for ; Sat, 22 May 2010 23:07: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 AA2573A6AAA for ; Sat, 22 May 2010 23:07:39 -0700 (PDT) Received: (qmail 23856 invoked from network); 23 May 2010 06:07:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 May 2010 06:07:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 22 May 2010 23:07:32 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sat, 22 May 2010 23:07:05 -0700 Thread-Topic: 'immediate' without identity Thread-Index: Acr6PitAPMuFteLZRAaTwHyjgPLNNw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ZVk= qiM= AHqz AfJq AwHq ClUP ERuM FMJq GTrM GWk2 GpmJ GrHA IQ9w JXLh Jgcb LCSB; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {4E3E26D0-232B-4E00-8064-2A0328D79709}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Sun, 23 May 2010 06:07:05 GMT; JwBpAG0AbQBlAGQAaQBhAHQAZQAnACAAdwBpAHQAaABvAHUAdAAgAGkAZABlAG4AdABpAHQAeQA= x-cr-puzzleid: {4E3E26D0-232B-4E00-8064-2A0328D79709} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] 'immediate' without identity 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, 23 May 2010 06:07:40 -0000 Are there use cases for the 'immediate' parameter where a companion paramet= er for identity (e.g. 'username') is not needed or required? The purpose of= the 'immediate' parameter is for the authorization server to authenticate = the end user via some automatic means (usually a cookie) and check if an ac= cess token was already issued for that end user / client identifier combina= tion. This parameter is only useful when the client is already familiar with the = end user (not the first time it seeks authorization), in which case, it sho= uld pass that information along to make sure the same user is logged into t= he authorization server. If all the use cases require both, we should include both and make one requ= ired if the other is present. EHL From eran@hueniverse.com Sat May 22 23:10:38 2010 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 C0D043A6AB3 for ; Sat, 22 May 2010 23:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 5iMOGyIZl5+0 for ; Sat, 22 May 2010 23:10: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 4856D3A6A72 for ; Sat, 22 May 2010 23:10:37 -0700 (PDT) Received: (qmail 26632 invoked from network); 23 May 2010 06:10:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 May 2010 06:10:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 22 May 2010 23:10:30 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sat, 22 May 2010 23:10:05 -0700 Thread-Topic: Meeting notes request Thread-Index: Acr6PpaO5Q5riyPfRhKmxEsktDbDnQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: iFs= uz4= BQwh BmCF CUSt Cycz DfBH ETbc Erb8 GQk3 H1Hk I35t JQmt JnQ1 Jshn KWRe; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {8F1DC0CB-189F-4A4C-B8FE-FDA45FA89BC6}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Sun, 23 May 2010 06:10:05 GMT;TQBlAGUAdABpAG4AZwAgAG4AbwB0AGUAcwAgAHIAZQBxAHUAZQBzAHQA x-cr-puzzleid: {8F1DC0CB-189F-4A4C-B8FE-FDA45FA89BC6} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Meeting notes request 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, 23 May 2010 06:10:39 -0000 Can someone email me or the list the notes from the meeting? I'd like to ge= t working on the hundred+ spec notes collected. EHL From torsten@lodderstedt.net Sun May 23 02:38:09 2010 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 3FBBC3A6B67 for ; Sun, 23 May 2010 02:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 yrkCNmR8knFn for ; Sun, 23 May 2010 02:38:08 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by core3.amsl.com (Postfix) with ESMTP id 5D9CA3A6B65 for ; Sun, 23 May 2010 02:38:07 -0700 (PDT) Received: from p4fff1313.dip.t-dialin.net ([79.255.19.19] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OG7d9-0003c6-3l; Sun, 23 May 2010 11:37:59 +0200 Message-ID: <4BF8F775.8010603@lodderstedt.net> Date: Sun, 23 May 2010 11:37:57 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 23 May 2010 09:38:09 -0000 > > Are there use cases for the 'immediate' parameter where a companion parameter for identity (e.g. 'username') is not needed or required? The purpose of the 'immediate' parameter is for the authorization server to authenticate the end user via some automatic means (usually a cookie) and check if an access token was already issued for that end user / client identifier combination. > > This parameter is only useful when the client is already familiar with the end user (not the first time it seeks authorization), in which case, it should pass that information along to make sure the same user is logged into the authorization server. > > If all the use cases require both, we should include both and make one required if the other is present. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > How does the client determine the end-user's identity (at the AS) in the initial authorization transaction? Will you introduce a respective response parameter? regards, Torsten. From eran@hueniverse.com Sun May 23 08:41:10 2010 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 DEAF23A6C63 for ; Sun, 23 May 2010 08:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_40=-0.185] 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 6JeQA2q1EXbB for ; Sun, 23 May 2010 08:41:09 -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 BB01F3A6A7D for ; Sun, 23 May 2010 08:41:09 -0700 (PDT) Received: (qmail 25040 invoked from network); 23 May 2010 15:41:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 May 2010 15:41:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 23 May 2010 08:41:01 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sun, 23 May 2010 08:40:39 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr6W6RdV+i0KkbaREGNC9Hkaoo/YwAMepgg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> In-Reply-To: <4BF8F775.8010603@lodderstedt.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 23 May 2010 15:41:11 -0000 Yep, we need to take care of that too. What I'm getting at is that it seems= like we need a better story about identity and 'immediate' in OAuth which = seems to be more about the use cases of the OpenID Connect proposal than th= e OAuth core proposal. However, since these use cases are very important to= many of the participants here in the context of implementing *OAuth* (not = OpenID), we should provide some support. What I'm thinking is to take the 'immediate' parameter out, and write a sim= ple OAuth identity extension spec where it will be included, as well as the= requested 'username' parameter (or whatever we decide to call it). It will= not include any discovery (which is probably going to be another spec), ju= st how to establish and verify identity using OAuth once you know where the= token endpoint is and have client credentials (registered). But back to my original email, what are the use cases for 'immediate' witho= ut identity? EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Sunday, May 23, 2010 2:38 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] 'immediate' without identity >=20 > > > > Are there use cases for the 'immediate' parameter where a companion > parameter for identity (e.g. 'username') is not needed or required? The > purpose of the 'immediate' parameter is for the authorization server to > authenticate the end user via some automatic means (usually a cookie) and > check if an access token was already issued for that end user / client > identifier combination. > > > > This parameter is only useful when the client is already familiar with = the > end user (not the first time it seeks authorization), in which case, it s= hould > pass that information along to make sure the same user is logged into the > authorization server. > > > > If all the use cases require both, we should include both and make one > required if the other is present. > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 > How does the client determine the end-user's identity (at the AS) in the > initial authorization transaction? Will you introduce a respective respon= se > parameter? >=20 > regards, > Torsten. From dick.hardt@gmail.com Sun May 23 15:32:18 2010 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 B3E8B3A6849 for ; Sun, 23 May 2010 15:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 3Pz91G4NU4Uc for ; Sun, 23 May 2010 15:32:17 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A00333A686A for ; Sun, 23 May 2010 15:32:17 -0700 (PDT) Received: by pwi1 with SMTP id 1so1349349pwi.31 for ; Sun, 23 May 2010 15:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type:subject :date:references:to:message-id:mime-version:x-mailer; bh=8tGH38OGOl5bZr0kS0MZM48xnWmQ2b0Y5uzlKh+UY7Y=; b=VtZ/RP0/wSKQenUMOzucgMsdqp9EB2xeat4vjZyzFjcmIM3D+mnf4smV5oDFWPUb2M TFOqSaEisPMyw+qtdU3oQbvAFM4auEKifSEC8MARZCXCzjV2Q+6cwyvLltpCmkYy4hR0 mcpuY8ExEoYvWYpnIEZL2t13JDw8H9732p98Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; b=Qk/HNISn1/2r61NMGcxgLFAaIyze3RaE9wkuieMwcxIoDaXnr7rVR6b6VEMEll3I51 q4sMtNpXyUR9cCr214ahJXKL+IXdrRRLCVzbwW03RYKgjqE7vTZ51E4GU93a0YtrGu9d fN84VTMGllT4A542UnrOIUI+bIw79Kyv5pNLE= Received: by 10.115.114.34 with SMTP id r34mr4115444wam.64.1274653927536; Sun, 23 May 2010 15:32:07 -0700 (PDT) Received: from [10.0.1.8] ([24.130.32.55]) by mx.google.com with ESMTPS id f11sm32605888wai.11.2010.05.23.15.32.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 May 2010 15:32:06 -0700 (PDT) From: Dick Hardt Content-Type: multipart/alternative; boundary=Apple-Mail-30--6017678 Date: Sun, 23 May 2010 15:32:05 -0700 References: To: "OAuth WG (oauth@ietf.org)" Message-Id: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 23 May 2010 22:32:18 -0000 --Apple-Mail-30--6017678 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Frustration devs have with URL encoding. This is the core motivation to = using JSON as the AS response format. -- Dick Begin forwarded message: > From: Andrew Badera > Date: May 23, 2010 2:57:44 PM PDT > To: twitter-development-talk@googlegroups.com > Cc: oauth@googlegroups.com > Subject: [oauth] Re: [twitter-dev] Hard lesson learned > Reply-To: oauth@googlegroups.com >=20 > Miguel, >=20 > This 'lesson' has been 'learned' and re-learned many times over, here = on the Twitter dev list and on the oauth list. One would hope that at = some point this issue would rise to enough prominence to get people in = charge of implementation, and sig participants in general, to do = something about it. The common developer these days is not a super savvy = geek, and even the super savvy geeks among us waste time on this issue, = again and again. >=20 > =E2=88=9E Andy Badera > =E2=88=9E +1 518-641-1280 Google Voice > =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private > =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera >=20 >=20 > On Sun, May 23, 2010 at 5:52 PM, Miguel de Icaza = wrote: > Hello guys, >=20 > Perhaps the most frustrating piece in dealing with the OAuth > configuration is that the twitter OAuth page talks casually about > "urlEncode". You need to "urlEncode this" and "urlEncode that". What > the page does not say is that "urlEncode" is not a standard > urlEncoding system that web developers are used to. The urlEncode > required by OAuth signatures is actually "percent encode" and it is > *required* that you use percent encoding for anything but a small > subset of characters. >=20 > The only characters that do not require percent encoding are: >=20 > unreserved =3D a through z, A through Z, 0 through 9 and '-', '.', = '_', > '~' >=20 > Miguel >=20 >=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@googlegroups.com. > For more options, visit this group at = http://groups.google.com/group/oauth?hl=3Den. --Apple-Mail-30--6017678 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
From: Andrew Badera = <andrew@badera.us>
=
Date: May 23, 2010 = 2:57:44 PM PDT
Subject: [oauth] Re: = [twitter-dev] Hard lesson learned

Miguel,

This 'lesson' has been 'learned' = and re-learned many times over, here on the Twitter dev list and on the = oauth list. One would hope that at some point this issue would rise to = enough prominence to get people in charge of implementation, and sig = participants in general, to do something about it. The common developer = these days is not a super savvy geek, and even the super savvy geeks = among us waste time on this issue, again and again.

=E2=88=9E Andy Badera
=E2=88=9E +1 = 518-641-1280 Google Voice
=E2=88=9E This email is: [ ] bloggable [x] = ask first [ ] private
=E2=88=9E Google me: http://www.googl= e.com/search?q=3Dandrew%20badera


On Sun, May 23, 2010 at 5:52 PM, = Miguel de Icaza <miguel.de.icaza@gmail.com>= ; wrote:
Hello guys,

   Perhaps the most frustrating piece in dealing with the = OAuth
configuration is that the twitter OAuth page talks casually about
"urlEncode".  You need to "urlEncode this" and "urlEncode that". =  What
the page does not say is that "urlEncode" is not a standard
urlEncoding system that web developers are used to.  The = urlEncode
required by OAuth signatures is actually "percent encode" and it is
*required* that you use percent encoding for anything but a small
subset of characters.

   The only characters that do not require percent encoding = are:

unreserved =3D a through z, A through Z, 0 through 9 and  '-', '.', = '_',
'~'

Miguel


--
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@googl= egroups.com.
For more options, visit this group at http://groups.google= .com/group/oauth?hl=3Den.

= --Apple-Mail-30--6017678-- From James.H.Manger@team.telstra.com Sun May 23 17:10:21 2010 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 A77E03A68BC for ; Sun, 23 May 2010 17:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.549 X-Spam-Level: * X-Spam-Status: No, score=1.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU+KraoXxlsG for ; Sun, 23 May 2010 17:10:20 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 7BC673A67B2 for ; Sun, 23 May 2010 17:10:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,287,1272808800"; d="scan'208";a="3046187" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 24 May 2010 10:10:09 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5991"; a="2346566" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipccni.tcif.telstra.com.au with ESMTP; 24 May 2010 10:10:10 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Mon, 24 May 2010 10:10:10 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Mon, 24 May 2010 10:10:10 +1000 Thread-Topic: 'immediate' without identity Thread-Index: Acr6PitAPMuFteLZRAaTwHyjgPLNNwAlRjZA Message-ID: <255B9BB34FB7D647A506DC292726F6E1126397FF6A@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@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] 'immediate' without identity 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, 24 May 2010 00:10:21 -0000 PiBBcmUgdGhlcmUgdXNlIGNhc2VzIGZvciB0aGUgJ2ltbWVkaWF0ZScgcGFyYW1ldGVyIHdoZXJl IGEgY29tcGFuaW9uIHBhcmFtZXRlciBmb3IgaWRlbnRpdHkgKGUuZy4gJ3VzZXJuYW1lJykgaXMg bm90IG5lZWRlZCBvciByZXF1aXJlZD8NCg0KWWVzLiBBIGNsaWVudCBhcHAgbWlnaHQgd2FudCB0 byBvZmZlciBhIGJpdCBvZiBwZXJzb25hbGl6YXRpb24gaWYgaXQgY2FuIHByb3ZpZGUgaXQgc2ls ZW50bHkgKGVnIGJ5IHJlYWRpbmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2Ugb24gYSB2aXNpdG9y4oCZ cyBiZWhhbGYpLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IGl0IGhhcyBpZGVudGlmaWVk IHRoZSB2aXNpdG9yIHlldC4NCg0KSSBkb24ndCB0aGluayBpdCBpcyBuZWNlc3NhcnkgKG9yIGhl bHBmdWwpIHRvIHRpZSAiaW1tZWRpYXRlIiBhbmQgInVzZXJuYW1lIiB0b2dldGhlci4NCg0KDQot LSANCkphbWVzIE1hbmdlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBv YXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQpTZW50OiBTdW5kYXksIDIzIE1heSAyMDEwIDQ6 MDcgUE0NClRvOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0OiBbT0FVVEgtV0dd ICdpbW1lZGlhdGUnIHdpdGhvdXQgaWRlbnRpdHkNCg0KQXJlIHRoZXJlIHVzZSBjYXNlcyBmb3Ig dGhlICdpbW1lZGlhdGUnIHBhcmFtZXRlciB3aGVyZSBhIGNvbXBhbmlvbiBwYXJhbWV0ZXIgZm9y IGlkZW50aXR5IChlLmcuICd1c2VybmFtZScpIGlzIG5vdCBuZWVkZWQgb3IgcmVxdWlyZWQ/IFRo ZSBwdXJwb3NlIG9mIHRoZSAnaW1tZWRpYXRlJyBwYXJhbWV0ZXIgaXMgZm9yIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciB0byBhdXRoZW50aWNhdGUgdGhlIGVuZCB1c2VyIHZpYSBzb21lIGF1dG9t YXRpYyBtZWFucyAodXN1YWxseSBhIGNvb2tpZSkgYW5kIGNoZWNrIGlmIGFuIGFjY2VzcyB0b2tl biB3YXMgYWxyZWFkeSBpc3N1ZWQgZm9yIHRoYXQgZW5kIHVzZXIgLyBjbGllbnQgaWRlbnRpZmll ciBjb21iaW5hdGlvbi4NCg0KVGhpcyBwYXJhbWV0ZXIgaXMgb25seSB1c2VmdWwgd2hlbiB0aGUg Y2xpZW50IGlzIGFscmVhZHkgZmFtaWxpYXIgd2l0aCB0aGUgZW5kIHVzZXIgKG5vdCB0aGUgZmly c3QgdGltZSBpdCBzZWVrcyBhdXRob3JpemF0aW9uKSwgaW4gd2hpY2ggY2FzZSwgaXQgc2hvdWxk IHBhc3MgdGhhdCBpbmZvcm1hdGlvbiBhbG9uZyB0byBtYWtlIHN1cmUgdGhlIHNhbWUgdXNlciBp cyBsb2dnZWQgaW50byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQoNCklmIGFsbCB0aGUgdXNl IGNhc2VzIHJlcXVpcmUgYm90aCwgd2Ugc2hvdWxkIGluY2x1ZGUgYm90aCBhbmQgbWFrZSBvbmUg cmVxdWlyZWQgaWYgdGhlIG90aGVyIGlzIHByZXNlbnQuDQo= From lshepard@facebook.com Sun May 23 19:16:22 2010 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 3A6053A698E for ; Sun, 23 May 2010 19:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 nvpIVOnIL-rF for ; Sun, 23 May 2010 19:16:20 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 052113A6ABB for ; Sun, 23 May 2010 19:14:53 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4O2E1mw015544 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 23 May 2010 19:14:01 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub01.TheFacebook.com (192.168.18.104) with Microsoft SMTP Server (TLS) id 8.2.213.0; Sun, 23 May 2010 19:14:38 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Sun, 23 May 2010 19:14:39 -0700 From: Luke Shepard To: Marius Scurtescu Date: Sun, 23 May 2010 19:13:29 -0700 Thread-Topic: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow Thread-Index: Acr65tymULu0V0HLRQejycK1Jz3TrA== Message-ID: <50876A45-F34B-4C60-89F6-2CFA2EB29B8B@facebook.com> References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-21_02:2010-02-06, 2010-05-21, 2010-05-23 signatures=0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow 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, 24 May 2010 02:16:22 -0000 Brian - I like your proposal. It solves the refresh token problem and the s= erver-side auth in one go. Marius - your proposal would work great in a circumstance where you have st= rong integration between JavaScript and the server, and they are both contr= olled by the same developer. In that case, sure, the developer could pass t= he access token back to the front-end (although you would have a perf hit). However, the case that I'd like to solve (and what I read, Brian wants to a= s well) is like this: - Client includes some Javascript from the relevant service (either Faceboo= k or Twitter @anywhere) - The JS handles the auth flow and does some client-side API calls - for ex= ample, Twitter displays hovercards on each username on the site, or Faceboo= k renders some profile pics - The JS also passes a token down to the server - either in the cookies, or= perhaps directly via an Ajax call - The server can now independently make its own API calls if it wants, and = gets a refresh token or whatever else it wants This allows for a single, general purpose JS library that handles auth for = both client and server applications - which is something that the web serve= r flow by itself does not allow. On May 21, 2010, at 5:50 PM, Marius Scurtescu wrote: > On Fri, May 21, 2010 at 1:46 PM, Brian Ellin wrote: >> Marius, >> I don't understand. Will you elaborate on how specifically that would w= ork? >=20 > Maybe I am missing something, but I was suggesting that the JavaScript > code starts a web server flow at the end of which it has a > verification code. It passes this verification code down to the client > server, the client server swaps it for an access token and a refresh > token and passes the access token to the JavaScript client. When the > access token expires the client JavaScript has two options, ask the > client server for a refresh or do an immediate request to that authz > server. >=20 > If you want that the client server and client JavaScript have tokens > with totally different scopes, then you probably want to send the user > for approval twice. If you just want the client JavaScript to have a > token with a lesser scope (and avoid a second approval), then we > should probably look into down-scoping, which currently is not > supported. >=20 > Would that work? >=20 > Marius >=20 >=20 >> Brian >>=20 >> On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu >> wrote: >>>=20 >>> Why not use the web server flow in this case? >>>=20 >>> I think it should work with un-registered clients as well (no client >>> secret). >>>=20 >>> Marius >>>=20 >>>=20 >>>=20 >>> On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrot= e: >>>> We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter. >>>> @anywhere is a pure javascript layer that developers can drop in to a= dd >>>> Twitter features to their website. With the User-Agent flow, we issue >>>> short >>>> lived access tokens that refresh as they expire. It works great for >>>> in-page >>>> stuff, but many developers are also building server-side integrations >>>> and >>>> would love to have different longer lived access tokens on their serve= r. >>>> This is a common pattern that other connect-like services built on to= p >>>> of >>>> OAuth 2.0 will also find necessary. >>>> So, why not just use the access token issued by the User-Agent flow on >>>> the >>>> client server? Overloading the use of that token is not desirable for= a >>>> couple of reasons: >>>> 1) The client server may not be using ssl, and as such the browser >>>> cannot >>>> securely transfer the access token to the server. >>>> 2) The access token lifetime policy for the User-Agent flow may not >>>> be desirable on the server. Specifically, the server may need a token >>>> that >>>> lasts for, say, two weeks instead of 15 minutes. Additionally, the >>>> token on >>>> the server may have access to different resources that are >>>> not desirable to >>>> transmit to or through the browser. >>>> In short, it is desirable to get two different access tokens from a >>>> single >>>> user authorization triggered by the User-Agent flow. >>>> Proposal: >>>> Make it possible to get a Web Server flow verification code from the >>>> User-Agent client authorization request [1]. Specifically, add a new >>>> optional parameter named "web_server_code" which when set to "true" >>>> returns >>>> a Web Server flow verification "code" field in the User-Agent >>>> authorization >>>> response. The verification code can then be sent by the javascript >>>> layer to >>>> the client server, where it is then used to request an access token [2= ]. >>>> Love to hear your feedback. >>>> 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1 >>>> 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2 >>>> -- >>>> Brian Ellin >>>> Product Manager, Twitter Platform >>>> http://twitter.com/brianellin >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> -- >> Brian Ellin >> Twitter Platform Team >> http://twitter.com/brianellin >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Sun May 23 20:01:38 2010 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 C857A3A6861 for ; Sun, 23 May 2010 20:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 vJCSaEuinogE for ; Sun, 23 May 2010 20:01:38 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 0C7CC3A67D4 for ; Sun, 23 May 2010 20:01:38 -0700 (PDT) Received: by pwi3 with SMTP id 3so5908pwi.31 for ; Sun, 23 May 2010 20:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=lKSs56dS6QHFXUn5wWAeEbKjSXswKhbawgzKoCflssI=; b=gbSgghQIn8fPlA9xVkBH0pl6jrOrJ/aGSyHpQJpWBD1BkiTMPZaDzaVdsjH6CnZlAS BffPOgolXSjuTA0/ItuoUDUNucX+MprRLJBam80Hg3t+R8ft2XP0OERG1inHrjNqJABm tggqNeF//0Eaxf+sMFHCqWbPU3BU+CJyIFY9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=WF+FhOK/+XYb1GBp9/Qjr99gL/X0qscukz0ccIv/D/vXKREHkEqtZ59SHpJQZ6JwJO xFC/G0k6fvRpjc3nfHH8meFyaGV62iMw6JSisp9o37wHF02z/tm5vA/nrx/k61i0l7RJ 1BgfArixIeGPYNwucaX8Ck3PoYEZiYsm1Sgts= Received: by 10.140.247.20 with SMTP id u20mr3549532rvh.122.1274670088104; Sun, 23 May 2010 20:01:28 -0700 (PDT) Received: from [10.0.1.12] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id b10sm2757121rvn.3.2010.05.23.20.01.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 May 2010 20:01:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 23 May 2010 20:01:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 03:01:38 -0000 On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote: > But back to my original email, what are the use cases for 'immediate' = without identity? The client may not have any indication of which user it is, but want to = check if it is a user they already know. They can do a check immediate, = get the token, then make an API call to see which user it is. This would be the case if the user has used the client, but is now on a = different machine or has cleared cookies. -- Dick From eran@hueniverse.com Sun May 23 22:32:35 2010 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 473253A6A42 for ; Sun, 23 May 2010 22:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 CpsAKQYzK8i8 for ; Sun, 23 May 2010 22:32:34 -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 5E3B43A69B7 for ; Sun, 23 May 2010 22:32:34 -0700 (PDT) Received: (qmail 9543 invoked from network); 24 May 2010 05:32:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 May 2010 05:32:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 23 May 2010 22:32:25 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Sun, 23 May 2010 22:32:02 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr67WhUPUCXTi5bQXu7TMziAKOoYAAFOKdA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 05:32:35 -0000 How does this work if there are two people using the same computer and the = other user is the one currently logged into the server? I think the client should be required to tell the server who the user is wh= en using immediate to avoid this problem. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, May 23, 2010 8:01 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] 'immediate' without identity >=20 > On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote: > > But back to my original email, what are the use cases for 'immediate' > without identity? >=20 >=20 > The client may not have any indication of which user it is, but want to c= heck if > it is a user they already know. They can do a check immediate, get the to= ken, > then make an API call to see which user it is. >=20 > This would be the case if the user has used the client, but is now on a > different machine or has cleared cookies. >=20 > -- Dick From dick.hardt@gmail.com Mon May 24 07:34:53 2010 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 844623A6832 for ; Mon, 24 May 2010 07:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 r1eA98PvSN2U for ; Mon, 24 May 2010 07:34:52 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5AADD3A67F2 for ; Mon, 24 May 2010 07:34:52 -0700 (PDT) Received: by fxm12 with SMTP id 12so2542965fxm.31 for ; Mon, 24 May 2010 07:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=9Xm5s42nc5VQ9vINNfZuLfXeV1pfGdNxONGS2tkWcAU=; b=JAP7C0wGTpiN/mNKYk2jjvqEr1gSq/4T8Uf6V46GzvtePfyhnKQrA/qapnS8K8zoCZ jetuh7bP6oDMt0Ew8bVIzc6N8cVqcV7+01nav1ezZVaTs/xa8HmTy3cg3Q9UTrr9KdF8 qTa9UHvWPQc27sjzfwFxKv+D+XnwrE2zWPmNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=EA6uaM7WGItLlf2qyrbLGoFt4AyX7NRdJHiNImfqSMU1ckSQNMJeBoe+SMjEzTm+09 bgaAR1YudssjS4+zFYzSNE5e/XHmUJZqyt4YrMsScD05Cn6uNArq2CUZa0coFBDs3Cvr pZCVyL/5Tm4Ea56c7uPEtz7OMpT6+apcv3R9k= Received: by 10.223.63.17 with SMTP id z17mr4697141fah.66.1274711681224; Mon, 24 May 2010 07:34:41 -0700 (PDT) Received: from [10.0.1.8] ([24.130.32.55]) by mx.google.com with ESMTPS id r25sm19808814fai.11.2010.05.24.07.34.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 May 2010 07:34:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 24 May 2010 07:34:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <045D28A6-9691-4831-ACCE-526F8A551948@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 14:34:53 -0000 You were looking for use cases for immediate without identity.=20 I agree that *if* the client does know the user, then it should tell the = server. Are you saying that if the client does not know the user it = should not use immediate? -- Dick On 2010-05-23, at 10:32 PM, Eran Hammer-Lahav wrote: > How does this work if there are two people using the same computer and = the other user is the one currently logged into the server? >=20 > I think the client should be required to tell the server who the user = is when using immediate to avoid this problem. >=20 > EHL >=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Sunday, May 23, 2010 8:01 PM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] 'immediate' without identity >>=20 >> On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote: >>> But back to my original email, what are the use cases for = 'immediate' >> without identity? >>=20 >>=20 >> The client may not have any indication of which user it is, but want = to check if >> it is a user they already know. They can do a check immediate, get = the token, >> then make an API call to see which user it is. >>=20 >> This would be the case if the user has used the client, but is now on = a >> different machine or has cleared cookies. >>=20 >> -- Dick >=20 From eran@hueniverse.com Mon May 24 08:55:49 2010 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 1BCB33A6B33 for ; Mon, 24 May 2010 08:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 VoxvLENTZI3t for ; Mon, 24 May 2010 08:55:48 -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 215B53A6A92 for ; Mon, 24 May 2010 08:55:48 -0700 (PDT) Received: (qmail 7665 invoked from network); 24 May 2010 15:55:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 May 2010 15:55:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 24 May 2010 08:55:39 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Mon, 24 May 2010 08:55:20 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr7TkCnWa6nCEZ1S92cQEQAytpYagACrRVQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE23@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <045D28A6-9691-4831-ACCE-526F8A551948@gmail.com> In-Reply-To: <045D28A6-9691-4831-ACCE-526F8A551948@gmail.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 15:55:49 -0000 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Monday, May 24, 2010 7:35 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] 'immediate' without identity >=20 > You were looking for use cases for immediate without identity. >=20 > I agree that *if* the client does know the user, then it should tell the = server. > Are you saying that if the client does not know the user it should not us= e > immediate? I think the server should reject an immediate request without a username. O= therwise the server will be giving the client an access token that belongs = to another user. Let me rephrase this: is anyone here planning on supporting 'immediate' for= cases where the client don't know who the user is and just wants access to= whoever last logged into the server? Basically ignoring the chance more t= han one user is using the computer, or trusting the client to then get the = username and ask the user if it is them (after getting an access token for = someone else and making at least one call for their identity). EHL > -- Dick >=20 > On 2010-05-23, at 10:32 PM, Eran Hammer-Lahav wrote: >=20 > > How does this work if there are two people using the same computer and > the other user is the one currently logged into the server? > > > > I think the client should be required to tell the server who the user i= s when > using immediate to avoid this problem. > > > > EHL > > > >> -----Original Message----- > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Sunday, May 23, 2010 8:01 PM > >> To: Eran Hammer-Lahav > >> Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] 'immediate' without identity > >> > >> On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote: > >>> But back to my original email, what are the use cases for 'immediate' > >> without identity? > >> > >> > >> The client may not have any indication of which user it is, but want > >> to check if it is a user they already know. They can do a check > >> immediate, get the token, then make an API call to see which user it i= s. > >> > >> This would be the case if the user has used the client, but is now on > >> a different machine or has cleared cookies. > >> > >> -- Dick > > From lshepard@facebook.com Mon May 24 08:56:49 2010 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 259B23A6B63 for ; Mon, 24 May 2010 08:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 WxLiU-5OVXWa for ; Mon, 24 May 2010 08:56:48 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 75CD13A6A56 for ; Mon, 24 May 2010 08:56:36 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4OFtl3X017025 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 May 2010 08:55:47 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub01.TheFacebook.com (192.168.18.104) with Microsoft SMTP Server (TLS) id 8.2.213.0; Mon, 24 May 2010 08:56:24 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Mon, 24 May 2010 08:56:25 -0700 From: Luke Shepard To: Eran Hammer-Lahav Date: Mon, 24 May 2010 08:56:26 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr7WakCBu6fk527Tyuut2ShAP1YLw== Message-ID: <7EC5CA44-D7FE-49CE-9738-34DA989C1F55@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-24_02:2010-02-06, 2010-05-24, 2010-05-24 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 15:56:49 -0000 +1 to Dick. Eran - this is a very common use case. You can't require the client to know= who the user is ahead of time. If the other user is the one currently logged into the server, then that's = the ID that is returned. It's up to the client to figure out what to do - i= n most cases, they will treat the identity returned from the server as auth= oritative. That's what single sign on is. On May 23, 2010, at 10:32 PM, Eran Hammer-Lahav wrote: > How does this work if there are two people using the same computer and th= e other user is the one currently logged into the server? >=20 > I think the client should be required to tell the server who the user is = when using immediate to avoid this problem. >=20 > EHL >=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Sunday, May 23, 2010 8:01 PM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] 'immediate' without identity >>=20 >> On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote: >>> But back to my original email, what are the use cases for 'immediate' >> without identity? >>=20 >>=20 >> The client may not have any indication of which user it is, but want to = check if >> it is a user they already know. They can do a check immediate, get the t= oken, >> then make an API call to see which user it is. >>=20 >> This would be the case if the user has used the client, but is now on a >> different machine or has cleared cookies. >>=20 >> -- Dick >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon May 24 09:04:27 2010 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 DE3533A6B7B for ; Mon, 24 May 2010 09:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_05=-1.11] 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 80IwZG+pj4rs for ; Mon, 24 May 2010 09:04:26 -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 BB90C3A6B33 for ; Mon, 24 May 2010 09:04:26 -0700 (PDT) Received: (qmail 20740 invoked from network); 24 May 2010 16:04:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 May 2010 16:04:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 24 May 2010 09:04:13 -0700 From: Eran Hammer-Lahav To: Luke Shepard Date: Mon, 24 May 2010 09:03:53 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr7WakCBu6fk527Tyuut2ShAP1YLwAAC8+g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE2A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7EC5CA44-D7FE-49CE-9738-34DA989C1F55@facebook.com> In-Reply-To: <7EC5CA44-D7FE-49CE-9738-34DA989C1F55@facebook.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 16:04:28 -0000 Seems like bad server policy to me. By limiting immediate mode to times whe= n the client knows who the user is, the server keeps control over when to a= utomatically issue access tokens to clients. After all, the server can use = immediate mode even when not asked for. The scenario you are talking about is the rare case of a user using a clien= t for the first time on a given computer. This doesn't happen often. I am not suggesting that the spec will mandate usernames (thought I would n= ever write a server allowing immediate without a username). I am simply ask= ing if there are use cases where the two are completely unrelated. That is,= unrelated enough to live in separate specifications (since the username/id= entity part is going to live elsewhere). BTW, single sign on is all about identity, even when implicit. You are sugg= esting a single sign on system in which no one cares if the same identity i= s maintained across applications. Odd. EHL > -----Original Message----- > From: Luke Shepard [mailto:lshepard@facebook.com] > Sent: Monday, May 24, 2010 8:56 AM > To: Eran Hammer-Lahav > Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] 'immediate' without identity >=20 > +1 to Dick. >=20 > Eran - this is a very common use case. You can't require the client to kn= ow > who the user is ahead of time. >=20 > If the other user is the one currently logged into the server, then that'= s the > ID that is returned. It's up to the client to figure out what to do - in = most > cases, they will treat the identity returned from the server as authorita= tive. > That's what single sign on is. >=20 > On May 23, 2010, at 10:32 PM, Eran Hammer-Lahav wrote: >=20 > > How does this work if there are two people using the same computer and > the other user is the one currently logged into the server? > > > > I think the client should be required to tell the server who the user i= s when > using immediate to avoid this problem. > > > > EHL > > > >> -----Original Message----- > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Sunday, May 23, 2010 8:01 PM > >> To: Eran Hammer-Lahav > >> Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] 'immediate' without identity > >> > >> On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote: > >>> But back to my original email, what are the use cases for 'immediate' > >> without identity? > >> > >> > >> The client may not have any indication of which user it is, but want > >> to check if it is a user they already know. They can do a check > >> immediate, get the token, then make an API call to see which user it i= s. > >> > >> This would be the case if the user has used the client, but is now on > >> a different machine or has cleared cookies. > >> > >> -- Dick > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From balfanz@google.com Mon May 24 09:07:55 2010 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 3EBAA3A6B63 for ; Mon, 24 May 2010 09:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.469 X-Spam-Level: X-Spam-Status: No, score=-103.469 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, 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 OPFPeTHXbl85 for ; Mon, 24 May 2010 09:07:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 62D743A6BF2 for ; Mon, 24 May 2010 09:07:45 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o4OG7ZoF005675 for ; Mon, 24 May 2010 09:07:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274717256; bh=bu4EQYEZGi7+6Go20qtqScrxHac=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hdYcb8qWCshXMGmwSA+an/kLOE71o/6Zc9/WujvYxcAMFxdV8710yEEyGH2THxbwJ FLlMzG5ioZgyv7nCfw5vQ== 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=Y79OSWgbuoFYYmK4Q06578DLUlVpLila95TWhPUu2WQI+XUmH/2dhvy2lqfTcXE9N VPKXKn7pJumuA92qlbXVA== Received: from gwaa18 (gwaa18.prod.google.com [10.200.27.18]) by hpaq13.eem.corp.google.com with ESMTP id o4OG7Peo013115 for ; Mon, 24 May 2010 09:07:34 -0700 Received: by gwaa18 with SMTP id a18so1790424gwa.23 for ; Mon, 24 May 2010 09:07:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.185.6 with SMTP id cm6mr3950057ibb.72.1274717216936; Mon, 24 May 2010 09:06:56 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Mon, 24 May 2010 09:06:56 -0700 (PDT) In-Reply-To: <4BF79CEB.9020502@lodderstedt.net> References: <4BF79CEB.9020502@lodderstedt.net> Date: Mon, 24 May 2010 09:06:56 -0700 Message-ID: From: Dirk Balfanz To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=0050450171eee79bc80487593ad8 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Mon, 24 May 2010 16:07:55 -0000 --0050450171eee79bc80487593ad8 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 22, 2010 at 1:59 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Assume "client secret" means the secret issued by the OAuth AS to its > clients, I think this client secret should be used to authenticate clients > to the AS only. All other authentication (e.g. against PR) can be based on > that trust anchor. I don't mind using the secret to sign AS requests. But > here at Deutsche Telekom, we don't want to sign PR requests with the client > secret because this requires a strong coupling between AS and PR. Our aim is > to operate PR's and AS as independently as possible. > That's fine - you can use public-key signatures (i.e., the client signs the HTTP request with their private key) or bearer tokens over SSL to achieve that goal. In both cases, the PRs don't need to know a secret shared between the Client and the AS. > I think the token secret is fine for signing PR requests and proving > legitimate token ownership. > Assuming that the token secret is somehow better protected than the token itself, then yes, it is. But as I pointed out, it needlessly complicates the spec, and fails to address certain use cases that people want. > It is issued after the client has succefully authenticated on the AS and > thus transitively asserts its identity to the PR. Moreover, the secret can > be passed from AS to PR as (encrypted) part of the access token. So the > coupling between AS and PR is loose. That pattern is well-known from > Kerberos and proven in the wild. > Kerberos is a different protocol - I would caution against drawing parallels and assuming that we obtain certain properties from Kerberos because we (superficially) follow flows that sort-of look like Kerberos (for starters, we use signatures, they use encryption, but there are other differences). Having said that, the loose coupling between between AS and PR is certainly something that Kerberos also has. Which I don't want to take away. Bearer tokens give you that. Bearer tokens over SSL give you that. We don't need signatures for that. I'm arguing that signatures can give us properties that Kerberos _doesn't_ have, i.e, non-repudiation and end-to-end integrity: In Kerberos, the Service Server can't tell the difference between the Client and the Ticket-Granting Server. The Ticket-Granting Server can't tell the difference between the Client and the Authentication Server. If we ever want to build an LoA2 or LoA3 auth protocol on top of OAuth2, that's not good enough. Dirk. > One could use another PR-specific client-secret to sign PR requests. But > that's out of OAuth2-scope, from my point of view. > > regards, > Torsten. > > Am 21.05.2010 01:39, schrieb Dirk Balfanz: > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away with > base string canonicalization, (2) allow for symmetric and public keys, and > (3) allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal > by showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth > 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it > would work both with the signing mechanism in the current spec, as well as > with Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore > easier to implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put together > by Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from > the spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then > X, else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like > this: > > "Servers may require that requests be authenticated by the Client, so > that presentation of the access token alone is not sufficient to access a > Protected Resource. This has several use cases, including, but not limited > to, the following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access > tokens may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. The > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, > then the Client uses the following mechanism to sign their HTTP requests: > [...]" > > Then, we basically drop the old Section 5.3 here (except we use the > client secret instead of the access token secret). Eventually, instead of > Section 5.3, we may have Brian's new signature scheme section here, which > would add the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be > achieved once we have public-key crypto. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > --0050450171eee79bc80487593ad8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, May 22, 2010 at 1:59 AM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
=20
Assume "client secret" means the secret issued by the OAuth AS to= its clients, I think this client secret should be used to authenticate clients to the AS only. All other authentication (e.g. against PR) can be based on that trust anchor. I don't mind using the secret to sign AS requests. But here at Deutsche Telekom, we don't want to sign PR requests with the client secret because this requires a strong coupling between AS and PR. Our aim is to operate PR's and AS as independently as possible.

That's fine - you can use public-key signatures= (i.e., the client signs the HTTP request with their private key) or bearer= tokens over SSL to achieve that goal. In both cases, the PRs don't nee= d to know a secret shared between the Client and the AS.
=A0
I think the token secret is fine for signing PR requests and p= roving legitimate token ownership.

Assuming = that the token secret is somehow better protected than the token itself, th= en yes, it is. But as I pointed out, it needlessly complicates the spec, an= d fails to address certain use cases that people want.=A0
=A0
It is issued after the client has succefully authenticated on the AS and thus transitively asserts its identity to the PR. Moreover, the secret can be passed from AS to PR as (encrypted) part of the access token. So the coupling between AS and PR is loose. That pattern is well-known from Kerberos and proven in the wild.

Kerberos is a different pro= tocol - I would caution against drawing parallels and assuming that we obta= in certain properties from Kerberos because we (superficially) follow flows= that sort-of look like Kerberos (for starters, we use signatures, they use= encryption, but there are other differences). Having said that, the loose = coupling between between AS and PR is certainly something that Kerberos als= o has. Which I don't want to take away. Bearer tokens give you that. Be= arer tokens over SSL give you that. We don't need signatures for that.= =A0

I'm arguing that signatures can give us properties = that Kerberos _doesn't_ have, i.e, non-repudiation and end-to-end integ= rity: In Kerberos, the Service Server can't tell the difference between= the Client and the Ticket-Granting Server. The Ticket-Granting Server can&= #39;t tell the difference between the Client and the Authentication Server.= If we ever want to build an LoA2 or LoA3 auth protocol on top of OAuth2, t= hat's not good enough.

Dirk.

=A0
One could use an= other PR-specific client-secret to sign PR requests. But that's out of OAuth2-scope, from my point of view.

regards,
Torsten.

Am 21.05.2010 01:39, schrieb Dirk Balfanz:
Hi guys,=A0

at today's interim meeting, we were discussing Brian Eaton's proposal for OAuth signatures. He was proposing a mechanism that would (1) do away with base string canonicalization, (2) allow for symmetric and public keys, and (3) allow for extensibility.=A0

He got homework from the group to prove the feasibility of his proposal by showing a couple of implementations.=A0

In this post, I would like to introduce another improvement of the OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would work both with the signing mechanism in the current spec, as well as with Brian's signature mechanism). The goal of my proposal is twofold:

- it simplifies the spec. It will become more readable and therefore easier to implement
- it separates out the mechanisms for delegated authorization and for integrity protection into two independent pieces, which can be put together by Servers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access requests.

Long version of the proposal:

- remove all references to access tokens that are not bearer tokens from the spec.
- stop calling the access tokens "bearer tokens". Call the= m just "access tokens".=A0
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token then X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes something like this:

"Servers may require that requests be authenticated by the Client, so that presentation of the access token alone is not sufficient to access a Protected Resource. =A0This has several use cases, including, but not limited to, the following:

- Non-repudiation: high-security deployments may require that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that access tokens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure may strip SSL protection before the request reaches the protected resource. The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR access requests, then the Client uses the following mechanism to sign their HTTP requests: [...]"

Then, we basically drop the old Section 5.3 here (except we use the client secret instead of the access token secret). Eventually, instead of Section 5.3, we may have Brian's new signature scheme section here, which would add the option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only be achieved once we have public-key crypto.


_______________________________________________
OAuth mailing list

OAuth=
@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth


--0050450171eee79bc80487593ad8-- From torsten@lodderstedt.net Mon May 24 09:18:02 2010 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 34AE13A69F0 for ; Mon, 24 May 2010 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 IeSISojYqdrB for ; Mon, 24 May 2010 09:18:01 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id DF26A3A6A06 for ; Mon, 24 May 2010 09:17:57 -0700 (PDT) Received: from p4fff13ed.dip.t-dialin.net ([79.255.19.237] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OGaLc-0007vp-Vq for oauth@ietf.org; Mon, 24 May 2010 18:17:49 +0200 Message-ID: <4BFAA6AB.8040809@lodderstedt.net> Date: Mon, 24 May 2010 18:17:47 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 24 May 2010 16:18:02 -0000 How many access tokens can be the result of a single OAuth authorization flow? A recent discussion about OpenID Connect on the OpenId mailing list raised that question and I would like to initiate a discussion on this list. Currently, every flow (and the refresh token request) results in a single access token and (optionally) a single refresh token. I think a single access token might not be enough when it comes to multiple scopes. Let's assume a client wants to access the calendar and contact list of an end-user. Since access to the corresponding resource servers is managed by the same authorization server, the resources are distinguished by different scopes, say "calendar" and "contacts". The client sends a request GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri= https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=calendar%20contacts HTTP/1.1 Host: oauth.example.com and after the authorization flow has been conducted sucessfully, the client's access token request would be answered as follows. HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkKG", "expires_in":3600, "refresh_token":"8xLOxBtZp8" } So the token "SlAV32hkKG" must be good for two different protected resources, "calendar" and "contacts". I think this works if: 1) the token is a handle that can be swoped for user identity and authorization data during service request or 2) it is a self-contained token AND both resources are provided by the same resource server. But what if the authorization server issues self-contained tokens and the resources are hosted on different, independent resource servers? Let's assume the authorization server issues self-contained, signed, and encrypted bearer tokens. Signature and encryption are based on shared secrets between authorization server and resource server. In such a scenario, operational security requires to issue different tokens with different signature values and to encrypt those tokens with different keys. Moreover, the resource servers might need different user attributes and permissions, so even the tokens payload might differ. I believe this scenario will become even more important with the advent of OpenID Connect. With OpenID connect, every client asking for an end-user's OpenID (+user data) and, additionally, authorization for another resource will need at least two tokens under the assumptions given above. In order to support such scenarios, I would propose to return an array of access tokens from every authorization flow and the refresh request. An authorization server should know which resources and scopes are handled by what resource servers and indicate this relation in the access tokens response structure. This structure could be as follows. HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_tokens":[ { "token":"SlAV32hkKG", "scopes":["calendar"], "expires_in":3600}, { "token":"SlAV32hk34", "scopes":["contacts"], "expires_in":7200},], "refresh_token":"8xLOxBtZp8" } The scopes a particular access token is good for are indicated, so a client library is able to choose the right tokens for services requests. Alternatively it might suffice (or be better?) to indicate the sites a token is valid for (proposal of James Manger). It think there is no need for multiple refresh tokens because these tokens are handled by the authorization server only. In case all resources are handled by the same resource server, the result would look like HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_tokens":[{ "token":"SlAV32hkKG", "expires_in":3600},], "refresh_token":"8xLOxBtZp8" } Thoughts? regards, Torsten. From hardjono@mit.edu Mon May 24 09:31:58 2010 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 3C6703A6D05 for ; Mon, 24 May 2010 09:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_50=0.001, UNPARSEABLE_RELAY=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 2vrVpfHFfaaS for ; Mon, 24 May 2010 09:31:57 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 2AC8D3A6C5F for ; Mon, 24 May 2010 09:31:46 -0700 (PDT) X-AuditID: 1209190d-b7bf0ae0000059a7-c2-4bfaa9ea4879 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 7D.34.22951.AE9AAFB4; Mon, 24 May 2010 12:31:38 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4OGVbrT015582; Mon, 24 May 2010 12:31:37 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4OGVZlC019134; Mon, 24 May 2010 12:31:37 -0400 Received: from w92exhub10.exchange.mit.edu (18.7.73.18) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 24 May 2010 12:30:40 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub10.exchange.mit.edu ([18.7.73.18]) with mapi; Mon, 24 May 2010 12:31:28 -0400 From: Thomas Hardjono To: OAuth WG Date: Mon, 24 May 2010 12:31:28 -0400 Thread-Topic: Access token opaqueness question Thread-Index: Acr7TkCnWa6nCEZ1S92cQEQAytpYagACrRVQAADfdHA= Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <045D28A6-9691-4831-ACCE-526F8A551948@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE23@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE23@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 X-Brightmail-Tracker: AAAAAA== Subject: [OAUTH-WG] Access token opaqueness question 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, 24 May 2010 16:31:58 -0000 I'm still a newbie to the OAuth and WRAP discussions, so please bear with m= e. In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is basi= caly an opaque structure to the client, but which can have some "internal s= tructure" (having meaning to the authz server and resource server): ] Access token strings can use any internal structure agreed upon ] between the authorization server and the resource server, but their ] structure is opaque to the client. Since the access token provides ] the client access to the protected resource for the life of the ] access token (or until revoked), the authorization server should ] issue access tokens which expire within an appropriate time, usually ] much shorter than the duration of the access grant. I was wondering how true this is?=20 I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth C= lient need not understand this structure, but could simply pass it down to = the Kerberos-client (in the OS or in the browser). Then within this token (now a Kerberos ticket), the ticket fields would con= tain matching entries (as far as possible) to the OAuth token parameters (e= g. expires_in, token_secret, etc). For the cryptographic tokens (Section 5.3), I would then use the session-ke= y in the ticket to compute he HMAC. Would this work? Any suggestions? /thomas/ From Bill_Keenan@intuit.com Mon May 24 10:05:14 2010 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 5345C3A6D12 for ; Mon, 24 May 2010 10:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.164 X-Spam-Level: X-Spam-Status: No, score=-5.164 tagged_above=-999 required=5 tests=[AWL=-1.165, BAYES_50=0.001, 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 AY2YGsHOpWsj for ; Mon, 24 May 2010 10:05:12 -0700 (PDT) Received: from mail1.intuit.com (mail1.intuit.com [12.149.175.11]) by core3.amsl.com (Postfix) with ESMTP id 3B80C3A6E78 for ; Mon, 24 May 2010 10:04:49 -0700 (PDT) DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:MIME-Version: X-MimeOLE:Content-class:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Return-Path: X-OriginalArrivalTime; b=ipDkF06imKlAvlLBTa6fEz+YMVjhALxkXB36o6IAijDdphPz8PMEKt4k fxQm/kYjfCdgm3+YSCYniBz4tZ5O7i5TImhzLVfnh71TmEPCne9ThWg9h HFlLdEyj4jDtTs3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Bill_Keenan@intuit.com; q=dns/txt; s=default; t=1274720681; x=1306256681; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; z=MIME-Version:=201.0|Content-Transfer-Encoding:=20base64 |Subject:=20RE:=20[OAUTH-WG]=20multiple=20access=20tokens =20from=20a=20single=20authorization=20flow?|Date:=20Mon, =2024=20May=202010=2010:04:37=20-0700|Message-ID:=20<5DEB 74B3E9FA574EAA911DB8167C559E159752@SDGEXEVS12.corp.intuit .net>|In-Reply-To:=20<4BFAA6AB.8040809@lodderstedt.net> |References:=20<4BFAA6AB.8040809@lodderstedt.net>|From: =20"Keenan,=20Bill"=20|To:=20; bh=P+iM/vl43TVphSAl9ZtDsuBIoC/H9R7F5bxRT2wj1JU=; b=aBMM+CagdCDdXuaVn6e3+J4ogub9Ulwk3xDj6Tu4A/8ApI/QqA2Kro1h RC6UD56QCitQkouhsX2gMHsEvmFe3REhtDfW0CDkI+vqixL788BB4ZW4F fromBdZeliGxMrj; X-SBRS: None X-IronPort-AV: E=Sophos;i="4.53,292,1272870000"; d="scan'208";a="224286396" Received: from relay-ex.sd.intuit.com (HELO SDGEXBH03.corp.intuit.net) ([172.17.135.77]) by mail1.sdg.ie.intuit.com with ESMTP; 24 May 2010 10:04:39 -0700 Received: from SDGEXEVS12.corp.intuit.net ([172.17.135.111]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 May 2010 10:04:37 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 24 May 2010 10:04:37 -0700 Message-ID: <5DEB74B3E9FA574EAA911DB8167C559E159752@SDGEXEVS12.corp.intuit.net> In-Reply-To: <4BFAA6AB.8040809@lodderstedt.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr7XKuVIikLhuSuSB20h2vFWcCcfwAAlCJg References: <4BFAA6AB.8040809@lodderstedt.net> From: "Keenan, Bill" To: X-OriginalArrivalTime: 24 May 2010 17:04:37.0582 (UTC) FILETIME=[30FECEE0:01CAFB63] Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 24 May 2010 17:05:14 -0000 VGhhbmtzIFRvcnN0ZW4gZm9yIG1vcmUgb2YgeW91ciBnb29kIHRoaW5raW5nIGFuZCB3cml0ZS11 cC4uLg0KDQpBdCBJbnR1aXQsIHVzaW5nIDEuMGEsIHdlIGRpZCBhbiBleHBlcmltZW50IHdpdGgg b25lIG9mIG91ciBtb2JpbGUgYXBwcyB1c2luZyBtdWx0aXBsZSB0b2tlbnMuIFRoZSBwcm9ncmFt bWluZyBtb2RlbCBvZiBoYXZpbmcgdGhlIGNsaWVudCBtYWludGFpbiBhIG1hcHBpbmcgb2YgdG9r ZW4gdG8gUk9BIGVuZHBvaW50LCBzbyB0aGV5IHVzZWQgdGhlIGNvcnJlY3QgdG9rZW4gdHVybmVk IG91dCB0byBiZSBhIGhlYWRhY2hlLiBXZSBiYWlsZWQgb24gdGhpcywgYW5kIG1vdmVkIHRvIGEg c2luZ2xlIHRva2VuLCBhbmQgdXNlZCBhIG1lY2hhbmlzbSBzZXJ2ZXItc2lkZSB0byBtYW5hZ2Ug dGhlIHByaW5jaXBsZSBvZiBsZWFzdC1wcml2aWxlZ2UuIEFzIGFsbCB0aGUgcmVzb3VyY2VzIHRo ZSBtb2JpbGUgYXBwIG5lZWRlZCB3ZXJlIGhvc3RlZCBieSBJbnR1aXQsIHdlIGhhZCB0aGlzIG9w dGlvbi4gQXMgd2UgZ2V0IHRvIGFwcHMgZG9pbmcgbWFzaHVwcyBvZiBlbnRpdGllcyBmcm9tIG11 bHRpcGxlIGRhdGEgcHJvdmlkZXJzLCBhcHBzIHdpbGwgbmVlZCB0byBtYW5hZ2UgbXVsdGlwbGUg dG9rZW5zLg0KDQpBdCBJbnR1aXQsIHdlIGhhdmUgYmVlbiB3cmVzdGxpbmcgd2l0aCBzY29wZSBm b3Igc2V2ZXJhbCBtb250aHMuIFdpdGggMTAwJ3MgZ29pbmcgdG8gMTAwMCdzIG9mIGVudGl0aWVz LCB3aGljaCBlYWNoIGhhdmUgNCAtIDE1IHZlcmJzLCBleHByZXNzaW5nIHRoZSBzZXQgb2YgZW5k cG9pbnRzLCB3aGljaCBhIHRva2VuIHNob3VsZCBhbGxvdyBhY2Nlc3MgdG8gaXMgY29tcGxpY2F0 ZWQuIEkgZG9uJ3Qgc2VlIGFuIG9wcG9ydHVuaXR5IHRvIG5vcm1hbGl6ZSB0aGUgY29tcGxleGl0 eSwgc28gd2UgYXJlIGFsbCBpbnRlcm9wZXJhYmxlIG9uIHRoZSBjYXJkaW5hbGl0eSBvZiB0b2tl bnMgdG8gdGhlIHByb3RlY3RlZCByZXNvdXJjZXMgYW4gYXBwbGljYXRpb24gbmVlZHMgZnJvbSBh IHNwZWNpZmljIHByb3ZpZGVyLiBJJ2xsIHB1c2ggZm9yIHNpbmdsZSB0b2tlbiBpbiBteSB3b3Js ZDsgb3RoZXJzIHdhbnQgbXVsdGlwbGUgdG9rZW5zIChtYXliZSkuDQoNCkV4cGVyaWVuY2UgcHVz aGVzIG1lIHRvd2FyZHMgcHJvdmlkaW5nIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgYSB3YXkg dG8gc2F5IGV2ZXJ5dGhpbmcgdGhleSBuZWVkLCBhbmQgZ2V0dGluZyBhIHNpbmdsZSB0b2tlbiB0 byB1c2UgaW4gYWNjZXNzaW5nIHRob3NlIGVuZHBvaW50cy4gTXVjaCBvZiBvdXIgYWNjZXNzIGNv bnRyb2wgaXMgYnVpbHQgYXJvdW5kIGFuIFJCQUMsIHNvIGlzc3VpbmcgYSB0b2tlbiB3aXRoIG9u ZSBvciBtb3JlIHJvbGVzIHdvdWxkIHByb3ZpZGUgYWNjZXNzIHRvIGFsbCB0aGUgZW5kcG9pbnRz IGF2YWlsYWJsZSB0byB0aGUgcm9sZShzKS4gVGhlIGRldmVsb3BlciBsZWFybnMsIGZyb20gU0RL IGRvY3VtZW50YXRpb24sIHRoZSByb2xlcyBhbiBBUEkgaXMgYXZhaWxhYmxlIHRvLiBJbiBvdXIg Y2FzZSwgd2UgZG9uJ3Qgd2FudCBkZXZlbG9wZXJzIHVuZGVyc3RhbmRpbmcgaG93IEludHVpdCdz IGRhdGFjZW50ZXJzIGFyZSBvcmdhbml6ZWQsIHNvIHdlIHdvdWxkIG5vdCB3YW50IHRoZW0gZ2V0 dGluZyBtdWx0aXBsZSB0b2tlbnMgYmVjYXVzZSB0aGV5IHRob3VnaHQgdGhleSB3ZXJlIGNyb3Nz aW5nIHNvbWUgYm91bmRhcnkgb2Ygb3VyIGludGVybmFsIGRlcGxveW1lbnQuDQoNClJpZ2h0IG5v dywgbXVsdGlwbGUgdG9rZW5zIGRvZXMgbm90IGhlbHAgbWUuIEkgYW0gc3VyZSBpdCBjb3VsZCBo ZWxwIHNvbWUuIE15IGNhdXRpb24gdG8gdGhvc2UgZ29pbmcgZG93biB0aGUgbXVsdGktdG9rZW4g cGF0aCBpcyBleHBvc2luZyBtb3JlIG9mIHlvdXIgZGVwbG95bWVudCB0aGFuIG5lZWRlZCBieSBo YXZpbmcgZGV2ZWxvcGVycyBnZXQgdG9rZW5zIGZvciBzcGVjaWZpYyBhcmVhcy4NCg0KQmlsbEsN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9yc3RlbiBM b2RkZXJzdGVkdA0KU2VudDogTW9uZGF5LCBNYXkgMjQsIDIwMTAgOToxOCBBTQ0KVG86IE9BdXRo IFdHIChvYXV0aEBpZXRmLm9yZykNClN1YmplY3Q6IFtPQVVUSC1XR10gbXVsdGlwbGUgYWNjZXNz IHRva2VucyBmcm9tIGEgc2luZ2xlIGF1dGhvcml6YXRpb24gZmxvdz8NCg0KSG93IG1hbnkgYWNj ZXNzIHRva2VucyBjYW4gYmUgdGhlIHJlc3VsdCBvZiBhIHNpbmdsZSBPQXV0aCBhdXRob3JpemF0 aW9uIA0KZmxvdz8NCg0KQSByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBPcGVuSUQgQ29ubmVjdCBv biB0aGUgT3BlbklkIG1haWxpbmcgbGlzdCANCnJhaXNlZCB0aGF0IHF1ZXN0aW9uIGFuZCBJIHdv dWxkIGxpa2UgdG8gaW5pdGlhdGUgYSBkaXNjdXNzaW9uIG9uIHRoaXMgDQpsaXN0Lg0KDQpDdXJy ZW50bHksIGV2ZXJ5IGZsb3cgKGFuZCB0aGUgcmVmcmVzaCB0b2tlbiByZXF1ZXN0KSByZXN1bHRz IGluIGEgDQpzaW5nbGUgYWNjZXNzIHRva2VuIGFuZCAob3B0aW9uYWxseSkgYSBzaW5nbGUgcmVm cmVzaCB0b2tlbi4gSSB0aGluayBhIA0Kc2luZ2xlIGFjY2VzcyB0b2tlbiBtaWdodCBub3QgYmUg ZW5vdWdoIHdoZW4gaXQgY29tZXMgdG8gbXVsdGlwbGUgc2NvcGVzLg0KDQpMZXQncyBhc3N1bWUg YSBjbGllbnQgd2FudHMgdG8gYWNjZXNzIHRoZSBjYWxlbmRhciBhbmQgY29udGFjdCBsaXN0IG9m IA0KYW4gZW5kLXVzZXIuIFNpbmNlIGFjY2VzcyB0byB0aGUgY29ycmVzcG9uZGluZyByZXNvdXJj ZSBzZXJ2ZXJzIGlzIA0KbWFuYWdlZCBieSB0aGUgc2FtZSBhdXRob3JpemF0aW9uIHNlcnZlciwg dGhlIHJlc291cmNlcyBhcmUgDQpkaXN0aW5ndWlzaGVkIGJ5IGRpZmZlcmVudCBzY29wZXMsIHNh eSAiY2FsZW5kYXIiIGFuZCAiY29udGFjdHMiLg0KDQpUaGUgY2xpZW50IHNlbmRzIGEgcmVxdWVz dA0KDQogICAgICBHRVQgL2F1dGhvcml6ZT90eXBlPXdlYl9zZXJ2ZXImY2xpZW50X2lkPXM2Qmhk UmtxdDMmcmVkaXJlY3RfdXJpPQ0KICAgICAgICAgIA0KaHR0cHMlM0ElMkYlMkZjbGllbnQlMkVl eGFtcGxlJTJFY29tJTJGY2Imc2NvcGU9Y2FsZW5kYXIlMjBjb250YWN0cyBIVFRQLzEuMQ0KICAg ICAgSG9zdDogb2F1dGguZXhhbXBsZS5jb20NCg0KYW5kIGFmdGVyIHRoZSBhdXRob3JpemF0aW9u IGZsb3cgaGFzIGJlZW4gY29uZHVjdGVkIHN1Y2Vzc2Z1bGx5LCB0aGUgDQpjbGllbnQncyBhY2Nl c3MgdG9rZW4gcmVxdWVzdCB3b3VsZCBiZSBhbnN3ZXJlZCBhcyBmb2xsb3dzLg0KDQogICAgICBI VFRQLzEuMSAyMDAgT0sNCiAgICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbg0KICAg ICAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUNCg0KICAgICAgew0KICAgICAgICAiYWNjZXNzX3Rv a2VuIjoiU2xBVjMyaGtLRyIsDQogICAgICAgICJleHBpcmVzX2luIjozNjAwLA0KICAgICAgICAi cmVmcmVzaF90b2tlbiI6Ijh4TE94QnRacDgiDQogICAgICB9DQoNClNvIHRoZSB0b2tlbiAiU2xB VjMyaGtLRyIgbXVzdCBiZSBnb29kIGZvciB0d28gZGlmZmVyZW50IHByb3RlY3RlZCANCnJlc291 cmNlcywgImNhbGVuZGFyIiBhbmQgImNvbnRhY3RzIi4NCg0KSSB0aGluayB0aGlzIHdvcmtzIGlm Og0KMSkgdGhlIHRva2VuIGlzIGEgaGFuZGxlIHRoYXQgY2FuIGJlIHN3b3BlZCBmb3IgdXNlciBp ZGVudGl0eSBhbmQgDQphdXRob3JpemF0aW9uIGRhdGEgZHVyaW5nIHNlcnZpY2UgcmVxdWVzdCBv cg0KMikgaXQgaXMgYSBzZWxmLWNvbnRhaW5lZCB0b2tlbiBBTkQgYm90aCByZXNvdXJjZXMgYXJl IHByb3ZpZGVkIGJ5IHRoZSANCnNhbWUgcmVzb3VyY2Ugc2VydmVyLg0KDQpCdXQgd2hhdCBpZiB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIHNlbGYtY29udGFpbmVkIHRva2VucyBhbmQg DQp0aGUgcmVzb3VyY2VzIGFyZSBob3N0ZWQgb24gZGlmZmVyZW50LCBpbmRlcGVuZGVudCByZXNv dXJjZSBzZXJ2ZXJzPw0KDQpMZXQncyBhc3N1bWUgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlz c3VlcyBzZWxmLWNvbnRhaW5lZCwgc2lnbmVkLCBhbmQgDQplbmNyeXB0ZWQgYmVhcmVyIHRva2Vu cy4gU2lnbmF0dXJlIGFuZCBlbmNyeXB0aW9uIGFyZSBiYXNlZCBvbiBzaGFyZWQgDQpzZWNyZXRz IGJldHdlZW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlci4gSW4gc3Vj aCBhIA0Kc2NlbmFyaW8sIG9wZXJhdGlvbmFsIHNlY3VyaXR5IHJlcXVpcmVzIHRvIGlzc3VlIGRp ZmZlcmVudCB0b2tlbnMgd2l0aCANCmRpZmZlcmVudCBzaWduYXR1cmUgdmFsdWVzIGFuZCB0byBl bmNyeXB0IHRob3NlIHRva2VucyB3aXRoIGRpZmZlcmVudCANCmtleXMuIE1vcmVvdmVyLCB0aGUg cmVzb3VyY2Ugc2VydmVycyBtaWdodCBuZWVkIGRpZmZlcmVudCB1c2VyIA0KYXR0cmlidXRlcyBh bmQgcGVybWlzc2lvbnMsIHNvIGV2ZW4gdGhlIHRva2VucyBwYXlsb2FkIG1pZ2h0IGRpZmZlci4N Cg0KSSBiZWxpZXZlIHRoaXMgc2NlbmFyaW8gd2lsbCBiZWNvbWUgZXZlbiBtb3JlIGltcG9ydGFu dCB3aXRoIHRoZSBhZHZlbnQgDQpvZiBPcGVuSUQgQ29ubmVjdC4gV2l0aCBPcGVuSUQgY29ubmVj dCwgZXZlcnkgY2xpZW50IGFza2luZyBmb3IgYW4gDQplbmQtdXNlcidzIE9wZW5JRCAoK3VzZXIg ZGF0YSkgYW5kLCBhZGRpdGlvbmFsbHksIGF1dGhvcml6YXRpb24gZm9yIA0KYW5vdGhlciByZXNv dXJjZSB3aWxsIG5lZWQgYXQgbGVhc3QgdHdvIHRva2VucyB1bmRlciB0aGUgYXNzdW1wdGlvbnMg DQpnaXZlbiBhYm92ZS4NCg0KSW4gb3JkZXIgdG8gc3VwcG9ydCBzdWNoIHNjZW5hcmlvcywgSSB3 b3VsZCBwcm9wb3NlIHRvIHJldHVybiBhbiBhcnJheSANCm9mIGFjY2VzcyB0b2tlbnMgZnJvbSBl dmVyeSBhdXRob3JpemF0aW9uIGZsb3cgYW5kIHRoZSByZWZyZXNoIHJlcXVlc3QuIA0KQW4gYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGtub3cgd2hpY2ggcmVzb3VyY2VzIGFuZCBzY29wZXMg YXJlIA0KaGFuZGxlZCBieSB3aGF0IHJlc291cmNlIHNlcnZlcnMgYW5kIGluZGljYXRlIHRoaXMg cmVsYXRpb24gaW4gdGhlIA0KYWNjZXNzIHRva2VucyByZXNwb25zZSBzdHJ1Y3R1cmUuIFRoaXMg c3RydWN0dXJlIGNvdWxkIGJlIGFzIGZvbGxvd3MuDQoNCiAgICAgIEhUVFAvMS4xIDIwMCBPSw0K ICAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uDQogICAgICBDYWNoZS1Db250cm9s OiBuby1zdG9yZQ0KDQogICAgICB7DQogICAgICAgICJhY2Nlc3NfdG9rZW5zIjpbDQogICAgICAg eyAidG9rZW4iOiJTbEFWMzJoa0tHIiwgInNjb3BlcyI6WyJjYWxlbmRhciJdLCAiZXhwaXJlc19p biI6MzYwMH0sDQogICAgICAgeyAidG9rZW4iOiJTbEFWMzJoazM0IiwgInNjb3BlcyI6WyJjb250 YWN0cyJdLCAiZXhwaXJlc19pbiI6NzIwMH0sXSwNCiAgICAgICAgInJlZnJlc2hfdG9rZW4iOiI4 eExPeEJ0WnA4Ig0KICAgICAgfQ0KDQpUaGUgc2NvcGVzIGEgcGFydGljdWxhciBhY2Nlc3MgdG9r ZW4gaXMgZ29vZCBmb3IgYXJlIGluZGljYXRlZCwgc28gYSANCmNsaWVudCBsaWJyYXJ5IGlzIGFi bGUgdG8gY2hvb3NlIHRoZSByaWdodCB0b2tlbnMgZm9yIHNlcnZpY2VzIHJlcXVlc3RzLiANCkFs dGVybmF0aXZlbHkgaXQgbWlnaHQgc3VmZmljZSAob3IgYmUgYmV0dGVyPykgdG8gaW5kaWNhdGUg dGhlIHNpdGVzIGEgDQp0b2tlbiBpcyB2YWxpZCBmb3IgKHByb3Bvc2FsIG9mIEphbWVzIE1hbmdl cikuIEl0IHRoaW5rIHRoZXJlIGlzIG5vIG5lZWQgDQpmb3IgbXVsdGlwbGUgcmVmcmVzaCB0b2tl bnMgYmVjYXVzZSB0aGVzZSB0b2tlbnMgYXJlIGhhbmRsZWQgYnkgdGhlIA0KYXV0aG9yaXphdGlv biBzZXJ2ZXIgb25seS4NCg0KSW4gY2FzZSBhbGwgcmVzb3VyY2VzIGFyZSBoYW5kbGVkIGJ5IHRo ZSBzYW1lIHJlc291cmNlIHNlcnZlciwgdGhlIA0KcmVzdWx0IHdvdWxkIGxvb2sgbGlrZQ0KDQog ICAgICBIVFRQLzEuMSAyMDAgT0sNCiAgICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNv bg0KICAgICAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUNCg0KICAgICAgew0KICAgICAgICAgImFj Y2Vzc190b2tlbnMiOlt7ICJ0b2tlbiI6IlNsQVYzMmhrS0ciLCAiZXhwaXJlc19pbiI6MzYwMH0s XSwNCiAgICAgICAgInJlZnJlc2hfdG9rZW4iOiI4eExPeEJ0WnA4Ig0KICAgICAgfQ0KDQpUaG91 Z2h0cz8NCg0KcmVnYXJkcywNClRvcnN0ZW4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From dick.hardt@gmail.com Mon May 24 11:23:13 2010 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 26ED53A7079 for ; Mon, 24 May 2010 11:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 NXmWeUWMYX+Y for ; Mon, 24 May 2010 11:23:11 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 36D643A6FAF for ; Mon, 24 May 2010 11:18:36 -0700 (PDT) Received: by pwi3 with SMTP id 3so326660pwi.31 for ; Mon, 24 May 2010 11:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=/2N98BLtE8qP/vnPvlic1Qy8tzIEBNRhOaeJqgBGSc8=; b=e9Bzpzm9Nawc3FVfXiUW1QgFdnsrM0fCjT64b17Jrm39VKpZmiTnlBudZXrpl8vLR+ Y55DcFVIQC+OEDVbSPLy+VkN79pI1ycfUSJwAGt5siC+As4++r0Hnlw/gKIw1dPRH/6y 4cQ5ka3v3amTZnsIVPXmJ406BJyNy28CB5EC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=BGZFeqgRdiBi01qG3em9J2QXC0VyL5Hw0r6FinkP44MhF7dcxNrzjSYmpX+Kia2mRY 1+pHn5+9wweWuWXYJ5SXuKP3NQ7Rdy6VX0Ujv026zMtdxTfQ+Cl4++UegiDgiN4iAnQ1 QRO4PklRrfqq7X82a2vIyyJu3QmbV+fm5m1VQ= Received: by 10.140.55.8 with SMTP id d8mr4350910rva.216.1274725086323; Mon, 24 May 2010 11:18:06 -0700 (PDT) Received: from [10.0.1.8] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id b1sm897766rvn.14.2010.05.24.11.18.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 May 2010 11:18:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE23@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 24 May 2010 11:18:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <262F30C0-D23B-4486-83FE-90DD87EB7329@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <045D28A6-9691-4831-ACCE-526F8A551948@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE23@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 18:23:13 -0000 On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote: >=20 >=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Monday, May 24, 2010 7:35 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] 'immediate' without identity >>=20 >> You were looking for use cases for immediate without identity. >>=20 >> I agree that *if* the client does know the user, then it should tell = the server. >> Are you saying that if the client does not know the user it should = not use >> immediate? >=20 > I think the server should reject an immediate request without a = username. Otherwise the server will be giving the client an access token = that belongs to another user. Now I understand. I agree. -- Dick From lshepard@facebook.com Mon May 24 12:44:48 2010 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 AF7273A6B79 for ; Mon, 24 May 2010 12:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 CcQd9fmeIdeL for ; Mon, 24 May 2010 12:44:47 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 9150E3A6F8B for ; Mon, 24 May 2010 12:44:47 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4OJiGPH020007 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 May 2010 12:44:16 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Mon, 24 May 2010 12:44:36 -0700 From: Luke Shepard To: Dick Hardt Date: Mon, 24 May 2010 12:44:38 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr7eYnIafuy+UGKQiayN31iyjqyLQ== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <045D28A6-9691-4831-ACCE-526F8A551948@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE23@P3PW5EX1MB01.EX1.SECURESERVER.NET> <262F30C0-D23B-4486-83FE-90DD87EB7329@gmail.com> In-Reply-To: <262F30C0-D23B-4486-83FE-90DD87EB7329@gmail.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-24_02:2010-02-06, 2010-05-24, 2010-05-24 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 19:44:48 -0000 Suppose the client does not have a username - say, because the cookie expir= ed. What is the appropriate behavior? Would you require the client to spawn a popup or redirect to a full page au= th every time a user revisits their site? This doesn't make sense. Under what circumstances do you think the client gives an access token that= belongs to another user? If the user is logged into the service provider, = then they can get that access token anyway by just visiting the service pro= vider ... On May 24, 2010, at 11:18 AM, Dick Hardt wrote: >=20 > On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote: >=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>> Sent: Monday, May 24, 2010 7:35 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] 'immediate' without identity >>>=20 >>> You were looking for use cases for immediate without identity. >>>=20 >>> I agree that *if* the client does know the user, then it should tell th= e server. >>> Are you saying that if the client does not know the user it should not = use >>> immediate? >>=20 >> I think the server should reject an immediate request without a username= . Otherwise the server will be giving the client an access token that belon= gs to another user. >=20 > Now I understand. I agree. >=20 > -- Dick >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon May 24 12:51:49 2010 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 3DBD33A68F5 for ; Mon, 24 May 2010 12:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6] 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 yGgB2zXMu2aN for ; Mon, 24 May 2010 12:51:48 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id AB3383A6B79 for ; Mon, 24 May 2010 12:51:47 -0700 (PDT) Received: from p4fff13ed.dip.t-dialin.net ([79.255.19.237] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OGdgY-00052Q-4e; Mon, 24 May 2010 21:51:38 +0200 Message-ID: <4BFAD8C8.7060703@lodderstedt.net> Date: Mon, 24 May 2010 21:51:36 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 19:51:49 -0000 > > Yep, we need to take care of that too. What I'm getting at is that it seems like we need a better story about identity and 'immediate' in OAuth which seems to be more about the use cases of the OpenID Connect proposal than the OAuth core proposal. However, since these use cases are very important to many of the participants here in the context of implementing *OAuth* (not OpenID), we should provide some support. > > What I'm thinking is to take the 'immediate' parameter out, and write a simple OAuth identity extension spec where it will be included, as well as the requested 'username' parameter (or whatever we decide to call it). It will not include any discovery (which is probably going to be another spec), just how to establish and verify identity using OAuth once you know where the token endpoint is and have client credentials (registered). > > But back to my original email, what are the use cases for 'immediate' without identity? > As James pointed out, a client can generally use the immediate parameter to offer "a bit of personalization if it can provide it silently". Having that in mind, I see the following scenarios: Classical OAuth A classical OAuth client would probably have its own user management and use OAuth to get access to a end-users resources on other sites. It does not need to know (and probably shall not know) the user's identity on the other sites. The immediate parameter could be used w/o identity in the following situations: - the client does not want to store refresh tokens and tries to aquire an access token after login - the authz server does not issue refresh tokens, but stores end-user authorizations and issues access tokens based on it - the client is authorized automatically by a security policy (company internal applications) OpenID Connect In this context, the OAuth services is used to obatin the end-user's identity. So how should the client know the identity upfront? This would be comparable to an OpenID RP knowing the user id before issuing the authentication request. The immediate parameter works the same way as the openid.mode "checkid_immediate". Typically the client will try to acquire an end-users identity, if already established, in order to (optionally) personalize the site. We do this for several portal sites (w/ our proprietary SSO protocol). If this fails and the end-user enters a protected region of the sites afterwards, user authentication is enforced by ommiting the immediate parameter. Yes, if two users use the same computer, the "wrong" identity could be used here. But that's, from my point of view, a characteristics of single sign on. That's why single sign-on should be accompanied by single logout. My conclusion: There are several use cases where the client does not need (or is unable) to know the user's identity but could use the immediate mode. In contrast, I think the username is useful in several situations w/o the immediate mode. For example, if the client already possesses a token for a particular user and wants to acquire another token for another resource of that particular user. The client could ensure the users identity match by passing the username to the authorization flow. regards, Torsten. > EHL > > > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Sunday, May 23, 2010 2:38 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] 'immediate' without identity >> >> >>> Are there use cases for the 'immediate' parameter where a companion >>> >> parameter for identity (e.g. 'username') is not needed or required? The >> purpose of the 'immediate' parameter is for the authorization server to >> authenticate the end user via some automatic means (usually a cookie) and >> check if an access token was already issued for that end user / client >> identifier combination. >> >>> This parameter is only useful when the client is already familiar with the >>> >> end user (not the first time it seeks authorization), in which case, it should >> pass that information along to make sure the same user is logged into the >> authorization server. >> >>> If all the use cases require both, we should include both and make one >>> >> required if the other is present. >> >>> EHL >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> How does the client determine the end-user's identity (at the AS) in the >> initial authorization transaction? Will you introduce a respective response >> parameter? >> >> regards, >> Torsten. >> > From eran@hueniverse.com Mon May 24 13:05:30 2010 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 DA4113A6CC9 for ; Mon, 24 May 2010 13:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_40=-0.185, 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 1KnDhQl-SHbl for ; Mon, 24 May 2010 13:05:19 -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 6A1563A6C29 for ; Mon, 24 May 2010 13:05:19 -0700 (PDT) Received: (qmail 9598 invoked from network); 24 May 2010 20:05:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 May 2010 20:05:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 24 May 2010 13:05:06 -0700 From: Eran Hammer-Lahav To: Luke Shepard , Dick Hardt Date: Mon, 24 May 2010 13:05:04 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr7eYnIafuy+UGKQiayN31iyjqyLQAAtxBg Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8202A0034854eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 24 May 2010 20:05:31 -0000 --_000_C8202A0034854eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am more interested in how you plan to address the (long term) security an= d privacy issue: who is responsible to prevent one user in getting an acces= s token for another in a shared computer environment. As long as the user g= oes to facebook.com, you show they who is logged in clearly, so if it is no= t them, they can log out. But using immediate without a username, it sounds to me like you expect the= client to do the right thing. Is this how you plan to address this? Ask th= e client to find out whose access token it got, display it to the user, and= allow them to correct this? Especially given that at this point the client= account is already "paired" with the access token. EHL On 5/24/10 12:44 PM, "Luke Shepard" wrote: Suppose the client does not have a username - say, because the cookie expir= ed. What is the appropriate behavior? Would you require the client to spawn a popup or redirect to a full page au= th every time a user revisits their site? This doesn't make sense. Under what circumstances do you think the client gives an access token that= belongs to another user? If the user is logged into the service provider, = then they can get that access token anyway by just visiting the service pro= vider ... On May 24, 2010, at 11:18 AM, Dick Hardt wrote: > > On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote: > >> >> >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>> Sent: Monday, May 24, 2010 7:35 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] 'immediate' without identity >>> >>> You were looking for use cases for immediate without identity. >>> >>> I agree that *if* the client does know the user, then it should tell th= e server. >>> Are you saying that if the client does not know the user it should not = use >>> immediate? >> >> I think the server should reject an immediate request without a username= . Otherwise the server will be giving the client an access token that belon= gs to another user. > > Now I understand. I agree. > > -- Dick > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_C8202A0034854eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] 'immediate' without identity I am more interested in how you plan to address the (long term) secur= ity and privacy issue: who is responsible to prevent one user in getting an= access token for another in a shared computer environment. As long as the = user goes to facebook.com, you show they who is logged in clearly, so if it= is not them, they can log out.

But using immediate without a username, it sounds to me like you expect the= client to do the right thing. Is this how you plan to address this? Ask th= e client to find out whose access token it got, display it to the user, and= allow them to correct this? Especially given that at this point the client= account is already “paired” with the access token.

EHL


On 5/24/10 12:44 PM, "Luke Shepard" <lshepard@facebook.com> wrote:

Suppose the client does not have a username= - say, because the cookie expired. What is the appropriate behavior?

Would you require the client to spawn a popup or redirect to a full page au= th every time a user revisits their site? This doesn't make sense.

Under what circumstances do you think the client gives an access token that= belongs to another user? If the user is logged into the service provider, = then they can get that access token anyway by just visiting the service pro= vider ...

On May 24, 2010, at 11:18 AM, Dick Hardt wrote:

>
> On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Dick Hardt [mail= to:dick.hardt@gmail.com]
>>> Sent: Monday, May 24, 2010 7:35 AM
>>> To: Eran Hammer-Lahav
>>> Cc: OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] 'immediate' without identity
>>>
>>> You were looking for use cases for immediate without identity.=
>>>
>>> I agree that *if* the client does know the user, then it shoul= d tell the server.
>>> Are you saying that if the client does not know the user it sh= ould not use
>>> immediate?
>>
>> I think the server should reject an immediate request without a us= ername. Otherwise the server will be giving the client an access token that= belongs to another user.
>
> Now I understand. I agree.
>
> -- Dick
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth


--_000_C8202A0034854eranhueniversecom_-- From eran@hueniverse.com Mon May 24 14:13:36 2010 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 2A7853A6826 for ; Mon, 24 May 2010 14:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_50=0.001, 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 0gkiYzw58JW3 for ; Mon, 24 May 2010 14:13:30 -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 448273A683B for ; Mon, 24 May 2010 14:13:30 -0700 (PDT) Received: (qmail 27266 invoked from network); 24 May 2010 21:13:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 May 2010 21:13:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 24 May 2010 14:13:12 -0700 From: Eran Hammer-Lahav To: Dick Hardt , OAuth WG Date: Mon, 24 May 2010 14:13:11 -0700 Thread-Topic: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) Thread-Index: Acr7JsfXEx6ajYlJS26yY2bl29RD0wAXyI9A Message-ID: In-Reply-To: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C82039F834863eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 24 May 2010 21:13:36 -0000 --_000_C82039F834863eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a bad example. This deals with encoding for the purpose if the sign= ature base string. Not the same as decoding responses which I doubt is a pr= oblem for Twitter as I think their token values are URL safe. EHL On 5/23/10 3:32 PM, "Dick Hardt" wrote: Frustration devs have with URL encoding. This is the core motivation to usi= ng JSON as the AS response format. -- Dick Begin forwarded message: From: Andrew Badera Date: May 23, 2010 2:57:44 PM PDT To: twitter-development-talk@googlegroups.com Cc: oauth@googlegroups.com Subject: [oauth] Re: [twitter-dev] Hard lesson learned Reply-To: oauth@googlegroups.com Miguel, This 'lesson' has been 'learned' and re-learned many times over, here on th= e Twitter dev list and on the oauth list. One would hope that at some point= this issue would rise to enough prominence to get people in charge of impl= ementation, and sig participants in general, to do something about it. The = common developer these days is not a super savvy geek, and even the super s= avvy geeks among us waste time on this issue, again and again. ? Andy Badera ? +1 518-641-1280 Google Voice ? This email is: [ ] bloggable [x] ask first [ ] private ? Google me: http://www.google.com/search?q=3Dandrew%20badera On Sun, May 23, 2010 at 5:52 PM, Miguel de Icaza wrote: Hello guys, Perhaps the most frustrating piece in dealing with the OAuth configuration is that the twitter OAuth page talks casually about "urlEncode". You need to "urlEncode this" and "urlEncode that". What the page does not say is that "urlEncode" is not a standard urlEncoding system that web developers are used to. The urlEncode required by OAuth signatures is actually "percent encode" and it is *required* that you use percent encoding for anything but a small subset of characters. The only characters that do not require percent encoding are: unreserved =3D a through z, A through Z, 0 through 9 and '-', '.', '_', '~' Miguel --_000_C82039F834863eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson = learned) This is a bad example. This deals with encoding for the purpose if th= e signature base string. Not the same as decoding responses which I doubt i= s a problem for Twitter as I think their token values are URL safe.

EHL


On 5/23/10 3:32 PM, "Dick Hardt" <dick.hardt@gmail.com> wrote:

Frustration devs have with URL encoding. Th= is is the core motivation to using JSON as the AS response format.

-- Dick

Begin forwarded message:

From: Andrew Badera <andrew@badera.us>
Date: May 23, 2010 2:57:44 PM PDT
To: twitter-de= velopment-talk@googlegroups.com
Cc: oauth@googlegroups.com Subject: [oauth] Re: [twitter-dev] Hard lesson learned
Reply-To: oauth@googlegroups.com=

Miguel,

This 'lesson' has been 'learned' and re-learned many times over, here on th= e Twitter dev list and on the oauth list. One would hope that at some point= this issue would rise to enough prominence to get people in charge of impl= ementation, and sig participants in general, to do something about it. The = common developer these days is not a super savvy geek, and even the super s= avvy geeks among us waste time on this issue, again and again.

∞ Andy Badera
∞ +1 518-641-1280 Google Voice
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me: http://www.google.com/search?q=3Dandrew%20badera


On Sun, May 23, 2010 at 5:52 PM, Miguel de Icaza <miguel.de.icaza@gmail.com> wrote:
Hello guys,

    Perhaps the most frustrating piece in dealing with = the OAuth
configuration is that the twitter OAuth page talks casually about
"urlEncode".  You need to "urlEncode this" and &qu= ot;urlEncode that".  What
the page does not say is that "urlEncode" is not a standard
urlEncoding system that web developers are used to.  The urlEncode
required by OAuth signatures is actually "percent encode" and it = is
*required* that you use percent encoding for anything but a small
subset of characters.

    The only characters that do not require percent enc= oding are:

unreserved =3D a through z, A through Z, 0 through 9 and  '-', '.', '_= ',
'~'

Miguel

--_000_C82039F834863eranhueniversecom_-- From eran@hueniverse.com Mon May 24 14:23:11 2010 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 267723A6823 for ; Mon, 24 May 2010 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.013 X-Spam-Level: X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=-1.015, BAYES_50=0.001, 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 43HDY-oR-rcL for ; Mon, 24 May 2010 14:23:05 -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 387E93A6767 for ; Mon, 24 May 2010 14:23:04 -0700 (PDT) Received: (qmail 8231 invoked from network); 24 May 2010 21:22:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 May 2010 21:22:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 24 May 2010 14:22:49 -0700 From: Eran Hammer-Lahav To: Luke Shepard , Marius Scurtescu Date: Mon, 24 May 2010 14:22:47 -0700 Thread-Topic: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow Thread-Index: Acr65tymULu0V0HLRQejycK1Jz3TrAAoGTAs Message-ID: In-Reply-To: <50876A45-F34B-4C60-89F6-2CFA2EB29B8B@facebook.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8203C3734866eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow 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, 24 May 2010 21:23:11 -0000 --_000_C8203C3734866eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Anyone wants to turn this into an actual proposal with list of changes to t= he current flow? EHL On 5/23/10 7:13 PM, "Luke Shepard" wrote: Brian - I like your proposal. It solves the refresh token problem and the s= erver-side auth in one go. Marius - your proposal would work great in a circumstance where you have st= rong integration between JavaScript and the server, and they are both contr= olled by the same developer. In that case, sure, the developer could pass t= he access token back to the front-end (although you would have a perf hit). However, the case that I'd like to solve (and what I read, Brian wants to a= s well) is like this: - Client includes some Javascript from the relevant service (either Faceboo= k or Twitter @anywhere) - The JS handles the auth flow and does some client-side API calls - for ex= ample, Twitter displays hovercards on each username on the site, or Faceboo= k renders some profile pics - The JS also passes a token down to the server - either in the cookies, or= perhaps directly via an Ajax call - The server can now independently make its own API calls if it wants, and = gets a refresh token or whatever else it wants This allows for a single, general purpose JS library that handles auth for = both client and server applications - which is something that the web serve= r flow by itself does not allow. On May 21, 2010, at 5:50 PM, Marius Scurtescu wrote: > On Fri, May 21, 2010 at 1:46 PM, Brian Ellin wrote: >> Marius, >> I don't understand. Will you elaborate on how specifically that would w= ork? > > Maybe I am missing something, but I was suggesting that the JavaScript > code starts a web server flow at the end of which it has a > verification code. It passes this verification code down to the client > server, the client server swaps it for an access token and a refresh > token and passes the access token to the JavaScript client. When the > access token expires the client JavaScript has two options, ask the > client server for a refresh or do an immediate request to that authz > server. > > If you want that the client server and client JavaScript have tokens > with totally different scopes, then you probably want to send the user > for approval twice. If you just want the client JavaScript to have a > token with a lesser scope (and avoid a second approval), then we > should probably look into down-scoping, which currently is not > supported. > > Would that work? > > Marius > > >> Brian >> >> On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu >> wrote: >>> >>> Why not use the web server flow in this case? >>> >>> I think it should work with un-registered clients as well (no client >>> secret). >>> >>> Marius >>> >>> >>> >>> On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrot= e: >>>> We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter. >>>> @anywhere is a pure javascript layer that developers can drop in to a= dd >>>> Twitter features to their website. With the User-Agent flow, we issue >>>> short >>>> lived access tokens that refresh as they expire. It works great for >>>> in-page >>>> stuff, but many developers are also building server-side integrations >>>> and >>>> would love to have different longer lived access tokens on their serve= r. >>>> This is a common pattern that other connect-like services built on to= p >>>> of >>>> OAuth 2.0 will also find necessary. >>>> So, why not just use the access token issued by the User-Agent flow on >>>> the >>>> client server? Overloading the use of that token is not desirable for= a >>>> couple of reasons: >>>> 1) The client server may not be using ssl, and as such the browser >>>> cannot >>>> securely transfer the access token to the server. >>>> 2) The access token lifetime policy for the User-Agent flow may not >>>> be desirable on the server. Specifically, the server may need a token >>>> that >>>> lasts for, say, two weeks instead of 15 minutes. Additionally, the >>>> token on >>>> the server may have access to different resources that are >>>> not desirable to >>>> transmit to or through the browser. >>>> In short, it is desirable to get two different access tokens from a >>>> single >>>> user authorization triggered by the User-Agent flow. >>>> Proposal: >>>> Make it possible to get a Web Server flow verification code from the >>>> User-Agent client authorization request [1]. Specifically, add a new >>>> optional parameter named "web_server_code" which when set to "true" >>>> returns >>>> a Web Server flow verification "code" field in the User-Agent >>>> authorization >>>> response. The verification code can then be sent by the javascript >>>> layer to >>>> the client server, where it is then used to request an access token [2= ]. >>>> Love to hear your feedback. >>>> 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1 >>>> 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2 >>>> -- >>>> Brian Ellin >>>> Product Manager, Twitter Platform >>>> http://twitter.com/brianellin >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >> >> >> >> -- >> Brian Ellin >> Twitter Platform Team >> http://twitter.com/brianellin >> > _______________________________________________ > 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 --_000_C8203C3734866eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Proposal: make it possible to get a verification code= in the user-agent flow Anyone wants to turn this into an actual proposal with list of change= s to the current flow?

EHL


On 5/23/10 7:13 PM, "Luke Shepard" <lshepard@facebook.com> wrote:

Brian - I like your proposal. It solves the= refresh token problem and the server-side auth in one go.

Marius - your proposal would work great in a circumstance where you have st= rong integration between JavaScript and the server, and they are both contr= olled by the same developer. In that case, sure, the developer could pass t= he access token back to the front-end (although you would have a perf hit).=

However, the case that I'd like to solve (and what I read, Brian wants to a= s well) is like this:

- Client includes some Javascript from the relevant service (either Faceboo= k or Twitter @anywhere)
- The JS handles the auth flow and does some client-side API calls - for ex= ample, Twitter displays hovercards on each username on the site, or Faceboo= k renders some profile pics
- The JS also passes a token down to the server - either in the cookies, or= perhaps directly via an Ajax call
- The server can now independently make its own API calls if it wants, and = gets a refresh token or whatever else it wants

This allows for a single, general purpose JS library that handles auth for = both client and server applications - which is something that the web serve= r flow by itself does not allow.

On May 21, 2010, at 5:50 PM, Marius Scurtescu wrote:

> On Fri, May 21, 2010 at 1:46 PM, Brian Ellin <bellin@twitter.com> wrote:
>> Marius,
>> I don't understand.  Will you elaborate on how specifically t= hat would work?
>
> Maybe I am missing something, but I was suggesting that the JavaScript=
> code starts a web server flow at the end of which it has a
> verification code. It passes this verification code down to the client=
> server, the client server swaps it for an access token and a refresh > token and passes the access token to the JavaScript client. When the > access token expires the client JavaScript has two options, ask the > client server for a refresh or do an immediate request to that authz > server.
>
> If you want that the client server and client JavaScript have tokens > with totally different scopes, then you probably want to send the user=
> for approval twice. If you just want the client JavaScript to have a > token with a lesser scope (and avoid a second approval), then we
> should probably look into down-scoping, which currently is not
> supported.
>
> Would that work?
>
> Marius
>
>
>> Brian
>>
>> On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu <mscurtescu@google.com>
>> wrote:
>>>
>>> Why not use the web server flow in this case?
>>>
>>> I think it should work with un-registered clients as well (no = client
>>> secret).
>>>
>>> Marius
>>>
>>>
>>>
>>> On Fri, May 21, 2010 at 10:39 AM, Brian Ellin <bellin@twitter.com> wrote:
>>>> We're using the OAuth 2.0 User-Agent flow in @anywhere at = Twitter.
>>>>  @anywhere is a pure javascript layer that developers= can drop in to add
>>>> Twitter features to their website.  With the User-Age= nt flow, we issue
>>>> short
>>>> lived access tokens that refresh as they expire.  It = works great for
>>>> in-page
>>>> stuff, but many developers are also building server-side i= ntegrations
>>>> and
>>>> would love to have different longer lived access tokens on= their server.
>>>>  This is a common pattern that other connect-like ser= vices built on top
>>>> of
>>>> OAuth 2.0 will also find necessary.
>>>> So, why not just use the access token issued by the User-A= gent flow on
>>>> the
>>>> client server?  Overloading the use of that token is = not desirable for a
>>>> couple of reasons:
>>>> 1) The client server may not be using ssl, and as such the= browser
>>>> cannot
>>>> securely transfer the access token to the server.
>>>> 2) The access token lifetime policy for the User-Agent flo= w may not
>>>> be desirable on the server.  Specifically, the server= may need a token
>>>> that
>>>> lasts for, say, two weeks instead of 15 minutes.  Add= itionally, the
>>>> token on
>>>> the server may have access to different resources that are=
>>>> not desirable to
>>>> transmit to or through the browser.
>>>> In short, it is desirable to get two different access toke= ns from a
>>>> single
>>>> user authorization triggered by the User-Agent flow.
>>>> Proposal:
>>>> Make it possible to get a Web Server flow verification cod= e from the
>>>> User-Agent client authorization request [1]. Specifically,= add a new
>>>> optional parameter named "web_server_code" which= when set to "true"
>>>> returns
>>>> a Web Server flow verification "code" field in t= he User-Agent
>>>> authorization
>>>> response.  The verification code can then be sent by = the javascript
>>>> layer to
>>>> the client server, where it is then used to request an acc= ess token [2].
>>>> Love to hear your feedback.
>>>> 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#sect= ion-3.5.1
>>>> 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#sect= ion-3.6.2
>>>> --
>>>> Brian Ellin
>>>> Product Manager, Twitter Platform
>>>> http://twitter.c= om/brianellin
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> ht= tps://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>
>>
>>
>> --
>> Brian Ellin
>> Twitter Platform Team
>> http://twitter.com/brian= ellin
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C8203C3734866eranhueniversecom_-- From mscurtescu@google.com Mon May 24 16:38:14 2010 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 0954F3A6FDD for ; Mon, 24 May 2010 16:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.247 X-Spam-Level: X-Spam-Status: No, score=-100.247 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 lGg7ZpiIHTLQ for ; Mon, 24 May 2010 16:38:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 8C4CB3A685C for ; Mon, 24 May 2010 16:38:12 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o4ONc25O017714 for ; Mon, 24 May 2010 16:38:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274744283; bh=570bsLvw3X/hVwi416MSWLET6Is=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=WakTu2wbKC/0GF4Sch+yQeciy9b7QwAHmeH7W6Q9tkfNs+0w6EHhe+kwU8rPMoVUy 7oJCoxPXPRgEGn4Tl1FeA== 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:content-transfer-encoding:x-system-of-record; b=StfTONLcA2u8Q/N2+ZaeFE0w60FoPkQG+h0NiHaGS9UadpblOVyk6MmDDWa5gZ011 /Tr6y7O+NRQEXxS4cPdHA== Received: from pvc22 (pvc22.prod.google.com [10.241.209.150]) by kpbe14.cbf.corp.google.com with ESMTP id o4ONc0Ht027597 for ; Mon, 24 May 2010 16:38:01 -0700 Received: by pvc22 with SMTP id 22so2145943pvc.24 for ; Mon, 24 May 2010 16:38:00 -0700 (PDT) Received: by 10.141.22.19 with SMTP id z19mr4583313rvi.250.1274744280468; Mon, 24 May 2010 16:38:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Mon, 24 May 2010 16:37:40 -0700 (PDT) In-Reply-To: <4BFAA6AB.8040809@lodderstedt.net> References: <4BFAA6AB.8040809@lodderstedt.net> From: Marius Scurtescu Date: Mon, 24 May 2010 16:37:40 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 24 May 2010 23:38:14 -0000 Hi Torsten, I think this problem can also be solved with down-scoping support on the refresh call (or a separate flow as Dick suggested). The client would get back a single access token and corresponding refresh token. It then can use the "refresh" call with an optional scope to get a narrow access token. The original access token (the one that came along the refresh token) would be discarded. I realized that with down-scoping it is up to the client to do the right thing, but I don't think that multiple access tokens can really solve the issue. In your example, what if there are three types of APIs: - requiring only "calendar" scope - requiring only "contacts" scope - requiring both "calendar" and "contacts" scopes How would the authorization server know how many access tokens to issue based only on requested scopes? The client knows what narrow access tokens it needs because it knows what APIs it intends to use. Marius On Mon, May 24, 2010 at 9:17 AM, Torsten Lodderstedt wrote: > How many access tokens can be the result of a single OAuth authorization > flow? > > A recent discussion about OpenID Connect on the OpenId mailing list raise= d > that question and I would like to initiate a discussion on this list. > > Currently, every flow (and the refresh token request) results in a single > access token and (optionally) a single refresh token. I think a single > access token might not be enough when it comes to multiple scopes. > > Let's assume a client wants to access the calendar and contact list of an > end-user. Since access to the corresponding resource servers is managed b= y > the same authorization server, the resources are distinguished by differe= nt > scopes, say "calendar" and "contacts". > > The client sends a request > > =A0 =A0 GET /authorize?type=3Dweb_server&client_id=3Ds6BhdRkqt3&redirect_= uri=3D > =A0 =A0 =A0 =A0 https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=3Dcalenda= r%20contacts > HTTP/1.1 > =A0 =A0 Host: oauth.example.com > > and after the authorization flow has been conducted sucessfully, the > client's access token request would be answered as follows. > > =A0 =A0 HTTP/1.1 200 OK > =A0 =A0 Content-Type: application/json > =A0 =A0 Cache-Control: no-store > > =A0 =A0 { > =A0 =A0 =A0 "access_token":"SlAV32hkKG", > =A0 =A0 =A0 "expires_in":3600, > =A0 =A0 =A0 "refresh_token":"8xLOxBtZp8" > =A0 =A0 } > > So the token "SlAV32hkKG" must be good for two different protected > resources, "calendar" and "contacts". > > I think this works if: > 1) the token is a handle that can be swoped for user identity and > authorization data during service request or > 2) it is a self-contained token AND both resources are provided by the sa= me > resource server. > > But what if the authorization server issues self-contained tokens and the > resources are hosted on different, independent resource servers? > > Let's assume the authorization server issues self-contained, signed, and > encrypted bearer tokens. Signature and encryption are based on shared > secrets between authorization server and resource server. In such a > scenario, operational security requires to issue different tokens with > different signature values and to encrypt those tokens with different key= s. > Moreover, the resource servers might need different user attributes and > permissions, so even the tokens payload might differ. > > I believe this scenario will become even more important with the advent o= f > OpenID Connect. With OpenID connect, every client asking for an end-user'= s > OpenID (+user data) and, additionally, authorization for another resource > will need at least two tokens under the assumptions given above. > > In order to support such scenarios, I would propose to return an array of > access tokens from every authorization flow and the refresh request. An > authorization server should know which resources and scopes are handled b= y > what resource servers and indicate this relation in the access tokens > response structure. This structure could be as follows. > > =A0 =A0 HTTP/1.1 200 OK > =A0 =A0 Content-Type: application/json > =A0 =A0 Cache-Control: no-store > > =A0 =A0 { > =A0 =A0 =A0 "access_tokens":[ > =A0 =A0 =A0{ "token":"SlAV32hkKG", "scopes":["calendar"], "expires_in":36= 00}, > =A0 =A0 =A0{ "token":"SlAV32hk34", "scopes":["contacts"], "expires_in":72= 00},], > =A0 =A0 =A0 "refresh_token":"8xLOxBtZp8" > =A0 =A0 } > > The scopes a particular access token is good for are indicated, so a clie= nt > library is able to choose the right tokens for services requests. > Alternatively it might suffice (or be better?) to indicate the sites a to= ken > is valid for (proposal of James Manger). It think there is no need for > multiple refresh tokens because these tokens are handled by the > authorization server only. > > In case all resources are handled by the same resource server, the result > would look like > > =A0 =A0 HTTP/1.1 200 OK > =A0 =A0 Content-Type: application/json > =A0 =A0 Cache-Control: no-store > > =A0 =A0 { > =A0 =A0 =A0 =A0"access_tokens":[{ "token":"SlAV32hkKG", "expires_in":3600= },], > =A0 =A0 =A0 "refresh_token":"8xLOxBtZp8" > =A0 =A0 } > > Thoughts? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Mon May 24 16:55:47 2010 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 4A8663A67DB for ; Mon, 24 May 2010 16:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.234 X-Spam-Level: X-Spam-Status: No, score=-100.234 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 aU-JbFYmfRhL for ; Mon, 24 May 2010 16:55:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D8F3C3A68A9 for ; Mon, 24 May 2010 16:55:45 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o4ONtZ5Q032599 for ; Mon, 24 May 2010 16:55:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274745335; bh=VMDH44ptfgfj0JHIpecbrmRk+pg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=oOjI9Bq7+SPJjAMqSp6wdaR36BEEOA/Ztc8ESCYphuuH6wVEas4szL+QRFFwSViOz PRRF6WTowdUMQSNyZ2bcQ== 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:content-transfer-encoding:x-system-of-record; b=bMHeYn0S8JH54YnwL6oCJZ4RYFXOkyXTME2OpWqwAka2rHtDA09by0k9g0IK2md5r e758mBZYxCwAZbH6bfK/Q== Received: from pvc22 (pvc22.prod.google.com [10.241.209.150]) by kpbe18.cbf.corp.google.com with ESMTP id o4ONtXhP006942 for ; Mon, 24 May 2010 16:55:33 -0700 Received: by pvc22 with SMTP id 22so2152260pvc.24 for ; Mon, 24 May 2010 16:55:33 -0700 (PDT) Received: by 10.140.57.20 with SMTP id f20mr4526470rva.175.1274745333299; Mon, 24 May 2010 16:55:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Mon, 24 May 2010 16:55:13 -0700 (PDT) In-Reply-To: References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> From: Marius Scurtescu Date: Mon, 24 May 2010 16:55:13 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 24 May 2010 23:55:47 -0000 And to add to this, this example shows that encoding is hard, JSON only solves decoding (in most cases, but not all). For all direct requests clients still need to encode and without a library still need to figure what chars must be encoded. Introducing JSON because dealing with form-encoded is hard does not make much sense. As discussions last week showed (and earlier on this list), with JSON there is also the perception that it is easy to do by hand and that no escaping is needed. IMO that will lead to way more problems. I guess that there are other reasons to use JSON. The best argument I heard is that JSON may be used in some token formats and in discovery documents. That could make sense, but even then, I don't think there is any harm in using form-encoded for the basic protocol. Marius On Mon, May 24, 2010 at 2:13 PM, Eran Hammer-Lahav wr= ote: > This is a bad example. This deals with encoding for the purpose if the > signature base string. Not the same as decoding responses which I doubt i= s a > problem for Twitter as I think their token values are URL safe. > > EHL > > > On 5/23/10 3:32 PM, "Dick Hardt" wrote: > > Frustration devs have with URL encoding. This is the core motivation to > using JSON as the AS response format. > > -- Dick > > Begin forwarded message: > > From: Andrew Badera > Date: May 23, 2010 2:57:44 PM PDT > To: twitter-development-talk@googlegroups.com > Cc: oauth@googlegroups.com > Subject: [oauth] Re: [twitter-dev] Hard lesson learned > Reply-To: oauth@googlegroups.com > > Miguel, > > This 'lesson' has been 'learned' and re-learned many times over, here on = the > Twitter dev list and on the oauth list. One would hope that at some point > this issue would rise to enough prominence to get people in charge of > implementation, and sig participants in general, to do something about it= . > The common developer these days is not a super savvy geek, and even the > super savvy geeks among us waste time on this issue, again and again. > > =E2=88=9E Andy Badera > =E2=88=9E +1 518-641-1280 Google Voice > =E2=88=9E This email is: [ ] bloggable [x] ask first [ ] private > =E2=88=9E Google me: http://www.google.com/search?q=3Dandrew%20badera > > > On Sun, May 23, 2010 at 5:52 PM, Miguel de Icaza > wrote: > > Hello guys, > > =C2=A0=C2=A0=C2=A0=C2=A0Perhaps the most frustrating piece in dealing wit= h the OAuth > configuration is that the twitter OAuth page talks casually about > "urlEncode". =C2=A0You need to "urlEncode this" and "urlEncode that". =C2= =A0What > the page does not say is that "urlEncode" is not a standard > urlEncoding system that web developers are used to. =C2=A0The urlEncode > required by OAuth signatures is actually "percent encode" and it is > *required* that you use percent encoding for anything but a small > subset of characters. > > =C2=A0=C2=A0=C2=A0=C2=A0The only characters that do not require percent e= ncoding are: > > unreserved =3D a through z, A through Z, 0 through 9 and =C2=A0'-', '.', = '_', > '~' > > Miguel > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From dick.hardt@gmail.com Mon May 24 17:53:07 2010 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 51E273A68C0 for ; Mon, 24 May 2010 17:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_40=-0.185] 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 6Sl2gAtPVGFk for ; Mon, 24 May 2010 17:53:06 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 88DDC3A685F for ; Mon, 24 May 2010 17:53:06 -0700 (PDT) Received: by pva18 with SMTP id 18so1113956pva.31 for ; Mon, 24 May 2010 17:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=QSQVbLDSra5/DGKKWauYNV8MuRYvllrfsNQ0X1lGM1k=; b=B4rWt8PvgKVenmFDFhtgcWpUnM6/PTJ0c/03LS4AKWQBpM6JfOHIXWMUJ+tnqLMqqY ccJyYF3Mhp6B/P9dEW77Jl+wwGy7LUUtrrhaySlV35PITNn0YbQ4teqUHj0UbX6U3JFK MuZJLi+YzgShXcFt/QBtZUZADiso07f7ossCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=YN4teMAN1/BBwzLrtevyISDJ+USSgHQnqCSx+1nvOlT0GRitnESGpquQMunkyeYzid hzdHCQNYjnKIPyO5ELGAFzCI8bzgbHDWVXZgZotan9fghDGqMlexedSWoDZZMlrYM/fh V3Ml30bE7T4103c9DhBHoSHEv3X7Kz4Vs5JIo= Received: by 10.141.1.1 with SMTP id d1mr4630822rvi.89.1274748775876; Mon, 24 May 2010 17:52:55 -0700 (PDT) Received: from [10.0.1.8] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id b2sm3650794rvn.19.2010.05.24.17.52.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 May 2010 17:52:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Mon, 24 May 2010 17:52:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> To: Marius Scurtescu X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 25 May 2010 00:53:07 -0000 On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote: > And to add to this, this example shows that encoding is hard, JSON > only solves decoding (in most cases, but not all). JSON solves encoding and decoding with the same library. >=20 > For all direct requests clients still need to encode and without a > library still need to figure what chars must be encoded. You argued this point numerous times at the in-person meeting. Clients = are used to encoding and creating requests to servers. That is what they = do. There are many simple ways of doing this. Clients in general do NOT decode forms data, that is done by servers, = and is built into server frameworks. > Introducing JSON because dealing with form-encoded is hard does not > make much sense. As discussions last week showed (and earlier on this > list), with JSON there is also the perception that it is easy to do by > hand and that no escaping is needed. IMO that will lead to way more > problems. Libraries exit for encoding and decoding JSON. They are really easy to = use. There is asymmetry in the forms data. Servers typically decode, and = clients typically encode. -- Dick= From James.H.Manger@team.telstra.com Mon May 24 18:18:56 2010 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 6C20B3A681D for ; Mon, 24 May 2010 18:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.551 X-Spam-Level: * X-Spam-Status: No, score=1.551 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxvDlZUyYaw1 for ; Mon, 24 May 2010 18:18:55 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 369183A67F9 for ; Mon, 24 May 2010 18:18:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,295,1272808800"; d="scan'208";a="3131180" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 25 May 2010 11:18:45 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5992"; a="2698567" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcani.tcif.telstra.com.au with ESMTP; 25 May 2010 11:18:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Tue, 25 May 2010 11:18:45 +1000 From: "Manger, James H" To: Torsten Lodderstedt , "OAuth WG (oauth@ietf.org)" Date: Tue, 25 May 2010 11:18:44 +1000 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr7XKzqkaM10ER2TCO/tC1m79gbGgARqJow Message-ID: <255B9BB34FB7D647A506DC292726F6E112639DC9C7@WSMSG3153V.srv.dir.telstra.com> References: <4BFAA6AB.8040809@lodderstedt.net> In-Reply-To: <4BFAA6AB.8040809@lodderstedt.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] multiple access tokens from a single authorization flow? 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, 25 May 2010 01:18:56 -0000 VG9yc3RlbiwNCg0KSSBvYnZpb3VzbHkgYWdyZWUgdGhhdCBzdXBwb3J0aW5nIHJlc3BvbnNlcyB3 aXRoIG11bHRpcGxlIHRva2VucyBpcyB1c2VmdWwuDQpNeSBvcmlnaW5hbCBzdWdnZXN0aW9uIChh cHBsaWNhdGlvbi9jcmVkZW50aWFscyBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvb2F1dGgvY3VycmVudC9tc2cwMTkyMC5odG1sKSBhbHNvIGhhZCBtdWx0aXBsZSB0b2tlbnMg d2l0aCBqdXN0IG9uZSByZWZyZXNoX3Rva2VuLg0KDQpJIG5vdyB0aGluayBpdCB3b3VsZCBiZSBz aW1wbGVyIHRvIHVuZGVyc3RhbmQsIHBhcnNlLCBzcGVjaWZ5LCBhbmQgYWdyZWUgb24gaWYgd2Ug ZG9uJ3QgdHJ5IHRvIHNwbGl0IGZpZWxkcyBiZXR3ZWVuIHRob3NlIHRoYXQgYXJlIGNvbW1vbiB0 byBhbGwgdGhlIHRva2VucyBpbiBhIHJlc3BvbnNlIGFuZCB0aG9zZSB0aGF0IGFyZSBzcGVjaWZp YyB0byBvbmUgdG9rZW4uIEEgSlNPTiBhcnJheSBvZiBKU09OIG9iamVjdHMgLS0gb25lIEpTT04g b2JqZWN0IHBlciB0b2tlbiAtLSBpcyBzaWduaWZpY2FudGx5IHNpbXBsZXIuIElmIHNvbWUgaW5m b3JtYXRpb24gaXMgZHVwbGljYXRlZCBpbiB0d28gdG9rZW5zIHRoYXQgaXMgYSB2ZXJ5IG1pbm9y IGluZWZmaWNpZW5jeSAoZWcgYSBmZXcgZG96ZW4gZXh0cmEgYnl0ZXMgaW4gb25lIHJlc3BvbnNl KS4NCg0KDQoNCk1hcml1cywNClN1cHBvcnRpbmcgdGhlIHN3YXBwaW5nIChkb3duLXNjb3Bpbmcp IG9mIHRva2VucyB3aXRoIGV4dHJhIGNhbGxzIG1pZ2h0IGJlIGZlYXNpYmxlLCBidXQgaXQgZmVl bHMgbGlrZSBhIG1vcmUgY29tcGxleCBhbmQgbGVzcyBmbGV4aWJsZSBzb2x1dGlvbi4gSXQgaGFz IG1vcmUgb3ZlcmhlYWQgKGV4dHJhIHJvdW5kIHRyaXBzKS4gSXQgd291bGQgYWxzbyBuZWVkIGV4 dHJhIGluZm9ybWF0aW9uIHRvIHRlbGwgdGhlIGNsaWVudCB0aGF0IHN3YXBwaW5nIGlzIHBvc3Np YmxlLCBhbmQgZm9yIHdoYXQgc2NvcGVzL3NlcnZlcnMvc2NoZW1lcy8uLi4gaXQgY2FuLCBzaG91 bGQgb3IgbXVzdCBiZSBkb25lLg0KDQo+IFRoZSBvcmlnaW5hbCBhY2Nlc3MgdG9rZW4gKHRoZSBv bmUgdGhhdCBjYW1lIGFsb25nIHRoZSByZWZyZXNoIHRva2VuKSB3b3VsZCBiZSBkaXNjYXJkZWQu DQoNClRoaXMgZG9lc24ndCBtZWV0IHNvbWUgb2YgdGhlIHJlcXVpcmVtZW50cy4gVG9rZW5zIGZv ciBIVFRQIGFuZCBIVFRQUyBhcmUgbmVlZGVkIHNpbXVsdGFuZW91c2x5LCBub3Qgc2VxdWVudGlh bGx5LiBTaW1pbGFybHkgd2l0aCB0b2tlbnMgZm9yIGEgJ2NvbnRhY3RzJyBzZXJ2ZXIgYW5kIGEg J2NhbGVuZGFyJyBzZXJ2ZXI7IG9yIHRva2VucyB0byB1c2Ugd2l0aCBCQVNJQyBhbmQgVE9LRU4g c2NoZW1lcyBldGMuDQoNCi0tIA0KSmFtZXMgTWFuZ2VyDQoNCg0K From mscurtescu@google.com Mon May 24 20:53:17 2010 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 C8BA13A67D1 for ; Mon, 24 May 2010 20:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.362 X-Spam-Level: X-Spam-Status: No, score=-104.362 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_50=0.001, 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 EnA8fUukV68e for ; Mon, 24 May 2010 20:53:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A8ADD3A6DA4 for ; Mon, 24 May 2010 20:53:00 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o4P3qo0T022950 for ; Mon, 24 May 2010 20:52:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274759572; bh=YFP+lKioLNbwYTxMQvMhU65jxY4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=x9+r0lur8+XqNsGoJDABNWXnzpw3H5ryRyv1n8410E83CtvINPw8lMtm+CBmLpTkI OU8cgi2mhQSFBcqYwMOqw== 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:content-transfer-encoding:x-system-of-record; b=LenR2iS6vDNLImRHA3a4w6qamA5jqRrjMTtglqN1yxgMl7M4f7ZGPxSIEeauDCkxV 3Mb4g8T0l7eADRppNOKrQ== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by hpaq2.eem.corp.google.com with ESMTP id o4P3qlCX001930 for ; Mon, 24 May 2010 20:52:48 -0700 Received: by pzk28 with SMTP id 28so2223088pzk.11 for ; Mon, 24 May 2010 20:52:47 -0700 (PDT) Received: by 10.140.55.10 with SMTP id d10mr4739455rva.247.1274759567283; Mon, 24 May 2010 20:52:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Mon, 24 May 2010 20:52:27 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112639DC9C7@WSMSG3153V.srv.dir.telstra.com> References: <4BFAA6AB.8040809@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112639DC9C7@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Mon, 24 May 2010 20:52:27 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 03:53:17 -0000 On Mon, May 24, 2010 at 6:18 PM, Manger, James H wrote: > Torsten, > > I obviously agree that supporting responses with multiple tokens is usefu= l. > My original suggestion (application/credentials http://www.ietf.org/mail-= archive/web/oauth/current/msg01920.html) also had multiple tokens with just= one refresh_token. > > I now think it would be simpler to understand, parse, specify, and agree = on if we don't try to split fields between those that are common to all the= tokens in a response and those that are specific to one token. A JSON arra= y of JSON objects -- one JSON object per token -- is significantly simpler.= If some information is duplicated in two tokens that is a very minor ineff= iciency (eg a few dozen extra bytes in one response). > > > > Marius, > Supporting the swapping (down-scoping) of tokens with extra calls might b= e feasible, but it feels like a more complex and less flexible solution. It= has more overhead (extra round trips). It would also need extra informatio= n to tell the client that swapping is possible, and for what scopes/servers= /schemes/... it can, should or must be done. I agree that the extra calls complicate things. How does the authz server know how to partition the scopes to the multiple tokens? One scope per token? What if an API requires multiple scopes? Marius From leah.culver@gmail.com Mon May 24 21:04:40 2010 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 259D63A6B1F for ; Mon, 24 May 2010 21:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 XlttxJpInj5h for ; Mon, 24 May 2010 21:04:39 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D3C5D3A6C4F for ; Mon, 24 May 2010 21:04:38 -0700 (PDT) Received: by gyh4 with SMTP id 4so1956628gyh.31 for ; Mon, 24 May 2010 21:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=g2kDTC6hbeFUyRqIpkQfI3w8Q4CCevNNH/eDzt59C3A=; b=nyC5Ne1doc/a9y8Iyjbf0BfKYeGURL/13x3Y7kHq2wvQZCaP0uX8ongGWRAMi2c5/N tcpKcB1HsmaS4RIGhKopn659gWDzIxbbzujkpXMvZLqQjSo62nLC263Hsw30p4Yh0hfF JsDx4wuDyMEN+Wsx9P/SRiwa7vAgDbTN7njuk= 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; b=f8rLK33bbTLb+uWrqe7QytFi6rvW4ZY35d0zfS4d0DlFmIiLgZKTux25Q9hsfRyUCN 27vKbx9D+Ua5k9aw9qorPPGDo+0Vpxb//uwKfXQrUVSarH3IDfF8GU3WmpyY9b5W/w7v LM3W2TqB5s3bESStjh3CT5xTdFXrRbT6q2gR8= Received: by 10.91.117.18 with SMTP id u18mr2871235agm.174.1274760268110; Mon, 24 May 2010 21:04:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.66.18 with HTTP; Mon, 24 May 2010 21:03:58 -0700 (PDT) In-Reply-To: References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> From: Leah Culver Date: Mon, 24 May 2010 21:03:58 -0700 Message-ID: To: Dick Hardt Content-Type: multipart/alternative; boundary=001485f87eecf45ddb048763401b Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 25 May 2010 04:04:40 -0000 --001485f87eecf45ddb048763401b Content-Type: text/plain; charset=ISO-8859-1 To me this smells a lot like XML a few years ago... how XML is baked into XMPP and people thought that HTML should be converted to XML... seemed like a good idea at the time :D So yeah, I'm against supporting ONLY JSON. I'd be fine if the spec allowed for form-encoded, XML or whatever else might become the hot new thing. I'm really for leaving it up to the provider. I don't think it's up to OAuth to force people to use what we think is the coolest encoding format. Leah On Mon, May 24, 2010 at 5:52 PM, Dick Hardt wrote: > > On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote: > > > And to add to this, this example shows that encoding is hard, JSON > > only solves decoding (in most cases, but not all). > > JSON solves encoding and decoding with the same library. > > > > > For all direct requests clients still need to encode and without a > > library still need to figure what chars must be encoded. > > You argued this point numerous times at the in-person meeting. Clients are > used to encoding and creating requests to servers. That is what they do. > There are many simple ways of doing this. > > Clients in general do NOT decode forms data, that is done by servers, and > is built into server frameworks. > > > Introducing JSON because dealing with form-encoded is hard does not > > make much sense. As discussions last week showed (and earlier on this > > list), with JSON there is also the perception that it is easy to do by > > hand and that no escaping is needed. IMO that will lead to way more > > problems. > > Libraries exit for encoding and decoding JSON. They are really easy to use. > There is asymmetry in the forms data. Servers typically decode, and clients > typically encode. > > -- Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001485f87eecf45ddb048763401b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To me this smells a lot like XML a few years ago... how XML is baked into X= MPP and people thought that HTML should be converted to XML... seemed like = a good idea at the time :D

So yeah, I'm against supporting ONLY = JSON. I'd be fine if the spec allowed for form-encoded, XML or whatever= else might become the hot new thing. I'm really for leaving it up to t= he provider. I don't think it's up to OAuth to force people to use = what we think is the coolest encoding format.

Leah


On Mon, May 24, 2010 at 5:52= PM, Dick Hardt <dick.hardt@gmail.com> wrote:

On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote:

> And to add to this, this example shows that encoding is hard, JSON
> only solves decoding (in most cases, but not all).

JSON solves encoding and decoding with the same library.

>
> For all direct requests clients still need to encode and without a
> library still need to figure what chars must be encoded.

You argued this point numerous times at the in-person meeting. Client= s are used to encoding and creating requests to servers. That is what they = do. There are many simple ways of doing this.

Clients in general do NOT decode forms data, that is done by servers, and i= s built into server frameworks.

> Introducing JSON because dealing with form-encoded is hard does not > make much sense. As discussions last week showed (and earlier on this<= br> > list), with JSON there is also the perception that it is easy to do by=
> hand and that no escaping is needed. IMO that will lead to way more > problems.

Libraries exit for encoding and decoding JSON. They are really easy t= o use. There is asymmetry in the forms data. Servers typically decode, and = clients typically encode.

-- Dick
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001485f87eecf45ddb048763401b-- From James.H.Manger@team.telstra.com Mon May 24 22:04:50 2010 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 256083A68E7 for ; Mon, 24 May 2010 22:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.165 X-Spam-Level: ** X-Spam-Status: No, score=2.165 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHy6sIA-EOmw for ; Mon, 24 May 2010 22:04:49 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id DDBEE3A6857 for ; Mon, 24 May 2010 22:04:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,296,1272808800"; d="scan'208";a="3159258" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 25 May 2010 15:04:38 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5992"; a="2352865" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 25 May 2010 15:04:39 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 25 May 2010 15:04:38 +1000 From: "Manger, James H" To: Marius Scurtescu Date: Tue, 25 May 2010 15:04:37 +1000 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr7vcF/kCIy5gl8Srydyqzvb6Kk8AAByt7Q Message-ID: <255B9BB34FB7D647A506DC292726F6E112639DD01D@WSMSG3153V.srv.dir.telstra.com> References: <4BFAA6AB.8040809@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112639DC9C7@WSMSG3153V.srv.dir.telstra.com> 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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 05:04:50 -0000 PiBIb3cgZG9lcyB0aGUgYXV0aHoNCj4gc2VydmVyIGtub3cgaG93IHRvIHBhcnRpdGlvbiB0aGUg c2NvcGVzIHRvIHRoZSBtdWx0aXBsZSB0b2tlbnM/IE9uZQ0KPiBzY29wZSBwZXIgdG9rZW4/IFdo YXQgaWYgYW4gQVBJIHJlcXVpcmVzIG11bHRpcGxlIHNjb3Blcz8NCg0KQW4gQVMgd2lsbCBnZW5l cmFsbHkga25vdyBhIGZhaXIgYml0IGFib3V0IHRoZSBzZXJ2aWNlcyBmb3Igd2hpY2ggaXQgaXMg aXNzdWluZyBhY2Nlc3MgdG9rZW5zIC0tIGF0IGxlYXN0IHdoaWNoIHNlcnZpY2VzIHJlcXVpcmUg d2hhdCBzb3J0IG9mIHRva2VuLg0KDQpGb3Igc2l0dWF0aW9ucyB3aGVyZSB0aGUgY2xpZW50IGFw cCBoYXMgbW9yZSBrbm93bGVkZ2UgdGhhbiB0aGUgQVMgb24gaG93IHRva2VucyB3aWxsIGJlIHVz ZWQsIHRoZSBjbGllbnQgYXBwIGNvdWxkIHRlbGwgdGhlIEFTIGhvdyB0byBwYXJ0aXRpb24gdG9r ZW5zIHdpdGggYW5vdGhlciBwYXJhbWV0ZXIgaW4gdGhlIHVzZXItdXJpICh0aG91Z2ggT0F1dGgy IGRvZXNuJ3QgbmVjZXNzYXJpbHkgaGF2ZSB0byBzdGFuZGFyZGlzZSBzdWNoIGEgcGFyYW1ldGVy IG5vdykuDQoNCi0tIA0KSmFtZXMgTWFuZ2VyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IE1hcml1cyBTY3VydGVzY3UgW21haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb21d IA0KU2VudDogVHVlc2RheSwgMjUgTWF5IDIwMTAgMTo1MiBQTQ0KVG86IE1hbmdlciwgSmFtZXMg SA0KQ2M6IFRvcnN0ZW4gTG9kZGVyc3RlZHQ7IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIG11bHRpcGxlIGFjY2VzcyB0b2tlbnMgZnJvbSBhIHNpbmds ZSBhdXRob3JpemF0aW9uIGZsb3c/DQoNCk9uIE1vbiwgTWF5IDI0LCAyMDEwIGF0IDY6MTggUE0s IE1hbmdlciwgSmFtZXMgSA0KPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+IHdyb3Rl Og0KPiBUb3JzdGVuLA0KPg0KPiBJIG9idmlvdXNseSBhZ3JlZSB0aGF0IHN1cHBvcnRpbmcgcmVz cG9uc2VzIHdpdGggbXVsdGlwbGUgdG9rZW5zIGlzIHVzZWZ1bC4NCj4gTXkgb3JpZ2luYWwgc3Vn Z2VzdGlvbiAoYXBwbGljYXRpb24vY3JlZGVudGlhbHMgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDE5MjAuaHRtbCkgYWxzbyBoYWQgbXVsdGlw bGUgdG9rZW5zIHdpdGgganVzdCBvbmUgcmVmcmVzaF90b2tlbi4NCj4NCj4gSSBub3cgdGhpbmsg aXQgd291bGQgYmUgc2ltcGxlciB0byB1bmRlcnN0YW5kLCBwYXJzZSwgc3BlY2lmeSwgYW5kIGFn cmVlIG9uIGlmIHdlIGRvbid0IHRyeSB0byBzcGxpdCBmaWVsZHMgYmV0d2VlbiB0aG9zZSB0aGF0 IGFyZSBjb21tb24gdG8gYWxsIHRoZSB0b2tlbnMgaW4gYSByZXNwb25zZSBhbmQgdGhvc2UgdGhh dCBhcmUgc3BlY2lmaWMgdG8gb25lIHRva2VuLiBBIEpTT04gYXJyYXkgb2YgSlNPTiBvYmplY3Rz IC0tIG9uZSBKU09OIG9iamVjdCBwZXIgdG9rZW4gLS0gaXMgc2lnbmlmaWNhbnRseSBzaW1wbGVy LiBJZiBzb21lIGluZm9ybWF0aW9uIGlzIGR1cGxpY2F0ZWQgaW4gdHdvIHRva2VucyB0aGF0IGlz IGEgdmVyeSBtaW5vciBpbmVmZmljaWVuY3kgKGVnIGEgZmV3IGRvemVuIGV4dHJhIGJ5dGVzIGlu IG9uZSByZXNwb25zZSkuDQo+DQo+DQo+DQo+IE1hcml1cywNCj4gU3VwcG9ydGluZyB0aGUgc3dh cHBpbmcgKGRvd24tc2NvcGluZykgb2YgdG9rZW5zIHdpdGggZXh0cmEgY2FsbHMgbWlnaHQgYmUg ZmVhc2libGUsIGJ1dCBpdCBmZWVscyBsaWtlIGEgbW9yZSBjb21wbGV4IGFuZCBsZXNzIGZsZXhp YmxlIHNvbHV0aW9uLiBJdCBoYXMgbW9yZSBvdmVyaGVhZCAoZXh0cmEgcm91bmQgdHJpcHMpLiBJ dCB3b3VsZCBhbHNvIG5lZWQgZXh0cmEgaW5mb3JtYXRpb24gdG8gdGVsbCB0aGUgY2xpZW50IHRo YXQgc3dhcHBpbmcgaXMgcG9zc2libGUsIGFuZCBmb3Igd2hhdCBzY29wZXMvc2VydmVycy9zY2hl bWVzLy4uLiBpdCBjYW4sIHNob3VsZCBvciBtdXN0IGJlIGRvbmUuDQoNCkkgYWdyZWUgdGhhdCB0 aGUgZXh0cmEgY2FsbHMgY29tcGxpY2F0ZSB0aGluZ3MuIEhvdyBkb2VzIHRoZSBhdXRoeg0Kc2Vy dmVyIGtub3cgaG93IHRvIHBhcnRpdGlvbiB0aGUgc2NvcGVzIHRvIHRoZSBtdWx0aXBsZSB0b2tl bnM/IE9uZQ0Kc2NvcGUgcGVyIHRva2VuPyBXaGF0IGlmIGFuIEFQSSByZXF1aXJlcyBtdWx0aXBs ZSBzY29wZXM/DQoNCg0KTWFyaXVzDQo= From dick.hardt@gmail.com Mon May 24 22:52:52 2010 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 9AFEB3A698E for ; Mon, 24 May 2010 22:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29UuMSR0CmyR for ; Mon, 24 May 2010 22:52:50 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 19AFE3A694F for ; Mon, 24 May 2010 22:52:50 -0700 (PDT) Received: by pva18 with SMTP id 18so1221586pva.31 for ; Mon, 24 May 2010 22:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kmNaom74fCuz/QqiDRH3RAN6KcD8TTZRwWx8Hw0Pw5A=; b=fxLh5kSwrQt76+uBKmHK2f4V0cbjHADPYC9xSoLLsvlQH5mppAlFOwr0tfrYscOQnA uYUNTXEDyiwYl88LoP82ubTJ7D0p+mBAfmMv2cs9vRlCJLhLUWipXMu8kfNIhqRrrf2S XvPraLY56GLnd5dsg5xVkFE26DNKZXX8ZQfJg= 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=oaAS5JcfthrxGsB3BWcPFPS7OTFkow+jhH3AyoeHNJteS2towF03oW+puxrPMmxid+ YZLoq620sPlZWf0hoI2XE9FVkNIFdTnNRu9HwdjLQdtV8ropByMzzwQkvymeOZcRXUqT pG+ZggKsImhQxwfLmfRH2AJx+uHjV6GImyqr8= MIME-Version: 1.0 Received: by 10.143.20.1 with SMTP id x1mr4283963wfi.148.1274766758850; Mon, 24 May 2010 22:52:38 -0700 (PDT) Received: by 10.143.39.21 with HTTP; Mon, 24 May 2010 22:52:38 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <045D28A6-9691-4831-ACCE-526F8A551948@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE23@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 24 May 2010 22:52:38 -0700 Message-ID: From: Dick Hardt To: Thomas Hardjono Content-Type: multipart/alternative; boundary=00504502c721d5324c048764c35c Cc: OAuth WG Subject: Re: [OAUTH-WG] Access token opaqueness question 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, 25 May 2010 05:52:52 -0000 --00504502c721d5324c048764c35c Content-Type: text/plain; charset=ISO-8859-1 Not sure why you want to pull the OAuth token parameters from the Kerberos token. Are you envisioning the Protected Resource is a Kerberos Client? On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono wrote: > > I'm still a newbie to the OAuth and WRAP discussions, so please bear with > me. > > In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is > basicaly an opaque structure to the client, but which can have some > "internal structure" (having meaning to the authz server and resource > server): > > ] Access token strings can use any internal structure agreed upon > ] between the authorization server and the resource server, but their > ] structure is opaque to the client. Since the access token provides > ] the client access to the protected resource for the life of the > ] access token (or until revoked), the authorization server should > ] issue access tokens which expire within an appropriate time, usually > ] much shorter than the duration of the access grant. > > I was wondering how true this is? > > I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth > Client need not understand this structure, but could simply pass it down to > the Kerberos-client (in the OS or in the browser). > > Then within this token (now a Kerberos ticket), the ticket fields would > contain matching entries (as far as possible) to the OAuth token parameters > (eg. expires_in, token_secret, etc). > > For the cryptographic tokens (Section 5.3), I would then use the > session-key in the ticket to compute he HMAC. > > Would this work? Any suggestions? > > /thomas/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00504502c721d5324c048764c35c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not sure why you want to pull the OAuth token parameters from the Kerberos = token.

Are you envisioning the Protected Resource is a K= erberos Client?


On = Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono <hardjono@mit.edu> wrote:

I'm still a newbie to the OAuth and WRAP discussions, so please bear wi= th me.

In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is basi= caly an opaque structure to the client, but which can have some "inter= nal structure" (having meaning to the authz server and resource server= ):

] Access token strings can use any internal structure agreed upon
] between the authorization server and the resource server, but their
] structure is opaque to the client. =A0Since the access token provides
] the client access to the protected resource for the life of the
] access token (or until revoked), the authorization server should
] issue access tokens which expire within an appropriate time, usually
] much shorter than the duration of the access grant.

I was wondering how true this is?

I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth C= lient need not understand this structure, but could simply pass it down to = the Kerberos-client (in the OS or in the browser).

Then within this token (now a Kerberos ticket), the ticket fields would con= tain matching entries (as far as possible) to the OAuth token parameters (e= g. expires_in, token_secret, etc).

For the cryptographic tokens (Section 5.3), I would then use the session-ke= y in the ticket to compute he HMAC.

Would this work? =A0Any suggestions?

/thomas/


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

--00504502c721d5324c048764c35c-- From pid@pidster.com Tue May 25 01:41:23 2010 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 E62883A6F43 for ; Tue, 25 May 2010 01:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=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 ybOHYY908T+o for ; Tue, 25 May 2010 01:41:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 972BA3A6F00 for ; Tue, 25 May 2010 01:41:21 -0700 (PDT) Received: by wwe15 with SMTP id 15so289010wwe.31 for ; Tue, 25 May 2010 01:41:10 -0700 (PDT) Received: by 10.227.147.19 with SMTP id j19mr6585311wbv.4.1274776870215; Tue, 25 May 2010 01:41:10 -0700 (PDT) Received: from Phoenix.local (cpc2-lewi13-2-0-cust269.2-4.cable.virginmedia.com [86.14.119.14]) by mx.google.com with ESMTPS id h22sm37968380wbh.9.2010.05.25.01.41.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 01:41:08 -0700 (PDT) Message-ID: <4BFB8D0B.8080408@pidster.com> Date: Tue, 25 May 2010 09:40:43 +0100 From: Pid Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dick Hardt References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA15FA999A30C671B8886F894" Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pid@pidster.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 08:41:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA15FA999A30C671B8886F894 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 25/05/2010 01:52, Dick Hardt wrote: >=20 > On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote: >=20 >> And to add to this, this example shows that encoding is hard, JSON >> only solves decoding (in most cases, but not all). >=20 > JSON solves encoding and decoding with the same library. >=20 >> >> For all direct requests clients still need to encode and without a >> library still need to figure what chars must be encoded. >=20 > You argued this point numerous times at the in-person meeting. Clients = are used to encoding and creating requests to servers. That is what they = do. There are many simple ways of doing this. >=20 > Clients in general do NOT decode forms data, that is done by servers, a= nd is built into server frameworks. If one was feeling mischievous, one could argue that an implementer only needs to find or create a library for the client side, rather than both - like JSON. >> Introducing JSON because dealing with form-encoded is hard does not >> make much sense. As discussions last week showed (and earlier on this >> list), with JSON there is also the perception that it is easy to do by= >> hand and that no escaping is needed. IMO that will lead to way more >> problems. >=20 > Libraries exit for encoding and decoding JSON. They are really easy to = use. There is asymmetry in the forms data. Servers typically decode, and = clients typically encode. I really don't think this is a reasonable argument in favour of JSON. It's somewhat confusing to argue in favour of using an external library on one hand, but not the other. The best summary of the arguments in favour of JSON was by Joseph Smarr in response to my previous inquiry, which hasn't been superseded, I think= =2E However, IMO JSON is yet to be demonstrated as the better solution. p > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------enigA15FA999A30C671B8886F894 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQIVAwUBS/uNG2oM2OGpOvr9AQrymRAAj3wSu3DdfWgzhxHHz12YCnqP9sqpu8wb UvI7ZVC948M7eWuQpXFl7w3eiXcjsguo+YJctc2uWeVkBd9X4ab40kkNM3zMvPAZ 0ttHbjyJ0eIVkVbWnm+4LgMqZ9wQ9h+aJHKpMtvd8ZPo10J771cgIT2bXeuGbwm/ 5iWIzlV9X4cMwdjOoeLfrLYRV1VvC+a0oOdJaumITG2cSmqbxlwX/yheem/U7sW1 QQNOskDoKHcTbYu69rUfq2KJb3meASgM42DFlwgXwJGj+YE8QSeqS21hXGvE29NX UQyw1DqqCQm7bb1vjJlpAyFefI6+ERfweJqCVWQ9OxtvYuXeFqj32ZJ3Rgm+6LN9 oHMJC0yDmZJbjcgI6FH4RlLaX5xxVfYWw7/fbAJvEYflNuoz1xMqjoyKumJMB2N4 N/RzT3+pLozZEObJNCACNzSk8q3OGaT+j7fViARbgxkDxYKF8ZPMvQ41Nx8aa+bE lTz4hJF70f8P3EAkzJ0GoNS7Cc+RY64e/zZRo1hkIrmnBLH+aaOV5WmAqH7kHjLJ mgquLYoYzeoSC7Tl4dyJXwQwRPhd6S47xFA1yAueM32SgiV+h33nxm+lXD7IBsWi Iq4zv+ku+csOL6e1sJD/uNMbQ9oit/FZP7F3kOoWsmDkwdjRxLyKdfNOHnVUQo54 pkIeldBbqn0= =eABf -----END PGP SIGNATURE----- --------------enigA15FA999A30C671B8886F894-- From jricher@mitre.org Tue May 25 04:00:20 2010 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 BDAC63A6B4B for ; Tue, 25 May 2010 04:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.267 X-Spam-Level: X-Spam-Status: No, score=-4.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_50=0.001, 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 uqBYQKtKUePZ for ; Tue, 25 May 2010 04:00:19 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 1561D3A6961 for ; Tue, 25 May 2010 04:00:19 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4PB0Aed027667 for ; Tue, 25 May 2010 07:00:10 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4PB0AXL027664; Tue, 25 May 2010 07:00:10 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.210]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 25 May 2010 07:00:09 -0400 From: "Richer, Justin P." To: "Manger, James H" , Torsten Lodderstedt , "OAuth WG (oauth@ietf.org)" Date: Tue, 25 May 2010 07:00:08 -0400 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr7XKzqkaM10ER2TCO/tC1m79gbGgARqJowABVBeFE= Message-ID: References: <4BFAA6AB.8040809@lodderstedt.net>, <255B9BB34FB7D647A506DC292726F6E112639DC9C7@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112639DC9C7@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 11:00:20 -0000 It seems like this would make what I see as the more common case -- getting= a single access token from a flow -- more complicated. Everybody pays the = overhead in order to support one limited use case, which is what brought ab= out the request token in oauth1. I don't want to always have to grab "token= [0]" from the response where before i just grabbed "token".=20 Also, this approach ties us to a hierarchical data representation format li= ke JSON instead of being able to use anything that can hand us simple key-v= alue pairs. Hashtables/dictionaries/associative-arrays are very easy to man= ipulate and understand in many languages. If we can do this in a way that doesn't create overhead for the single-toke= n case and if we can figure out a way to serialize it in a flat way as well= , then I'm all for it; but I don't think we should add this much complexity= just to save a few round trips. I am in favor of Dick's proposal(s) for re= -scoping and revoking existing tokens using the refresh token as credential= . This would allow clients to grab a refresh token then make one more call = each to grab whatever access tokens they wanted to. -- justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Manger, = James H [James.H.Manger@team.telstra.com] Sent: Monday, May 24, 2010 9:18 PM To: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization = flow? Torsten, I obviously agree that supporting responses with multiple tokens is useful. My original suggestion (application/credentials http://www.ietf.org/mail-ar= chive/web/oauth/current/msg01920.html) also had multiple tokens with just o= ne refresh_token. I now think it would be simpler to understand, parse, specify, and agree on= if we don't try to split fields between those that are common to all the t= okens in a response and those that are specific to one token. A JSON array = of JSON objects -- one JSON object per token -- is significantly simpler. I= f some information is duplicated in two tokens that is a very minor ineffic= iency (eg a few dozen extra bytes in one response). Marius, Supporting the swapping (down-scoping) of tokens with extra calls might be = feasible, but it feels like a more complex and less flexible solution. It h= as more overhead (extra round trips). It would also need extra information = to tell the client that swapping is possible, and for what scopes/servers/s= chemes/... it can, should or must be done. > The original access token (the one that came along the refresh token) wou= ld be discarded. This doesn't meet some of the requirements. Tokens for HTTP and HTTPS are n= eeded simultaneously, not sequentially. Similarly with tokens for a 'contac= ts' server and a 'calendar' server; or tokens to use with BASIC and TOKEN s= chemes etc. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Tue May 25 07:08:43 2010 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 7E1013A6BEB for ; Tue, 25 May 2010 07:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.176 X-Spam-Level: ** X-Spam-Status: No, score=2.176 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3A3bDsGt0Kt for ; Tue, 25 May 2010 07:08:42 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 52A153A6BC9 for ; Tue, 25 May 2010 07:08:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,298,1272808800"; d="scan'208";a="3184193" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 26 May 2010 00:08:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5992"; a="2375507" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipccvi.tcif.telstra.com.au with ESMTP; 26 May 2010 00:08:33 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Wed, 26 May 2010 00:08:33 +1000 From: "Manger, James H" To: "Richer, Justin P." , "OAuth WG (oauth@ietf.org)" Date: Wed, 26 May 2010 00:08:32 +1000 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr7XKzqkaM10ER2TCO/tC1m79gbGgARqJowABVBeFEAA8mbjg== Message-ID: <255B9BB34FB7D647A506DC292726F6E11262FEE7D7@WSMSG3153V.srv.dir.telstra.com> References: <4BFAA6AB.8040809@lodderstedt.net>, <255B9BB34FB7D647A506DC292726F6E112639DC9C7@WSMSG3153V.srv.dir.telstra.com>, In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 14:08:43 -0000 Justin, > I don't want to always have to grab "token[0]" from the response where be= fore i just grabbed "token". Surely token[0] vs token is too trivial to be an issue. > Also, this approach ties us to a hierarchical data representation format = like JSON instead of being able to use anything that can hand us simple key= -value pairs. Hashtables/dictionaries/associative-arrays are very easy to m= anipulate and understand in many languages. An array is even simpler than a hashtable. An array of hashtables is still = very easy to manipulate in any language. Info on any particular token can s= till be a hashtable. > If we can do this in a way that doesn't create overhead for the single-to= ken case and > if we can figure out a way to serialize it in a flat way as well, then I'= m all for it; We can certainly figure out a way to serialise it in a flat way -- but it w= ill look messy. OpenID manages to serialise in a flat way all sorts of stru= ctured info, even from different namespaces. Its just that few will tolerat= e such a mess today given the wide availability of a standard such as JSON = that provides the basic structure without mess. [Actually a good argument for JSON is we can have the more important discus= sions on new functionality (such as multiple tokens), on message flows, on = semantics etc without constantly being concerned about serialisation, argui= ng about how to squeeze the logical messages into a single flat ASCII-subse= t hashtable.]=20 > but I don't think we should add this much complexity just to save a few r= ound trips. I am in favor of Dick's proposal(s) for re-scoping and revoking= existing tokens using the refresh token as credential. This would allow cl= ients to grab a refresh token then make one more call each to grab whatever= access tokens they wanted to. If you have multiple calls to get multiple tokens you still need client app= s to be capable of managing multiple tokens. At that point you have already= accepted the complexity. Whether the tokens are collected in multiple call= s or parsed from one response is not the complex part. I think the real argument is whether multiple tokens are a choice by the cl= ient app or a requirement by the server. If it is a choice by each client app, then some client apps could be a bit = simpler by choosing to only to use a single token. On the other hand, if a server is allowed to enforce multiple tokens (for d= ifferent content servers / scopes; for HTTP and HTTPS; for user-agents and = web-servers etc) then there is no avoiding support for multiple tokens in g= eneric OAuth2 client apps (and OAuth libraries in particular). I have some reluctance in supporting multiple tokens as, say, 50% of early = services might not use them initially. However there are enough real use ca= ses that I do think OAuth2 needs to support multiple tokens. If, in a few y= ears, 99% of services make do with a single token then no one will bother c= oding the extra complexity and code will trivially skip the extraneous "[" = and "]" around the token info (ie no harm done for service-specific apps; l= imited hassle for generic apps). More likely is that if we don't support mu= ltiple tokens a bunch of use cases can't be supported and an incompatible O= Auth3 will be needed next year (major harm for everyone). -- James Manger From lshepard@facebook.com Tue May 25 08:27:44 2010 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 A60133A6907 for ; Tue, 25 May 2010 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 OG4JCnRjpDT9 for ; Tue, 25 May 2010 08:27:43 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id B42AD3A68D8 for ; Tue, 25 May 2010 08:27:43 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4PFRDEc031393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 May 2010 08:27:13 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Tue, 25 May 2010 08:27:32 -0700 From: Luke Shepard To: "Manger, James H" Date: Tue, 25 May 2010 08:27:29 -0700 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr8HssdN6HEc+9YTR2n3KwVooomCg== Message-ID: References: <4BFAA6AB.8040809@lodderstedt.net>, <255B9BB34FB7D647A506DC292726F6E112639DC9C7@WSMSG3153V.srv.dir.telstra.com>, <255B9BB34FB7D647A506DC292726F6E11262FEE7D7@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11262FEE7D7@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-25_02:2010-02-06, 2010-05-25, 2010-05-25 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 15:27:44 -0000 Few responses on this topic: On May 25, 2010, at 7:08 AM, Manger, James H wrote: > Justin, >=20 >> I don't want to always have to grab "token[0]" from the response where b= efore i just grabbed "token". >=20 > Surely token[0] vs token is too trivial to be an issue. It's a pretty reasonable issue to raise. Extra complexity when not needed i= n the common case bogs down the spec. >> Also, this approach ties us to a hierarchical data representation format= like JSON instead of being able to use anything that can hand us simple ke= y-value pairs. Hashtables/dictionaries/associative-arrays are very easy to = manipulate and understand in many languages. >=20 > An array is even simpler than a hashtable. An array of hashtables is stil= l very easy to manipulate in any language. Info on any particular token can= still be a hashtable. A URL of a=3D1&b=3D2 is naturally a hashtable. There is no natural way to r= epresent arrays in URL parameters. PHP even converts normal arrays into has= htables. Generally it's much easier for developers to deal with simple key/= value pairs. > I have some reluctance in supporting multiple tokens as, say, 50% of earl= y services might not use them initially. Where do you get this stat from? Facebook has no need for multiple tokens, = and generally=20 > However there are enough real use cases that I do think OAuth2 needs to s= upport multiple tokens. If, in a few years, 99% of services make do with a = single token then no one will bother coding the extra complexity and code w= ill trivially skip the extraneous "[" and "]" around the token info (ie no = harm done for service-specific apps; limited hassle for generic apps). More= likely is that if we don't support multiple tokens a bunch of use cases ca= n't be supported and an incompatible OAuth3 will be needed next year (major= harm for everyone). As Justin suggested, I think it would be a good exercise to figure out how = your requirements could be represented as a backwards-compatible extension = instead of increasing complexity of the core spec. I'm confident that this = would not require a rewrite of the protocol. From hardjono@mit.edu Tue May 25 08:29:38 2010 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 D43223A6816 for ; Tue, 25 May 2010 08:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_50=0.001, 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 Ez3p-RiFxrGt for ; Tue, 25 May 2010 08:29:37 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 58D083A695D for ; Tue, 25 May 2010 08:29:37 -0700 (PDT) X-AuditID: 12074424-b7b9dae000002832-72-4bfbecd82cb2 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 9C.53.10290.8DCEBFB4; Tue, 25 May 2010 11:29:28 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4PFTSlI016043; Tue, 25 May 2010 11:29:28 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4PFTS57029310; Tue, 25 May 2010 11:29:28 -0400 Received: from oc11exhub3.exchange.mit.edu (18.9.3.13) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 25 May 2010 11:29:06 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub3.exchange.mit.edu ([18.9.3.13]) with mapi; Tue, 25 May 2010 11:29:27 -0400 From: Thomas Hardjono To: Dick Hardt Date: Tue, 25 May 2010 11:29:26 -0400 Thread-Topic: [OAUTH-WG] Access token opaqueness question Thread-Index: Acr7zn3OV6j+rym8Roiccd+EQQpTQgAQ901A Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BF8F775.8010603@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDCD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDD1D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <045D28A6-9691-4831-ACCE-526F8A551948@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3B8CDE23@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_DADD7EAD88AB484D8CCC328D40214CCD0178540444EXPO10exchang_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: OAuth WG Subject: Re: [OAUTH-WG] Access token opaqueness question 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, 25 May 2010 15:29:39 -0000 --_000_DADD7EAD88AB484D8CCC328D40214CCD0178540444EXPO10exchang_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The message flows within OAuth 2.0 are virtually identical to the Kerberos = protocol (RFC4120 and RFC1510). There is also significant overlap in functi= onality (e.g. OAuth token matches the Kerberos ticket, the Refresh Token ma= tches the TGT, etc). Since there is a huge install-base of Kerberos out there, we want to figure= out how to get the best interoperability between OAuth 2.0 and Kerberos. T= he scenario we think most probable is for organizations to stand-up an OAut= h front-end, while retaining their Kerberos infra in the back-end. What is the process in this Working Group to suggest ideas? Should I just = send to this list or write-up a draft? Thanks. /thomas/ __________________________________________ From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, May 25, 2010 1:53 AM To: Thomas Hardjono Cc: OAuth WG Subject: Re: [OAUTH-WG] Access token opaqueness question Not sure why you want to pull the OAuth token parameters from the Kerberos = token. Are you envisioning the Protected Resource is a Kerberos Client? On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono > wrote: I'm still a newbie to the OAuth and WRAP discussions, so please bear with m= e. In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is basi= caly an opaque structure to the client, but which can have some "internal s= tructure" (having meaning to the authz server and resource server): ] Access token strings can use any internal structure agreed upon ] between the authorization server and the resource server, but their ] structure is opaque to the client. Since the access token provides ] the client access to the protected resource for the life of the ] access token (or until revoked), the authorization server should ] issue access tokens which expire within an appropriate time, usually ] much shorter than the duration of the access grant. I was wondering how true this is? I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth C= lient need not understand this structure, but could simply pass it down to = the Kerberos-client (in the OS or in the browser). Then within this token (now a Kerberos ticket), the ticket fields would con= tain matching entries (as far as possible) to the OAuth token parameters (e= g. expires_in, token_secret, etc). For the cryptographic tokens (Section 5.3), I would then use the session-ke= y in the ticket to compute he HMAC. Would this work? Any suggestions? /thomas/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_DADD7EAD88AB484D8CCC328D40214CCD0178540444EXPO10exchang_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The message flows within OAuth 2.0 are virtually identical t= o the Kerberos protocol (RFC4120 and RFC1510). There is also significant over= lap in functionality (e.g. OAuth token matches the Kerberos ticket, the Refresh Token matches the TGT, etc).

 

Since there is a huge install-base of Kerberos out there, we want to figure out how to get the best interoperability between OAuth 2.0 a= nd Kerberos. The scenario we think most probable is for organizations to stand= -up an OAuth front-end, while retaining their Kerberos infra in the back-end.

 

What is the process in this Working Group to suggest ideas?  Should I just send to this list or write-up a draft?

 

Thanks.

 

/thomas/

 

 

__________________________________= ________

 

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, May 25, 2010 1:53 AM
To: Thomas Hardjono
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access token opaqueness question<= /span>

 

Not sure why you want to pull the OAuth token paramete= rs from the Kerberos token.

 

Are you envisioning the Protected Resource is a Kerber= os Client?

 

 

On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono <<= a href=3D"mailto:hardjono@mit.edu">hardjono@mit.edu> wrote:=


I'm still a newbie to the OAuth and WRAP discussions, so please bear with m= e.

In Section 2.2, draft-ietf-oauth-v2-05 states that the access token is basi= caly an opaque structure to the client, but which can have some "internal s= tructure" (having meaning to the authz server and resource server):

] Access token strings can use any internal structure agreed upon
] between the authorization server and the resource server, but their
] structure is opaque to the client.  Since the access token provides<= br> ] the client access to the protected resource for the life of the
] access token (or until revoked), the authorization server should
] issue access tokens which expire within an appropriate time, usually
] much shorter than the duration of the access grant.

I was wondering how true this is?

I want to use a Kerberos v5 ticket as the token (base encoded). The OAuth Client need not understand this structure, but could simply pass it down to= the Kerberos-client (in the OS or in the browser).

Then within this token (now a Kerberos ticket), the ticket fields would con= tain matching entries (as far as possible) to the OAuth token parameters (eg. expires_in, token_secret, etc).

For the cryptographic tokens (Section 5.3), I would then use the session-ke= y in the ticket to compute he HMAC.

Would this work?  Any suggestions?

/thomas/


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

 

--_000_DADD7EAD88AB484D8CCC328D40214CCD0178540444EXPO10exchang_-- From mscurtescu@google.com Tue May 25 10:30:01 2010 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 0812D3A63D3 for ; Tue, 25 May 2010 10:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.71 X-Spam-Level: X-Spam-Status: No, score=-104.71 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_20=-0.74, 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 TjGgXI763QTV for ; Tue, 25 May 2010 10:30:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2503E3A681F for ; Tue, 25 May 2010 10:29:59 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o4PHTjYt006900 for ; Tue, 25 May 2010 10:29:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274808587; bh=TzJgX4KC/p46wJupdiRnDK1Shu0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=D/NZCFrTDFFrG3vqRQtsVn90ienKHw4xqBBI18AQzXn6fKJJfCsCcURsbZej1Yj4U PznVpkEv3NDqfukMHhpTA== 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:content-transfer-encoding:x-system-of-record; b=hHWLzsHejNNNkGYDOAQJKVNnXD3jeZhDgh9mK64nFZu7uSe/Plhj6pihwqTiiTll1 kLhudtaY5QOsYQ7oX2ATQ== Received: from pva18 (pva18.prod.google.com [10.241.209.18]) by kpbe15.cbf.corp.google.com with ESMTP id o4PHTi24006793 for ; Tue, 25 May 2010 10:29:44 -0700 Received: by pva18 with SMTP id 18so1517990pva.31 for ; Tue, 25 May 2010 10:29:44 -0700 (PDT) Received: by 10.141.139.21 with SMTP id r21mr5621271rvn.2.1274808584115; Tue, 25 May 2010 10:29:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Tue, 25 May 2010 10:29:24 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112639DD01D@WSMSG3153V.srv.dir.telstra.com> References: <4BFAA6AB.8040809@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E112639DC9C7@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E112639DD01D@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Tue, 25 May 2010 10:29:24 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 17:30:01 -0000 On Mon, May 24, 2010 at 10:04 PM, Manger, James H wrote: >> How does the authz >> server know how to partition the scopes to the multiple tokens? One >> scope per token? What if an API requires multiple scopes? > > An AS will generally know a fair bit about the services for which it is i= ssuing access tokens -- at least which services require what sort of token. Ideally the AS should not have intimate knowledge of the services, that does not scale. Also, the client is requesting access to a set of scopes, and not to a set of services, not always the same thing. > For situations where the client app has more knowledge than the AS on how= tokens will be used, the client app could tell the AS how to partition tok= ens with another parameter in the user-uri (though OAuth2 doesn't necessari= ly have to standardise such a parameter now). I think this complicates the spec quite a bit. Down-scoping really solves the problem and keeps the spec simple. The only drawback is that extra calls are needed. Marius From mscurtescu@google.com Tue May 25 10:46:53 2010 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 2DA053A6927 for ; Tue, 25 May 2010 10:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.129 X-Spam-Level: X-Spam-Status: No, score=-100.129 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 7bvlpHl8ssXa for ; Tue, 25 May 2010 10:46:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 675943A6933 for ; Tue, 25 May 2010 10:46:51 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o4PHkZCq031109 for ; Tue, 25 May 2010 10:46:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274809596; bh=XvAi0mt8MAewTNR5YGsEAUNgZ9M=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=sdOwDPqiaJR0qC499+Rg7Zz+PisADnS93KLRG0m9QdOcGyc5ZAIPBbhE30gN4Znxq KS2tD1NWxM1bluXgbugUA== 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:content-transfer-encoding:x-system-of-record; b=WSPQumHcHmGbcsVUoQKSKiLfd9RuncNoQx29DFV9R8kDbh4V+C80BjXaKYG5StrqR 1rPmb0ImFon8yRnssdgrQ== Received: from pvg3 (pvg3.prod.google.com [10.241.210.131]) by kpbe12.cbf.corp.google.com with ESMTP id o4PHkXnr022231 for ; Tue, 25 May 2010 10:46:34 -0700 Received: by pvg3 with SMTP id 3so671993pvg.19 for ; Tue, 25 May 2010 10:46:33 -0700 (PDT) Received: by 10.141.124.18 with SMTP id b18mr5465728rvn.202.1274809593205; Tue, 25 May 2010 10:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Tue, 25 May 2010 10:46:13 -0700 (PDT) In-Reply-To: <50876A45-F34B-4C60-89F6-2CFA2EB29B8B@facebook.com> References: <50876A45-F34B-4C60-89F6-2CFA2EB29B8B@facebook.com> From: Marius Scurtescu Date: Tue, 25 May 2010 10:46:13 -0700 Message-ID: To: Luke Shepard 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: make it possible to get a verification code in the user-agent flow 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, 25 May 2010 17:46:53 -0000 On Sun, May 23, 2010 at 7:13 PM, Luke Shepard wrote= : > Brian - I like your proposal. It solves the refresh token problem and the= server-side auth in one go. > > Marius - your proposal would work great in a circumstance where you have = strong integration between JavaScript and the server, and they are both con= trolled by the same developer. In that case, sure, the developer could pass= the access token back to the front-end (although you would have a perf hit= ). > > However, the case that I'd like to solve (and what I read, Brian wants to= as well) is like this: > > - Client includes some Javascript from the relevant service (either Faceb= ook or Twitter @anywhere) > - The JS handles the auth flow and does some client-side API calls - for = example, Twitter displays hovercards on each username on the site, or Faceb= ook renders some profile pics > - The JS also passes a token down to the server - either in the cookies, = or perhaps directly via an Ajax call Isn't this suggesting a strong integration as well? > - The server can now independently make its own API calls if it wants, an= d gets a refresh token or whatever else it wants > > This allows for a single, general purpose JS library that handles auth fo= r both client and server applications - which is something that the web ser= ver flow by itself does not allow. I think that "Web Server" is a bit of misnomer. This flow can be used by native apps and also by JavaScript clients. The main difference between Web Server and User-Agent flows is that the former requires an extra direct call to swap the verification code. I could be missing something, but here is how I see how "User-Agent with optional verification code" can be implemented with the current spec: 1. JavaScript client starts Web Server flow with immediate off 2. user approves scopes 3. JavaScript receives verification code 4. JavaScript passes verification code down to client server 5. JavaScript does User-Agent flow with immediate on 6. JavaScript receives access token 7. JavaScript uses access token 8. When access token expires, go to 5. One problem, how does the JavaScript code know when to request a verification code, but this applies to the proposed enhanced User-Agent flow as well. Also, the proposed flow saves on one immediate call, that can be optimized by the client server returning an access token on the request that passes the verification code down. Not sure it is worth it. Does the above work? Marius - > > On May 21, 2010, at 5:50 PM, Marius Scurtescu wrote: > >> On Fri, May 21, 2010 at 1:46 PM, Brian Ellin wrote: >>> Marius, >>> I don't understand. =A0Will you elaborate on how specifically that woul= d work? >> >> Maybe I am missing something, but I was suggesting that the JavaScript >> code starts a web server flow at the end of which it has a >> verification code. It passes this verification code down to the client >> server, the client server swaps it for an access token and a refresh >> token and passes the access token to the JavaScript client. When the >> access token expires the client JavaScript has two options, ask the >> client server for a refresh or do an immediate request to that authz >> server. >> >> If you want that the client server and client JavaScript have tokens >> with totally different scopes, then you probably want to send the user >> for approval twice. If you just want the client JavaScript to have a >> token with a lesser scope (and avoid a second approval), then we >> should probably look into down-scoping, which currently is not >> supported. >> >> Would that work? >> >> Marius >> >> >>> Brian >>> >>> On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu >>> wrote: >>>> >>>> Why not use the web server flow in this case? >>>> >>>> I think it should work with un-registered clients as well (no client >>>> secret). >>>> >>>> Marius >>>> >>>> >>>> >>>> On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wro= te: >>>>> We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter. >>>>> =A0@anywhere is a pure javascript layer that developers can drop in t= o add >>>>> Twitter features to their website. =A0With the User-Agent flow, we is= sue >>>>> short >>>>> lived access tokens that refresh as they expire. =A0It works great fo= r >>>>> in-page >>>>> stuff, but many developers are also building server-side integrations >>>>> and >>>>> would love to have different longer lived access tokens on their serv= er. >>>>> =A0This is a common pattern that other connect-like services built on= top >>>>> of >>>>> OAuth 2.0 will also find necessary. >>>>> So, why not just use the access token issued by the User-Agent flow o= n >>>>> the >>>>> client server? =A0Overloading the use of that token is not desirable = for a >>>>> couple of reasons: >>>>> 1) The client server may not be using ssl, and as such the browser >>>>> cannot >>>>> securely transfer the access token to the server. >>>>> 2) The access token lifetime policy for the User-Agent flow may not >>>>> be desirable on the server. =A0Specifically, the server may need a to= ken >>>>> that >>>>> lasts for, say, two weeks instead of 15 minutes. =A0Additionally, the >>>>> token on >>>>> the server may have access to different resources that are >>>>> not desirable to >>>>> transmit to or through the browser. >>>>> In short, it is desirable to get two different access tokens from a >>>>> single >>>>> user authorization triggered by the User-Agent flow. >>>>> Proposal: >>>>> Make it possible to get a Web Server flow verification code from the >>>>> User-Agent client authorization request [1]. Specifically, add a new >>>>> optional parameter named "web_server_code" which when set to "true" >>>>> returns >>>>> a Web Server flow verification "code" field in the User-Agent >>>>> authorization >>>>> response. =A0The verification code can then be sent by the javascript >>>>> layer to >>>>> the client server, where it is then used to request an access token [= 2]. >>>>> Love to hear your feedback. >>>>> 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1 >>>>> 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2 >>>>> -- >>>>> Brian Ellin >>>>> Product Manager, Twitter Platform >>>>> http://twitter.com/brianellin >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>> >>> >>> >>> -- >>> Brian Ellin >>> Twitter Platform Team >>> http://twitter.com/brianellin >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > From torsten@lodderstedt.net Tue May 25 13:21:39 2010 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 893513A6A48 for ; Tue, 25 May 2010 13:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 rC+ZCa3rEXgp for ; Tue, 25 May 2010 13:21:37 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id D75733A68F5 for ; Tue, 25 May 2010 13:21:33 -0700 (PDT) Received: from p4fff0330.dip.t-dialin.net ([79.255.3.48] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OH0cu-0001Hh-4g for oauth@ietf.org; Tue, 25 May 2010 22:21:24 +0200 Message-ID: <4BFC3142.6010506@lodderstedt.net> Date: Tue, 25 May 2010 22:21:22 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <4BFAA6AB.8040809@lodderstedt.net> In-Reply-To: <4BFAA6AB.8040809@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 20:21:39 -0000 Thank you all for your feedback on my posting. I will answer in a single response. To start with I want to clarfiy where I come from and what way my thoughts went along. This will hopefully help to understand the limitation of OAuth2 I want to address. At Deutsche Telekom we provide a variety of IP-based services to our customers, for example e-Mail, calendar, contacts, web storage, Voice over IP (SIP), IP TV, Video on demand, personal video recorder and much more. More and more of these services are made available to the outside by way of REST or SOAP-based web services. Authorization is provided by a central token service, which issues user-related and self-contained security tokens clients use in subsequent services request to authorize on behalf of end-users. Our goal is that authorization of service access shall be possible w/o further interaction with identity management systems, which gives as maximum performance and scalability. Therefore every token contains the user attributes (like name) and permissions (e.g. the user is allowed to view channel X or has a web storage quota of 2GB) as required by a certain service. And every service has other requirements: For example, the EPG service needs all TV-channel-related permissions whereas the web storage service may require the respective storage-related permissions and quotas. For privacy reasons, the user identifiers in the tokens may also vary among services. Some service get access to universal identifiers whereas other services only get to know service-specific identifiers. Token security is based on digital signatures (HMAC because it's faster than public-key based signatures), encryption (in order to prevent clients from eavesdropping internal and personal data), token lifetime and audience. You might have guessed already, we orginally started w/ SAML assertions as token format. Now we also use a less noisy, bandwith-optimized binary token format. Our services are operated by various internal units or external partners - that's a business-driven decision and not a technical one. So operational security forces us to use different shared secrets for different services. Bottom line: there are plenty of different services with different characteristics needing different user data and permissions, operated by different organisations. We use self-contained tokens for performance and scalability reasons. Using a single token for all services is not an option in our landscape. For example, putting all permissions and attributes of a single user out of our user directory into one token would probably result in tokens with >100 KBytes in size. Probably it is a unique environment, but I don't believe that. Our current token service implementation is partially based on OAuth 1.0a and we intend to move towards OAuth2 when it becomes stable. Our current implementation (as the current OAuth2 draft, too) only supports the authorization of access to a single service. In the past I thought this would be an acceptable limitation since most (if not all) applications I know access a single service only. The OpenId Connect proposal made me reconsidering my opinion. As soon as a OpenID connect client needs to access other resources beside the user data service, there will be a need for more than one access token even for average clients (at least in our setup). And, combined clients are comming around the edge even here at Deutsche Telekom! For example, there is a client visualizing data from e-Mail and Webstorage in a single view. Our suppose our EPG client, which is used to program personal digital videorecorder at home from the smartphone. This client could be extended to add reminders into the users calendar for important live broadcasts (service: calendar), to send e-Mails with recommandations to friends (from contacts) using the e-Mail service. In the end, I think it is up to the client to compose services into end user applications. If we accept multi-service clients, the question is how will these clients be supported by the OAuth standard? With the current draft, the client has to send the user through the authz process n-times (n = number of services). This would look this: user accesses client REDIRECT AS Login at AS User Consent service 1 REDIRECT back get access token for service 1 REDIRECT AS SSO at AS User Consent service 2 REDIRECT back get access token for service 2 REDIRECT AS SSO at AS User Consent service 3 REDIRECT back get access token for service 3 What a user experience is that? And imagine such a use case for the device flow :-( Do we have other options to perform this process more user-friendly? First of all, how does the client request authorization for different services? As far as I see, the scope parameter is the only way to pass such information to the authorization server. So instead of mererly denoting permissions, we can use scopes as kind of service id + permissions. Which options do we have for returning tokens to the client? As proposed by Marius, the authorization server could issue a refresh token and the client could use the refresh request in combination with the downscoping feature in order to acquire access tokens. Consequences? In the setup illustrated above, the authorization server cannot create any access token (or an arbitrary one), it can only return a refresh token. This would mean to make the access token response parameter optional. Here I'm colliding with my mental picture of refresh tokens as long-living and storable tokens. Are these refresh tokens still long-living or as short-living as a Kerberos TGT? If they are still long-living, what about the use cases where we don't want to return refresh tokens? As far as I remember, user agent and username/password flow were candidates. How shall we handle them? Coming back to my original proposal: The authorization server could also issue multiple access tokens and (optionally) a refresh token - preserving the refresh token semantics. Justin pointed out that my original proposal added complexity to the simplest use case even if the authorization server does not issue multiple tokens. I understand your objection and would like to suggest a modified response structure. Instead of putting all access token into an array, the authz server could also use the structure as defined in the current draft and use another list of "additional_access_tokens", if more than one token has been created. HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkAB", "scopes":"calendar", "expires_in":3600, "refresh_token":"8xLOxBtZp8" additional_access_tokens = [{ "token":"SlAV32hkKG", "scopes":["calendar"], "expires_in":3600}, ...] } So in the simplest case, the response would look the same as before. HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkAB", "scopes":"calendar", "expires_in":3600, "refresh_token":"8xLOxBtZp8" } Thoughts? regards, Torsten. From mscurtescu@google.com Tue May 25 13:37:33 2010 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 DFCD83A6819 for ; Tue, 25 May 2010 13:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.377 X-Spam-Level: X-Spam-Status: No, score=-99.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 09PZedi9yYY3 for ; Tue, 25 May 2010 13:37:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A878B3A680A for ; Tue, 25 May 2010 13:37:32 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o4PKbKHB021540 for ; Tue, 25 May 2010 13:37:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274819841; bh=1MT1/nUmycQIaPwNl8Er8LkTOLc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cC66tE1Oy3PTnJOCYgBwGBEg1ZPAM2CDLe/XpGQCQuCeOT0NwDkaJ1M88+O5YtdJX 1sWPkhgp4sUiSoKdUeUNQ== 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=M09VOkT4DMMeIsYXE9PnoO1xFx3PdqwgODdvBDU1KtJJ30eS6m3K8U7TWks7Pr0Mz /b51vv34elFJ+Jqyh3eCA== Received: from pwj2 (pwj2.prod.google.com [10.241.219.66]) by wpaz5.hot.corp.google.com with ESMTP id o4PKbJIO022384 for ; Tue, 25 May 2010 13:37:19 -0700 Received: by pwj2 with SMTP id 2so169829pwj.39 for ; Tue, 25 May 2010 13:37:19 -0700 (PDT) Received: by 10.141.213.5 with SMTP id p5mr5743498rvq.14.1274819839106; Tue, 25 May 2010 13:37:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Tue, 25 May 2010 13:36:59 -0700 (PDT) In-Reply-To: <4BFC3142.6010506@lodderstedt.net> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> From: Marius Scurtescu Date: Tue, 25 May 2010 13:36:59 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 20:37:34 -0000 On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt wrote: > > As proposed by Marius, the authorization server could issue a refresh token > and the client could use the refresh request in combination with the > downscoping feature in order to acquire access tokens. > Consequences? > In the setup illustrated above, the authorization server cannot create any > access token (or an arbitrary one), it can only return a refresh token. This > would mean to make the access token response parameter optional. Here I'm > colliding with my mental picture of refresh tokens as long-living and > storable tokens. Are these refresh tokens still long-living or as > short-living as a Kerberos TGT? If they are still long-living, what about > the use cases where we don't want to return refresh tokens? As far as I > remember, user agent and username/password flow were candidates. How shall > we handle them? I think the authz server can create an access token that will grant access to all requested scopes, just as the corresponding refresh token. If the client intends to do down-scoping then it will probably just discard this initial access token. One way to ensure that the client is not lazy and it is not using the broadly scoped access token is to have services refuse access tokens that are not narrowed down to only what the service needs. Marius From torsten@lodderstedt.net Tue May 25 13:53:00 2010 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 DF2FD3A6D11 for ; Tue, 25 May 2010 13:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 x06BWbF7CmQt for ; Tue, 25 May 2010 13:53:00 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id D9E5E3A6D18 for ; Tue, 25 May 2010 13:46:28 -0700 (PDT) Received: from p4fff0330.dip.t-dialin.net ([79.255.3.48] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OH111-00031M-Jc; Tue, 25 May 2010 22:46:19 +0200 Message-ID: <4BFC371A.5040109@lodderstedt.net> Date: Tue, 25 May 2010 22:46:18 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 20:53:01 -0000 > > On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt > wrote: > >> As proposed by Marius, the authorization server could issue a refresh token >> and the client could use the refresh request in combination with the >> downscoping feature in order to acquire access tokens. >> Consequences? >> In the setup illustrated above, the authorization server cannot create any >> access token (or an arbitrary one), it can only return a refresh token. This >> would mean to make the access token response parameter optional. Here I'm >> colliding with my mental picture of refresh tokens as long-living and >> storable tokens. Are these refresh tokens still long-living or as >> short-living as a Kerberos TGT? If they are still long-living, what about >> the use cases where we don't want to return refresh tokens? As far as I >> remember, user agent and username/password flow were candidates. How shall >> we handle them? >> > I think the authz server can create an access token that will grant > access to all requested scopes, just as the corresponding refresh > token. If the client intends to do down-scoping then it will probably > just discard this initial access token. > > One way to ensure that the client is not lazy and it is not using the > broadly scoped access token is to have services refuse access tokens > that are not narrowed down to only what the service needs. > > Marius > As I said, every service in our setup needs another access token, with different content, signed and encrypted with another shared secret. It is technically impossible to create the super access token. Refresh tokens are just handles representing the user's authorization and are used by the authz server only. They therefore can represent any scope. regards, Torsten. From mscurtescu@google.com Tue May 25 14:13:12 2010 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 BE6BD3A7069 for ; Tue, 25 May 2010 14:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.377 X-Spam-Level: X-Spam-Status: No, score=-99.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 gsKx7rulCFWK for ; Tue, 25 May 2010 14:13:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C41753A706C for ; Tue, 25 May 2010 13:51:50 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o4PKpfM9028447 for ; Tue, 25 May 2010 13:51:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274820701; bh=tE8fz2TPVrlGnP+4oHiTA4DSXI4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=tTaT1D0my0fxCKEZAdyzGPpLfHH7nw8iiO81cBdtMs7tHsimfq1e6RpvJmw4p7it1 vOCgTjNXqCgiYnfhYWdCw== 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:content-transfer-encoding:x-system-of-record; b=aJGoLBxha/yTzzwAiMJB7fz/iJsgLjjaXyaGxFZQNpdoXkOChip4FQgf0tWmgQU8b lcd7fvYou8u5dfJ8ojeSA== Received: from pwi8 (pwi8.prod.google.com [10.241.219.8]) by hpaq7.eem.corp.google.com with ESMTP id o4PKpdVC024400 for ; Tue, 25 May 2010 13:51:40 -0700 Received: by pwi8 with SMTP id 8so434354pwi.3 for ; Tue, 25 May 2010 13:51:39 -0700 (PDT) Received: by 10.140.56.18 with SMTP id e18mr5719468rva.167.1274820699133; Tue, 25 May 2010 13:51:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Tue, 25 May 2010 13:51:19 -0700 (PDT) In-Reply-To: <4BFC371A.5040109@lodderstedt.net> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> From: Marius Scurtescu Date: Tue, 25 May 2010 13:51:19 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 25 May 2010 21:13:12 -0000 On Tue, May 25, 2010 at 1:46 PM, Torsten Lodderstedt wrote: >> >> On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt >> =A0wrote: >> >>> >>> As proposed by Marius, the authorization server could issue a refresh >>> token >>> and the client could use the refresh request in combination with the >>> downscoping feature in order to acquire access tokens. >>> Consequences? >>> In the setup illustrated above, the authorization server cannot create >>> any >>> access token (or an arbitrary one), it can only return a refresh token. >>> This >>> would mean to make the access token response parameter optional. Here I= 'm >>> colliding with my mental picture of refresh tokens as long-living and >>> storable tokens. Are these refresh tokens still long-living or as >>> short-living as a Kerberos TGT? If they are still long-living, what abo= ut >>> the use cases where we don't want to return refresh tokens? As far as I >>> remember, user agent and username/password flow were candidates. How >>> shall >>> we handle them? >>> >> >> I think the authz server can create an access token that will grant >> access to all requested scopes, just as the corresponding refresh >> token. If the client intends to do down-scoping then it will probably >> just discard this initial access token. >> >> One way to ensure that the client is not lazy and it is not using the >> broadly scoped access token is to have services refuse access tokens >> that are not narrowed down to only what the service needs. >> >> Marius >> > > As I said, every service in our setup needs another access token, with > different content, signed and encrypted with another shared secret. It is > technically impossible to create the super access token. Refresh tokens a= re > just handles representing the user's authorization and are used by the au= thz > server only. They therefore can represent any scope. I see, thanks for clarifying. Marius From kris.selden@gmail.com Tue May 25 14:11:17 2010 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 A95613A701F for ; Tue, 25 May 2010 14:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 swP4zc-2F2CC for ; Tue, 25 May 2010 14:11:15 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id C67F73A7024 for ; Tue, 25 May 2010 13:51:25 -0700 (PDT) Received: by pxi19 with SMTP id 19so2431503pxi.31 for ; Tue, 25 May 2010 13:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=+NAVHDQjeBijcVBxX8QMtuFp559DVhVLjY9tPqnE+QU=; b=t8hyWN06hoW5wS1ZkyHlbiAVeM0riXHjz58WYqUnCSpBWxbLhdvWLst6MougVseyb/ c98IEgSGME08fttL5JQL0CHW+mLEDeeYHuGF85VuOwQidvlu14WNlJw5nrISWlsxAw2j J9Bqzvu/CYT+pyHHz7xeoUfnW/lp7tVZwccJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MnEGa2p1V+oQWYxCLn6Jo5NzX92kPKqSU9z54XUeOEbrpTBF5gxlfdsTtyKvlfGOMY gPCbV/cmYA0TW33jFI4J7xMNQ7185+eE4zNmqbF9XvHUG3XFexG+9DEQ/VBZ+xIGkUD1 yant9UoWIfvA8zMzcfrpqTDeZLJRkH/3MlSSg= Received: by 10.115.39.40 with SMTP id r40mr6669410waj.183.1274820673576; Tue, 25 May 2010 13:51:13 -0700 (PDT) Received: from [10.210.5.147] (74-94-67-45-tacoma-wa.hfc.comcastbusiness.net [74.94.67.45]) by mx.google.com with ESMTPS id c1sm5445976wam.7.2010.05.25.13.51.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 13:51:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: <4BFB8D0B.8080408@pidster.com> Date: Tue, 25 May 2010 13:51:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <996D9B84-03D8-43B9-8441-FDE1B5A19F74@gmail.com> References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> <4BFB8D0B.8080408@pidster.com> To: pid@pidster.com X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Tue, 25 May 2010 15:16:34 -0700 Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 25 May 2010 21:11:17 -0000 Once again, I want to plea the case for keeping the response simple = key/value string pairs so it is trivial to serialize to multiple = formats. The OAuth endpoint should be able to match the format(s) of the = API it protects. Given this simple response payload, the spec can generically describe = how to serialize the string key/value pairs to = application/x-www-form-urlencoded, application/json and application/xml = with other formats added through extensions. Values that are lists can simply be a delimited string, with the = delimiter either a character that cannot be in the value (like space = delimited urls) or use a simple escaping mechanism described by the = spec. Integers can be spec'd as such and not rely on format spec. I = know, this means in JSON {"expires_in":"3600"} which gives people a rash = but helps make it trivial to decouple format. String encoding should be specified by the charset parameter of the = Content-Type header of the response. The client could indicate supported = charsets through Accept-Charset in the request. Likely this should match = how it is handled in the protected APIs. Anyway, let me digress a = little, which responses from an OAuth endpoint are even likely to run = into any problems with encoding -- what needs more than ASCII? Even if a = bearer token is in JSON you could still use \u escapes on a UTF8 encoded = JSON to reduce it to ASCII. Some of the arguments for JSON as the only format remind me of an = infomercial where they make a basic kitchen implement look harder to use = than it is, to exaggerate the need of their handy dandy slicer dicer = tool. No, there aren't a lot of libraries that do form decoding on the client = side (if it is a language that is only typically used on the client = side, is this anything but JavaScript or ActionScript?) but I can't = think of any that do not have decoding for percent encoding (which isn't = hard anyway) and the rest is trivial to parse. The headaches in OAuth 1.0 came from the signature base string's use of = percent encoding which is a separate issue from using = application/x-www-form-urlencoded as a response type. Making the OAuth endpoint any one format (unless that response type is = truly trivial to parse without 3rd party libraries) renders an APIs = support of multiple formats (which seems quite popular) pointless. On May 25, 2010, at 1:40 AM, Pid wrote: > On 25/05/2010 01:52, Dick Hardt wrote: >>=20 >> On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote: >>=20 >>> And to add to this, this example shows that encoding is hard, JSON >>> only solves decoding (in most cases, but not all). >>=20 >> JSON solves encoding and decoding with the same library. >>=20 >>>=20 >>> For all direct requests clients still need to encode and without a >>> library still need to figure what chars must be encoded. >>=20 >> You argued this point numerous times at the in-person meeting. = Clients are used to encoding and creating requests to servers. That is = what they do. There are many simple ways of doing this. >>=20 >> Clients in general do NOT decode forms data, that is done by servers, = and is built into server frameworks. >=20 > If one was feeling mischievous, one could argue that an implementer = only > needs to find or create a library for the client side, rather than = both > - like JSON. >=20 >=20 >>> Introducing JSON because dealing with form-encoded is hard does not >>> make much sense. As discussions last week showed (and earlier on = this >>> list), with JSON there is also the perception that it is easy to do = by >>> hand and that no escaping is needed. IMO that will lead to way more >>> problems. >>=20 >> Libraries exit for encoding and decoding JSON. They are really easy = to use. There is asymmetry in the forms data. Servers typically decode, = and clients typically encode. >=20 > I really don't think this is a reasonable argument in favour of JSON. > It's somewhat confusing to argue in favour of using an external = library > on one hand, but not the other. >=20 >=20 > The best summary of the arguments in favour of JSON was by Joseph = Smarr > in response to my previous inquiry, which hasn't been superseded, I = think. >=20 > However, IMO JSON is yet to be demonstrated as the better solution. >=20 >=20 > p >=20 >=20 >=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 From muralive@gmail.com Tue May 25 13:46:58 2010 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 EB4A43A6D60 for ; Tue, 25 May 2010 13:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 CafOnrk1wA1w for ; Tue, 25 May 2010 13:46:58 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 296523A6BC9 for ; Tue, 25 May 2010 13:44:15 -0700 (PDT) Received: by fxm6 with SMTP id 6so724705fxm.31 for ; Tue, 25 May 2010 13:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=3NKgGck7TnxMyIBd1O+BdDPD39ZtPfAbFFatfxceILc=; b=MCndTwYMh/CCvTmjghFBUQgePPNR5U5VjQoU9mGawA+u+adQ7LP5i8Lola/gEHM1M8 Kd1UYZZ1I2IWP8Lb4r9y/aQyKeZs/uwUNS5XhqeSAJ/7JPWR3Fivm6cEblpp7yX+1J+y Hmd0SVtQd/Q5rhAP1+m3gX2tmyhOk876ZBR9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=Vwo1mCwgLGCUR/3aRC425MCbVbg8Ssf7faSS144eFWXTrWOAJFSmPT3L1gRfGg+OZt pSCsT+yHOmSeo/LkyFc+kcWMrqGyz6HOC6I38p2yLVUwplZJFe0JH1rMn7gv9b+1RJ7Z dIuy0K3WhoAy5WXEqGGNNDMghyy7GXGtmkYs8= Received: by 10.204.48.212 with SMTP id s20mr2739768bkf.205.1274820240811; Tue, 25 May 2010 13:44:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.118.81 with HTTP; Tue, 25 May 2010 13:43:40 -0700 (PDT) From: Murali VP Date: Tue, 25 May 2010 13:43:40 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=00032555691e9bacd60487713794 Subject: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) 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, 25 May 2010 23:00:10 -0000 --00032555691e9bacd60487713794 Content-Type: text/plain; charset=ISO-8859-1 Anyway to find out what the outcome was from the May 20th interim meeting? I wanted to participate but had to be at Google I/O. 3.5. User-Agent Flow 1. Since the client_id is public, the only check that prevents from any client posing as a registered client is the redirect_uri, this is fine, except that if client web application has numerous domains, each domain should register and have a separate client_id which is a pain. The alternative of a single redirect_uri returning a 302 won't work since the fragment will no more be available (I guess there are ways to get around this). 2. It is not clear from the draft how a user agent flow would refresh an access token. As per section 4, client does a HTTP(S) POST to authorization server which seems to return a 200 to user-agent if the request was successful leaving the user-agent in authorization server's domain with a JSON response data! If user-agent flow cannot refresh access token, why did it send the refresh_token in the first place in the fragment? 3. The draft doesn't seem to mention how a client in the user-agent can make protected resource requests given that such requests would be cross domain. The only viable option seems to be JSONP requests (eg. Facebook). The specification should include some material describing protected resource requests in the user-agent flow case. A relatively less important question: Since the request token has been eliminated, the web server flow (3.6) which comes close to the widely adopted OAuth 1.0's 3-legged oauth flow but without much of a dance isn't backward compatible, is this a known decision? --00032555691e9bacd60487713794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anyway to find out what the outcome was from the May 20th interim meeting? = I
wanted to participate but had to be at Google I/O.

3.5. =A0User-Agent Flow

1. Since the client_id is public, the only check that prevents from
any client posing as a registered client is the redirect_uri, this is
fine, except that if client web application has numerous domains, each
domain should register and have a separate client_id which is a pain.
The alternative of a single redirect_uri returning a 302 won't work
since the fragment will no more be available (I guess there are ways
to get around this).


2. It is not clear from the draft how a user agent flow would refresh
an access token. As per section 4, client does a HTTP(S) POST to
authorization server which seems to return a 200 to user-agent if the
request was successful leaving the user-agent in authorization
server's domain with a JSON response data! If user-agent flow cannot refresh access token, why did it send the refresh_token in the first
place in the fragment?


3. The draft doesn't seem to mention how a client in the user-agent
can make protected resource requests given that such requests would be
cross domain. The only viable option seems to be JSONP requests (eg.
Facebook). The specification should include some material describing
protected resource requests in the user-agent flow case.


A relatively less important question:

Since the request token has been eliminated, the web server flow (3.6)
which comes close to the widely adopted OAuth 1.0's 3-legged oauth
flow but without much of a dance isn't backward compatible, is this a known decision? --00032555691e9bacd60487713794-- From mscurtescu@google.com Tue May 25 18:21:00 2010 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 61FF63A6835 for ; Tue, 25 May 2010 18:20:56 -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 QpQO39rNb66n for ; Tue, 25 May 2010 18:20:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CDF563A6847 for ; Tue, 25 May 2010 18:20:35 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o4Q1KItB017016 for ; Tue, 25 May 2010 18:20:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274836821; bh=CpY4sNCrfXwFr2eEWuerZh5DmVM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZrKbkuYRMLyMfscIpJ2rJmDW4KQfD6ZpJS+JpcFycM/H1nXZ1AplCYofkyPz9N1XJ ZIxcsQs2DKFORnwbUnTqA== 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=bLto4bAdTPV/aLuiH+nav2/mDOfjXhjoPR9PR2H8NBhxkj6+W02ui7TVRmY93qHCM QlNCNX2rMn1ivRrA3tBlQ== Received: from pxi10 (pxi10.prod.google.com [10.243.27.10]) by wpaz24.hot.corp.google.com with ESMTP id o4Q1KGjw012824 for ; Tue, 25 May 2010 18:20:17 -0700 Received: by pxi10 with SMTP id 10so3495402pxi.35 for ; Tue, 25 May 2010 18:20:16 -0700 (PDT) Received: by 10.141.14.6 with SMTP id r6mr5887121rvi.69.1274836815141; Tue, 25 May 2010 18:20:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Tue, 25 May 2010 18:19:55 -0700 (PDT) In-Reply-To: <4BFB8D0B.8080408@pidster.com> References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> <4BFB8D0B.8080408@pidster.com> From: Marius Scurtescu Date: Tue, 25 May 2010 18:19:55 -0700 Message-ID: To: pid@pidster.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 26 May 2010 01:21:00 -0000 On Tue, May 25, 2010 at 1:40 AM, Pid wrote: > > The best summary of the arguments in favour of JSON was by Joseph Smarr > in response to my previous inquiry, which hasn't been superseded, I think. Yes, Joseph made a very good argument for JSON. My only objection is that form-encoded is still used in several places, so the problems are still not solved, and now clients have to deal with 2 encodings. I know that there is disagreement on this, but I have not seen a good proof that this is not true. Marius From atom@yahoo-inc.com Tue May 25 18:43:45 2010 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 927D53A67A3 for ; Tue, 25 May 2010 18:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.602 X-Spam-Level: X-Spam-Status: No, score=-13.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] 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 Cerf9iR-kcgu for ; Tue, 25 May 2010 18:43:38 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id E4A403A65A6 for ; Tue, 25 May 2010 18:43:37 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4Q1gd1q084604; Tue, 25 May 2010 18:42:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type:x-originalarrivaltime; b=ZHzR15IOUHotcbcB6c9BUM5t25iFz8U+vSOrvQw/0stp4OsdfAiLbKUyd3156Pu1 Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 May 2010 18:42:39 -0700 Received: from 172.21.148.15 ([172.21.148.15]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 May 2010 01:42:18 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 25 May 2010 18:42:15 -0700 From: Allen Tom To: Eran Hammer-Lahav , Luke Shepard , Dick Hardt , OAuth WG Message-ID: Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr7eYnIafuy+UGKQiayN31iyjqyLQAAtxBgAD4RQho= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3357657736_40539993" X-OriginalArrivalTime: 26 May 2010 01:42:39.0113 (UTC) FILETIME=[B971CF90:01CAFC74] Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 26 May 2010 01:43:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3357657736_40539993 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Yahoo=B9s security team has concerns regarding the immediate mode and shared computers. Consider the case where a browser based JS app is running in a browser tab with credentials belonging to a particular user. While the app is still running, the original user lets a friend borrow the browser. The friend opens another tab, logs the original user out of the Service Provider, and then logs in as different user using the friend=B9s account. At this point =AD the app is still running as the original user a different tab. If the app=B9s credentials expire, it could attempt an immediate request to refresh them =AD which could then return the credentials belonging to the 2nd user. Since this is a JS app =AD the data that belongs to the first user is already loaded, so the app could start co-mingling the data between the two users. At Yahoo, we call this scenario =B3crossing the streams=B2 - and that=B9s always a really bad thing. This scenario could be really disastrous if the SP has a login CSRF vulnerability =AD meaning that an attacker can CSRF the victim=B9s browser into logging in with the attacker=B9s account. This vulnerability would result in the victim=B9s data mixing with the Attacker. One possible way to prevent this issue is for the client to pass the user=B9s identifier (or access token/refresh token/etc) in the immediate request. Allen On 5/24/10 1:05 PM, "Eran Hammer-Lahav" wrote: > I am more interested in how you plan to address the (long term) security = and > privacy issue: who is responsible to prevent one user in getting an acces= s > token for another in a shared computer environment. As long as the user g= oes > to facebook.com, you show they who is logged in clearly, so if it is not = them, > they can log out. >=20 > But using immediate without a username, it sounds to me like you expect t= he > client to do the right thing. Is this how you plan to address this? Ask t= he > client to find out whose access token it got, display it to the user, and > allow them to correct this? Especially given that at this point the clien= t > account is already =B3paired=B2 with the access token. >=20 > EHL >=20 >=20 > On 5/24/10 12:44 PM, "Luke Shepard" wrote: >=20 >> Suppose the client does not have a username - say, because the cookie >> expired. What is the appropriate behavior? >>=20 >> Would you require the client to spawn a popup or redirect to a full page= auth >> every time a user revisits their site? This doesn't make sense. >>=20 >> Under what circumstances do you think the client gives an access token t= hat >> belongs to another user? If the user is logged into the service provider= , >> then they can get that access token anyway by just visiting the service >> provider ... >>=20 >> On May 24, 2010, at 11:18 AM, Dick Hardt wrote: >>=20 >>> > >>> > On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote: >>> > >>>> >> >>>> >> >>>>> >>> -----Original Message----- >>>>> >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>>>> >>> Sent: Monday, May 24, 2010 7:35 AM >>>>> >>> To: Eran Hammer-Lahav >>>>> >>> Cc: OAuth WG (oauth@ietf.org) >>>>> >>> Subject: Re: [OAUTH-WG] 'immediate' without identity >>>>> >>> >>>>> >>> You were looking for use cases for immediate without identity. >>>>> >>> >>>>> >>> I agree that *if* the client does know the user, then it should t= ell >>>>> the server. >>>>> >>> Are you saying that if the client does not know the user it shoul= d not use >>>>> >>> immediate? >>>> >> >>>> >> I think the server should reject an immediate request without a >>>> username. Otherwise the server will be giving the client an access tok= en >>>> that belongs to another user. >>> > >>> > Now I understand. I agree. >>> > >>> > -- Dick >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --B_3357657736_40539993 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] 'immediate' without identity Yahoo’s security team has concerns regarding the immediate mode and = shared computers.

Consider the case where a browser based JS app is running in a browser tab = with credentials belonging to a particular user. While the app is still runn= ing, the original user lets a friend borrow the browser. The friend opens an= other tab, logs the original user out of the Service Provider, and then logs= in as different user using the friend’s account.

At this point – the app is still running as the original user a diffe= rent tab. If the app’s credentials expire, it could attempt an immedia= te request to refresh them – which could then return the credentials b= elonging to the 2nd user. Since this is a JS app – the data that belon= gs to the first user is already loaded, so the app could start co-mingling t= he data between the two users.

At Yahoo, we call this scenario  “crossing the streams” - = and that’s always a really bad thing.

This scenario could be really disastrous if the SP has a login CSRF vulnera= bility – meaning that an attacker can CSRF the victim’s browser = into logging in with the attacker’s account. This vulnerability would = result in the victim’s data mixing with the Attacker.

One possible way to prevent this issue is for the client to pass the user&#= 8217;s identifier (or access token/refresh token/etc) in the immediate reque= st.

Allen


On 5/24/10 1:05 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I am more interested in how you plan to address = the (long term) security and privacy issue: who is responsible to prevent on= e user in getting an access token for another in a shared computer environme= nt. As long as the user goes to facebook.com, you show they who is logged in= clearly, so if it is not them, they can log out.

But using immediate without a username, it sounds to me like you expect the= client to do the right thing. Is this how you plan to address this? Ask the= client to find out whose access token it got, display it to the user, and a= llow them to correct this? Especially given that at this point the client ac= count is already “paired” with the access token.

EHL


On 5/24/10 12:44 PM, "Luke Shepard" <lshepard@facebook.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Suppose the client does not have a username - sa= y, because the cookie expired. What is the appropriate behavior?

Would you require the client to spawn a popup or redirect to a full page au= th every time a user revisits their site? This doesn't make sense.

Under what circumstances do you think the client gives an access token that= belongs to another user? If the user is logged into the service provider, t= hen they can get that access token anyway by just visiting the service provi= der ...

On May 24, 2010, at 11:18 AM, Dick Hardt wrote:

>
> On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Dick Hardt [mailto= :dick.hardt@gmail.com]
>>> Sent: Monday, May 24, 2010 7:35 AM
>>> To: Eran Hammer-Lahav
>>> Cc: OAuth WG (oauth@ietf.org)
>>> Subject: Re: [OAUTH-WG] 'immediate' without identity
>>>
>>> You were looking for use cases for immediate without identity.=
>>>
>>> I agree that *if* the client does know the user, then it shoul= d tell the server.
>>> Are you saying that if the client does not know the user it sh= ould not use
>>> immediate?
>>
>> I think the server should reject an immediate request without a us= ername. Otherwise the server will be giving the client an access token that = belongs to another user.
>
> Now I understand. I agree.
>
> -- Dick
>
> _______________________________________________
> 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
--B_3357657736_40539993-- From atom@yahoo-inc.com Tue May 25 19:00:37 2010 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 44F303A67A2 for ; Tue, 25 May 2010 19:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.134 X-Spam-Level: X-Spam-Status: No, score=-14.134 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] 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 jNAvQSDa69Y6 for ; Tue, 25 May 2010 19:00:35 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 9D20D3A6784 for ; Tue, 25 May 2010 19:00:35 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o4Q1wQng079685; Tue, 25 May 2010 18:58:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:return-path:x-originalarrivaltime; b=VZrRh3qbZ3RPo8faE/X9j2w5G7sMS+/EnR/GeneCS7eV59nwaT5Dc0wdzpN9/UoV Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 May 2010 18:56:44 -0700 Received: from 172.21.148.15 ([172.21.148.15]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 May 2010 01:56:09 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 25 May 2010 18:56:06 -0700 From: Allen Tom To: "Richer, Justin P." , Dirk Balfanz , OAuth WG Message-ID: Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr4dbWDj+nMDy6TTqWPCApNuWCL5gAnYzSeANjWA/A= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 May 2010 01:56:44.0080 (UTC) FILETIME=[B1158B00:01CAFC76] Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 02:00:37 -0000 +1 I fully agree with Dirk and Brian that there needs to be some work on signatures. There are many types of applications that require higher levels of security than what bearer tokens can provide. That being said, I think that bearer token/refresh token model can satisify the majority of use cases - in fact it would satisfy 100% of all public APIs that we have at Yahoo. Perhaps in the interest of keeping the spec focused, it would make more sense to split out a Signed Token Spec, as Justin proposes, that is focused solely on uses cases that require a signature? Allen On 5/21/10 11:27 AM, "Richer, Justin P." wrote: > I have a slightly more radical proposal. What if we factor out the signed > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given > the same attention by the group and all that like Eran was talking about > yesterday. What this would take is taking out all reference to signing and > making core OAuth just about bare tokens, then have a separate spec that > details what to call your shared secret parameters, how to get them, and how > to sign with them. This makes the core spec a lot simpler (as detailed below) > but makes the overall use case of using signed tokens more complicated to > follow, as it'd be split in two. > > -- justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > Balfanz [balfanz@google.com] > Sent: Thursday, May 20, 2010 7:39 PM > To: OAuth WG > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away with > base string canonicalization, (2) allow for symmetric and public keys, and (3) > allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal by > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would > work both with the signing mechanism in the current spec, as well as with > Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easier to > implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put together by > Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from the > spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then X, > else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like this: > > "Servers may require that requests be authenticated by the Client, so that > presentation of the access token alone is not sufficient to access a Protected > Resource. This has several use cases, including, but not limited to, the > following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access tokens > may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. The > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, then > the Client uses the following mechanism to sign their HTTP requests: [...]" > > Then, we basically drop the old Section 5.3 here (except we use the client > secret instead of the access token secret). Eventually, instead of Section > 5.3, we may have Brian's new signature scheme section here, which would add > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieved > once we have public-key crypto. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From atom@yahoo-inc.com Tue May 25 19:17:52 2010 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 87B623A67F6 for ; Tue, 25 May 2010 19:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.868 X-Spam-Level: X-Spam-Status: No, score=-13.868 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] 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 zXACnNbYQj-8 for ; Tue, 25 May 2010 19:17:46 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 3873A3A67A3 for ; Tue, 25 May 2010 19:17:37 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4Q2GoHU098667; Tue, 25 May 2010 19:16:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type:x-originalarrivaltime; b=1nGZsJQDUAGAeS7Q+cy1ZQyLqERJqK/hX8w2Z1QKSWpDA20fifik4pN9xWFl+GUG Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 May 2010 19:16:50 -0700 Received: from 172.21.148.15 ([172.21.148.15]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 May 2010 02:16:39 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 25 May 2010 19:16:35 -0700 From: Allen Tom To: Murali VP , Message-ID: Thread-Topic: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) Thread-Index: Acr8eXbtpcv6DZ2txkSn7M0JCOEspQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3357659797_40704949" X-OriginalArrivalTime: 26 May 2010 02:16:50.0385 (UTC) FILETIME=[80191410:01CAFC79] Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) 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, 26 May 2010 02:17:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3357659797_40704949 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Yes =AD one of the design goals for Oauth-WRAP was to eliminate the request token.=20 It is very tricky for SPs to implement the Request Token due to data replication issues. The Request token could be issued to the client in one data center, and then immediately submitted by the browser to a different data center. This means that the data has to be very quickly replicated. On the client side of things, if the AS=B9s approval screen is displayed in a popup window (like Facebook Connect) - it could be tricky to tricky for the client to pre-fetch the request token before displaying the =B3Connect=B2 butto= n in order to get around popup blockers. Allen On 5/25/10 1:43 PM, "Murali VP" wrote: >=20 > A relatively less important question: >=20 > Since the request token has been eliminated, the web server flow (3.6) > which comes close to the widely adopted OAuth 1.0's 3-legged oauth > flow but without much of a dance isn't backward compatible, is this a > known decision? --B_3357659797_40704949 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05)= Yes – one of the design goals for Oauth-WRAP was to eliminate the re= quest token.

It is very tricky for SPs to implement the Request Token due to data replic= ation issues. The Request token could be issued to the client in one data ce= nter, and then immediately submitted by the browser to a different data cent= er. This means that the data has to be very quickly replicated.

On the client side of things, if the AS’s approval screen is displaye= d in a popup window (like Facebook Connect) - it could be tricky to tricky f= or the client to pre-fetch the request token before displaying the “Co= nnect” button in order to get around popup blockers.

Allen


On 5/25/10 1:43 PM, "Murali VP" <= muralive@gmail.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>
A relatively less important question:

Since the request token has been eliminated, the web server flow (3.6)
which comes close to the widely adopted OAuth 1.0's 3-legged oauth
flow but without much of a dance isn't backward compatible, is this a
known decision?
--B_3357659797_40704949-- From James.H.Manger@team.telstra.com Wed May 26 00:20:08 2010 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 8C6093A6861 for ; Wed, 26 May 2010 00:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHOwjV-C6JZN for ; Wed, 26 May 2010 00:20:07 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id E24A53A68A2 for ; Wed, 26 May 2010 00:20:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,303,1272808800"; d="p7s'?scan'208";a="3247929" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 26 May 2010 17:19:55 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5993"; a="2502350" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccni.tcif.telstra.com.au with ESMTP; 26 May 2010 17:19:55 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 26 May 2010 17:19:55 +1000 From: "Manger, James H" To: Kris Selden Date: Wed, 26 May 2010 17:19:54 +1000 Thread-Topic: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) Thread-Index: Acr8V/O9L0tVKmo6TWSjVb3jLwJPlgALY8mA Message-ID: <255B9BB34FB7D647A506DC292726F6E11263A5327B@WSMSG3153V.srv.dir.telstra.com> References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> <4BFB8D0B.8080408@pidster.com> <996D9B84-03D8-43B9-8441-FDE1B5A19F74@gmail.com> In-Reply-To: <996D9B84-03D8-43B9-8441-FDE1B5A19F74@gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000B_01CAFCF7.A808EF80" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 26 May 2010 07:20:08 -0000 ------=_NextPart_000_000B_01CAFCF7.A808EF80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Kris, > The OAuth endpoint should be able to match the format(s) of the API it > protects. I had a quick look at the APIs for 24 services implementing OAuth (v1 or drafts of v2) as listed on the OAuth wiki. Of these 24 APIs, the response formats supported were: * 21 XML * 19 JSON * 16 XML and JSON * 5 XML only * 3 JSON only Other formats with some support: Atom, RSS, PHP, JSONP, CSV, vCards, FastInfoset, XML-RPC. None use form-encoding for responses. > Once again, I want to plea the case for keeping the response > simple key/value string pairs so it is trivial to serialize to multiple > formats. Most APIs from this sample offer multiple formats. None restricted themselves to simple key/value string pairs. None attempt to serialize to a format with as little structure as form-encoding. Where OAuth2 differs from most APIs is that it offers a response over 2 different "channels": an HTTP response body (as APIs do); and in a HTTP redirect (which most APIs don't do). If we really want to match the formats of the API being protected, then the HTTP redirect channel should tunnel exactly the same response that could be obtained in an API-like response body. Putting base64url-encoded XML or JSON in the redirect URI is one way to do such tunnelling. Its not the simplest solution for the simplest use case, but it is clear and future-proof. -- James Manger ------=_NextPart_000_000B_01CAFCF7.A808EF80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIc2jCCBqMw ggSLoAMCAQICEClsBJZEfCC2SncEyz0UzYEwDQYJKoZIhvcNAQEFBQAwGjEYMBYGA1UEAxMPVGVs c3RyYSBSb290IENBMB4XDTA5MTExNjA0NTkxM1oXDTM0MTExNjA1MDYxMVowGjEYMBYGA1UEAxMP VGVsc3RyYSBSb290IENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA3r3Fb5E/8GUk cHwd9/kRB14EH1trG6C7NrwmF7isLj3j8fbELwkg0Lm0qzVuYziwqC3sbB4BcpY1YU9UZfB8J7cO Efbk1GkVkSwNnpKyUHsxAWAelb0eOord3bB21M2UeUyWkGQhoU3+ZxyaAALKDm1QZQx7Tw8wdkIQ mc1mJ4cJg/I9dTk1J5ybG4ZWs4/87PnLe0A5KRD841YWeKO1oLrV6Zvj65Aa6gpme0AdLVEDStM/ 4jNtso6jf63ixizKzazfbt5lJJZizGHelymCF2BGjps0+6eMsteMmfQ84OXG82V00pFy6kwGjH6+ Y081OXTo6Gq/sR+6d4RDFIltIYGyYKKBzsEGw2MJqxqyXat9UV/50xspN26BZlB5zHFNdKI9eBKC sv6EpgklYSfv9vgNBBnwavHmGvmw12i0NUd9WlS3YybQzxnWE49Q05jIxt+ZgV4Rg6oiCRb7rktN d8qwRUb0LcSfcYOqGGffuckNQzKGNGySrkznOrC33BsVEmGMgXGqtZk4L7Sfq5NL1y7wCJUKw8qI Ox/ijs0SSfc9VDwqZmhEM9NV8sGUsvmTeH1D8G06zjmE6loXUyIQXZLohQQ96TQyjKuA3lvtCbJt yHFbgyi8wVJG+Ze3+Ywo+JB10rlR7FF6XEniihJEIYAHkSsGRqOASUzBA7p2Ip8CAwEAAaOCAeMw ggHfMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1UdDgQWBBSXNqRMMI9eSlUu k+RwLu+s1mV3iDAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwDQYJKoZIhvcNAQEFBQADggIBAHZuKnwg4R4Fk32A fxTzTHtDboZI1ZW3Yv7nSdqfZlnfF8bEAD6FSEoMJ0w6jProxVXSZwia5Fkhf4jt6M949PP+G5Cl V89x3z8pECqJhbVcZbE9p1hJXPy72IwILRblSnTnPh9CTLV0gTOkmX6SmrDMG3GSV3djTt8cf88o JTcbRe0vJgFwf5sPlMEplrK3tK0pIjomzcoGLfP9Zv+wvVLvGvu5TVxWiFIQrdtuUjzL3/2VxFb4 M5kLQaQCaxTOxcB/8epSyaInbLI1YsyhRtPyzCAT0pbTTPKR3eNgMF7YlzakASa5LbiTkWIayS8h s+MjkqIF9CX1PwOBphQgJa3yPm4bIfNBGH4520knrb5r/D/cTDtjarXh4v/ExJphEqbU6m44C4Wq Cp7jV3v6Xm91QaQbCF/e4H4RD9PTr/c+MILhmhEq879n6iF6276oe2kWZE0yXy8eiK5Ung0F2tJX PfQidNaI9NTMHViQoacVY9ah/juHnEIrnEozrYuMLqC+39i9BXAIQ4Qq7GJ132xr5o8/xb2iQ1IZ wD27yb7Or1gzcKjKvJj/pkCeDgC7fQVlxtvfDBjiKuAoWs7PXGTtGzfiObrnEmhmR0DnWSehA5ld o3/fyiGuyN53nU+ewQY4AyE8jBzPxq6YmVjWM0FAdyJLHyX+YBvYjs2VAX2cMIIG6jCCBNKgAwIB AgIKYQWDvgAAAAAABTANBgkqhkiG9w0BAQUFADAaMRgwFgYDVQQDEw9UZWxzdHJhIFJvb3QgQ0Ew HhcNMDkxMTI1MDEyNDI3WhcNMTkxMTI1MDEzNDI3WjBDMSQwIgYDVQQKExtUZWxzdHJhIENvcnBv cmF0aW9uIExpbWl0ZWQxGzAZBgNVBAMTElRlbHN0cmEgUG9saWN5IENBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAK3IBZQGtMLEw5e8k3SJcSRf/BnMWwguu1Ltka6XK/nmcmjTOPl/ qqpkC2uBZUFZAflrWJdmh5MTamCWNMsRSmtiWwSJQsFTPWstSRELqkuM0+lXIlTTU4dTFM3cp/pE l4ly+xBUd6ndQQeB/MOsTsbdkhALj/oMZzSSVLJw3cngrS4pG9TjV8zKMIkZQBeIURBgqh1yd6nX n1FNctjyDH1ybxftcuhK3hEEbPrAHJQB9YN317l7ISYqg99jec/3mVf0C1fOuzefKHGINXo8M2lL H3P4O28fSmaLyJK3p6IStoRmtrHwIkc9WHnDe0e9aieQx+PPosll61EtyJiaRX0CAwEAAaOCAwcw ggMDMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFJT5/udCeR3rxZ9HUpfHV7X4nD4oMAsG A1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADCCAYkGA1UdIASCAYAwggF8MIIBeAYMKwYBBAGI QAQbAQEBMIIBZjCCASAGCCsGAQUFBwICMIIBEh6CAQ4ARgBvAHIAIABhACAAYwBvAHAAeQAgAG8A ZgAgAHQAaABlACAAVABlAGwAcwB0AHIAYQAgAFAASwBJACAAQwBQAFMALAAgAGMAbABpAGMAawAg AE0AbwByAGUAIABJAG4AZgBvAC4AIABGAG8AcgAgAEMAUABTACAAcQB1AGUAcgBpAGUAcwAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAEcAbwB2AGUAcgBuAGEAbgBjAGUAIABDAG8AdQBuAGMAaQBs ACwAIABFAG0AYQBpAGwAOgAgAFQAZQBsAHMAdAByAGEALgBQAEcAQwBAAHQAZQBhAG0ALgB0AGUA bABzAHQAcgBhAC4AYwBvAG0wQAYIKwYBBQUHAgEWNGh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVs c3RyYS5jb20uYXUvVGVsc3RyYUNQUy5wZGYwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYD VR0jBBgwFoAUlzakTDCPXkpVLpPkcC7vrNZld4gwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwUm9vdCUyMENBLmNybDCBlQYI KwYBBQUHAQEEgYgwgYUwSQYIKwYBBQUHMAKGPWh0dHA6Ly90ZWxzdHJhLXBraS5wa2kudGVsc3Ry YS5jb20uYXUvVGVsc3RyYSUyMFJvb3QlMjBDQS5jcnQwOAYIKwYBBQUHMAGGLGh0dHA6Ly90ZWxz dHJhLW9jc3AucGtpLnRlbHN0cmEuY29tLmF1L29jc3AvMA0GCSqGSIb3DQEBBQUAA4ICAQDIYtRV XKCxl7sydCNMtC6BCJXmw7pgGswnfIDNCOF/XKTNA+5xY1+VchlRI1iWb4q15YToT6EEKXJPdWdv pO+atxyMMUScQCmZM5mW1PpbMGzXRrTL3LbDhDRaLWYD15+Wt2rgNU++iiIVA363TdgCllY3ync7 GzknJGdTl+0BEen2d4juqf0GWURu/KICxyt0YOYgoDe1O3mYbJJ4RjOOFc3lTkGPgwagtJNP22yq CcJ776pzvaa6qMTMEqzAgM5X6o6Yhp8zXHOU0M0x4/pJGb8PswKhzFi7F1TWKf0zmoKlpvAUV39U P0F8oPyMYjYPDYyBsRiaZ7iRUH1u01bPQ8XXt1jmDemXxO9w4d//Kp1qark3rcUZLi6FC4QPg0Rp S9rLWAPBDHqqFKi6mAU2W8nGWj3yY6/FI2dBPSGsxY0W2KUiEbEvgN534SPgZxJd1QT2x2CEUy1x x98EBpBZCkNQN1pMo3k3CaMn14ychHd3Y544+8UD0IYWaGzbrWiEBlcHca0yg7+F0Wu3Jln4DRM+ G0MlsB9Nq5J4YvgtX3ao0V7q+nA6oEV0TX3nPl1K99b6Xou4lILRg+/siOSIwsf+xTlaiLMntO2+ evRHTSJTPwR2H1LQQIuVatkBnTx3Yh28zMP1ge+hNLU66RHEez2mE+LktzmpQdysO8UGEzCCB0Qw ggYsoAMCAQICCjvNhgsAAAAAAEwwDQYJKoZIhvcNAQEFBQAwfDETMBEGCgmSJomT8ixkARkWA2Nv bTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzARBgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJ k/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJhIFVzZXIgSXNzdWluZyBDQTEwHhcNMTAwMzMw MjI1MzEzWhcNMTEwMzMwMjI1MzEzWjASMRAwDgYDVQQDEwdjNzk5ODc4MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA177RZ1A0Y6bicGyF7owW1qoXjfivAcx6I7POmUXIto2pUR2uNYYv Q7e1W74BDD5jhR0LST7/VHage1HtfFGJsgbQC6VXTsWPbRwnsf5ifBlUleKeQXmL5C/3zHBoJJhT oCkkpLG1VMaUcbzfQuCDLjvrAhAAjDwAAyy8y46Ukkn4KSmxThu/7ovVkWfD564+APLSRu1mOu7L J7+zZniH/dAXGMuCnCJr2zqACc8vdPnmX3F5FDINe73xmqJXz3Y8v7H9dPgsuZaaa09bTLMGsOof 1BeKxJs4aCu2Dn+RLlon1Vnh10tV3j4yAH++9W6y/+i/ngv7qRNqLmoR30xHtwIDAQABo4IEMDCC BCwwCwYDVR0PBAQDAgeAMB0GA1UdDgQWBBSIvXFbqQtgAqfVgd/2LucldVpzITA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiE1I4igu3fU4X1gxiCxrxchYe7LX6HyKV0hceteQIBZAIBBDAfBgNV HSMEGDAWgBSzErFXrmmp60LIrAigOp3IfvE23DCCATwGA1UdHwSCATMwggEvMIIBK6CCASegggEj hoHWbGRhcDovLy9DTj1UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEsQ049V1NDQVMwMTAx LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL3Rl bHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBD QTEuY3JsMIIBcQYIKwYBBQUHAQEEggFjMIIBXzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPVRl bHN0cmElMjBVc2VyJTIwSXNzdWluZyUyMENBMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2Vy dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JlLERDPWRpcixEQz10ZWxz dHJhLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTBUBggrBgEFBQcwAoZIaHR0cDovL3RlbHN0cmEtcGtpLnBraS50ZWxzdHJhLmNvbS5h dS9UZWxzdHJhJTIwVXNlciUyMElzc3VpbmclMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzATBgNVHSUEDDAKBggrBgEFBQcD BDBdBgNVHSAEVjBUMFIGDCsGAQQBiEAEGwEBATBCMEAGCCsGAQUFBwIBFjRodHRwOi8vdGVsc3Ry YS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRmMBsGCSsGAQQBgjcVCgQOMAww CgYIKwYBBQUHAwQwWAYDVR0RBFEwT6AsBgorBgEEAYI3FAIDoB4MHGM3OTk4NzhAY29yZS5kaXIu dGVsc3RyYS5jb22BH0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20wDQYJKoZIhvcNAQEF BQADggEBAJdlLwFD54TirlRG+9jSLXEkMPsEG0jf6Hcgak1fGpMs20biU+i83rFkNL+scmcUf90z R7s1XFtb95rDvPbVPz7iYWoXimE3cv16Bnny2ZECh0+f7rY+ku05bXfBGLdSrCkXqOI57QEgC9ew 4yi303MOMGhxW/xGAv6CWaY4sGBRboTE71PkJCql4k635iThBP7YxJGe8/VDbiZNk8qspSBDswpv 0gQM0xDyUPkDT1Q5PEOLqugCxYXIKTKfXuGFj9nn8obzlhkyDvWxYYKH/mx8fe10ZVPGFgkSBa0o gjG0GUg5UZxnS+apqtMoZOoPHRMcZgxpKycDj01BSNdO6FAwggf5MIIG4aADAgECAgoWWLv+AAAA AAAFMA0GCSqGSIb3DQEBBQUAMEMxJDAiBgNVBAoTG1RlbHN0cmEgQ29ycG9yYXRpb24gTGltaXRl ZDEbMBkGA1UEAxMSVGVsc3RyYSBQb2xpY3kgQ0ExMB4XDTA5MTEyOTA4MzI0NVoXDTE0MTEyOTA4 NDI0NVowfDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3RlbHN0cmExEzAR BgoJkiaJk/IsZAEZFgNkaXIxFDASBgoJkiaJk/IsZAEZFgRjb3JlMSEwHwYDVQQDExhUZWxzdHJh IFVzZXIgSXNzdWluZyBDQTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCevv2YM8z1 batCiS4O8l8YKJZNgA6wCcNatQ0E3OK1ZKLijCumkWAbGkRGHvIsZGkvU9XV4SEVzaVmdC+w83S+ wDNwj+8RtR3yjTOZ/ttiXO1/zWbXq8pS+RYalOp2NS6bIs7J6bvN5nSzYJESNEkSwv57ZxDutL12 gw2tC411FYTWqaL10rAOA3Hn5wSyr51WdrkjxNZqmmhSGvOITi+8UAeIe6rzarh/YemYJp1sA2p0 ZIg1VhBg8vvY6dONG1h/atFDjECJtroqYbvtJpQWeXQK8hSR/JlLeAYqt/J8GKQv+8mkycQUn0Xt D5gbjF60i81culOIsXttS4xIe1tzAgMBAAGjggS0MIIEsDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBSzErFXrmmp60LIrAigOp3IfvE23DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMC AQAwggGJBgNVHSAEggGAMIIBfDCCAXgGDCsGAQQBiEAEGwEBATCCAWYwggEgBggrBgEFBQcCAjCC ARIeggEOAEYAbwByACAAYQAgAGMAbwBwAHkAIABvAGYAIAB0AGgAZQAgAFQAZQBsAHMAdAByAGEA IABQAEsASQAgAEMAUABTACwAIABjAGwAaQBjAGsAIABNAG8AcgBlACAASQBuAGYAbwAuACAARgBv AHIAIABDAFAAUwAgAHEAdQBlAHIAaQBlAHMAIABjAG8AbgB0AGEAYwB0ACAAdABoAGUAIABHAG8A dgBlAHIAbgBhAG4AYwBlACAAQwBvAHUAbgBjAGkAbAAsACAARQBtAGEAaQBsADoAIABUAGUAbABz AHQAcgBhAC4AUABHAEMAQAB0AGUAYQBtAC4AdABlAGwAcwB0AHIAYQAuAGMAbwBtMEAGCCsGAQUF BwIBFjRodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0cmEuY29tLmF1L1RlbHN0cmFDUFMucGRm MBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFJT5/udCeR3rxZ9HUpfHV7X4 nD4oMIIBLAYDVR0fBIIBIzCCAR8wggEboIIBF6CCAROGgc5sZGFwOi8vL0NOPVRlbHN0cmElMjBQ b2xpY3klMjBDQTEsQ049d3NjYXAwMTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGlyLERDPXRlbHN0cmEs REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0 cmlidXRpb25Qb2ludIZAaHR0cDovL3RlbHN0cmEtY3JsLnBraS50ZWxzdHJhLmNvbS5hdS9UZWxz dHJhJTIwUG9saWN5JTIwQ0ExLmNybDCCAWEGCCsGAQUFBwEBBIIBUzCCAU8wgcQGCCsGAQUFBzAC hoG3bGRhcDovLy9DTj1UZWxzdHJhJTIwUG9saWN5JTIwQ0ExLENOPUFJQSxDTj1QdWJsaWMlMjBL ZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcmUsREM9ZGly LERDPXRlbHN0cmEsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MEwGCCsGAQUFBzAChkBodHRwOi8vdGVsc3RyYS1wa2kucGtpLnRlbHN0 cmEuY29tLmF1L1RlbHN0cmElMjBQb2xpY3klMjBDQTEuY3J0MDgGCCsGAQUFBzABhixodHRwOi8v dGVsc3RyYS1vY3NwLnBraS50ZWxzdHJhLmNvbS5hdS9vY3NwLzANBgkqhkiG9w0BAQUFAAOCAQEA KLKdzu8ZWRTUOdOZJ02fEONNrwAHAUMMwFh5pD/2CPhY6e29qU+4zih5R30GUcj+2LVohlOHyWVq vvQJyJTxH+YTf3xrldjV69lL3lLCMfsuGX2LteGfwLsN45hUOnm1RWlvf0Gaug4GdLZeXjVLyfgU MF/BhesXEUGWB68Q5N8FxUVVgrmXRYYWyGQHGGHXWn/UCOreGjawPr7GC0HgndgkwHxjhTqgCmzo Sl0TIwWxFu6gO0eleF+3S85IFb3dwmctj+ZZm0tm3i5+59RVytuycvvAArwZT4Dc3nLD78fnjpXs c9oXwjRWF3x98fn2ycF56Ys+d3592133GLCMljGCAjgwggI0AgEBMIGKMHwxEzARBgoJkiaJk/Is ZAEZFgNjb20xFzAVBgoJkiaJk/IsZAEZFgd0ZWxzdHJhMRMwEQYKCZImiZPyLGQBGRYDZGlyMRQw EgYKCZImiZPyLGQBGRYEY29yZTEhMB8GA1UEAxMYVGVsc3RyYSBVc2VyIElzc3VpbmcgQ0ExAgo7 zYYLAAAAAABMMAkGBSsOAwIaBQCggYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTAwNTI2MDcxOTUzWjAjBgkqhkiG9w0BCQQxFgQU0R5r4l8xWMPsHtifzvNGhXX/ 0u4wJAYJKoZIhvcNAQkPMRcwFTAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASC AQCtdj5HH7eBePQFI+OTM0tRiCKQr1NDazebTiNlToD0BATC8X0JbCtrCvmL/QRGwN0wmwhDItfK Terhb/jrxl7BmBPXMt+j6VnKIozxsWie0XMM/LFTh04VOZ6jPRwqJhV2f3A14UpvLuXT2s4v0mdz uwuLFrGU6rLV9bNWku5U7cVZtyugDw/0MdkWCEXE61dZMUnqdMliCt+z8HvpMJv1P3GTpuT1zyRu H3j1VNjAs1w5pNokWfJEfIQafE+gYdQRcBsFLUaHJJlbsVTGFyc9g9swIv3PaxL1V3MUrD80fwse 9Yn5i5UZVUT0v4X1OqATA+I/vYf5BPNKHQRKygZ+AAAAAAAA ------=_NextPart_000_000B_01CAFCF7.A808EF80-- From kris.selden@gmail.com Wed May 26 03:07:02 2010 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 BC2633A6870 for ; Wed, 26 May 2010 03:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 SC75sMLKtG2b for ; Wed, 26 May 2010 03:07:01 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 17C4B3A68BD for ; Wed, 26 May 2010 03:07:01 -0700 (PDT) Received: by pxi19 with SMTP id 19so2718560pxi.31 for ; Wed, 26 May 2010 03:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=d9dBdMX1Y+UQiL8NayA5J9BPstTxb7fqAvKID33kvak=; b=Qiu/iNfIjJNdTiQs/d3ROQgCHgZBTs5jg8No4gXVyXa1kns1DpkVx3myNucFV0JMHb ep4i6O2Lte/hv4oNe0zSaeV7jp0NYLu6d9HhTtgMgsAhpxed9YtI1cqPMidKmDzjPVVE nuu64jp9LlpaT9X3sqjNWcs99Xj8SXQR7HfhE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QG57Jf1Xnh5UcPdOojRkTiQ4j4oMMbAu93Q7JamyVGYIqjPvb/PnhWd1eGevowUfXF c9nyT97HkbWCcIRcAzp7474ZruGwKIV0NgtJ10AUByJMkbRJAR94tC+SVXHPI1n63PuU Q518xXTv3dHaBdLiGFN36rIwThZ17RUxx7YBU= Received: by 10.143.26.21 with SMTP id d21mr5661433wfj.225.1274868409714; Wed, 26 May 2010 03:06:49 -0700 (PDT) Received: from [172.16.2.2] (c-76-121-106-185.hsd1.wa.comcast.net [76.121.106.185]) by mx.google.com with ESMTPS id 21sm5197138pzk.8.2010.05.26.03.06.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 03:06:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263A5327B@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 26 May 2010 03:06:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B4652CB-B22F-489B-8DD5-45A8B8BF06F2@gmail.com> References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> <4BFB8D0B.8080408@pidster.com> <996D9B84-03D8-43B9-8441-FDE1B5A19F74@gmail.com> <255B9BB34FB7D647A506DC292726F6E11263A5327B@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 26 May 2010 10:07:02 -0000 I like your response. I think application/json and application/xml would be fine without = application/x-www-form-urlencoded. I just thought it made a good lowest = common denominator for serialization which I think aids in making it = simple to support multiple formats. On May 26, 2010, at 12:19 AM, Manger, James H wrote: > Kris, >=20 >> The OAuth endpoint should be able to match the format(s) of the API = it=20 >> protects. >=20 > I had a quick look at the APIs for 24 services implementing OAuth (v1 = or=20 > drafts of v2) as listed on the OAuth wiki. >=20 > Of these 24 APIs, the response formats supported were: > * 21 XML > * 19 JSON > * 16 XML and JSON > * 5 XML only > * 3 JSON only >=20 > Other formats with some support: Atom, RSS, PHP, JSONP, CSV, vCards,=20= > FastInfoset, XML-RPC. >=20 > None use form-encoding for responses. >=20 >=20 >> Once again, I want to plea the case for keeping the response >> simple key/value string pairs so it is trivial to serialize to = multiple=20 >> formats. >=20 > Most APIs from this sample offer multiple formats. > None restricted themselves to simple key/value string pairs. > None attempt to serialize to a format with as little structure as=20 > form-encoding. >=20 >=20 > Where OAuth2 differs from most APIs is that it offers a response over = 2=20 > different "channels": an HTTP response body (as APIs do); and in a = HTTP=20 > redirect (which most APIs don't do). > If we really want to match the formats of the API being protected, = then the=20 > HTTP redirect channel should tunnel exactly the same response that = could be=20 > obtained in an API-like response body. Putting base64url-encoded XML = or JSON=20 > in the redirect URI is one way to do such tunnelling. Its not the = simplest=20 > solution for the simplest use case, but it is clear and future-proof. >=20 > -- > James Manger From danbri@danbri.org Wed May 26 03:27:30 2010 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 AD2973A68ED for ; Wed, 26 May 2010 03:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 Cbv2OFoXqIIE for ; Wed, 26 May 2010 03:27:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 814D33A6880 for ; Wed, 26 May 2010 03:27:29 -0700 (PDT) Received: by wye20 with SMTP id 20so2154344wye.31 for ; Wed, 26 May 2010 03:27:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.171.85 with SMTP id q63mr5250105wel.143.1274869635629; Wed, 26 May 2010 03:27:15 -0700 (PDT) Received: by 10.216.80.208 with HTTP; Wed, 26 May 2010 03:27:15 -0700 (PDT) In-Reply-To: References: <04B5665A-0187-4AD0-95BD-9C6195BB6212@gmail.com> Date: Wed, 26 May 2010 12:27:15 +0200 Message-ID: From: Dan Brickley To: Leah Culver Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Why JSON (Was: [oauth] Re: [twitter-dev] Hard lesson learned) 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, 26 May 2010 10:27:31 -0000 On Tue, May 25, 2010 at 6:03 AM, Leah Culver wrote: > So yeah, I'm against supporting ONLY JSON. I'd be fine if the spec allowed > for form-encoded, XML or whatever else might become the hot new thing. I'm > really for leaving it up to the provider. I don't think it's up to OAuth to > force people to use what we think is the coolest encoding format. Well said! "At least JSON" would be fine, but leave the door open for other formats... Dan From sakimura@gmail.com Wed May 26 06:58:07 2010 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 8ACF53A6823 for ; Wed, 26 May 2010 06:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 WtntWef-2Msf for ; Wed, 26 May 2010 06:58:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 566573A68AE for ; Wed, 26 May 2010 06:58:06 -0700 (PDT) Received: by gyh4 with SMTP id 4so3068416gyh.31 for ; Wed, 26 May 2010 06:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=wvMKlU0/1mvrenRNrk+y0S3J79m+Wzioa8jYRAZakIg=; b=LGL0Ek+RWxe9SBC1NoDszNF5K+7mJ9vda9ts/AVsh6s/wF1zGJULbQ7Ij9la3K+GP2 jQJJ9pwRHPzhMhPH10YsEQ2yzXA/IzxGo66ewMfFpTVUifcsEwTi6OAAUQYloIs8V/E8 ZH9oujiCyCGF1BQy4GwC/CI+SM9jxN3xaopQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SlnhlSiXBgT5u6ryT7MaWo3BWxbGvR5OSvcF9IsMyMX6HTadVNrZ48Z99ZsAjRpWuh Qm+U6xx26RpmFsN16UGkAPgL0GgSt8f6zb+s/FfH0UsBSk1OlAejOfqOfXCgPzoTdf7/ AF6KUCM7OgwZCVAWbzhYKtgnpyBuVocWMwPIo= MIME-Version: 1.0 Received: by 10.231.149.131 with SMTP id t3mr1263648ibv.55.1274882273769; Wed, 26 May 2010 06:57:53 -0700 (PDT) Received: by 10.231.31.132 with HTTP; Wed, 26 May 2010 06:57:53 -0700 (PDT) Date: Wed, 26 May 2010 22:57:53 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 26 May 2010 13:58:07 -0000 Back in February, I have suggested mobile web app flow to the oauth_wrap group. Now that it is wrapped into OAuth 2.0, here is my another try, this time for OAuth 2.0 draft. "OAuth 2.0 Mobile WebApp Flow" http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ I really wish that this could be included in OAuth 2.0 as it will help build identity layers on OAuth 2.0 that works for mobile web browsers etc. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From lshepard@facebook.com Wed May 26 07:29:34 2010 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 788493A691A for ; Wed, 26 May 2010 07:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 Rpi9cSfn0rhT for ; Wed, 26 May 2010 07:29:33 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id E77063A6947 for ; Wed, 26 May 2010 07:29:32 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4QESxvl009916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 May 2010 07:29:00 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub01.TheFacebook.com (192.168.18.104) with Microsoft SMTP Server (TLS) id 8.2.213.0; Wed, 26 May 2010 07:29:18 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Wed, 26 May 2010 07:29:19 -0700 From: Luke Shepard To: Allen Tom Date: Wed, 26 May 2010 07:29:18 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr839M8v7EgUwumQnG9RInzKjvLLQ== Message-ID: <1E40D78C-2CDE-4A7A-813F-9B848E253F3F@facebook.com> References: 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_1E40D78C2CDE4A7A813F9B848E253F3Ffacebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-26_02:2010-02-06, 2010-05-26, 2010-05-26 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 26 May 2010 14:29:34 -0000 --_000_1E40D78C2CDE4A7A813F9B848E253F3Ffacebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a legitimate concern. One other possible way to prevent this issue = is for the client to interpret the response, clear state, and refresh the p= age. This is the suggested way that many Connect sites handle the situation= . I don't disagree that it may be nice to allow the client to pass a username= for verification. I think that it should not be required, as responsible c= lients can do the right thing. Requiring a username prevents a whole class = of possible use cases - most notably, single sign on when you don't current= ly know the user at all. On May 25, 2010, at 6:42 PM, Allen Tom wrote: Yahoo=92s security team has concerns regarding the immediate mode and share= d computers. Consider the case where a browser based JS app is running in a browser tab = with credentials belonging to a particular user. While the app is still run= ning, the original user lets a friend borrow the browser. The friend opens = another tab, logs the original user out of the Service Provider, and then l= ogs in as different user using the friend=92s account. At this point =96 the app is still running as the original user a different= tab. If the app=92s credentials expire, it could attempt an immediate requ= est to refresh them =96 which could then return the credentials belonging t= o the 2nd user. Since this is a JS app =96 the data that belongs to the fir= st user is already loaded, so the app could start co-mingling the data betw= een the two users. At Yahoo, we call this scenario =93crossing the streams=94 - and that=92s = always a really bad thing. This scenario could be really disastrous if the SP has a login CSRF vulnera= bility =96 meaning that an attacker can CSRF the victim=92s browser into lo= gging in with the attacker=92s account. This vulnerability would result in = the victim=92s data mixing with the Attacker. One possible way to prevent this issue is for the client to pass the user= =92s identifier (or access token/refresh token/etc) in the immediate reques= t. Allen On 5/24/10 1:05 PM, "Eran Hammer-Lahav" > wrote: I am more interested in how you plan to address the (long term) security an= d privacy issue: who is responsible to prevent one user in getting an acces= s token for another in a shared computer environment. As long as the user g= oes to facebook.com, you show they who is logged in cl= early, so if it is not them, they can log out. But using immediate without a username, it sounds to me like you expect the= client to do the right thing. Is this how you plan to address this? Ask th= e client to find out whose access token it got, display it to the user, and= allow them to correct this? Especially given that at this point the client= account is already =93paired=94 with the access token. EHL On 5/24/10 12:44 PM, "Luke Shepard" > wrote: Suppose the client does not have a username - say, because the cookie expir= ed. What is the appropriate behavior? Would you require the client to spawn a popup or redirect to a full page au= th every time a user revisits their site? This doesn't make sense. Under what circumstances do you think the client gives an access token that= belongs to another user? If the user is logged into the service provider, = then they can get that access token anyway by just visiting the service pro= vider ... On May 24, 2010, at 11:18 AM, Dick Hardt wrote: > > On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote: > >> >> >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>> Sent: Monday, May 24, 2010 7:35 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] 'immediate' without identity >>> >>> You were looking for use cases for immediate without identity. >>> >>> I agree that *if* the client does know the user, then it should tell th= e server. >>> Are you saying that if the client does not know the user it should not = use >>> immediate? >> >> I think the server should reject an immediate request without a username= . Otherwise the server will be giving the client an access token that belon= gs to another user. > > Now I understand. I agree. > > -- Dick > > _______________________________________________ > 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 --_000_1E40D78C2CDE4A7A813F9B848E253F3Ffacebookcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a legitimate conce= rn. One other possible way to prevent this issue is for the client to = interpret the response, clear state, and refresh the page. This is the sugg= ested way that many Connect sites handle the situation.

=
I don't disagree that it may be nice to allow the client to pass a use= rname for verification. I think that it should not be required, as responsi= ble clients can do the right thing. Requiring a username prevents a whole c= lass of possible use cases - most notably, single sign on when you don't cu= rrently know the user at all.

On May 25, 2010, at 6= :42 PM, Allen Tom wrote:

Yahoo=92s security team has concerns regarding the immediate mode and= shared computers.

Consider the case where a browser based JS app is running in a browser tab = with credentials belonging to a particular user. While the app is still run= ning, the original user lets a friend borrow the browser. The friend opens = another tab, logs the original user out of the Service Provider, and then l= ogs in as different user using the friend=92s account.

At this point =96 the app is still running as the original user a different= tab. If the app=92s credentials expire, it could attempt an immediate requ= est to refresh them =96 which could then return the credentials belonging t= o the 2nd user. Since this is a JS app =96 the data that belongs to the fir= st user is already loaded, so the app could start co-mingling the data betw= een the two users.

At Yahoo, we call this scenario  =93crossing the streams=94 - and that= =92s always a really bad thing.

This scenario could be really disastrous if the SP has a login CSRF vulnera= bility =96 meaning that an attacker can CSRF the victim=92s browser into lo= gging in with the attacker=92s account. This vulnerability would result in = the victim=92s data mixing with the Attacker.

One possible way to prevent this issue is for the client to pass the user= =92s identifier (or access token/refresh token/etc) in the immediate reques= t.

Allen


On 5/24/10 1:05 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

I am more interested in how y= ou plan to address the (long term) security and privacy issue: who is respo= nsible to prevent one user in getting an access token for another in a shar= ed computer environment. As long as the user goes to facebook.com, you show they who is logged in clearly, so if i= t is not them, they can log out.

But using immediate without a username, it sounds to me like you expect the= client to do the right thing. Is this how you plan to address this? Ask th= e client to find out whose access token it got, display it to the user, and= allow them to correct this? Especially given that at this point the client= account is already =93paired=94 with the access token.

EHL


On 5/24/10 12:44 PM, "Luke Shepard" <lshepard@facebook.com> wrote:

Suppose the client does not h= ave a username - say, because the cookie expired. What is the appropriate b= ehavior?

Would you require the client to spawn a popup or redirect to a full page au= th every time a user revisits their site? This doesn't make sense.

Under what circumstances do you think the client gives an access token that= belongs to another user? If the user is logged into the service provider, = then they can get that access token anyway by just visiting the service pro= vider ...

On May 24, 2010, at 11:18 AM, Dick Hardt wrote:

>
> On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Dick Hardt [mail= to:dick.hardt@gmail.com]
>>> Sent: Monday, May 24, 2010 7:35 AM
>>> To: Eran Hammer-Lahav
>>> Cc: OAuth WG (oauth@ietf= .org)
>>> Subject: Re: [OAUTH-WG] 'immediate' without identity
>>>
>>> You were looking for use cases for immediate without identity.=
>>>
>>> I agree that *if* the client does know the user, then it shoul= d tell the server.
>>> Are you saying that if the client does not know the user it sh= ould not use
>>> immediate?
>>
>> I think the server should reject an immediate request without a us= ername. Otherwise the server will be giving the client an access token that= belongs to another user.
>
> Now I understand. I agree.
>
> -- Dick
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

= --_000_1E40D78C2CDE4A7A813F9B848E253F3Ffacebookcom_-- From hardjono@mit.edu Wed May 26 08:28:00 2010 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 DD40B3A679C for ; Wed, 26 May 2010 08:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=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 L4UILQBQ3dKy for ; Wed, 26 May 2010 08:27:52 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 202573A696F for ; Wed, 26 May 2010 08:27:51 -0700 (PDT) X-AuditID: 12074423-b7c0bae0000030f0-c4-4bfd3dee9516 Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id D2.60.12528.EED3DFB4; Wed, 26 May 2010 11:27:42 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o4QFRgPa032740 for ; Wed, 26 May 2010 11:27:42 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4QFRe1F027276 for ; Wed, 26 May 2010 11:27:41 -0400 Received: from oc11exhub3.exchange.mit.edu (18.9.3.13) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 May 2010 11:27:15 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub3.exchange.mit.edu ([18.9.3.13]) with mapi; Wed, 26 May 2010 11:27:40 -0400 From: Thomas Hardjono To: OAuth WG Date: Wed, 26 May 2010 11:27:37 -0400 Thread-Topic: Secret _Type question Thread-Index: Acr85/idOiylNUZkTG+UZ0aRtbxoYQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ADaF COGB CvR9 CxvV DubG DzO7 FD/+ GQHv HDS3 HrAb ImQ2 Ixk4 J2Dq KT4j Kzgd LPhZ; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {1F81B6B6-6ED9-4C45-8681-4708C9C89221}; aABhAHIAZABqAG8AbgBvAEAAbQBpAHQALgBlAGQAdQA=; Wed, 26 May 2010 15:27:37 GMT;UwBlAGMAcgBlAHQAIABfAFQAeQBwAGUAIAAgAHEAdQBlAHMAdABpAG8AbgA= x-cr-puzzleid: {1F81B6B6-6ED9-4C45-8681-4708C9C89221} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [OAUTH-WG] Secret _Type question 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, 26 May 2010 15:28:00 -0000 Another newbie question about OAuth2.0. In the Client Credential Flow (Section 3.9.1 of draft-05), the Client is su= pposed to issue a Client Request Access Token. One of the fields/parameter= s used is the secret_type, which is defined in Section 5.3. However, looking at Section 5.3 it seems theere is only one secret type tha= t is suported, namely hmac-sha256. How do I define my own secret type? (Is there a registry somewhere) Thanks. /thomas/ From eran@hueniverse.com Wed May 26 08:29:00 2010 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 4385D3A67F4 for ; Wed, 26 May 2010 08:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=1.276, 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 Qz174WHn2eU1 for ; Wed, 26 May 2010 08:28:51 -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 6B08D3A6837 for ; Wed, 26 May 2010 08:28:51 -0700 (PDT) Received: (qmail 6040 invoked from network); 26 May 2010 15:28:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 May 2010 15:28:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 26 May 2010 08:28:40 -0700 From: Eran Hammer-Lahav To: Luke Shepard , Allen Tom Date: Wed, 26 May 2010 08:28:27 -0700 Thread-Topic: [OAUTH-WG] 'immediate' without identity Thread-Index: Acr839M8v7EgUwumQnG9RInzKjvLLQACCRhA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3B8CE423@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1E40D78C-2CDE-4A7A-813F-9B848E253F3F@facebook.com> In-Reply-To: <1E40D78C-2CDE-4A7A-813F-9B848E253F3F@facebook.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_90C41DD21FB7C64BB94121FBBC2E72343B3B8CE423P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] 'immediate' without identity 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, 26 May 2010 15:29:00 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B8CE423P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But that wasn't the question... it was whether the two are closely related = (as in, should be defined in the same specification) and likely to be used = together. EHL From: Luke Shepard [mailto:lshepard@facebook.com] Sent: Wednesday, May 26, 2010 7:29 AM To: Allen Tom Cc: Eran Hammer-Lahav; Dick Hardt; OAuth WG Subject: Re: [OAUTH-WG] 'immediate' without identity This is a legitimate concern. One other possible way to prevent this issue = is for the client to interpret the response, clear state, and refresh the p= age. This is the suggested way that many Connect sites handle the situation= . I don't disagree that it may be nice to allow the client to pass a username= for verification. I think that it should not be required, as responsible c= lients can do the right thing. Requiring a username prevents a whole class = of possible use cases - most notably, single sign on when you don't current= ly know the user at all. On May 25, 2010, at 6:42 PM, Allen Tom wrote: Yahoo's security team has concerns regarding the immediate mode and shared = computers. Consider the case where a browser based JS app is running in a browser tab = with credentials belonging to a particular user. While the app is still run= ning, the original user lets a friend borrow the browser. The friend opens = another tab, logs the original user out of the Service Provider, and then l= ogs in as different user using the friend's account. At this point - the app is still running as the original user a different t= ab. If the app's credentials expire, it could attempt an immediate request = to refresh them - which could then return the credentials belonging to the = 2nd user. Since this is a JS app - the data that belongs to the first user = is already loaded, so the app could start co-mingling the data between the = two users. At Yahoo, we call this scenario "crossing the streams" - and that's always= a really bad thing. This scenario could be really disastrous if the SP has a login CSRF vulnera= bility - meaning that an attacker can CSRF the victim's browser into loggin= g in with the attacker's account. This vulnerability would result in the vi= ctim's data mixing with the Attacker. One possible way to prevent this issue is for the client to pass the user's= identifier (or access token/refresh token/etc) in the immediate request. Allen On 5/24/10 1:05 PM, "Eran Hammer-Lahav" > wrote: I am more interested in how you plan to address the (long term) security an= d privacy issue: who is responsible to prevent one user in getting an acces= s token for another in a shared computer environment. As long as the user g= oes to facebook.com, you show they who is logged in cl= early, so if it is not them, they can log out. But using immediate without a username, it sounds to me like you expect the= client to do the right thing. Is this how you plan to address this? Ask th= e client to find out whose access token it got, display it to the user, and= allow them to correct this? Especially given that at this point the client= account is already "paired" with the access token. EHL On 5/24/10 12:44 PM, "Luke Shepard" > wrote: Suppose the client does not have a username - say, because the cookie expir= ed. What is the appropriate behavior? Would you require the client to spawn a popup or redirect to a full page au= th every time a user revisits their site? This doesn't make sense. Under what circumstances do you think the client gives an access token that= belongs to another user? If the user is logged into the service provider, = then they can get that access token anyway by just visiting the service pro= vider ... On May 24, 2010, at 11:18 AM, Dick Hardt wrote: > > On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote: > >> >> >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.hardt@gmail.com] >>> Sent: Monday, May 24, 2010 7:35 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] 'immediate' without identity >>> >>> You were looking for use cases for immediate without identity. >>> >>> I agree that *if* the client does know the user, then it should tell th= e server. >>> Are you saying that if the client does not know the user it should not = use >>> immediate? >> >> I think the server should reject an immediate request without a username= . Otherwise the server will be giving the client an access token that belon= gs to another user. > > Now I understand. I agree. > > -- Dick > > _______________________________________________ > 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B8CE423P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But that = wasn’t the question… it was whether the two are closely related= (as in, should be defined in the same specification) and likely to be used= together.

 

EHL

 

From: Luke Shepard [mailto:lshepard@facebook.com]
Sent:= Wednesday, May 26, 2010 7:29 AM
To: Allen Tom
Cc: = Eran Hammer-Lahav; Dick Hardt; OAuth WG
Subject: Re: [OAUTH-WG] '= immediate' without identity

 

This is a legitimate conce= rn. One other possible way to prevent this issue is for the client to = interpret the response, clear state, and refresh the page. This is the sugg= ested way that many Connect sites handle the situation.

=

 

I don't disagree that it may be nice to allow the client to pass a user= name for verification. I think that it should not be required, as responsib= le clients can do the right thing. Requiring a username prevents a whole cl= ass of possible use cases - most notably, single sign on when you don't cur= rently know the user at all.

=  

On May 25, 2010, at 6:4= 2 PM, Allen Tom wrote:



Yahoo’s security team has concerns reg= arding the immediate mode and shared computers.

Consider the case wh= ere a browser based JS app is running in a browser tab with credentials bel= onging to a particular user. While the app is still running, the original u= ser lets a friend borrow the browser. The friend opens another tab, logs th= e original user out of the Service Provider, and then logs in as different = user using the friend’s account.

At this point – the app= is still running as the original user a different tab. If the app’s = credentials expire, it could attempt an immediate request to refresh them &= #8211; which could then return the credentials belonging to the 2nd user. S= ince this is a JS app – the data that belongs to the first user is al= ready loaded, so the app could start co-mingling the data between the two u= sers.

At Yahoo, we call this scenario  “crossing the stre= ams” - and that’s always a really bad thing.

This scenar= io could be really disastrous if the SP has a login CSRF vulnerability R= 11; meaning that an attacker can CSRF the victim’s browser into loggi= ng in with the attacker’s account. This vulnerability would result in= the victim’s data mixing with the Attacker.

One possible way = to prevent this issue is for the client to pass the user’s identifier= (or access token/refresh token/etc) in the immediate request.

Allen=


On 5/24/10 1:05 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:
<= br>

I am more interested in how you = plan to address the (long term) security and privacy issue: who is responsi= ble to prevent one user in getting an access token for another in a shared = computer environment. As long as the user goes to facebook.com, you show they who is logged in clearly, so if it i= s not them, they can log out.

But using immediate without a username= , it sounds to me like you expect the client to do the right thing. Is this= how you plan to address this? Ask the client to find out whose access toke= n it got, display it to the user, and allow them to correct this? Especiall= y given that at this point the client account is already “paired̶= 1; with the access token.

EHL


On 5/24/10 12:44 PM, "= Luke Shepard" <lshepar= d@facebook.com> wrote:


Suppose the client does not have a usernam= e - say, because the cookie expired. What is the appropriate behavior?
<= br>Would you require the client to spawn a popup or redirect to a full page= auth every time a user revisits their site? This doesn't make sense.
Under what circumstances do you think the client gives an access token th= at belongs to another user? If the user is logged into the service provider= , then they can get that access token anyway by just visiting the service p= rovider ...

On May 24, 2010, at 11:18 AM, Dick Hardt wrote:

&= gt;
> On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote:
>
= >>
>>
>>> -----Original Message-----
>>= > From: Dick Hardt [mailto:dick.= hardt@gmail.com]
>>> Sent: Monday, May 24, 2010 7:35 AM
= >>> To: Eran Hammer-Lahav
>>> Cc: OAuth WG (oauth@ietf.org)
>>> Subject: Re= : [OAUTH-WG] 'immediate' without identity
>>>
>>> Y= ou were looking for use cases for immediate without identity.
>>&g= t;
>>> I agree that *if* the client does know the user, then it= should tell the server.
>>> Are you saying that if the client = does not know the user it should not use
>>> immediate?
>= >
>> I think the server should reject an immediate request with= out a username. Otherwise the server will be giving the client an access to= ken that belongs to another user.
>
> Now I understand. I agree= .
>
> -- Dick
>
> _________________________________= ______________
> 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

<= p class=3DMsoNormal> 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3B8CE423P3PW5EX1MB01E_-- From hardjono@mit.edu Wed May 26 08:42:19 2010 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 F3A043A659A for ; Wed, 26 May 2010 08:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=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 vBIaefStCjPm for ; Wed, 26 May 2010 08:42:17 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 9FFB23A68CD for ; Wed, 26 May 2010 08:42:17 -0700 (PDT) X-AuditID: 1209190d-b7bf0ae0000059a7-0c-4bfd41500137 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 61.AA.22951.0514DFB4; Wed, 26 May 2010 11:42:08 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4QFg8Eh024170 for ; Wed, 26 May 2010 11:42:08 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4QFg8D9029440 for ; Wed, 26 May 2010 11:42:08 -0400 Received: from w92exhub10.exchange.mit.edu (18.7.73.18) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 May 2010 11:41:30 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub10.exchange.mit.edu ([18.7.73.18]) with mapi; Wed, 26 May 2010 11:42:07 -0400 From: Thomas Hardjono To: OAuth WG Date: Wed, 26 May 2010 11:42:05 -0400 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr4dbWDj+nMDy6TTqWPCApNuWCL5gAnYzSeANjWA/AAHKS0YA== Message-ID: References: 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 15:42:19 -0000 +1 also. A separate signatures/tokens spec would be useful. If service providers in the future wish to use OAuth for authenticating users within transactions with assurance higher than LOA1, then I strongly suggest the issue of non-repudiation is addressed. Logging/auditing/tracking is huge issue in some environments. /thomas/ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Allen Tom > Sent: Tuesday, May 25, 2010 9:56 PM > To: Richer, Justin P.; Dirk Balfanz; OAuth WG > Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAu= th 2 >=20 > +1 >=20 > I fully agree with Dirk and Brian that there needs to be some work on > signatures. There are many types of applications that require higher leve= ls > of security than what bearer tokens can provide. >=20 > That being said, I think that bearer token/refresh token model can satisi= fy > the majority of use cases - in fact it would satisfy 100% of all public A= PIs > that we have at Yahoo. >=20 > Perhaps in the interest of keeping the spec focused, it would make more > sense to split out a Signed Token Spec, as Justin proposes, that is focus= ed > solely on uses cases that require a signature? >=20 > Allen >=20 >=20 >=20 > On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >=20 > > I have a slightly more radical proposal. What if we factor out the sign= ed > > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, g= iven > > the same attention by the group and all that like Eran was talking abou= t > > yesterday. What this would take is taking out all reference to signing = and > > making core OAuth just about bare tokens, then have a separate spec tha= t > > details what to call your shared secret parameters, how to get them, an= d > how > > to sign with them. This makes the core spec a lot simpler (as detailed > below) > > but makes the overall use case of using signed tokens more complicated = to > > follow, as it'd be split in two. > > > > -- justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > > Balfanz [balfanz@google.com] > > Sent: Thursday, May 20, 2010 7:39 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth= 2 > > > > Hi guys, > > > > at today's interim meeting, we were discussing Brian Eaton's proposal f= or > > OAuth signatures. He was proposing a mechanism that would (1) do away w= ith > > base string canonicalization, (2) allow for symmetric and public keys, = and > (3) > > allow for extensibility. > > > > He got homework from the group to prove the feasibility of his proposal= by > > showing a couple of implementations. > > > > In this post, I would like to introduce another improvement of the OAut= h 2 > > signing mechanism, one which is orthogonal to Brian's proposal (i.e., i= t > would > > work both with the signing mechanism in the current spec, as well as wi= th > > Brian's signature mechanism). The goal of my proposal is twofold: > > > > - it simplifies the spec. It will become more readable and therefore ea= sier > to > > implement > > - it separates out the mechanisms for delegated authorization and for > > integrity protection into two independent pieces, which can be put toge= ther > by > > Servers and/or Clients like LEGO blocks. > > > > Summary: > > > > - use the client secret instead of the token secret for signing PR acce= ss > > requests. > > > > Long version of the proposal: > > > > - remove all references to access tokens that are not bearer tokens fro= m > the > > spec. > > - stop calling the access tokens "bearer tokens". Call them just "acces= s > > tokens". > > - remove all references to token secrets from the spec > > - remove all parts of the spec that are of the kind "if bearer_token th= en > X, > > else Y", and replace them with X. > > - delete section 5.3 > > - add a section called "Request Authentication" that goes something lik= e > this: > > > > "Servers may require that requests be authenticated by the Client, so t= hat > > presentation of the access token alone is not sufficient to access a > Protected > > Resource. This has several use cases, including, but not limited to, t= he > > following: > > > > - Non-repudiation: high-security deployments may require that requests = be > > authenticated (signed) in a non-repudiateable way[1] > > - Access to protected resources is not protected by SSL, so that access > tokens > > may leak. > > - End-to-end-integrity: even if SSL _is_ used, network infrastructure m= ay > > strip SSL protection before the request reaches the protected resource.= The > > protected resource, however, may require end-to-end integrity. > > > > If the Server requires that the Client authenticate PR access requests, > then > > the Client uses the following mechanism to sign their HTTP requests: [.= ..]" > > > > Then, we basically drop the old Section 5.3 here (except we use the cli= ent > > secret instead of the access token secret). Eventually, instead of Sect= ion > > 5.3, we may have Brian's new signature scheme section here, which would= add > > the option of public-key crypto[1], etc. > > > > What do you guys think? > > > > Dirk. > > > > [1] Technically speaking, the goal of non-repudiation can only be achie= ved > > once we have public-key crypto. > > > > _______________________________________________ > > 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 From hardjono@mit.edu Wed May 26 08:45:30 2010 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 C97CC3A6832 for ; Wed, 26 May 2010 08:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bumTCuTNLz7v for ; Wed, 26 May 2010 08:45:26 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by core3.amsl.com (Postfix) with ESMTP id 76E613A6843 for ; Wed, 26 May 2010 08:45:26 -0700 (PDT) X-AuditID: 12074422-b7c13ae000003829-ef-4bfd420d3a44 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with SMTP id 25.DF.14377.D024DFB4; Wed, 26 May 2010 11:45:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4QFjHLL024574; Wed, 26 May 2010 11:45:17 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4QFjFmu029948; Wed, 26 May 2010 11:45:16 -0400 Received: from w92exhub9.exchange.mit.edu (18.7.73.17) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 May 2010 11:44:51 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub9.exchange.mit.edu ([18.7.73.17]) with mapi; Wed, 26 May 2010 11:45:15 -0400 From: Thomas Hardjono To: Allen Tom , "oauth@ietf.org" Date: Wed, 26 May 2010 11:45:14 -0400 Thread-Topic: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) Thread-Index: Acr8eXbtpcv6DZ2txkSn7M0JCOEspQAcJ0oQ Message-ID: References: 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_DADD7EAD88AB484D8CCC328D40214CCD01785405A5EXPO10exchang_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) 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, 26 May 2010 15:45:30 -0000 --_000_DADD7EAD88AB484D8CCC328D40214CCD01785405A5EXPO10exchang_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Allen, If the explicit action of the Client sending a Request Token is removed, how does OAuth do logging and auditing? /thomas/ __________________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= llen Tom Sent: Tuesday, May 25, 2010 10:17 PM To: Murali VP; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-0= 5) Yes - one of the design goals for Oauth-WRAP was to eliminate the request t= oken. It is very tricky for SPs to implement the Request Token due to data replic= ation issues. The Request token could be issued to the client in one data c= enter, and then immediately submitted by the browser to a different data ce= nter. This means that the data has to be very quickly replicated. On the client side of things, if the AS's approval screen is displayed in a= popup window (like Facebook Connect) - it could be tricky to tricky for th= e client to pre-fetch the request token before displaying the "Connect" but= ton in order to get around popup blockers. Allen On 5/25/10 1:43 PM, "Murali VP" wrote: A relatively less important question: Since the request token has been eliminated, the web server flow (3.6) which comes close to the widely adopted OAuth 1.0's 3-legged oauth flow but without much of a dance isn't backward compatible, is this a known decision? --_000_DADD7EAD88AB484D8CCC328D40214CCD01785405A5EXPO10exchang_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05)=

Allen,

 

If the explicit action of the Client sending a Request Token=

is removed, how does OAuth do logging and auditing?

 

/thomas/

 

 

__________________________________= ________

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Allen Tom
Sent: Tuesday, May 25, 2010 10:17 PM
To: Murali VP; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on dr= aft 2-05)

 

Yes – one of the design goals for Oauth-WRAP was to eliminate the request= token.

It is very tricky for SPs to implement the Request Token due to data replication issues. The Request token could be issued to the client in one = data center, and then immediately submitted by the browser to a different data center. This means that the data has to be very quickly replicated.

On the client side of things, if the AS’s approval screen is displaye= d in a popup window (like Facebook Connect) - it could be tricky to tricky for the client to pre-fetch the request token before displaying the “Connect&= #8221; button in order to get around popup blockers.

Allen


On 5/25/10 1:43 PM, "Murali VP" <muralive@gmail.com> wrote:


A relatively less important question:

Since the request token has been eliminated, the web server flow (3.6)
which comes close to the widely adopted OAuth 1.0's 3-legged oauth
flow but without much of a dance isn't backward compatible, is this a
known decision?

--_000_DADD7EAD88AB484D8CCC328D40214CCD01785405A5EXPO10exchang_-- From dick.hardt@gmail.com Wed May 26 09:39:30 2010 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 ED78B3A685E for ; Wed, 26 May 2010 09:39:30 -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 r86nIDrKmUPs for ; Wed, 26 May 2010 09:39:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E58893A687C for ; Wed, 26 May 2010 09:39:29 -0700 (PDT) Received: by gyh4 with SMTP id 4so3247961gyh.31 for ; Wed, 26 May 2010 09:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=Te3Z0hBhHkjw04NCNQ0Ppv3wbKGNlrVm3eM/tpQf18I=; b=FVn2W3PLo8iwl8ugH2+7obUyNQWzEbGHQOz1r+ecz9BHQZi1VUiRCnFhY9zASbakGM X5zG7LkqruhFUfnNg01lQucpRmRYRr3eRXZJjjdhi5Fy5J4ThdlQzXbEasCI3IojA1zS nGDAr7NS5t38Gn1oK720fWpep6k6e1mIXOSLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=xPtspLfIwU/vU3K6m1re2krFpSr9Bh2xOMCouuipte6XbMmViTP88sfF2JUsg9lieW WShMU5/ZVSoiqznXlzUWr1WjH0tbA4ifduiS1Mzr/aRYr7dINZtMO7Rks1gcEwbsTYHo 6p5IFYRx33gljVT+IhRw3fHdu05TTCywc28qI= Received: by 10.100.244.3 with SMTP id r3mr11491406anh.77.1274891956899; Wed, 26 May 2010 09:39:16 -0700 (PDT) Received: from [10.0.0.7] ([38.109.197.253]) by mx.google.com with ESMTPS id y7sm1272665ana.4.2010.05.26.09.39.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 May 2010 09:39:13 -0700 (PDT) From: Dick Hardt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 10:39:09 -0600 Message-Id: <926FECBD-5AAE-4EC6-A238-09F75BD12B1A@gmail.com> To: "OAuth WG (oauth@ietf.org)" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [OAUTH-WG] 5.3.1.2 Normalized String Construction 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, 26 May 2010 16:39:31 -0000 The access token is not in the string that is signed. Is this a mistake = or am I missing something? -- Dick From hardjono@mit.edu Wed May 26 10:15:20 2010 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 B5E8C3A692B for ; Wed, 26 May 2010 10:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.183 X-Spam-Level: X-Spam-Status: No, score=-0.183 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, UNPARSEABLE_RELAY=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 2qlIpPeDiAKg for ; Wed, 26 May 2010 10:15:02 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id C74BC3A681E for ; Wed, 26 May 2010 10:15:00 -0700 (PDT) X-AuditID: 12074424-b7b9dae000002832-80-4bfd570b58d6 Received: from mailhub-auth-3.mit.edu (MAILHUB-AUTH-3.MIT.EDU [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 1E.D4.10290.B075DFB4; Wed, 26 May 2010 13:14:51 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id o4QHEpHH015015; Wed, 26 May 2010 13:14:51 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4QHEngV026939; Wed, 26 May 2010 13:14:50 -0400 Received: from oc11exhub2.exchange.mit.edu (18.9.3.12) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 May 2010 13:14:24 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub2.exchange.mit.edu ([18.9.3.12]) with mapi; Wed, 26 May 2010 13:14:48 -0400 From: Thomas Hardjono To: Torsten Lodderstedt , "OAuth WG (oauth@ietf.org)" Date: Wed, 26 May 2010 13:14:46 -0400 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr8R+AyX4ijw1NHSEK2wWE9jIHS0QArf6Mw Message-ID: References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> In-Reply-To: <4BFC3142.6010506@lodderstedt.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 26 May 2010 17:15:20 -0000 Hi Torsten, Looking at your example below (with the user having=20 to login/consent several times), it seems what is needed is multiple short-term (narrower) tokens that is provably derived from one single (parent) longer-life token. So the human user would need to consent only once to the parent longer-life token, and the client would fetch the multiple shorter-life tokens automatically. The keyword here is "provably" (which may be read as "cryptographically provable"). BTW. Apologies for the history lesson, but this was the same problem with Kerberos when it was first deployed at MIT project Athena in the late 1980s. The solution was to create a separate Ticket-Granting-Ticket (TGT) with the user being prompted for a password only once. Then the Kerberos client would obtain Service Tickets (to access resources) using the TGT. /thomas/ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Torsten Lodderstedt > Sent: Tuesday, May 25, 2010 4:21 PM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] multiple access tokens from a single authorizatio= n > flow? >=20 > ..... > With the current draft, the client has to send the user through the > authz process n-times (n =3D number of services). This would look this: >=20 > user accesses client > REDIRECT AS > Login at AS > User Consent service 1 > REDIRECT back > get access token for service 1 > REDIRECT AS > SSO at AS > User Consent service 2 > REDIRECT back > get access token for service 2 > REDIRECT AS > SSO at AS > User Consent service 3 > REDIRECT back > get access token for service 3 >=20 > What a user experience is that? And imagine such a use case for the > device flow :-( >=20 > Do we have other options to perform this process more user-friendly? >=20 > First of all, how does the client request authorization for different > services? As far as I see, the scope parameter is the only way to pass > such information to the authorization server. So instead of mererly > denoting permissions, we can use scopes as kind of service id + permissio= ns. >=20 > Which options do we have for returning tokens to the client? >=20 > As proposed by Marius, the authorization server could issue a refresh > token and the client could use the refresh request in combination with > the downscoping feature in order to acquire access tokens. > Consequences? > In the setup illustrated above, the authorization server cannot create > any access token (or an arbitrary one), it can only return a refresh > token. This would mean to make the access token response parameter > optional. Here I'm colliding with my mental picture of refresh tokens as > long-living and storable tokens. Are these refresh tokens still > long-living or as short-living as a Kerberos TGT? If they are still > long-living, what about the use cases where we don't want to return > refresh tokens? As far as I remember, user agent and username/password > flow were candidates. How shall we handle them? >=20 > Coming back to my original proposal: The authorization server could also > issue multiple access tokens and (optionally) a refresh token - > preserving the refresh token semantics. >=20 > Justin pointed out that my original proposal added complexity to the > simplest use case even if the authorization server does not issue > multiple tokens. I understand your objection and would like to suggest a > modified response structure. Instead of putting all access token into an > array, the authz server could also use the structure as defined in the > current draft and use another list of "additional_access_tokens", if > more than one token has been created. >=20 > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store >=20 > { > "access_token":"SlAV32hkAB", > "scopes":"calendar", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8" > additional_access_tokens =3D [{ "token":"SlAV32hkKG", > "scopes":["calendar"], "expires_in":3600}, ...] > } >=20 > So in the simplest case, the response would look the same as before. >=20 > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store >=20 > { > "access_token":"SlAV32hkAB", > "scopes":"calendar", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8" > } >=20 > Thoughts? >=20 > regards, > Torsten. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hardjono@mit.edu Wed May 26 10:37:05 2010 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 317C83A696D for ; Wed, 26 May 2010 10:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_50=0.001, UNPARSEABLE_RELAY=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 okd-18OnwOKL for ; Wed, 26 May 2010 10:37:03 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by core3.amsl.com (Postfix) with ESMTP id BFF653A683C for ; Wed, 26 May 2010 10:37:00 -0700 (PDT) X-AuditID: 1209190e-b7b82ae000005260-1f-4bfd5c32ca4a Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with SMTP id C1.E2.21088.33C5DFB4; Wed, 26 May 2010 13:36:51 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o4QHaoip014143; Wed, 26 May 2010 13:36:50 -0400 Received: from w92exedge3.EXCHANGE.MIT.EDU (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4QHante012179; Wed, 26 May 2010 13:36:50 -0400 Received: from oc11exhub5.exchange.mit.edu (18.9.3.15) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 May 2010 13:36:05 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub5.exchange.mit.edu ([18.9.3.15]) with mapi; Wed, 26 May 2010 13:36:49 -0400 From: Thomas Hardjono To: "OAuth WG (oauth@ietf.org)" Date: Wed, 26 May 2010 13:36:47 -0400 Thread-Topic: Proposal: Redesigning the Refresh Token (RE: multiple access tokens from a single authorization) Thread-Index: Acr8TxPOf9DKTo2mT2y+p3FIb7gk8gAqJwEQ Message-ID: References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.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 X-Brightmail-Tracker: AAAAAA== Subject: [OAUTH-WG] Proposal: Redesigning the Refresh Token (RE: multiple access tokens from a single authorization) 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, 26 May 2010 17:37:05 -0000 Apologies if I'm speaking out of school :) but it seems the Refresh Token offers an opportunity for solving Torsten's problem. - Instead of calling it a Refresh Token, why not redefine it as a Service Token (or Sub-Access Token) with a specific scope and intended Resource Server. - In 3.3.1., when the Client perform authentication it needs to identify the multiple Resource Servers it seeks to access (each with a separate scope and requested access lifetimes). - In the Access Token Response (3.3.2.1) coming back from the Authorization Server, the response would contain a matching number of Service Tokens, each with a separate access_secret, scope, expires_in values. - The Client can then use any of these Service Tokens independent of the original Access Request, until the expiration of the Service Token. No need for the Client to prompt the human user. /thomas/ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Marius Scurtescu > Sent: Tuesday, May 25, 2010 4:51 PM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] multiple access tokens from a single authorizatio= n > flow? >=20 > On Tue, May 25, 2010 at 1:46 PM, Torsten Lodderstedt > wrote: > >> > >> On Tue, May 25, 2010 at 1:21 PM, Torsten Lodderstedt > >> =A0wrote: > >> > >>> > >>> As proposed by Marius, the authorization server could issue a refresh > >>> token > >>> and the client could use the refresh request in combination with the > >>> downscoping feature in order to acquire access tokens. > >>> Consequences? > >>> In the setup illustrated above, the authorization server cannot creat= e > >>> any > >>> access token (or an arbitrary one), it can only return a refresh toke= n. > >>> This > >>> would mean to make the access token response parameter optional. Here= I'm > >>> colliding with my mental picture of refresh tokens as long-living and > >>> storable tokens. Are these refresh tokens still long-living or as > >>> short-living as a Kerberos TGT? If they are still long-living, what a= bout > >>> the use cases where we don't want to return refresh tokens? As far as= I > >>> remember, user agent and username/password flow were candidates. How > >>> shall > >>> we handle them? > >>> > >> > >> I think the authz server can create an access token that will grant > >> access to all requested scopes, just as the corresponding refresh > >> token. If the client intends to do down-scoping then it will probably > >> just discard this initial access token. > >> > >> One way to ensure that the client is not lazy and it is not using the > >> broadly scoped access token is to have services refuse access tokens > >> that are not narrowed down to only what the service needs. > >> > >> Marius > >> > > > > As I said, every service in our setup needs another access token, with > > different content, signed and encrypted with another shared secret. It = is > > technically impossible to create the super access token. Refresh tokens= are > > just handles representing the user's authorization and are used by the > authz > > server only. They therefore can represent any scope. >=20 > I see, thanks for clarifying. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From balfanz@google.com Wed May 26 10:44:23 2010 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 213FD3A67CF for ; Wed, 26 May 2010 10:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 74HoKIOEa-6p for ; Wed, 26 May 2010 10:44:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 41C9F3A67AD for ; Wed, 26 May 2010 10:44:21 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o4QHi8ht020576 for ; Wed, 26 May 2010 10:44:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274895849; bh=CufxdvpkcV5X2/ZJ46NPmTudsZY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=nAur/jrb9iXkvhwzn9nD5/iR69OyZK29OvRr996eACjwlWUwELNnpeeCzkU3NMlsy /+Jb3+kmaO2s4z6OiqV8A== 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=Fc++CgnU8ZrHcRsovhk581uoO2n8g1R9SePfaGr6oSY8xd1CN5LDWZovdrZtzg8KO jQGUk8M8cgL4xa7XnHghA== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by kpbe20.cbf.corp.google.com with ESMTP id o4QHi6Fj013289 for ; Wed, 26 May 2010 10:44:07 -0700 Received: by gyf3 with SMTP id 3so6151517gyf.2 for ; Wed, 26 May 2010 10:44:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.148.200 with SMTP id q8mr7628660ibv.10.1274895846379; Wed, 26 May 2010 10:44:06 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Wed, 26 May 2010 10:44:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 May 2010 10:44:06 -0700 Message-ID: From: Dirk Balfanz To: Allen Tom Content-Type: multipart/alternative; boundary=0016e6407eba0c907d048782d239 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 17:44:23 -0000 --0016e6407eba0c907d048782d239 Content-Type: text/plain; charset=ISO-8859-1 Repeating what I said before: - separate spec is fine by me - part of the point I'm trying to make is that that spec shouldn't be about signed _tokens_, but instead about signed _HTTP requests_ (so instead of merely proving that you know a secret that came with the token, you prove who you are when you use the token). I'd be interested what the Facebook guys think about this - I believe the current signature scheme is in there mostly to address a use case they had. Luke, Dave - would a separate signing spec be ok with you guys? Dirk. On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: > +1 > > I fully agree with Dirk and Brian that there needs to be some work on > signatures. There are many types of applications that require higher levels > of security than what bearer tokens can provide. > > That being said, I think that bearer token/refresh token model can satisify > the majority of use cases - in fact it would satisfy 100% of all public > APIs > that we have at Yahoo. > > Perhaps in the interest of keeping the spec focused, it would make more > sense to split out a Signed Token Spec, as Justin proposes, that is focused > solely on uses cases that require a signature? > > Allen > > > > On 5/21/10 11:27 AM, "Richer, Justin P." wrote: > > > I have a slightly more radical proposal. What if we factor out the signed > > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, > given > > the same attention by the group and all that like Eran was talking about > > yesterday. What this would take is taking out all reference to signing > and > > making core OAuth just about bare tokens, then have a separate spec that > > details what to call your shared secret parameters, how to get them, and > how > > to sign with them. This makes the core spec a lot simpler (as detailed > below) > > but makes the overall use case of using signed tokens more complicated to > > follow, as it'd be split in two. > > > > -- justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > > Balfanz [balfanz@google.com] > > Sent: Thursday, May 20, 2010 7:39 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > > > Hi guys, > > > > at today's interim meeting, we were discussing Brian Eaton's proposal for > > OAuth signatures. He was proposing a mechanism that would (1) do away > with > > base string canonicalization, (2) allow for symmetric and public keys, > and (3) > > allow for extensibility. > > > > He got homework from the group to prove the feasibility of his proposal > by > > showing a couple of implementations. > > > > In this post, I would like to introduce another improvement of the OAuth > 2 > > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it > would > > work both with the signing mechanism in the current spec, as well as with > > Brian's signature mechanism). The goal of my proposal is twofold: > > > > - it simplifies the spec. It will become more readable and therefore > easier to > > implement > > - it separates out the mechanisms for delegated authorization and for > > integrity protection into two independent pieces, which can be put > together by > > Servers and/or Clients like LEGO blocks. > > > > Summary: > > > > - use the client secret instead of the token secret for signing PR access > > requests. > > > > Long version of the proposal: > > > > - remove all references to access tokens that are not bearer tokens from > the > > spec. > > - stop calling the access tokens "bearer tokens". Call them just "access > > tokens". > > - remove all references to token secrets from the spec > > - remove all parts of the spec that are of the kind "if bearer_token then > X, > > else Y", and replace them with X. > > - delete section 5.3 > > - add a section called "Request Authentication" that goes something like > this: > > > > "Servers may require that requests be authenticated by the Client, so > that > > presentation of the access token alone is not sufficient to access a > Protected > > Resource. This has several use cases, including, but not limited to, the > > following: > > > > - Non-repudiation: high-security deployments may require that requests be > > authenticated (signed) in a non-repudiateable way[1] > > - Access to protected resources is not protected by SSL, so that access > tokens > > may leak. > > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > > strip SSL protection before the request reaches the protected resource. > The > > protected resource, however, may require end-to-end integrity. > > > > If the Server requires that the Client authenticate PR access requests, > then > > the Client uses the following mechanism to sign their HTTP requests: > [...]" > > > > Then, we basically drop the old Section 5.3 here (except we use the > client > > secret instead of the access token secret). Eventually, instead of > Section > > 5.3, we may have Brian's new signature scheme section here, which would > add > > the option of public-key crypto[1], etc. > > > > What do you guys think? > > > > Dirk. > > > > [1] Technically speaking, the goal of non-repudiation can only be > achieved > > once we have public-key crypto. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --0016e6407eba0c907d048782d239 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Repeating what I said before:

- separate spec is fine by= me
- part of the point I'm trying to make is that that spec = shouldn't be about signed _tokens_, but instead about signed _HTTP requ= ests_ (so instead of merely proving that you know a secret that came with t= he token, you =A0prove who you are when you use the token).=A0

I'd be interested what the Facebook guys think abou= t this - I believe the current signature scheme is in there mostly to addre= ss a use case they had.

Luke, Dave - would a separ= ate signing spec be ok with you guys?

Dirk.

On Tue, May 25, 2010 at 6:= 56 PM, Allen Tom <atom@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oauth-bounces@ietf.org= [oauth-bounces@ietf.org]= On Behalf Of Dirk
> Balfanz [balfanz@google.com]=
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to= , the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which = would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> ________________________= _______________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--0016e6407eba0c907d048782d239-- From mscurtescu@google.com Wed May 26 10:54:49 2010 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 6A95A3A67AD for ; Wed, 26 May 2010 10:54:49 -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 B3R2e+SYqaV2 for ; Wed, 26 May 2010 10:54:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5BFF23A68FA for ; Wed, 26 May 2010 10:54:48 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o4QHsbiG006374 for ; Wed, 26 May 2010 10:54:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274896478; bh=XMxrzPkwIfCLUre52j36QEtsxf8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=aKEEUVWr2FfXyHir3rq55HDA7X2I5wuUpxrR05umRqfwwolF0cL4oGrzh343NWs90 x2BG7B1pFXmG7DqIozdZQ== 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=BUdHEw1bDBSmXKP8/+qshL/+d6fNPiMeDzIy9FlQur0pJpX3j991hYgCNQ1dJ8Fup L8zWguZVjIoi626FC+T7A== Received: from pvg12 (pvg12.prod.google.com [10.241.210.140]) by kpbe16.cbf.corp.google.com with ESMTP id o4QHsZVV006143 for ; Wed, 26 May 2010 10:54:36 -0700 Received: by pvg12 with SMTP id 12so263612pvg.18 for ; Wed, 26 May 2010 10:54:35 -0700 (PDT) Received: by 10.141.214.15 with SMTP id r15mr6922113rvq.189.1274896474457; Wed, 26 May 2010 10:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Wed, 26 May 2010 10:54:14 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Wed, 26 May 2010 10:54:14 -0700 Message-ID: To: Nat Sakimura Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 26 May 2010 17:54:49 -0000 Hi Nat, The main use case for this flow would be for mobile apps that cannot handle long URLs, is that correct? If so, I assume that the only problematic long URL is the initial request sent through the user-agent to the authorization server, right? Does the Web Client run on the phone as well, or on some external web server? Marius On Wed, May 26, 2010 at 6:57 AM, Nat Sakimura wrote: > Back in February, I have suggested mobile web app flow to the oauth_wrap group. > Now that it is wrapped into OAuth 2.0, here is my another try, this > time for OAuth 2.0 draft. > > "OAuth 2.0 Mobile WebApp Flow" > http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ > > I really wish that this could be included in OAuth 2.0 as it will help > build identity layers on OAuth 2.0 that works for mobile web browsers etc. > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Wed May 26 10:55:43 2010 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 018B53A68D0 for ; Wed, 26 May 2010 10:55:43 -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 aeBR3e5eo-az for ; Wed, 26 May 2010 10:55:41 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id 3156B3A683C for ; Wed, 26 May 2010 10:55:41 -0700 (PDT) Received: by gxk20 with SMTP id 20so3723543gxk.12 for ; Wed, 26 May 2010 10:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZeXry2nnuP6nNx3Sh/DZdXBtbTl0We8o3t13KNTYz7g=; b=UUHbV3VjaRFUfrcmr1/q0qI0WUYQXHd827T2xHAi9trBC8PIDCz0V169vFDDzf8/Ke i44cYcb7IVT20N/Tge5GFh6bI4n7PD4al1evqRrATfNzEEUhstnoAuw+cH7OZn/wvVcy jbohNBnmlgdN1AXZYJjH7pCrkq9eiQ1LGHVOA= 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=md/j5DjgoG1R7zsTqaKpyL8dyhznndPDmshil0r1yCr5tJiitTXeDuK5zmiwFtREeT 06x1UfO2d8BOAcTFY9JUW7eR/1BA1PPr/85YtwPg6Nu4T+PO0Dv5UIGL306DiSfZWo0G KeI4lllUoYTS7UseBTG2vTGWmpLz/Izh85sH0= MIME-Version: 1.0 Received: by 10.231.166.66 with SMTP id l2mr7474806iby.61.1274896529495; Wed, 26 May 2010 10:55:29 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Wed, 26 May 2010 10:55:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 May 2010 11:55:29 -0600 Message-ID: From: David Recordon To: Dirk Balfanz Content-Type: multipart/alternative; boundary=005045013e3cc41634048782fa43 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 17:55:43 -0000 --005045013e3cc41634048782fa43 Content-Type: text/plain; charset=ISO-8859-1 I'd prefer that we keep signatures simple enough that they can remain in the core spec. --David On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote: > Repeating what I said before: > > - separate spec is fine by me > - part of the point I'm trying to make is that that spec shouldn't be about > signed _tokens_, but instead about signed _HTTP requests_ (so instead of > merely proving that you know a secret that came with the token, you prove > who you are when you use the token). > > I'd be interested what the Facebook guys think about this - I believe the > current signature scheme is in there mostly to address a use case they had. > > Luke, Dave - would a separate signing spec be ok with you guys? > > Dirk. > > > On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: > >> +1 >> >> I fully agree with Dirk and Brian that there needs to be some work on >> signatures. There are many types of applications that require higher >> levels >> of security than what bearer tokens can provide. >> >> That being said, I think that bearer token/refresh token model can >> satisify >> the majority of use cases - in fact it would satisfy 100% of all public >> APIs >> that we have at Yahoo. >> >> Perhaps in the interest of keeping the spec focused, it would make more >> sense to split out a Signed Token Spec, as Justin proposes, that is >> focused >> solely on uses cases that require a signature? >> >> Allen >> >> >> >> On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >> >> > I have a slightly more radical proposal. What if we factor out the >> signed >> > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, >> given >> > the same attention by the group and all that like Eran was talking about >> > yesterday. What this would take is taking out all reference to signing >> and >> > making core OAuth just about bare tokens, then have a separate spec that >> > details what to call your shared secret parameters, how to get them, and >> how >> > to sign with them. This makes the core spec a lot simpler (as detailed >> below) >> > but makes the overall use case of using signed tokens more complicated >> to >> > follow, as it'd be split in two. >> > >> > -- justin >> > ________________________________________ >> > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk >> > Balfanz [balfanz@google.com] >> > Sent: Thursday, May 20, 2010 7:39 PM >> > To: OAuth WG >> > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth >> 2 >> > >> > Hi guys, >> > >> > at today's interim meeting, we were discussing Brian Eaton's proposal >> for >> > OAuth signatures. He was proposing a mechanism that would (1) do away >> with >> > base string canonicalization, (2) allow for symmetric and public keys, >> and (3) >> > allow for extensibility. >> > >> > He got homework from the group to prove the feasibility of his proposal >> by >> > showing a couple of implementations. >> > >> > In this post, I would like to introduce another improvement of the OAuth >> 2 >> > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it >> would >> > work both with the signing mechanism in the current spec, as well as >> with >> > Brian's signature mechanism). The goal of my proposal is twofold: >> > >> > - it simplifies the spec. It will become more readable and therefore >> easier to >> > implement >> > - it separates out the mechanisms for delegated authorization and for >> > integrity protection into two independent pieces, which can be put >> together by >> > Servers and/or Clients like LEGO blocks. >> > >> > Summary: >> > >> > - use the client secret instead of the token secret for signing PR >> access >> > requests. >> > >> > Long version of the proposal: >> > >> > - remove all references to access tokens that are not bearer tokens from >> the >> > spec. >> > - stop calling the access tokens "bearer tokens". Call them just "access >> > tokens". >> > - remove all references to token secrets from the spec >> > - remove all parts of the spec that are of the kind "if bearer_token >> then X, >> > else Y", and replace them with X. >> > - delete section 5.3 >> > - add a section called "Request Authentication" that goes something like >> this: >> > >> > "Servers may require that requests be authenticated by the Client, so >> that >> > presentation of the access token alone is not sufficient to access a >> Protected >> > Resource. This has several use cases, including, but not limited to, >> the >> > following: >> > >> > - Non-repudiation: high-security deployments may require that requests >> be >> > authenticated (signed) in a non-repudiateable way[1] >> > - Access to protected resources is not protected by SSL, so that access >> tokens >> > may leak. >> > - End-to-end-integrity: even if SSL _is_ used, network infrastructure >> may >> > strip SSL protection before the request reaches the protected resource. >> The >> > protected resource, however, may require end-to-end integrity. >> > >> > If the Server requires that the Client authenticate PR access requests, >> then >> > the Client uses the following mechanism to sign their HTTP requests: >> [...]" >> > >> > Then, we basically drop the old Section 5.3 here (except we use the >> client >> > secret instead of the access token secret). Eventually, instead of >> Section >> > 5.3, we may have Brian's new signature scheme section here, which would >> add >> > the option of public-key crypto[1], etc. >> > >> > What do you guys think? >> > >> > Dirk. >> > >> > [1] Technically speaking, the goal of non-repudiation can only be >> achieved >> > once we have public-key crypto. >> > >> > _______________________________________________ >> > 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 > > --005045013e3cc41634048782fa43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd prefer that we keep signatures simple enough that they can remain i= n the core spec.

--David


On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <= balfanz@google.com> wro= te:
Repeating what I said before:

- separate spec is fine by me
- part of the point I'm t= rying to make is that that spec shouldn't be about signed _tokens_, but= instead about signed _HTTP requests_ (so instead of merely proving that yo= u know a secret that came with the token, you =A0prove who you are when you= use the token).=A0

I'd be interested what the Facebook guys think abou= t this - I believe the current signature scheme is in there mostly to addre= ss a use case they had.

Luke, Dave - would a separ= ate signing spec be ok with you guys?

Dirk.


On Tue, May 25, 2010 at 6:56 PM, All= en Tom <atom@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to= , the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which = would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



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


--005045013e3cc41634048782fa43-- From balfanz@google.com Wed May 26 11:15:53 2010 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 8F0803A698A for ; Wed, 26 May 2010 11:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 a5Rhgg+0FnCa for ; Wed, 26 May 2010 11:15:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 666383A68F8 for ; Wed, 26 May 2010 11:15:40 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o4QIFK0d028346 for ; Wed, 26 May 2010 11:15:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274897721; bh=gDWPgwNwj/8hP27LF37+OoC4Vs4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=aeZN4260Pvv+cdYFyoRuVsQ2obWhY8jHwJNFPBXLNAec9/uUnh9ElaHz/LH3z8nRF t5/cD3iyoYpJhpvkIdGNg== 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=AxtlFQaXT6fdPYxAgT2EMX9bNYpfArnNGtAMxttv9LH7Q9dHu1/2rKfRBTUe91kcz /xJwXvzghp2GaQ+qx+pZg== Received: from gwj19 (gwj19.prod.google.com [10.200.10.19]) by hpaq6.eem.corp.google.com with ESMTP id o4QIFIUM019138 for ; Wed, 26 May 2010 11:15:19 -0700 Received: by gwj19 with SMTP id 19so2488170gwj.8 for ; Wed, 26 May 2010 11:15:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.120.69 with SMTP id c5mr296556ibr.79.1274897718477; Wed, 26 May 2010 11:15:18 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Wed, 26 May 2010 11:15:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 May 2010 11:15:18 -0700 Message-ID: From: Dirk Balfanz To: David Recordon Content-Type: multipart/alternative; boundary=0016e6471226a2847904878341bb X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 18:15:53 -0000 --0016e6471226a2847904878341bb Content-Type: text/plain; charset=ISO-8859-1 Ok - to those advocating a separate spec: What if the separate spec was really simple (a couple of pages), and we just pasted it as "Section X" into the core OAuth spec? To Facebook: What if the core OAuth spec had a section called "Signed OAuth Requests" that (in its extreme form) had the single sentence: "If PRs require signing, then Clients use the XYZ mechanism to sign their OAuth requests" (with a link to XYZ)? Dirk. On Wed, May 26, 2010 at 10:55 AM, David Recordon wrote: > I'd prefer that we keep signatures simple enough that they can remain in > the core spec. > > --David > > > > On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote: > >> Repeating what I said before: >> >> - separate spec is fine by me >> - part of the point I'm trying to make is that that spec shouldn't be >> about signed _tokens_, but instead about signed _HTTP requests_ (so instead >> of merely proving that you know a secret that came with the token, you >> prove who you are when you use the token). >> >> I'd be interested what the Facebook guys think about this - I believe the >> current signature scheme is in there mostly to address a use case they had. >> >> Luke, Dave - would a separate signing spec be ok with you guys? >> >> Dirk. >> >> >> On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: >> >>> +1 >>> >>> I fully agree with Dirk and Brian that there needs to be some work on >>> signatures. There are many types of applications that require higher >>> levels >>> of security than what bearer tokens can provide. >>> >>> That being said, I think that bearer token/refresh token model can >>> satisify >>> the majority of use cases - in fact it would satisfy 100% of all public >>> APIs >>> that we have at Yahoo. >>> >>> Perhaps in the interest of keeping the spec focused, it would make more >>> sense to split out a Signed Token Spec, as Justin proposes, that is >>> focused >>> solely on uses cases that require a signature? >>> >>> Allen >>> >>> >>> >>> On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >>> >>> > I have a slightly more radical proposal. What if we factor out the >>> signed >>> > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, >>> given >>> > the same attention by the group and all that like Eran was talking >>> about >>> > yesterday. What this would take is taking out all reference to signing >>> and >>> > making core OAuth just about bare tokens, then have a separate spec >>> that >>> > details what to call your shared secret parameters, how to get them, >>> and how >>> > to sign with them. This makes the core spec a lot simpler (as detailed >>> below) >>> > but makes the overall use case of using signed tokens more complicated >>> to >>> > follow, as it'd be split in two. >>> > >>> > -- justin >>> > ________________________________________ >>> > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of >>> Dirk >>> > Balfanz [balfanz@google.com] >>> > Sent: Thursday, May 20, 2010 7:39 PM >>> > To: OAuth WG >>> > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth >>> 2 >>> > >>> > Hi guys, >>> > >>> > at today's interim meeting, we were discussing Brian Eaton's proposal >>> for >>> > OAuth signatures. He was proposing a mechanism that would (1) do away >>> with >>> > base string canonicalization, (2) allow for symmetric and public keys, >>> and (3) >>> > allow for extensibility. >>> > >>> > He got homework from the group to prove the feasibility of his proposal >>> by >>> > showing a couple of implementations. >>> > >>> > In this post, I would like to introduce another improvement of the >>> OAuth 2 >>> > signing mechanism, one which is orthogonal to Brian's proposal (i.e., >>> it would >>> > work both with the signing mechanism in the current spec, as well as >>> with >>> > Brian's signature mechanism). The goal of my proposal is twofold: >>> > >>> > - it simplifies the spec. It will become more readable and therefore >>> easier to >>> > implement >>> > - it separates out the mechanisms for delegated authorization and for >>> > integrity protection into two independent pieces, which can be put >>> together by >>> > Servers and/or Clients like LEGO blocks. >>> > >>> > Summary: >>> > >>> > - use the client secret instead of the token secret for signing PR >>> access >>> > requests. >>> > >>> > Long version of the proposal: >>> > >>> > - remove all references to access tokens that are not bearer tokens >>> from the >>> > spec. >>> > - stop calling the access tokens "bearer tokens". Call them just >>> "access >>> > tokens". >>> > - remove all references to token secrets from the spec >>> > - remove all parts of the spec that are of the kind "if bearer_token >>> then X, >>> > else Y", and replace them with X. >>> > - delete section 5.3 >>> > - add a section called "Request Authentication" that goes something >>> like this: >>> > >>> > "Servers may require that requests be authenticated by the Client, so >>> that >>> > presentation of the access token alone is not sufficient to access a >>> Protected >>> > Resource. This has several use cases, including, but not limited to, >>> the >>> > following: >>> > >>> > - Non-repudiation: high-security deployments may require that requests >>> be >>> > authenticated (signed) in a non-repudiateable way[1] >>> > - Access to protected resources is not protected by SSL, so that access >>> tokens >>> > may leak. >>> > - End-to-end-integrity: even if SSL _is_ used, network infrastructure >>> may >>> > strip SSL protection before the request reaches the protected resource. >>> The >>> > protected resource, however, may require end-to-end integrity. >>> > >>> > If the Server requires that the Client authenticate PR access requests, >>> then >>> > the Client uses the following mechanism to sign their HTTP requests: >>> [...]" >>> > >>> > Then, we basically drop the old Section 5.3 here (except we use the >>> client >>> > secret instead of the access token secret). Eventually, instead of >>> Section >>> > 5.3, we may have Brian's new signature scheme section here, which would >>> add >>> > the option of public-key crypto[1], etc. >>> > >>> > What do you guys think? >>> > >>> > Dirk. >>> > >>> > [1] Technically speaking, the goal of non-repudiation can only be >>> achieved >>> > once we have public-key crypto. >>> > >>> > _______________________________________________ >>> > 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 >> >> > --0016e6471226a2847904878341bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok - to those advocating a separate spec: What if the separate spec was rea= lly simple (a couple of pages), and we just pasted it as "Section X&qu= ot; into the core OAuth spec?

To Facebook: What if the c= ore OAuth spec had a section called "Signed OAuth Requests" that = (in its extreme form) had the single sentence: "If PRs require signing= , then Clients use the XYZ mechanism to sign their OAuth requests" (wi= th a link to XYZ)?

Dirk.

On Wed, May 26, 2010 at 10= :55 AM, David Recordon <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simple enough that they can remain i= n the core spec.

--David



On W= ed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

=
- separate spec is fine by me
- part of the point I'm tr= ying to make is that that spec shouldn't be about signed _tokens_, but = instead about signed _HTTP requests_ (so instead of merely proving that you= know a secret that came with the token, you =A0prove who you are when you = use the token).=A0

I'd be interested what the Facebook guys think abou= t this - I believe the current signature scheme is in there mostly to addre= ss a use case they had.

Luke, Dave - would a separ= ate signing spec be ok with you guys?

Dirk.


<= div class=3D"gmail_quote">On Tue, May 25, 2010 at 6:56 PM, Allen Tom <ato= m@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to= , the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which = would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



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



--0016e6471226a2847904878341bb-- From torsten@lodderstedt.net Wed May 26 11:18:22 2010 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 1B3C13A6876 for ; Wed, 26 May 2010 11:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_DE=0.35] 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 tpLHolwFB-w8 for ; Wed, 26 May 2010 11:18:21 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id 4067D3A694D for ; Wed, 26 May 2010 11:18:19 -0700 (PDT) Received: from p4fff1463.dip.t-dialin.net ([79.255.20.99] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OHLBA-0005u7-Er; Wed, 26 May 2010 20:18:08 +0200 Message-ID: <4BFD65D7.7050109@lodderstedt.net> Date: Wed, 26 May 2010 20:17:59 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Thomas Hardjono References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 26 May 2010 18:18:22 -0000 I also realized the parallels of refresh tokens and TGTs. That's why I said "Are these refresh tokens still long-living or as short-living as a Kerberos TGT?" when discussing Marius's proposal. In my opinion, the main difference between TGT and refresh token is the live-time. Refresh tokens may have a unlimited validity whereas TGTs as far as I know live for at least 24h (incl. re-newal). We can use refresh tokens the same way as TGTs but than every flow must return a refresh token and, in my opinion, aquisition of access tokens (or call it services tickets :-)) should be a second step using the refresh request. At request level, this would look as follows Obtaining token flow result HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "refresh_token":"8xLOxBtZp8" } Acquiring token for scope "calendar" Host: server.example.com Content-Type: application/x-www-form-urlencoded type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM& refresh_token=8xLOxBtZp8&scope=calendar HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkKG", "expires_in":3600 } Acquiring token for scope "contacts" Host: server.example.com Content-Type: application/x-www-form-urlencoded type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM& refresh_token=8xLOxBtZp8&scope=contacts HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkAB", "expires_in":3600 } regards, Torsten. > Hi Torsten, > > Looking at your example below (with the user having > to login/consent several times), it seems what is needed > is multiple short-term (narrower) tokens that is provably > derived from one single (parent) longer-life token. > So the human user would need to consent only once > to the parent longer-life token, and the client would > fetch the multiple shorter-life tokens automatically. > The keyword here is "provably" (which may be > read as "cryptographically provable"). > > BTW. Apologies for the history lesson, but > this was the same problem with Kerberos when > it was first deployed at MIT project Athena in the late 1980s. > The solution was to create a separate Ticket-Granting-Ticket (TGT) > with the user being prompted for a password only once. > Then the Kerberos client would obtain Service Tickets > (to access resources) using the TGT. > > /thomas/ > > > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of >> Torsten Lodderstedt >> Sent: Tuesday, May 25, 2010 4:21 PM >> To: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization >> flow? >> >> ..... >> With the current draft, the client has to send the user through the >> authz process n-times (n = number of services). This would look this: >> >> user accesses client >> REDIRECT AS >> Login at AS >> User Consent service 1 >> REDIRECT back >> get access token for service 1 >> REDIRECT AS >> SSO at AS >> User Consent service 2 >> REDIRECT back >> get access token for service 2 >> REDIRECT AS >> SSO at AS >> User Consent service 3 >> REDIRECT back >> get access token for service 3 >> >> What a user experience is that? And imagine such a use case for the >> device flow :-( >> >> Do we have other options to perform this process more user-friendly? >> >> First of all, how does the client request authorization for different >> services? As far as I see, the scope parameter is the only way to pass >> such information to the authorization server. So instead of mererly >> denoting permissions, we can use scopes as kind of service id + permissions. >> >> Which options do we have for returning tokens to the client? >> >> As proposed by Marius, the authorization server could issue a refresh >> token and the client could use the refresh request in combination with >> the downscoping feature in order to acquire access tokens. >> Consequences? >> In the setup illustrated above, the authorization server cannot create >> any access token (or an arbitrary one), it can only return a refresh >> token. This would mean to make the access token response parameter >> optional. Here I'm colliding with my mental picture of refresh tokens as >> long-living and storable tokens. Are these refresh tokens still >> long-living or as short-living as a Kerberos TGT? If they are still >> long-living, what about the use cases where we don't want to return >> refresh tokens? As far as I remember, user agent and username/password >> flow were candidates. How shall we handle them? >> >> Coming back to my original proposal: The authorization server could also >> issue multiple access tokens and (optionally) a refresh token - >> preserving the refresh token semantics. >> >> Justin pointed out that my original proposal added complexity to the >> simplest use case even if the authorization server does not issue >> multiple tokens. I understand your objection and would like to suggest a >> modified response structure. Instead of putting all access token into an >> array, the authz server could also use the structure as defined in the >> current draft and use another list of "additional_access_tokens", if >> more than one token has been created. >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> Cache-Control: no-store >> >> { >> "access_token":"SlAV32hkAB", >> "scopes":"calendar", >> "expires_in":3600, >> "refresh_token":"8xLOxBtZp8" >> additional_access_tokens = [{ "token":"SlAV32hkKG", >> "scopes":["calendar"], "expires_in":3600}, ...] >> } >> >> So in the simplest case, the response would look the same as before. >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> Cache-Control: no-store >> >> { >> "access_token":"SlAV32hkAB", >> "scopes":"calendar", >> "expires_in":3600, >> "refresh_token":"8xLOxBtZp8" >> } >> >> Thoughts? >> >> regards, >> Torsten. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From recordond@gmail.com Wed May 26 11:20:26 2010 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 E2E2A3A69B9 for ; Wed, 26 May 2010 11:20:25 -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 nU+7hR4sAZic for ; Wed, 26 May 2010 11:20:22 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 14A553A69B1 for ; Wed, 26 May 2010 11:20:21 -0700 (PDT) Received: by gwj15 with SMTP id 15so2405151gwj.31 for ; Wed, 26 May 2010 11:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WKlpnD/0QocSI+bHCuEH9tBobl5x9o/quoFoH3cAR/o=; b=GIBpnVYtPRQ/4QS8Kj3HZgWX6z5LEL9dU+9H0Zaro8vLRzUMyAIfob1GdT24YeQ/VL 3FcnBt5b1jI4Uf1NPjUievVRCrkrwpazgoHdREvyT0X7UjCy5RPrDdaHND8G+MLD7qvq 6yhxSOiXdotUajYO+P0L6CTI+Z0iuhEXlrcvo= 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=TZN7BX3Jh8LZVSiOl5TVqG2PW8ZmSaIX5uPHJq2rDx8k7FeeTML+7CZK2zhF3F3aXh 4xDipb45BNt5hMkEcI3CP9PU1ujei0HiDNYYctKhP9Vg1YFcmXSBKLNUquGx5hvC8lSN cQxAoAQ/Wra9B30KcaC9wpYAcuNRwHChNOaLA= MIME-Version: 1.0 Received: by 10.231.187.6 with SMTP id cu6mr6395456ibb.76.1274898009180; Wed, 26 May 2010 11:20:09 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Wed, 26 May 2010 11:20:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 May 2010 12:20:09 -0600 Message-ID: From: David Recordon To: Dirk Balfanz Content-Type: multipart/alternative; boundary=00504502cbccf64bfd04878352bf Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 18:20:26 -0000 --00504502cbccf64bfd04878352bf Content-Type: text/plain; charset=ISO-8859-1 How about we figure out the technical details of signatures before figuring out where they're placed? :) On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz wrote: > Ok - to those advocating a separate spec: What if the separate spec was > really simple (a couple of pages), and we just pasted it as "Section X" into > the core OAuth spec? > > To Facebook: What if the core OAuth spec had a section called "Signed OAuth > Requests" that (in its extreme form) had the single sentence: "If PRs > require signing, then Clients use the XYZ mechanism to sign their OAuth > requests" (with a link to XYZ)? > > Dirk. > > > On Wed, May 26, 2010 at 10:55 AM, David Recordon wrote: > >> I'd prefer that we keep signatures simple enough that they can remain in >> the core spec. >> >> --David >> >> >> >> On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote: >> >>> Repeating what I said before: >>> >>> - separate spec is fine by me >>> - part of the point I'm trying to make is that that spec shouldn't be >>> about signed _tokens_, but instead about signed _HTTP requests_ (so instead >>> of merely proving that you know a secret that came with the token, you >>> prove who you are when you use the token). >>> >>> I'd be interested what the Facebook guys think about this - I believe the >>> current signature scheme is in there mostly to address a use case they had. >>> >>> Luke, Dave - would a separate signing spec be ok with you guys? >>> >>> Dirk. >>> >>> >>> On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: >>> >>>> +1 >>>> >>>> I fully agree with Dirk and Brian that there needs to be some work on >>>> signatures. There are many types of applications that require higher >>>> levels >>>> of security than what bearer tokens can provide. >>>> >>>> That being said, I think that bearer token/refresh token model can >>>> satisify >>>> the majority of use cases - in fact it would satisfy 100% of all public >>>> APIs >>>> that we have at Yahoo. >>>> >>>> Perhaps in the interest of keeping the spec focused, it would make more >>>> sense to split out a Signed Token Spec, as Justin proposes, that is >>>> focused >>>> solely on uses cases that require a signature? >>>> >>>> Allen >>>> >>>> >>>> >>>> On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >>>> >>>> > I have a slightly more radical proposal. What if we factor out the >>>> signed >>>> > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, >>>> given >>>> > the same attention by the group and all that like Eran was talking >>>> about >>>> > yesterday. What this would take is taking out all reference to signing >>>> and >>>> > making core OAuth just about bare tokens, then have a separate spec >>>> that >>>> > details what to call your shared secret parameters, how to get them, >>>> and how >>>> > to sign with them. This makes the core spec a lot simpler (as detailed >>>> below) >>>> > but makes the overall use case of using signed tokens more complicated >>>> to >>>> > follow, as it'd be split in two. >>>> > >>>> > -- justin >>>> > ________________________________________ >>>> > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of >>>> Dirk >>>> > Balfanz [balfanz@google.com] >>>> > Sent: Thursday, May 20, 2010 7:39 PM >>>> > To: OAuth WG >>>> > Subject: [OAUTH-WG] proposal for factoring out request signing in >>>> OAuth 2 >>>> > >>>> > Hi guys, >>>> > >>>> > at today's interim meeting, we were discussing Brian Eaton's proposal >>>> for >>>> > OAuth signatures. He was proposing a mechanism that would (1) do away >>>> with >>>> > base string canonicalization, (2) allow for symmetric and public keys, >>>> and (3) >>>> > allow for extensibility. >>>> > >>>> > He got homework from the group to prove the feasibility of his >>>> proposal by >>>> > showing a couple of implementations. >>>> > >>>> > In this post, I would like to introduce another improvement of the >>>> OAuth 2 >>>> > signing mechanism, one which is orthogonal to Brian's proposal (i.e., >>>> it would >>>> > work both with the signing mechanism in the current spec, as well as >>>> with >>>> > Brian's signature mechanism). The goal of my proposal is twofold: >>>> > >>>> > - it simplifies the spec. It will become more readable and therefore >>>> easier to >>>> > implement >>>> > - it separates out the mechanisms for delegated authorization and for >>>> > integrity protection into two independent pieces, which can be put >>>> together by >>>> > Servers and/or Clients like LEGO blocks. >>>> > >>>> > Summary: >>>> > >>>> > - use the client secret instead of the token secret for signing PR >>>> access >>>> > requests. >>>> > >>>> > Long version of the proposal: >>>> > >>>> > - remove all references to access tokens that are not bearer tokens >>>> from the >>>> > spec. >>>> > - stop calling the access tokens "bearer tokens". Call them just >>>> "access >>>> > tokens". >>>> > - remove all references to token secrets from the spec >>>> > - remove all parts of the spec that are of the kind "if bearer_token >>>> then X, >>>> > else Y", and replace them with X. >>>> > - delete section 5.3 >>>> > - add a section called "Request Authentication" that goes something >>>> like this: >>>> > >>>> > "Servers may require that requests be authenticated by the Client, so >>>> that >>>> > presentation of the access token alone is not sufficient to access a >>>> Protected >>>> > Resource. This has several use cases, including, but not limited to, >>>> the >>>> > following: >>>> > >>>> > - Non-repudiation: high-security deployments may require that requests >>>> be >>>> > authenticated (signed) in a non-repudiateable way[1] >>>> > - Access to protected resources is not protected by SSL, so that >>>> access tokens >>>> > may leak. >>>> > - End-to-end-integrity: even if SSL _is_ used, network infrastructure >>>> may >>>> > strip SSL protection before the request reaches the protected >>>> resource. The >>>> > protected resource, however, may require end-to-end integrity. >>>> > >>>> > If the Server requires that the Client authenticate PR access >>>> requests, then >>>> > the Client uses the following mechanism to sign their HTTP requests: >>>> [...]" >>>> > >>>> > Then, we basically drop the old Section 5.3 here (except we use the >>>> client >>>> > secret instead of the access token secret). Eventually, instead of >>>> Section >>>> > 5.3, we may have Brian's new signature scheme section here, which >>>> would add >>>> > the option of public-key crypto[1], etc. >>>> > >>>> > What do you guys think? >>>> > >>>> > Dirk. >>>> > >>>> > [1] Technically speaking, the goal of non-repudiation can only be >>>> achieved >>>> > once we have public-key crypto. >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >>> >> > --00504502cbccf64bfd04878352bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How about we figure out the technical details of signatures before figuring= out where they're placed? :) </bikeshed>


On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balfanz@google.com&g= t; wrote:
Ok - to those advocating a separate spec: W= hat if the separate spec was really simple (a couple of pages), and we just= pasted it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section calle= d "Signed OAuth Requests" that (in its extreme form) had the sing= le sentence: "If PRs require signing, then Clients use the XYZ mechani= sm to sign their OAuth requests" (with a link to XYZ)?

Dirk.


On Wed, May 26, 2010 at 10:55 AM, Da= vid Recordon <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simple enough that they can remain i= n the core spec.

--David



On Wed, May 26, 2= 010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

=
- separate spec is fine by me
- part of the point I'm tr= ying to make is that that spec shouldn't be about signed _tokens_, but = instead about signed _HTTP requests_ (so instead of merely proving that you= know a secret that came with the token, you =A0prove who you are when you = use the token).=A0

I'd be interested what the Facebook guys think abou= t this - I believe the current signature scheme is in there mostly to addre= ss a use case they had.

Luke, Dave - would a separ= ate signing spec be ok with you guys?

Dirk.


<= div class=3D"gmail_quote">On Tue, May 25, 2010 at 6:56 PM, Allen Tom <ato= m@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to= , the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which = would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



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




--00504502cbccf64bfd04878352bf-- From torsten@lodderstedt.net Wed May 26 11:26:30 2010 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 E47CC3A69B9 for ; Wed, 26 May 2010 11:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.22 X-Spam-Level: * X-Spam-Status: No, score=1.22 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] 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 mLfZ7OsNqKLX for ; Wed, 26 May 2010 11:26:30 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id A574A3A69B4 for ; Wed, 26 May 2010 11:26:29 -0700 (PDT) Received: from p4fff1463.dip.t-dialin.net ([79.255.20.99] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OHLJ5-0008Mx-KK; Wed, 26 May 2010 20:26:19 +0200 Message-ID: <4BFD67CA.5040600@lodderstedt.net> Date: Wed, 26 May 2010 20:26:18 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] in-app logout? 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, 26 May 2010 18:26:31 -0000 Hi Eran, in my perception, there is some support on the list for having a request to revoke refresh tokens. Will you add such a request to the specification? Do you need a text proposal? regards, Torsten. > IMHO this would look more like a hack than proper protocol design. We need > a delete/revoke operation that's the pendant to the other token operations (i.e. > crud ops). > > Hubert > > > > On Fri, May 21, 2010 at 7:05 PM, Beau Lebens wrote: > >> Could this just be implemented through support for a scope change >> where scope=none or revoke or something? >> >> On Friday, May 21, 2010, Lukas Rosenstock wrote: >> >>> Why not simply add this functionality to the token endpoint?The same place that was used to fetch the access token first or refresh it could be used to revoke the same token with another request. The only requirement would be to define something like type=revoke. >>> I feel that is much easier than making the token a URL which supports DELETE. >>> However, any mechanism will break implementations that rely on minimal or no communication between authorization server and protected resource, because all protected resources have to be informed. >>> >>> Regards, Lukas >>> >>> 2010/5/16 Dick Hardt >>> >>> James: An important capability of the refresh token is that it *can* be a self contained token in that is not an id, but a signed token that can be examined and acted upon on presentation. >>> Torsten: enabling a client to revoke a refresh token looks like a useful mechanism. I anticipate it will be viewed as a vitamin feature rather than a painkiller and will fall by the wayside unless the security conscience rally to have it included. >>> >>> >>> -- Dick >>> >>> >>> On Thu, May 13, 2010 at 7:10 AM, Manger, James H wrote: >>> Torsten, >>> >>> >>>> What about refresh token revocation/deletion? >>>> >>> HTTP already has a method to do this: DELETE >>> It just needs each token to have a URI. >>> >>> Tokens (almost) already have URIs -- its just not immediately obvious because the URI has to be built from a common token endpoint and a refresh_token. >>> >>> I think it would improve the spec if refresh_token was renamed to, say, token_id; and its value defined as a URI (which can be a relative URI so the string may not need to change at all). >>> >>> To refresh a token you POST to the token's URI. >>> To delete a token you send a DELETE request to the token's URI. >>> >>> It doesn't cause major changes, but there are some benefits. >>> It is a more web-style design. >>> It leaves only 1 type of token in the spec -- an access token -- which simplifies the text and aids understanding. >>> There are no arguments about length, allowed chars etc because it is a URI -- a well-known type, often with native support. >>> Its obvious how to delete the token as there is a standard HTTP method DELETE to apply to the token URI. >>> >>> If a particular service supported an additional way to delete items in its API (eg POST with a method=delete query parameter) that could apply to the OAuth part as well. >>> >>> -- >>> James Manger >>> _______________________________________________ >>> 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 >>> >>> >>> >>> -- >>> http://lukasrosenstock.net/ >>> >>> >>> >> _______________________________________________ >> 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 hardjono@mit.edu Wed May 26 11:28:07 2010 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 68F463A69B1 for ; Wed, 26 May 2010 11:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 g5CLrDdtuQ5z for ; Wed, 26 May 2010 11:28:06 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id D7B4A3A69A2 for ; Wed, 26 May 2010 11:28:05 -0700 (PDT) X-AuditID: 12074424-b7b9dae000002832-19-4bfd682cbd2a Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 19.98.10290.C286DFB4; Wed, 26 May 2010 14:27:56 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o4QIRuht019513; Wed, 26 May 2010 14:27:56 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4QIRtMB019026; Wed, 26 May 2010 14:27:55 -0400 Received: from w92exhub5.exchange.mit.edu (18.7.73.11) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 May 2010 14:27:54 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub5.exchange.mit.edu ([18.7.73.11]) with mapi; Wed, 26 May 2010 14:27:54 -0400 From: Thomas Hardjono To: Torsten Lodderstedt Date: Wed, 26 May 2010 14:27:52 -0400 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr8/83QU8nwWobeTnSA46z98R2HuQAAKf4w Message-ID: References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFD65D7.7050109@lodderstedt.net> In-Reply-To: <4BFD65D7.7050109@lodderstedt.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 X-Brightmail-Tracker: AAAAAA== Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 26 May 2010 18:28:07 -0000 I do realize several people on this list should see the parallel :) Sever= al folks at the last IETF OAuth meeting also brought-up the similarities. One of the aspect unclear to me with OAuth draft-05 is the cryptographic re= lationship between the Refresh Token ("8xLOxBtZp8") and the Calendar token = ("SlAV32hkKG") & Contacts token ("SlAV32hkAB"). That is, how can a verifyi= ng third party be satisfied that the access came from the same Client/Sessi= on. /thomas/ __________________________________________ > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Wednesday, May 26, 2010 2:18 PM > To: Thomas Hardjono > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] multiple access tokens from a single authorizatio= n > flow? >=20 > I also realized the parallels of refresh tokens and TGTs. That's why I sa= id >=20 > "Are these refresh tokens still long-living or as short-living as a > Kerberos TGT?" >=20 > when discussing Marius's proposal. In my opinion, the main difference > between TGT and refresh token is the live-time. Refresh tokens may have > a unlimited validity whereas TGTs as far as I know live for at least 24h > (incl. re-newal). >=20 > We can use refresh tokens the same way as TGTs but than every flow must > return a refresh token and, in my opinion, aquisition of access tokens > (or call it services tickets :-)) should be a second step using the > refresh request. >=20 > At request level, this would look as follows >=20 > Obtaining token flow result >=20 > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store >=20 > { > "refresh_token":"8xLOxBtZp8" > } >=20 > Acquiring token for scope "calendar" >=20 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded >=20 > type=3Drefresh_token&client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpn= qmM& > refresh_token=3D8xLOxBtZp8&scope=3Dcalendar >=20 > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store >=20 > { > "access_token":"SlAV32hkKG", > "expires_in":3600 > } >=20 > Acquiring token for scope "contacts" >=20 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded >=20 > type=3Drefresh_token&client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpn= qmM& > refresh_token=3D8xLOxBtZp8&scope=3Dcontacts >=20 > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store >=20 > { > "access_token":"SlAV32hkAB", > "expires_in":3600 > } >=20 >=20 > regards, > Torsten. >=20 > > Hi Torsten, > > > > Looking at your example below (with the user having > > to login/consent several times), it seems what is needed > > is multiple short-term (narrower) tokens that is provably > > derived from one single (parent) longer-life token. > > So the human user would need to consent only once > > to the parent longer-life token, and the client would > > fetch the multiple shorter-life tokens automatically. > > The keyword here is "provably" (which may be > > read as "cryptographically provable"). > > > > BTW. Apologies for the history lesson, but > > this was the same problem with Kerberos when > > it was first deployed at MIT project Athena in the late 1980s. > > The solution was to create a separate Ticket-Granting-Ticket (TGT) > > with the user being prompted for a password only once. > > Then the Kerberos client would obtain Service Tickets > > (to access resources) using the TGT. > > > > /thomas/ > > > > > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= Of > >> Torsten Lodderstedt > >> Sent: Tuesday, May 25, 2010 4:21 PM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] multiple access tokens from a single authoriza= tion > >> flow? > >> > >> ..... > >> With the current draft, the client has to send the user through the > >> authz process n-times (n =3D number of services). This would look this= : > >> > >> user accesses client > >> REDIRECT AS > >> Login at AS > >> User Consent service 1 > >> REDIRECT back > >> get access token for service 1 > >> REDIRECT AS > >> SSO at AS > >> User Consent service 2 > >> REDIRECT back > >> get access token for service 2 > >> REDIRECT AS > >> SSO at AS > >> User Consent service 3 > >> REDIRECT back > >> get access token for service 3 > >> > >> What a user experience is that? And imagine such a use case for the > >> device flow :-( > >> > >> Do we have other options to perform this process more user-friendly? > >> > >> First of all, how does the client request authorization for different > >> services? As far as I see, the scope parameter is the only way to pass > >> such information to the authorization server. So instead of mererly > >> denoting permissions, we can use scopes as kind of service id + > permissions. > >> > >> Which options do we have for returning tokens to the client? > >> > >> As proposed by Marius, the authorization server could issue a refresh > >> token and the client could use the refresh request in combination with > >> the downscoping feature in order to acquire access tokens. > >> Consequences? > >> In the setup illustrated above, the authorization server cannot create > >> any access token (or an arbitrary one), it can only return a refresh > >> token. This would mean to make the access token response parameter > >> optional. Here I'm colliding with my mental picture of refresh tokens = as > >> long-living and storable tokens. Are these refresh tokens still > >> long-living or as short-living as a Kerberos TGT? If they are still > >> long-living, what about the use cases where we don't want to return > >> refresh tokens? As far as I remember, user agent and username/password > >> flow were candidates. How shall we handle them? > >> > >> Coming back to my original proposal: The authorization server could al= so > >> issue multiple access tokens and (optionally) a refresh token - > >> preserving the refresh token semantics. > >> > >> Justin pointed out that my original proposal added complexity to the > >> simplest use case even if the authorization server does not issue > >> multiple tokens. I understand your objection and would like to suggest= a > >> modified response structure. Instead of putting all access token into = an > >> array, the authz server could also use the structure as defined in the > >> current draft and use another list of "additional_access_tokens", if > >> more than one token has been created. > >> > >> HTTP/1.1 200 OK > >> Content-Type: application/json > >> Cache-Control: no-store > >> > >> { > >> "access_token":"SlAV32hkAB", > >> "scopes":"calendar", > >> "expires_in":3600, > >> "refresh_token":"8xLOxBtZp8" > >> additional_access_tokens =3D [{ "token":"SlAV32hkKG", > >> "scopes":["calendar"], "expires_in":3600}, ...] > >> } > >> > >> So in the simplest case, the response would look the same as before. > >> > >> HTTP/1.1 200 OK > >> Content-Type: application/json > >> Cache-Control: no-store > >> > >> { > >> "access_token":"SlAV32hkAB", > >> "scopes":"calendar", > >> "expires_in":3600, > >> "refresh_token":"8xLOxBtZp8" > >> } > >> > >> Thoughts? > >> > >> regards, > >> Torsten. > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> >=20 From jricher@mitre.org Wed May 26 11:48:40 2010 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 11CA53A6993 for ; Wed, 26 May 2010 11:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 8+ejvF4HMuZC for ; Wed, 26 May 2010 11:48:38 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7046D3A6920 for ; Wed, 26 May 2010 11:48:38 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4QImSav021435 for ; Wed, 26 May 2010 14:48:29 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4QImSD7021429; Wed, 26 May 2010 14:48:28 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.210]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 26 May 2010 14:48:28 -0400 From: "Richer, Justin P." To: Dirk Balfanz , David Recordon Date: Wed, 26 May 2010 14:45:23 -0400 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr8/3lJg5dawbvITqqzxsSAYHcvFgABCBtb Message-ID: References: , 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 WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 18:48:40 -0000 I'm fine with it staying as the new-and-improved section 5.3, but it seems = like it would be a natural piece to be factored out. As an extension, it co= uld say things like "For any flow, the AS can return a secret with the toke= n" instead of having it be peppered through all sections like it is today. = Maybe we can do that in an internal section? I'm not the wizard of normativ= e language that Eran is. :)=20 So really, I'm more arguing for refactoring, whether the language stays ins= ide of the OAuth spec or beside it ends up being beside the point. -- justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk Bal= fanz [balfanz@google.com] Sent: Wednesday, May 26, 2010 2:15 PM To: David Recordon Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth= 2 Ok - to those advocating a separate spec: What if the separate spec was rea= lly simple (a couple of pages), and we just pasted it as "Section X" into t= he core OAuth spec? To Facebook: What if the core OAuth spec had a section called "Signed OAuth= Requests" that (in its extreme form) had the single sentence: "If PRs requ= ire signing, then Clients use the XYZ mechanism to sign their OAuth request= s" (with a link to XYZ)? Dirk. On Wed, May 26, 2010 at 10:55 AM, David Recordon > wrote: I'd prefer that we keep signatures simple enough that they can remain in th= e core spec. --David On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz > wrote: Repeating what I said before: - separate spec is fine by me - part of the point I'm trying to make is that that spec shouldn't be about= signed _tokens_, but instead about signed _HTTP requests_ (so instead of m= erely proving that you know a secret that came with the token, you prove w= ho you are when you use the token). I'd be interested what the Facebook guys think about this - I believe the c= urrent signature scheme is in there mostly to address a use case they had. Luke, Dave - would a separate signing spec be ok with you guys? Dirk. On Tue, May 25, 2010 at 6:56 PM, Allen Tom > wrote: +1 I fully agree with Dirk and Brian that there needs to be some work on signatures. There are many types of applications that require higher levels of security than what bearer tokens can provide. That being said, I think that bearer token/refresh token model can satisify the majority of use cases - in fact it would satisfy 100% of all public API= s that we have at Yahoo. Perhaps in the interest of keeping the spec focused, it would make more sense to split out a Signed Token Spec, as Justin proposes, that is focused solely on uses cases that require a signature? Allen On 5/21/10 11:27 AM, "Richer, Justin P." > wrote: > I have a slightly more radical proposal. What if we factor out the signed > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, giv= en > the same attention by the group and all that like Eran was talking about > yesterday. What this would take is taking out all reference to signing an= d > making core OAuth just about bare tokens, then have a separate spec that > details what to call your shared secret parameters, how to get them, and = how > to sign with them. This makes the core spec a lot simpler (as detailed be= low) > but makes the overall use case of using signed tokens more complicated to > follow, as it'd be split in two. > > -- justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounce= s@ietf.org] On Behalf Of Dirk > Balfanz [balfanz@google.com] > Sent: Thursday, May 20, 2010 7:39 PM > To: OAuth WG > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away wit= h > base string canonicalization, (2) allow for symmetric and public keys, an= d (3) > allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal b= y > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth = 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it = would > work both with the signing mechanism in the current spec, as well as with > Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easi= er to > implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put togeth= er by > Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from = the > spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then= X, > else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like = this: > > "Servers may require that requests be authenticated by the Client, so tha= t > presentation of the access token alone is not sufficient to access a Prot= ected > Resource. This has several use cases, including, but not limited to, the > following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access t= okens > may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. T= he > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, t= hen > the Client uses the following mechanism to sign their HTTP requests: [...= ]" > > Then, we basically drop the old Section 5.3 here (except we use the clien= t > secret instead of the access token secret). Eventually, instead of Sectio= n > 5.3, we may have Brian's new signature scheme section here, which would a= dd > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieve= d > once we have public-key crypto. > > _______________________________________________ > 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 jricher@mitre.org Wed May 26 11:51:58 2010 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 4EDC53A69C0 for ; Wed, 26 May 2010 11:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 jV0mhSMeBfyS for ; Wed, 26 May 2010 11:51:57 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id C60023A6987 for ; Wed, 26 May 2010 11:51:56 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4QIplgG024735 for ; Wed, 26 May 2010 14:51:47 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o4QIplOX024732; Wed, 26 May 2010 14:51:47 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.210]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 26 May 2010 14:51:47 -0400 From: "Richer, Justin P." To: Thomas Hardjono , Torsten Lodderstedt Date: Wed, 26 May 2010 14:49:50 -0400 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr8/83QU8nwWobeTnSA46z98R2HuQAAKf4wAADwy4Q= Message-ID: References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFD65D7.7050109@lodderstedt.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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 26 May 2010 18:51:58 -0000 >From what I understand, there is no inherent similarity between the two. Yo= u *can* wire up your AS and PR to do some verification of that caliber, but= it's not required by the OAuth spec. For cases when the AS and PR are coll= apsed into a single system (which is a large percentage of use cases outsid= e of the Big Internet Companies, from what I gather), then all you need to = do to prove that the access and refresh token are related is by a lookup to= a local database table.=20 -- justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Thomas H= ardjono [hardjono@MIT.EDU] Sent: Wednesday, May 26, 2010 2:27 PM To: Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization = flow? I do realize several people on this list should see the parallel :) Sever= al folks at the last IETF OAuth meeting also brought-up the similarities. One of the aspect unclear to me with OAuth draft-05 is the cryptographic re= lationship between the Refresh Token ("8xLOxBtZp8") and the Calendar token = ("SlAV32hkKG") & Contacts token ("SlAV32hkAB"). That is, how can a verifyi= ng third party be satisfied that the access came from the same Client/Sessi= on. /thomas/ __________________________________________ > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Wednesday, May 26, 2010 2:18 PM > To: Thomas Hardjono > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] multiple access tokens from a single authorizatio= n > flow? > > I also realized the parallels of refresh tokens and TGTs. That's why I sa= id > > "Are these refresh tokens still long-living or as short-living as a > Kerberos TGT?" > > when discussing Marius's proposal. In my opinion, the main difference > between TGT and refresh token is the live-time. Refresh tokens may have > a unlimited validity whereas TGTs as far as I know live for at least 24h > (incl. re-newal). > > We can use refresh tokens the same way as TGTs but than every flow must > return a refresh token and, in my opinion, aquisition of access tokens > (or call it services tickets :-)) should be a second step using the > refresh request. > > At request level, this would look as follows > > Obtaining token flow result > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "refresh_token":"8xLOxBtZp8" > } > > Acquiring token for scope "calendar" > > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > type=3Drefresh_token&client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpn= qmM& > refresh_token=3D8xLOxBtZp8&scope=3Dcalendar > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"SlAV32hkKG", > "expires_in":3600 > } > > Acquiring token for scope "contacts" > > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > type=3Drefresh_token&client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpn= qmM& > refresh_token=3D8xLOxBtZp8&scope=3Dcontacts > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"SlAV32hkAB", > "expires_in":3600 > } > > > regards, > Torsten. > > > Hi Torsten, > > > > Looking at your example below (with the user having > > to login/consent several times), it seems what is needed > > is multiple short-term (narrower) tokens that is provably > > derived from one single (parent) longer-life token. > > So the human user would need to consent only once > > to the parent longer-life token, and the client would > > fetch the multiple shorter-life tokens automatically. > > The keyword here is "provably" (which may be > > read as "cryptographically provable"). > > > > BTW. Apologies for the history lesson, but > > this was the same problem with Kerberos when > > it was first deployed at MIT project Athena in the late 1980s. > > The solution was to create a separate Ticket-Granting-Ticket (TGT) > > with the user being prompted for a password only once. > > Then the Kerberos client would obtain Service Tickets > > (to access resources) using the TGT. > > > > /thomas/ > > > > > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= Of > >> Torsten Lodderstedt > >> Sent: Tuesday, May 25, 2010 4:21 PM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] multiple access tokens from a single authoriza= tion > >> flow? > >> > >> ..... > >> With the current draft, the client has to send the user through the > >> authz process n-times (n =3D number of services). This would look this= : > >> > >> user accesses client > >> REDIRECT AS > >> Login at AS > >> User Consent service 1 > >> REDIRECT back > >> get access token for service 1 > >> REDIRECT AS > >> SSO at AS > >> User Consent service 2 > >> REDIRECT back > >> get access token for service 2 > >> REDIRECT AS > >> SSO at AS > >> User Consent service 3 > >> REDIRECT back > >> get access token for service 3 > >> > >> What a user experience is that? And imagine such a use case for the > >> device flow :-( > >> > >> Do we have other options to perform this process more user-friendly? > >> > >> First of all, how does the client request authorization for different > >> services? As far as I see, the scope parameter is the only way to pass > >> such information to the authorization server. So instead of mererly > >> denoting permissions, we can use scopes as kind of service id + > permissions. > >> > >> Which options do we have for returning tokens to the client? > >> > >> As proposed by Marius, the authorization server could issue a refresh > >> token and the client could use the refresh request in combination with > >> the downscoping feature in order to acquire access tokens. > >> Consequences? > >> In the setup illustrated above, the authorization server cannot create > >> any access token (or an arbitrary one), it can only return a refresh > >> token. This would mean to make the access token response parameter > >> optional. Here I'm colliding with my mental picture of refresh tokens = as > >> long-living and storable tokens. Are these refresh tokens still > >> long-living or as short-living as a Kerberos TGT? If they are still > >> long-living, what about the use cases where we don't want to return > >> refresh tokens? As far as I remember, user agent and username/password > >> flow were candidates. How shall we handle them? > >> > >> Coming back to my original proposal: The authorization server could al= so > >> issue multiple access tokens and (optionally) a refresh token - > >> preserving the refresh token semantics. > >> > >> Justin pointed out that my original proposal added complexity to the > >> simplest use case even if the authorization server does not issue > >> multiple tokens. I understand your objection and would like to suggest= a > >> modified response structure. Instead of putting all access token into = an > >> array, the authz server could also use the structure as defined in the > >> current draft and use another list of "additional_access_tokens", if > >> more than one token has been created. > >> > >> HTTP/1.1 200 OK > >> Content-Type: application/json > >> Cache-Control: no-store > >> > >> { > >> "access_token":"SlAV32hkAB", > >> "scopes":"calendar", > >> "expires_in":3600, > >> "refresh_token":"8xLOxBtZp8" > >> additional_access_tokens =3D [{ "token":"SlAV32hkKG", > >> "scopes":["calendar"], "expires_in":3600}, ...] > >> } > >> > >> So in the simplest case, the response would look the same as before. > >> > >> HTTP/1.1 200 OK > >> Content-Type: application/json > >> Cache-Control: no-store > >> > >> { > >> "access_token":"SlAV32hkAB", > >> "scopes":"calendar", > >> "expires_in":3600, > >> "refresh_token":"8xLOxBtZp8" > >> } > >> > >> Thoughts? > >> > >> regards, > >> Torsten. > >> > >> _______________________________________________ > >> 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 igor.faynberg@alcatel-lucent.com Wed May 26 11:53:11 2010 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 6EDF73A69BE for ; Wed, 26 May 2010 11:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] 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 V4POxUXjteVp for ; Wed, 26 May 2010 11:53:10 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 40F533A69DD for ; Wed, 26 May 2010 11:53:10 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o4QIqwnw000951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 May 2010 13:52:58 -0500 (CDT) Received: from [135.244.9.24] (faynberg.lra.lucent.com [135.244.9.24]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o4QIqvW1022261; Wed, 26 May 2010 13:52:58 -0500 (CDT) Message-ID: <4BFD6E08.3040802@alcatel-lucent.com> Date: Wed, 26 May 2010 14:52:56 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <4BFD67CA.5040600@lodderstedt.net> In-Reply-To: <4BFD67CA.5040600@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:53:11 -0000 +1 on the support. Torsten, I just wonder if you see this as (possible a part of ) a single-sign off method? Igor Torsten Lodderstedt wrote: > Hi Eran, > > in my perception, there is some support on the list for having a > request to revoke refresh tokens. Will you add such a request to the > specification? Do you need a text proposal? > > regards, > Torsten. > >> IMHO this would look more like a hack than proper protocol design. We >> need >> a delete/revoke operation that's the pendant to the other token >> operations (i.e. >> crud ops). >> >> Hubert >> >> >> >> On Fri, May 21, 2010 at 7:05 PM, Beau >> Lebens wrote: >> >>> Could this just be implemented through support for a scope change >>> where scope=none or revoke or something? >>> >>> On Friday, May 21, 2010, Lukas Rosenstock >>> wrote: >>> >>>> Why not simply add this functionality to the token endpoint?The >>>> same place that was used to fetch the access token first or refresh >>>> it could be used to revoke the same token with another request. The >>>> only requirement would be to define something like type=revoke. >>>> I feel that is much easier than making the token a URL which >>>> supports DELETE. >>>> However, any mechanism will break implementations that rely on >>>> minimal or no communication between authorization server and >>>> protected resource, because all protected resources have to be >>>> informed. >>>> >>>> Regards, Lukas >>>> >>>> 2010/5/16 Dick Hardt >>>> >>>> James: An important capability of the refresh token is that it >>>> *can* be a self contained token in that is not an id, but a signed >>>> token that can be examined and acted upon on presentation. >>>> Torsten: enabling a client to revoke a refresh token looks like a >>>> useful mechanism. I anticipate it will be viewed as a vitamin >>>> feature rather than a painkiller and will fall by the wayside >>>> unless the security conscience rally to have it included. >>>> >>>> >>>> -- Dick >>>> >>>> >>>> On Thu, May 13, 2010 at 7:10 AM, Manger, James >>>> H wrote: >>>> Torsten, >>>> >>>> >>>>> What about refresh token revocation/deletion? >>>>> >>>> HTTP already has a method to do this: DELETE >>>> It just needs each token to have a URI. >>>> >>>> Tokens (almost) already have URIs -- its just not immediately >>>> obvious because the URI has to be built from a common token >>>> endpoint and a refresh_token. >>>> >>>> I think it would improve the spec if refresh_token was renamed to, >>>> say, token_id; and its value defined as a URI (which can be a >>>> relative URI so the string may not need to change at all). >>>> >>>> To refresh a token you POST to the token's URI. >>>> To delete a token you send a DELETE request to the token's URI. >>>> >>>> It doesn't cause major changes, but there are some benefits. >>>> It is a more web-style design. >>>> It leaves only 1 type of token in the spec -- an access token -- >>>> which simplifies the text and aids understanding. >>>> There are no arguments about length, allowed chars etc because it >>>> is a URI -- a well-known type, often with native support. >>>> Its obvious how to delete the token as there is a standard HTTP >>>> method DELETE to apply to the token URI. >>>> >>>> If a particular service supported an additional way to delete items >>>> in its API (eg POST with a method=delete query parameter) that >>>> could apply to the OAuth part as well. >>>> >>>> -- >>>> James Manger >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> -- >>>> http://lukasrosenstock.net/ >>>> >>>> >>>> >>> _______________________________________________ >>> 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 hardjono@mit.edu Wed May 26 12:49:16 2010 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 412213A68FD for ; Wed, 26 May 2010 12:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 UdsFfYSPdP2a for ; Wed, 26 May 2010 12:49:14 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 636503A69DB for ; Wed, 26 May 2010 12:49:13 -0700 (PDT) X-AuditID: 12074424-b7b9dae000002832-b1-4bfd7b3071aa Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 48.6C.10290.03B7DFB4; Wed, 26 May 2010 15:49:04 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o4QJn4rQ026913; Wed, 26 May 2010 15:49:04 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o4QJn3cj030690; Wed, 26 May 2010 15:49:03 -0400 Received: from oc11exhub2.exchange.mit.edu (18.9.3.12) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 26 May 2010 15:48:37 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub2.exchange.mit.edu ([18.9.3.12]) with mapi; Wed, 26 May 2010 15:49:02 -0400 From: Thomas Hardjono To: "Richer, Justin P." , Torsten Lodderstedt Date: Wed, 26 May 2010 15:49:01 -0400 Thread-Topic: [OAUTH-WG] multiple access tokens from a single authorization flow? Thread-Index: Acr8/83QU8nwWobeTnSA46z98R2HuQAAKf4wAADwy4QAAdN4UA== Message-ID: References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFD65D7.7050109@lodderstedt.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 X-Brightmail-Tracker: AAAAAA== Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 26 May 2010 19:49:16 -0000 I hope to be writing-up a draft that will include text that discusses similarities. In terms of operability, one possible approach is placing a KDC behind an OAuth AS, and making the OAuth RS a Kerberized service. All Krb messages would be encoded in GSSAPI token format (base64 encoded), as is done in other specs. This makes all the Krb messages opaque to OAuth. What I then need is some way to indicate in the access_token, refresh_token and client_secret that the contained data is Kerberos data. Would this work? /thomas/ > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Wednesday, May 26, 2010 2:50 PM > To: Thomas Hardjono; Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] multiple access tokens from a single authorizatio= n > flow? >=20 > From what I understand, there is no inherent similarity between the two. = You > *can* wire up your AS and PR to do some verification of that caliber, but > it's not required by the OAuth spec. For cases when the AS and PR are > collapsed into a single system (which is a large percentage of use cases > outside of the Big Internet Companies, from what I gather), then all you = need > to do to prove that the access and refresh token are related is by a look= up > to a local database table. >=20 > -- justin >=20 > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Thomas > Hardjono [hardjono@MIT.EDU] > Sent: Wednesday, May 26, 2010 2:27 PM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] multiple access tokens from a single authorizatio= n > flow? >=20 > I do realize several people on this list should see the parallel :) Sev= eral > folks at the last IETF OAuth meeting also brought-up the similarities. >=20 > One of the aspect unclear to me with OAuth draft-05 is the cryptographic > relationship between the Refresh Token ("8xLOxBtZp8") and the Calendar to= ken > ("SlAV32hkKG") & Contacts token ("SlAV32hkAB"). That is, how can a verif= ying > third party be satisfied that the access came from the same Client/Sessio= n. >=20 > /thomas/ >=20 >=20 >=20 > __________________________________________ >=20 >=20 > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Wednesday, May 26, 2010 2:18 PM > > To: Thomas Hardjono > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] multiple access tokens from a single authorizat= ion > > flow? > > > > I also realized the parallels of refresh tokens and TGTs. That's why I = said > > > > "Are these refresh tokens still long-living or as short-living as a > > Kerberos TGT?" > > > > when discussing Marius's proposal. In my opinion, the main difference > > between TGT and refresh token is the live-time. Refresh tokens may have > > a unlimited validity whereas TGTs as far as I know live for at least 24= h > > (incl. re-newal). > > > > We can use refresh tokens the same way as TGTs but than every flow must > > return a refresh token and, in my opinion, aquisition of access tokens > > (or call it services tickets :-)) should be a second step using the > > refresh request. > > > > At request level, this would look as follows > > > > Obtaining token flow result > > > > HTTP/1.1 200 OK > > Content-Type: application/json > > Cache-Control: no-store > > > > { > > "refresh_token":"8xLOxBtZp8" > > } > > > > Acquiring token for scope "calendar" > > > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > > > type=3Drefresh_token&client_id=3Ds6BhdRkqt3&client_secret=3D8eSEI= pnqmM& > > refresh_token=3D8xLOxBtZp8&scope=3Dcalendar > > > > HTTP/1.1 200 OK > > Content-Type: application/json > > Cache-Control: no-store > > > > { > > "access_token":"SlAV32hkKG", > > "expires_in":3600 > > } > > > > Acquiring token for scope "contacts" > > > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > > > type=3Drefresh_token&client_id=3Ds6BhdRkqt3&client_secret=3D8eSEI= pnqmM& > > refresh_token=3D8xLOxBtZp8&scope=3Dcontacts > > > > HTTP/1.1 200 OK > > Content-Type: application/json > > Cache-Control: no-store > > > > { > > "access_token":"SlAV32hkAB", > > "expires_in":3600 > > } > > > > > > regards, > > Torsten. > > > > > Hi Torsten, > > > > > > Looking at your example below (with the user having > > > to login/consent several times), it seems what is needed > > > is multiple short-term (narrower) tokens that is provably > > > derived from one single (parent) longer-life token. > > > So the human user would need to consent only once > > > to the parent longer-life token, and the client would > > > fetch the multiple shorter-life tokens automatically. > > > The keyword here is "provably" (which may be > > > read as "cryptographically provable"). > > > > > > BTW. Apologies for the history lesson, but > > > this was the same problem with Kerberos when > > > it was first deployed at MIT project Athena in the late 1980s. > > > The solution was to create a separate Ticket-Granting-Ticket (TGT) > > > with the user being prompted for a password only once. > > > Then the Kerberos client would obtain Service Tickets > > > (to access resources) using the TGT. > > > > > > /thomas/ > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf > Of > > >> Torsten Lodderstedt > > >> Sent: Tuesday, May 25, 2010 4:21 PM > > >> To: OAuth WG (oauth@ietf.org) > > >> Subject: Re: [OAUTH-WG] multiple access tokens from a single > authorization > > >> flow? > > >> > > >> ..... > > >> With the current draft, the client has to send the user through the > > >> authz process n-times (n =3D number of services). This would look th= is: > > >> > > >> user accesses client > > >> REDIRECT AS > > >> Login at AS > > >> User Consent service 1 > > >> REDIRECT back > > >> get access token for service 1 > > >> REDIRECT AS > > >> SSO at AS > > >> User Consent service 2 > > >> REDIRECT back > > >> get access token for service 2 > > >> REDIRECT AS > > >> SSO at AS > > >> User Consent service 3 > > >> REDIRECT back > > >> get access token for service 3 > > >> > > >> What a user experience is that? And imagine such a use case for the > > >> device flow :-( > > >> > > >> Do we have other options to perform this process more user-friendly? > > >> > > >> First of all, how does the client request authorization for differen= t > > >> services? As far as I see, the scope parameter is the only way to pa= ss > > >> such information to the authorization server. So instead of mererly > > >> denoting permissions, we can use scopes as kind of service id + > > permissions. > > >> > > >> Which options do we have for returning tokens to the client? > > >> > > >> As proposed by Marius, the authorization server could issue a refres= h > > >> token and the client could use the refresh request in combination wi= th > > >> the downscoping feature in order to acquire access tokens. > > >> Consequences? > > >> In the setup illustrated above, the authorization server cannot crea= te > > >> any access token (or an arbitrary one), it can only return a refresh > > >> token. This would mean to make the access token response parameter > > >> optional. Here I'm colliding with my mental picture of refresh token= s as > > >> long-living and storable tokens. Are these refresh tokens still > > >> long-living or as short-living as a Kerberos TGT? If they are still > > >> long-living, what about the use cases where we don't want to return > > >> refresh tokens? As far as I remember, user agent and username/passwo= rd > > >> flow were candidates. How shall we handle them? > > >> > > >> Coming back to my original proposal: The authorization server could = also > > >> issue multiple access tokens and (optionally) a refresh token - > > >> preserving the refresh token semantics. > > >> > > >> Justin pointed out that my original proposal added complexity to the > > >> simplest use case even if the authorization server does not issue > > >> multiple tokens. I understand your objection and would like to sugge= st a > > >> modified response structure. Instead of putting all access token int= o an > > >> array, the authz server could also use the structure as defined in t= he > > >> current draft and use another list of "additional_access_tokens", if > > >> more than one token has been created. > > >> > > >> HTTP/1.1 200 OK > > >> Content-Type: application/json > > >> Cache-Control: no-store > > >> > > >> { > > >> "access_token":"SlAV32hkAB", > > >> "scopes":"calendar", > > >> "expires_in":3600, > > >> "refresh_token":"8xLOxBtZp8" > > >> additional_access_tokens =3D [{ "token":"SlAV32hkKG", > > >> "scopes":["calendar"], "expires_in":3600}, ...] > > >> } > > >> > > >> So in the simplest case, the response would look the same as before. > > >> > > >> HTTP/1.1 200 OK > > >> Content-Type: application/json > > >> Cache-Control: no-store > > >> > > >> { > > >> "access_token":"SlAV32hkAB", > > >> "scopes":"calendar", > > >> "expires_in":3600, > > >> "refresh_token":"8xLOxBtZp8" > > >> } > > >> > > >> Thoughts? > > >> > > >> regards, > > >> Torsten. > > >> > > >> _______________________________________________ > > >> 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 From dick.hardt@gmail.com Wed May 26 13:44:24 2010 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 E2D263A6A08 for ; Wed, 26 May 2010 13:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 5Gbh9lEzsa5V for ; Wed, 26 May 2010 13:44:23 -0700 (PDT) Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by core3.amsl.com (Postfix) with ESMTP id 4A4A23A69E2 for ; Wed, 26 May 2010 13:44:23 -0700 (PDT) Received: by pzk9 with SMTP id 9so4325872pzk.19 for ; Wed, 26 May 2010 13:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=FiO3AkKt+mN+YwRPqjVAtMBjjiyW9o2Kzdkq59BWN5Y=; b=InY06vcS0KquLE0pRzCRqpPXGmUIKio5TMBqPcPpng2Lc0YDxHoDVHtda7q2TqgzC6 1uuiN7wzk1R1dIiHq1IlXk8nVC0nVh1VlRAcD+hmh8Kv8bqwwzvTZt92aN35bOlYWOBB WJrKXy23j35Btvrazy3dLNSml9zmpl087oeNw= 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=IAlZoUyYmeUiiL3llcas+p4cdrKXzSy9sfFNB8UtyDx+82PRTrK3jtPFH8LVJMPI5i wbuZwZniDkApTxoIbPks2OSRfo6lvZbQ4eSgbQXUAZvKKW3S0qPlM9/Dc5XPQGhk4QPc UuHUsjfzlgFXnVZPG8fJl9H0g+nvapssTmDIQ= MIME-Version: 1.0 Received: by 10.142.202.4 with SMTP id z4mr6235249wff.294.1274906652127; Wed, 26 May 2010 13:44:12 -0700 (PDT) Received: by 10.143.39.21 with HTTP; Wed, 26 May 2010 13:44:12 -0700 (PDT) In-Reply-To: <4BFAA6AB.8040809@lodderstedt.net> References: <4BFAA6AB.8040809@lodderstedt.net> Date: Wed, 26 May 2010 14:44:12 -0600 Message-ID: From: Dick Hardt To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=000e0cd32f781f3234048785561c Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 26 May 2010 20:44:25 -0000 --000e0cd32f781f3234048785561c Content-Type: text/plain; charset=ISO-8859-1 Are you referring to my OpenID v.Next NewSocialService scenario? What issues do you see doing this in v.Next rather than OAuth? Using OpenID allows the client/RP to only discover the user's OP, which knows where the user's calendar / address book is. Having the OP as an intermediary allows it to interact with the user to select which address book or calendar to provide in a particular context cleanly solves the multiple service provider issue -- Dick On Mon, May 24, 2010 at 10:17 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > How many access tokens can be the result of a single OAuth authorization > flow? > > A recent discussion about OpenID Connect on the OpenId mailing list raised > that question and I would like to initiate a discussion on this list. > > Currently, every flow (and the refresh token request) results in a single > access token and (optionally) a single refresh token. I think a single > access token might not be enough when it comes to multiple scopes. > > Let's assume a client wants to access the calendar and contact list of an > end-user. Since access to the corresponding resource servers is managed by > the same authorization server, the resources are distinguished by different > scopes, say "calendar" and "contacts". > > The client sends a request > > GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri= > https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=calendar%20contacts > HTTP/1.1 > Host: oauth.example.com > > and after the authorization flow has been conducted sucessfully, the > client's access token request would be answered as follows. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"SlAV32hkKG", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8" > } > > So the token "SlAV32hkKG" must be good for two different protected > resources, "calendar" and "contacts". > > I think this works if: > 1) the token is a handle that can be swoped for user identity and > authorization data during service request or > 2) it is a self-contained token AND both resources are provided by the same > resource server. > > But what if the authorization server issues self-contained tokens and the > resources are hosted on different, independent resource servers? > > Let's assume the authorization server issues self-contained, signed, and > encrypted bearer tokens. Signature and encryption are based on shared > secrets between authorization server and resource server. In such a > scenario, operational security requires to issue different tokens with > different signature values and to encrypt those tokens with different keys. > Moreover, the resource servers might need different user attributes and > permissions, so even the tokens payload might differ. > > I believe this scenario will become even more important with the advent of > OpenID Connect. With OpenID connect, every client asking for an end-user's > OpenID (+user data) and, additionally, authorization for another resource > will need at least two tokens under the assumptions given above. > > In order to support such scenarios, I would propose to return an array of > access tokens from every authorization flow and the refresh request. An > authorization server should know which resources and scopes are handled by > what resource servers and indicate this relation in the access tokens > response structure. This structure could be as follows. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_tokens":[ > { "token":"SlAV32hkKG", "scopes":["calendar"], "expires_in":3600}, > { "token":"SlAV32hk34", "scopes":["contacts"], "expires_in":7200},], > "refresh_token":"8xLOxBtZp8" > } > > The scopes a particular access token is good for are indicated, so a client > library is able to choose the right tokens for services requests. > Alternatively it might suffice (or be better?) to indicate the sites a token > is valid for (proposal of James Manger). It think there is no need for > multiple refresh tokens because these tokens are handled by the > authorization server only. > > In case all resources are handled by the same resource server, the result > would look like > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_tokens":[{ "token":"SlAV32hkKG", "expires_in":3600},], > "refresh_token":"8xLOxBtZp8" > } > > Thoughts? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd32f781f3234048785561c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are you referring to my OpenID v.Next NewSocialService scenario?

What issues do you see doing this in v.Next rather than OAuth?=A0<= /div>

Using OpenID allows the client/RP to only discover= the user's OP, which knows where the user's calendar / address boo= k is.

Having the OP as an intermediary allows it to interact = with the user to select which address book or calendar to provide in a part= icular context cleanly solves the multiple service provider issue

-- Dick


On Mon, May 24, 2010 at 10:17 AM, Torsten Lodderstedt <torsten@lodderstedt.ne= t> wrote:
How many access tokens can be the result of= a single OAuth authorization flow?

A recent discussion about OpenID Connect on the OpenId mailing list raised = that question and I would like to initiate a discussion on this list.

Currently, every flow (and the refresh token request) results in a single a= ccess token and (optionally) a single refresh token. I think a single acces= s token might not be enough when it comes to multiple scopes.

Let's assume a client wants to access the calendar and contact list of = an end-user. Since access to the corresponding resource servers is managed = by the same authorization server, the resources are distinguished by differ= ent scopes, say "calendar" and "contacts".

The client sends a request

=A0 =A0 GET /authorize?type=3Dweb_server&client_id=3Ds6BhdRkqt3&re= direct_uri=3D
=A0 =A0 =A0 =A0 https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=3Dcale= ndar%20contacts HTTP/1.1
=A0 =A0 Host: oauth= .example.com

and after the authorization flow has been conducted sucessfully, the client= 's access token request would be answered as follows.

=A0 =A0 HTTP/1.1 200 OK
=A0 =A0 Content-Type: application/json
=A0 =A0 Cache-Control: no-store

=A0 =A0 {
=A0 =A0 =A0 "access_token":"SlAV32hkKG",
=A0 =A0 =A0 "expires_in":3600,
=A0 =A0 =A0 "refresh_token":"8xLOxBtZp8"
=A0 =A0 }

So the token "SlAV32hkKG" must be good for two different protecte= d resources, "calendar" and "contacts".

I think this works if:
1) the token is a handle that can be swoped for user identity and authoriza= tion data during service request or
2) it is a self-contained token AND both resources are provided by the same= resource server.

But what if the authorization server issues self-contained tokens and the r= esources are hosted on different, independent resource servers?

Let's assume the authorization server issues self-contained, signed, an= d encrypted bearer tokens. Signature and encryption are based on shared sec= rets between authorization server and resource server. In such a scenario, = operational security requires to issue different tokens with different sign= ature values and to encrypt those tokens with different keys. Moreover, the= resource servers might need different user attributes and permissions, so = even the tokens payload might differ.

I believe this scenario will become even more important with the advent of = OpenID Connect. With OpenID connect, every client asking for an end-user= 9;s OpenID (+user data) and, additionally, authorization for another resour= ce will need at least two tokens under the assumptions given above.

In order to support such scenarios, I would propose to return an array of a= ccess tokens from every authorization flow and the refresh request. An auth= orization server should know which resources and scopes are handled by what= resource servers and indicate this relation in the access tokens response = structure. This structure could be as follows.

=A0 =A0 HTTP/1.1 200 OK
=A0 =A0 Content-Type: application/json
=A0 =A0 Cache-Control: no-store

=A0 =A0 {
=A0 =A0 =A0 "access_tokens":[
=A0 =A0 =A0{ "token":"SlAV32hkKG", "scopes":= ["calendar"], "expires_in":3600},
=A0 =A0 =A0{ "token":"SlAV32hk34", "scopes":= ["contacts"], "expires_in":7200},],
=A0 =A0 =A0 "refresh_token":"8xLOxBtZp8"
=A0 =A0 }

The scopes a particular access token is good for are indicated, so a client= library is able to choose the right tokens for services requests. Alternat= ively it might suffice (or be better?) to indicate the sites a token is val= id for (proposal of James Manger). It think there is no need for multiple r= efresh tokens because these tokens are handled by the authorization server = only.

In case all resources are handled by the same resource server, the result w= ould look like

=A0 =A0 HTTP/1.1 200 OK
=A0 =A0 Content-Type: application/json
=A0 =A0 Cache-Control: no-store

=A0 =A0 {
=A0 =A0 =A0 =A0"access_tokens":[{ "token":"SlAV32= hkKG", "expires_in":3600},],
=A0 =A0 =A0 "refresh_token":"8xLOxBtZp8"
=A0 =A0 }

Thoughts?

regards,
Torsten.

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

--000e0cd32f781f3234048785561c-- From lshepard@facebook.com Wed May 26 14:20:28 2010 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 EA9A43A69E4 for ; Wed, 26 May 2010 14:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 viq5qyud-ZTj for ; Wed, 26 May 2010 14:20:24 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 737063A6A06 for ; Wed, 26 May 2010 14:20:24 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4QLJQVU016592 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 May 2010 14:19:28 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub02.TheFacebook.com (192.168.18.105) with Microsoft SMTP Server (TLS) id 8.2.213.0; Wed, 26 May 2010 14:17:58 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Wed, 26 May 2010 14:17:58 -0700 From: Luke Shepard To: David Recordon Date: Wed, 26 May 2010 14:17:56 -0700 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr9GOl/TaHZnsbiSC2e7+O5vv8vpw== Message-ID: References: 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_C921074CB2F94B078173C55E11F0B987facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-26_04:2010-02-06, 2010-05-26, 2010-05-26 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 21:20:28 -0000 --_000_C921074CB2F94B078173C55E11F0B987facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, when I argued for signatures, the specific use cases we are concerned w= ith: - Mobile handsets and networks that don't support SSL very well - High-volume applications where SSL is a significant cost to both sides - = for Facebook, the top few apps make up a significant amount of API traffic,= so we could do signatures for them and not for everyone else I expect that these are issues that others will encounter as they expand in= to these areas- especially on the mobile side. These are not Facebook-speci= fic issues. That said, I agree with David that we should just figure out what the signa= tures are - I don't really care where they live. If they need to live in a = separate spec then whatever, as long as the specs interoperate very cleanly= . But I would like to hear from other mobile developers if they have tried = OAuth 2.0 with success (Brian, I think you mentioned you may have some data= about that?) On May 26, 2010, at 11:20 AM, David Recordon wrote: How about we figure out the technical details of signatures before figuring= out where they're placed? :) On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz > wrote: Ok - to those advocating a separate spec: What if the separate spec was rea= lly simple (a couple of pages), and we just pasted it as "Section X" into t= he core OAuth spec? To Facebook: What if the core OAuth spec had a section called "Signed OAuth= Requests" that (in its extreme form) had the single sentence: "If PRs requ= ire signing, then Clients use the XYZ mechanism to sign their OAuth request= s" (with a link to XYZ)? Dirk. On Wed, May 26, 2010 at 10:55 AM, David Recordon > wrote: I'd prefer that we keep signatures simple enough that they can remain in th= e core spec. --David On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz > wrote: Repeating what I said before: - separate spec is fine by me - part of the point I'm trying to make is that that spec shouldn't be about= signed _tokens_, but instead about signed _HTTP requests_ (so instead of m= erely proving that you know a secret that came with the token, you prove w= ho you are when you use the token). I'd be interested what the Facebook guys think about this - I believe the c= urrent signature scheme is in there mostly to address a use case they had. Luke, Dave - would a separate signing spec be ok with you guys? Dirk. On Tue, May 25, 2010 at 6:56 PM, Allen Tom > wrote: +1 I fully agree with Dirk and Brian that there needs to be some work on signatures. There are many types of applications that require higher levels of security than what bearer tokens can provide. That being said, I think that bearer token/refresh token model can satisify the majority of use cases - in fact it would satisfy 100% of all public API= s that we have at Yahoo. Perhaps in the interest of keeping the spec focused, it would make more sense to split out a Signed Token Spec, as Justin proposes, that is focused solely on uses cases that require a signature? Allen On 5/21/10 11:27 AM, "Richer, Justin P." > wrote: > I have a slightly more radical proposal. What if we factor out the signed > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, giv= en > the same attention by the group and all that like Eran was talking about > yesterday. What this would take is taking out all reference to signing an= d > making core OAuth just about bare tokens, then have a separate spec that > details what to call your shared secret parameters, how to get them, and = how > to sign with them. This makes the core spec a lot simpler (as detailed be= low) > but makes the overall use case of using signed tokens more complicated to > follow, as it'd be split in two. > > -- justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounce= s@ietf.org] On Behalf Of Dirk > Balfanz [balfanz@google.com] > Sent: Thursday, May 20, 2010 7:39 PM > To: OAuth WG > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away wit= h > base string canonicalization, (2) allow for symmetric and public keys, an= d (3) > allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal b= y > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth = 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it = would > work both with the signing mechanism in the current spec, as well as with > Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easi= er to > implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put togeth= er by > Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from = the > spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then= X, > else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like = this: > > "Servers may require that requests be authenticated by the Client, so tha= t > presentation of the access token alone is not sufficient to access a Prot= ected > Resource. This has several use cases, including, but not limited to, the > following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access t= okens > may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. T= he > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, t= hen > the Client uses the following mechanism to sign their HTTP requests: [...= ]" > > Then, we basically drop the old Section 5.3 here (except we use the clien= t > secret instead of the access token secret). Eventually, instead of Sectio= n > 5.3, we may have Brian's new signature scheme section here, which would a= dd > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieve= d > once we have public-key crypto. > > _______________________________________________ > 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 --_000_C921074CB2F94B078173C55E11F0B987facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So, when I argued for= signatures, the specific use cases we are concerned with:
<= br>
- Mobile handsets and networks that don't support SSL very we= ll
- High-volume applications where SSL is a significant cost to = both sides - for Facebook, the top few apps make up a significant amount of= API traffic, so we could do signatures for them and not for everyone else<= /div>

I expect that these are issues that others will en= counter as they expand into these areas- especially on the mobile side. The= se are not Facebook-specific issues.

That said, I = agree with David that we should just figure out what the signatures are - I= don't really care where they live. If they need to live in a separate spec= then whatever, as long as the specs interoperate very cleanly. But I would= like to hear from other mobile developers if they have tried OAuth 2.0 wit= h success (Brian, I think you mentioned you may have some data about that?)=

On May 26, 2010, at 11:20 AM, David Recordon wrote:
How abo= ut we figure out the technical details of signatures before figuring out wh= ere they're placed? :) </bikeshed>


On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <<= a href=3D"mailto:balfanz@google.com">balfanz@google.com> wrot= e:
Ok - to those advocating a separate spec: W= hat if the separate spec was really simple (a couple of pages), and we just= pasted it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section calle= d "Signed OAuth Requests" that (in its extreme form) had the single sentenc= e: "If PRs require signing, then Clients use the XYZ mechanism to sign thei= r OAuth requests" (with a link to XYZ)?

Dirk.


On Wed, May 26, 2010 at 10:55 AM, Da= vid Recordon <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simple enough that they can remain in th= e core spec.

--David
<= /div>



On Wed, May 26, 2010 = at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

=
- separate spec is fine by me
- part of the point I'm trying= to make is that that spec shouldn't be about signed _tokens_, but instead = about signed _HTTP requests_ (so instead of merely proving that you know a = secret that came with the token, you  prove who you are when you use t= he token). 

I'd be interested what the Facebook guys think about th= is - I believe the current signature scheme is in there mostly to address a= use case they had.

Luke, Dave - would a separate = signing spec be ok with you guys?

Dirk.


<= div class=3D"gmail_quote">On Tue, May 25, 2010 at 6:56 PM, Allen Tom <ato= m@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
>  -- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's proposal = for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.e., = it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:
>
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them just "acce= ss
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_token t= hen X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes something li= ke this:
>
> "Servers may require that requests be authenticated by the Client, so = that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource.  This has several use cases, including, but not limited= to, the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which woul= d add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



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




<ATT00001..txt>
= --_000_C921074CB2F94B078173C55E11F0B987facebookcom_-- From igor.faynberg@alcatel-lucent.com Wed May 26 14:37:07 2010 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 F40A03A6A26 for ; Wed, 26 May 2010 14:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=2.200, 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 86nrYVWTC2vw for ; Wed, 26 May 2010 14:37:05 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 715113A6A24 for ; Wed, 26 May 2010 14:37:05 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o4QLYfe0001190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 May 2010 16:34:41 -0500 (CDT) Received: from [135.244.9.24] (faynberg.lra.lucent.com [135.244.9.24]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o4QLYe76002608; Wed, 26 May 2010 16:34:40 -0500 (CDT) Message-ID: <4BFD93ED.7050009@alcatel-lucent.com> Date: Wed, 26 May 2010 17:34:37 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Luke Shepard References: 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 WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 21:37:07 -0000 But I thought that on the mobile side, TLS must be supported, and there are tons of 3GPP and ITU-T standards that require that. I would like to understand better was is in the way of achieving that. (Luke, I am not challenging your argument, by the way; I just want to understand what prevents the deployment of what I thought were pretty stable technologies). Another question: Can we rely on the mobile phone authentication to establish the keys between the mobile and any relying party? In this case the keys would be distributed by a mobile provider. Igor Luke Shepard wrote: > So, when I argued for signatures, the specific use cases we are > concerned with: > > - Mobile handsets and networks that don't support SSL very well > - High-volume applications where SSL is a significant cost to both > sides - for Facebook, the top few apps make up a significant amount of > API traffic, so we could do signatures for them and not for everyone else > > I expect that these are issues that others will encounter as they > expand into these areas- especially on the mobile side. These are not > Facebook-specific issues. > > That said, I agree with David that we should just figure out what the > signatures are - I don't really care where they live. If they need to > live in a separate spec then whatever, as long as the specs > interoperate very cleanly. But I would like to hear from other mobile > developers if they have tried OAuth 2.0 with success (Brian, I think > you mentioned you may have some data about that?) > > On May 26, 2010, at 11:20 AM, David Recordon wrote: > >> How about we figure out the technical details of signatures before >> figuring out where they're placed? :) >> >> >> On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz > > wrote: >> >> Ok - to those advocating a separate spec: What if the separate >> spec was really simple (a couple of pages), and we just pasted it >> as "Section X" into the core OAuth spec? >> >> To Facebook: What if the core OAuth spec had a section called >> "Signed OAuth Requests" that (in its extreme form) had the single >> sentence: "If PRs require signing, then Clients use the XYZ >> mechanism to sign their OAuth requests" (with a link to XYZ)? >> >> Dirk. >> >> >> On Wed, May 26, 2010 at 10:55 AM, David Recordon >> > wrote: >> >> I'd prefer that we keep signatures simple enough that they >> can remain in the core spec. >> >> --David >> >> >> >> On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz >> > wrote: >> >> Repeating what I said before: >> >> - separate spec is fine by me >> - part of the point I'm trying to make is that that spec >> shouldn't be about signed _tokens_, but instead about >> signed _HTTP requests_ (so instead of merely proving that >> you know a secret that came with the token, you prove >> who you are when you use the token). >> >> I'd be interested what the Facebook guys think about this >> - I believe the current signature scheme is in there >> mostly to address a use case they had. >> >> Luke, Dave - would a separate signing spec be ok with you >> guys? >> >> Dirk. >> >> >> On Tue, May 25, 2010 at 6:56 PM, Allen Tom >> > wrote: >> >> +1 >> >> I fully agree with Dirk and Brian that there needs to >> be some work on >> signatures. There are many types of applications that >> require higher levels >> of security than what bearer tokens can provide. >> >> That being said, I think that bearer token/refresh >> token model can satisify >> the majority of use cases - in fact it would satisfy >> 100% of all public APIs >> that we have at Yahoo. >> >> Perhaps in the interest of keeping the spec focused, >> it would make more >> sense to split out a Signed Token Spec, as Justin >> proposes, that is focused >> solely on uses cases that require a signature? >> >> Allen >> >> >> >> On 5/21/10 11:27 AM, "Richer, Justin P." >> > wrote: >> >> > I have a slightly more radical proposal. What if we >> factor out the signed >> > token use case into a parallel spec? The OAuth 2.0 >> Signed Token spec, given >> > the same attention by the group and all that like >> Eran was talking about >> > yesterday. What this would take is taking out all >> reference to signing and >> > making core OAuth just about bare tokens, then have >> a separate spec that >> > details what to call your shared secret parameters, >> how to get them, and how >> > to sign with them. This makes the core spec a lot >> simpler (as detailed below) >> > but makes the overall use case of using signed >> tokens more complicated to >> > follow, as it'd be split in two. >> > >> > -- justin >> > ________________________________________ >> > From: oauth-bounces@ietf.org >> >> [oauth-bounces@ietf.org >> ] On Behalf Of Dirk >> > Balfanz [balfanz@google.com >> ] >> > Sent: Thursday, May 20, 2010 7:39 PM >> > To: OAuth WG >> > Subject: [OAUTH-WG] proposal for factoring out >> request signing in OAuth 2 >> > >> > Hi guys, >> > >> > at today's interim meeting, we were discussing >> Brian Eaton's proposal for >> > OAuth signatures. He was proposing a mechanism that >> would (1) do away with >> > base string canonicalization, (2) allow for >> symmetric and public keys, and (3) >> > allow for extensibility. >> > >> > He got homework from the group to prove the >> feasibility of his proposal by >> > showing a couple of implementations. >> > >> > In this post, I would like to introduce another >> improvement of the OAuth 2 >> > signing mechanism, one which is orthogonal to >> Brian's proposal (i.e., it would >> > work both with the signing mechanism in the current >> spec, as well as with >> > Brian's signature mechanism). The goal of my >> proposal is twofold: >> > >> > - it simplifies the spec. It will become more >> readable and therefore easier to >> > implement >> > - it separates out the mechanisms for delegated >> authorization and for >> > integrity protection into two independent pieces, >> which can be put together by >> > Servers and/or Clients like LEGO blocks. >> > >> > Summary: >> > >> > - use the client secret instead of the token secret >> for signing PR access >> > requests. >> > >> > Long version of the proposal: >> > >> > - remove all references to access tokens that are >> not bearer tokens from the >> > spec. >> > - stop calling the access tokens "bearer tokens". >> Call them just "access >> > tokens". >> > - remove all references to token secrets from the spec >> > - remove all parts of the spec that are of the kind >> "if bearer_token then X, >> > else Y", and replace them with X. >> > - delete section 5.3 >> > - add a section called "Request Authentication" >> that goes something like this: >> > >> > "Servers may require that requests be authenticated >> by the Client, so that >> > presentation of the access token alone is not >> sufficient to access a Protected >> > Resource. This has several use cases, including, >> but not limited to, the >> > following: >> > >> > - Non-repudiation: high-security deployments may >> require that requests be >> > authenticated (signed) in a non-repudiateable way[1] >> > - Access to protected resources is not protected by >> SSL, so that access tokens >> > may leak. >> > - End-to-end-integrity: even if SSL _is_ used, >> network infrastructure may >> > strip SSL protection before the request reaches the >> protected resource. The >> > protected resource, however, may require end-to-end >> integrity. >> > >> > If the Server requires that the Client authenticate >> PR access requests, then >> > the Client uses the following mechanism to sign >> their HTTP requests: [...]" >> > >> > Then, we basically drop the old Section 5.3 here >> (except we use the client >> > secret instead of the access token secret). >> Eventually, instead of Section >> > 5.3, we may have Brian's new signature scheme >> section here, which would add >> > the option of public-key crypto[1], etc. >> > >> > What do you guys think? >> > >> > Dirk. >> > >> > [1] Technically speaking, the goal of >> non-repudiation can only be achieved >> > once we have public-key crypto. >> > >> > _______________________________________________ >> > 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 beaton@google.com Wed May 26 16:01:57 2010 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 9CD543A6A4F for ; Wed, 26 May 2010 16:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 esuLoxEWJhzP for ; Wed, 26 May 2010 16:01:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5A3BD3A6A4B for ; Wed, 26 May 2010 16:01:56 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o4QN1koF001795 for ; Wed, 26 May 2010 16:01:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274914906; bh=mYX9G6c31fkc3J3HXTXwJqj4NyQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=weuIN9EBEN6ucSjYxi/Vkw+Q3RD3GtTU7bYKCSEMFK6eO7ztN7EE3X8DV8aNKZ9Lh CLsxa+kZf5ElylA4nA1kA== 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=Xm0PTTl7qqMXNE4Kv3FxliYZsXXbUl/srcNoatp65g21MlpoWHn7gsQqE+3zwgcFf yrjRjlro9E83o77ep4hnA== Received: from gyh20 (gyh20.prod.google.com [10.243.50.212]) by hpaq12.eem.corp.google.com with ESMTP id o4QN1SRm027241 for ; Wed, 26 May 2010 16:01:45 -0700 Received: by gyh20 with SMTP id 20so4480394gyh.13 for ; Wed, 26 May 2010 16:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.39.6 with SMTP id m6mr4366765agm.49.1274914904611; Wed, 26 May 2010 16:01:44 -0700 (PDT) Received: by 10.91.214.14 with HTTP; Wed, 26 May 2010 16:01:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 May 2010 16:01:44 -0700 Message-ID: From: Brian Eaton To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 26 May 2010 23:01:57 -0000 On Wed, May 26, 2010 at 2:17 PM, Luke Shepard wrote: > - Mobile handsets and networks that don't support SSL very well We were initially worried about this when we moved GMail to https-only. Mobile app developers were concerned about latency and battery life. Neither proved to be an issue in practice. > - High-volume applications where SSL is a significant cost to both sides - > for Facebook, the top few apps make up a significant amount of API traffic, > so we could do signatures for them and not for everyone else SSL is fairly inexpensive for server-to-server calls. The SSL session is expensive to set-up (it requires an extra TCP round trip and a few ms of CPU), but it's only negotiated once. The session is then reused for long periods of time (hours, or days). HTTP persistent connections are another win. This does not cause any complexity at all on the client-side: SSL and HTTP libraries do the right thing automatically. On the server-side, you need to make sure that your SSL session caches are getting a good cache hit rate. This can be impacted both by capacity and network configuration. Configuration of load balancers matters. SSL hardware accelerators are another possible win on the server-side. They can reduce the CPU load. But the session cache is the most critical component for reducing latency. Terminating SSL at load balancers is another option. That integrates the SSL session cache and the load balancer, which can make deployment simpler. (We now return you to your regularly scheduled program on JSON vs form-encoding...) Cheers, Brian From yarong@microsoft.com Wed May 26 16:12:39 2010 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 A551C3A6A53 for ; Wed, 26 May 2010 16:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 bEpUy6wd3vOc for ; Wed, 26 May 2010 16:12:32 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 616543A6A2C for ; Wed, 26 May 2010 16:12:32 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 26 May 2010 16:12:23 -0700 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.205]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.004; Wed, 26 May 2010 16:12:21 -0700 From: Yaron Goland To: "oauth@ietf.org" Thread-Topic: Questions about sections 3.2/3.3 Thread-Index: Acr4TV5Gu7PqT32USNegznSs4LRTdwE23MZw Date: Wed, 26 May 2010 23:12:20 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C57904620@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C57904620TK5EX14MBXC111r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Questions about sections 3.2/3.3 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, 26 May 2010 23:12:40 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C57904620TK5EX14MBXC111r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since there was no response to this mail may I assume it went to /dev/null? From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Thursday, May 20, 2010 12:20 PM To: oauth@ietf.org Subject: [OAUTH-WG] Questions about sections 3.2/3.3 I was reading through the spec and had some questions about 3.2 and 3.3 tha= t I list below. Thanks, Yaron Section 3.2/3.3 - Handling requests without supported transport layer secur= ity Although optional in section 3.2 and mandatory in section 3.3 both sections= have a similar challenge - what happens if someone makes a request without= the transport layer security required by the endpoint? What HTTP error is = to be returned? 401? 403? A further complication is that both sections explicitly allow for transport= layer security solutions other than TLS/SSL. Doesn't this mean that we nee= d to extend section 6.1's definition of the www-authenticate response heade= r to also specify what transport layer security mechanisms are supported? Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what version of = TLS/SSL? The specification currently states: ...the authorization server MUST require the use of a transport-layer mechanism such as TLS/SSL (or a secure channel with equivalent protections) when sending requests to the token endpoints. To me this text implies that an OAuth server could be conformant and not im= plement TLS/SSL but instead implement some other transport-layer security m= echanism (say a VPN protocol). From an interoperability perspective that se= ems problematic since it means clients can't know what transport-layer solu= tion the token endpoint will support. Wouldn't it be reasonable to put in a= requirement that all OAuth endpoints MUST support RFC 5246 and RFC 5746? In other words the language could read: "...the authorization server MUST r= equire the use of a transport-layer mechanism when sending requests to the = token endpoints. Specifically, authorization servers MUST support version 1= .2 of TLS as defined in RFC 5246 and extended in RFC 5746 and MAY support o= ther equivalent secure channel mechanisms". Section 3.3.1 - What error is returned if clients provide credentials in bo= th the header and the body? Section 3.3.1 explicitly prohibits submitting client credentials using mult= iple schemes but it doesn't define what error to return if this requirement= is violated. Given the requirement in section 3.3.2.2 to include the "erro= r" field wouldn't it be useful to define URIs that map to specific errors d= efined in the specification? For example, "If the client does include multi= ple client credential schemes then, per section 3.3.2.2, a 400 Bad Request = response MUST be sent with an error code of urn:ietf:rfc:X:multiple-client-= credentials". Section 3.3.1 - How exactly are client credentials passed via HTTP Basic au= thentication? Although section 3.3.1 states that HTTP basic authentication is to be suppo= rted, it doesn't specify how. I realize the mapping is pretty obvious but s= tandards are one area where it pays off to be pedantic. Would it be useful = to add language such as?: "The authorization server MUST accept the client credentials using both the= request parameters and the HTTP Basic authentication scheme as defined in = [RFC2617]. When using HTTP Basic the client id MUST be mapped to the HTTP B= asic userid and the client secret MUST be mapped to the HTTP Basic password= . The realm value can either be discovered by sending an unauthenticated re= quest and examining the returned realm value in the www-Authenticate header= or by reading the authorization service's documentation." --_000_7C01E631FF4B654FA1E783F1C0265F8C57904620TK5EX14MBXC111r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since there was no res= ponse to this mail may I assume it went to /dev/null?

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Yaron Goland
Sent: Thursday, May 20, 2010 12:20 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Questions about sections 3.2/3.3

 

I was reading through the spec and had some question= s about 3.2 and 3.3 that I list below.

        &nbs= p;       Thanks,

        &nbs= p;            &= nbsp;          Yaron

Section 3.2/3.3 – Handling requests without supported transport l= ayer security

 

Although optional in section 3.2 and mandatory in se= ction 3.3 both sections have a similar challenge – what happens if so= meone makes a request without the transport layer security required by the = endpoint? What HTTP error is to be returned? 401? 403?

 

A further complication is that both sections explici= tly allow for transport layer security solutions other than TLS/SSL. Doesn&= #8217;t this mean that we need to extend section 6.1’s definition of = the www-authenticate response header to also specify what transport layer security mechanisms are supported?

 

Section 3.3 – Is TLS/SSL mandatory or optional? And if so, what v= ersion of TLS/SSL?

 

The specification currently states:

 

   …the

   authorization server MUST require the us= e of a transport-layer

   mechanism such as TLS/SSL (or a secure c= hannel with equivalent

   protections) when sending requests to th= e token endpoints.

 

To me this text implies that an OAuth server could b= e conformant and not implement TLS/SSL but instead implement some other tra= nsport-layer security mechanism (say a VPN protocol). From an interoperabil= ity perspective that seems problematic since it means clients can’t know what transport-layer solution the = token endpoint will support. Wouldn’t it be reasonable to put in a re= quirement that all OAuth endpoints MUST support RFC 5246 and RFC 5746?

 

In other words the language could read: “̷= 0;the authorization server MUST require the use of a transport-layer mechan= ism when sending requests to the token endpoints. Specifically, authorizati= on servers MUST support version 1.2 of TLS as defined in RFC 5246 and extended in RFC 5746 and MAY support other equival= ent secure channel mechanisms”.  

 

Section 3.3.1 – What error is returned if clients provide credent= ials in both the header and the body?

 

Section 3.3.1 explicitly prohibits submitting client= credentials using multiple schemes but it doesn’t define what error = to return if this requirement is violated. Given the requirement in section= 3.3.2.2 to include the “error” field wouldn’t it be useful to define URIs that map to specific errors defined in the spe= cification? For example, “If the client does include multiple client = credential schemes then, per section 3.3.2.2, a 400 Bad Request response MU= ST be sent with an error code of urn:ietf:rfc:X:multiple-client-credentials= ”.

 

Section 3.3.1 – How exactly are client credentials passed via HTT= P Basic authentication?

 

Although section 3.3.1 states that HTTP basic authen= tication is to be supported, it doesn’t specify how. I realize the ma= pping is pretty obvious but standards are one area where it pays off to be = pedantic. Would it be useful to add language such as?:

 

“The authorization server MUST accept the clie= nt credentials using both the request parameters and the HTTP Basic authent= ication scheme as defined in [RFC2617]. When using HTTP Basic the client id= MUST be mapped to the HTTP Basic userid and the client secret MUST be mapped to the HTTP Basic password. The realm= value can either be discovered by sending an unauthenticated request and e= xamining the returned realm value in the www-Authenticate header or by read= ing the authorization service’s documentation.”

 

--_000_7C01E631FF4B654FA1E783F1C0265F8C57904620TK5EX14MBXC111r_-- From nick@admob.com Wed May 26 16:18:19 2010 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 C67823A6A4F for ; Wed, 26 May 2010 16:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 dCvxnku7+lKq for ; Wed, 26 May 2010 16:18:18 -0700 (PDT) Received: from smtp.admob.com (webmail.admob.com [70.32.159.24]) by core3.amsl.com (Postfix) with ESMTP id BCCC53A690B for ; Wed, 26 May 2010 16:18:18 -0700 (PDT) Received: from [10.50.9.94] (10.50.9.94) by webmail.admob.com (10.50.4.24) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 26 May 2010 16:18:09 -0700 Message-ID: <4BFDAC3F.4080902@admob.com> Date: Wed, 26 May 2010 16:18:23 -0700 From: Nick Snyder User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Stricter End User Endpoint Requirements 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, 26 May 2010 23:18:19 -0000 Hi all, I am fairly new to this mailing list so my apologies if this has already been discussed. Section 3.2 (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.2) The way in which the authorization server authenticates the end user (e.g. username and password login, OpenID, session cookies) and in which the authorization server obtains the end user's authorization, including whether it uses a secure channel such as TLS/SSL, is beyond the scope of this specification. However, the authorization server MUST first verify the identity of the end user. This paragraph seems to imply that it is sufficient to use a session cookie to "verify" the identity of the user. Although the client cannot determine what the session cookie is, it can still take advantage of the fact that the browser will automatically include this cookie in any request to the authorization server. Consider an authorization server that implements the following end user endpoint and we are dealing with the web server flow 1) End user logs in and obtains a session cookie. This step is skipped if the end user already has a valid session cookie. 2) Client information is displayed to end user and the end user is asked to approve or deny the request by submitting a form. 3) End user endpoint verifies the cookie, approves or denies the request, and redirects the user to the redirect_uri If the form submission in step 2 only contains parameters that the client knows or can figure out then all then all a malicious client has to do it is get the end user to click on a link while they are logged in to the service. This link could lead to a webpage controlled by the malicious client where the the malicious client constructs the necessary form and automatically submits that form on page load using javascript. The client would then be redirected to whatever redirect_uri the malicious client specified and the end user would have no idea what just happened. As an illustrative example, assume that Facebook implemented the above end user endpoint. The malicious client could be a Facebook application which gets users to click on its crafted link via Facebook ads (thereby guaranteeing that anyone clicking on the ad is already logged in to Facebook). The end user would click on the ad and have no idea that they just authorized the malicious application to post to their wall. My suggestion would be to add language that defines "verification" as collecting some piece of information that the client could not reasonably know, deduce, or coerce the client into submitting (as is the case of the session cookie). This piece of information could be left undefined in the spec but examples would be 1) Require the user to always re-authenticate (e.g. username & password) before granting authorization 2) Have a CAPTCHA on the form in step 2 of my example Does this make sense? Nick From James.H.Manger@team.telstra.com Wed May 26 17:02:41 2010 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 487B33A6A70 for ; Wed, 26 May 2010 17:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrF1mIB08C7V for ; Wed, 26 May 2010 17:02:40 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id D47313A6A5A for ; Wed, 26 May 2010 17:02:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,307,1272808800"; d="scan'208";a="3750561" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 27 May 2010 10:02:25 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5994"; a="2440633" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 27 May 2010 10:02:27 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 27 May 2010 10:02:27 +1000 From: "Manger, James H" To: Nick Snyder , "oauth@ietf.org" Date: Thu, 27 May 2010 10:02:25 +1000 Thread-Topic: [OAUTH-WG] Stricter End User Endpoint Requirements Thread-Index: Acr9KbiAgeIzlGS/QLOMm7/TbdaX0QAA88UQ Message-ID: <255B9BB34FB7D647A506DC292726F6E11263ABFE80@WSMSG3153V.srv.dir.telstra.com> References: <4BFDAC3F.4080902@admob.com> In-Reply-To: <4BFDAC3F.4080902@admob.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] Stricter End User Endpoint Requirements 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, 27 May 2010 00:02:41 -0000 TmljaywNCllvdSBhcmUgdGFsa2luZyBhYm91dCBjcm9zcy1zaXRlIHJlcXVlc3QgZm9yZ2VyeSAo Q1NSRikgYXR0YWNrcy4NClRoZXNlIG5lZWQgdG8gYmUgbWVudGlvbmVkIGluIHRoZSAoY3VycmVu dGx5IGVtcHR5KSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLiBUaGVyZSBpcyB0ZXh0 IGFib3V0IENTUkYgaW4gdGhlIE9BdXRoIDEuMCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4NClRo ZXJlIGFyZSBiZXR0ZXIgc29sdXRpb25zIHRoYW4gQ0FQVENIQXMgb3IgYWx3YXlzIHJlLWF1dGhl bnRpY2F0aW5nLg0KDQotLSANCkphbWVzIE1hbmdlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOaWNrIFNueWRlcg0KU2VudDogVGh1cnNkYXksIDI3IE1h eSAyMDEwIDk6MTggQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdHXSBT dHJpY3RlciBFbmQgVXNlciBFbmRwb2ludCBSZXF1aXJlbWVudHMNCg0KSGkgYWxsLCBJIGFtIGZh aXJseSBuZXcgdG8gdGhpcyBtYWlsaW5nIGxpc3Qgc28gbXkgYXBvbG9naWVzIGlmIHRoaXMgaGFz IA0KYWxyZWFkeSBiZWVuIGRpc2N1c3NlZC4NCg0KU2VjdGlvbiAzLjIgIA0KKGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMDUjc2VjdGlvbi0zLjIpDQoNClRo ZSB3YXkgaW4gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhl IGVuZCB1c2VyDQooZS5nLiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgbG9naW4sIE9wZW5JRCwgc2Vz c2lvbiBjb29raWVzKSBhbmQgaW4NCndoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBvYnRh aW5zIHRoZSBlbmQgdXNlcidzIGF1dGhvcml6YXRpb24sDQppbmNsdWRpbmcgd2hldGhlciBpdCB1 c2VzIGEgc2VjdXJlIGNoYW5uZWwgc3VjaCBhcyBUTFMvU1NMLCBpcyBiZXlvbmQNCnRoZSBzY29w ZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uICBIb3dldmVyLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXINCk1VU1QgZmlyc3QgdmVyaWZ5IHRoZSBpZGVudGl0eSBvZiB0aGUgZW5kIHVzZXIuDQoNClRo aXMgcGFyYWdyYXBoIHNlZW1zIHRvIGltcGx5IHRoYXQgaXQgaXMgc3VmZmljaWVudCB0byB1c2Ug YSBzZXNzaW9uIA0KY29va2llIHRvICJ2ZXJpZnkiIHRoZSBpZGVudGl0eSBvZiB0aGUgdXNlci4g QWx0aG91Z2ggdGhlIGNsaWVudCBjYW5ub3QgDQpkZXRlcm1pbmUgd2hhdCB0aGUgc2Vzc2lvbiBj b29raWUgaXMsIGl0IGNhbiBzdGlsbCB0YWtlIGFkdmFudGFnZSBvZiB0aGUgDQpmYWN0IHRoYXQg dGhlIGJyb3dzZXIgd2lsbCBhdXRvbWF0aWNhbGx5IGluY2x1ZGUgdGhpcyBjb29raWUgaW4gYW55 IA0KcmVxdWVzdCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQoNCkNvbnNpZGVyIGFuIGF1 dGhvcml6YXRpb24gc2VydmVyIHRoYXQgaW1wbGVtZW50cyB0aGUgZm9sbG93aW5nIGVuZCB1c2Vy IA0KZW5kcG9pbnQgYW5kIHdlIGFyZSBkZWFsaW5nIHdpdGggdGhlIHdlYiBzZXJ2ZXIgZmxvdw0K MSkgRW5kIHVzZXIgbG9ncyBpbiBhbmQgb2J0YWlucyBhIHNlc3Npb24gY29va2llLiBUaGlzIHN0 ZXAgaXMgc2tpcHBlZCANCmlmIHRoZSBlbmQgdXNlciBhbHJlYWR5IGhhcyBhIHZhbGlkIHNlc3Np b24gY29va2llLg0KMikgQ2xpZW50IGluZm9ybWF0aW9uIGlzIGRpc3BsYXllZCB0byBlbmQgdXNl ciBhbmQgdGhlIGVuZCB1c2VyIGlzIGFza2VkIA0KdG8gYXBwcm92ZSBvciBkZW55IHRoZSByZXF1 ZXN0IGJ5IHN1Ym1pdHRpbmcgYSBmb3JtLg0KMykgRW5kIHVzZXIgZW5kcG9pbnQgdmVyaWZpZXMg dGhlIGNvb2tpZSwgYXBwcm92ZXMgb3IgZGVuaWVzIHRoZSANCnJlcXVlc3QsIGFuZCByZWRpcmVj dHMgdGhlIHVzZXIgdG8gdGhlIHJlZGlyZWN0X3VyaQ0KDQpJZiB0aGUgZm9ybSBzdWJtaXNzaW9u IGluIHN0ZXAgMiBvbmx5IGNvbnRhaW5zIHBhcmFtZXRlcnMgdGhhdCB0aGUgDQpjbGllbnQga25v d3Mgb3IgY2FuIGZpZ3VyZSBvdXQgdGhlbiBhbGwgdGhlbiBhbGwgYSBtYWxpY2lvdXMgY2xpZW50 IGhhcyANCnRvIGRvIGl0IGlzIGdldCB0aGUgZW5kIHVzZXIgdG8gY2xpY2sgb24gYSBsaW5rIHdo aWxlIHRoZXkgYXJlIGxvZ2dlZCBpbiANCnRvIHRoZSBzZXJ2aWNlLiBUaGlzIGxpbmsgY291bGQg bGVhZCB0byBhIHdlYnBhZ2UgY29udHJvbGxlZCBieSB0aGUgDQptYWxpY2lvdXMgY2xpZW50IHdo ZXJlIHRoZSB0aGUgbWFsaWNpb3VzIGNsaWVudCBjb25zdHJ1Y3RzIHRoZSBuZWNlc3NhcnkgDQpm b3JtIGFuZCBhdXRvbWF0aWNhbGx5IHN1Ym1pdHMgdGhhdCBmb3JtIG9uIHBhZ2UgbG9hZCB1c2lu ZyBqYXZhc2NyaXB0LiANClRoZSBjbGllbnQgd291bGQgdGhlbiBiZSByZWRpcmVjdGVkIHRvIHdo YXRldmVyIHJlZGlyZWN0X3VyaSB0aGUgDQptYWxpY2lvdXMgY2xpZW50IHNwZWNpZmllZCBhbmQg dGhlIGVuZCB1c2VyIHdvdWxkIGhhdmUgbm8gaWRlYSB3aGF0IGp1c3QgDQpoYXBwZW5lZC4NCg0K QXMgYW4gaWxsdXN0cmF0aXZlIGV4YW1wbGUsIGFzc3VtZSB0aGF0IEZhY2Vib29rIGltcGxlbWVu dGVkIHRoZSBhYm92ZSANCmVuZCB1c2VyIGVuZHBvaW50LiBUaGUgbWFsaWNpb3VzIGNsaWVudCBj b3VsZCBiZSBhIEZhY2Vib29rIGFwcGxpY2F0aW9uIA0Kd2hpY2ggZ2V0cyB1c2VycyB0byBjbGlj ayBvbiBpdHMgY3JhZnRlZCBsaW5rIHZpYSBGYWNlYm9vayBhZHMgKHRoZXJlYnkgDQpndWFyYW50 ZWVpbmcgdGhhdCBhbnlvbmUgY2xpY2tpbmcgb24gdGhlIGFkIGlzIGFscmVhZHkgbG9nZ2VkIGlu IHRvIA0KRmFjZWJvb2spLiBUaGUgZW5kIHVzZXIgd291bGQgY2xpY2sgb24gdGhlIGFkIGFuZCBo YXZlIG5vIGlkZWEgdGhhdCB0aGV5IA0KanVzdCBhdXRob3JpemVkIHRoZSBtYWxpY2lvdXMgYXBw bGljYXRpb24gdG8gcG9zdCB0byB0aGVpciB3YWxsLg0KDQpNeSBzdWdnZXN0aW9uIHdvdWxkIGJl IHRvIGFkZCBsYW5ndWFnZSB0aGF0IGRlZmluZXMgInZlcmlmaWNhdGlvbiIgYXMgDQpjb2xsZWN0 aW5nIHNvbWUgcGllY2Ugb2YgaW5mb3JtYXRpb24gdGhhdCB0aGUgY2xpZW50IGNvdWxkIG5vdCAN CnJlYXNvbmFibHkga25vdywgZGVkdWNlLCBvciBjb2VyY2UgdGhlIGNsaWVudCBpbnRvIHN1Ym1p dHRpbmcgKGFzIGlzIHRoZSANCmNhc2Ugb2YgdGhlIHNlc3Npb24gY29va2llKS4gVGhpcyBwaWVj ZSBvZiBpbmZvcm1hdGlvbiBjb3VsZCBiZSBsZWZ0IA0KdW5kZWZpbmVkIGluIHRoZSBzcGVjIGJ1 dCBleGFtcGxlcyB3b3VsZCBiZQ0KMSkgUmVxdWlyZSB0aGUgdXNlciB0byBhbHdheXMgcmUtYXV0 aGVudGljYXRlIChlLmcuIHVzZXJuYW1lICYgcGFzc3dvcmQpIA0KYmVmb3JlIGdyYW50aW5nIGF1 dGhvcml6YXRpb24NCjIpIEhhdmUgYSBDQVBUQ0hBIG9uIHRoZSBmb3JtIGluIHN0ZXAgMiBvZiBt eSBleGFtcGxlDQoNCkRvZXMgdGhpcyBtYWtlIHNlbnNlPw0KTmljaw0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cg== From atom@yahoo-inc.com Wed May 26 17:39:04 2010 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 7D9B73A6A77 for ; Wed, 26 May 2010 17:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.872 X-Spam-Level: X-Spam-Status: No, score=-13.872 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] 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 1Z83Z-hYKcBq for ; Wed, 26 May 2010 17:38:58 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id A26E83A6851 for ; Wed, 26 May 2010 17:38:58 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4R0cOOU062023; Wed, 26 May 2010 17:38:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type:x-originalarrivaltime; b=s0Al+SHgVJxWNAQNQk9JWE8YXtiRhzFNENJF15NNrc8Is3hFiNL3Vn/+OPW6bCvx Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 May 2010 17:38:24 -0700 Received: from 10.72.181.200 ([10.72.181.200]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 May 2010 00:37:36 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 26 May 2010 17:37:34 -0700 From: Allen Tom To: Thomas Hardjono , "oauth@ietf.org" Message-ID: Thread-Topic: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) Thread-Index: Acr8eXbtpcv6DZ2txkSn7M0JCOEspQAcJ0oQABKuCZ0= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3357740255_41991417" X-OriginalArrivalTime: 27 May 2010 00:38:24.0025 (UTC) FILETIME=[EA0BD090:01CAFD34] Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) 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, 27 May 2010 00:39:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3357740255_41991417 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Thomas, I don=B9t understand why there would be an issue regarding logging and auditing if there=B9s no Request Token, as in Oauth 1.0. An OAuth2 Auth Server can audit that the user approved the request when the user approves the request after the client redirects the browser to the End-User Endpoint (Section 3.2 in Draft 5). In most of the flows, the client the client is required to submit the verification code that the AS sent to the client=B9s redirect_uri in order to get the Access Token to get the user=B9s data. The AS can also audit/log whe= n the access token was returned to the client. I think that Service Providers can log/audit 1. The user=B9s approval of the request 2. The client=B9s request for the Access Token 3. The client=B9s use of the Access Token to fetch a Protected Resource I don=B9t think that the removal of the Oauth 1.0 request token really affect= s logging/auditing =AD perhaps I=B9m missing something? Thanks Allen On 5/26/10 8:45 AM, "Thomas Hardjono" wrote: > Allen, > =20 > If the explicit action of the Client sending a Request Token > is removed, how does OAuth do logging and auditing? > =20 > /thomas/ >=20 > =20 > =20 > __________________________________________ > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Allen Tom > Sent: Tuesday, May 25, 2010 10:17 PM > To: Murali VP; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2= -05) > =20 > Yes =AD one of the design goals for Oauth-WRAP was to eliminate the request > token.=20 >=20 > It is very tricky for SPs to implement the Request Token due to data > replication issues. The Request token could be issued to the client in on= e > data center, and then immediately submitted by the browser to a different= data > center. This means that the data has to be very quickly replicated. >=20 > On the client side of things, if the AS=B9s approval screen is displayed in= a > popup window (like Facebook Connect) - it could be tricky to tricky for t= he > client to pre-fetch the request token before displaying the =B3Connect=B2 but= ton > in order to get around popup blockers. >=20 > Allen >=20 >=20 > On 5/25/10 1:43 PM, "Murali VP" wrote: >=20 > A relatively less important question: >=20 > Since the request token has been eliminated, the web server flow (3.6) > which comes close to the widely adopted OAuth 1.0's 3-legged oauth > flow but without much of a dance isn't backward compatible, is this a > known decision? >=20 --B_3357740255_41991417 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05)= Hi Thomas,

I don’t understand why there would be an issue regarding logging and = auditing if there’s no Request Token, as in Oauth 1.0.

An OAuth2 Auth Server can audit that the user approved the request when the= user approves the request after the client redirects the browser to the End= -User Endpoint (Section 3.2 in Draft 5).

In most of the flows, the client the client is required to submit the verif= ication code that the AS sent to the client’s redirect_uri in order to= get the Access Token to get  the user’s data. The AS can also au= dit/log when the access token was returned to the client.

I think that Service Providers can log/audit

  1. The user’s approval of the request
  2. The client’s request for the Access Token
  3. The client’s use of the Access Token to fetch a Pr= otected Resource

I don’t think that the removal of the Oauth 1.0 request token really = affects logging/auditing – perhaps I’m missing something?

Thanks
Allen



On 5/26/10 8:45 AM, "Thomas Hardjono" <hardjono@mit.edu> wrote:

Allen,
 
If the explicit action of the Client sending a Request Token
is removed, how does OAuth do logging and auditing?
 
/thomas/
 
__________________________________________
 

From: = oauth-bounces@ietf.org [mailto:o= auth-bounces@ietf.org] On Behalf Of Allen Tom
Sent: Tuesday, May 25, 2010 10:17 PM
To: Murali VP; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on dr= aft 2-05)
Yes – one of the design goals for Oauth-WRAP was to el= iminate the request token.

It is very tricky for SPs to implement the Request Token due to data replic= ation issues. The Request token could be issued to the client in one data ce= nter, and then immediately submitted by the browser to a different data cent= er. This means that the data has to be very quickly replicated.

On the client side of things, if the AS’s approval screen is displaye= d in a popup window (like Facebook Connect) - it could be tricky to tricky f= or the client to pre-fetch the request token before displaying the “Co= nnect” button in order to get around popup blockers.

Allen


On 5/25/10 1:43 PM, "Murali VP" <= muralive@gmail.com> wrote:

A relatively less important question:

Since the request token has been eliminated, the web server flow (3.6)
which comes close to the widely adopted OAuth 1.0's 3-legged oauth
flow but without much of a dance isn't backward compatible, is this a
known decision?

--B_3357740255_41991417-- From James.H.Manger@team.telstra.com Wed May 26 19:07:26 2010 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 BD2423A6A72 for ; Wed, 26 May 2010 19:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w59vm4MV-VJc for ; Wed, 26 May 2010 19:07:25 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 0A2103A6A81 for ; Wed, 26 May 2010 19:07:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,308,1272808800"; d="scan'208";a="3301470" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 27 May 2010 12:07:14 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5994"; a="2820851" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcani.tcif.telstra.com.au with ESMTP; 27 May 2010 12:07:14 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 27 May 2010 12:07:14 +1000 From: "Manger, James H" To: Nat Sakimura , oauth Date: Thu, 27 May 2010 12:07:13 +1000 Thread-Topic: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow Thread-Index: Acr823jNUqtiAgFtSz2Km4OzGQmNDQAV7MRg Message-ID: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> References: 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] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 02:07:26 -0000 TmF0LA0KDQpUaGlzIGxvb2tzIGxpa2UgYSBkZWNlbnQgaWRlYTogYWxsb3cgb25lIHVzZXItdXJp IHBhcmFtZXRlciB0byByZWZlcmVuY2UgYSBsYXJnZXIgc2V0IG9mIHVzZXItdXJpIHBhcmFtZXRl cnMgaGVsZCBlbHNld2hlcmUgLS0gdG8gYXZvaWQgVVJJIHNpemUgbGltaXRzLg0KDQpIb3BlZnVs bHkgaXQgY2FuIGJlIHNwZWNpZmllZCBhcyBhbm90aGVyIHVzZXItdXJpIHBhcmFtZXRlciAtLSBu b3QgYXMgYSBzZXBhcmF0ZSBmbG93LiBJdCBjb3VsZCBiZSBoZWxwZnVsIGZvciBhbnkgb2YgdGhl IGRlbGVnYXRpb24gZmxvd3MuDQoNCltJIHRoaW5rIHRoZSBzcGVjIHdvdWxkIGJlIGltcHJvdmVk IHdpdGggYSBkZWRpY2F0ZWQgc2VjdGlvbiBvbiB0aGUgdXNlci11cmkgKEVuZC1Vc2VyIGVuZHBv aW50KSB0aGF0IGxpc3RzIGFsbCB0aGUgcGFyYW1ldGVycyB0aGF0IGl0IGNhbiB0YWtlICh0aGF0 IGFyZSBkZWZpbmVkIGluIHRoZSBzcGVjKSAtLSBhbmQgZXhwbGFpbnMgZWFjaCBwYXJhbWV0ZXIg KHNvbWUgd2lsbCBuZWVkIHRoZWlyIG93biBzdWItc2VjdGlvbikuIFRoZSBwZXItZmxvdyBzZWN0 aW9ucyB3b3VsZCBub3QgcmVwZWF0IGFueSBvZiB0aGF0OiB0aGV5IGNvdWxkIGJlIGEgbG90IG1v cmUgc3VjY2luY3QuXQ0KDQoNClF1aWNrIHN1Z2dlc3Rpb24gZm9yIHRleHQ6DQoNCltmb3Igc2Vj dGlvbiAzLjIgIkVuZC11c2VyIEVuZHBvaW50Il0NCi4uLg0KVGhlIGZvbGxvd2luZyB1c2VyLXVy aSBwYXJhbWV0ZXJzIGFyZSBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbjoNCi4uLg0KICBp bmNfdXJpICAgQSBVUkkgZm9yIG9idGFpbmluZyBmdXJ0aGVyIHBhcmFtZXRlcnMgZm9yIHRoaXMg cmVxdWVzdC4NCg0KLi4uDQo8aW5jX3VyaT4gYWxsb3dzIHBhcmFtZXRlcnMgZm9yIHRoZSB1c2Vy LXVyaSByZXF1ZXN0IHRvIGJlIHJlZmVyZW5jZWQsIGluc3RlYWQgb2YgaW5jbHVkZWQgZGlyZWN0 bHkuIFRoaXMgaXMgcGFydGljdWxhcmx5IGhlbHBmdWwgd2hlbiB0aGUgcGFyYW1ldGVycyBhcmUg bGFyZ2UgYW5kIG1pZ2h0IG5vdCBmaXQgd2l0aGluIHRoZSBVUkkgbGVuZ3RoIGxpbWl0cyBvZiB0 aGUgdXNlcidzIGJyb3dzZXIuIFRoZSByZXNwb25zZSB0byBhIEdFVCByZXF1ZXN0IHRvIDxpbmNf dXJpPiBTSEFMTCBiZSB1c2VyLXVyaSBwYXJhbWV0ZXJzIGluIFhYWCBmb3JtYXQuIEFueSBwYXJh bWV0ZXIgYXBwZWFyaW5nIGRpcmVjdGx5IGluIHRoZSB1c2VyLXVyaSBTSEFMTCBvdmVycmlkZSB0 aGUgc2FtZSBwYXJhbWV0ZXIgb2J0YWluZWQgZnJvbSA8aW5jX3VyaT4uIFRoZSA8aW5jX3VyaT4g cmVzcG9uc2UgU0hPVUxEIGJlIGNhY2hlYWJsZSBieSBpbmNsdWRpbmcgYXBwcm9wcmlhdGUgSFRU UCBjYWNoZS1jb250cm9sIGhlYWRlcnMuIFRoZSA8aW5jX3VyaT4gU0hBTEwgYmUgYW4gSFRUUCBv ciBIVFRQUyBVUkksIGFuZCBTSE9VTEQgYmUgdGhlIGxhdHRlci4NCg0KDQpbUHJvYmFibHkgbmVl ZCBhIHdheSBmb3IgYSBzZXJ2aWNlIHRvIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IGl0IHN1cHBv cnRzIDxpbmNfdXJpPi4gUGVyaGFwcyBhICJmZWF0dXJlcz1pbmNfdXJpLG90aGVyIiBwYXJhbWV0 ZXIgaW4gdGhlIEhUVFAgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIuXQ0KDQotLSANCkphbWVzIE1h bmdlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvYXV0aC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5h dCBTYWtpbXVyYQ0KU2VudDogV2VkbmVzZGF5LCAyNiBNYXkgMjAxMCAxMTo1OCBQTQ0KVG86IG9h dXRoDQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBNb2JpbGUgV2ViQXBwIEZsb3cNCg0K QmFjayBpbiBGZWJydWFyeSwgSSBoYXZlIHN1Z2dlc3RlZCBtb2JpbGUgd2ViIGFwcCBmbG93IHRv IHRoZSBvYXV0aF93cmFwIGdyb3VwLg0KTm93IHRoYXQgaXQgaXMgd3JhcHBlZCBpbnRvIE9BdXRo IDIuMCwgaGVyZSBpcyBteSBhbm90aGVyIHRyeSwgdGhpcw0KdGltZSBmb3IgT0F1dGggMi4wIGRy YWZ0Lg0KDQoiT0F1dGggMi4wIE1vYmlsZSBXZWJBcHAgRmxvdyINCmh0dHA6Ly93d3cuc2FraW11 cmEub3JnL2VuL21vZHVsZXMvd29yZHByZXNzL29hdXRoLTIwLW1vYmlsZS13ZWJhcHAtZmxvdy8N Cg0KSSByZWFsbHkgd2lzaCB0aGF0IHRoaXMgY291bGQgYmUgaW5jbHVkZWQgaW4gT0F1dGggMi4w IGFzIGl0IHdpbGwgaGVscA0KYnVpbGQgaWRlbnRpdHkgbGF5ZXJzIG9uIE9BdXRoIDIuMCB0aGF0 IHdvcmtzIGZvciBtb2JpbGUgd2ViIGJyb3dzZXJzIGV0Yy4NCg0KLS0gDQpOYXQgU2FraW11cmEg KD1uYXQpDQpodHRwOi8vd3d3LnNha2ltdXJhLm9yZy9lbi8NCmh0dHA6Ly90d2l0dGVyLmNvbS9f bmF0X2VuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From recordond@gmail.com Wed May 26 20:38:06 2010 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 A33AA3A63C9 for ; Wed, 26 May 2010 20:38:06 -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 BAqhJ39V168o for ; Wed, 26 May 2010 20:38:05 -0700 (PDT) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by core3.amsl.com (Postfix) with ESMTP id CD9183A67B6 for ; Wed, 26 May 2010 20:38:04 -0700 (PDT) Received: by gxk20 with SMTP id 20so4346660gxk.12 for ; Wed, 26 May 2010 20:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YMvSX+Uo5+iXwf0w93ObqUZiJ/Hh/K5Rab9bG6puI2g=; b=xz06EYmyIurJenp7dlOg7MHQjHyg249jjpl0gkMOqfwA8/T78nvZ9nOoYIGhSicJsg FW+Iais2RTsAqKA8/CupRzgGUcfPuh7nOw6pRTxy1h/fQjjYc298ALqO0Ahlja4SVxU0 IhSt+/qX37cjSWYZB90lV3JmAjgLDDcG3umh4= 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=paF6LLi7kFys+8icLbGneTdhS+zgkV2hL5FX74ifW1Qi+Yrmq0GkK8xJvEser3JqAo Pph8/YFgUaLrDfQwqM+9sYFZkxHhHLgF3/l2xR23DKnBkWK2L8U1PtkwD/Z/lFCj90XE lCOv0X756pyYCXJ1M/cN3bqBs/osbG3tHwQxU= MIME-Version: 1.0 Received: by 10.231.155.3 with SMTP id q3mr962363ibw.20.1274931471930; Wed, 26 May 2010 20:37:51 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Wed, 26 May 2010 20:37:51 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 26 May 2010 21:37:51 -0600 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: multipart/alternative; boundary=00504501423a7f58f504878b1d58 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 03:38:06 -0000 --00504501423a7f58f504878b1d58 Content-Type: text/plain; charset=ISO-8859-1 This feels exactly like the sort of thing that should be a new flow. Nat, thanks for writing it up! I think the next step is getting it into the XML2RFC format and some editing. On Wed, May 26, 2010 at 8:07 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Nat, > > This looks like a decent idea: allow one user-uri parameter to reference a > larger set of user-uri parameters held elsewhere -- to avoid URI size > limits. > > Hopefully it can be specified as another user-uri parameter -- not as a > separate flow. It could be helpful for any of the delegation flows. > > [I think the spec would be improved with a dedicated section on the > user-uri (End-User endpoint) that lists all the parameters that it can take > (that are defined in the spec) -- and explains each parameter (some will > need their own sub-section). The per-flow sections would not repeat any of > that: they could be a lot more succinct.] > > > Quick suggestion for text: > > [for section 3.2 "End-user Endpoint"] > ... > The following user-uri parameters are defined in this specification: > ... > inc_uri A URI for obtaining further parameters for this request. > > ... > allows parameters for the user-uri request to be referenced, > instead of included directly. This is particularly helpful when the > parameters are large and might not fit within the URI length limits of the > user's browser. The response to a GET request to SHALL be user-uri > parameters in XXX format. Any parameter appearing directly in the user-uri > SHALL override the same parameter obtained from . The > response SHOULD be cacheable by including appropriate HTTP cache-control > headers. The SHALL be an HTTP or HTTPS URI, and SHOULD be the > latter. > > > [Probably need a way for a service to indicate whether or not it supports > . Perhaps a "features=inc_uri,other" parameter in the HTTP > WWW-Authenticate header.] > > -- > James Manger > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Nat Sakimura > Sent: Wednesday, 26 May 2010 11:58 PM > To: oauth > Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow > > Back in February, I have suggested mobile web app flow to the oauth_wrap > group. > Now that it is wrapped into OAuth 2.0, here is my another try, this > time for OAuth 2.0 draft. > > "OAuth 2.0 Mobile WebApp Flow" > http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ > > I really wish that this could be included in OAuth 2.0 as it will help > build identity layers on OAuth 2.0 that works for mobile web browsers etc. > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > 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 > --00504501423a7f58f504878b1d58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This feels exactly like the sort of thing that should be a new flow. Nat, t= hanks for writing it up! I think the next step is getting it into the XML2R= FC format and some editing.


On Wed, = May 26, 2010 at 8:07 PM, Manger, James H <James.H.Manger@team.telstra.com&= gt; wrote:
Nat,

This looks like a decent idea: allow one user-uri parameter to reference a = larger set of user-uri parameters held elsewhere -- to avoid URI size limit= s.

Hopefully it can be specified as another user-uri parameter -- not as a sep= arate flow. It could be helpful for any of the delegation flows.

[I think the spec would be improved with a dedicated section on the user-ur= i (End-User endpoint) that lists all the parameters that it can take (that = are defined in the spec) -- and explains each parameter (some will need the= ir own sub-section). The per-flow sections would not repeat any of that: th= ey could be a lot more succinct.]


Quick suggestion for text:

[for section 3.2 "End-user Endpoint"]
...
The following user-uri parameters are defined in this specification:
...
=A0inc_uri =A0 A URI for obtaining further parameters for this request.
...
<inc_uri> allows parameters for the user-uri request to be referenced= , instead of included directly. This is particularly helpful when the param= eters are large and might not fit within the URI length limits of the user&= #39;s browser. The response to a GET request to <inc_uri> SHALL be us= er-uri parameters in XXX format. Any parameter appearing directly in the us= er-uri SHALL override the same parameter obtained from <inc_uri>. The= <inc_uri> response SHOULD be cacheable by including appropriate HTTP= cache-control headers. The <inc_uri> SHALL be an HTTP or HTTPS URI, = and SHOULD be the latter.


[Probably need a way for a service to indicate whether or not it supports &= lt;inc_uri>. Perhaps a "features=3Dinc_uri,other" parameter in= the HTTP WWW-Authenticate header.]

--
James Manger


-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Wednesday, 26 May 2010 11:58 PM
To: oauth
Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow

Back in February, I have suggested mobile web app flow to the oauth_wrap gr= oup.
Now that it is wrapped into OAuth 2.0, here is my another try, this
time for OAuth 2.0 draft.

"OAuth 2.0 Mobile WebApp Flow"
http://www.sakimura.org/en/modules/wordpress/o= auth-20-mobile-webapp-flow/

I really wish that this could be included in OAuth 2.0 as it will help
build identity layers on OAuth 2.0 that works for mobile web browsers etc.<= br>
--
Nat Sakimura (=3Dnat)
http://www.sakimu= ra.org/en/
http://twitter.com= /_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--00504501423a7f58f504878b1d58-- From uidude@google.com Wed May 26 20:52:30 2010 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 79B223A677D for ; Wed, 26 May 2010 20:52:30 -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=[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 Z+2xWN1HVCSN for ; Wed, 26 May 2010 20:52:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 609473A63C9 for ; Wed, 26 May 2010 20:52:29 -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 o4R3qJm6013160 for ; Wed, 26 May 2010 20:52:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274932339; bh=f7HKdoFpukhlkQZ0ZK4AZBjSTE4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WEes49/tY5skaIzqxHLTTnPYTgXFmFITHJYgIufVWCeAfsuuDZKfowrG22cgBQDUf 6VgXRYgjsWV3Ly2b3wLAw== 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=fkGFERWe6/uWecxFEjr7JNHRidxiJO1n4wpqA2L6ufiFzUw63LmXcKjEmdQHPEpmY nZNULl1cwu7onmLehKf7A== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by wpaz9.hot.corp.google.com with ESMTP id o4R3qIRA010411 for ; Wed, 26 May 2010 20:52:19 -0700 Received: by qyk30 with SMTP id 30so10194517qyk.16 for ; Wed, 26 May 2010 20:52:18 -0700 (PDT) Received: by 10.229.230.5 with SMTP id jk5mr2114700qcb.194.1274932337344; Wed, 26 May 2010 20:52:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.215 with HTTP; Wed, 26 May 2010 20:51:57 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Wed, 26 May 2010 20:51:57 -0700 Message-ID: To: Murali VP Content-Type: multipart/alternative; boundary=0016363b8ee41481aa04878b51f8 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) 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, 27 May 2010 03:52:30 -0000 --0016363b8ee41481aa04878b51f8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 25, 2010 at 1:43 PM, Murali VP wrote: > Anyway to find out what the outcome was from the May 20th interim meeting? > I > wanted to participate but had to be at Google I/O. > > 3.5. User-Agent Flow > > 1. Since the client_id is public, the only check that prevents from > any client posing as a registered client is the redirect_uri, this is > fine, except that if client web application has numerous domains, each > domain should register and have a separate client_id which is a pain. > The alternative of a single redirect_uri returning a 302 won't work > since the fragment will no more be available (I guess there are ways > to get around this). > You can have a single redirect_uri that does a client side redirect using JavaScript. The only catch is that this is dangerous from a security perspective - your additional redirect needs to have strict rules about the domains it can forward to - so this should be considered a power-developer technique and we need to write up best practices or better provide a JS library that has gone through review. > > > 2. It is not clear from the draft how a user agent flow would refresh > an access token. As per section 4, client does a HTTP(S) POST to > authorization server which seems to return a 200 to user-agent if the > request was successful leaving the user-agent in authorization > server's domain with a JSON response data! If user-agent flow cannot > refresh access token, why did it send the refresh_token in the first > place in the fragment? > > > 3. The draft doesn't seem to mention how a client in the user-agent > can make protected resource requests given that such requests would be > cross domain. The only viable option seems to be JSONP requests (eg. > Facebook). The specification should include some material describing > protected resource requests in the user-agent flow case. > > > A relatively less important question: > > Since the request token has been eliminated, the web server flow (3.6) > which comes close to the widely adopted OAuth 1.0's 3-legged oauth > flow but without much of a dance isn't backward compatible, is this a > known decision? > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016363b8ee41481aa04878b51f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 25, 2010 at 1:43 PM, Murali = VP <muralive@gma= il.com> wrote:
Anyway to find out what the outcome was from the May 20th interim meeting? = I
wanted to participate but had to be at Google I/O.

3.5. =A0User-Agent Flow

1. Since the client_id is public, the only check that prevents from
any client posing as a registered client is the redirect_uri, this is
fine, except that if client web application has numerous domains, each
domain should register and have a separate client_id which is a pain.
The alternative of a single redirect_uri returning a 302 won't work
since the fragment will no more be available (I guess there are ways
to get around this).

You can have a sin= gle redirect_uri that does a client side redirect using JavaScript. The onl= y catch is that this is dangerous from a security perspective - your additi= onal redirect needs to have strict rules about the domains it can forward t= o - so this should be considered a power-developer technique and we need to= write up best practices or better provide a JS library that has gone throu= gh review.
=A0


2. It is not clear from the draft how a user agent flow would refresh
an access token. As per section 4, client does a HTTP(S) POST to
authorization server which seems to return a 200 to user-agent if the
request was successful leaving the user-agent in authorization
server's domain with a JSON response data! If user-agent flow cannot refresh access token, why did it send the refresh_token in the first
place in the fragment?


3. The draft doesn't seem to mention how a client in the user-agent
can make protected resource requests given that such requests would be
cross domain. The only viable option seems to be JSONP requests (eg.
Facebook). The specification should include some material describing
protected resource requests in the user-agent flow case.


A relatively less important question:

Since the request token has been eliminated, the web server flow (3.6)
which comes close to the widely adopted OAuth 1.0's 3-legged oauth
flow but without much of a dance isn't backward compatible, is this a known decision?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--0016363b8ee41481aa04878b51f8-- From James.H.Manger@team.telstra.com Wed May 26 21:13:54 2010 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 1CBB93A677D for ; Wed, 26 May 2010 21:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hY8DT-KImfNC for ; Wed, 26 May 2010 21:13:53 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 0EA103A67AB for ; Wed, 26 May 2010 21:13:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,308,1272808800"; d="scan'208";a="3397315" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 27 May 2010 14:13:42 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5994"; a="2467711" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccvi.tcif.telstra.com.au with ESMTP; 27 May 2010 14:13:43 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 27 May 2010 14:13:42 +1000 From: "Manger, James H" To: David Recordon Date: Thu, 27 May 2010 14:13:41 +1000 Thread-Topic: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow Thread-Index: Acr9Tf7M7gPeU2jpSdejokfD+t4tDwAACT5Q Message-ID: <255B9BB34FB7D647A506DC292726F6E11263AC05E8@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> 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 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 04:13:54 -0000 RGF2aWQsDQoNCj4gVGhpcyBmZWVscyBleGFjdGx5IGxpa2UgdGhlIHNvcnQgb2YgdGhpbmcgdGhh dCBzaG91bGQgYmUgYSBuZXcgZmxvdy4NCg0KV2h5IGlzIHRoZSBzaXplIG9mIHRoZSBwYXJhbWV0 ZXJzIHJlbGF0ZWQgdG8gdGhlIGZ1bmRhbWVudGFsIGNhcGFiaWxpdGllcyB0aGF0IGRpc3Rpbmd1 aXNoIGZsb3dzIChjYW4vY2FuJ3QgbGF1bmNoIGJyb3dzZXI7IGNhbi9jYW4ndCByZWNlaXZlIHJl ZGlyZWN0czsgY2FuL2Nhbid0IGtlZXAgY2xpZW50IHNlY3JldDsgaXMvaXNuJ3QgcmVnaXN0ZXJl ZDsgd2l0aC93aXRob3V0IGEgdXNlcik/DQoNCkl0cyBub3QgdGhhdCBzb21lIGRldmljZXMgaGF2 ZSBVUkkgbGltaXRzIGFuZCBvdGhlciBkb24ndC4gSXRzIGp1c3QgdGhhdCB0aGUgc2l6ZSBvZiB0 aGUgbGltaXRzIHZhcmllcywgd2hpY2ggbWFrZSB0aGUgaXNzdWUgbW9yZSBwcmVzc2luZyBmb3Ig c2VsZWN0ZWQgbW9iaWxlIHBob25lcyBmaXJzdC4gUGVyaGFwcyB0aGVyZSBpcyBubyBjaGFuY2Ug dGhlIH4yS0IgVVJJIGxpbWl0IGluIElFIHdpbGwgZXZlciBiZSBleGNlZWRlZCAtLSBidXQgdGhp bmdzIGxpa2UgUEFQRSBpbiBPcGVuSUQgc3RyYWluZWQgc2ltaWxhciBhc3N1bXB0aW9ucyB0aGVy ZS4NCg0KSSBndWVzcyBJIGFtIGp1c3QgdW5jb21mb3J0YWJsZSB3aXRoIHRoZSByZXBldGl0aW9u IGJldHdlZW4gdGhlIGZsb3dzLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From recordond@gmail.com Wed May 26 21:23:33 2010 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 8FE0A3A677D for ; Wed, 26 May 2010 21:23:33 -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 S0mAMXatbPwV for ; Wed, 26 May 2010 21:23:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D8ADC3A680F for ; Wed, 26 May 2010 21:23:29 -0700 (PDT) Received: by gyh4 with SMTP id 4so3836423gyh.31 for ; Wed, 26 May 2010 21:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Lm4sC5rLnTZiK8BPP6HYc/EjbUw8ZD+9u8kypR7zWbY=; b=hIT/Rp3DCAn/a573zyX6GNrL/S9uA1WwRkWAKxXX43tV+Qd4Q2sy8+nqZAeoSkHEid bZqjUvKSEtju/IwngdqqX/w84rWID6A4jx59UMmlM4l7O3PCb4oWPmNJh5ABIkKPQ+1p D9IweyUDHaerBunyVPg+sfu+im19ql56bZ66w= 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=UlXyhAD3qQ1j1GNM1s5ppLL6x0SGdC3YXp0QzXNZ8IecFpoGhtnYrimIZOLXIlnTEu GIXgqsJMt9z/BQOsRdNmw4OnWgel46CYnnCne9mX0QlHlaDaPSw/rfMeGOWt+j8pASWv TxpI+Lyl2Oi/+fTvzccj4/+Gp2p8AlbxOLY/U= MIME-Version: 1.0 Received: by 10.231.170.1 with SMTP id b1mr739776ibz.13.1274934197603; Wed, 26 May 2010 21:23:17 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Wed, 26 May 2010 21:23:17 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263AC05E8@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263AC05E8@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 26 May 2010 22:23:17 -0600 Message-ID: From: David Recordon To: "Manger, James H" Content-Type: multipart/alternative; boundary=001636d348baf5cc4b04878bbfb7 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 04:23:33 -0000 --001636d348baf5cc4b04878bbfb7 Content-Type: text/plain; charset=ISO-8859-1 Isn't the capability that distinguishes this flow the fact that URLs can not be more than ~500 bytes? On Wed, May 26, 2010 at 10:13 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > David, > > > This feels exactly like the sort of thing that should be a new flow. > > Why is the size of the parameters related to the fundamental capabilities > that distinguish flows (can/can't launch browser; can/can't receive > redirects; can/can't keep client secret; is/isn't registered; with/without a > user)? > > Its not that some devices have URI limits and other don't. Its just that > the size of the limits varies, which make the issue more pressing for > selected mobile phones first. Perhaps there is no chance the ~2KB URI limit > in IE will ever be exceeded -- but things like PAPE in OpenID strained > similar assumptions there. > > I guess I am just uncomfortable with the repetition between the flows. > > -- > James Manger > --001636d348baf5cc4b04878bbfb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Isn't the capability that distinguishes this flow the fact that URLs ca= n not be more than ~500 bytes?


On We= d, May 26, 2010 at 10:13 PM, Manger, James H <James.H.Manger@team.telstra.com= > wrote:
David,

> This feels exactly like the sort of thing that should be a new flow.
Why is the size of the parameters related to the fundamental capabili= ties that distinguish flows (can/can't launch browser; can/can't re= ceive redirects; can/can't keep client secret; is/isn't registered;= with/without a user)?

Its not that some devices have URI limits and other don't. Its just tha= t the size of the limits varies, which make the issue more pressing for sel= ected mobile phones first. Perhaps there is no chance the ~2KB URI limit in= IE will ever be exceeded -- but things like PAPE in OpenID strained simila= r assumptions there.

I guess I am just uncomfortable with the repetition between the flows.

--
James Manger

--001636d348baf5cc4b04878bbfb7-- From sakimura@gmail.com Wed May 26 21:29:39 2010 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 B8A6E3A67F6 for ; Wed, 26 May 2010 21:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 7HUa1whiDKSq for ; Wed, 26 May 2010 21:29:38 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 55D4B3A677D for ; Wed, 26 May 2010 21:29:38 -0700 (PDT) Received: by gyh4 with SMTP id 4so3839777gyh.31 for ; Wed, 26 May 2010 21:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zatdivf+25MpBue4oQrtyrKeSq8taLM074m4by8aVNE=; b=vzwbevLekTZU9vuELpEvXEzic83Qhf2DW3oeJhMqDQDklwCXuCb5UyzHJx6djRl/1g fh6fH/ZAlSw7CttoV5Q24ptwljmY6TXEGfL9a1ac2oCn3Lv8W9JazQGvX4vpTCPqJAkP L9U81PesAi33lhGbwKdgvZWmNfLh29lK91gmI= 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=cmm9jCYzQcoBqaesjY7hRoPRQugWCXt0vqys6rkRgazVgQO+1P+TuRlJ3oFD9pfMv0 +AqvT35CLJPHuiCHWoQbDf5++Y4yC0t3bTQ7kojAEVsaeF50CUSElHF2p7aPHKHbkgmT tKnipwdJaBN5h1xmcGJOGR4TYshfTrp1+q0ug= MIME-Version: 1.0 Received: by 10.231.178.135 with SMTP id bm7mr326708ibb.73.1274934565250; Wed, 26 May 2010 21:29:25 -0700 (PDT) Received: by 10.231.31.132 with HTTP; Wed, 26 May 2010 21:29:24 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 27 May 2010 13:29:25 +0900 Message-ID: From: Nat Sakimura To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 04:29:39 -0000 I can do the XML2RFC thing as well. Shall I just make a section and upload the section somewhere? =3Dnat On Thu, May 27, 2010 at 12:37 PM, David Recordon wrot= e: > This feels exactly like the sort of thing that should be a new flow. Nat, > thanks for writing it up! I think the next step is getting it into the > XML2RFC format and some editing. > > On Wed, May 26, 2010 at 8:07 PM, Manger, James H > wrote: >> >> Nat, >> >> This looks like a decent idea: allow one user-uri parameter to reference= a >> larger set of user-uri parameters held elsewhere -- to avoid URI size >> limits. >> >> Hopefully it can be specified as another user-uri parameter -- not as a >> separate flow. It could be helpful for any of the delegation flows. >> >> [I think the spec would be improved with a dedicated section on the >> user-uri (End-User endpoint) that lists all the parameters that it can t= ake >> (that are defined in the spec) -- and explains each parameter (some will >> need their own sub-section). The per-flow sections would not repeat any = of >> that: they could be a lot more succinct.] >> >> >> Quick suggestion for text: >> >> [for section 3.2 "End-user Endpoint"] >> ... >> The following user-uri parameters are defined in this specification: >> ... >> =A0inc_uri =A0 A URI for obtaining further parameters for this request. >> >> ... >> allows parameters for the user-uri request to be referenced, >> instead of included directly. This is particularly helpful when the >> parameters are large and might not fit within the URI length limits of t= he >> user's browser. The response to a GET request to SHALL be user= -uri >> parameters in XXX format. Any parameter appearing directly in the user-u= ri >> SHALL override the same parameter obtained from . The >> response SHOULD be cacheable by including appropriate HTTP cache-control >> headers. The SHALL be an HTTP or HTTPS URI, and SHOULD be the >> latter. >> >> >> [Probably need a way for a service to indicate whether or not it support= s >> . Perhaps a "features=3Dinc_uri,other" parameter in the HTTP >> WWW-Authenticate header.] >> >> -- >> James Manger >> >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Nat Sakimura >> Sent: Wednesday, 26 May 2010 11:58 PM >> To: oauth >> Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow >> >> Back in February, I have suggested mobile web app flow to the oauth_wrap >> group. >> Now that it is wrapped into OAuth 2.0, here is my another try, this >> time for OAuth 2.0 draft. >> >> "OAuth 2.0 Mobile WebApp Flow" >> http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow= / >> >> I really wish that this could be included in OAuth 2.0 as it will help >> build identity layers on OAuth 2.0 that works for mobile web browsers et= c. >> >> -- >> Nat Sakimura (=3Dnat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> _______________________________________________ >> 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 > > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From recordond@gmail.com Wed May 26 21:37:33 2010 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 D88203A680F for ; Wed, 26 May 2010 21:37:33 -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 JvYtO7sOyB0h for ; Wed, 26 May 2010 21:37:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DFB7F3A680E for ; Wed, 26 May 2010 21:37:31 -0700 (PDT) Received: by gyh4 with SMTP id 4so3844096gyh.31 for ; Wed, 26 May 2010 21:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=H1ueUnxlMyp+OimFAduYMWfmPShA8C34eb4t8IexVhs=; b=bZUQKdgRGyI7hV4fkJL6BQGTiHaCsEJk/pCMkEi5qaYUnccEAzfWaCgPr+c/B07kGa yQdMyS5VZreWpYTU/1OyjlIzs2EBv0DzvqL0AucEdHVZDnZEUo8E24h/L4DoNAQCy1cT RuQAjhxHcG8Z3g+Syrd8/rkaik9rlH/1cRwsM= 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=Sb2Pka7CY/AOgVmf5T18L6IkOAKUyvF/JH7eQGR+JH7mgF3O7YaBYK9QT/nOob9emx BRwnqvhyuS2YyAsOkq1MA9D8OpsxjpNshJj9X/DT0NQAVHJQQQmur82SxbCEhNLdKFQ5 2ZHBdZw4NXLTKNi+S5hcZijKqkANXRWuRV4s4= MIME-Version: 1.0 Received: by 10.231.184.75 with SMTP id cj11mr10318613ibb.51.1274935039851; Wed, 26 May 2010 21:37:19 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Wed, 26 May 2010 21:37:19 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 26 May 2010 22:37:19 -0600 Message-ID: From: David Recordon To: Nat Sakimura Content-Type: multipart/alternative; boundary=0016367d6dec29825504878bf259 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 04:37:34 -0000 --0016367d6dec29825504878bf259 Content-Type: text/plain; charset=ISO-8859-1 I'd honestly write it as a standalone few page document. We really need to show that flows can be defined outside of the core spec from an extensibility standpoint. On Wed, May 26, 2010 at 10:29 PM, Nat Sakimura wrote: > I can do the XML2RFC thing as well. > > Shall I just make a section and upload the section somewhere? > > =nat > > On Thu, May 27, 2010 at 12:37 PM, David Recordon > wrote: > > This feels exactly like the sort of thing that should be a new flow. Nat, > > thanks for writing it up! I think the next step is getting it into the > > XML2RFC format and some editing. > > > > On Wed, May 26, 2010 at 8:07 PM, Manger, James H > > wrote: > >> > >> Nat, > >> > >> This looks like a decent idea: allow one user-uri parameter to reference > a > >> larger set of user-uri parameters held elsewhere -- to avoid URI size > >> limits. > >> > >> Hopefully it can be specified as another user-uri parameter -- not as a > >> separate flow. It could be helpful for any of the delegation flows. > >> > >> [I think the spec would be improved with a dedicated section on the > >> user-uri (End-User endpoint) that lists all the parameters that it can > take > >> (that are defined in the spec) -- and explains each parameter (some will > >> need their own sub-section). The per-flow sections would not repeat any > of > >> that: they could be a lot more succinct.] > >> > >> > >> Quick suggestion for text: > >> > >> [for section 3.2 "End-user Endpoint"] > >> ... > >> The following user-uri parameters are defined in this specification: > >> ... > >> inc_uri A URI for obtaining further parameters for this request. > >> > >> ... > >> allows parameters for the user-uri request to be referenced, > >> instead of included directly. This is particularly helpful when the > >> parameters are large and might not fit within the URI length limits of > the > >> user's browser. The response to a GET request to SHALL be > user-uri > >> parameters in XXX format. Any parameter appearing directly in the > user-uri > >> SHALL override the same parameter obtained from . The > >> response SHOULD be cacheable by including appropriate HTTP cache-control > >> headers. The SHALL be an HTTP or HTTPS URI, and SHOULD be the > >> latter. > >> > >> > >> [Probably need a way for a service to indicate whether or not it > supports > >> . Perhaps a "features=inc_uri,other" parameter in the HTTP > >> WWW-Authenticate header.] > >> > >> -- > >> James Manger > >> > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of > >> Nat Sakimura > >> Sent: Wednesday, 26 May 2010 11:58 PM > >> To: oauth > >> Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow > >> > >> Back in February, I have suggested mobile web app flow to the oauth_wrap > >> group. > >> Now that it is wrapped into OAuth 2.0, here is my another try, this > >> time for OAuth 2.0 draft. > >> > >> "OAuth 2.0 Mobile WebApp Flow" > >> > http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ > >> > >> I really wish that this could be included in OAuth 2.0 as it will help > >> build identity layers on OAuth 2.0 that works for mobile web browsers > etc. > >> > >> -- > >> Nat Sakimura (=nat) > >> http://www.sakimura.org/en/ > >> http://twitter.com/_nat_en > >> _______________________________________________ > >> 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 > > > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > --0016367d6dec29825504878bf259 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd honestly write it as a standalone few page document. We really need= to show that flows can be defined outside of the core spec from an extensi= bility standpoint.


On Wed, May 26, 2= 010 at 10:29 PM, Nat Sakimura <sakimura@gmail.com> wrote:
I can do the XML2RFC thing as well.

Shall I just make a section and upload the section somewhere?

=3Dnat

On Thu, May 27, 2010 at 12:37 PM, David Recordon <recordond@gmail.com> wrote:
> This feels exactly like the sort of thing that should be a new flow. N= at,
> thanks for writing it up! I think the next step is getting it into the=
> XML2RFC format and some editing.
>
> On Wed, May 26, 2010 at 8:07 PM, Manger, James H
> <James.H.Manger@= team.telstra.com> wrote:
>>
>> Nat,
>>
>> This looks like a decent idea: allow one user-uri parameter to ref= erence a
>> larger set of user-uri parameters held elsewhere -- to avoid URI s= ize
>> limits.
>>
>> Hopefully it can be specified as another user-uri parameter -- not= as a
>> separate flow. It could be helpful for any of the delegation flows= .
>>
>> [I think the spec would be improved with a dedicated section on th= e
>> user-uri (End-User endpoint) that lists all the parameters that it= can take
>> (that are defined in the spec) -- and explains each parameter (som= e will
>> need their own sub-section). The per-flow sections would not repea= t any of
>> that: they could be a lot more succinct.]
>>
>>
>> Quick suggestion for text:
>>
>> [for section 3.2 "End-user Endpoint"]
>> ...
>> The following user-uri parameters are defined in this specificatio= n:
>> ...
>> =A0inc_uri =A0 A URI for obtaining further parameters for this req= uest.
>>
>> ...
>> <inc_uri> allows parameters for the user-uri request to be r= eferenced,
>> instead of included directly. This is particularly helpful when th= e
>> parameters are large and might not fit within the URI length limit= s of the
>> user's browser. The response to a GET request to <inc_uri&g= t; SHALL be user-uri
>> parameters in XXX format. Any parameter appearing directly in the = user-uri
>> SHALL override the same parameter obtained from <inc_uri>. T= he <inc_uri>
>> response SHOULD be cacheable by including appropriate HTTP cache-c= ontrol
>> headers. The <inc_uri> SHALL be an HTTP or HTTPS URI, and SH= OULD be the
>> latter.
>>
>>
>> [Probably need a way for a service to indicate whether or not it s= upports
>> <inc_uri>. Perhaps a "features=3Dinc_uri,other" pa= rameter in the HTTP
>> WWW-Authenticate header.]
>>
>> --
>> James Manger
>>
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ie= tf.org] On Behalf Of
>> Nat Sakimura
>> Sent: Wednesday, 26 May 2010 11:58 PM
>> To: oauth
>> Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow
>>
>> Back in February, I have suggested mobile web app flow to the oaut= h_wrap
>> group.
>> Now that it is wrapped into OAuth 2.0, here is my another try, thi= s
>> time for OAuth 2.0 draft.
>>
>> "OAuth 2.0 Mobile WebApp Flow"
>> http://www.sakimura.org/en/modules/wo= rdpress/oauth-20-mobile-webapp-flow/
>>
>> I really wish that this could be included in OAuth 2.0 as it will = help
>> build identity layers on OAuth 2.0 that works for mobile web brows= ers etc.
>>
>> --
>> Nat Sakimura (=3Dnat)
>> http://w= ww.sakimura.org/en/
>> http://tw= itter.com/_nat_en
>> _______________________________________________
>> 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
>
>



--

--0016367d6dec29825504878bf259-- From recordond@gmail.com Wed May 26 21:37:54 2010 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 69A313A6817 for ; Wed, 26 May 2010 21:37:54 -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 92udv9ugpshf for ; Wed, 26 May 2010 21:37:52 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 903C83A677D for ; Wed, 26 May 2010 21:37:52 -0700 (PDT) Received: by gwj15 with SMTP id 15so2886233gwj.31 for ; Wed, 26 May 2010 21:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VROXJFkOHA6nWZvKREAR5EFiJ4n1c1nuzi1+Ti1+WBU=; b=L8xuQUMapsTuihqO7lIGtFSRiwG4+NZx37vu75fTim93IGeHZ8vBATg5rkxySGwNja UU/uR2LSGLA6Ie34cwmmIdqZ7IV9W0DL/iNgU0XbyRQQM4fX2SjsJS3J7VXfwUlv/Aht 9PoJNoAC4bbvQLy6o4W5yOuCeTonwIujf9MnE= 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=ddr7uTzVtg/+3maiz1oneB2WDvvEuI7wPY6I55xODSZotjvrC5CLwFixV9dcoKXKp+ 84OzPX1t8BK9jGTDjvYIpqymXs4sJUCua/mv9WuVAyciZxMt3k2otQncIXUZGeqEIi/y p4xFpMDBK2p8W/eB9D0vtWY0H/9E8NPui7fDE= MIME-Version: 1.0 Received: by 10.231.184.1 with SMTP id ci1mr1213060ibb.39.1274935063104; Wed, 26 May 2010 21:37:43 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Wed, 26 May 2010 21:37:43 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 26 May 2010 22:37:43 -0600 Message-ID: From: David Recordon To: Nat Sakimura Content-Type: multipart/alternative; boundary=0016367b6f7a8c4da804878bf32b Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 04:37:54 -0000 --0016367b6f7a8c4da804878bf32b Content-Type: text/plain; charset=ISO-8859-1 And have it become one of the official IETF Working Group documents though. On Wed, May 26, 2010 at 10:37 PM, David Recordon wrote: > I'd honestly write it as a standalone few page document. We really need to > show that flows can be defined outside of the core spec from an > extensibility standpoint. > > > On Wed, May 26, 2010 at 10:29 PM, Nat Sakimura wrote: > >> I can do the XML2RFC thing as well. >> >> Shall I just make a section and upload the section somewhere? >> >> =nat >> >> On Thu, May 27, 2010 at 12:37 PM, David Recordon >> wrote: >> > This feels exactly like the sort of thing that should be a new flow. >> Nat, >> > thanks for writing it up! I think the next step is getting it into the >> > XML2RFC format and some editing. >> > >> > On Wed, May 26, 2010 at 8:07 PM, Manger, James H >> > wrote: >> >> >> >> Nat, >> >> >> >> This looks like a decent idea: allow one user-uri parameter to >> reference a >> >> larger set of user-uri parameters held elsewhere -- to avoid URI size >> >> limits. >> >> >> >> Hopefully it can be specified as another user-uri parameter -- not as a >> >> separate flow. It could be helpful for any of the delegation flows. >> >> >> >> [I think the spec would be improved with a dedicated section on the >> >> user-uri (End-User endpoint) that lists all the parameters that it can >> take >> >> (that are defined in the spec) -- and explains each parameter (some >> will >> >> need their own sub-section). The per-flow sections would not repeat any >> of >> >> that: they could be a lot more succinct.] >> >> >> >> >> >> Quick suggestion for text: >> >> >> >> [for section 3.2 "End-user Endpoint"] >> >> ... >> >> The following user-uri parameters are defined in this specification: >> >> ... >> >> inc_uri A URI for obtaining further parameters for this request. >> >> >> >> ... >> >> allows parameters for the user-uri request to be referenced, >> >> instead of included directly. This is particularly helpful when the >> >> parameters are large and might not fit within the URI length limits of >> the >> >> user's browser. The response to a GET request to SHALL be >> user-uri >> >> parameters in XXX format. Any parameter appearing directly in the >> user-uri >> >> SHALL override the same parameter obtained from . The >> >> >> response SHOULD be cacheable by including appropriate HTTP >> cache-control >> >> headers. The SHALL be an HTTP or HTTPS URI, and SHOULD be the >> >> latter. >> >> >> >> >> >> [Probably need a way for a service to indicate whether or not it >> supports >> >> . Perhaps a "features=inc_uri,other" parameter in the HTTP >> >> WWW-Authenticate header.] >> >> >> >> -- >> >> James Manger >> >> >> >> >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of >> >> Nat Sakimura >> >> Sent: Wednesday, 26 May 2010 11:58 PM >> >> To: oauth >> >> Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow >> >> >> >> Back in February, I have suggested mobile web app flow to the >> oauth_wrap >> >> group. >> >> Now that it is wrapped into OAuth 2.0, here is my another try, this >> >> time for OAuth 2.0 draft. >> >> >> >> "OAuth 2.0 Mobile WebApp Flow" >> >> >> http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ >> >> >> >> I really wish that this could be included in OAuth 2.0 as it will help >> >> build identity layers on OAuth 2.0 that works for mobile web browsers >> etc. >> >> >> >> -- >> >> Nat Sakimura (=nat) >> >> http://www.sakimura.org/en/ >> >> http://twitter.com/_nat_en >> >> _______________________________________________ >> >> 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 >> > >> > >> >> >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> > > --0016367b6f7a8c4da804878bf32b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And have it become one of the official IETF Working Group documents though.=


On Wed, May 26, 2010 at 10:37 PM, D= avid Recordon <= recordond@gmail.com> wrote:
I'd honestly write it as a standalone f= ew page document. We really need to show that flows can be defined outside = of the core spec from an extensibility standpoint.


On Wed= , May 26, 2010 at 10:29 PM, Nat Sakimura <sakimura@gmail.com> wrote:
I can do the XML2RFC thing as well.

Shall I just make a section and upload the section somewhere?

=3Dnat

On Thu, May 27, 2010 at 12:37 PM, David Recordon <recordond@gmail.com> wrote:
> This feels exactly like the sort of thing that should be a new flow. N= at,
> thanks for writing it up! I think the next step is getting it into the=
> XML2RFC format and some editing.
>
> On Wed, May 26, 2010 at 8:07 PM, Manger, James H
> <James.H.Manger@team.telstra.com> wrote:
>>
>> Nat,
>>
>> This looks like a decent idea: allow one user-uri parameter to ref= erence a
>> larger set of user-uri parameters held elsewhere -- to avoid URI s= ize
>> limits.
>>
>> Hopefully it can be specified as another user-uri parameter -- not= as a
>> separate flow. It could be helpful for any of the delegation flows= .
>>
>> [I think the spec would be improved with a dedicated section on th= e
>> user-uri (End-User endpoint) that lists all the parameters that it= can take
>> (that are defined in the spec) -- and explains each parameter (som= e will
>> need their own sub-section). The per-flow sections would not repea= t any of
>> that: they could be a lot more succinct.]
>>
>>
>> Quick suggestion for text:
>>
>> [for section 3.2 "End-user Endpoint"]
>> ...
>> The following user-uri parameters are defined in this specificatio= n:
>> ...
>> =A0inc_uri =A0 A URI for obtaining further parameters for this req= uest.
>>
>> ...
>> <inc_uri> allows parameters for the user-uri request to be r= eferenced,
>> instead of included directly. This is particularly helpful when th= e
>> parameters are large and might not fit within the URI length limit= s of the
>> user's browser. The response to a GET request to <inc_uri&g= t; SHALL be user-uri
>> parameters in XXX format. Any parameter appearing directly in the = user-uri
>> SHALL override the same parameter obtained from <inc_uri>. T= he <inc_uri>
>> response SHOULD be cacheable by including appropriate HTTP cache-c= ontrol
>> headers. The <inc_uri> SHALL be an HTTP or HTTPS URI, and SH= OULD be the
>> latter.
>>
>>
>> [Probably need a way for a service to indicate whether or not it s= upports
>> <inc_uri>. Perhaps a "features=3Dinc_uri,other" pa= rameter in the HTTP
>> WWW-Authenticate header.]
>>
>> --
>> James Manger
>>
>>
>> -----Original Message-----
>> From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
>> Nat Sakimura
>> Sent: Wednesday, 26 May 2010 11:58 PM
>> To: oauth
>> Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow
>>
>> Back in February, I have suggested mobile web app flow to the oaut= h_wrap
>> group.
>> Now that it is wrapped into OAuth 2.0, here is my another try, thi= s
>> time for OAuth 2.0 draft.
>>
>> "OAuth 2.0 Mobile WebApp Flow"
>> http://www.sakimura.org/en/modules/wo= rdpress/oauth-20-mobile-webapp-flow/
>>
>> I really wish that this could be included in OAuth 2.0 as it will = help
>> build identity layers on OAuth 2.0 that works for mobile web brows= ers etc.
>>
>> --
>> Nat Sakimura (=3Dnat)
>> http://w= ww.sakimura.org/en/
>> http://tw= itter.com/_nat_en
>> _______________________________________________
>> 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
>
>



--


--0016367b6f7a8c4da804878bf32b-- From sakimura@gmail.com Wed May 26 21:41:33 2010 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 1DE493A6827 for ; Wed, 26 May 2010 21:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11] 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 lIBNMuqWqv62 for ; Wed, 26 May 2010 21:41:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E848C3A6812 for ; Wed, 26 May 2010 21:41:31 -0700 (PDT) Received: by gyh4 with SMTP id 4so3846350gyh.31 for ; Wed, 26 May 2010 21:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cxPqfQyuKkBALJHapV++IKjqD6iV5uXOxMFrbXWSpfQ=; b=PiWbDFSv/bSN/lFwe6+rC3Uc7kpADyoriveKLmSCrd7tpnROOQ4dO4NkNen7c/XVbf r1q6j3hSPO4NzYiLgRx6uppLShKYTe5jRyk65uDAt+vbJiCO+Tq5HFEOXSRQWp/2OzEF RVBF1XwN76WFmP8vu1lOXNH6dV5mdcaHQW+PY= 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=tI4V/Er9AnEjTkPvTZh+EeqcvDNu0NlQLr9wIjfPPlBvGh9T4XreUK0yn2lG5rK4V5 HdzZdvD64uUWAkbnTjcqEtdKH6ndNeup1Gi99K8W1kfzESxdu1qtr8+KEN9euAl09o9J FUnQ3KaoWUzIIAGaszDe3G8Z25T1BfaHg59pk= MIME-Version: 1.0 Received: by 10.231.194.194 with SMTP id dz2mr130306ibb.74.1274935279546; Wed, 26 May 2010 21:41:19 -0700 (PDT) Received: by 10.231.31.132 with HTTP; Wed, 26 May 2010 21:41:19 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263AC05E8@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 27 May 2010 13:41:19 +0900 Message-ID: From: Nat Sakimura To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 04:41:33 -0000 That is the main reason I am pushing forward, but there are other reasons as well. For example, if the device is sitting on a slow network, it would be much faster and thus user friendly if we move bulk of the payload server to server. Another example of the merit is that when something like user identifiers are to be sent to the end_user_endpoint, then it would be much better to do it server to server than through the browser, which is a default man-in-the-middle. Implementation is going to be simpler as well. Since the request travels server to server over SSL, it does not have to be signed to avoid tampering. When these parameters are sent over browser redirect, they can be tampered. To avoid the tampering, you need to sign the request, which is a big headache. =nat On Thu, May 27, 2010 at 1:23 PM, David Recordon wrote: > Isn't the capability that distinguishes this flow the fact that URLs can not > be more than ~500 bytes? > > On Wed, May 26, 2010 at 10:13 PM, Manger, James H > wrote: >> >> David, >> >> > This feels exactly like the sort of thing that should be a new flow. >> >> Why is the size of the parameters related to the fundamental capabilities >> that distinguish flows (can/can't launch browser; can/can't receive >> redirects; can/can't keep client secret; is/isn't registered; with/without a >> user)? >> >> Its not that some devices have URI limits and other don't. Its just that >> the size of the limits varies, which make the issue more pressing for >> selected mobile phones first. Perhaps there is no chance the ~2KB URI limit >> in IE will ever be exceeded -- but things like PAPE in OpenID strained >> similar assumptions there. >> >> I guess I am just uncomfortable with the repetition between the flows. >> >> -- >> James Manger > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From lshepard@facebook.com Wed May 26 22:41:31 2010 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 CDFBD3A680A for ; Wed, 26 May 2010 22:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.315 X-Spam-Level: X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 W1jOhNhfDNTy for ; Wed, 26 May 2010 22:41:30 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id A53C33A67B7 for ; Wed, 26 May 2010 22:41:30 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o4R5eIfn026350 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 May 2010 22:40:36 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub02.TheFacebook.com (192.168.18.105) with Microsoft SMTP Server (TLS) id 8.2.213.0; Wed, 26 May 2010 22:39:55 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Wed, 26 May 2010 22:39:55 -0700 From: Luke Shepard To: Brian Eaton Date: Wed, 26 May 2010 22:39:54 -0700 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr9XwkwrqI+CUAeRGGBgP7azbsRAg== Message-ID: References: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-27_01:2010-02-06, 2010-05-27, 2010-05-26 signatures=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 05:41:32 -0000 On May 26, 2010, at 4:01 PM, Brian Eaton wrote: > On Wed, May 26, 2010 at 2:17 PM, Luke Shepard wro= te: >> - Mobile handsets and networks that don't support SSL very well >=20 > We were initially worried about this when we moved GMail to > https-only. Mobile app developers were concerned about latency and > battery life. Neither proved to be an issue in practice. I agree with you that battery life is likely not a concern, but when I talk= with our mobile team, we have definitely had issues with SSL connections -= and when we switch to HTTP things clear up. I am working to dig into the n= umbers and find out exactly which carriers cause issues but it at least has= been an issue. When you say that it's not a concern, can you explain which= types of applications you're talking about? Does GMail just fail some of t= he time or are there other workarounds you've implemented for the issues? >> - High-volume applications where SSL is a significant cost to both sides= - >> for Facebook, the top few apps make up a significant amount of API traff= ic, >> so we could do signatures for them and not for everyone else >=20 > SSL is fairly inexpensive for server-to-server calls. The SSL session > is expensive to set-up (it requires an extra TCP round trip and a few > ms of CPU), but it's only negotiated once. The session is then reused > for long periods of time (hours, or days). HTTP persistent > connections are another win. I agree that this is ideal. Let me get some more stats on this. >=20 > This does not cause any complexity at all on the client-side: SSL and > HTTP libraries do the right thing automatically. >=20 > On the server-side, you need to make sure that your SSL session caches > are getting a good cache hit rate. This can be impacted both by > capacity and network configuration. Configuration of load balancers > matters. >=20 > SSL hardware accelerators are another possible win on the server-side. > They can reduce the CPU load. But the session cache is the most > critical component for reducing latency. >=20 > Terminating SSL at load balancers is another option. That integrates > the SSL session cache and the load balancer, which can make deployment > simpler. This is how Facebook does it - terminate at the load balancer. I'm worried = more about latency than cost for other developers. Don't get me wrong, I love SSL, I love the simplicity of it, and I hope we = can make it work everywhere. I just want to make sure we address the real i= ssues and don't treat it as a panacea. From sakimura@gmail.com Thu May 27 04:06:57 2010 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 7412A3A68BD for ; Thu, 27 May 2010 04:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 IIO7nWkV9SUb for ; Thu, 27 May 2010 04:06:55 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 60ADC3A69B8 for ; Thu, 27 May 2010 04:06:55 -0700 (PDT) Received: by gwj15 with SMTP id 15so3106458gwj.31 for ; Thu, 27 May 2010 04:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=idwJFbx4u5GlQYY5jfCVA883j5P6NXq2FZttYl68G1s=; b=mK0kC4TJR7TFXBD23Jryqp0Yxmy17saIaL0FEaK8UG08GiYrzAp0T2ezYR/ejPgRVc AzwxId2Cu/cMnxKD6aIkPUw4OLJ2/WP1YhOAP9oyLZ7yVs/iSgttDrwz25Rz0CMSvVu3 08zEn38zXmbUuwD96nma2IUJYfHP8PLHHrEBU= 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=PgULgwjbI3ljDW+81uxhrRot0Cd2obLqz/k0vDzq9AVDp6Q6zieW7gG2nyTF2OvWRM 2beMKqNj66l05qxO3WDVdDX/m4sZmjLrdgHLwD5SAeb5Udj21kzpM6S2Fzh5lZENvfyP WAkaLRjspjQQ0LeYVxhLTe4B6rdcR9SGk0B3w= MIME-Version: 1.0 Received: by 10.231.158.132 with SMTP id f4mr55761ibx.52.1274958403231; Thu, 27 May 2010 04:06:43 -0700 (PDT) Received: by 10.231.31.132 with HTTP; Thu, 27 May 2010 04:06:43 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 27 May 2010 20:06:43 +0900 Message-ID: From: Nat Sakimura To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 11:06:57 -0000 Just in case: I just took the existing oauth-2.0 draft xml and added mobile web app flow. Here is the XML snippet for the flow.
The moble web app flow is a user delegation flow suitable for clients capable of interacting with the end-user’s user-agent (typically a web browser) that are capability constrained especiall= y for url length and capable of receiving incoming requests from the authorization server (capable of acting as an HTTP server). The mobile web app flow includes following steps. The web client creates a request file at a URL “request_url” that captures all the parameters that= it would like to send to the Authorization Server including client identifier and a redirect URI to which the authorization server will send the end-user back once authorization is received (or denied). The web client initiates the flow by redirecting the end-user’s user-agent to the end-user endpoint with request_url. The Authorization server obtains parameters by accessing request_url. The authorization server authenticates the end-user (via the user-agent) and establishes whether the end-user grants or deni= es the client’s access request. Assuming the end-user granted access, the authorization serv= er redirects the user-agent back to the client to the redirection = URI provided earlier. The authorization includes a verification cod= e for the client to use to obtain an access token. The client requests an access token from the authorization server by including its client credentials (identifier and secret), as well as the verification code received in the previ= ous step. The authorization server validates the client credentials an= d the verification code and responds back with the access token.<= /t>
Clients creates and saves the parameters in 3.6.1 at request_u= rl. This file can be used many times, so it does not need to be done every time.
In order for the end-user to grant the client access, the clie= nt sends the end-user to the authorization server. The client constructs the request URI by adding the following URI query parameters to the end-user endpoint URI: REQUIRED. The parameter value= MUST be set to web_server. REQUIRED. Request file= url from which the Authorization Server may obtain the request parameters. OPTIONAL. The parameter = value must be set to true or false. If set to true, the authorization server MUST NO= T prompt the end-user to authenticate or approve access. Instea= d, the authorization server attempts to establish the end-user's identity via other means (e.g. browser cookies) and checks if the end-user has previously approved an identical access requ= est by the same client and if that access grant is still active. = If the authorization server does not support an immediate check = or if it is unable to establish the end-user's identity or appro= val status, it MUST deny the request without prompting the end-us= er. Defaults to false if omitted. The client directs the end-user to the constructed URI using a= n HTTP redirection response, or by other means available to it via = the end- user’s user-agent. The request MUST use the HTTP “GET” method. For example, the client directs the end-user’s user-agent to make the following HTTPS requests (line breaks are for display purposes only):
For example, the client directs the end-user's user-agent to make the following HTTPS requests (line breaks ar= e for display purposes only):
If the client has previously registered a redirection URI with the authorization server, the authorization server MUST verify th= at the redirection URI received matches the registered URI associate= d with the client identifier. The authorization server authenticates the end-user and obtain= s an authorization decision (by asking the end-user or establishing approval via other means). The authorization server sends the end= - user’s user-agent to the provided client redirection URI us= ing an HTTP redirection response, or by other means available to it v= ia the end-user’s user-agent.
Refer to Section 3.6.1.1.
Refer to Section 3.6.1.1.
For example, the authorization server directs the client to make the following HTTP request:
The authorization flow concludes unsuccessfully.
The client obtains an access token from the authorization serv= er by making an HTTP POST request to t= he token endpoint. The client constructs a request URI by adding the following parameters to the request: REQUIRED. The parameter value= MUST be set to web_server. REQUIRED. The client identifier as described in . REQUIRED if the clie= nt identifier has a matching secret. The client secret as descri= bed in . REQUIRED. The verification co= de received from the authorization server. The authorization server MUST verify that the verification cod= e, client identity, client secret, and redirection URI are all valid and match its stored association. If the request is valid, the authorization server issues a successful response as described in . If the request is invalid, the authorization server returns an error response as described in wi= th one of the following error codes: redirect_uri_mismatch bad_verification_code incorrect_client_credentials
For example:
On Thu, May 27, 2010 at 12:37 PM, David Recordon wrot= e: > This feels exactly like the sort of thing that should be a new flow. Nat, > thanks for writing it up! I think the next step is getting it into the > XML2RFC format and some editing. > > On Wed, May 26, 2010 at 8:07 PM, Manger, James H > wrote: >> >> Nat, >> >> This looks like a decent idea: allow one user-uri parameter to reference= a >> larger set of user-uri parameters held elsewhere -- to avoid URI size >> limits. >> >> Hopefully it can be specified as another user-uri parameter -- not as a >> separate flow. It could be helpful for any of the delegation flows. >> >> [I think the spec would be improved with a dedicated section on the >> user-uri (End-User endpoint) that lists all the parameters that it can t= ake >> (that are defined in the spec) -- and explains each parameter (some will >> need their own sub-section). The per-flow sections would not repeat any = of >> that: they could be a lot more succinct.] >> >> >> Quick suggestion for text: >> >> [for section 3.2 "End-user Endpoint"] >> ... >> The following user-uri parameters are defined in this specification: >> ... >> =A0inc_uri =A0 A URI for obtaining further parameters for this request. >> >> ... >> allows parameters for the user-uri request to be referenced, >> instead of included directly. This is particularly helpful when the >> parameters are large and might not fit within the URI length limits of t= he >> user's browser. The response to a GET request to SHALL be user= -uri >> parameters in XXX format. Any parameter appearing directly in the user-u= ri >> SHALL override the same parameter obtained from . The >> response SHOULD be cacheable by including appropriate HTTP cache-control >> headers. The SHALL be an HTTP or HTTPS URI, and SHOULD be the >> latter. >> >> >> [Probably need a way for a service to indicate whether or not it support= s >> . Perhaps a "features=3Dinc_uri,other" parameter in the HTTP >> WWW-Authenticate header.] >> >> -- >> James Manger >> >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Nat Sakimura >> Sent: Wednesday, 26 May 2010 11:58 PM >> To: oauth >> Subject: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow >> >> Back in February, I have suggested mobile web app flow to the oauth_wrap >> group. >> Now that it is wrapped into OAuth 2.0, here is my another try, this >> time for OAuth 2.0 draft. >> >> "OAuth 2.0 Mobile WebApp Flow" >> http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow= / >> >> I really wish that this could be included in OAuth 2.0 as it will help >> build identity layers on OAuth 2.0 that works for mobile web browsers et= c. >> >> -- >> Nat Sakimura (=3Dnat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> _______________________________________________ >> 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 > > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From beaton@google.com Thu May 27 07:14:46 2010 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 D4ED33A6ADE for ; Thu, 27 May 2010 07:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.677 X-Spam-Level: X-Spam-Status: No, score=-104.677 tagged_above=-999 required=5 tests=[AWL=1.300, 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 zbX3GcxuZK5g for ; Thu, 27 May 2010 07:14:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2617F3A6943 for ; Thu, 27 May 2010 07:14:42 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o4REEWqh001704 for ; Thu, 27 May 2010 07:14:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274969672; bh=xIwHjPYwu3PubmgeJfesqw953tM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kg14tLOggQ9motZqh3puhyubBOIp7aNF2EbUqThFmeApOmiF+iOb7UxV3RAF0CXIp zPh6Mwo5LKrA3dPc/jv6A== 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=IDTmlQaG5eDtIqUd9RLvsFcjw32sAuaWerN/Bz6GZFRvU9Pv8o62WPK+mCGGW7cxg 7Ob7OmhTdLg354lsF9IVA== Received: from pzk8 (pzk8.prod.google.com [10.243.19.136]) by wpaz21.hot.corp.google.com with ESMTP id o4REEUkg021924 for ; Thu, 27 May 2010 07:14:31 -0700 Received: by pzk8 with SMTP id 8so14998pzk.12 for ; Thu, 27 May 2010 07:14:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.207.15 with SMTP id e15mr3115168wfg.14.1274969670405; Thu, 27 May 2010 07:14:30 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Thu, 27 May 2010 07:14:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 May 2010 07:14:30 -0700 Message-ID: From: Brian Eaton To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 14:14:46 -0000 On Wed, May 26, 2010 at 10:39 PM, Luke Shepard wrote: > I agree with you that battery life is likely not a concern, but when I talk with our > mobile team, we have definitely had issues with SSL connections - and when > we switch to HTTP things clear up. I am working to dig into the numbers and > find out exactly which carriers cause issues but it at least has been an issue. > When you say that it's not a concern, can you explain which types of > applications you're talking about? Does GMail just fail some of the time or > are there other workarounds you've implemented for the issues? Interesting. We moved both our mobile installed apps and our mobile gmail web interface to encrypted connections without running into this. Keep me posted on what you find. From balfanz@google.com Thu May 27 08:41:47 2010 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 19A5D3A6AEE for ; Thu, 27 May 2010 08:41:47 -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=[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 8JtTnD3EcGBA for ; Thu, 27 May 2010 08:41:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3F2FF3A6960 for ; Thu, 27 May 2010 08:41:44 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o4RFfSNx015838 for ; Thu, 27 May 2010 08:41:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274974889; bh=NO57oyIAPfrhPINto6ylHccoSvk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=S1ozFZMJZX2X58kv9qPSLXvtwONOuSckZXw6nt5MJFJzqBobMovWnRsY/GO2wclF2 FJN13WslGpJDuDMp9O3YQ== 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=Hg0SFOuq0zkvi6oyAI4ozk3FI8gGczkkYMLhE3cWT73zkiSwWaaYw0HocpeeAtfez K1kXyBFaO0jMgvH4kNhfg== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by hpaq12.eem.corp.google.com with ESMTP id o4RFf30g019347 for ; Thu, 27 May 2010 08:41:26 -0700 Received: by gwb11 with SMTP id 11so45841gwb.18 for ; Thu, 27 May 2010 08:41:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.167.144 with SMTP id q16mr1657549iby.34.1274974886274; Thu, 27 May 2010 08:41:26 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Thu, 27 May 2010 08:41:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 May 2010 08:41:25 -0700 Message-ID: From: Dirk Balfanz To: Luke Shepard Content-Type: multipart/alternative; boundary=0050450142e831a7f204879539a3 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 15:41:47 -0000 --0050450142e831a7f204879539a3 Content-Type: text/plain; charset=ISO-8859-1 Sorry, I didn't mean to turn this into a debate over whether we should have signatures. I think you guys stated your case clearly, and there are other use cases as well. The questions I was trying to figure out was whether - you'd be ok using the client secret to sign instead of the token secret (I think I heard David say that that was ok), - you'd be ok with a signature scheme that's sufficiently factored out of the rest of the spec that it might warrant it's own companion spec (I agree that this is getting close to bikeshed territory, so let's worry about this once we know what the signatures look like). Dirk. On Wed, May 26, 2010 at 2:17 PM, Luke Shepard wrote: > So, when I argued for signatures, the specific use cases we are concerned > with: > > - Mobile handsets and networks that don't support SSL very well > - High-volume applications where SSL is a significant cost to both sides - > for Facebook, the top few apps make up a significant amount of API traffic, > so we could do signatures for them and not for everyone else > > I expect that these are issues that others will encounter as they expand > into these areas- especially on the mobile side. These are not > Facebook-specific issues. > > That said, I agree with David that we should just figure out what the > signatures are - I don't really care where they live. If they need to live > in a separate spec then whatever, as long as the specs interoperate very > cleanly. But I would like to hear from other mobile developers if they have > tried OAuth 2.0 with success (Brian, I think you mentioned you may have some > data about that?) > > On May 26, 2010, at 11:20 AM, David Recordon wrote: > > How about we figure out the technical details of signatures before figuring > out where they're placed? :) > > > On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz wrote: > >> Ok - to those advocating a separate spec: What if the separate spec was >> really simple (a couple of pages), and we just pasted it as "Section X" into >> the core OAuth spec? >> >> To Facebook: What if the core OAuth spec had a section called "Signed >> OAuth Requests" that (in its extreme form) had the single sentence: "If PRs >> require signing, then Clients use the XYZ mechanism to sign their OAuth >> requests" (with a link to XYZ)? >> >> Dirk. >> >> >> On Wed, May 26, 2010 at 10:55 AM, David Recordon wrote: >> >>> I'd prefer that we keep signatures simple enough that they can remain in >>> the core spec. >>> >>> --David >>> >>> >>> >>> On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote: >>> >>>> Repeating what I said before: >>>> >>>> - separate spec is fine by me >>>> - part of the point I'm trying to make is that that spec shouldn't be >>>> about signed _tokens_, but instead about signed _HTTP requests_ (so instead >>>> of merely proving that you know a secret that came with the token, you >>>> prove who you are when you use the token). >>>> >>>> I'd be interested what the Facebook guys think about this - I believe >>>> the current signature scheme is in there mostly to address a use case they >>>> had. >>>> >>>> Luke, Dave - would a separate signing spec be ok with you guys? >>>> >>>> Dirk. >>>> >>>> >>>> On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: >>>> >>>>> +1 >>>>> >>>>> I fully agree with Dirk and Brian that there needs to be some work on >>>>> signatures. There are many types of applications that require higher >>>>> levels >>>>> of security than what bearer tokens can provide. >>>>> >>>>> That being said, I think that bearer token/refresh token model can >>>>> satisify >>>>> the majority of use cases - in fact it would satisfy 100% of all public >>>>> APIs >>>>> that we have at Yahoo. >>>>> >>>>> Perhaps in the interest of keeping the spec focused, it would make more >>>>> sense to split out a Signed Token Spec, as Justin proposes, that is >>>>> focused >>>>> solely on uses cases that require a signature? >>>>> >>>>> Allen >>>>> >>>>> >>>>> >>>>> On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >>>>> >>>>> > I have a slightly more radical proposal. What if we factor out the >>>>> signed >>>>> > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, >>>>> given >>>>> > the same attention by the group and all that like Eran was talking >>>>> about >>>>> > yesterday. What this would take is taking out all reference to >>>>> signing and >>>>> > making core OAuth just about bare tokens, then have a separate spec >>>>> that >>>>> > details what to call your shared secret parameters, how to get them, >>>>> and how >>>>> > to sign with them. This makes the core spec a lot simpler (as >>>>> detailed below) >>>>> > but makes the overall use case of using signed tokens more >>>>> complicated to >>>>> > follow, as it'd be split in two. >>>>> > >>>>> > -- justin >>>>> > ________________________________________ >>>>> > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of >>>>> Dirk >>>>> > Balfanz [balfanz@google.com] >>>>> > Sent: Thursday, May 20, 2010 7:39 PM >>>>> > To: OAuth WG >>>>> > Subject: [OAUTH-WG] proposal for factoring out request signing in >>>>> OAuth 2 >>>>> > >>>>> > Hi guys, >>>>> > >>>>> > at today's interim meeting, we were discussing Brian Eaton's proposal >>>>> for >>>>> > OAuth signatures. He was proposing a mechanism that would (1) do away >>>>> with >>>>> > base string canonicalization, (2) allow for symmetric and public >>>>> keys, and (3) >>>>> > allow for extensibility. >>>>> > >>>>> > He got homework from the group to prove the feasibility of his >>>>> proposal by >>>>> > showing a couple of implementations. >>>>> > >>>>> > In this post, I would like to introduce another improvement of the >>>>> OAuth 2 >>>>> > signing mechanism, one which is orthogonal to Brian's proposal (i.e., >>>>> it would >>>>> > work both with the signing mechanism in the current spec, as well as >>>>> with >>>>> > Brian's signature mechanism). The goal of my proposal is twofold: >>>>> > >>>>> > - it simplifies the spec. It will become more readable and therefore >>>>> easier to >>>>> > implement >>>>> > - it separates out the mechanisms for delegated authorization and for >>>>> > integrity protection into two independent pieces, which can be put >>>>> together by >>>>> > Servers and/or Clients like LEGO blocks. >>>>> > >>>>> > Summary: >>>>> > >>>>> > - use the client secret instead of the token secret for signing PR >>>>> access >>>>> > requests. >>>>> > >>>>> > Long version of the proposal: >>>>> > >>>>> > - remove all references to access tokens that are not bearer tokens >>>>> from the >>>>> > spec. >>>>> > - stop calling the access tokens "bearer tokens". Call them just >>>>> "access >>>>> > tokens". >>>>> > - remove all references to token secrets from the spec >>>>> > - remove all parts of the spec that are of the kind "if bearer_token >>>>> then X, >>>>> > else Y", and replace them with X. >>>>> > - delete section 5.3 >>>>> > - add a section called "Request Authentication" that goes something >>>>> like this: >>>>> > >>>>> > "Servers may require that requests be authenticated by the Client, so >>>>> that >>>>> > presentation of the access token alone is not sufficient to access a >>>>> Protected >>>>> > Resource. This has several use cases, including, but not limited to, >>>>> the >>>>> > following: >>>>> > >>>>> > - Non-repudiation: high-security deployments may require that >>>>> requests be >>>>> > authenticated (signed) in a non-repudiateable way[1] >>>>> > - Access to protected resources is not protected by SSL, so that >>>>> access tokens >>>>> > may leak. >>>>> > - End-to-end-integrity: even if SSL _is_ used, network infrastructure >>>>> may >>>>> > strip SSL protection before the request reaches the protected >>>>> resource. The >>>>> > protected resource, however, may require end-to-end integrity. >>>>> > >>>>> > If the Server requires that the Client authenticate PR access >>>>> requests, then >>>>> > the Client uses the following mechanism to sign their HTTP requests: >>>>> [...]" >>>>> > >>>>> > Then, we basically drop the old Section 5.3 here (except we use the >>>>> client >>>>> > secret instead of the access token secret). Eventually, instead of >>>>> Section >>>>> > 5.3, we may have Brian's new signature scheme section here, which >>>>> would add >>>>> > the option of public-key crypto[1], etc. >>>>> > >>>>> > What do you guys think? >>>>> > >>>>> > Dirk. >>>>> > >>>>> > [1] Technically speaking, the goal of non-repudiation can only be >>>>> achieved >>>>> > once we have public-key crypto. >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>> >>>> >>> >> > > > > --0050450142e831a7f204879539a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, I didn't mean to turn this into a debate over whether we should = have signatures. I think you guys stated your case clearly, and there are o= ther use cases as well.=A0

The questions I was trying to= figure out was whether=A0

- you'd be ok using the client secret to sign inste= ad of the token secret (I think I heard David say that that was ok),=A0
- you'd be ok with a signature scheme that's sufficiently fa= ctored out of the rest of the spec that it might warrant it's own compa= nion spec (I agree that this is getting close to bikeshed territory, so let= 's worry about this once we know what the signatures look like).

Dirk.

On Wed, May 26,= 2010 at 2:17 PM, Luke Shepard <lshepard@facebook.com> wrote:
So, when I argued for signatures, = the specific=A0use cases we are concerned with:

- = Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - = for Facebook, the top few apps make up a significant amount of API traffic,= so we could do signatures for them and not for everyone else

I expect that these are issues that others will encounter as= they expand into these areas- especially on the mobile side. These are not= Facebook-specific issues.

That said, I agree with= David that we should just figure out what the signatures are - I don't= really care where they live. If they need to live in a separate spec then = whatever, as long as the specs interoperate very cleanly. But I would like = to hear from other mobile developers if they have tried OAuth 2.0 with succ= ess (Brian, I think you mentioned you may have some data about that?)

On May 26, 2010, at 11:20 A= M, David Recordon wrote:

How about we figure out the technical detail= s of signatures before figuring out where they're placed? :) </bikes= hed>


On Wed, May 26, 2010 at 12:15 PM, Dirk B= alfanz <balfanz@google.com> wrote:
Ok - to those advocating a separate spec: Wh= at if the separate spec was really simple (a couple of pages), and we just = pasted it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section calle= d "Signed OAuth Requests" that (in its extreme form) had the sing= le sentence: "If PRs require signing, then Clients use the XYZ mechani= sm to sign their OAuth requests" (with a link to XYZ)?

Dirk.


<= div class=3D"gmail_quote">On Wed, May 26, 2010 at 10:55 AM, David Recordon = <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simple enough that they can remain i= n the core spec.

--David



On Wed, May 26, 2= 010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

=
- separate spec is fine by me
- part of the point I'm tr= ying to make is that that spec shouldn't be about signed _tokens_, but = instead about signed _HTTP requests_ (so instead of merely proving that you= know a secret that came with the token, you =A0prove who you are when you = use the token).=A0

I'd be interested what the Facebook guys think abou= t this - I believe the current signature scheme is in there mostly to addre= ss a use case they had.

Luke, Dave - would a separ= ate signing spec be ok with you guys?

Dirk.


<= div class=3D"gmail_quote">On Tue, May 25, 2010 at 6:56 PM, Allen Tom <ato= m@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to= , the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which = would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



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




<ATT00001..txt>
=
--0050450142e831a7f204879539a3-- From recordond@gmail.com Thu May 27 08:56:39 2010 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 B182B3A6B18 for ; Thu, 27 May 2010 08:56:39 -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 DwVaLWBu0vxT for ; Thu, 27 May 2010 08:56:37 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A94723A6359 for ; Thu, 27 May 2010 08:56:37 -0700 (PDT) Received: by pwi8 with SMTP id 8so87097pwi.31 for ; Thu, 27 May 2010 08:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lq5DhmTgGUa/9xE1j9czJRzi4g78G55yT+89qf4iFwU=; b=mcPbW0fqOKxeyJx2T/deJKgiqwWqVltOxdbjYx1d81HJ3CV8U/04y3WmE5/QZA4r9h 7qUNLezSGQKdJmHFZqAZjzYSYKdlmn8ak82yknQl1s9n/rSEdgoSsjfW8ZyxqCqJVJrM gfCm0bFjWEcz5V61Pg5Cevfp4iW8D2QCfOXkM= 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=JlGes3SSD/e8/RXaQJY+Qni1J2IzDy0pjHf1DAhBVfD+psulG+sI/le53AnIVgiOzd 7RhPFo8Zs631kRVzRZMwbyY2/Rs4kSJ8CVNEdDpxakha0KOiR+/do20CRFix4CR0D5Qq FrVm0L1R6Cuo1xfbb4T0zINnoezT/HVsEoeKE= MIME-Version: 1.0 Received: by 10.141.108.10 with SMTP id k10mr8117768rvm.113.1274975783606; Thu, 27 May 2010 08:56:23 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Thu, 27 May 2010 08:56:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 May 2010 09:56:21 -0600 Message-ID: From: David Recordon To: Dirk Balfanz Content-Type: multipart/alternative; boundary=000e0cd137f8b165100487956e05 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 15:56:39 -0000 --000e0cd137f8b165100487956e05 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I thought Allen clearly said that signing with the client secret won't work for Yahoo!? Hi Dirk- > We at Yahoo would be very much against using the client secret for signin= g > requests to Protected Resources, since this would require that the client > secret be distributed to the PR endpoints. For security reasons, one of t= he > design goals for WRAP was to keep the client secret a secret between only > the AS and the Client =96 deliberately separating the authentication of t= he > client (on the AS) from the serving of the protected resource. > From your post, it=92s not quite clear what the disadvantage is with usin= g > the Access Token secret for generating signatures. > (forgive me if this was already discussed today - I was very zonked out > after 3 days of IIW) > Thanks Allen On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz wrote: > Sorry, I didn't mean to turn this into a debate over whether we should ha= ve > signatures. I think you guys stated your case clearly, and there are othe= r > use cases as well. > > The questions I was trying to figure out was whether > > - you'd be ok using the client secret to sign instead of the token secret > (I think I heard David say that that was ok), > - you'd be ok with a signature scheme that's sufficiently factored out of > the rest of the spec that it might warrant it's own companion spec (I agr= ee > that this is getting close to bikeshed territory, so let's worry about th= is > once we know what the signatures look like). > > Dirk. > > > On Wed, May 26, 2010 at 2:17 PM, Luke Shepard wrot= e: > >> So, when I argued for signatures, the specific use cases we are concerne= d >> with: >> >> - Mobile handsets and networks that don't support SSL very well >> - High-volume applications where SSL is a significant cost to both sides= - >> for Facebook, the top few apps make up a significant amount of API traff= ic, >> so we could do signatures for them and not for everyone else >> >> I expect that these are issues that others will encounter as they expand >> into these areas- especially on the mobile side. These are not >> Facebook-specific issues. >> >> That said, I agree with David that we should just figure out what the >> signatures are - I don't really care where they live. If they need to li= ve >> in a separate spec then whatever, as long as the specs interoperate very >> cleanly. But I would like to hear from other mobile developers if they h= ave >> tried OAuth 2.0 with success (Brian, I think you mentioned you may have = some >> data about that?) >> >> On May 26, 2010, at 11:20 AM, David Recordon wrote: >> >> How about we figure out the technical details of signatures before >> figuring out where they're placed? :) >> >> >> On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz wrote= : >> >>> Ok - to those advocating a separate spec: What if the separate spec was >>> really simple (a couple of pages), and we just pasted it as "Section X"= into >>> the core OAuth spec? >>> >>> To Facebook: What if the core OAuth spec had a section called "Signed >>> OAuth Requests" that (in its extreme form) had the single sentence: "If= PRs >>> require signing, then Clients use the XYZ mechanism to sign their OAuth >>> requests" (with a link to XYZ)? >>> >>> Dirk. >>> >>> >>> On Wed, May 26, 2010 at 10:55 AM, David Recordon w= rote: >>> >>>> I'd prefer that we keep signatures simple enough that they can remain = in >>>> the core spec. >>>> >>>> --David >>>> >>>> >>>> >>>> On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wro= te: >>>> >>>>> Repeating what I said before: >>>>> >>>>> - separate spec is fine by me >>>>> - part of the point I'm trying to make is that that spec shouldn't be >>>>> about signed _tokens_, but instead about signed _HTTP requests_ (so i= nstead >>>>> of merely proving that you know a secret that came with the token, yo= u >>>>> prove who you are when you use the token). >>>>> >>>>> I'd be interested what the Facebook guys think about this - I believe >>>>> the current signature scheme is in there mostly to address a use case= they >>>>> had. >>>>> >>>>> Luke, Dave - would a separate signing spec be ok with you guys? >>>>> >>>>> Dirk. >>>>> >>>>> >>>>> On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote= : >>>>> >>>>>> +1 >>>>>> >>>>>> I fully agree with Dirk and Brian that there needs to be some work o= n >>>>>> signatures. There are many types of applications that require higher >>>>>> levels >>>>>> of security than what bearer tokens can provide. >>>>>> >>>>>> That being said, I think that bearer token/refresh token model can >>>>>> satisify >>>>>> the majority of use cases - in fact it would satisfy 100% of all >>>>>> public APIs >>>>>> that we have at Yahoo. >>>>>> >>>>>> Perhaps in the interest of keeping the spec focused, it would make >>>>>> more >>>>>> sense to split out a Signed Token Spec, as Justin proposes, that is >>>>>> focused >>>>>> solely on uses cases that require a signature? >>>>>> >>>>>> Allen >>>>>> >>>>>> >>>>>> >>>>>> On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >>>>>> >>>>>> > I have a slightly more radical proposal. What if we factor out the >>>>>> signed >>>>>> > token use case into a parallel spec? The OAuth 2.0 Signed Token >>>>>> spec, given >>>>>> > the same attention by the group and all that like Eran was talking >>>>>> about >>>>>> > yesterday. What this would take is taking out all reference to >>>>>> signing and >>>>>> > making core OAuth just about bare tokens, then have a separate spe= c >>>>>> that >>>>>> > details what to call your shared secret parameters, how to get the= m, >>>>>> and how >>>>>> > to sign with them. This makes the core spec a lot simpler (as >>>>>> detailed below) >>>>>> > but makes the overall use case of using signed tokens more >>>>>> complicated to >>>>>> > follow, as it'd be split in two. >>>>>> > >>>>>> > -- justin >>>>>> > ________________________________________ >>>>>> > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of >>>>>> Dirk >>>>>> > Balfanz [balfanz@google.com] >>>>>> > Sent: Thursday, May 20, 2010 7:39 PM >>>>>> > To: OAuth WG >>>>>> > Subject: [OAUTH-WG] proposal for factoring out request signing in >>>>>> OAuth 2 >>>>>> > >>>>>> > Hi guys, >>>>>> > >>>>>> > at today's interim meeting, we were discussing Brian Eaton's >>>>>> proposal for >>>>>> > OAuth signatures. He was proposing a mechanism that would (1) do >>>>>> away with >>>>>> > base string canonicalization, (2) allow for symmetric and public >>>>>> keys, and (3) >>>>>> > allow for extensibility. >>>>>> > >>>>>> > He got homework from the group to prove the feasibility of his >>>>>> proposal by >>>>>> > showing a couple of implementations. >>>>>> > >>>>>> > In this post, I would like to introduce another improvement of the >>>>>> OAuth 2 >>>>>> > signing mechanism, one which is orthogonal to Brian's proposal >>>>>> (i.e., it would >>>>>> > work both with the signing mechanism in the current spec, as well = as >>>>>> with >>>>>> > Brian's signature mechanism). The goal of my proposal is twofold: >>>>>> > >>>>>> > - it simplifies the spec. It will become more readable and therefo= re >>>>>> easier to >>>>>> > implement >>>>>> > - it separates out the mechanisms for delegated authorization and >>>>>> for >>>>>> > integrity protection into two independent pieces, which can be put >>>>>> together by >>>>>> > Servers and/or Clients like LEGO blocks. >>>>>> > >>>>>> > Summary: >>>>>> > >>>>>> > - use the client secret instead of the token secret for signing PR >>>>>> access >>>>>> > requests. >>>>>> > >>>>>> > Long version of the proposal: >>>>>> > >>>>>> > - remove all references to access tokens that are not bearer token= s >>>>>> from the >>>>>> > spec. >>>>>> > - stop calling the access tokens "bearer tokens". Call them just >>>>>> "access >>>>>> > tokens". >>>>>> > - remove all references to token secrets from the spec >>>>>> > - remove all parts of the spec that are of the kind "if bearer_tok= en >>>>>> then X, >>>>>> > else Y", and replace them with X. >>>>>> > - delete section 5.3 >>>>>> > - add a section called "Request Authentication" that goes somethin= g >>>>>> like this: >>>>>> > >>>>>> > "Servers may require that requests be authenticated by the Client, >>>>>> so that >>>>>> > presentation of the access token alone is not sufficient to access= a >>>>>> Protected >>>>>> > Resource. This has several use cases, including, but not limited >>>>>> to, the >>>>>> > following: >>>>>> > >>>>>> > - Non-repudiation: high-security deployments may require that >>>>>> requests be >>>>>> > authenticated (signed) in a non-repudiateable way[1] >>>>>> > - Access to protected resources is not protected by SSL, so that >>>>>> access tokens >>>>>> > may leak. >>>>>> > - End-to-end-integrity: even if SSL _is_ used, network >>>>>> infrastructure may >>>>>> > strip SSL protection before the request reaches the protected >>>>>> resource. The >>>>>> > protected resource, however, may require end-to-end integrity. >>>>>> > >>>>>> > If the Server requires that the Client authenticate PR access >>>>>> requests, then >>>>>> > the Client uses the following mechanism to sign their HTTP request= s: >>>>>> [...]" >>>>>> > >>>>>> > Then, we basically drop the old Section 5.3 here (except we use th= e >>>>>> client >>>>>> > secret instead of the access token secret). Eventually, instead of >>>>>> Section >>>>>> > 5.3, we may have Brian's new signature scheme section here, which >>>>>> would add >>>>>> > the option of public-key crypto[1], etc. >>>>>> > >>>>>> > What do you guys think? >>>>>> > >>>>>> > Dirk. >>>>>> > >>>>>> > [1] Technically speaking, the goal of non-repudiation can only be >>>>>> achieved >>>>>> > once we have public-key crypto. >>>>>> > >>>>>> > _______________________________________________ >>>>>> > 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 >>>>> >>>>> >>>> >>> >> >> >> >> > --000e0cd137f8b165100487956e05 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I thought Allen clearly said that signing with the client secret won't = work for Yahoo!?

Hi Dirk-

We at Yahoo would be very much against using the client secret for signing = requests to Protected Resources, since this would require that the client s= ecret be distributed to the PR endpoints. For security reasons, one of the = design goals for WRAP was to keep the client secret a secret between only t= he AS and the Client =96 deliberately separating the authentication of the = client (on the AS) from the serving of the protected resource.=A0

>From your post, it=92s not quite clear what the disadvantage is with using = the Access Token secret for generating signatures.

(forgive me if this was already discussed today - I was very zonked out aft= er 3 days of IIW)

Thanks
Allen


On Thu, May= 27, 2010 at 9:41 AM, Dirk Balfanz <balfanz@google.com> wrote:
Sorry, I didn't mean to turn this into a debate over whether we should = have signatures. I think you guys stated your case clearly, and there are o= ther use cases as well.=A0

The questions I was trying to= figure out was whether=A0

- you'd be ok using the client secret to sign inste= ad of the token secret (I think I heard David say that that was ok),=A0
- you'd be ok with a signature scheme that's sufficiently fa= ctored out of the rest of the spec that it might warrant it's own compa= nion spec (I agree that this is getting close to bikeshed territory, so let= 's worry about this once we know what the signatures look like).

Dirk.


On Wed, May 26, 2010 at 2= :17 PM, Luke Shepard <lshepard@facebook.com> wrote:
So, when I argued for signatures, = the specific=A0use cases we are concerned with:

- = Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - = for Facebook, the top few apps make up a significant amount of API traffic,= so we could do signatures for them and not for everyone else

I expect that these are issues that others will encounter as= they expand into these areas- especially on the mobile side. These are not= Facebook-specific issues.

That said, I agree with= David that we should just figure out what the signatures are - I don't= really care where they live. If they need to live in a separate spec then = whatever, as long as the specs interoperate very cleanly. But I would like = to hear from other mobile developers if they have tried OAuth 2.0 with succ= ess (Brian, I think you mentioned you may have some data about that?)

On May 26, 2010, at 11:20 AM, David Reco= rdon wrote:

=
How about we figure out the technical details of signatures before fig= uring out where they're placed? :) </bikeshed>


On Wed, May 26, 2010 at 12:15 PM, Dirk B= alfanz <balfanz@google.com> wrote:
Ok - to those advocating a separate spec: Wh= at if the separate spec was really simple (a couple of pages), and we just = pasted it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section calle= d "Signed OAuth Requests" that (in its extreme form) had the sing= le sentence: "If PRs require signing, then Clients use the XYZ mechani= sm to sign their OAuth requests" (with a link to XYZ)?

Dirk.


<= div class=3D"gmail_quote">On Wed, May 26, 2010 at 10:55 AM, David Recordon = <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simple enough that they can remain i= n the core spec.

--David



On Wed, May 26, 2= 010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

=
- separate spec is fine by me
- part of the point I'm tr= ying to make is that that spec shouldn't be about signed _tokens_, but = instead about signed _HTTP requests_ (so instead of merely proving that you= know a secret that came with the token, you =A0prove who you are when you = use the token).=A0

I'd be interested what the Facebook guys think abou= t this - I believe the current signature scheme is in there mostly to addre= ss a use case they had.

Luke, Dave - would a separ= ate signing spec be ok with you guys?

Dirk.


<= div class=3D"gmail_quote">On Tue, May 25, 2010 at 6:56 PM, Allen Tom <ato= m@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to= , the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which = would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



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




<ATT00001..txt>
=

--000e0cd137f8b165100487956e05-- From balfanz@google.com Thu May 27 09:05:10 2010 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 A8C663A6359 for ; Thu, 27 May 2010 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 YkvNZCLMJk55 for ; Thu, 27 May 2010 09:05:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id DA48D3A6B27 for ; Thu, 27 May 2010 09:05:07 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o4RG4sQt027829 for ; Thu, 27 May 2010 09:04:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274976295; bh=Xsv46anNTpH4O2eZKaYBIUq4Tus=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qsQLp3CQaVXzltgtCHpMLLsASfU1ic3r4e5e8lX7jFT1Yxk3OHSe4GIsodtESqVXq Rg4NClpZVkWn6//2Muyww== 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=yhjyBXKFx17mSbuqwhns6uslkkTy+ZXYDp2lY3BPCb9cW5Ac/wOOD4wtkewpsxR48 TGo0TD+ne7+hQBrkvqK+A== Received: from gyh3 (gyh3.prod.google.com [10.243.50.195]) by wpaz24.hot.corp.google.com with ESMTP id o4RG4rrF005631 for ; Thu, 27 May 2010 09:04:53 -0700 Received: by gyh3 with SMTP id 3so106913gyh.23 for ; Thu, 27 May 2010 09:04:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.185.6 with SMTP id cm6mr1119047ibb.72.1274976293241; Thu, 27 May 2010 09:04:53 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Thu, 27 May 2010 09:04:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 May 2010 09:04:53 -0700 Message-ID: From: Dirk Balfanz To: David Recordon Content-Type: multipart/alternative; boundary=0050450171ee0e42d20487958d32 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 16:05:10 -0000 --0050450171ee0e42d20487958d32 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, May 27, 2010 at 8:56 AM, David Recordon wrote= : > I thought Allen clearly said that signing with the client secret won't wo= rk > for Yahoo!? Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures a= t all. So I think we're good from the Yahoo! side of things. Allen - did I get this right? Dirk. > > Hi Dirk- > > >> We at Yahoo would be very much against using the client secret for signi= ng >> requests to Protected Resources, since this would require that the clien= t >> secret be distributed to the PR endpoints. For security reasons, one of = the >> design goals for WRAP was to keep the client secret a secret between onl= y >> the AS and the Client =96 deliberately separating the authentication of = the >> client (on the AS) from the serving of the protected resource. > > >> From your post, it=92s not quite clear what the disadvantage is with usi= ng >> the Access Token secret for generating signatures. > > >> (forgive me if this was already discussed today - I was very zonked out >> after 3 days of IIW) > > >> Thanks > > Allen > > > > On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz wrote: > >> Sorry, I didn't mean to turn this into a debate over whether we should >> have signatures. I think you guys stated your case clearly, and there ar= e >> other use cases as well. >> >> The questions I was trying to figure out was whether >> >> - you'd be ok using the client secret to sign instead of the token secre= t >> (I think I heard David say that that was ok), >> - you'd be ok with a signature scheme that's sufficiently factored out o= f >> the rest of the spec that it might warrant it's own companion spec (I ag= ree >> that this is getting close to bikeshed territory, so let's worry about t= his >> once we know what the signatures look like). >> >> Dirk. >> >> >> On Wed, May 26, 2010 at 2:17 PM, Luke Shepard wro= te: >> >>> So, when I argued for signatures, the specific use cases we are concern= ed >>> with: >>> >>> - Mobile handsets and networks that don't support SSL very well >>> - High-volume applications where SSL is a significant cost to both side= s >>> - for Facebook, the top few apps make up a significant amount of API >>> traffic, so we could do signatures for them and not for everyone else >>> >>> I expect that these are issues that others will encounter as they expan= d >>> into these areas- especially on the mobile side. These are not >>> Facebook-specific issues. >>> >>> That said, I agree with David that we should just figure out what the >>> signatures are - I don't really care where they live. If they need to l= ive >>> in a separate spec then whatever, as long as the specs interoperate ver= y >>> cleanly. But I would like to hear from other mobile developers if they = have >>> tried OAuth 2.0 with success (Brian, I think you mentioned you may have= some >>> data about that?) >>> >>> On May 26, 2010, at 11:20 AM, David Recordon wrote: >>> >>> How about we figure out the technical details of signatures before >>> figuring out where they're placed? :) >>> >>> >>> On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz wrot= e: >>> >>>> Ok - to those advocating a separate spec: What if the separate spec wa= s >>>> really simple (a couple of pages), and we just pasted it as "Section X= " into >>>> the core OAuth spec? >>>> >>>> To Facebook: What if the core OAuth spec had a section called "Signed >>>> OAuth Requests" that (in its extreme form) had the single sentence: "I= f PRs >>>> require signing, then Clients use the XYZ mechanism to sign their OAut= h >>>> requests" (with a link to XYZ)? >>>> >>>> Dirk. >>>> >>>> >>>> On Wed, May 26, 2010 at 10:55 AM, David Recordon = wrote: >>>> >>>>> I'd prefer that we keep signatures simple enough that they can remain >>>>> in the core spec. >>>>> >>>>> --David >>>>> >>>>> >>>>> >>>>> On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wr= ote: >>>>> >>>>>> Repeating what I said before: >>>>>> >>>>>> - separate spec is fine by me >>>>>> - part of the point I'm trying to make is that that spec shouldn't b= e >>>>>> about signed _tokens_, but instead about signed _HTTP requests_ (so = instead >>>>>> of merely proving that you know a secret that came with the token, y= ou >>>>>> prove who you are when you use the token). >>>>>> >>>>>> I'd be interested what the Facebook guys think about this - I believ= e >>>>>> the current signature scheme is in there mostly to address a use cas= e they >>>>>> had. >>>>>> >>>>>> Luke, Dave - would a separate signing spec be ok with you guys? >>>>>> >>>>>> Dirk. >>>>>> >>>>>> >>>>>> On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote= : >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> I fully agree with Dirk and Brian that there needs to be some work = on >>>>>>> signatures. There are many types of applications that require highe= r >>>>>>> levels >>>>>>> of security than what bearer tokens can provide. >>>>>>> >>>>>>> That being said, I think that bearer token/refresh token model can >>>>>>> satisify >>>>>>> the majority of use cases - in fact it would satisfy 100% of all >>>>>>> public APIs >>>>>>> that we have at Yahoo. >>>>>>> >>>>>>> Perhaps in the interest of keeping the spec focused, it would make >>>>>>> more >>>>>>> sense to split out a Signed Token Spec, as Justin proposes, that is >>>>>>> focused >>>>>>> solely on uses cases that require a signature? >>>>>>> >>>>>>> Allen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >>>>>>> >>>>>>> > I have a slightly more radical proposal. What if we factor out th= e >>>>>>> signed >>>>>>> > token use case into a parallel spec? The OAuth 2.0 Signed Token >>>>>>> spec, given >>>>>>> > the same attention by the group and all that like Eran was talkin= g >>>>>>> about >>>>>>> > yesterday. What this would take is taking out all reference to >>>>>>> signing and >>>>>>> > making core OAuth just about bare tokens, then have a separate sp= ec >>>>>>> that >>>>>>> > details what to call your shared secret parameters, how to get >>>>>>> them, and how >>>>>>> > to sign with them. This makes the core spec a lot simpler (as >>>>>>> detailed below) >>>>>>> > but makes the overall use case of using signed tokens more >>>>>>> complicated to >>>>>>> > follow, as it'd be split in two. >>>>>>> > >>>>>>> > -- justin >>>>>>> > ________________________________________ >>>>>>> > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf O= f >>>>>>> Dirk >>>>>>> > Balfanz [balfanz@google.com] >>>>>>> > Sent: Thursday, May 20, 2010 7:39 PM >>>>>>> > To: OAuth WG >>>>>>> > Subject: [OAUTH-WG] proposal for factoring out request signing in >>>>>>> OAuth 2 >>>>>>> > >>>>>>> > Hi guys, >>>>>>> > >>>>>>> > at today's interim meeting, we were discussing Brian Eaton's >>>>>>> proposal for >>>>>>> > OAuth signatures. He was proposing a mechanism that would (1) do >>>>>>> away with >>>>>>> > base string canonicalization, (2) allow for symmetric and public >>>>>>> keys, and (3) >>>>>>> > allow for extensibility. >>>>>>> > >>>>>>> > He got homework from the group to prove the feasibility of his >>>>>>> proposal by >>>>>>> > showing a couple of implementations. >>>>>>> > >>>>>>> > In this post, I would like to introduce another improvement of th= e >>>>>>> OAuth 2 >>>>>>> > signing mechanism, one which is orthogonal to Brian's proposal >>>>>>> (i.e., it would >>>>>>> > work both with the signing mechanism in the current spec, as well >>>>>>> as with >>>>>>> > Brian's signature mechanism). The goal of my proposal is twofold: >>>>>>> > >>>>>>> > - it simplifies the spec. It will become more readable and >>>>>>> therefore easier to >>>>>>> > implement >>>>>>> > - it separates out the mechanisms for delegated authorization and >>>>>>> for >>>>>>> > integrity protection into two independent pieces, which can be pu= t >>>>>>> together by >>>>>>> > Servers and/or Clients like LEGO blocks. >>>>>>> > >>>>>>> > Summary: >>>>>>> > >>>>>>> > - use the client secret instead of the token secret for signing P= R >>>>>>> access >>>>>>> > requests. >>>>>>> > >>>>>>> > Long version of the proposal: >>>>>>> > >>>>>>> > - remove all references to access tokens that are not bearer toke= ns >>>>>>> from the >>>>>>> > spec. >>>>>>> > - stop calling the access tokens "bearer tokens". Call them just >>>>>>> "access >>>>>>> > tokens". >>>>>>> > - remove all references to token secrets from the spec >>>>>>> > - remove all parts of the spec that are of the kind "if >>>>>>> bearer_token then X, >>>>>>> > else Y", and replace them with X. >>>>>>> > - delete section 5.3 >>>>>>> > - add a section called "Request Authentication" that goes somethi= ng >>>>>>> like this: >>>>>>> > >>>>>>> > "Servers may require that requests be authenticated by the Client= , >>>>>>> so that >>>>>>> > presentation of the access token alone is not sufficient to acces= s >>>>>>> a Protected >>>>>>> > Resource. This has several use cases, including, but not limited >>>>>>> to, the >>>>>>> > following: >>>>>>> > >>>>>>> > - Non-repudiation: high-security deployments may require that >>>>>>> requests be >>>>>>> > authenticated (signed) in a non-repudiateable way[1] >>>>>>> > - Access to protected resources is not protected by SSL, so that >>>>>>> access tokens >>>>>>> > may leak. >>>>>>> > - End-to-end-integrity: even if SSL _is_ used, network >>>>>>> infrastructure may >>>>>>> > strip SSL protection before the request reaches the protected >>>>>>> resource. The >>>>>>> > protected resource, however, may require end-to-end integrity. >>>>>>> > >>>>>>> > If the Server requires that the Client authenticate PR access >>>>>>> requests, then >>>>>>> > the Client uses the following mechanism to sign their HTTP >>>>>>> requests: [...]" >>>>>>> > >>>>>>> > Then, we basically drop the old Section 5.3 here (except we use t= he >>>>>>> client >>>>>>> > secret instead of the access token secret). Eventually, instead o= f >>>>>>> Section >>>>>>> > 5.3, we may have Brian's new signature scheme section here, which >>>>>>> would add >>>>>>> > the option of public-key crypto[1], etc. >>>>>>> > >>>>>>> > What do you guys think? >>>>>>> > >>>>>>> > Dirk. >>>>>>> > >>>>>>> > [1] Technically speaking, the goal of non-repudiation can only be >>>>>>> achieved >>>>>>> > once we have public-key crypto. >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > 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 >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> >> > --0050450171ee0e42d20487958d32 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, May 27, 2010 at 8:56 AM, David R= ecordon <record= ond@gmail.com> wrote:
I thought Allen clearly said that signing with the client secret won't = work for Yahoo!?

Right - but he also said t= hat they (i.e. Yahoo!) wouldn't need signatures at all. So I think we&#= 39;re good from the Yahoo! side of things.=A0

Allen - did I get this right?

Dirk.
=

=A0

Hi Dirk-

We at Yahoo would be very much against using the client secret for signing = requests to Protected Resources, since this would require that the client s= ecret be distributed to the PR endpoints. For security reasons, one of the = design goals for WRAP was to keep the client secret a secret between only t= he AS and the Client =96 deliberately separating the authentication of the = client (on the AS) from the serving of the protected resource.=A0

>From your post, it=92s not quite clear what the disadvantage is with using = the Access Token secret for generating signatures.

(forgive me if this was already discussed today - I was very zonked out aft= er 3 days of IIW)

Thanks
Allen

On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz = <balfanz@google.com> wrote:
Sorry, I didn't mean to turn this into a debate over whether we should = have signatures. I think you guys stated your case clearly, and there are o= ther use cases as well.=A0

The questions I was trying to= figure out was whether=A0

- you'd be ok using the client secret to sign inste= ad of the token secret (I think I heard David say that that was ok),=A0
- you'd be ok with a signature scheme that's sufficiently fa= ctored out of the rest of the spec that it might warrant it's own compa= nion spec (I agree that this is getting close to bikeshed territory, so let= 's worry about this once we know what the signatures look like).

Dirk.


On Wed, May 26, 2010 at 2:17 PM, Luke = Shepard <lshepard@facebook.com> wrote:
So, when I argued for signatures, = the specific=A0use cases we are concerned with:

- = Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - = for Facebook, the top few apps make up a significant amount of API traffic,= so we could do signatures for them and not for everyone else

I expect that these are issues that others will encounter as= they expand into these areas- especially on the mobile side. These are not= Facebook-specific issues.

That said, I agree with= David that we should just figure out what the signatures are - I don't= really care where they live. If they need to live in a separate spec then = whatever, as long as the specs interoperate very cleanly. But I would like = to hear from other mobile developers if they have tried OAuth 2.0 with succ= ess (Brian, I think you mentioned you may have some data about that?)

On May 26, 2010, at 11:20 AM, David Reco= rdon wrote:

=
How about we figure out the technical details of signatures before fig= uring out where they're placed? :) </bikeshed>


On Wed, May 26, 2010 at 12:15 PM, Dirk B= alfanz <balfanz@google.com> wrote:
Ok - to those advocating a separate spec: Wh= at if the separate spec was really simple (a couple of pages), and we just = pasted it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section calle= d "Signed OAuth Requests" that (in its extreme form) had the sing= le sentence: "If PRs require signing, then Clients use the XYZ mechani= sm to sign their OAuth requests" (with a link to XYZ)?

Dirk.


<= div class=3D"gmail_quote">On Wed, May 26, 2010 at 10:55 AM, David Recordon = <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simple enough that they can remain i= n the core spec.

--David



On Wed, May 26, 2= 010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

=
- separate spec is fine by me
- part of the point I'm tr= ying to make is that that spec shouldn't be about signed _tokens_, but = instead about signed _HTTP requests_ (so instead of merely proving that you= know a secret that came with the token, you =A0prove who you are when you = use the token).=A0

I'd be interested what the Facebook guys think abou= t this - I believe the current signature scheme is in there mostly to addre= ss a use case they had.

Luke, Dave - would a separ= ate signing spec be ok with you guys?

Dirk.


<= div class=3D"gmail_quote">On Tue, May 25, 2010 at 6:56 PM, Allen Tom <ato= m@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to= , the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which = would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



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




<ATT00001..txt>

=


--0050450171ee0e42d20487958d32-- From atom@yahoo-inc.com Thu May 27 09:59:56 2010 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 D95D13A6AF8 for ; Thu, 27 May 2010 09:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.058 X-Spam-Level: X-Spam-Status: No, score=-15.058 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] 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 5FUBEh7N7cCu for ; Thu, 27 May 2010 09:59:44 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id BC23C3A6AF1 for ; Thu, 27 May 2010 09:59:44 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id o4RGwqG6092938; Thu, 27 May 2010 09:58:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:cc:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type:x-originalarrivaltime; b=UTQKY58rATbD0CocUq+zhVUfQb+QE1bO1B7el3glxJie1zvs3iA6DKBhtriRSKfL Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 09:58:52 -0700 Received: from 10.72.244.228 ([10.72.244.228]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 May 2010 16:58:40 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 27 May 2010 09:58:37 -0700 From: Allen Tom To: Dirk Balfanz , David Recordon Message-ID: Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr9vdlPmEpCLEXJekiUD+iZScP8Pw== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3357799117_42570958" X-OriginalArrivalTime: 27 May 2010 16:58:52.0605 (UTC) FILETIME=[E29CBED0:01CAFDBD] Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 16:59:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3357799117_42570958 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The short summary is that Yahoo thinks that signatures should not be required for most use cases. In the exceptional cases where signatures are required, then it should be up to the service provider (and not the client) to determine when they=B9re required, and which signature algorithm is to be used. Yahoo does not want to be forced to support signatures generated using the client secret =AD we don=B9t even want this to be an option for the overwhelming majority of our APIs. Due to the way services are deployed at Yahoo, our security team feels that in general, having PR endpoints validat= e signatures computed using the client secret makes our overall system LESS secure =AD since we=B9d be forced to distribute client secrets to the PR endpoints. Distributing the client secret to the PR endpoints is very undesirable, since doing so requires that the PR endpoints have the same level of security as the AS. Having a clean separation between the AS and the PR was one of the goals of Oauth-WRAP =AD and having the PR authenticate the client using the client secret violates this goal. That being said, Yahoo does have private/internal APIs which require a very high level of security in which bearer tokens are not sufficient, and signatures using the AT secret aren=B9t sufficient either =AD in these cases, signing the request with the client secret is probably the right way to go. Again =AD this should be up to the SP to determine that a signature is required, and how that signature is generated. So what I=B9m trying to say is =AD yes there are cases where it=B9s desirable to have stronger signatures than just signing with the AT secret =AD however I think that the cases in which signatures are required, and which signature algorithm is to be used should be entirely up to the SP. Does that clarify things? Allen On 5/27/10 9:04 AM, "Dirk Balfanz" wrote: >=20 >=20 > On Thu, May 27, 2010 at 8:56 AM, David Recordon wro= te: >> I thought Allen clearly said that signing with the client secret won't w= ork >> for Yahoo!? >=20 > Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures= at > all. So I think we're good from the Yahoo! side of things.=A0 >=20 > Allen - did I get this right? >=20 > Dirk. >=20 > =A0 >>=20 >>> Hi Dirk- >>>=20 >>> We at Yahoo would be very much against using the client secret for sign= ing >>> requests to Protected Resources, since this would require that the clie= nt >>> secret be distributed to the PR endpoints. For security reasons, one of= the >>> design goals for WRAP was to keep the client secret a secret between on= ly >>> the AS and the Client =AD deliberately separating the authentication of t= he >>> client (on the AS) from the serving of the protected resource.=A0 >>>=20 >>> From your post, it=B9s not quite clear what the disadvantage is with usin= g the >>> Access Token secret for generating signatures. >>>=20 >>> (forgive me if this was already discussed today - I was very zonked out >>> after 3 days of IIW) >>>=20 >>> Thanks >>> Allen >>=20 >>=20 >> On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz wrote= : >>> Sorry, I didn't mean to turn this into a debate over whether we should = have >>> signatures. I think you guys stated your case clearly, and there are ot= her >>> use cases as well.=A0 >>>=20 >>> The questions I was trying to figure out was whether=A0 >>>=20 >>> - you'd be ok using the client secret to sign instead of the token secr= et (I >>> think I heard David say that that was ok),=A0 >>> - you'd be ok with a signature scheme that's sufficiently factored out = of >>> the rest of the spec that it might warrant it's own companion spec (I a= gree >>> that this is getting close to bikeshed territory, so let's worry about = this >>> once we know what the signatures look like). >>>=20 >>> Dirk. >>>=20 >>>=20 >>> On Wed, May 26, 2010 at 2:17 PM, Luke Shepard w= rote: >>>> So, when I argued for signatures, the specific=A0use cases we are concer= ned >>>> with: >>>>=20 >>>> - Mobile handsets and networks that don't support SSL very well >>>> - High-volume applications where SSL is a significant cost to both sid= es - >>>> for Facebook, the top few apps make up a significant amount of API tra= ffic, >>>> so we could do signatures for them and not for everyone else >>>>=20 >>>> I expect that these are issues that others will encounter as they expa= nd >>>> into these areas- especially on the mobile side. These are not >>>> Facebook-specific issues. >>>>=20 >>>> That said, I agree with David that we should just figure out what the >>>> signatures are - I don't really care where they live. If they need to = live >>>> in a separate spec then whatever, as long as the specs interoperate ve= ry >>>> cleanly. But I would like to hear from other mobile developers if they= have >>>> tried OAuth 2.0 with success (Brian, I think you mentioned you may hav= e >>>> some data about that?) >>>>=20 >>>> On May 26, 2010, at 11:20 AM, David Recordon wrote: >>>>=20 >>>>> How about we figure out the technical details of signatures before >>>>> figuring out where they're placed? :) >>>>>=20 >>>>>=20 >>>>> On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz w= rote: >>>>>> Ok - to those advocating a separate spec: What if the separate spec = was >>>>>> really simple (a couple of pages), and we just pasted it as "Section= X" >>>>>> into the core OAuth spec? >>>>>>=20 >>>>>> To Facebook: What if the core OAuth spec had a section called "Signe= d >>>>>> OAuth Requests" that (in its extreme form) had the single sentence: = "If >>>>>> PRs require signing, then Clients use the XYZ mechanism to sign thei= r >>>>>> OAuth requests" (with a link to XYZ)? >>>>>>=20 >>>>>> Dirk. >>>>>>=20 >>>>>>=20 >>>>>> On Wed, May 26, 2010 at 10:55 AM, David Recordon >>>>>> wrote: >>>>>>> I'd prefer that we keep signatures simple enough that they can rema= in in >>>>>>> the core spec. >>>>>>>=20 >>>>>>> --David >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz >>>>>>> wrote: Repeating what I said before: - separate spec is fine by me - part of the point I'm trying to make is that that spec shouldn't be about signed _tokens_, but instead about signed _HTTP requests_ (so instead of merely proving that you know a secret that came with the token, you =A0prove who you are when you use the token).=A0 I'd be interested what the Facebook guys think about this - I believe the current signature scheme is in there mostly to address a use case they had. Luke, Dave - would a separate signing spec be ok with you guys? Dirk. On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: +1 I fully agree with Dirk and Brian that there needs to be some work on signatures. There are many types of applications that require higher levels of security than what bearer tokens can provide. That being said, I think that bearer token/refresh token model can satisify the majority of use cases - in fact it would satisfy 100% of all public API= s that we have at Yahoo. Perhaps in the interest of keeping the spec focused, it would make more sense to split out a Signed Token Spec, as Justin proposes, that is focused solely on uses cases that require a signature? Allen On 5/21/10 11:27 AM, "Richer, Justin P." wrote: > I have a slightly more radical proposal. What if we factor out the signed > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, giv= en > the same attention by the group and all that like Eran was talking about > yesterday. What this would take is taking out all reference to signing an= d > making core OAuth just about bare tokens, then have a separate spec that > details what to call your shared secret parameters, how to get them, and = how > to sign with them. This makes the core spec a lot simpler (as detailed be= low) > but makes the overall use case of using signed tokens more complicated to > follow, as it'd be split in two. > > =A0-- justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > Balfanz [balfanz@google.com] > Sent: Thursday, May 20, 2010 7:39 PM > To: OAuth WG > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away wit= h > base string canonicalization, (2) allow for symmetric and public keys, an= d (3) > allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal b= y > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth = 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it = would > work both with the signing mechanism in the current spec, as well as with > Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easi= er to > implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put togeth= er by > Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from = the > spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then= X, > else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like = this: > > "Servers may require that requests be authenticated by the Client, so tha= t > presentation of the access token alone is not sufficient to access a Prot= ected > Resource. =A0This has several use cases, including, but not limited to, the > following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access t= okens > may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. T= he > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, t= hen > the Client uses the following mechanism to sign their HTTP requests: [...= ]" > > Then, we basically drop the old Section 5.3 here (except we use the clien= t > secret instead of the access token secret). Eventually, instead of Sectio= n > 5.3, we may have Brian's new signature scheme section here, which would a= dd > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieve= d > once we have public-key crypto. > > _______________________________________________ > 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 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> >>>>=20 >>>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --B_3357799117_42570958 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2= The short summary is that Yahoo thinks that signatures should not be requi= red for most use cases. In the exceptional cases where signatures are requir= ed, then it should be up to the service provider (and not the client) to det= ermine when they’re required, and  which signature algorithm is t= o be used.  Yahoo does not want to be forced to support signatures gene= rated using the client secret – we don’t even want this to be an= option for the overwhelming majority of our APIs. Due to the way services a= re deployed at Yahoo, our security team feels that in general, having PR end= points validate signatures computed using the client secret makes our overal= l system LESS secure – since we’d be forced to distribute client= secrets to the PR endpoints. Distributing the client secret to the PR endpo= ints is very undesirable, since doing so requires that the PR endpoints have= the same level of security as the AS.

Having a clean separation between the AS and the PR was one of the goals of= Oauth-WRAP – and having the PR authenticate the client using the clie= nt secret violates this goal.

That being said, Yahoo does have private/internal APIs which require a very= high level of security in which bearer tokens are not sufficient, and signa= tures using the AT secret aren’t sufficient either – in these ca= ses, signing the request with the client secret is probably the right way to= go. Again – this should be up to the SP to determine that a signature= is required, and how that signature is generated.

So what I’m trying to say is – yes there are cases where itR= 17;s desirable to have stronger signatures than just signing with the AT sec= ret – however I think that the cases in which signatures are required,= and which signature algorithm is to be used should be entirely up to the SP= .

Does that clarify things?
Allen




On 5/27/10 9:04 AM, "Dirk Balfanz" <balfanz@google.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>

On Thu, May 27, 2010 at 8:56 AM, David Recordon <recordond@gmail.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>I thought Allen clearly said that signing with t= he client secret won't work for Yahoo!?
=
Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures a= t all. So I think we're good from the Yahoo! side of things.=A0

Allen - did I get this right?

Dirk.

=A0
<= SPAN STYLE=3D'font-size:11pt'>
<= SPAN STYLE=3D'font-size:11pt'>Hi Dirk-

We at Yahoo would be very much against using the client secret for signing = requests to Protected Resources, since this would require that the client se= cret be distributed to the PR endpoints. For security reasons, one of the de= sign goals for WRAP was to keep the client secret a secret between only the = AS and the Client – deliberately separating the authentication of the = client (on the AS) from the serving of the protected resource.=A0

>From your post, it’s not quite clear what the disadvantage is with us= ing the Access Token secret for generating signatures.

(forgive me if this was already discussed today - I was very zonked out aft= er 3 days of IIW)

Thanks
Allen
=

On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <balfanz@google.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Sorry, I didn't mean to turn this into a debate = over whether we should have signatures. I think you guys stated your case cl= early, and there are other use cases as well.=A0

The questions I was trying to figure out was whether=A0

- you'd be ok using the client secret to sign instead of the token secret (= I think I heard David say that that was ok),=A0
- you'd be ok with a signature scheme that's sufficiently factored out of t= he rest of the spec that it might warrant it's own companion spec (I agree t= hat this is getting close to bikeshed territory, so let's worry about this o= nce we know what the signatures look like).

Dirk.


On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <lshepard@facebook.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>So, when I argued for signatures, the specific=A0u= se cases we are concerned with:

- Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - = for Facebook, the top few apps make up a significant amount of API traffic, = so we could do signatures for them and not for everyone else

I expect that these are issues that others will encounter as they expand in= to these areas- especially on the mobile side. These are not Facebook-specif= ic issues.

That said, I agree with David that we should just figure out what the signa= tures are - I don't really care where they live. If they need to live in a s= eparate spec then whatever, as long as the specs interoperate very cleanly. = But I would like to hear from other mobile developers if they have tried OAu= th 2.0 with success (Brian, I think you mentioned you may have some data abo= ut that?)

On May 26, 2010, at 11:20 AM, David Recordon wrote:

<= SPAN STYLE=3D'font-size:11pt'>How about we figure out the technical details of= signatures before figuring out where they're placed? :) </bikeshed>

On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balfanz@google.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Ok - to those advocating a separate spec: What i= f the separate spec was really simple (a couple of pages), and we just paste= d it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section called "Signed = OAuth Requests" that (in its extreme form) had the single sentence: &qu= ot;If PRs require signing, then Clients use the XYZ mechanism to sign their = OAuth requests" (with a link to XYZ)?

Dirk.


On Wed, May 26, 2010 at 10:55 AM, David Recordon <recordond@gmail.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>I'd prefer that we keep signatures simple enough= that they can remain in the core spec.

--David



On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Dirk.


On Tue, May 25, 2010 at 6:56 PM, Allen Tom <atom@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk<= BR> > Balfanz [balfanz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's proposal = for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.e., = it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:
>
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= BR> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to, = the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which woul= d add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _______________________________________________
> 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

<= BLOCKQUOTE>

=
=
<ATT00001..txt>
=
=
=
=

___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
--B_3357799117_42570958-- From muralive@gmail.com Thu May 27 10:09:16 2010 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 08CE23A6896 for ; Thu, 27 May 2010 10:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 vsig--SHBjZL for ; Thu, 27 May 2010 10:09:15 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 26E4E3A6ABA for ; Thu, 27 May 2010 10:09:10 -0700 (PDT) Received: by wye20 with SMTP id 20so150446wye.31 for ; Thu, 27 May 2010 10:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=jR8b0Sfwj+7u0Be0jkdlegowTzGM/B1suGkt4mp7i3k=; b=h+g8D8SqprCWir6RuzGinNGYvc2qlYeFpc6NAbcyl9o3OUD1kY/eR0UO3zI1tr/0YR E14lPxReFXKVdF7qbguK48pLpbHG+q0qa1dXic5C396AJf95hr9XySNkDMMiciPXXMnx qZVaUxcZzBAAwPg/e7IMf6Vo5hg8aC7828zVI= 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; b=JWmrvVGLWo82OzhMAXWUy2mCy4UyfOGebkV/g686MPB/yJoGUSBK2M+ylUAGK9h/Ng QTEnapSnH1h0X7UMcHqT3NE16Zh1/2gV/NUWQ0aB2khTtyrkUW7RC9/vZuTEkD1IfhDh ThwA1vw/TMBLbyLS//O48bPNJmFD5IJ4zleIs= Received: by 10.227.147.193 with SMTP id m1mr10224286wbv.23.1274980137712; Thu, 27 May 2010 10:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.89.141 with HTTP; Thu, 27 May 2010 10:08:37 -0700 (PDT) In-Reply-To: References: From: Murali VP Date: Thu, 27 May 2010 10:08:37 -0700 Message-ID: To: Evan Gilbert Content-Type: multipart/alternative; boundary=001636831762343c770487967249 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05) 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, 27 May 2010 17:09:16 -0000 --001636831762343c770487967249 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 26, 2010 at 8:51 PM, Evan Gilbert wrote: > > > On Tue, May 25, 2010 at 1:43 PM, Murali VP wrote: > >> Anyway to find out what the outcome was from the May 20th interim meeting? >> I >> wanted to participate but had to be at Google I/O. >> >> 3.5. User-Agent Flow >> >> 1. Since the client_id is public, the only check that prevents from >> any client posing as a registered client is the redirect_uri, this is >> fine, except that if client web application has numerous domains, each >> domain should register and have a separate client_id which is a pain. >> The alternative of a single redirect_uri returning a 302 won't work >> since the fragment will no more be available (I guess there are ways >> to get around this). >> > > You can have a single redirect_uri that does a client side redirect using > JavaScript. The only catch is that this is dangerous from a security > perspective - your additional redirect needs to have strict rules about the > domains it can forward to - so this should be considered a power-developer > technique and we need to write up best practices or better provide a JS > library that has gone through review. > > Agree with you, based on the fact that the access_token is sent in the fragment and not as a query parameter attached to the redirect_uri implies that the access_token is not meant to be sent to the client's web server, so the forwarding cannot result in sending the access_token but should continue to attach the fragment which the forwarded to domain should still have a script to read and use the access_token in the fragment. --001636831762343c770487967249 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 26, 2010 at 8:51 PM, Evan Gilber= t <uidude@google.= com> wrote:


On Tue, May 25, 2010 a= t 1:43 PM, Murali VP <muralive@gmail.com> wrote:
Anyway to find out what the outcome was from the May 20th interim meeting? = I
wanted to participate but had to be at Google I/O.

3.5. =A0User-Agent Flow

1. Since the client_id is public, the only check that prevents from
any client posing as a registered client is the redirect_uri, this is
fine, except that if client web application has numerous domains, each
domain should register and have a separate client_id which is a pain.
The alternative of a single redirect_uri returning a 302 won't work
since the fragment will no more be available (I guess there are ways
to get around this).

You can have= a single redirect_uri that does a client side redirect using JavaScript. T= he only catch is that this is dangerous from a security perspective - your = additional redirect needs to have strict rules about the domains it can for= ward to - so this should be considered a power-developer technique and we n= eed to write up best practices or better provide a JS library that has gone= through review.
=A0
Agree with you, based on the fact tha= t the access_token is sent in the fragment and not as a query parameter att= ached to the redirect_uri implies that the access_token is not meant to be = sent to the client's web server, so the forwarding cannot result in sen= ding the access_token but should continue to attach the fragment which the = forwarded to domain should still have a script to read and use the access_t= oken in the fragment.
--001636831762343c770487967249-- From mscurtescu@google.com Thu May 27 10:11:22 2010 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 986553A6ABA for ; Thu, 27 May 2010 10:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.677 X-Spam-Level: X-Spam-Status: No, score=-104.677 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 pI8BAr5E76Jx for ; Thu, 27 May 2010 10:11:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 52CB13A6B4B for ; Thu, 27 May 2010 10:11:20 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o4RHB78u019110 for ; Thu, 27 May 2010 10:11:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274980268; bh=IzSF0ZhEItyCW5axTojB4PireUQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=RcuKiSbaBCXf/oz24A9AZ09idzA3r/SYiojl/1LftGQRokt/KQTGtuSpzszfAb2KX EMnbslQpxxt8DBJkQ+XgA== 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=sSGxsISyPqRBJZGv2BeZhnhXqIcBVtix6CWr9IRUnhAexmNvhgZsCxRVUkOvggXDc L3t4/hP/TB+sJWeCgKcqQ== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by kpbe14.cbf.corp.google.com with ESMTP id o4RHB5Xf022849 for ; Thu, 27 May 2010 10:11:05 -0700 Received: by pwi6 with SMTP id 6so264677pwi.0 for ; Thu, 27 May 2010 10:11:05 -0700 (PDT) Received: by 10.140.252.6 with SMTP id z6mr8227167rvh.229.1274980265135; Thu, 27 May 2010 10:11:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Thu, 27 May 2010 10:10:45 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 27 May 2010 10:10:45 -0700 Message-ID: To: Nat Sakimura Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 17:11:22 -0000 Thanks for the clarification Nat. Just curios, can't the phone client actually POST to the authz server? That would take care of the URL length limitation. In your diagram, the verification code is passed from UA to Web Client and then the Web Client is exchanging it for the access and refresh tokens. These tokens are never passed back to the UA, is that intended? Also, why can't the UA do the exchange directly? Marius On Wed, May 26, 2010 at 6:11 PM, Nat Sakimura wrote: > Yes. It is mainly for something called "feature phones" that has over > 90% share in Japan. > > If it is the core OAuth only, it is not much of the problem. > However, when we start adding something like Identity Layer on top of it, > it starts to get problematic. > > The web client usually lives on external web server. > > Here are some answers to the question I got to the blog page from > Luke, so that we can share them here as well. > > Q. Why "immediate" in the request? > > Initially, I was thinking like you did. Then, I got feedback from the > community that if "immediate" was denied at the Authz Server, the RP > may want to redo it with "immediate"=false, thus overriding what was > written in the request file instead of making two versions of the > request file. It is an override mechanism. > > Q. Why not "type" in the request? > > I could certainly include it in the request. Only the reason I did not > was that it was already written in the request file, and it is not > going to change like "immediate". The concern about having "type" in > the request instead of request file is that it is easy to tamper. > Since "type" is also used as some kind of security measure, it might > be better to protect it if it is easy to do, and that was another > reason for putting type in the request file and not request. > > Q. Name "rurl" confusing > > Originally, "rurl" was called "rpfurl" for Request Parameter File URL. > Then, Breno told me that it is "mouthful" and since then it was > wanting a better name. "rurl" was my attempt to make it not mouthful. > Certainly, I can make it "request_url". > > > On Thu, May 27, 2010 at 2:54 AM, Marius Scurtescu wrote: >> Hi Nat, >> >> The main use case for this flow would be for mobile apps that cannot >> handle long URLs, is that correct? If so, I assume that the only >> problematic long URL is the initial request sent through the >> user-agent to the authorization server, right? >> >> Does the Web Client run on the phone as well, or on some external web server? >> >> Marius >> >> >> >> On Wed, May 26, 2010 at 6:57 AM, Nat Sakimura wrote: >>> Back in February, I have suggested mobile web app flow to the oauth_wrap group. >>> Now that it is wrapped into OAuth 2.0, here is my another try, this >>> time for OAuth 2.0 draft. >>> >>> "OAuth 2.0 Mobile WebApp Flow" >>> http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ >>> >>> I really wish that this could be included in OAuth 2.0 as it will help >>> build identity layers on OAuth 2.0 that works for mobile web browsers etc. >>> >>> -- >>> Nat Sakimura (=nat) >>> http://www.sakimura.org/en/ >>> http://twitter.com/_nat_en >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > From sakimura@gmail.com Thu May 27 11:06:38 2010 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 075F93A6BE7 for ; Thu, 27 May 2010 11:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_50=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 tOWI1nGJPnSn for ; Thu, 27 May 2010 11:06:36 -0700 (PDT) Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by core3.amsl.com (Postfix) with ESMTP id 0A7993A6BE0 for ; Thu, 27 May 2010 11:06:19 -0700 (PDT) Received: by pzk9 with SMTP id 9so204876pzk.19 for ; Thu, 27 May 2010 11:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=d1Vc40XH6svzoMGbADkLIYpW3kPwDwxtvrUQoYuckcc=; b=OK5BHVNkaSV89GN7jlisxglcz5NwjhQ7Ftq19QPjhkRi/h8EFiHSoYf+TqWQoT1TNz Gseg7T965TD759u0Pc64biDFCYIhyuLEEiCs7EMAdl/a/PTRAZO3iU7GZNSdywzSnZvu gH72ABZE9dJN/OrLh+d4v8D43vao2F4wU4tV0= 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=Mr3QoV5UlPYVs7gW7BQ/Xzm1gEGbRGyObSNOOemWfxxzkpdWOmpQ5rpDFWOUN1jTDc vEVn22zKjW2nEh1xuj/yS5wLdsBRgvJg5pbk1MQoLHM72czA5n1gp3qAozE9eww1SDbh EUuRy5xwiWfpfggo2/5R+3GbetgvTW1NlmNO8= MIME-Version: 1.0 Received: by 10.142.55.11 with SMTP id d11mr755257wfa.99.1274983566730; Thu, 27 May 2010 11:06:06 -0700 (PDT) Received: by 10.231.31.132 with HTTP; Thu, 27 May 2010 11:06:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 May 2010 03:06:06 +0900 Message-ID: From: Nat Sakimura To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 18:06:38 -0000 On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu wrote: > Thanks for the clarification Nat. > > Just curios, can't the phone client actually POST to the authz server? > That would take care of the URL length limitation. POST means an extra click, which is a UI disaster. Also, more data over the air means slower response. > > In your diagram, the verification code is passed from UA to Web Client > and then the Web Client is exchanging it for the access and refresh > tokens. These tokens are never passed back to the UA, is that > intended? Also, why can't the UA do the exchange directly? It is following the Web Server flow. Apart from getting the request parameter through the request_url fetch is almost exactly as in the Web Server flow. You could conceive similar things to UA-flow, I suppose. > > Marius > > > > On Wed, May 26, 2010 at 6:11 PM, Nat Sakimura wrote: >> Yes. It is mainly for something called "feature phones" that has over >> 90% share in Japan. >> >> If it is the core OAuth only, it is not much of the problem. >> However, when we start adding something like Identity Layer on top of it, >> it starts to get problematic. >> >> The web client usually lives on external web server. >> >> Here are some answers to the question I got to the blog page from >> Luke, so that we can share them here as well. >> >> Q. Why "immediate" in the request? >> >> Initially, I was thinking like you did. Then, I got feedback from the >> community that if "immediate" was denied at the Authz Server, the RP >> may want to redo it with "immediate"=false, thus overriding what was >> written in the request file instead of making two versions of the >> request file. It is an override mechanism. >> >> Q. Why not "type" in the request? >> >> I could certainly include it in the request. Only the reason I did not >> was that it was already written in the request file, and it is not >> going to change like "immediate". The concern about having "type" in >> the request instead of request file is that it is easy to tamper. >> Since "type" is also used as some kind of security measure, it might >> be better to protect it if it is easy to do, and that was another >> reason for putting type in the request file and not request. >> >> Q. Name "rurl" confusing >> >> Originally, "rurl" was called "rpfurl" for Request Parameter File URL. >> Then, Breno told me that it is "mouthful" and since then it was >> wanting a better name. "rurl" was my attempt to make it not mouthful. >> Certainly, I can make it "request_url". >> >> >> On Thu, May 27, 2010 at 2:54 AM, Marius Scurtescu wrote: >>> Hi Nat, >>> >>> The main use case for this flow would be for mobile apps that cannot >>> handle long URLs, is that correct? If so, I assume that the only >>> problematic long URL is the initial request sent through the >>> user-agent to the authorization server, right? >>> >>> Does the Web Client run on the phone as well, or on some external web server? >>> >>> Marius >>> >>> >>> >>> On Wed, May 26, 2010 at 6:57 AM, Nat Sakimura wrote: >>>> Back in February, I have suggested mobile web app flow to the oauth_wrap group. >>>> Now that it is wrapped into OAuth 2.0, here is my another try, this >>>> time for OAuth 2.0 draft. >>>> >>>> "OAuth 2.0 Mobile WebApp Flow" >>>> http://www.sakimura.org/en/modules/wordpress/oauth-20-mobile-webapp-flow/ >>>> >>>> I really wish that this could be included in OAuth 2.0 as it will help >>>> build identity layers on OAuth 2.0 that works for mobile web browsers etc. >>>> >>>> -- >>>> Nat Sakimura (=nat) >>>> http://www.sakimura.org/en/ >>>> http://twitter.com/_nat_en >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> >> >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From gffletch@aol.com Thu May 27 11:12:36 2010 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 ACA453A67ED for ; Thu, 27 May 2010 11:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 FT+yWOL9u4tj for ; Thu, 27 May 2010 11:12:24 -0700 (PDT) Received: from imr-ma05.mx.aol.com (imr-ma05.mx.aol.com [64.12.100.31]) by core3.amsl.com (Postfix) with ESMTP id 1240D3A6B6C for ; Thu, 27 May 2010 11:12:15 -0700 (PDT) Received: from mtaout-da05.r1000.mx.aol.com (mtaout-da05.r1000.mx.aol.com [172.29.51.133]) by imr-ma05.mx.aol.com (8.14.1/8.14.1) with ESMTP id o4RIBfmn030485; Thu, 27 May 2010 14:11:41 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 45AF1E0000B3; Thu, 27 May 2010 14:11:41 -0400 (EDT) Message-ID: <4BFEB5DC.9050705@aol.com> Date: Thu, 27 May 2010 14:11:40 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Allen Tom References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020807080905050105080906" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:504447168:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33854bfeb5dd1b52 X-AOL-IP: 10.181.183.108 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 18:12:36 -0000 This is a multi-part message in MIME format. --------------020807080905050105080906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hmm... to me this says... Yahoo won't deploy PRs that require client_secret signatures, but may have some internal apps where this is ok. So, to me that sounds like Yahoo is ok with client_secret based signatures as one way to sign the requests, but they don't want it to be the only way. I would like to bring back what Dirk has said earlier in this thread... 1. Signing isn't about the token but rather about the message 2. Signing provides message integrity 3. Signing provides (or should allow for) proof of sender I'd like to add... 4. Signing (combined with appropriate information in the AT) enables "right to present" the token I think that for certain use cases, its critical that the PR be able to ensure that the client is "authorized" to present the AT. This isn't possible for bearer tokens. I also don't believe this hurts sub-delegation because the AS can create an AT that can be sub-delegated and when the sub-delegate presents the AT, the PR can verify that the sub-delegate is allowed to present that AT. Thanks, George On 5/27/10 12:58 PM, Allen Tom wrote: > The short summary is that Yahoo thinks that signatures should not be > required for most use cases. In the exceptional cases where signatures > are required, then it should be up to the service provider (and not > the client) to determine when they're required, and which signature > algorithm is to be used. Yahoo does not want to be forced to support > signatures generated using the client secret -- we don't even want > this to be an option for the overwhelming majority of our APIs. Due to > the way services are deployed at Yahoo, our security team feels that > in general, having PR endpoints validate signatures computed using the > client secret makes our overall system LESS secure -- since we'd be > forced to distribute client secrets to the PR endpoints. Distributing > the client secret to the PR endpoints is very undesirable, since doing > so requires that the PR endpoints have the same level of security as > the AS. > > Having a clean separation between the AS and the PR was one of the > goals of Oauth-WRAP -- and having the PR authenticate the client using > the client secret violates this goal. > > That being said, Yahoo does have private/internal APIs which require a > very high level of security in which bearer tokens are not sufficient, > and signatures using the AT secret aren't sufficient either -- in > these cases, signing the request with the client secret is probably > the right way to go. Again -- this should be up to the SP to determine > that a signature is required, and how that signature is generated. > > So what I'm trying to say is -- yes there are cases where it's > desirable to have stronger signatures than just signing with the AT > secret -- however I think that the cases in which signatures are > required, and which signature algorithm is to be used should be > entirely up to the SP. > > Does that clarify things? > Allen > > > > > On 5/27/10 9:04 AM, "Dirk Balfanz" wrote: > > > > On Thu, May 27, 2010 at 8:56 AM, David Recordon > wrote: > > I thought Allen clearly said that signing with the client > secret won't work for Yahoo!? > > > Right - but he also said that they (i.e. Yahoo!) wouldn't need > signatures at all. So I think we're good from the Yahoo! side of > things. > > Allen - did I get this right? > > Dirk. > > > > Hi Dirk- > > We at Yahoo would be very much against using the client > secret for signing requests to Protected Resources, since > this would require that the client secret be distributed > to the PR endpoints. For security reasons, one of the > design goals for WRAP was to keep the client secret a > secret between only the AS and the Client -- deliberately > separating the authentication of the client (on the AS) > from the serving of the protected resource. > > >From your post, it's not quite clear what the disadvantage > is with using the Access Token secret for generating > signatures. > > (forgive me if this was already discussed today - I was > very zonked out after 3 days of IIW) > > Thanks > Allen > > > > On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz > wrote: > > Sorry, I didn't mean to turn this into a debate over > whether we should have signatures. I think you guys stated > your case clearly, and there are other use cases as well. > > The questions I was trying to figure out was whether > > - you'd be ok using the client secret to sign instead of > the token secret (I think I heard David say that that was > ok), > - you'd be ok with a signature scheme that's sufficiently > factored out of the rest of the spec that it might warrant > it's own companion spec (I agree that this is getting > close to bikeshed territory, so let's worry about this > once we know what the signatures look like). > > Dirk. > > > On Wed, May 26, 2010 at 2:17 PM, Luke Shepard > wrote: > > So, when I argued for signatures, the specific use > cases we are concerned with: > > - Mobile handsets and networks that don't support SSL > very well > - High-volume applications where SSL is a significant > cost to both sides - for Facebook, the top few apps > make up a significant amount of API traffic, so we > could do signatures for them and not for everyone else > > I expect that these are issues that others will > encounter as they expand into these areas- especially > on the mobile side. These are not Facebook-specific > issues. > > That said, I agree with David that we should just > figure out what the signatures are - I don't really > care where they live. If they need to live in a > separate spec then whatever, as long as the specs > interoperate very cleanly. But I would like to hear > from other mobile developers if they have tried OAuth > 2.0 with success (Brian, I think you mentioned you may > have some data about that?) > > On May 26, 2010, at 11:20 AM, David Recordon wrote: > > How about we figure out the technical details of > signatures before figuring out where they're > placed? :) > > > On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz > wrote: > > Ok - to those advocating a separate spec: What > if the separate spec was really simple (a > couple of pages), and we just pasted it as > "Section X" into the core OAuth spec? > > To Facebook: What if the core OAuth spec had a > section called "Signed OAuth Requests" that > (in its extreme form) had the single sentence: > "If PRs require signing, then Clients use the > XYZ mechanism to sign their OAuth requests" > (with a link to XYZ)? > > Dirk. > > > On Wed, May 26, 2010 at 10:55 AM, David > Recordon wrote: > > I'd prefer that we keep signatures simple > enough that they can remain in the core spec. > > --David > > > > On Wed, May 26, 2010 at 11:44 AM, Dirk > Balfanz wrote: > > Repeating what I said before: > > - separate spec is fine by me > - part of the point I'm trying to make is that that spec shouldn't be > about signed _tokens_, but instead about signed _HTTP requests_ (so > instead of merely proving that you know a secret that came with the > token, you prove who you are when you use the token). > > I'd be interested what the Facebook guys think about this - I believe > the current signature scheme is in there mostly to address a use case > they had. > > Luke, Dave - would a separate signing spec be ok with you guys? > > Dirk. > > > On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: > +1 > > I fully agree with Dirk and Brian that there needs to be some work on > signatures. There are many types of applications that require higher > levels > of security than what bearer tokens can provide. > > That being said, I think that bearer token/refresh token model can > satisify > the majority of use cases - in fact it would satisfy 100% of all > public APIs > that we have at Yahoo. > > Perhaps in the interest of keeping the spec focused, it would make more > sense to split out a Signed Token Spec, as Justin proposes, that is > focused > solely on uses cases that require a signature? > > Allen > > > > On 5/21/10 11:27 AM, "Richer, Justin P." wrote: > > > I have a slightly more radical proposal. What if we factor out the signed > > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, > given > > the same attention by the group and all that like Eran was talking about > > yesterday. What this would take is taking out all reference to > signing and > > making core OAuth just about bare tokens, then have a separate spec that > > details what to call your shared secret parameters, how to get them, > and how > > to sign with them. This makes the core spec a lot simpler (as > detailed below) > > but makes the overall use case of using signed tokens more complicated to > > follow, as it'd be split in two. > > > > -- justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > > Balfanz [balfanz@google.com] > > Sent: Thursday, May 20, 2010 7:39 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > > > Hi guys, > > > > at today's interim meeting, we were discussing Brian Eaton's proposal for > > OAuth signatures. He was proposing a mechanism that would (1) do away > with > > base string canonicalization, (2) allow for symmetric and public > keys, and (3) > > allow for extensibility. > > > > He got homework from the group to prove the feasibility of his > proposal by > > showing a couple of implementations. > > > > In this post, I would like to introduce another improvement of the > OAuth 2 > > signing mechanism, one which is orthogonal to Brian's proposal (i.e., > it would > > work both with the signing mechanism in the current spec, as well as with > > Brian's signature mechanism). The goal of my proposal is twofold: > > > > - it simplifies the spec. It will become more readable and therefore > easier to > > implement > > - it separates out the mechanisms for delegated authorization and for > > integrity protection into two independent pieces, which can be put > together by > > Servers and/or Clients like LEGO blocks. > > > > Summary: > > > > - use the client secret instead of the token secret for signing PR access > > requests. > > > > Long version of the proposal: > > > > - remove all references to access tokens that are not bearer tokens > from the > > spec. > > - stop calling the access tokens "bearer tokens". Call them just "access > > tokens". > > - remove all references to token secrets from the spec > > - remove all parts of the spec that are of the kind "if bearer_token > then X, > > else Y", and replace them with X. > > - delete section 5.3 > > - add a section called "Request Authentication" that goes something > like this: > > > > "Servers may require that requests be authenticated by the Client, so > that > > presentation of the access token alone is not sufficient to access a > Protected > > Resource. This has several use cases, including, but not limited to, the > > following: > > > > - Non-repudiation: high-security deployments may require that requests be > > authenticated (signed) in a non-repudiateable way[1] > > - Access to protected resources is not protected by SSL, so that > access tokens > > may leak. > > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > > strip SSL protection before the request reaches the protected > resource. The > > protected resource, however, may require end-to-end integrity. > > > > If the Server requires that the Client authenticate PR access > requests, then > > the Client uses the following mechanism to sign their HTTP requests: > [...]" > > > > Then, we basically drop the old Section 5.3 here (except we use the > client > > secret instead of the access token secret). Eventually, instead of > Section > > 5.3, we may have Brian's new signature scheme section here, which > would add > > the option of public-key crypto[1], etc. > > > > What do you guys think? > > > > Dirk. > > > > [1] Technically speaking, the goal of non-repudiation can only be > achieved > > once we have public-key crypto. > > > > _______________________________________________ > > 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 --------------020807080905050105080906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hmm... to me this says...
Yahoo won't deploy PRs that require client_secret signatures, but may have some internal apps where this is ok.

So, to me that sounds like Yahoo is ok with client_secret based signatures as one way to sign the requests, but they don't want it to be the only way.

I would like to bring back what Dirk has said earlier in this thread...

1. Signing isn't about the token but rather about the message
2. Signing provides message integrity
3. Signing provides (or should allow for) proof of sender

I'd like to add...
4. Signing (combined with appropriate information in the AT) enables "right to present" the token

I think that for certain use cases, its critical that the PR be able to ensure that the client is "authorized" to present the AT. This isn't possible for bearer tokens. I also don't believe this hurts sub-delegation because the AS can create an AT that can be sub-delegated and when the sub-delegate presents the AT, the PR can verify that the sub-delegate is allowed to present that AT.

Thanks,
George

On 5/27/10 12:58 PM, Allen Tom wrote:
Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 The short summary is that Yahoo thinks that signatures should not be required for most use cases. In the exceptional cases where signatures are required, then it should be up to the service provider (and not the client) to determine when they’re required, and  which signature algorithm is to be used.  Yahoo does not want to be forced to support signatures generated using the client secret – we don’t even want this to be an option for the overwhelming majority of our APIs. Due to the way services are deployed at Yahoo, our security team feels that in general, having PR endpoints validate signatures computed using the client secret makes our overall system LESS secure – since we’d be forced to distribute client secrets to the PR endpoints. Distributing the client secret to the PR endpoints is very undesirable, since doing so requires that the PR endpoints have the same level of security as the AS.

Having a clean separation between the AS and the PR was one of the goals of Oauth-WRAP – and having the PR authenticate the client using the client secret violates this goal.

That being said, Yahoo does have private/internal APIs which require a very high level of security in which bearer tokens are not sufficient, and signatures using the AT secret aren’t sufficient either – in these cases, signing the request with the client secret is probably the right way to go. Again – this should be up to the SP to determine that a signature is required, and how that signature is generated.

So what I’m trying to say is – yes there are cases where it’s desirable to have stronger signatures than just signing with the AT secret – however I think that the cases in which signatures are required, and which signature algorithm is to be used should be entirely up to the SP.

Does that clarify things?
Allen




On 5/27/10 9:04 AM, "Dirk Balfanz" <balfanz@google.com> wrote:


On Thu, May 27, 2010 at 8:56 AM, David Recordon <recordond@gmail.com> wrote:
I thought Allen clearly said that signing with the client secret won't work for Yahoo!?

Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures at all. So I think we're good from the Yahoo! side of things. 

Allen - did I get this right?

Dirk.

 

Hi Dirk-

We at Yahoo would be very much against using the client secret for signing requests to Protected Resources, since this would require that the client secret be distributed to the PR endpoints. For security reasons, one of the design goals for WRAP was to keep the client secret a secret between only the AS and the Client – deliberately separating the authentication of the client (on the AS) from the serving of the protected resource. 

>From your post, it’s not quite clear what the disadvantage is with using the Access Token secret for generating signatures.

(forgive me if this was already discussed today - I was very zonked out after 3 days of IIW)

Thanks
Allen


On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <balfanz@google.com> wrote:
Sorry, I didn't mean to turn this into a debate over whether we should have signatures. I think you guys stated your case clearly, and there are other use cases as well. 

The questions I was trying to figure out was whether 

- you'd be ok using the client secret to sign instead of the token secret (I think I heard David say that that was ok), 
- you'd be ok with a signature scheme that's sufficiently factored out of the rest of the spec that it might warrant it's own companion spec (I agree that this is getting close to bikeshed territory, so let's worry about this once we know what the signatures look like).

Dirk.


On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <lshepard@facebook.com> wrote:
So, when I argued for signatures, the specific use cases we are concerned with:

- Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - for Facebook, the top few apps make up a significant amount of API traffic, so we could do signatures for them and not for everyone else

I expect that these are issues that others will encounter as they expand into these areas- especially on the mobile side. These are not Facebook-specific issues.

That said, I agree with David that we should just figure out what the signatures are - I don't really care where they live. If they need to live in a separate spec then whatever, as long as the specs interoperate very cleanly. But I would like to hear from other mobile developers if they have tried OAuth 2.0 with success (Brian, I think you mentioned you may have some data about that?)

On May 26, 2010, at 11:20 AM, David Recordon wrote:
How about we figure out the technical details of signatures before figuring out where they're placed? :) </bikeshed>


On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balfanz@google.com> wrote:
Ok - to those advocating a separate spec: What if the separate spec was really simple (a couple of pages), and we just pasted it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section called "Signed OAuth Requests" that (in its extreme form) had the single sentence: "If PRs require signing, then Clients use the XYZ mechanism to sign their OAuth requests" (with a link to XYZ)?

Dirk.


On Wed, May 26, 2010 at 10:55 AM, David Recordon <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simple enough that they can remain in the core spec.

--David



On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

- separate spec is fine by me
- part of the point I'm trying to make is that that spec shouldn't be about signed _tokens_, but instead about signed _HTTP requests_ (so instead of merely proving that you know a secret that came with the token, you  prove who you are when you use the token). 

I'd be interested what the Facebook guys think about this - I believe the current signature scheme is in there mostly to address a use case they had.

Luke, Dave - would a separate signing spec be ok with you guys?

Dirk.


On Tue, May 25, 2010 at 6:56 PM, Allen Tom <atom@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify
the majority of use cases - in fact it would satisfy 100% of all public APIs
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the signed
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given
> the same attention by the group and all that like Eran was talking about
> yesterday. What this would take is taking out all reference to signing and
> making core OAuth just about bare tokens, then have a separate spec that
> details what to call your shared secret parameters, how to get them, and how
> to sign with them. This makes the core spec a lot simpler (as detailed below)
> but makes the overall use case of using signed tokens more complicated to
> follow, as it'd be split in two.
>
>  -- justin
> ________________________________________
> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfanz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's proposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away with
> base string canonicalization, (2) allow for symmetric and public keys, and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposal by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAuth 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would
> work both with the signing mechanism in the current spec, as well as with
> Brian's signature mechanism). The goal of my proposal is twofold:
>
> - it simplifies the spec. It will become more readable and therefore easier to
> implement
> - it separates out the mechanisms for delegated authorization and for
> integrity protection into two independent pieces, which can be put together by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR access
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens from the
> spec.
> - stop calling the access tokens "bearer tokens". Call them just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_token then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes something like this:
>
> "Servers may require that requests be authenticated by the Client, so that
> presentation of the access token alone is not sufficient to access a Protected
> Resource.  This has several use cases, including, but not limited to, the
> following:
>
> - Non-repudiation: high-security deployments may require that requests be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that access tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure may
> strip SSL protection before the request reaches the protected resource. The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests, then
> the Client uses the following mechanism to sign their HTTP requests: [...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the client
> secret instead of the access token secret). Eventually, instead of Section
> 5.3, we may have Brian's new signature scheme section here, which would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achieved
> once we have public-key crypto.
>
> _______________________________________________
> 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



<ATT00001..txt>





_______________________________________________
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

--------------020807080905050105080906-- From mscurtescu@google.com Thu May 27 11:12:58 2010 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 2CE573A67EE for ; Thu, 27 May 2010 11:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.614 X-Spam-Level: X-Spam-Status: No, score=-104.614 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, 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 lQcWBnbOD0tU for ; Thu, 27 May 2010 11:12:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id EAF013A6939 for ; Thu, 27 May 2010 11:12:56 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o4RICkPF023707 for ; Thu, 27 May 2010 11:12:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274983967; bh=eP13DL8C9aOrFIrGvvJSlJK3MXs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wBJBDBSFnd88Ndo/Sxo+7G3Q48rvD5cau2Jd6rnImv4F0u1gyGAV/+ikBEtJCae4T 1FV1PzHMEa8Ekjk7ix6mg== 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=nUfya4t48Ct4l4lScCZzGlEzM1aCbDakTTjRPEVwcU56EsM0bh3xsETjAPzU9eQBs 5M3EigrwDNWyugF9YpNkw== Received: from pxi6 (pxi6.prod.google.com [10.243.27.6]) by kpbe17.cbf.corp.google.com with ESMTP id o4RICdAt019274 for ; Thu, 27 May 2010 11:12:45 -0700 Received: by pxi6 with SMTP id 6so176193pxi.1 for ; Thu, 27 May 2010 11:12:45 -0700 (PDT) Received: by 10.140.58.10 with SMTP id g10mr240592rva.85.1274983965388; Thu, 27 May 2010 11:12:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.2 with HTTP; Thu, 27 May 2010 11:12:25 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 27 May 2010 11:12:25 -0700 Message-ID: To: Nat Sakimura Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 27 May 2010 18:12:58 -0000 On Thu, May 27, 2010 at 11:06 AM, Nat Sakimura wrote: > On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu wrote: >> Thanks for the clarification Nat. >> >> Just curios, can't the phone client actually POST to the authz server? >> That would take care of the URL length limitation. > > POST means an extra click, which is a UI disaster. I assume self posting forms do not work on these devices? > Also, more data over the air means slower response. True, but the alternative is to have the authz server fetch the data from the web client, some cycles are lost there as well. >> In your diagram, the verification code is passed from UA to Web Client >> and then the Web Client is exchanging it for the access and refresh >> tokens. These tokens are never passed back to the UA, is that >> intended? Also, why can't the UA do the exchange directly? > > It is following the Web Server flow. > Apart from getting the request parameter through the request_url fetch > is almost exactly as in the Web Server flow. Sure, but who is the client in this case? Isn't the UA (aka phone) ultimately interested in having access tokens so it can make API calls? Marius From balfanz@google.com Thu May 27 11:32:51 2010 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 5F5F43A69FD for ; Thu, 27 May 2010 11:32:51 -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=[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 faOim0f5z-Xy for ; Thu, 27 May 2010 11:32:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5689E3A690E for ; Thu, 27 May 2010 11:32:48 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o4RIWbgP010541 for ; Thu, 27 May 2010 11:32:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274985158; bh=rw2lqqJT9Rh/rn1mdE5vZmuRKGo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=vUoR3iCJmbsgAi+8DFblbCLjj5leNiAUwtRKnJUeWjxtqKozlktm8wGSZmc2KjqcK rmD2RfpUH1xuGvO8ChRaA== 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=lEKt0UQUGgemEsiM06zN+mB6bzfY0jt/Rp2MtuXwSX7SkviDd0Hh+ZtwouU1nzfTj 03ekzPSPV3pt0m9/mru/w== Received: from pxi19 (pxi19.prod.google.com [10.243.27.19]) by hpaq1.eem.corp.google.com with ESMTP id o4RIWZbE021641 for ; Thu, 27 May 2010 11:32:36 -0700 Received: by pxi19 with SMTP id 19so153750pxi.31 for ; Thu, 27 May 2010 11:32:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.2.10 with SMTP id e10mr8198911rvi.240.1274985154105; Thu, 27 May 2010 11:32:34 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Thu, 27 May 2010 11:32:33 -0700 (PDT) In-Reply-To: <4BFEB5DC.9050705@aol.com> References: <4BFEB5DC.9050705@aol.com> Date: Thu, 27 May 2010 11:32:33 -0700 Message-ID: From: Dirk Balfanz To: George Fletcher Content-Type: multipart/alternative; boundary=000e0cd113b434515b0487979ddf X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 18:32:51 -0000 --000e0cd113b434515b0487979ddf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, May 27, 2010 at 11:11 AM, George Fletcher wrote: > Hmm... to me this says... > > Yahoo won't deploy PRs that require client_secret signatures, but may > have some internal apps where this is ok. > > So, to me that sounds like Yahoo is ok with client_secret based signature= s > as one way to sign the requests, but they don't want it to be the only wa= y. > > Well the other proposal that's coming down the pipe is to re-introduce so= me form of public key signatures (where the client secret is not a shared HMAC key, but a private RSA key). Those would have all the properties you mentio= n below, plus the benefit that the PRs don't need to know the AS's secrets. Dirk. > > > I would like to bring back what Dirk has said earlier in this thread... > > 1. Signing isn't about the token but rather about the message > 2. Signing provides message integrity > 3. Signing provides (or should allow for) proof of sender > > I'd like to add... > 4. Signing (combined with appropriate information in the AT) enables "rig= ht > to present" the token > > I think that for certain use cases, its critical that the PR be able to > ensure that the client is "authorized" to present the AT. This isn't > possible for bearer tokens. I also don't believe this hurts sub-delegatio= n > because the AS can create an AT that can be sub-delegated and when the > sub-delegate presents the AT, the PR can verify that the sub-delegate is > allowed to present that AT. > > Thanks, > George > > On 5/27/10 12:58 PM, Allen Tom wrote: > > The short summary is that Yahoo thinks that signatures should not be > required for most use cases. In the exceptional cases where signatures ar= e > required, then it should be up to the service provider (and not the clien= t) > to determine when they=92re required, and which signature algorithm is t= o be > used. Yahoo does not want to be forced to support signatures generated > using the client secret =96 we don=92t even want this to be an option for= the > overwhelming majority of our APIs. Due to the way services are deployed a= t > Yahoo, our security team feels that in general, having PR endpoints valid= ate > signatures computed using the client secret makes our overall system LESS > secure =96 since we=92d be forced to distribute client secrets to the PR > endpoints. Distributing the client secret to the PR endpoints is very > undesirable, since doing so requires that the PR endpoints have the same > level of security as the AS. > > Having a clean separation between the AS and the PR was one of the goals = of > Oauth-WRAP =96 and having the PR authenticate the client using the client > secret violates this goal. > > That being said, Yahoo does have private/internal APIs which require a ve= ry > high level of security in which bearer tokens are not sufficient, and > signatures using the AT secret aren=92t sufficient either =96 in these ca= ses, > signing the request with the client secret is probably the right way to g= o. > Again =96 this should be up to the SP to determine that a signature is > required, and how that signature is generated. > > So what I=92m trying to say is =96 yes there are cases where it=92s desir= able to > have stronger signatures than just signing with the AT secret =96 however= I > think that the cases in which signatures are required, and which signatur= e > algorithm is to be used should be entirely up to the SP. > > Does that clarify things? > Allen > > > > > On 5/27/10 9:04 AM, "Dirk Balfanz" wrote: > > > > On Thu, May 27, 2010 at 8:56 AM, David Recordon > wrote: > > I thought Allen clearly said that signing with the client secret won't wo= rk > for Yahoo!? > > > Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures > at all. So I think we're good from the Yahoo! side of things. > > Allen - did I get this right? > > Dirk. > > > > > Hi Dirk- > > We at Yahoo would be very much against using the client secret for signin= g > requests to Protected Resources, since this would require that the client > secret be distributed to the PR endpoints. For security reasons, one of t= he > design goals for WRAP was to keep the client secret a secret between only > the AS and the Client =96 deliberately separating the authentication of t= he > client (on the AS) from the serving of the protected resource. > > >From your post, it=92s not quite clear what the disadvantage is with usi= ng > the Access Token secret for generating signatures. > > (forgive me if this was already discussed today - I was very zonked out > after 3 days of IIW) > > Thanks > Allen > > > > On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz wrote: > > Sorry, I didn't mean to turn this into a debate over whether we should ha= ve > signatures. I think you guys stated your case clearly, and there are othe= r > use cases as well. > > The questions I was trying to figure out was whether > > - you'd be ok using the client secret to sign instead of the token secret > (I think I heard David say that that was ok), > - you'd be ok with a signature scheme that's sufficiently factored out of > the rest of the spec that it might warrant it's own companion spec (I agr= ee > that this is getting close to bikeshed territory, so let's worry about th= is > once we know what the signatures look like). > > Dirk. > > > On Wed, May 26, 2010 at 2:17 PM, Luke Shepard > wrote: > > So, when I argued for signatures, the specific use cases we are concerned > with: > > - Mobile handsets and networks that don't support SSL very well > - High-volume applications where SSL is a significant cost to both sides = - > for Facebook, the top few apps make up a significant amount of API traffi= c, > so we could do signatures for them and not for everyone else > > I expect that these are issues that others will encounter as they expand > into these areas- especially on the mobile side. These are not > Facebook-specific issues. > > That said, I agree with David that we should just figure out what the > signatures are - I don't really care where they live. If they need to liv= e > in a separate spec then whatever, as long as the specs interoperate very > cleanly. But I would like to hear from other mobile developers if they ha= ve > tried OAuth 2.0 with success (Brian, I think you mentioned you may have s= ome > data about that?) > > On May 26, 2010, at 11:20 AM, David Recordon wrote: > > How about we figure out the technical details of signatures before > figuring out where they're placed? :) > > > On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz wrote= : > > Ok - to those advocating a separate spec: What if the separate spec was > really simple (a couple of pages), and we just pasted it as "Section X" i= nto > the core OAuth spec? > > To Facebook: What if the core OAuth spec had a section called "Signed OAu= th > Requests" that (in its extreme form) had the single sentence: "If PRs > require signing, then Clients use the XYZ mechanism to sign their OAuth > requests" (with a link to XYZ)? > > Dirk. > > > On Wed, May 26, 2010 at 10:55 AM, David Recordon > wrote: > > I'd prefer that we keep signatures simple enough that they can remain in > the core spec. > > --David > > > > On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote= : > > Repeating what I said before: > > - separate spec is fine by me > - part of the point I'm trying to make is that that spec shouldn't be abo= ut > signed _tokens_, but instead about signed _HTTP requests_ (so instead of > merely proving that you know a secret that came with the token, you prov= e > who you are when you use the token). > > I'd be interested what the Facebook guys think about this - I believe the > current signature scheme is in there mostly to address a use case they ha= d. > > Luke, Dave - would a separate signing spec be ok with you guys? > > Dirk. > > > On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: > +1 > > I fully agree with Dirk and Brian that there needs to be some work on > signatures. There are many types of applications that require higher leve= ls > of security than what bearer tokens can provide. > > That being said, I think that bearer token/refresh token model can satisi= fy > the majority of use cases - in fact it would satisfy 100% of all public > APIs > that we have at Yahoo. > > Perhaps in the interest of keeping the spec focused, it would make more > sense to split out a Signed Token Spec, as Justin proposes, that is focus= ed > solely on uses cases that require a signature? > > Allen > > > > On 5/21/10 11:27 AM, "Richer, Justin P." wrote: > > > I have a slightly more radical proposal. What if we factor out the sign= ed > > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, > given > > the same attention by the group and all that like Eran was talking abou= t > > yesterday. What this would take is taking out all reference to signing > and > > making core OAuth just about bare tokens, then have a separate spec tha= t > > details what to call your shared secret parameters, how to get them, an= d > how > > to sign with them. This makes the core spec a lot simpler (as detailed > below) > > but makes the overall use case of using signed tokens more complicated = to > > follow, as it'd be split in two. > > > > -- justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > > Balfanz [balfanz@google.com] > > Sent: Thursday, May 20, 2010 7:39 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth= 2 > > > > Hi guys, > > > > at today's interim meeting, we were discussing Brian Eaton's proposal f= or > > OAuth signatures. He was proposing a mechanism that would (1) do away > with > > base string canonicalization, (2) allow for symmetric and public keys, > and (3) > > allow for extensibility. > > > > He got homework from the group to prove the feasibility of his proposal > by > > showing a couple of implementations. > > > > In this post, I would like to introduce another improvement of the OAut= h > 2 > > signing mechanism, one which is orthogonal to Brian's proposal (i.e., i= t > would > > work both with the signing mechanism in the current spec, as well as wi= th > > Brian's signature mechanism). The goal of my proposal is twofold: > > > > - it simplifies the spec. It will become more readable and therefore > easier to > > implement > > - it separates out the mechanisms for delegated authorization and for > > integrity protection into two independent pieces, which can be put > together by > > Servers and/or Clients like LEGO blocks. > > > > Summary: > > > > - use the client secret instead of the token secret for signing PR acce= ss > > requests. > > > > Long version of the proposal: > > > > - remove all references to access tokens that are not bearer tokens fro= m > the > > spec. > > - stop calling the access tokens "bearer tokens". Call them just "acces= s > > tokens". > > - remove all references to token secrets from the spec > > - remove all parts of the spec that are of the kind "if bearer_token th= en > X, > > else Y", and replace them with X. > > - delete section 5.3 > > - add a section called "Request Authentication" that goes something lik= e > this: > > > > "Servers may require that requests be authenticated by the Client, so > that > > presentation of the access token alone is not sufficient to access a > Protected > > Resource. This has several use cases, including, but not limited to, t= he > > following: > > > > - Non-repudiation: high-security deployments may require that requests = be > > authenticated (signed) in a non-repudiateable way[1] > > - Access to protected resources is not protected by SSL, so that access > tokens > > may leak. > > - End-to-end-integrity: even if SSL _is_ used, network infrastructure m= ay > > strip SSL protection before the request reaches the protected resource. > The > > protected resource, however, may require end-to-end integrity. > > > > If the Server requires that the Client authenticate PR access requests, > then > > the Client uses the following mechanism to sign their HTTP requests: > [...]" > > > > Then, we basically drop the old Section 5.3 here (except we use the > client > > secret instead of the access token secret). Eventually, instead of > Section > > 5.3, we may have Brian's new signature scheme section here, which would > add > > the option of public-key crypto[1], etc. > > > > What do you guys think? > > > > Dirk. > > > > [1] Technically speaking, the goal of non-repudiation can only be > achieved > > once we have public-key crypto. > > > > _______________________________________________ > > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --000e0cd113b434515b0487979ddf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, May 27, 2010 at 11:11 AM, George= Fletcher <gffletc= h@aol.com> wrote:
=20
Hmm... to me this says...
Yahoo won't deploy PRs that require client_secret signatures, but may have some internal apps where this is ok.

So, to me that sounds like Yahoo is ok with client_secret based signatures as one way to sign the requests, but they don't want it to be the only way.=A0
Well the other proposal that's coming down = the pipe is to re-introduce some form of public key signatures (where the c= lient secret is not a shared HMAC key, but a private RSA key). Those would = have all the properties you mention below, plus the benefit that the PRs do= n't need to know the AS's secrets.

Dirk.
=A0


I would like to bring back what Dirk has said earlier in this thread...

1. Signing isn't about the token but rather about the message
2. Signing provides message integrity
3. Signing provides (or should allow for) proof of sender

I'd like to add...
4. Signing (combined with appropriate information in the AT) enables "right to present" the token

I think that for certain use cases, its critical that the PR be able to ensure that the client is "authorized" to present the AT. This is= n't possible for bearer tokens. I also don't believe this hurts sub-delegation because the AS can create an AT that can be sub-delegated and when the sub-delegate presents the AT, the PR can verify that the sub-delegate is allowed to present that AT.

Thanks,
George

On 5/27/10 12:58 PM, Allen Tom wrote:
=20 The short summary is that Yahoo thinks that signatures should not be required for most use cases. In the exceptional cases where signatures are required, then it should be up to the service provider (and not the client) to determine when they=92re required, and =A0which signature algorithm is to be used. =A0Yahoo does not want to be forced to support signatures generated using the client secret =96 we don=92t even want this to be an option for the overwhelming majority of our APIs. Due to the way services are deployed at Yahoo, our security team feels that in general, having PR endpoints validate signatures computed using the client secret makes our overall system LESS secure =96 since we=92d be forced to distribute client secrets to the PR endpoints. Distributing the client secret to the PR endpoints is very undesirable, since doing so requires that the PR endpoints have the same level of security as the AS.

Having a clean separation between the AS and the PR was one of the goals of Oauth-WRAP =96 and having the PR authenticate the client using the client secret violates this goal.

That being said, Yahoo does have private/internal APIs which require a very high level of security in which bearer tokens are not sufficient, and signatures using the AT secret aren=92t sufficient either =96 in these cases, signing the request with the client secret is probably the right way to go. Again =96 this should be up to the SP to determine that a signature is required, and how that signature is generated.

So what I=92m trying to say is =96 yes there are cases where it=92s desirab= le to have stronger signatures than just signing with the AT secret =96 however I think that the cases in which signatures are required, and which signature algorithm is to be used should be entirely up to the SP.
Does that clarify things?
Allen




On 5/27/10 9:04 AM, "Dirk Balfanz" <balfanz@google.com> wrote:


On Thu, May 27, 2010 at 8:56 AM, David Recordon <recordond@gmail.com> wrote:
I thought Allen clearly said that signing with the client secret won't work for Yahoo!?

Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures at all. So I think we're good from the Yahoo! side of things.=A0

Allen - did I get this right?

Dirk.

=A0

Hi Dirk-

We at Yahoo would be very much against using the client secret for signing requests to Protected Resources, since this would require that the client secret be distributed to the PR endpoints. For security reasons, one of the design goals for WRAP was to keep the client secret a secret between only the AS and the Client =96 deliberately separating the authentication of the client (on the AS) from the serving of the protected resource.=A0

>From your post, it=92s not quite clear what the disadvantage is with using the Access Token secret for generating signatures.

(forgive me if this was already discussed today - I was very zonked out after 3 days of IIW)

Thanks
Allen


On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <balfanz@google.com> wrote:
Sorry, I didn't mean to turn this into a debate over whether we should have signatures. I think you guys stated your case clearly, and there are other use cases as well.=A0

The questions I was trying to figure out was whether=A0

- you'd be ok using the client secret to sign instead of the token secret (I think I heard David say that that was ok),=A0
- you'd be ok with a signature scheme that's sufficiently factored = out of the rest of the spec that it might warrant it's own companion spec (I agree that this is getting close to bikeshed territory, so let's worry about this once we know what the signatures look like).

Dirk.


On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <lshepard@facebook.com> wrote:
So, when I argued for signatures, the specific=A0use cases we are concerned with:

- Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - for Facebook, the top few apps make up a significant amount of API traffic, so we could do signatures for them and not for everyone else

I expect that these are issues that others will encounter as they expand into these areas- especially on the mobile side. These are not Facebook-specific issues.

That said, I agree with David that we should just figure out what the signatures are - I don't really care where they live. If they need to live in a separate spec then whatever, as long as the specs interoperate very cleanly. But I would like to hear from other mobile developers if they have tried OAuth 2.0 with success (Brian, I think you mentioned you may have some data about that?)

On May 26, 2010, at 11:20 AM, David Recordon wrote:
How about we figure out the technical details of signatures before figuring out where they're placed? :) </bikeshed>


On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balfanz@google.com> wrote:
<= span style=3D"font-size:11pt">Ok - to those advocating a separate spec: What if the separate spec was really simple (a couple of pages), and we just pasted it as "Section X" into the core OAuth spec?

To Facebook: What if the core OAuth spec had a section called "Signed OAuth Requests" that (in its extreme form) had the single sentence: &q= uot;If PRs require signing, then Clients use the XYZ mechanism to sign their OAuth requests" (with a link to XYZ)?

Dirk.


On Wed, May 26, 2010 at 10:55 AM, David Recordon <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simp= le enough that they can remain in the core spec.

--David



On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

- separate spec is fine by me
- part of the point I'm trying to make is that that spec shouldn't = be about signed _tokens_, but instead about signed _HTTP requests_ (so instead of merely proving that you know a secret that came with the token, you =A0prove who you are when you use the token).=A0

I'd be interested what the Facebook guys think about this - I believe the current signature scheme is in there mostly to address a use case they had.

Luke, Dave - would a separate signing spec be ok with you guys?

Dirk.


On Tue, May 25, 2010 at 6:56 PM, Allen Tom <atom@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify
the majority of use cases - in fact it would satisfy 100% of all public APIs
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the signed
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given
> the same attention by the group and all that like Eran was talking about
> yesterday. What this would take is taking out all reference to signing and
> making core OAuth just about bare tokens, then have a separate spec that
> details what to call your shared secret parameters, how to get them, and how
> to sign with them. This makes the core spec a lot simpler (as detailed below)
> but makes the overall use case of using signed tokens more complicated to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@= ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's proposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away with
> base string canonicalization, (2) allow for symmetric and public keys, and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposal by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAuth 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would
> work both with the signing mechanism in the current spec, as well as with
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore easier to
> implement
> - it separates out the mechanisms for delegated authorization and for
> integrity protection into two independent pieces, which can be put together by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR access
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens from the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_token then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes something like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a Protected
> Resource. =A0This has several use cases, including, but not limited to, the
> following:
>
> - Non-repudiation: high-security deployments may require that requests be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that access tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure may
> strip SSL protection before the request reaches the protected resource. The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests, then
> the Client uses the following mechanism to sign their HTTP requests: [...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the client
> secret instead of the access token secret). Eventually, instead of Section
> 5.3, we may have Brian's new signature scheme section here, which would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achieved
> once we have public-key crypto.
>
> _______________________________________________
> 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



<ATT00001..txt>





_______________________________________________
OAuth mailing list
OAuth@ietf.org<= br> https://www.ietf.org/mailman/listinfo/oauth

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


--000e0cd113b434515b0487979ddf-- From raffi@twitter.com Thu May 27 11:42:29 2010 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 13B9F3A6921 for ; Thu, 27 May 2010 11:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 F9GquWoMQm8r for ; Thu, 27 May 2010 11:42:27 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 53B3A3A684A for ; Thu, 27 May 2010 11:42:27 -0700 (PDT) Received: by pxi19 with SMTP id 19so158526pxi.31 for ; Thu, 27 May 2010 11:42:14 -0700 (PDT) Received: by 10.140.58.11 with SMTP id g11mr8316259rva.210.1274985733747; Thu, 27 May 2010 11:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.144.9 with HTTP; Thu, 27 May 2010 11:41:53 -0700 (PDT) In-Reply-To: References: From: Raffi Krikorian Date: Thu, 27 May 2010 11:41:53 -0700 Message-ID: To: David Recordon Content-Type: multipart/alternative; boundary=001636b2ac33c11173048797bff2 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 18:42:29 -0000 --001636b2ac33c11173048797bff2 Content-Type: text/plain; charset=ISO-8859-1 sorry to jump in late here - but i would also be interested in making signatures simple(r) to keep them in the core spec. i would be very interested in helping out on that front if need be. On Wed, May 26, 2010 at 10:55 AM, David Recordon wrote: > I'd prefer that we keep signatures simple enough that they can remain in > the core spec. > > --David > > > > On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote: > >> Repeating what I said before: >> >> - separate spec is fine by me >> - part of the point I'm trying to make is that that spec shouldn't be >> about signed _tokens_, but instead about signed _HTTP requests_ (so instead >> of merely proving that you know a secret that came with the token, you >> prove who you are when you use the token). >> >> I'd be interested what the Facebook guys think about this - I believe the >> current signature scheme is in there mostly to address a use case they had. >> >> Luke, Dave - would a separate signing spec be ok with you guys? >> >> Dirk. >> >> >> On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: >> >>> +1 >>> >>> I fully agree with Dirk and Brian that there needs to be some work on >>> signatures. There are many types of applications that require higher >>> levels >>> of security than what bearer tokens can provide. >>> >>> That being said, I think that bearer token/refresh token model can >>> satisify >>> the majority of use cases - in fact it would satisfy 100% of all public >>> APIs >>> that we have at Yahoo. >>> >>> Perhaps in the interest of keeping the spec focused, it would make more >>> sense to split out a Signed Token Spec, as Justin proposes, that is >>> focused >>> solely on uses cases that require a signature? >>> >>> Allen >>> >>> >>> >>> On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >>> >>> > I have a slightly more radical proposal. What if we factor out the >>> signed >>> > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, >>> given >>> > the same attention by the group and all that like Eran was talking >>> about >>> > yesterday. What this would take is taking out all reference to signing >>> and >>> > making core OAuth just about bare tokens, then have a separate spec >>> that >>> > details what to call your shared secret parameters, how to get them, >>> and how >>> > to sign with them. This makes the core spec a lot simpler (as detailed >>> below) >>> > but makes the overall use case of using signed tokens more complicated >>> to >>> > follow, as it'd be split in two. >>> > >>> > -- justin >>> > ________________________________________ >>> > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of >>> Dirk >>> > Balfanz [balfanz@google.com] >>> > Sent: Thursday, May 20, 2010 7:39 PM >>> > To: OAuth WG >>> > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth >>> 2 >>> > >>> > Hi guys, >>> > >>> > at today's interim meeting, we were discussing Brian Eaton's proposal >>> for >>> > OAuth signatures. He was proposing a mechanism that would (1) do away >>> with >>> > base string canonicalization, (2) allow for symmetric and public keys, >>> and (3) >>> > allow for extensibility. >>> > >>> > He got homework from the group to prove the feasibility of his proposal >>> by >>> > showing a couple of implementations. >>> > >>> > In this post, I would like to introduce another improvement of the >>> OAuth 2 >>> > signing mechanism, one which is orthogonal to Brian's proposal (i.e., >>> it would >>> > work both with the signing mechanism in the current spec, as well as >>> with >>> > Brian's signature mechanism). The goal of my proposal is twofold: >>> > >>> > - it simplifies the spec. It will become more readable and therefore >>> easier to >>> > implement >>> > - it separates out the mechanisms for delegated authorization and for >>> > integrity protection into two independent pieces, which can be put >>> together by >>> > Servers and/or Clients like LEGO blocks. >>> > >>> > Summary: >>> > >>> > - use the client secret instead of the token secret for signing PR >>> access >>> > requests. >>> > >>> > Long version of the proposal: >>> > >>> > - remove all references to access tokens that are not bearer tokens >>> from the >>> > spec. >>> > - stop calling the access tokens "bearer tokens". Call them just >>> "access >>> > tokens". >>> > - remove all references to token secrets from the spec >>> > - remove all parts of the spec that are of the kind "if bearer_token >>> then X, >>> > else Y", and replace them with X. >>> > - delete section 5.3 >>> > - add a section called "Request Authentication" that goes something >>> like this: >>> > >>> > "Servers may require that requests be authenticated by the Client, so >>> that >>> > presentation of the access token alone is not sufficient to access a >>> Protected >>> > Resource. This has several use cases, including, but not limited to, >>> the >>> > following: >>> > >>> > - Non-repudiation: high-security deployments may require that requests >>> be >>> > authenticated (signed) in a non-repudiateable way[1] >>> > - Access to protected resources is not protected by SSL, so that access >>> tokens >>> > may leak. >>> > - End-to-end-integrity: even if SSL _is_ used, network infrastructure >>> may >>> > strip SSL protection before the request reaches the protected resource. >>> The >>> > protected resource, however, may require end-to-end integrity. >>> > >>> > If the Server requires that the Client authenticate PR access requests, >>> then >>> > the Client uses the following mechanism to sign their HTTP requests: >>> [...]" >>> > >>> > Then, we basically drop the old Section 5.3 here (except we use the >>> client >>> > secret instead of the access token secret). Eventually, instead of >>> Section >>> > 5.3, we may have Brian's new signature scheme section here, which would >>> add >>> > the option of public-key crypto[1], etc. >>> > >>> > What do you guys think? >>> > >>> > Dirk. >>> > >>> > [1] Technically speaking, the goal of non-repudiation can only be >>> achieved >>> > once we have public-key crypto. >>> > >>> > _______________________________________________ >>> > 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 > > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi --001636b2ac33c11173048797bff2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sorry to jump in late here - but i would also be interested in making signa= tures simple(r) to keep them in the core spec. =A0i would be very intereste= d in helping out on that front if need be.

On Wed, May 26, 2010 at 10:55 AM, David Recordon <recordond@gmail.com> wrote= :
I'd prefer that we keep signatures simple enough that they can remain i= n the core spec.

--David



On W= ed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

=
- separate spec is fine by me
- part of the point I'm tr= ying to make is that that spec shouldn't be about signed _tokens_, but = instead about signed _HTTP requests_ (so instead of merely proving that you= know a secret that came with the token, you =A0prove who you are when you = use the token).=A0

I'd be interested what the Facebook guys think abou= t this - I believe the current signature scheme is in there mostly to addre= ss a use case they had.

Luke, Dave - would a separ= ate signing spec be ok with you guys?

Dirk.


<= div class=3D"gmail_quote">On Tue, May 25, 2010 at 6:56 PM, Allen Tom <ato= m@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
> =A0-- justin
> ________________________________________
> From: oaut= h-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfa= nz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's p= roposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.= e., it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:<= br> >
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= br> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource. =A0This has several use cases, including, but not limited to= , the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which = would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _____________________________________= __________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth



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



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




--
Raffi Krikorian
= Twitter Platform Team
http://twitte= r.com/raffi
--001636b2ac33c11173048797bff2-- From dick.hardt@gmail.com Thu May 27 12:14:17 2010 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 287DE3A6B7B for ; Thu, 27 May 2010 12:14:17 -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, 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 OPshb6yVOPsZ for ; Thu, 27 May 2010 12:14:01 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id F3BCB3A696B for ; Thu, 27 May 2010 12:13:45 -0700 (PDT) Received: by ywh3 with SMTP id 3so39427ywh.31 for ; Thu, 27 May 2010 12:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=HYIOm2oSP1dWykTvdL0TCnD/2Efu3igt724pi84EjeI=; b=Dag5ESS4OVmxgw+eOS3h8iIYKh89AmY82gorwiTrs9q9X0bjy/prqFOdMQLrLaGy18 XZpoz1ha3MFNpWLPzBqnagnf7pgYZ219rcJ6J7ZJ1VZkVyAKiIDWxoLK1/IhHijlZt3B g8b0F3m62G9T8QzvVuwCdL58eCzsWVc4ycf/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=OFZ6uLl/u5s61lPUAfg4dgQBXmz+X/Cg6RDpm/nanDR2y8pP39VMMyGsbrvIFu0F/7 D6EpuwaqKo69MacyIahkVQxBk2XNo1LlxtPUbJIdUgO5rzhJnJFY0L/4CkCdDmsybhya 6KstxIA1zFhPcvgZv7Qqa1RAhqkMjROrtvgog= Received: by 10.231.185.86 with SMTP id cn22mr9256940ibb.69.1274987612593; Thu, 27 May 2010 12:13:32 -0700 (PDT) Received: from [192.168.159.21] ([38.109.197.2]) by mx.google.com with ESMTPS id f1sm6843807ibg.9.2010.05.27.12.13.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 May 2010 12:13:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-48-327665899 From: Dick Hardt In-Reply-To: Date: Thu, 27 May 2010 13:13:29 -0600 Message-Id: <0299E561-B14F-4A7C-8913-F8CBD374C826@gmail.com> References: To: Raffi Krikorian X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 19:14:18 -0000 --Apple-Mail-48-327665899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Raffi: would you care to elaborate on Twittter's use case? On 2010-05-27, at 12:41 PM, Raffi Krikorian wrote: > sorry to jump in late here - but i would also be interested in making = signatures simple(r) to keep them in the core spec. i would be very = interested in helping out on that front if need be. >=20 > On Wed, May 26, 2010 at 10:55 AM, David Recordon = wrote: > I'd prefer that we keep signatures simple enough that they can remain = in the core spec. >=20 > --David >=20 >=20 >=20 > On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz = wrote: > Repeating what I said before: >=20 > - separate spec is fine by me > - part of the point I'm trying to make is that that spec shouldn't be = about signed _tokens_, but instead about signed _HTTP requests_ (so = instead of merely proving that you know a secret that came with the = token, you prove who you are when you use the token).=20 >=20 > I'd be interested what the Facebook guys think about this - I believe = the current signature scheme is in there mostly to address a use case = they had. >=20 > Luke, Dave - would a separate signing spec be ok with you guys? >=20 > Dirk. >=20 >=20 > On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: > +1 >=20 > I fully agree with Dirk and Brian that there needs to be some work on > signatures. There are many types of applications that require higher = levels > of security than what bearer tokens can provide. >=20 > That being said, I think that bearer token/refresh token model can = satisify > the majority of use cases - in fact it would satisfy 100% of all = public APIs > that we have at Yahoo. >=20 > Perhaps in the interest of keeping the spec focused, it would make = more > sense to split out a Signed Token Spec, as Justin proposes, that is = focused > solely on uses cases that require a signature? >=20 > Allen >=20 >=20 >=20 > On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >=20 > > I have a slightly more radical proposal. What if we factor out the = signed > > token use case into a parallel spec? The OAuth 2.0 Signed Token = spec, given > > the same attention by the group and all that like Eran was talking = about > > yesterday. What this would take is taking out all reference to = signing and > > making core OAuth just about bare tokens, then have a separate spec = that > > details what to call your shared secret parameters, how to get them, = and how > > to sign with them. This makes the core spec a lot simpler (as = detailed below) > > but makes the overall use case of using signed tokens more = complicated to > > follow, as it'd be split in two. > > > > -- justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of = Dirk > > Balfanz [balfanz@google.com] > > Sent: Thursday, May 20, 2010 7:39 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposal for factoring out request signing in = OAuth 2 > > > > Hi guys, > > > > at today's interim meeting, we were discussing Brian Eaton's = proposal for > > OAuth signatures. He was proposing a mechanism that would (1) do = away with > > base string canonicalization, (2) allow for symmetric and public = keys, and (3) > > allow for extensibility. > > > > He got homework from the group to prove the feasibility of his = proposal by > > showing a couple of implementations. > > > > In this post, I would like to introduce another improvement of the = OAuth 2 > > signing mechanism, one which is orthogonal to Brian's proposal = (i.e., it would > > work both with the signing mechanism in the current spec, as well as = with > > Brian's signature mechanism). The goal of my proposal is twofold: > > > > - it simplifies the spec. It will become more readable and therefore = easier to > > implement > > - it separates out the mechanisms for delegated authorization and = for > > integrity protection into two independent pieces, which can be put = together by > > Servers and/or Clients like LEGO blocks. > > > > Summary: > > > > - use the client secret instead of the token secret for signing PR = access > > requests. > > > > Long version of the proposal: > > > > - remove all references to access tokens that are not bearer tokens = from the > > spec. > > - stop calling the access tokens "bearer tokens". Call them just = "access > > tokens". > > - remove all references to token secrets from the spec > > - remove all parts of the spec that are of the kind "if bearer_token = then X, > > else Y", and replace them with X. > > - delete section 5.3 > > - add a section called "Request Authentication" that goes something = like this: > > > > "Servers may require that requests be authenticated by the Client, = so that > > presentation of the access token alone is not sufficient to access a = Protected > > Resource. This has several use cases, including, but not limited = to, the > > following: > > > > - Non-repudiation: high-security deployments may require that = requests be > > authenticated (signed) in a non-repudiateable way[1] > > - Access to protected resources is not protected by SSL, so that = access tokens > > may leak. > > - End-to-end-integrity: even if SSL _is_ used, network = infrastructure may > > strip SSL protection before the request reaches the protected = resource. The > > protected resource, however, may require end-to-end integrity. > > > > If the Server requires that the Client authenticate PR access = requests, then > > the Client uses the following mechanism to sign their HTTP requests: = [...]" > > > > Then, we basically drop the old Section 5.3 here (except we use the = client > > secret instead of the access token secret). Eventually, instead of = Section > > 5.3, we may have Brian's new signature scheme section here, which = would add > > the option of public-key crypto[1], etc. > > > > What do you guys think? > > > > Dirk. > > > > [1] Technically speaking, the goal of non-repudiation can only be = achieved > > once we have public-key crypto. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > Raffi Krikorian > Twitter Platform Team > http://twitter.com/raffi > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-48-327665899 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Raffi: would you care to elaborate on Twittter's use case?

On 2010-05-27, at 12:41 PM, Raffi Krikorian wrote:

sorry to jump in late here - but i would also be interested in making signatures simple(r) to keep them in the core spec.  i would be very interested in helping out on that front if need be.

On Wed, May 26, 2010 at 10:55 AM, David Recordon <recordond@gmail.com> wrote:
I'd prefer that we keep signatures simple enough that they can remain in the core spec.

--David



On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
Repeating what I said before:

- separate spec is fine by me
- part of the point I'm trying to make is that that spec shouldn't be about signed _tokens_, but instead about signed _HTTP requests_ (so instead of merely proving that you know a secret that came with the token, you  prove who you are when you use the token). 

I'd be interested what the Facebook guys think about this - I believe the current signature scheme is in there mostly to address a use case they had.

Luke, Dave - would a separate signing spec be ok with you guys?

Dirk.


On Tue, May 25, 2010 at 6:56 PM, Allen Tom <atom@yahoo-inc.com> wrote:
+1

I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels
of security than what bearer tokens can provide.

That being said, I think that bearer token/refresh token model can satisify
the majority of use cases - in fact it would satisfy 100% of all public APIs
that we have at Yahoo.

Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused
solely on uses cases that require a signature?

Allen



On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:

> I have a slightly more radical proposal. What if we factor out the signed
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given
> the same attention by the group and all that like Eran was talking about
> yesterday. What this would take is taking out all reference to signing and
> making core OAuth just about bare tokens, then have a separate spec that
> details what to call your shared secret parameters, how to get them, and how
> to sign with them. This makes the core spec a lot simpler (as detailed below)
> but makes the overall use case of using signed tokens more complicated to
> follow, as it'd be split in two.
>
>  -- justin
> ________________________________________
> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfanz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's proposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away with
> base string canonicalization, (2) allow for symmetric and public keys, and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposal by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAuth 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would
> work both with the signing mechanism in the current spec, as well as with
> Brian's signature mechanism). The goal of my proposal is twofold:
>
> - it simplifies the spec. It will become more readable and therefore easier to
> implement
> - it separates out the mechanisms for delegated authorization and for
> integrity protection into two independent pieces, which can be put together by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR access
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens from the
> spec.
> - stop calling the access tokens "bearer tokens". Call them just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_token then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes something like this:
>
> "Servers may require that requests be authenticated by the Client, so that
> presentation of the access token alone is not sufficient to access a Protected
> Resource.  This has several use cases, including, but not limited to, the
> following:
>
> - Non-repudiation: high-security deployments may require that requests be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that access tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure may
> strip SSL protection before the request reaches the protected resource. The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests, then
> the Client uses the following mechanism to sign their HTTP requests: [...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the client
> secret instead of the access token secret). Eventually, instead of Section
> 5.3, we may have Brian's new signature scheme section here, which would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achieved
> once we have public-key crypto.
>
> _______________________________________________
> 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




--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-48-327665899-- From atom@yahoo-inc.com Thu May 27 13:12:24 2010 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 923763A6965 for ; Thu, 27 May 2010 13:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.12 X-Spam-Level: X-Spam-Status: No, score=-15.12 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] 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 2+BdCu5flnSo for ; Thu, 27 May 2010 13:12:08 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id C2C563A672E for ; Thu, 27 May 2010 13:12:07 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o4RK9LYm029411; Thu, 27 May 2010 13:09:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:cc:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: return-path:x-originalarrivaltime; b=zZPC+pGqJ3bplFSt5NLzT9ZsucqgXZ8pkrm8hYHcD93gaTWwaeJIIUFiw+LLSOlV Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 13:09:21 -0700 Received: from 10.72.181.200 ([10.72.181.200]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 May 2010 20:08:53 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 27 May 2010 13:08:48 -0700 From: Allen Tom To: George Fletcher Message-ID: Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr92GrM0r1ZQiKro02j6l3jJAjfEQ== In-Reply-To: <4BFEB5DC.9050705@aol.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3357810531_42965087" X-OriginalArrivalTime: 27 May 2010 20:09:21.0728 (UTC) FILETIME=[7EE68400:01CAFDD8] Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 20:12:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3357810531_42965087 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi George, The really short summary is that Yahoo is fine with client based signatures being in the spec, although we do not want Service Providers to be obligate= d to support them. The decision as to whether or not signatures should be used, and which signature algorithm to use should be up to the Service Provider. We are very strongly against signatures generated using the client secret for the overwhelming majority of our APIs =AD which is why we want the signature algorithm to be chosen by the SP. A signature using the Access Token secret (without the client secret) is OK, although it=B9s unnecessary for our applications. A plain bearer token by itself (provided that it=B9s only valid for about an hour) is sufficient for all of Yahoo=B9s services =AD even without HTTPS. We=B9d rather increase security by deploying HTTPS rathe= r than requiring developers to sign their requests. Thanks Allen On 5/27/10 11:11 AM, "George Fletcher" wrote: > Hmm... to me this says... >=20 >> Yahoo won't deploy PRs that require client_secret signatures, but may ha= ve >> some internal apps where this is ok. >> =20 >> So, to me that sounds like Yahoo is ok with client_secret based signatu= res >> as one way to sign the requests, but they don't want it to be the only w= ay. >=20 > I would like to bring back what Dirk has said earlier in this thread... >=20 > 1. Signing isn't about the token but rather about the message > 2. Signing provides message integrity > 3. Signing provides (or should allow for) proof of sender >=20 > I'd like to add... > 4. Signing (combined with appropriate information in the AT) enables "rig= ht to > present" the token >=20 > I think that for certain use cases, its critical that the PR be able to e= nsure > that the client is "authorized" to present the AT. This isn't possible fo= r > bearer tokens. I also don't believe this hurts sub-delegation because the= AS > can create an AT that can be sub-delegated and when the sub-delegate pres= ents > the AT, the PR can verify that the sub-delegate is allowed to present tha= t AT. >=20 > Thanks, > George >=20 > On 5/27/10 12:58 PM, Allen Tom wrote: >> Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Th= e >> short summary is that Yahoo thinks that signatures should not be require= d for >> most use cases. In the exceptional cases where signatures are required, = then >> it should be up to the service provider (and not the client) to determin= e >> when they=B9re required, and which signature algorithm is to be used. Ya= hoo >> does not want to be forced to support signatures generated using the cli= ent >> secret =AD we don=B9t even want this to be an option for the overwhelming >> majority of our APIs. Due to the way services are deployed at Yahoo, our >> security team feels that in general, having PR endpoints validate signat= ures >> computed using the client secret makes our overall system LESS secure =AD = since >> we=B9d be forced to distribute client secrets to the PR endpoints. Distrib= uting >> the client secret to the PR endpoints is very undesirable, since doing s= o >> requires that the PR endpoints have the same level of security as the AS= . >> =20 >> Having a clean separation between the AS and the PR was one of the goals= of >> Oauth-WRAP =AD and having the PR authenticate the client using the client >> secret violates this goal. >> =20 >> That being said, Yahoo does have private/internal APIs which require a v= ery >> high level of security in which bearer tokens are not sufficient, and >> signatures using the AT secret aren=B9t sufficient either =AD in these cases= , >> signing the request with the client secret is probably the right way to = go. >> Again =AD this should be up to the SP to determine that a signature is >> required, and how that signature is generated. >> =20 >> So what I=B9m trying to say is =AD yes there are cases where it=B9s desirable = to >> have stronger signatures than just signing with the AT secret =AD however = I >> think that the cases in which signatures are required, and which signatu= re >> algorithm is to be used should be entirely up to the SP. >> =20 >> Does that clarify things? >> Allen >> =20 >> =20 >> =20 >> =20 >> On 5/27/10 9:04 AM, "Dirk Balfanz" wrote: >> =20 >> =20 >>>=20 >>> =20 >>> On Thu, May 27, 2010 at 8:56 AM, David Recordon w= rote: >>> =20 >>>> I thought Allen clearly said that signing with the client secret won't= work >>>> for Yahoo!? >>>> =20 >>> =20 >>> Right - but he also said that they (i.e. Yahoo!) wouldn't need signatur= es at >>> all. So I think we're good from the Yahoo! side of things. >>> =20 >>> Allen - did I get this right? >>> =20 >>> Dirk. >>> =20 >>> =20 >>> =20 >>>>=20 >>>> =20 >>>>> Hi Dirk- >>>>> =20 >>>>> We at Yahoo would be very much against using the client secret for si= gning >>>>> requests to Protected Resources, since this would require that the cl= ient >>>>> secret be distributed to the PR endpoints. For security reasons, one = of >>>>> the design goals for WRAP was to keep the client secret a secret betw= een >>>>> only the AS and the Client =AD deliberately separating the authenticati= on of >>>>> the client (on the AS) from the serving of the protected resource. >>>>> =20 >>>>>> >From your post, it=B9s not quite clear what the disadvantage is with = using >>>>>> the Access Token secret for generating signatures. >>>>> =20 >>>>> (forgive me if this was already discussed today - I was very zonked o= ut >>>>> after 3 days of IIW) >>>>> =20 >>>>> Thanks >>>>> Allen >>>>> =20 >>>> =20 >>>> =20 >>>> On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz wro= te: >>>> =20 >>>>> Sorry, I didn't mean to turn this into a debate over whether we shoul= d >>>>> have signatures. I think you guys stated your case clearly, and there= are >>>>> other use cases as well. >>>>> =20 >>>>> The questions I was trying to figure out was whether >>>>> =20 >>>>> - you'd be ok using the client secret to sign instead of the token se= cret >>>>> (I think I heard David say that that was ok), >>>>> - you'd be ok with a signature scheme that's sufficiently factored ou= t of >>>>> the rest of the spec that it might warrant it's own companion spec (I >>>>> agree that this is getting close to bikeshed territory, so let's worr= y >>>>> about this once we know what the signatures look like). >>>>> =20 >>>>> Dirk. >>>>> =20 >>>>> =20 >>>>> On Wed, May 26, 2010 at 2:17 PM, Luke Shepard >>>>> wrote: >>>>> =20 >>>>>> So, when I argued for signatures, the specific use cases we are conc= erned >>>>>> with: >>>>>> =20 >>>>>> - Mobile handsets and networks that don't support SSL very well >>>>>> - High-volume applications where SSL is a significant cost to both s= ides >>>>>> - for Facebook, the top few apps make up a significant amount of API >>>>>> traffic, so we could do signatures for them and not for everyone els= e >>>>>> =20 >>>>>> I expect that these are issues that others will encounter as they ex= pand >>>>>> into these areas- especially on the mobile side. These are not >>>>>> Facebook-specific issues. >>>>>> =20 >>>>>> That said, I agree with David that we should just figure out what th= e >>>>>> signatures are - I don't really care where they live. If they need t= o >>>>>> live in a separate spec then whatever, as long as the specs interope= rate >>>>>> very cleanly. But I would like to hear from other mobile developers = if >>>>>> they have tried OAuth 2.0 with success (Brian, I think you mentioned= you >>>>>> may have some data about that?) >>>>>> =20 >>>>>> On May 26, 2010, at 11:20 AM, David Recordon wrote: >>>>>> =20 >>>>>> =20 >>>>>>> How about we figure out the technical details of signatures before >>>>>>> figuring out where they're placed? :) >>>>>>> =20 >>>>>>> =20 >>>>>>> On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz >>>>>>> wrote: >>>>>>> =20 Ok - to those advocating a separate spec: What if the separate spec was really simple (a couple of pages), and we just pasted it as "Section X" int= o the core OAuth spec? =20 To Facebook: What if the core OAuth spec had a section called "Signed OAuth Requests" that (in its extreme form) had the single sentence: "If PRs require signing, then Clients use the XYZ mechanism to sign their OAuth requests" (with a link to XYZ)? =20 Dirk. =20 =20 On Wed, May 26, 2010 at 10:55 AM, David Recordon wrote: =20 I'd prefer that we keep signatures simple enough that they can remain in th= e core spec. =20 --David =20 =20 =20 On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote: =20 =20 >>>>>>> =20 >>>>>> =20 >>>>> =20 >>>> =20 >>> =20 >> Repeating what I said before: >> =20 >> - separate spec is fine by me >> - part of the point I'm trying to make is that that spec shouldn't be ab= out >> signed _tokens_, but instead about signed _HTTP requests_ (so instead of >> merely proving that you know a secret that came with the token, you pro= ve >> who you are when you use the token). >> =20 >> I'd be interested what the Facebook guys think about this - I believe th= e >> current signature scheme is in there mostly to address a use case they h= ad. >> =20 >> Luke, Dave - would a separate signing spec be ok with you guys? >> =20 >> Dirk. >> =20 >> =20 >> On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: >> +1 >> =20 >> I fully agree with Dirk and Brian that there needs to be some work on >> signatures. There are many types of applications that require higher lev= els >> of security than what bearer tokens can provide. >> =20 >> That being said, I think that bearer token/refresh token model can satis= ify >> the majority of use cases - in fact it would satisfy 100% of all public = APIs >> that we have at Yahoo. >> =20 >> Perhaps in the interest of keeping the spec focused, it would make more >> sense to split out a Signed Token Spec, as Justin proposes, that is focu= sed >> solely on uses cases that require a signature? >> =20 >> Allen >> =20 >> =20 >> =20 >> On 5/21/10 11:27 AM, "Richer, Justin P." wrote: >> =20 >>> > I have a slightly more radical proposal. What if we factor out the si= gned >>> > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, >>> given >>> > the same attention by the group and all that like Eran was talking ab= out >>> > yesterday. What this would take is taking out all reference to signin= g and >>> > making core OAuth just about bare tokens, then have a separate spec t= hat >>> > details what to call your shared secret parameters, how to get them, = and >>> how >>> > to sign with them. This makes the core spec a lot simpler (as detaile= d >>> below) >>> > but makes the overall use case of using signed tokens more complicate= d to >>> > follow, as it'd be split in two. >>> > >>> > -- justin >>> > ________________________________________ >>> > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Di= rk >>> > Balfanz [balfanz@google.com] >>> > Sent: Thursday, May 20, 2010 7:39 PM >>> > To: OAuth WG >>> > Subject: [OAUTH-WG] proposal for factoring out request signing in OAu= th 2 >>> > >>> > Hi guys, >>> > >>> > at today's interim meeting, we were discussing Brian Eaton's proposal= for >>> > OAuth signatures. He was proposing a mechanism that would (1) do away= with >>> > base string canonicalization, (2) allow for symmetric and public keys= , and >>> (3) >>> > allow for extensibility. >>> > >>> > He got homework from the group to prove the feasibility of his propos= al by >>> > showing a couple of implementations. >>> > >>> > In this post, I would like to introduce another improvement of the OA= uth 2 >>> > signing mechanism, one which is orthogonal to Brian's proposal (i.e.,= it >>> would >>> > work both with the signing mechanism in the current spec, as well as = with >>> > Brian's signature mechanism). The goal of my proposal is twofold: >>> > >>> > - it simplifies the spec. It will become more readable and therefore >>> easier to >>> > implement >>> > - it separates out the mechanisms for delegated authorization and for >>> > integrity protection into two independent pieces, which can be put >>> together by >>> > Servers and/or Clients like LEGO blocks. >>> > >>> > Summary: >>> > >>> > - use the client secret instead of the token secret for signing PR ac= cess >>> > requests. >>> > >>> > Long version of the proposal: >>> > >>> > - remove all references to access tokens that are not bearer tokens f= rom >>> the >>> > spec. >>> > - stop calling the access tokens "bearer tokens". Call them just "acc= ess >>> > tokens". >>> > - remove all references to token secrets from the spec >>> > - remove all parts of the spec that are of the kind "if bearer_token = then >>> X, >>> > else Y", and replace them with X. >>> > - delete section 5.3 >>> > - add a section called "Request Authentication" that goes something l= ike >>> this: >>> > >>> > "Servers may require that requests be authenticated by the Client, so= that >>> > presentation of the access token alone is not sufficient to access a >>> Protected >>> > Resource. This has several use cases, including, but not limited to,= the >>> > following: >>> > >>> > - Non-repudiation: high-security deployments may require that request= s be >>> > authenticated (signed) in a non-repudiateable way[1] >>> > - Access to protected resources is not protected by SSL, so that acce= ss >>> tokens >>> > may leak. >>> > - End-to-end-integrity: even if SSL _is_ used, network infrastructure= may >>> > strip SSL protection before the request reaches the protected resourc= e. >>> The >>> > protected resource, however, may require end-to-end integrity. >>> > >>> > If the Server requires that the Client authenticate PR access request= s, >>> then >>> > the Client uses the following mechanism to sign their HTTP requests: >>> [...]" >>> > >>> > Then, we basically drop the old Section 5.3 here (except we use the c= lient >>> > secret instead of the access token secret). Eventually, instead of Se= ction >>> > 5.3, we may have Brian's new signature scheme section here, which wou= ld >>> add >>> > the option of public-key crypto[1], etc. >>> > >>> > What do you guys think? >>> > >>> > Dirk. >>> > >>> > [1] Technically speaking, the goal of non-repudiation can only be ach= ieved >>> > once we have public-key crypto. >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> =20 >>> =20 >>>> =20 >>>>> =20 >>>>>> =20 >>>>>>> =20 =20 =20 =20 =20 >>>>>>> =20 >>>>>>> >>>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>>> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >> =20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --B_3357810531_42965087 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2= Hi George,

The really short summary is that Yahoo is fine with client based signatures= being in the spec, although we do not want Service Providers to be obligate= d to support them. The decision as to whether or not signatures should be us= ed, and which signature algorithm to use should be up to the Service Provide= r.

We are very strongly against signatures generated using the client secret f= or the overwhelming majority of our APIs – which is why we want the si= gnature algorithm to be chosen by the SP. A signature using the Access Token= secret (without the client secret) is OK, although it’s unnecessary f= or our applications.  A plain bearer token by itself (provided that it&= #8217;s only valid for about an hour) is sufficient for all of Yahoo’s= services – even without HTTPS.  We’d rather increase secur= ity by deploying HTTPS rather than requiring developers to sign their reques= ts.

Thanks
Allen


On 5/27/10 11:11 AM, "George Fletcher" <gffletch@aol.com> wrote:

Hmm... to me this says...

Yahoo won't deploy PRs that require client_secret signatu= res, but may have some internal apps where this is ok.
 So, to me that sounds l= ike Yahoo is ok with client_secret based signatures as one way to sign the r= equests, but they don't want it to be the only way.

I would like to bring back what Dirk has said earlier in this thread...

1. Signing isn't about the token but rather about the message
2. Signing provides message integrity
3. Signing provides (or should allow for) proof of sender

I'd like to add...
4. Signing (combined with appropriate information in the AT) enables "= right to present" the token

I think that for certain use cases, its critical that the PR be able to ens= ure that the client is "authorized" to present the AT. This isn't = possible for bearer tokens. I also don't believe this hurts sub-delegation b= ecause the AS can create an AT that can be sub-delegated and when the sub-de= legate presents the AT, the PR can verify that the sub-delegate is allowed t= o present that AT.

Thanks,
George

On 5/27/10 12:58 PM, Allen Tom wrote:
Re: [OAUTH-WG] proposal for factoring out reque= st signing in OAuth 2 The short summary is that Yahoo thinks that signatures= should not be required for most use cases. In the exceptional cases where s= ignatures are required, then it should be up to the service provider (and no= t the client) to determine when they’re required, and  which sign= ature algorithm is to be used.  Yahoo does not want to be forced to sup= port signatures generated using the client secret – we don’t eve= n want this to be an option for the overwhelming majority of our APIs. Due t= o the way services are deployed at Yahoo, our security team feels that in ge= neral, having PR endpoints validate signatures computed using the client sec= ret makes our overall system LESS secure – since we’d be forced = to distribute client secrets to the PR endpoints. Distributing the client se= cret to the PR endpoints is very undesirable, since doing so requires that t= he PR endpoints have the same level of security as the AS.
 
Having a clean separation between the AS and the PR was one of the goals of= Oauth-WRAP – and having the PR authenticate the client using the clie= nt secret violates this goal.
 
That being said, Yahoo does have private/internal APIs which require a very= high level of security in which bearer tokens are not sufficient, and signa= tures using the AT secret aren’t sufficient either – in these ca= ses, signing the request with the client secret is probably the right way to= go. Again – this should be up to the SP to determine that a signature= is required, and how that signature is generated.
 
So what I’m trying to say is – yes there are cases where itR= 17;s desirable to have stronger signatures than just signing with the AT sec= ret – however I think that the cases in which signatures are required,= and which signature algorithm is to be used should be entirely up to the SP= .
 
Does that clarify things?
Allen
 
 
 
 
On 5/27/10 9:04 AM, "Dirk Balfanz" <balfanz@google.com> wrote:
 
  

 
On Thu, May 27, 2010 at 8:56 AM, David Recordon <recordond@gmail.com> wrote:
  
I thought Allen clearly said that signing with t= he client secret won't work for Yahoo!?
 

Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures a= t all. So I think we're good from the Yahoo! side of things.
 
Allen - did I get this right?
 
Dirk.
 
 
  

  
Hi Dirk-
 
We at Yahoo would be very much against using the client secret for signing = requests to Protected Resources, since this would require that the client se= cret be distributed to the PR endpoints. For security reasons, one of the de= sign goals for WRAP was to keep the client secret a secret between only the = AS and the Client – deliberately separating the authentication of the = client (on the AS) from the serving of the protected resource.
 
>From your post, it’s not quite clear what the disadvantage is wit= h using the Access Token secret for generating signatures.
 
(forgive me if this was already discussed today - I was very zonked out aft= er 3 days of IIW)
 
Thanks
Allen
 

 
On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <balfanz@google.com> wrote:
  
Sorry, I didn't mean to turn this into a debate = over whether we should have signatures. I think you guys stated your case cl= early, and there are other use cases as well.
 
The questions I was trying to figure out was whether
 
- you'd be ok using the client secret to sign instead of the token secret (= I think I heard David say that that was ok),
- you'd be ok with a signature scheme that's sufficiently factored out of t= he rest of the spec that it might warrant it's own companion spec (I agree t= hat this is getting close to bikeshed territory, so let's worry about this o= nce we know what the signatures look like).
 
 Dirk.
 
On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <lshepard@facebook.com> wrote:
  
So, when I argued for signatures, the specific u= se cases we are concerned with:
 
- Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - = for Facebook, the top few apps make up a significant amount of API traffic, = so we could do signatures for them and not for everyone else
 
I expect that these are issues that others will encounter as they expand in= to these areas- especially on the mobile side. These are not Facebook-specif= ic issues.
 
That said, I agree with David that we should just figure out what the signa= tures are - I don't really care where they live. If they need to live in a s= eparate spec then whatever, as long as the specs interoperate very cleanly. = But I would like to hear from other mobile developers if they have tried OAu= th 2.0 with success (Brian, I think you mentioned you may have some data abo= ut that?)
 
On May 26, 2010, at 11:20 AM, David Recordon wrote:
 
  
How about we figure out the technical details of= signatures before figuring out where they're placed? :) </bikeshed>  
 
On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balfanz@google.com> wrote:
  
Ok - to those advocating a separate spec: Wha= t if the separate spec was really simple (a couple of pages), and we just pa= sted it as "Section X" into the core OAuth spec?
 
To Facebook: What if the core OAuth spec had a section called "Signed = OAuth Requests" that (in its extreme form) had the single sentence: &qu= ot;If PRs require signing, then Clients use the XYZ mechanism to sign their = OAuth requests" (with a link to XYZ)?
 
 Dirk.
 
On Wed, May 26, 2010 at 10:55 AM, David Recordon <recordond@gmail.com> wrote:
  
I'd prefer that we keep signatures simple enough that they can remain in th= e core spec.
 
 --David
 
 
On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
 
 
<= BLOCKQUOTE>





Repeating what I said before:
 
- separate spec is fine by me
- part of the point I'm trying to make is that that spec shouldn't be about= signed _tokens_, but instead about signed _HTTP requests_ (so instead of me= rely proving that you know a secret that came with the token, you  prov= e who you are when you use the token).
 
I'd be interested what the Facebook guys think about this - I believe the c= urrent signature scheme is in there mostly to address a use case they had.  
Luke, Dave - would a separate signing spec be ok with you guys?
 
 Dirk.
 
On Tue, May 25, 2010 at 6:56 PM, Allen Tom <atom@yahoo-inc.com> wrote:
+1
 
I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels=
of security than what bearer tokens can provide.
 
That being said, I think that bearer token/refresh token model can satisify=
the majority of use cases - in fact it would satisfy 100% of all public API= s
that we have at Yahoo.
 
Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused=
solely on uses cases that require a signature?
 
Allen
 
 
On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:
 
> I have a slightly more radical proposal. What if we factor out the sig= ned
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, = given
> the same attention by the group and all that like Eran was talking abo= ut
> yesterday. What this would take is taking out all reference to signing= and
> making core OAuth just about bare tokens, then have a separate spec th= at
> details what to call your shared secret parameters, how to get them, a= nd how
> to sign with them. This makes the core spec a lot simpler (as detailed= below)
> but makes the overall use case of using signed tokens more complicated= to
> follow, as it'd be split in two.
>
>  -- justin
> ________________________________________
> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk<= BR> > Balfanz [balfanz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAut= h 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's proposal = for
> OAuth signatures. He was proposing a mechanism that would (1) do away = with
> base string canonicalization, (2) allow for symmetric and public keys,= and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposa= l by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAu= th 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.e., = it would
> work both with the signing mechanism in the current spec, as well as w= ith
> Brian's signature mechanism). The goal of my proposal is twofold:
>
> - it simplifies the spec. It will become more readable and therefore e= asier to
> implement
> - it separates out the mechanisms for delegated authorization and for<= BR> > integrity protection into two independent pieces, which can be put tog= ether by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR acc= ess
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens fr= om the
> spec.
> - stop calling the access tokens "bearer tokens". Call them = just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_to= ken then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes so= mething like this:
>
> "Servers may require that requests be authenticated by the Client= , so that
> presentation of the access token alone is not sufficient to access a P= rotected
> Resource.  This has several use cases, including, but not limited= to, the
> following:
>
> - Non-repudiation: high-security deployments may require that requests= be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that acces= s tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure = may
> strip SSL protection before the request reaches the protected resource= . The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests= , then
> the Client uses the following mechanism to sign their HTTP requests: [= ...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the cl= ient
> secret instead of the access token secret). Eventually, instead of Sec= tion
> 5.3, we may have Brian's new signature scheme section here, which woul= d add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achi= eved
> once we have public-key crypto.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf= .org/mailman/listinfo/oauth
 
 
 
_______________________________________________
OAuth mailing list
 OAuth@ietf.org
 https://www.iet= f.org/mailman/listinfo/oauth
 
  







 
 
 
<= BLOCKQUOTE>

<ATT00001..txt>
 

 

 

 

 
 
___________= ____________________________________
OAuth mailing list
 OAuth@ietf.org
 https://www.iet= f.org/mailman/listinfo/oauth
 



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
=

--B_3357810531_42965087-- From gffletch@aol.com Thu May 27 13:31:11 2010 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 42C2E3A67D7 for ; Thu, 27 May 2010 13:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, 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 d89pz2IG-yyy for ; Thu, 27 May 2010 13:30:59 -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 D02D23A672E for ; Thu, 27 May 2010 13:30:58 -0700 (PDT) Received: from mtaout-ma01.r1000.mx.aol.com (mtaout-ma01.r1000.mx.aol.com [172.29.41.1]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id o4RKUXDa027188; Thu, 27 May 2010 16:30:33 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id C98D3E000129; Thu, 27 May 2010 16:30:32 -0400 (EDT) Message-ID: <4BFED668.8060100@aol.com> Date: Thu, 27 May 2010 16:30:32 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Allen Tom References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030505090406050902070304" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:499620224:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29014bfed6683ba3 X-AOL-IP: 10.181.183.108 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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, 27 May 2010 20:31:11 -0000 This is a multi-part message in MIME format. --------------030505090406050902070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks, makes sense. +1 to SP's deciding on what signature mech is required :) On 5/27/10 4:08 PM, Allen Tom wrote: > Hi George, > > The really short summary is that Yahoo is fine with client based > signatures being in the spec, although we do not want Service > Providers to be obligated to support them. The decision as to whether > or not signatures should be used, and which signature algorithm to use > should be up to the Service Provider. > > We are very strongly against signatures generated using the client > secret for the overwhelming majority of our APIs -- which is why we > want the signature algorithm to be chosen by the SP. A signature using > the Access Token secret (without the client secret) is OK, although > it's unnecessary for our applications. A plain bearer token by itself > (provided that it's only valid for about an hour) is sufficient for > all of Yahoo's services -- even without HTTPS. We'd rather increase > security by deploying HTTPS rather than requiring developers to sign > their requests. > > Thanks > Allen > > > On 5/27/10 11:11 AM, "George Fletcher" wrote: > > Hmm... to me this says... > > Yahoo won't deploy PRs that require client_secret signatures, > but may have some internal apps where this is ok. > > So, to me that sounds like Yahoo is ok with client_secret > based signatures as one way to sign the requests, but they > don't want it to be the only way. > > > I would like to bring back what Dirk has said earlier in this > thread... > > 1. Signing isn't about the token but rather about the message > 2. Signing provides message integrity > 3. Signing provides (or should allow for) proof of sender > > I'd like to add... > 4. Signing (combined with appropriate information in the AT) > enables "right to present" the token > > I think that for certain use cases, its critical that the PR be > able to ensure that the client is "authorized" to present the AT. > This isn't possible for bearer tokens. I also don't believe this > hurts sub-delegation because the AS can create an AT that can be > sub-delegated and when the sub-delegate presents the AT, the PR > can verify that the sub-delegate is allowed to present that AT. > > Thanks, > George > > On 5/27/10 12:58 PM, Allen Tom wrote: > > Re: [OAUTH-WG] proposal for factoring out request signing in > OAuth 2 The short summary is that Yahoo thinks that signatures > should not be required for most use cases. In the exceptional > cases where signatures are required, then it should be up to > the service provider (and not the client) to determine when > they're required, and which signature algorithm is to be > used. Yahoo does not want to be forced to support signatures > generated using the client secret -- we don't even want this > to be an option for the overwhelming majority of our APIs. Due > to the way services are deployed at Yahoo, our security team > feels that in general, having PR endpoints validate signatures > computed using the client secret makes our overall system LESS > secure -- since we'd be forced to distribute client secrets to > the PR endpoints. Distributing the client secret to the PR > endpoints is very undesirable, since doing so requires that > the PR endpoints have the same level of security as the AS. > > Having a clean separation between the AS and the PR was one of > the goals of Oauth-WRAP -- and having the PR authenticate the > client using the client secret violates this goal. > > That being said, Yahoo does have private/internal APIs which > require a very high level of security in which bearer tokens > are not sufficient, and signatures using the AT secret aren't > sufficient either -- in these cases, signing the request with > the client secret is probably the right way to go. Again -- > this should be up to the SP to determine that a signature is > required, and how that signature is generated. > > So what I'm trying to say is -- yes there are cases where it's > desirable to have stronger signatures than just signing with > the AT secret -- however I think that the cases in which > signatures are required, and which signature algorithm is to > be used should be entirely up to the SP. > > Does that clarify things? > Allen > > > > > On 5/27/10 9:04 AM, "Dirk Balfanz" wrote: > > > > > On Thu, May 27, 2010 at 8:56 AM, David Recordon > wrote: > > I thought Allen clearly said that signing with the > client secret won't work for Yahoo!? > > > Right - but he also said that they (i.e. Yahoo!) wouldn't > need signatures at all. So I think we're good from the > Yahoo! side of things. > > Allen - did I get this right? > > Dirk. > > > > > > Hi Dirk- > > We at Yahoo would be very much against using the > client secret for signing requests to Protected > Resources, since this would require that the > client secret be distributed to the PR endpoints. > For security reasons, one of the design goals for > WRAP was to keep the client secret a secret > between only the AS and the Client -- deliberately > separating the authentication of the client (on > the AS) from the serving of the protected resource. > > >From your post, it's not quite clear what the > disadvantage is with using the Access Token secret > for generating signatures. > > (forgive me if this was already discussed today - > I was very zonked out after 3 days of IIW) > > Thanks > Allen > > > > On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz > wrote: > > Sorry, I didn't mean to turn this into a debate > over whether we should have signatures. I think > you guys stated your case clearly, and there are > other use cases as well. > > The questions I was trying to figure out was whether > > - you'd be ok using the client secret to sign > instead of the token secret (I think I heard David > say that that was ok), > - you'd be ok with a signature scheme that's > sufficiently factored out of the rest of the spec > that it might warrant it's own companion spec (I > agree that this is getting close to bikeshed > territory, so let's worry about this once we know > what the signatures look like). > > Dirk. > > > On Wed, May 26, 2010 at 2:17 PM, Luke Shepard > wrote: > > So, when I argued for signatures, the specific > use cases we are concerned with: > > - Mobile handsets and networks that don't > support SSL very well > - High-volume applications where SSL is a > significant cost to both sides - for Facebook, > the top few apps make up a significant amount > of API traffic, so we could do signatures for > them and not for everyone else > > I expect that these are issues that others > will encounter as they expand into these > areas- especially on the mobile side. These > are not Facebook-specific issues. > > That said, I agree with David that we should > just figure out what the signatures are - I > don't really care where they live. If they > need to live in a separate spec then whatever, > as long as the specs interoperate very > cleanly. But I would like to hear from other > mobile developers if they have tried OAuth 2.0 > with success (Brian, I think you mentioned you > may have some data about that?) > > On May 26, 2010, at 11:20 AM, David Recordon > wrote: > > > How about we figure out the technical > details of signatures before figuring out > where they're placed? :) > > > On Wed, May 26, 2010 at 12:15 PM, Dirk > Balfanz wrote: > > Ok - to those advocating a separate spec: What if the separate spec > was really simple (a couple of pages), and we just pasted it as > "Section X" into the core OAuth spec? > > To Facebook: What if the core OAuth spec had a section called "Signed > OAuth Requests" that (in its extreme form) had the single sentence: > "If PRs require signing, then Clients use the XYZ mechanism to sign > their OAuth requests" (with a link to XYZ)? > > Dirk. > > > On Wed, May 26, 2010 at 10:55 AM, David Recordon > wrote: > > I'd prefer that we keep signatures simple enough that they can remain > in the core spec. > > --David > > > > On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote: > > > > > > > > Repeating what I said before: > > - separate spec is fine by me > - part of the point I'm trying to make is that that spec > shouldn't be about signed _tokens_, but instead about signed > _HTTP requests_ (so instead of merely proving that you know a > secret that came with the token, you prove who you are when > you use the token). > > I'd be interested what the Facebook guys think about this - I > believe the current signature scheme is in there mostly to > address a use case they had. > > Luke, Dave - would a separate signing spec be ok with you guys? > > Dirk. > > > On Tue, May 25, 2010 at 6:56 PM, Allen Tom > wrote: > +1 > > I fully agree with Dirk and Brian that there needs to be some > work on > signatures. There are many types of applications that require > higher levels > of security than what bearer tokens can provide. > > That being said, I think that bearer token/refresh token model > can satisify > the majority of use cases - in fact it would satisfy 100% of > all public APIs > that we have at Yahoo. > > Perhaps in the interest of keeping the spec focused, it would > make more > sense to split out a Signed Token Spec, as Justin proposes, > that is focused > solely on uses cases that require a signature? > > Allen > > > > On 5/21/10 11:27 AM, "Richer, Justin P." > wrote: > > > I have a slightly more radical proposal. What if we factor > out the signed > > token use case into a parallel spec? The OAuth 2.0 Signed > Token spec, given > > the same attention by the group and all that like Eran was > talking about > > yesterday. What this would take is taking out all reference > to signing and > > making core OAuth just about bare tokens, then have a > separate spec that > > details what to call your shared secret parameters, how to > get them, and how > > to sign with them. This makes the core spec a lot simpler (as > detailed below) > > but makes the overall use case of using signed tokens more > complicated to > > follow, as it'd be split in two. > > > > -- justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On > Behalf Of Dirk > > Balfanz [balfanz@google.com] > > Sent: Thursday, May 20, 2010 7:39 PM > > To: OAuth WG > > Subject: [OAUTH-WG] proposal for factoring out request > signing in OAuth 2 > > > > Hi guys, > > > > at today's interim meeting, we were discussing Brian Eaton's > proposal for > > OAuth signatures. He was proposing a mechanism that would (1) > do away with > > base string canonicalization, (2) allow for symmetric and > public keys, and (3) > > allow for extensibility. > > > > He got homework from the group to prove the feasibility of > his proposal by > > showing a couple of implementations. > > > > In this post, I would like to introduce another improvement > of the OAuth 2 > > signing mechanism, one which is orthogonal to Brian's > proposal (i.e., it would > > work both with the signing mechanism in the current spec, as > well as with > > Brian's signature mechanism). The goal of my proposal is twofold: > > > > - it simplifies the spec. It will become more readable and > therefore easier to > > implement > > - it separates out the mechanisms for delegated authorization > and for > > integrity protection into two independent pieces, which can > be put together by > > Servers and/or Clients like LEGO blocks. > > > > Summary: > > > > - use the client secret instead of the token secret for > signing PR access > > requests. > > > > Long version of the proposal: > > > > - remove all references to access tokens that are not bearer > tokens from the > > spec. > > - stop calling the access tokens "bearer tokens". Call them > just "access > > tokens". > > - remove all references to token secrets from the spec > > - remove all parts of the spec that are of the kind "if > bearer_token then X, > > else Y", and replace them with X. > > - delete section 5.3 > > - add a section called "Request Authentication" that goes > something like this: > > > > "Servers may require that requests be authenticated by the > Client, so that > > presentation of the access token alone is not sufficient to > access a Protected > > Resource. This has several use cases, including, but not > limited to, the > > following: > > > > - Non-repudiation: high-security deployments may require that > requests be > > authenticated (signed) in a non-repudiateable way[1] > > - Access to protected resources is not protected by SSL, so > that access tokens > > may leak. > > - End-to-end-integrity: even if SSL _is_ used, network > infrastructure may > > strip SSL protection before the request reaches the protected > resource. The > > protected resource, however, may require end-to-end integrity. > > > > If the Server requires that the Client authenticate PR access > requests, then > > the Client uses the following mechanism to sign their HTTP > requests: [...]" > > > > Then, we basically drop the old Section 5.3 here (except we > use the client > > secret instead of the access token secret). Eventually, > instead of Section > > 5.3, we may have Brian's new signature scheme section here, > which would add > > the option of public-key crypto[1], etc. > > > > What do you guys think? > > > > Dirk. > > > > [1] Technically speaking, the goal of non-repudiation can > only be achieved > > once we have public-key crypto. > > > > _______________________________________________ > > 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 > > > --------------030505090406050902070304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, makes sense. +1 to SP's deciding on what signature mech is required :)

On 5/27/10 4:08 PM, Allen Tom wrote:
Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Hi George,

The really short summary is that Yahoo is fine with client based signatures being in the spec, although we do not want Service Providers to be obligated to support them. The decision as to whether or not signatures should be used, and which signature algorithm to use should be up to the Service Provider.

We are very strongly against signatures generated using the client secret for the overwhelming majority of our APIs – which is why we want the signature algorithm to be chosen by the SP. A signature using the Access Token secret (without the client secret) is OK, although it’s unnecessary for our applications.  A plain bearer token by itself (provided that it’s only valid for about an hour) is sufficient for all of Yahoo’s services – even without HTTPS.  We’d rather increase security by deploying HTTPS rather than requiring developers to sign their requests.

Thanks
Allen


On 5/27/10 11:11 AM, "George Fletcher" <gffletch@aol.com> wrote:
Hmm... to me this says...
Yahoo won't deploy PRs that require client_secret signatures, but may have some internal apps where this is ok.
 So, to me that sounds like Yahoo is ok with client_secret based signatures as one way to sign the requests, but they don't want it to be the only way.

I would like to bring back what Dirk has said earlier in this thread...

1. Signing isn't about the token but rather about the message
2. Signing provides message integrity
3. Signing provides (or should allow for) proof of sender

I'd like to add...
4. Signing (combined with appropriate information in the AT) enables "right to present" the token

I think that for certain use cases, its critical that the PR be able to ensure that the client is "authorized" to present the AT. This isn't possible for bearer tokens. I also don't believe this hurts sub-delegation because the AS can create an AT that can be sub-delegated and when the sub-delegate presents the AT, the PR can verify that the sub-delegate is allowed to present that AT.

Thanks,
George

On 5/27/10 12:58 PM, Allen Tom wrote:
Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 The short summary is that Yahoo thinks that signatures should not be required for most use cases. In the exceptional cases where signatures are required, then it should be up to the service provider (and not the client) to determine when they’re required, and  which signature algorithm is to be used.  Yahoo does not want to be forced to support signatures generated using the client secret – we don’t even want this to be an option for the overwhelming majority of our APIs. Due to the way services are deployed at Yahoo, our security team feels that in general, having PR endpoints validate signatures computed using the client secret makes our overall system LESS secure – since we’d be forced to distribute client secrets to the PR endpoints. Distributing the client secret to the PR endpoints is very undesirable, since doing so requires that the PR endpoints have the same level of security as the AS.
 
Having a clean separation between the AS and the PR was one of the goals of Oauth-WRAP – and having the PR authenticate the client using the client secret violates this goal.
 
That being said, Yahoo does have private/internal APIs which require a very high level of security in which bearer tokens are not sufficient, and signatures using the AT secret aren’t sufficient either – in these cases, signing the request with the client secret is probably the right way to go. Again – this should be up to the SP to determine that a signature is required, and how that signature is generated.
 
So what I’m trying to say is – yes there are cases where it’s desirable to have stronger signatures than just signing with the AT secret – however I think that the cases in which signatures are required, and which signature algorithm is to be used should be entirely up to the SP.
 
Does that clarify things?
Allen
 
 
 
 
On 5/27/10 9:04 AM, "Dirk Balfanz" <balfanz@google.com> wrote:
 
  

 
On Thu, May 27, 2010 at 8:56 AM, David Recordon <recordond@gmail.com> wrote:
  
I thought Allen clearly said that signing with the client secret won't work for Yahoo!?
 

Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures at all. So I think we're good from the Yahoo! side of things.
 
Allen - did I get this right?
 
Dirk.
 
 
  

  
Hi Dirk-
 
We at Yahoo would be very much against using the client secret for signing requests to Protected Resources, since this would require that the client secret be distributed to the PR endpoints. For security reasons, one of the design goals for WRAP was to keep the client secret a secret between only the AS and the Client – deliberately separating the authentication of the client (on the AS) from the serving of the protected resource.
 
>From your post, it’s not quite clear what the disadvantage is with using the Access Token secret for generating signatures.
 
(forgive me if this was already discussed today - I was very zonked out after 3 days of IIW)
 
Thanks
Allen
 

 
On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <balfanz@google.com> wrote:
  
Sorry, I didn't mean to turn this into a debate over whether we should have signatures. I think you guys stated your case clearly, and there are other use cases as well.
 
The questions I was trying to figure out was whether
 
- you'd be ok using the client secret to sign instead of the token secret (I think I heard David say that that was ok),
- you'd be ok with a signature scheme that's sufficiently factored out of the rest of the spec that it might warrant it's own companion spec (I agree that this is getting close to bikeshed territory, so let's worry about this once we know what the signatures look like).
 
 Dirk.
 
On Wed, May 26, 2010 at 2:17 PM, Luke Shepard <lshepard@facebook.com> wrote:
  
So, when I argued for signatures, the specific use cases we are concerned with:
 
- Mobile handsets and networks that don't support SSL very well
- High-volume applications where SSL is a significant cost to both sides - for Facebook, the top few apps make up a significant amount of API traffic, so we could do signatures for them and not for everyone else
 
I expect that these are issues that others will encounter as they expand into these areas- especially on the mobile side. These are not Facebook-specific issues.
 
That said, I agree with David that we should just figure out what the signatures are - I don't really care where they live. If they need to live in a separate spec then whatever, as long as the specs interoperate very cleanly. But I would like to hear from other mobile developers if they have tried OAuth 2.0 with success (Brian, I think you mentioned you may have some data about that?)
 
On May 26, 2010, at 11:20 AM, David Recordon wrote:
 
  
How about we figure out the technical details of signatures before figuring out where they're placed? :) </bikeshed>
 
 
On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balfanz@google.com> wrote:
  
Ok - to those advocating a separate spec: What if the separate spec was really simple (a couple of pages), and we just pasted it as "Section X" into the core OAuth spec?
 
To Facebook: What if the core OAuth spec had a section called "Signed OAuth Requests" that (in its extreme form) had the single sentence: "If PRs require signing, then Clients use the XYZ mechanism to sign their OAuth requests" (with a link to XYZ)?
 
 Dirk.
 
On Wed, May 26, 2010 at 10:55 AM, David Recordon <recordond@gmail.com> wrote:
  
I'd prefer that we keep signatures simple enough that they can remain in the core spec.
 
 --David
 
 
On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <balfanz@google.com> wrote:
 
 





Repeating what I said before:
 
- separate spec is fine by me
- part of the point I'm trying to make is that that spec shouldn't be about signed _tokens_, but instead about signed _HTTP requests_ (so instead of merely proving that you know a secret that came with the token, you  prove who you are when you use the token).
 
I'd be interested what the Facebook guys think about this - I believe the current signature scheme is in there mostly to address a use case they had.
 
Luke, Dave - would a separate signing spec be ok with you guys?
 
 Dirk.
 
On Tue, May 25, 2010 at 6:56 PM, Allen Tom <atom@yahoo-inc.com> wrote:
+1
 
I fully agree with Dirk and Brian that there needs to be some work on
signatures. There are many types of applications that require higher levels
of security than what bearer tokens can provide.
 
That being said, I think that bearer token/refresh token model can satisify
the majority of use cases - in fact it would satisfy 100% of all public APIs
that we have at Yahoo.
 
Perhaps in the interest of keeping the spec focused, it would make more
sense to split out a Signed Token Spec, as Justin proposes, that is focused
solely on uses cases that require a signature?
 
Allen
 
 
On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:
 
> I have a slightly more radical proposal. What if we factor out the signed
> token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given
> the same attention by the group and all that like Eran was talking about
> yesterday. What this would take is taking out all reference to signing and
> making core OAuth just about bare tokens, then have a separate spec that
> details what to call your shared secret parameters, how to get them, and how
> to sign with them. This makes the core spec a lot simpler (as detailed below)
> but makes the overall use case of using signed tokens more complicated to
> follow, as it'd be split in two.
>
>  -- justin
> ________________________________________
> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk
> Balfanz [balfanz@google.com]
> Sent: Thursday, May 20, 2010 7:39 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2
>
> Hi guys,
>
> at today's interim meeting, we were discussing Brian Eaton's proposal for
> OAuth signatures. He was proposing a mechanism that would (1) do away with
> base string canonicalization, (2) allow for symmetric and public keys, and (3)
> allow for extensibility.
>
> He got homework from the group to prove the feasibility of his proposal by
> showing a couple of implementations.
>
> In this post, I would like to introduce another improvement of the OAuth 2
> signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would
> work both with the signing mechanism in the current spec, as well as with
> Brian's signature mechanism). The goal of my proposal is twofold:
>
> - it simplifies the spec. It will become more readable and therefore easier to
> implement
> - it separates out the mechanisms for delegated authorization and for
> integrity protection into two independent pieces, which can be put together by
> Servers and/or Clients like LEGO blocks.
>
> Summary:
>
> - use the client secret instead of the token secret for signing PR access
> requests.
>
> Long version of the proposal:
>
> - remove all references to access tokens that are not bearer tokens from the
> spec.
> - stop calling the access tokens "bearer tokens". Call them just "access
> tokens".
> - remove all references to token secrets from the spec
> - remove all parts of the spec that are of the kind "if bearer_token then X,
> else Y", and replace them with X.
> - delete section 5.3
> - add a section called "Request Authentication" that goes something like this:
>
> "Servers may require that requests be authenticated by the Client, so that
> presentation of the access token alone is not sufficient to access a Protected
> Resource.  This has several use cases, including, but not limited to, the
> following:
>
> - Non-repudiation: high-security deployments may require that requests be
> authenticated (signed) in a non-repudiateable way[1]
> - Access to protected resources is not protected by SSL, so that access tokens
> may leak.
> - End-to-end-integrity: even if SSL _is_ used, network infrastructure may
> strip SSL protection before the request reaches the protected resource. The
> protected resource, however, may require end-to-end integrity.
>
> If the Server requires that the Client authenticate PR access requests, then
> the Client uses the following mechanism to sign their HTTP requests: [...]"
>
> Then, we basically drop the old Section 5.3 here (except we use the client
> secret instead of the access token secret). Eventually, instead of Section
> 5.3, we may have Brian's new signature scheme section here, which would add
> the option of public-key crypto[1], etc.
>
> What do you guys think?
>
> Dirk.
>
> [1] Technically speaking, the goal of non-repudiation can only be achieved
> once we have public-key crypto.
>
> _______________________________________________
> 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
 
  







 
 
 

<ATT00001..txt>
 

 

 

 

 
 
_______________________________________________
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


--------------030505090406050902070304-- From eran@hueniverse.com Thu May 27 16:50:27 2010 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 212103A6930 for ; Thu, 27 May 2010 16:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_40=-0.185] 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 r6aYJyzrsLAo for ; Thu, 27 May 2010 16:50:24 -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 D54663A67B3 for ; Thu, 27 May 2010 16:50:23 -0700 (PDT) Received: (qmail 22832 invoked from network); 27 May 2010 23:50:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 May 2010 23:50:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 27 May 2010 16:50:09 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Thu, 27 May 2010 16:50:01 -0700 Thread-Topic: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr99xs1uJuUWCz/R4m5WzKq+EWYEAAADHuA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@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] FW: Duplicating request component in an HTTP authentication scheme 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, 27 May 2010 23:50:27 -0000 -----Original Message----- From: Roy T. Fielding [mailto:fielding@gbiv.com]=20 Sent: Thursday, May 27, 2010 4:48 PM To: Eran Hammer-Lahav Cc: HTTP Working Group (ietf-http-wg@w3.org) Subject: Re: Duplicating request component in an HTTP authentication scheme On May 27, 2010, at 4:11 PM, Eran Hammer-Lahav wrote: > The OAuth working group is debating how to make signed authenticated requ= ests. The two main questions is what do sign, and what to sign it with. On = the 'what to sign part' we know we want to sign the request URI, HTTP metho= d, and host name (among other cryptographic attributes such as timestamp an= d nonce). >=20 > OAuth 1.0 includes a normalization process taking the request and seriali= zing it into a base string (which is then signed). For OAuth 2.0, we have t= wo competing proposals: >=20 > 1. Normalize the request and send just the signature 2. Normalize the=20 > request and send both the signature and the signed string >=20 > The advantage of #2 is that is moves the complexity from the client to th= e server. It is up to the server to figure out if the signed blob matches t= he request itself. The issue is that by doing so, the HTTP request is dupli= cated (HTTP request and authentication blob). Server will be required to co= mpare the request with the blob to make sure they match. In practice, serve= rs can ignore the request and just respond to the blob because it's the aut= henticated copy. >=20 > The ramification of #2 is that it moves the HTTP request bits to another = layer, creating a sort of wrapper. And a security hole that you can drive a truck through. If you are going t= o sign the routing bits, then you have to verify that the route is the same= in both the blob and the message so that the blob is not being used to byp= ass route security (e.g., firewalls) to access internal paths. If the server doesn't check the actual message, then don't bother to sign a= nything. In other words, I say #1, or at least I would if this were not he= ading down the exact same road as S-HTTP. > However, this approach should make it easier for client developers (who p= roved themselves to be extremely incompetent with the 1.0 specification) to= get signatures right. It also allows for signing arbitrary data in additio= n to the HTTP request. >=20 > Thoughts? The same client developers will have the same competence issues with regard= to any new spec. Just make sure that the protocol breaks visibly if anyth= ing is done wrong, and then they can fix their own protocol stacks if they = want to implement this signing. ....Roy From sakimura@gmail.com Thu May 27 18:16:02 2010 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 A7A073A69CD for ; Thu, 27 May 2010 18:15:56 -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 MmR1S0yAaAQg for ; Thu, 27 May 2010 18:15:45 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 9F59E3A6987 for ; Thu, 27 May 2010 18:15:43 -0700 (PDT) Received: by pxi19 with SMTP id 19so308834pxi.31 for ; Thu, 27 May 2010 18:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=vcEErkAC6UoUZmf/PoLOZjdUx4+LjmPqnOZgLnOgwJA=; b=juqBM/uxBfppa9aNZ2CX07+2pdTY7eyur7OxXFmaO40y2JNLkSQVwlBCxZREc14SJu UuTWZCyFowPFYTM+7a9DIrb5ogoWjVWG/zN6dzGeEpOeHSNJ8okm9rt9kw0EZlnRhfjI NP/AnYMTTkOSJyKRRpJ821QiJZyc86NrYrTtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=cs6bXiUBPWtcEb9skfUXTyV+J9qy0jFDTHfVYXY/BtpX6/cGJ2cqfjgfQDly6V9DiJ JVQFp8kNIZH55eIbRCdPC84HRyIv/zILz/25Mqj59F4CA/+KJ2ad/Flw930d9N3DVyvb 3lExMtFxCQsm0fv+wVpHbokPwhiU+IIBntrno= Received: by 10.142.247.33 with SMTP id u33mr7528686wfh.44.1275009331794; Thu, 27 May 2010 18:15:31 -0700 (PDT) Received: from [192.168.2.4] (pd84537.tokynt01.ap.so-net.ne.jp [111.216.69.55]) by mx.google.com with ESMTPS id 21sm1392229pzk.8.2010.05.27.18.15.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 May 2010 18:15:30 -0700 (PDT) References: Message-Id: <46CE3296-E32C-4C0F-8F2E-3B6E2F5A07DC@gmail.com> From: Nat To: Marius Scurtescu In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 28 May 2010 10:15:43 +0900 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 28 May 2010 01:16:02 -0000 On 2010/05/28, at 3:12, Marius Scurtescu wrote: > On Thu, May 27, 2010 at 11:06 AM, Nat Sakimura > wrote: >> On Fri, May 28, 2010 at 2:10 AM, Marius Scurtescu > > wrote: >>> Thanks for the clarification Nat. >>> >>> Just curios, can't the phone client actually POST to the authz >>> server? >>> That would take care of the URL length limitation. >> >> POST means an extra click, which is a UI disaster. > > I assume self posting forms do not work on these devices? > Unfortunately, not. > >> Also, more data over the air means slower response. > > True, but the alternative is to have the authz server fetch the data > from the web client, some cycles are lost there as well. > The server to server connection generally is much faster. > >>> In your diagram, the verification code is passed from UA to Web >>> Client >>> and then the Web Client is exchanging it for the access and refresh >>> tokens. These tokens are never passed back to the UA, is that >>> intended? Also, why can't the UA do the exchange directly? >> >> It is following the Web Server flow. >> Apart from getting the request parameter through the request_url >> fetch >> is almost exactly as in the Web Server flow. > > Sure, but who is the client in this case? Isn't the UA (aka phone) > ultimately interested in having access tokens so it can make API > calls? > The UA on these devices are generally dumb. Generally speaking, we want the the web client to all the job and get only the summary to the UA. > > Marius From beaton@google.com Thu May 27 18:24:41 2010 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 613E03A69F8 for ; Thu, 27 May 2010 18:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.563 X-Spam-Level: X-Spam-Status: No, score=-99.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 zo+kaxh0Udfa for ; Thu, 27 May 2010 18:24:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 220A53A69E6 for ; Thu, 27 May 2010 18:21:45 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o4S1LUcm022764 for ; Thu, 27 May 2010 18:21:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275009694; bh=OTOTJ5nBIe7g8/0UEC+tTxL8494=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=xGivV7y042Y81IjV8JPCemyXed2KaNMq664mXri5zNozEpmZ7e4qdWm28rRWXEjvG ZvCRNbHYYu5ZTJ9GmTMrA== 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=k8x/aiXqaVZZlpk/zEMwqoO0VfzFMXwTeDlx2Nly66DekjvHrGJdGByqsTPedjS4L 4NShWSTjyt/IXkAGELFZQ== Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by kpbe20.cbf.corp.google.com with ESMTP id o4S1LTim030673 for ; Thu, 27 May 2010 18:21:29 -0700 Received: by pzk30 with SMTP id 30so606190pzk.6 for ; Thu, 27 May 2010 18:21:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.117.14 with SMTP id p14mr7684158wfc.144.1275009688740; Thu, 27 May 2010 18:21:28 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Thu, 27 May 2010 18:21:28 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 27 May 2010 18:21:28 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav , fielding@gbiv.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 01:24:41 -0000 Umm, needless to say, I disagree with Roy on this one. =3D) To respond to the main point: > And a security hole that you can drive a truck through. If you > are going to sign the routing bits, then you have to verify that > the route is the same in both the blob and the message so that > the blob is not being used to bypass route security (e.g., firewalls) > to access internal paths. Yes, the server needs to check that the URL it received and the URL that was signed match. This kind of check is extremely common in authentication protocols. It happens in SAML, OpenID, etc... Servers in all of those protocols verify that the "audience" field in the signed message matches the expected audience. All of those protocols are insecure if this check is left out. NTLM leaves this check-out, and this vulnerability can be used to launch relay attacks. OAuth 1.0 was unusual in that it required that the server match a hash of the URL, rather than the real URL. It's an extra layer of indirection and complexity. It doesn't improve security. Cheers, Brian On Thu, May 27, 2010 at 4:50 PM, Eran Hammer-Lahav wr= ote: > > > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@gbiv.com] > Sent: Thursday, May 27, 2010 4:48 PM > To: Eran Hammer-Lahav > Cc: HTTP Working Group (ietf-http-wg@w3.org) > Subject: Re: Duplicating request component in an HTTP authentication sche= me > > On May 27, 2010, at 4:11 PM, Eran Hammer-Lahav wrote: > >> The OAuth working group is debating how to make signed authenticated req= uests. The two main questions is what do sign, and what to sign it with. On= the 'what to sign part' we know we want to sign the request URI, HTTP meth= od, and host name (among other cryptographic attributes such as timestamp a= nd nonce). >> >> OAuth 1.0 includes a normalization process taking the request and serial= izing it into a base string (which is then signed). For OAuth 2.0, we have = two competing proposals: >> >> 1. Normalize the request and send just the signature 2. Normalize the >> request and send both the signature and the signed string >> >> The advantage of #2 is that is moves the complexity from the client to t= he server. It is up to the server to figure out if the signed blob matches = the request itself. The issue is that by doing so, the HTTP request is dupl= icated (HTTP request and authentication blob). Server will be required to c= ompare the request with the blob to make sure they match. In practice, serv= ers can ignore the request and just respond to the blob because it's the au= thenticated copy. >> >> The ramification of #2 is that it moves the HTTP request bits to another= layer, creating a sort of wrapper. > > And a security hole that you can drive a truck through. =A0If you are goi= ng to sign the routing bits, then you have to verify that the route is the = same in both the blob and the message so that the blob is not being used to= bypass route security (e.g., firewalls) to access internal paths. > > If the server doesn't check the actual message, then don't bother to sign= anything. =A0In other words, I say #1, or at least I would if this were no= t heading down the exact same road as S-HTTP. > >> However, this approach should make it easier for client developers (who = proved themselves to be extremely incompetent with the 1.0 specification) t= o get signatures right. It also allows for signing arbitrary data in additi= on to the HTTP request. >> >> Thoughts? > > The same client developers will have the same competence issues with rega= rd to any new spec. =A0Just make sure that the protocol breaks visibly if a= nything is done wrong, and then they can fix their own protocol stacks if t= hey want to implement this signing. > > ....Roy > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From romeda@gmail.com Thu May 27 18:49:24 2010 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 59E023A6987 for ; Thu, 27 May 2010 18:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 7SrIMKvfiioN for ; Thu, 27 May 2010 18:49:23 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 8F1AB3A6882 for ; Thu, 27 May 2010 18:49:23 -0700 (PDT) Received: by pxi19 with SMTP id 19so319923pxi.31 for ; Thu, 27 May 2010 18:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=e9qM8fPV5WxLB5y+LEotoG5h9Z8IxcYEXXnola92p1A=; b=vIl0fTxaSjE9PANtKN87RPe4Xnd/FO024nm2SGieyaOSRhbBxL8nWLH6RPHdrJmQuw Y2B60WSamex++9lH67v6yt6cF+a8bomUG7T21AKUeO+G8hpIEiXeNfkkS3mmY9ZI8k5A eexEhjaAXILgjWwj+2GQYBVehvS4ubr/CzQa4= 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=ONqhOkvWdwT22PZvDYiwVOUhJiMy30r5WOxmt9cTVJbJde4J0P7j9ibHPwt9ET+2/N OTDd6wpX17x3mSFUnVheICFA3kXBuaurPpNtX1AYM+c+q3DQ4fFXwPlxRjVaMV3X69Ua FGNPdg3CvfyZoixdLG+Set7uLectpJv655Fhg= Received: by 10.141.213.36 with SMTP id p36mr8651351rvq.5.1275011351261; Thu, 27 May 2010 18:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.207.6 with HTTP; Thu, 27 May 2010 18:48:51 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Fri, 28 May 2010 02:48:51 +0100 Message-ID: To: Brian Eaton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: fielding@gbiv.com, "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 01:49:24 -0000 On 28 May 2010 02:21, Brian Eaton wrote: > OAuth 1.0 was unusual in that it required that the server match a hash > of the URL, rather than the real URL. =C2=A0It's an extra layer of > indirection and complexity. =C2=A0It doesn't improve security. To be more precise, OAuth 1.0 required that the server match a normalised form of the URL. You're absolutely correct that it doesn't improve security [over matching the URL], but it *is* more secure than either not proving that the token bearer provided the URL in the first place or having the client and server match potentially different versions of the URL. This is a problem of leaky abstractions: if HTTP was used in a way such that the client unequivocally asserted "This: {x} is the unabridged HTTP URL that I am requesting", and such that {x} was presented untouched to the service handling the request, then we wouldn't have to worry about normalisation. As it stands, getting access to the raw request URL is relatively difficult in many environments that handle HTTP requests, and even more difficult to obtain from HTTP client libraries, since the actual request URI is often constructed in a private method at the last moment before a request is actually made. Which is all to say that it is indeed complex, but much of that complexity is a result of HTTP libraries trying to hide complexity from users. I'd echo Roy's assertion that as library support improves, approaches to URL normalisation will become hidden behind the same layers of abstraction as constructing query strings and request URIs are today. b. From eran@hueniverse.com Thu May 27 20:04:22 2010 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 6B8473A69F1 for ; Thu, 27 May 2010 20:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, 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 TG-skuBVr0Sn for ; Thu, 27 May 2010 20:04:21 -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 7C78B3A69EE for ; Thu, 27 May 2010 20:04:21 -0700 (PDT) Received: (qmail 10534 invoked from network); 28 May 2010 03:04:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 May 2010 03:04:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 27 May 2010 20:04:11 -0700 From: Eran Hammer-Lahav To: Brian Eaton , "fielding@gbiv.com" Date: Thu, 27 May 2010 20:04:02 -0700 Thread-Topic: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr+BBuR0Dzqy8pmQGiubSLzImlEzAADj+7A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C508@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@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 WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 03:04:22 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Thursday, May 27, 2010 6:21 PM > OAuth 1.0 was unusual in that it required that the server match a hash of= the > URL, rather than the real URL. It's an extra layer of indirection and > complexity. It doesn't improve security. The current draft signs the real URL. EHL From beaton@google.com Thu May 27 20:59:12 2010 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 8A5DD3A67E2 for ; Thu, 27 May 2010 20:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.12 X-Spam-Level: X-Spam-Status: No, score=-104.12 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185, 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 sw8FkaC8pVrA for ; Thu, 27 May 2010 20:59:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AF52B3A67A7 for ; Thu, 27 May 2010 20:59:11 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o4S3wvWi017860 for ; Thu, 27 May 2010 20:58:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275019137; bh=VJkCyTLr+D2HwdCIQw2yOBR9AH4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=fNSECa87wQVMTu6mq4fSlT0g090cUi3Uup8E64J0S1bgS3Nq9LoTTFsnzoldxhGSz tAkaeHx93Fwa3koqxYgvA== 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=TpiyoQBIIMjT7cei998eGnfKwNK580YnTUBXFeXtWT3h7HiPIjHH5+D1bsbQO4k1F CJsR6g7ZF6aUoGcy7RT5A== Received: from pxi12 (pxi12.prod.google.com [10.243.27.12]) by wpaz21.hot.corp.google.com with ESMTP id o4S3wttF020624 for ; Thu, 27 May 2010 20:58:56 -0700 Received: by pxi12 with SMTP id 12so777754pxi.0 for ; Thu, 27 May 2010 20:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.10.5 with SMTP id 5mr7349952wfj.267.1275019135273; Thu, 27 May 2010 20:58:55 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Thu, 27 May 2010 20:58:55 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 27 May 2010 20:58:55 -0700 Message-ID: From: Brian Eaton To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: fielding@gbiv.com, "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 03:59:12 -0000 On Thu, May 27, 2010 at 6:48 PM, Blaine Cook wrote: > On 28 May 2010 02:21, Brian Eaton wrote: >> OAuth 1.0 was unusual in that it required that the server match a hash >> of the URL, rather than the real URL. =A0It's an extra layer of >> indirection and complexity. =A0It doesn't improve security. > > To be more precise, OAuth 1.0 required that the server match a > normalised form of the URL. You're absolutely correct that it doesn't > improve security [over matching the URL], but it *is* more secure than > either not proving that the token bearer provided the URL in the first > place or having the client and server match potentially different > versions of the URL. Cool. Glad we can put Roy's security concern to rest, at least. Bearer tokens vs signed requests is a separate issue entirely. > Which is all to say that it is indeed complex, but much of that > complexity is a result of HTTP libraries trying to hide complexity > from users. I'd echo Roy's assertion that as library support improves, > approaches to URL normalisation will become hidden behind the same > layers of abstraction as constructing query strings and request URIs > are today. I think we're going to get some real data on which approach is easier soon.= =3D) From James.H.Manger@team.telstra.com Thu May 27 21:12:39 2010 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 5884E3A69F7 for ; Thu, 27 May 2010 21:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul4k4+AuJFwQ for ; Thu, 27 May 2010 21:12:35 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 0D1AE3A69FF for ; Thu, 27 May 2010 21:12:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,316,1272808800"; d="scan'208";a="3376451" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 28 May 2010 14:12:23 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5995"; a="2589031" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdni.tcif.telstra.com.au with ESMTP; 28 May 2010 14:12:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Fri, 28 May 2010 14:12:23 +1000 From: "Manger, James H" To: Nat Sakimura Date: Fri, 28 May 2010 14:12:22 +1000 Thread-Topic: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow Thread-Index: Acr9jLfW6pjzzbzCRUK58DL1NF7yIAAjBE5w Message-ID: <255B9BB34FB7D647A506DC292726F6E11263B6402C@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> 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 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 28 May 2010 04:12:39 -0000 V2h5IGFyZSB0aGUgJ3R5cGUnIGFuZCAnaW1tZWRpYXRlJyBwYXJhbWV0ZXJzIHByb3ZpZGVkIGRp cmVjdGx5IChpbiB0aGUgVVJJKSwgaW5zdGVhZCBvZiBpbmRpcmVjdGx5IChpbiB0aGUgcmVzcG9u c2UgdG8gdGhlIHJlcXVlc3RfdXJpKT8NCg0KVGhlIHRleHQgaW1wbGllcyBhbGwgb3RoZXIgcGFy YW1ldGVycyBoYXZlIHRvIHByb3ZpZGVkIGluZGlyZWN0bHkuIElzIHRoZXJlIGFueSBjcml0ZXJp YSBmb3IgY2hvb3Npbmcgd2hldGhlciBhIHBhcmFtZXRlciBNVVNULCBNQVkgb3IgTVVTVCBOT1Qg YmUgcHJvdmlkZWQgaW5kaXJlY3RseT8gDQoNClRoZSBleGFtcGxlIGRvZXNuJ3QgbWF0Y2ggdGhl IHRleHQgYXMgaXQgZGlyZWN0bHkgaW5jbHVkZSBhICdjbGllbnRfaWQnIHBhcmFtZXRlci4NCg0K QWxsb3dpbmcgYW55IHBhcmFtZXRlcnMgdG8gYmUgcHJvdmlkZWQgaW5kaXJlY3RseSBzb3VuZHMg bW9yZSBzZW5zaWJsZS4NCg0KLS0gDQpKYW1lcyBNYW5nZXINCg0KDQotLS0tLS0tLS0tDQpGcm9t OiBOYXQgU2FraW11cmEgW21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb21dIA0KU2VudDogVGh1cnNk YXksIDI3IE1heSAyMDEwIDk6MDcgUE0NClRvOiBEYXZpZCBSZWNvcmRvbg0KQ2M6IE1hbmdlciwg SmFtZXMgSDsgb2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBNb2JpbGUg V2ViQXBwIEZsb3cNCg0KLi4uDQogICBDbGllbnQgUmVxdWVzdHMgQXV0aG9yaXphdGlvbg0KDQog ICAgICAgdHlwZSAgICAgICAgIFJFUVVJUkVELiBUaGUgcGFyYW1ldGVyIHZhbHVlIE1VU1QgYmUg c2V0IHRvIHdlYl9zZXJ2ZXINCg0KICAgICAgIHJlcXVlc3RfdXJsICBSRVFVSVJFRC4gUmVxdWVz dCBmaWxlIHVybCBmcm9tIHdoaWNoIHRoZSBBdXRob3JpemF0aW9uDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTZXJ2ZXIgbWF5IG9idGFpbiB0aGUgcmVxdWVzdCBwYXJhbWV0ZXJzIA0K DQogICAgICAgSW1tZWRpYXRlICAgIE9QVElPTkFMLiBUaGUgcGFyYW1ldGVyIHZhbHVlIG11c3Qg YmUgc2V0IHRvIHRydWUgb3IgZmFsc2UuLi4gDQouLi4NCg0KICBHRVQgL2F1dGhvcml6ZT90eXBl PXdlYl9zZXJ2ZXImY2xpZW50X2lkPXM2QmhkUmtxdDMmcmVkaXJlY3RfdXJpPQ0KICAgICAgaHR0 cHMlM0ElMkYlMkZjbGllbnQlMkVleGFtcGxlJTJFY29tJTJGY2IgSFRUUC8xLjENCiAgSG9zdDog c2VydmVyLmV4YW1wbGUuY29tDQo= From eran@hueniverse.com Thu May 27 22:31:06 2010 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 427803A6A37 for ; Thu, 27 May 2010 22:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.478, 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 8lhFi7CrBWvs for ; Thu, 27 May 2010 22:31: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 29A683A6A2F for ; Thu, 27 May 2010 22:18:54 -0700 (PDT) Received: (qmail 31786 invoked from network); 28 May 2010 05:18:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 May 2010 05:18:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 27 May 2010 22:18:29 -0700 From: Eran Hammer-Lahav To: Blaine Cook , Brian Eaton Date: Thu, 27 May 2010 22:18:21 -0700 Thread-Topic: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr+B/jt4vmaBkSzSs2fLC5dJIPxCgAG7v+w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C510@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "fielding@gbiv.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 05:31:06 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmxhaW5lIENvb2sgW21h aWx0bzpyb21lZGFAZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDI3LCAyMDEwIDY6 NDkgUE0NCj4gVG86IEJyaWFuIEVhdG9uDQo+IENjOiBFcmFuIEhhbW1lci1MYWhhdjsgZmllbGRp bmdAZ2Jpdi5jb207IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gU3ViamVjdDogUmU6IFtP QVVUSC1XR10gRlc6IER1cGxpY2F0aW5nIHJlcXVlc3QgY29tcG9uZW50IGluIGFuIEhUVFANCj4g YXV0aGVudGljYXRpb24gc2NoZW1lDQo+IA0KPiBPbiAyOCBNYXkgMjAxMCAwMjoyMSwgQnJpYW4g RWF0b24gPGJlYXRvbkBnb29nbGUuY29tPiB3cm90ZToNCj4gPiBPQXV0aCAxLjAgd2FzIHVudXN1 YWwgaW4gdGhhdCBpdCByZXF1aXJlZCB0aGF0IHRoZSBzZXJ2ZXIgbWF0Y2ggYSBoYXNoDQo+ID4g b2YgdGhlIFVSTCwgcmF0aGVyIHRoYW4gdGhlIHJlYWwgVVJMLiDCoEl0J3MgYW4gZXh0cmEgbGF5 ZXIgb2YNCj4gPiBpbmRpcmVjdGlvbiBhbmQgY29tcGxleGl0eS4gwqBJdCBkb2Vzbid0IGltcHJv dmUgc2VjdXJpdHkuDQo+IA0KPiBUbyBiZSBtb3JlIHByZWNpc2UsIE9BdXRoIDEuMCByZXF1aXJl ZCB0aGF0IHRoZSBzZXJ2ZXIgbWF0Y2ggYSBub3JtYWxpc2VkDQo+IGZvcm0gb2YgdGhlIFVSTC4N Cg0KTm8gaXQgZG9lc27igJl0Lg0KDQpPQXV0aCAxLjAgcmVxdWlyZXMgdGhlIHNlcnZlciB0byAq aW5kZXBlbmRlbnRseSogbm9ybWFsaXplIHRoZSByZWNlaXZlZCByZXF1ZXN0LiBUaGVyZSBpcyBu byBkdXBsaWNhdGlvbiBvZiBkYXRhIGFuZCB0aGVyZSBpcyBub3RoaW5nIHRvIG1hdGNoLiBUaGVy ZSBhcmUgbGltaXRhdGlvbiBpbiB0aGUgd2F5IHRoZSBVUkkgaXMgbm9ybWFsaXplZCAocGFyYW1l dGVyIG9yZGVyIGlzIG5vdCBrZXB0IGZvciBleGFtcGxlKSwgYnV0IHRoZSBzZXJ2ZXIgd29ya3Mg d2l0aCB0aGUgYWN0dWFsIEhUVFAgcmVxdWVzdCBiaXRzLg0KDQo+IFlvdSdyZSBhYnNvbHV0ZWx5 IGNvcnJlY3QgdGhhdCBpdCBkb2Vzbid0IGltcHJvdmUgc2VjdXJpdHkNCj4gW292ZXIgbWF0Y2hp bmcgdGhlIFVSTF0NCg0KTm90IHN1cmUgSSBnZXQgd2hhdCB5b3UgbWVhbiwgYnV0IGhhdmluZyB0 byBjb21wYXJlIHdoYXQgd2FzIHNpZ25lZCB3aXRoIHdoYXQgd2FzIHJlY2VpdmVkIGFkZHMgYSBw b3RlbnRpYWwgc2VjdXJpdHkgcmlzayBhbmQgY29tcGxleGl0eS4gVGhlcmUgaXMgdmVyeSBsaXR0 bGUgcm9vbSBmb3IgbWlzbWF0Y2ggaW4gMS4wIGFuZCBpbiB0aGUgY3VycmVudCAyLjAgdGV4dC4N Cg0KPiwgYnV0IGl0ICppcyogbW9yZSBzZWN1cmUgdGhhbiBlaXRoZXIgbm90IHByb3ZpbmcgdGhh dA0KPiB0aGUgdG9rZW4gYmVhcmVyIHByb3ZpZGVkIHRoZSBVUkwgaW4gdGhlIGZpcnN0IHBsYWNl IG9yIGhhdmluZyB0aGUgY2xpZW50IGFuZA0KPiBzZXJ2ZXIgbWF0Y2ggcG90ZW50aWFsbHkgZGlm ZmVyZW50IHZlcnNpb25zIG9mIHRoZSBVUkwuDQo+IA0KPiBUaGlzIGlzIGEgcHJvYmxlbSBvZiBs ZWFreSBhYnN0cmFjdGlvbnM6IGlmIEhUVFAgd2FzIHVzZWQgaW4gYSB3YXkgc3VjaCB0aGF0DQo+ IHRoZSBjbGllbnQgdW5lcXVpdm9jYWxseSBhc3NlcnRlZCAiVGhpczoge3h9IGlzIHRoZSB1bmFi cmlkZ2VkIEhUVFAgVVJMIHRoYXQgSQ0KPiBhbSByZXF1ZXN0aW5nIiwgYW5kIHN1Y2ggdGhhdCB7 eH0gd2FzIHByZXNlbnRlZCB1bnRvdWNoZWQgdG8gdGhlIHNlcnZpY2UNCj4gaGFuZGxpbmcgdGhl IHJlcXVlc3QsIHRoZW4gd2Ugd291bGRuJ3QgaGF2ZSB0byB3b3JyeSBhYm91dCBub3JtYWxpc2F0 aW9uLg0KDQpCZXR3ZWVuIHRoZSByZXF1ZXN0IFVSSSBhbmQgSG9zdCBoZWFkZXIsIHlvdSBnb3Qg cHJldHR5IG11Y2ggZXZlcnl0aGluZyB5b3UgbmVlZC4gVGhlIG9ubHkgdGhpbmcgbWlzc2luZyBp cyB0aGUgc2NoZW1lIHdoaWNoIGNhbiBwcm9iYWJseSBiZSBpZ25vcmVkIHNpbmNlIHRoZSBwb3J0 IG51bWJlciBpcyBiZWluZyBzaWduZWQuIFNvbWUgcG9vcmx5IHdyaXR0ZW4gcGxhdGZvcm1zIG1p Z2h0IG5vdCBleHBvc2UgdGhlIHJhdyBIVFRQIHJlcXVlc3QsIGJ1dCB0aGF0IGRvZXNuJ3QgbWVh biBIVFRQIGRvZXNuJ3QgZ2l2ZSB5b3UgZXZlcnl0aGluZyB5b3UgbmVlZCB0byBjb25zdHJ1Y3Qg dGhlIGFic29sdXRlIHJlcXVlc3QgVVJJLg0KDQo+IEFzIGl0IHN0YW5kcywgZ2V0dGluZyBhY2Nl c3MgdG8gdGhlIHJhdyByZXF1ZXN0IFVSTCBpcyByZWxhdGl2ZWx5IGRpZmZpY3VsdCBpbg0KPiBt YW55IGVudmlyb25tZW50cyB0aGF0IGhhbmRsZSBIVFRQIHJlcXVlc3RzLCBhbmQgZXZlbiBtb3Jl IGRpZmZpY3VsdCB0bw0KPiBvYnRhaW4gZnJvbSBIVFRQIGNsaWVudCBsaWJyYXJpZXMsIHNpbmNl IHRoZSBhY3R1YWwgcmVxdWVzdCBVUkkgaXMgb2Z0ZW4NCj4gY29uc3RydWN0ZWQgaW4gYSBwcml2 YXRlIG1ldGhvZCBhdCB0aGUgbGFzdCBtb21lbnQgYmVmb3JlIGEgcmVxdWVzdCBpcw0KPiBhY3R1 YWxseSBtYWRlLg0KPiANCj4gV2hpY2ggaXMgYWxsIHRvIHNheSB0aGF0IGl0IGlzIGluZGVlZCBj b21wbGV4LCBidXQgbXVjaCBvZiB0aGF0IGNvbXBsZXhpdHkgaXMgYQ0KPiByZXN1bHQgb2YgSFRU UCBsaWJyYXJpZXMgdHJ5aW5nIHRvIGhpZGUgY29tcGxleGl0eSBmcm9tIHVzZXJzLiBJJ2QgZWNo byBSb3kncw0KPiBhc3NlcnRpb24gdGhhdCBhcyBsaWJyYXJ5IHN1cHBvcnQgaW1wcm92ZXMsIGFw cHJvYWNoZXMgdG8gVVJMIG5vcm1hbGlzYXRpb24NCj4gd2lsbCBiZWNvbWUgaGlkZGVuIGJlaGlu ZCB0aGUgc2FtZSBsYXllcnMgb2YgYWJzdHJhY3Rpb24gYXMgY29uc3RydWN0aW5nDQo+IHF1ZXJ5 IHN0cmluZ3MgYW5kIHJlcXVlc3QgVVJJcyBhcmUgdG9kYXkuDQoNCkknbSB3aWxsaW5nIHRvIGxp bWl0IHNpZ25hdHVyZXMgdG8gcGxhdGZvcm1zIHRoYXQgZXhwb3NlIHRoZSByYXcgYml0cyBvbiB0 aGUgY2xpZW50IGFuZCBzZXJ2ZXIgc2lkZXMsIG9yIHRoYXQgaW1wbGVtZW50IG5hdGl2ZSBPQXV0 aCBzaWduYXR1cmUgc3VwcG9ydC4gVGhpcyBpcywgYWZ0ZXIgYWxsLCBiZWluZyBsYWJlbGVkIGFu IGFkdmFuY2UgZmVhdHVyZS4uLg0KDQpFSEwNCg== From eran@hueniverse.com Thu May 27 22:52:13 2010 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 EB6CE3A687E for ; Thu, 27 May 2010 22:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_40=-0.185] 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 aeDmQD-RprR0 for ; Thu, 27 May 2010 22:52: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 8045E3A6829 for ; Thu, 27 May 2010 22:52:11 -0700 (PDT) Received: (qmail 5066 invoked from network); 28 May 2010 05:52:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 May 2010 05:52:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 27 May 2010 22:52:01 -0700 From: Eran Hammer-Lahav To: Brian Eaton , Blaine Cook Date: Thu, 27 May 2010 22:51:53 -0700 Thread-Topic: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr+GhoRIq3CLRcUQ/ChTKE0REISWwACxwmQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC25E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@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: "fielding@gbiv.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 05:52:13 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Thursday, May 27, 2010 8:59 PM > To: Blaine Cook > Cc: Eran Hammer-Lahav; fielding@gbiv.com; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP > authentication scheme >=20 > On Thu, May 27, 2010 at 6:48 PM, Blaine Cook wrote: > > On 28 May 2010 02:21, Brian Eaton wrote: > >> OAuth 1.0 was unusual in that it required that the server match a > >> hash of the URL, rather than the real URL. =A0It's an extra layer of > >> indirection and complexity. =A0It doesn't improve security. > > > > To be more precise, OAuth 1.0 required that the server match a > > normalised form of the URL. You're absolutely correct that it doesn't > > improve security [over matching the URL], but it *is* more secure than > > either not proving that the token bearer provided the URL in the first > > place or having the client and server match potentially different > > versions of the URL. >=20 > Cool. Glad we can put Roy's security concern to rest, at least. I disagree. Your signature proposal makes matching worse, but moves the "ca= nonicalization problem" to the server side. You just flipped the problem. T= he client gets much simpler but the server gets potentially less secure (as= a likely result of poor implementation). The server has to compare the HTTP request method, as well as the host, por= t, scheme, and request URI with the signed blob. In the request URI, the ho= st has to compare the path and query parameters, which means it needs some = rules about how to perform this comparison. Does parameter order matters? C= ase sensitivity? Duplicated parameter names? Percent encoding? Starting to sound familiar? Comparing two URIs is notoriously tricky which means servers will need to e= ither allow lose comparison and risk security holes, or require a very stri= ct comparison (such as case sensitive string comparison of the raw request = URI to the signed request URI minus the scheme, host, and port). In such a = case, the client request will often fail because the URI doesn't match (for= the same reasons 1.0 goes through hoops). The only way to avoid all of this is for the server to ignore the HTTP requ= est and only care about what is signed. This means that a client can make a= n HTTP GET request with a signed POST request in the authentication header,= bypassing routing security (Roy's point). Your proposal makes it extremely tempting to cut corners (and when you do, = yes, it is significantly simpler than 1.0). > I think we're going to get some real data on which approach is easier soo= n. =3D) I didn't know 'easier' is a guiding principal in designing security. Someon= e should tell the TLS/SSL folks. :-) --- To be clear, I am not completely against your proposal. But it has a fundamental design flaw in its duplication of HTTP request dat= a. Take the HTTP bits out of the JSON structure and I'm completely supporti= ve (i.e. the signature base string is a simple combination of the HTTP bits= + the provided base64 encoded JSON blob or something like that). Otherwise= , it would need to include specific rules on how the server MUST validate t= he request by comparing the signed bits with the actual request (and it has= to be simpler than the OAuth 1.0 signature base string and current text in= 2.0). Your proposal has parts I really like such as the ability to sign arbitrary= data, beyond just the HTTP request bits. This makes it useful for signing = identity assertions, server responses, etc. But before we get to that, we n= eed to address the duplication problem. Everything we do is a tradeoff between security and simplicity, but it only= works when we make accurate analysis. I haven't seen anything in your resp= onse to Roy to justify your conclusions that we can put it aside. EHL From torsten@lodderstedt.net Thu May 27 23:57:18 2010 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 C3ADC3A6828 for ; Thu, 27 May 2010 23:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 tQhBroJf6ToG for ; Thu, 27 May 2010 23:57:17 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id 118163A6811 for ; Thu, 27 May 2010 23:57:16 -0700 (PDT) Received: from p4fff3288.dip.t-dialin.net ([79.255.50.136] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OHtVC-0005vi-1z; Fri, 28 May 2010 08:57:06 +0200 Message-ID: <4BFF6940.2030904@lodderstedt.net> Date: Fri, 28 May 2010 08:57:04 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dick Hardt References: <4BFAA6AB.8040809@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060504060700020500050701" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? 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, 28 May 2010 06:57:18 -0000 This is a multi-part message in MIME format. --------------060504060700020500050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm refering to a siuation where a single authorization server manages access to multiple resource serveres and a client seeks authorization for some of this resource servers. I assume this would also happen in your scenario once the OP discovers that access to calendar and address book are protected by the same authorization server. How would you envision the authorization process (user consent) and token exchange between OP, authorization server and RP/client in such a situation? regards, Torsten. > Are you referring to my OpenID v.Next NewSocialService scenario? > > What issues do you see doing this in v.Next rather than OAuth? > > Using OpenID allows the client/RP to only discover the user's OP, > which knows where the user's calendar / address book is. > > Having the OP as an intermediary allows it to interact with the user > to select which address book or calendar to provide in a particular > context cleanly solves the multiple service provider issue > > -- Dick > > > On Mon, May 24, 2010 at 10:17 AM, Torsten Lodderstedt > > wrote: > > How many access tokens can be the result of a single OAuth > authorization flow? > > A recent discussion about OpenID Connect on the OpenId mailing > list raised that question and I would like to initiate a > discussion on this list. > > Currently, every flow (and the refresh token request) results in a > single access token and (optionally) a single refresh token. I > think a single access token might not be enough when it comes to > multiple scopes. > > Let's assume a client wants to access the calendar and contact > list of an end-user. Since access to the corresponding resource > servers is managed by the same authorization server, the resources > are distinguished by different scopes, say "calendar" and "contacts". > > The client sends a request > > GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri= > > https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=calendar%20contacts HTTP/1.1 > Host: oauth.example.com > > and after the authorization flow has been conducted sucessfully, > the client's access token request would be answered as follows. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"SlAV32hkKG", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8" > } > > So the token "SlAV32hkKG" must be good for two different protected > resources, "calendar" and "contacts". > > I think this works if: > 1) the token is a handle that can be swoped for user identity and > authorization data during service request or > 2) it is a self-contained token AND both resources are provided by > the same resource server. > > But what if the authorization server issues self-contained tokens > and the resources are hosted on different, independent resource > servers? > > Let's assume the authorization server issues self-contained, > signed, and encrypted bearer tokens. Signature and encryption are > based on shared secrets between authorization server and resource > server. In such a scenario, operational security requires to issue > different tokens with different signature values and to encrypt > those tokens with different keys. Moreover, the resource servers > might need different user attributes and permissions, so even the > tokens payload might differ. > > I believe this scenario will become even more important with the > advent of OpenID Connect. With OpenID connect, every client asking > for an end-user's OpenID (+user data) and, additionally, > authorization for another resource will need at least two tokens > under the assumptions given above. > > In order to support such scenarios, I would propose to return an > array of access tokens from every authorization flow and the > refresh request. An authorization server should know which > resources and scopes are handled by what resource servers and > indicate this relation in the access tokens response structure. > This structure could be as follows. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_tokens":[ > { "token":"SlAV32hkKG", "scopes":["calendar"], > "expires_in":3600}, > { "token":"SlAV32hk34", "scopes":["contacts"], > "expires_in":7200},], > "refresh_token":"8xLOxBtZp8" > } > > The scopes a particular access token is good for are indicated, so > a client library is able to choose the right tokens for services > requests. Alternatively it might suffice (or be better?) to > indicate the sites a token is valid for (proposal of James > Manger). It think there is no need for multiple refresh tokens > because these tokens are handled by the authorization server only. > > In case all resources are handled by the same resource server, the > result would look like > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_tokens":[{ "token":"SlAV32hkKG", "expires_in":3600},], > "refresh_token":"8xLOxBtZp8" > } > > Thoughts? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------060504060700020500050701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm refering to a siuation where a single authorization server manages access to multiple resource serveres and a client seeks authorization for some of this resource servers. I assume this would also happen in your scenario once the OP discovers that access to calendar and address book are protected by the same authorization server. How would you envision the authorization process (user consent) and token exchange between OP, authorization server and RP/client in such a situation?

regards,
Torsten.

Are you referring to my OpenID v.Next NewSocialService scenario?

What issues do you see doing this in v.Next rather than OAuth? 

Using OpenID allows the client/RP to only discover the user's OP, which knows where the user's calendar / address book is.

Having the OP as an intermediary allows it to interact with the user to select which address book or calendar to provide in a particular context cleanly solves the multiple service provider issue

-- Dick


On Mon, May 24, 2010 at 10:17 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
How many access tokens can be the result of a single OAuth authorization flow?

A recent discussion about OpenID Connect on the OpenId mailing list raised that question and I would like to initiate a discussion on this list.

Currently, every flow (and the refresh token request) results in a single access token and (optionally) a single refresh token. I think a single access token might not be enough when it comes to multiple scopes.

Let's assume a client wants to access the calendar and contact list of an end-user. Since access to the corresponding resource servers is managed by the same authorization server, the resources are distinguished by different scopes, say "calendar" and "contacts".

The client sends a request

    GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri=
        https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=calendar%20contacts HTTP/1.1
    Host: oauth.example.com

and after the authorization flow has been conducted sucessfully, the client's access token request would be answered as follows.

    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-store

    {
      "access_token":"SlAV32hkKG",
      "expires_in":3600,
      "refresh_token":"8xLOxBtZp8"
    }

So the token "SlAV32hkKG" must be good for two different protected resources, "calendar" and "contacts".

I think this works if:
1) the token is a handle that can be swoped for user identity and authorization data during service request or
2) it is a self-contained token AND both resources are provided by the same resource server.

But what if the authorization server issues self-contained tokens and the resources are hosted on different, independent resource servers?

Let's assume the authorization server issues self-contained, signed, and encrypted bearer tokens. Signature and encryption are based on shared secrets between authorization server and resource server. In such a scenario, operational security requires to issue different tokens with different signature values and to encrypt those tokens with different keys. Moreover, the resource servers might need different user attributes and permissions, so even the tokens payload might differ.

I believe this scenario will become even more important with the advent of OpenID Connect. With OpenID connect, every client asking for an end-user's OpenID (+user data) and, additionally, authorization for another resource will need at least two tokens under the assumptions given above.

In order to support such scenarios, I would propose to return an array of access tokens from every authorization flow and the refresh request. An authorization server should know which resources and scopes are handled by what resource servers and indicate this relation in the access tokens response structure. This structure could be as follows.

    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-store

    {
      "access_tokens":[
     { "token":"SlAV32hkKG", "scopes":["calendar"], "expires_in":3600},
     { "token":"SlAV32hk34", "scopes":["contacts"], "expires_in":7200},],
      "refresh_token":"8xLOxBtZp8"
    }

The scopes a particular access token is good for are indicated, so a client library is able to choose the right tokens for services requests. Alternatively it might suffice (or be better?) to indicate the sites a token is valid for (proposal of James Manger). It think there is no need for multiple refresh tokens because these tokens are handled by the authorization server only.

In case all resources are handled by the same resource server, the result would look like

    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-store

    {
       "access_tokens":[{ "token":"SlAV32hkKG", "expires_in":3600},],
      "refresh_token":"8xLOxBtZp8"
    }

Thoughts?

regards,
Torsten.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------060504060700020500050701-- From bcampbell@pingidentity.com Fri May 28 08:03:20 2010 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 ABB7F3A691F for ; Fri, 28 May 2010 08:03:20 -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 WBN+MMMWS8wf for ; Fri, 28 May 2010 08:03:19 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8A9BF3A6A3C for ; Fri, 28 May 2010 08:03:19 -0700 (PDT) Received: by gwj19 with SMTP id 19so1026800gwj.31 for ; Fri, 28 May 2010 08:03:05 -0700 (PDT) Received: by 10.224.65.193 with SMTP id k1mr229408qai.158.1275058985282; Fri, 28 May 2010 08:03:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.86.19 with HTTP; Fri, 28 May 2010 08:02:35 -0700 (PDT) From: Brian Campbell Date: Fri, 28 May 2010 09:02:35 -0600 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Some minor issues in draft-ietf-oauth-v2-05 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, 28 May 2010 15:03:20 -0000 Hi all, I'm arriving pretty late to the OAuth party, so please bear with me. I just finished my first end-to-end read of the v2 spec and noticed some minor issues. I wish I had some profound contribution to make but initially it's a lot easier to notice the trivial details :) And sometimes such details are missed by those with more experience because it's easy to glance over things knowing what they are *supposed* to say rather than what they might really say. So hopefully there's still some value in a newbie brining up the tirvial stuff. And with that said, here's what I noticed: * On pages 38/39 in Section 3.10.1 there is a parameter name conflict where "format" is used both for the client indicating the assertion format as well as the requested response format. The parameter is used in other flows for the latter meaning so, for consistency, it seems like it would make sense to rename the assertion format parameter to something like "assertion_format". * In describing the optional "format" parameter the text, 'Defaults to "json" if no omitted' seems to have a typo and maybe need a few more or a few less words :) The same content shows up is in several places on pages 24, 28, 30, 33, 36, 39 & 41. * On pages 28/29 the client polling interval is given inconsistent normative treatment. On page 28 it's a suggestion, "The minimum amount of time in seconds that the client SHOULD wait between polling requests to the token endpoint." but on the next page it's stronger, "The client makes the following request at an arbitrary but reasonable interval which MUST NOT exceed the minimum interval rate provided by the authorization server (if present via the "interval" parameter)." * On page 41 in section 4 after the first example the paragraph starts with "verify the client credential, the validity of the refresh token..." - seems like somethings missing here? Regards, Brian Campbell From wmills@yahoo-inc.com Fri May 28 09:23:35 2010 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 A090F28C0D7 for ; Fri, 28 May 2010 09:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.265 X-Spam-Level: X-Spam-Status: No, score=-17.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] 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 Axs8paztzXXa for ; Fri, 28 May 2010 09:23:34 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 982323A6A4F for ; Fri, 28 May 2010 09:23:34 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o4SGM97K005269; Fri, 28 May 2010 09:22:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:x-originalarrivaltime; b=GX0/nHbM/J1rvJOoTDspOQuVwZWGWME3iamLWkJvnH2g+IxjbwLa1GtmSe1YduvK Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 May 2010 09:22:18 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 May 2010 09:21:41 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217057953CE@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C508@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr+BBuR0Dzqy8pmQGiubSLzImlEzAADj+7AABuiNoA= References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C508@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Eran Hammer-Lahav" , "Brian Eaton" , X-OriginalArrivalTime: 28 May 2010 16:22:18.0273 (UTC) FILETIME=[F11A0110:01CAFE81] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 16:23:35 -0000 I thought one of the fundamental ugly problems is that the client doesn't actually know the full URL authoritatively in all frameworks, because variables get appended to the query string in an unknown order in some cases? Solving that problem seems key. Oauth 1.0 had one solution, which it turns out people tend to get wrong. Brian's proposal solves it a different way with the problem that it makes for data duplication with those associated risks/problems. What other options do we have? > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, May 27, 2010 8:04 PM > To: Brian Eaton; fielding@gbiv.com > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] FW: Duplicating request component in=20 > an HTTP authentication scheme >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Eaton [mailto:beaton@google.com] > > Sent: Thursday, May 27, 2010 6:21 PM >=20 > > OAuth 1.0 was unusual in that it required that the server=20 > match a hash=20 > > of the URL, rather than the real URL. It's an extra layer of=20 > > indirection and complexity. It doesn't improve security. >=20 > The current draft signs the real URL. >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From muralive@gmail.com Fri May 28 09:29:51 2010 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 10BD13A6A65 for ; Fri, 28 May 2010 09:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 8oSl7DwJNpMM for ; Fri, 28 May 2010 09:29:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id CDC303A6A60 for ; Fri, 28 May 2010 09:29:47 -0700 (PDT) Received: by wye20 with SMTP id 20so1025481wye.31 for ; Fri, 28 May 2010 09:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=78meYSs7Y1DzOfXgJPIqFbj18T1562LBa6H6xQPeK68=; b=JfQG5O6ckTuEot3PByaSYHgW9z/pALP9dzbmuNY0oOcZjUTEDpdK//+xgMSmMAsbnc 4UemHmTJ+JM2KAKwEKFEtFgH58tsppqQor/zBZn2CnHy+427NScaUde+3LEIn6xvQ5N8 Rm16KuvrKQkuH+1GqFwkZlv2MqsBEc3Dxvsoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=D+sYeBzWqgcLbVhgiP5mVBP08Ic/2L6RnFch6XzKP4uKf8e4rCz0wi/tnv5mBJTT9j YVweZrlvHVLRy7tUZ3qLXgMfpnPjCJR3YfMiPvVsCNMG6QznWoLlI1aKDlZLKkH5jRP3 RVfJG205XOLcBmq4nkTP/LoXBMVRnZJPH+F2k= Received: by 10.227.154.204 with SMTP id p12mr476244wbw.141.1275064174721; Fri, 28 May 2010 09:29:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.89.141 with HTTP; Fri, 28 May 2010 09:29:14 -0700 (PDT) From: Murali VP Date: Fri, 28 May 2010 09:29:14 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0016364165ef333eda0487aa03ca Subject: [OAUTH-WG] user agent flow 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, 28 May 2010 16:29:51 -0000 --0016364165ef333eda0487aa03ca Content-Type: text/plain; charset=ISO-8859-1 OAuth 2.0 authors or anyone with authority on the draft, would appreciate some response to the below items. 3.5. User-Agent Flow 1. It is not clear from the draft how a user agent flow would refresh an access token. As per section 4, client does a HTTP(S) POST to authorization server which seems to return a 200 to user-agent if the request was successful leaving the user-agent in authorization server's domain with a JSON response data! If user-agent flow cannot refresh access token, why did it send the refresh_token in the first place in the fragment? 2. The draft doesn't seem to mention how a client in the user-agent can make protected resource requests given that such requests would be cross domain. The only viable option seems to be JSONP requests (eg. Facebook). The specification should include some material describing protected resource requests in the user-agent flow case. --0016364165ef333eda0487aa03ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OAuth 2.0 authors or anyone with authority on the draft, would appreciate s= ome response to the below items.

3.5. =A0User-Agent Flow

1. It is not clear from the draft how a user agent flow would refresh
an access token. As per section 4, client does a HTTP(S) POST to
authorization server which seems to return a 200 to user-agent if the
request was successful leaving the user-agent in authorization
server's domain with a JSON response data! If user-agent flow cannot refresh access token, why did it send the refresh_token in the first
place in the fragment?


2. The draft doesn't seem to mention how a client in the user-agent
can make protected resource requests given that such requests would be
cross domain. The only viable option seems to be JSONP requests (eg.
Facebook). The specification should include some material describing
protected resource requests in the user-agent flow case. --0016364165ef333eda0487aa03ca-- From beaton@google.com Fri May 28 11:02:23 2010 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 E31963A683D for ; Fri, 28 May 2010 11:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.77 X-Spam-Level: X-Spam-Status: No, score=-100.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UtoAkL9e5+EM for ; Fri, 28 May 2010 11:02:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C52863A6407 for ; Fri, 28 May 2010 11:02:22 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o4SI28nP020720 for ; Fri, 28 May 2010 11:02:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275069731; bh=yCh/utKrf4KSwhg8ARf85YeY2p0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=wf41oZgMoCXCMIWPFDF9aIyBv+6/z29dd7+Wm6q+pxzf72sJUOZWRJWep+rLGYmsQ CY+EX3Om7q7FZm7YmKeTA== 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=kOhFQIJKdGv4R8SuSQqnNS6L1uX3vJeGJ9RqP8LmPt3ZL7yXhc1M/tSOLWM1kELPV wbotjljbMUre0Gf2JwdYA== Received: from pvg11 (pvg11.prod.google.com [10.241.210.139]) by kpbe16.cbf.corp.google.com with ESMTP id o4SI1kdR006162 for ; Fri, 28 May 2010 11:02:06 -0700 Received: by pvg11 with SMTP id 11so553585pvg.33 for ; Fri, 28 May 2010 11:02:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.3.5 with SMTP id 5mr465050wfc.169.1275069726078; Fri, 28 May 2010 11:02:06 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Fri, 28 May 2010 11:02:05 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC25E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC25E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 28 May 2010 11:02:05 -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: "fielding@gbiv.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 18:02:24 -0000 On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav w= rote: >> Cool. =A0Glad we can put Roy's security concern to rest, at least. > > I disagree. Your signature proposal makes matching worse, but moves the > "canonicalization problem" to the server side. You just flipped the probl= em. > The client gets much simpler but the server gets potentially less secure > (as a likely result of poor implementation). You raise a bunch of really good points in your response, and I'm going to ignore almost all of them for now. =3D) I want to get to the heart of the "potentially less secure" statement. In OAuth 1.0, in order to be secure, the server had to check a signature. [= 1] Under the proposal I made earlier, the same server will need to check a signature, and it will also need to check the intended target of the signed message. That is *not unusual* in authentication protocols. OpenID, SAML, and others all have the exact same requirement. It's documented in their security recommendations. And there are compliance tests that verify that servers do check this. If someone fails to make this check, it will be revealed as soon as anyone looks at their code or tests their server. Cheers, Brian [1] Aside: secure servers actually need to do lots more than check signatures. They need good user management, and key management, and XSS-prevention, and XSRF-prevention, and patch management, and physical security, and so on. But that's out of scope for an authentication protocol. From fielding@gbiv.com Fri May 28 11:28:29 2010 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 98CD63A68C3 for ; Fri, 28 May 2010 11:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=-1.717, BAYES_50=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 C8+xdpe6pA4T for ; Fri, 28 May 2010 11:28:28 -0700 (PDT) Received: from spaceymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id CF0243A6925 for ; Fri, 28 May 2010 11:28:28 -0700 (PDT) Received: from [192.168.1.66] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) by spaceymail-a4.g.dreamhost.com (Postfix) with ESMTP id 1A0931614CD; Fri, 28 May 2010 11:28:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <012AB2B223CB3F4BB846962876F47217057953CE@SNV-EXVS08.ds.corp.yahoo.com> Date: Fri, 28 May 2010 11:28:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C508@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217057953CE@SNV-EXVS08.ds.corp.yahoo.com> To: "William Mills" X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Fri, 28 May 2010 14:21:35 -0700 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 18:28:29 -0000 On May 28, 2010, at 9:21 AM, William Mills wrote: > I thought one of the fundamental ugly problems is that the client > doesn't actually know the full URL authoritatively in all frameworks, > because variables get appended to the query string in an unknown order > in some cases? If the client doesn't know exactly what it is sending, then it isn't a secure client and any signature it might provide is bogus, by definition. Why do you bother to consider such a case? Let the clients fix their own technology. ....Roy From kris.selden@gmail.com Fri May 28 15:21:47 2010 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 6CD663A6879 for ; Fri, 28 May 2010 15:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_40=-0.185, 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 5wAdFKYXj2E4 for ; Fri, 28 May 2010 15:21:44 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id B5DA63A6866 for ; Fri, 28 May 2010 15:21:44 -0700 (PDT) Received: by pzk38 with SMTP id 38so1058461pzk.31 for ; Fri, 28 May 2010 15:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=+sQc52IOUlfgAfg5eezkPiJaxvA/8mJTCgqryrWXBWk=; b=kRkqbuT8SrWGzeY86cuCU/x/VRJgTJauM3oUJ/OQ+zPaKNxxgNE/Jmpy5MPbJI+Twk HuSNOq0/TBVDMtIvTfEdHjYIySsdQRlMFUHoz7qxyTUrEDqKIbdKf+rgeHWOmj5CVu15 RG3yFYS0/SXhX40xoePwaPwO6d6wIatwHAKUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=SAO3/xGdlVkBfq/T8ZQomM3TiOjWZtwxiYRqpptOybPeaUGTTs6oo9dkAcM7V/MTt4 saSeTyjShx5l9TQgPZf5kPIJ9r0cpLHHq58mwis8ayjMVO9sAQ07IyYl83u7wCEMrqvE MQSe1ZUGpAkaMKBtK//ze23jFQJilG+9e2qnU= Received: by 10.115.113.18 with SMTP id q18mr754606wam.220.1275085292164; Fri, 28 May 2010 15:21:32 -0700 (PDT) Received: from [10.210.5.118] (74-94-67-45-tacoma-wa.hfc.comcastbusiness.net [74.94.67.45]) by mx.google.com with ESMTPS id r20sm23145679wam.17.2010.05.28.15.21.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 May 2010 15:21:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-3-425342476 From: Kris Selden In-Reply-To: Date: Fri, 28 May 2010 15:21:25 -0700 Message-Id: <2E90D7D3-DBDC-40CA-97B4-C8BF6590E57D@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC25E@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Brian Eaton X-Mailer: Apple Mail (2.1078) Cc: "fielding@gbiv.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 22:21:47 -0000 --Apple-Mail-3-425342476 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can't you always have the front end web server preserve the original URI = in a header or something before the rewrite engine or application = framework mangle it, right? For example, this Nginx conf that preserves original parts of the = request that get changed when the request is proxied to the upstream web = server: proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header Host $http_host; Or even writing a module that validated the signature and intended = target directly in the web server before the app framework. I guess this makes in hard to write a complete drop-in solution just on = the app framework but that doesn't seem like a good idea anyways. Seems = like libraries that do different modular pieces OAuth are a lot more = useful rather than "plugin" library deciding something like you should = write a nonce to a MySQL DB table every request.=20 On May 28, 2010, at 11:02 AM, Brian Eaton wrote: > On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav = wrote: >>> Cool. Glad we can put Roy's security concern to rest, at least. >>=20 >> I disagree. Your signature proposal makes matching worse, but moves = the >> "canonicalization problem" to the server side. You just flipped the = problem. >> The client gets much simpler but the server gets potentially less = secure >> (as a likely result of poor implementation). >=20 > You raise a bunch of really good points in your response, and I'm > going to ignore almost all of them for now. =3D) >=20 > I want to get to the heart of the "potentially less secure" statement. >=20 > In OAuth 1.0, in order to be secure, the server had to check a = signature. [1] >=20 > Under the proposal I made earlier, the same server will need to check > a signature, and it will also need to check the intended target of the > signed message. >=20 > That is *not unusual* in authentication protocols. OpenID, SAML, and > others all have the exact same requirement. It's documented in their > security recommendations. And there are compliance tests that verify > that servers do check this. If someone fails to make this check, it > will be revealed as soon as anyone looks at their code or tests their > server. >=20 > Cheers, > Brian >=20 > [1] Aside: secure servers actually need to do lots more than check > signatures. They need good user management, and key management, and > XSS-prevention, and XSRF-prevention, and patch management, and > physical security, and so on. But that's out of scope for an > authentication protocol. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-3-425342476 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Can't = you always have the front end web server preserve the original URI in a = header or something before the rewrite engine or application = framework mangle it, right?

For example, this Nginx = conf that preserves original parts of the request that get changed when = the request is proxied to the upstream web server:
  proxy_set_header  X-Real-IP       =   $remote_addr;
  proxy_set_header  X-Forwarded-For   = $proxy_add_x_forwarded_for;
  proxy_set_header  X-Forwarded-Proto = https;
  proxy_set_header  Host       =       =  $http_host;

Or even writing = a module that validated the signature and intended target directly in = the web server before the app = framework.


I guess this makes in = hard to write a complete drop-in solution just on the app framework but = that doesn't seem like a good idea anyways. Seems like libraries that do = different modular pieces OAuth are a lot more useful rather than = "plugin" library deciding something like you should write a nonce to a = MySQL DB table every request. 

On May = 28, 2010, at 11:02 AM, Brian Eaton wrote:

On = Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> = wrote:
Cool. =  Glad we can put Roy's security concern to rest, at = least.

I disagree. = Your signature proposal makes matching worse, but moves = the
"canonicalization problem" = to the server side. You just flipped the = problem.
The client gets much = simpler but the server gets potentially less = secure
(as a likely result of = poor implementation).

You raise a bunch of really = good points in your response, and I'm
going to ignore almost all of = them for now.  =3D)

I want to get to the heart of the = "potentially less secure" statement.

In OAuth 1.0, in order to be = secure, the server had to check a signature. [1]

Under the = proposal I made earlier, the same server will need to check
a = signature, and it will also need to check the intended target of = the
signed message.

That is *not unusual* in authentication = protocols.  OpenID, SAML, and
others all have the exact same = requirement.  It's documented in their
security recommendations. =  And there are compliance tests that verify
that servers do = check this.  If someone fails to make this check, it
will be = revealed as soon as anyone looks at their code or tests = their
server.

Cheers,
Brian

[1] Aside: secure = servers actually need to do lots more than check
signatures. =  They need good user management, and key management, = and
XSS-prevention, and XSRF-prevention, and patch management, = and
physical security, and so on.  But that's out of scope for = an
authentication = protocol.
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail-3-425342476-- From eran@hueniverse.com Fri May 28 15:36:00 2010 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 837B33A693D for ; Fri, 28 May 2010 15:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.575, 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 xFCBuyCpNleO for ; Fri, 28 May 2010 15:35:54 -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 2FAEA3A695E for ; Fri, 28 May 2010 15:35:53 -0700 (PDT) Received: (qmail 21806 invoked from network); 28 May 2010 22:35:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 May 2010 22:35:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 28 May 2010 15:35:42 -0700 From: Eran Hammer-Lahav To: Kris Selden , Brian Eaton Date: Fri, 28 May 2010 15:35:37 -0700 Thread-Topic: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr+tCEW1x3Os0W2TpGWcfp+Fvn1BgAAezjw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC25E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <2E90D7D3-DBDC-40CA-97B4-C8BF6590E57D@gmail.com> In-Reply-To: <2E90D7D3-DBDC-40CA-97B4-C8BF6590E57D@gmail.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_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "fielding@gbiv.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 22:36:00 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's the same thing (in a header or in the attached signed blob). EHL From: Kris Selden [mailto:kris.selden@gmail.com] Sent: Friday, May 28, 2010 3:21 PM To: Brian Eaton Cc: Eran Hammer-Lahav; fielding@gbiv.com; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authen= tication scheme Can't you always have the front end web server preserve the original URI in= a header or something before the rewrite engine or application framework m= angle it, right? For example, this Nginx conf that preserves original parts of the request t= hat get changed when the request is proxied to the upstream web server: proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header Host $http_host; Or even writing a module that validated the signature and intended target d= irectly in the web server before the app framework. I guess this makes in hard to write a complete drop-in solution just on the= app framework but that doesn't seem like a good idea anyways. Seems like l= ibraries that do different modular pieces OAuth are a lot more useful rathe= r than "plugin" library deciding something like you should write a nonce to= a MySQL DB table every request. On May 28, 2010, at 11:02 AM, Brian Eaton wrote: On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav > wrote: Cool. Glad we can put Roy's security concern to rest, at least. I disagree. Your signature proposal makes matching worse, but moves the "canonicalization problem" to the server side. You just flipped the problem= . The client gets much simpler but the server gets potentially less secure (as a likely result of poor implementation). You raise a bunch of really good points in your response, and I'm going to ignore almost all of them for now. =3D) I want to get to the heart of the "potentially less secure" statement. In OAuth 1.0, in order to be secure, the server had to check a signature. [= 1] Under the proposal I made earlier, the same server will need to check a signature, and it will also need to check the intended target of the signed message. That is *not unusual* in authentication protocols. OpenID, SAML, and others all have the exact same requirement. It's documented in their security recommendations. And there are compliance tests that verify that servers do check this. If someone fails to make this check, it will be revealed as soon as anyone looks at their code or tests their server. Cheers, Brian [1] Aside: secure servers actually need to do lots more than check signatures. They need good user management, and key management, and XSS-prevention, and XSRF-prevention, and patch management, and physical security, and so on. But that's out of scope for an authentication protocol. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That̵= 7;s the same thing (in a header or in the attached signed blob).=

 

EHL

 

From:= Kri= s Selden [mailto:kris.selden@gmail.com]
Sent: Friday, May 28, 20= 10 3:21 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; field= ing@gbiv.com; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] F= W: Duplicating request component in an HTTP authentication scheme

 

Can't you always have the front end web server preserve the or= iginal URI in a header or something before the rewrite engine or appli= cation framework mangle it, right?

=  

For example, this Ngin= x conf that preserves original parts of the request that get changed when t= he request is proxied to the upstream web server:

=

  proxy_set_header  X-Real= -IP         $remote_addr;

<= /div>

  proxy_set_header  = ;X-Forwarded-For   $proxy_add_x_forwarded_for;

  proxy_set_header  = ;X-Forwarded-Proto https;

  proxy_set_header  Host       &= nbsp;      $http_host;

 

Or even writing a module that validated the signature and intended target = directly in the web server before the app framework.

 

 

I guess this makes i= n hard to write a complete drop-in solution just on the app framework but t= hat doesn't seem like a good idea anyways. Seems like libraries that do dif= ferent modular pieces OAuth are a lot more useful rather than "plugin&= quot; library deciding something like you should write a nonce to a MySQL D= B table every request. 

 

On May 28, 2010, = at 11:02 AM, Brian Eaton wrote:


On Thu, May 27, 2010 at 10:5= 1 PM, Eran Hammer-Lahav <eran@hue= niverse.com> wrote:

Cool.  Glad we c= an put Roy's security concern to rest, at least.

 

I disagree. Your signature pro= posal makes matching worse, but moves the

&= quot;canonicalization problem" to the server side. You just flipped th= e problem.

The client gets much simpler but= the server gets potentially less secure

(a= s a likely result of poor implementation).


You raise a bunch of rea= lly good points in your response, and I'm
going to ignore almost all of = them for now.  =3D)

I want to get to the heart of the "pot= entially less secure" statement.

In OAuth 1.0, in order to be s= ecure, the server had to check a signature. [1]

Under the proposal I= made earlier, the same server will need to check
a signature, and it wi= ll also need to check the intended target of the
signed message.

= That is *not unusual* in authentication protocols.  OpenID, SAML, and<= br>others all have the exact same requirement.  It's documented in the= ir
security recommendations.  And there are compliance tests that v= erify
that servers do check this.  If someone fails to make this ch= eck, it
will be revealed as soon as anyone looks at their code or tests = their
server.

Cheers,
Brian

[1] Aside: secure servers a= ctually need to do lots more than check
signatures.  They need good= user management, and key management, and
XSS-prevention, and XSRF-preve= ntion, and patch management, and
physical security, and so on.  But= that's out of scope for an
authentication protocol.
________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469P3PW5EX1MB01E_-- From kris.selden@gmail.com Fri May 28 15:45:51 2010 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 67A723A696C for ; Fri, 28 May 2010 15:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=1.253, 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 c+YzYc9MkWrY for ; Fri, 28 May 2010 15:45:50 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id CD1073A6866 for ; Fri, 28 May 2010 15:45:49 -0700 (PDT) Received: by pxi19 with SMTP id 19so786222pxi.31 for ; Fri, 28 May 2010 15:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=jw/VCJnPVcWIe4deF8dorC3qR04bK01O4FS4v7MuEmc=; b=W6NGl/WtQcFnjfriFsSkh8HNbP12rsdy1iSei7QGOHVxlpqMVb7Cy2vrGh0cXCqOcC JqkfZLP9iPr+F9aelDVEwqXEO0IG4fNLOG5JLMh/82yj2DNaiXjuoFh2M+k/a/unTaG6 PNYEshCziupa4rBlCyFNwMuGWy4zHrr4uzwnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=vswzsIWsLswwYq9HoDKPgrFdDnOlaABQjokjtat4Eqq1OOeniXPv7Ml33c3MrBQWrI GvrvsrprkWiUDAxEo8wIgUynFFGWdnOghxZ4e7yWUmP3E7W6huz67Wj09Odf6JbmZxHh x/O9W0yXT5j/afmYMkmJP+63W3ENm2K8HDTYQ= Received: by 10.115.37.28 with SMTP id p28mr774980waj.218.1275086736401; Fri, 28 May 2010 15:45:36 -0700 (PDT) Received: from [10.210.5.118] (74-94-67-45-tacoma-wa.hfc.comcastbusiness.net [74.94.67.45]) by mx.google.com with ESMTPS id n32sm23306852wae.22.2010.05.28.15.45.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 May 2010 15:45:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-4-426789563 From: Kris Selden In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 28 May 2010 15:45:32 -0700 Message-Id: <806FD5A9-5E91-45F8-B3E1-AE6D45C5ADE8@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC25E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <2E90D7D3-DBDC-40CA-97B4-C8BF6590E57D@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "fielding@gbiv.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 22:45:51 -0000 --Apple-Mail-4-426789563 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Except you are in control of your web server so you know you put it = there and where it came from right? On May 28, 2010, at 3:35 PM, Eran Hammer-Lahav wrote: > That=92s the same thing (in a header or in the attached signed blob). > =20 > EHL > =20 > From: Kris Selden [mailto:kris.selden@gmail.com]=20 > Sent: Friday, May 28, 2010 3:21 PM > To: Brian Eaton > Cc: Eran Hammer-Lahav; fielding@gbiv.com; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP = authentication scheme > =20 > Can't you always have the front end web server preserve the original = URI in a header or something before the rewrite engine or application = framework mangle it, right? > =20 > For example, this Nginx conf that preserves original parts of the = request that get changed when the request is proxied to the upstream web = server: > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto https; > proxy_set_header Host $http_host; > =20 > Or even writing a module that validated the signature and intended = target directly in the web server before the app framework. > =20 > =20 > I guess this makes in hard to write a complete drop-in solution just = on the app framework but that doesn't seem like a good idea anyways. = Seems like libraries that do different modular pieces OAuth are a lot = more useful rather than "plugin" library deciding something like you = should write a nonce to a MySQL DB table every request.=20 > =20 > On May 28, 2010, at 11:02 AM, Brian Eaton wrote: >=20 >=20 > On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav = wrote: >=20 > Cool. Glad we can put Roy's security concern to rest, at least. > =20 > I disagree. Your signature proposal makes matching worse, but moves = the > "canonicalization problem" to the server side. You just flipped the = problem. > The client gets much simpler but the server gets potentially less = secure > (as a likely result of poor implementation). >=20 > You raise a bunch of really good points in your response, and I'm > going to ignore almost all of them for now. =3D) >=20 > I want to get to the heart of the "potentially less secure" statement. >=20 > In OAuth 1.0, in order to be secure, the server had to check a = signature. [1] >=20 > Under the proposal I made earlier, the same server will need to check > a signature, and it will also need to check the intended target of the > signed message. >=20 > That is *not unusual* in authentication protocols. OpenID, SAML, and > others all have the exact same requirement. It's documented in their > security recommendations. And there are compliance tests that verify > that servers do check this. If someone fails to make this check, it > will be revealed as soon as anyone looks at their code or tests their > server. >=20 > Cheers, > Brian >=20 > [1] Aside: secure servers actually need to do lots more than check > signatures. They need good user management, and key management, and > XSS-prevention, and XSRF-prevention, and patch management, and > physical security, and so on. But that's out of scope for an > authentication protocol. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 --Apple-Mail-4-426789563 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Except you are in control of your web server so you = know you put it there and where it came from right?

On = May 28, 2010, at 3:35 PM, Eran Hammer-Lahav wrote:

That=92s the same thing (in a header or in the = attached signed blob).
 
EHL
 Kris = Selden [mailto:kris.selden@gmail.com] 
Sent: Friday, May 28, 2010 3:21 = PM
To: Brian = Eaton
Cc: Eran= Hammer-Lahav; fielding@gbiv.com; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] FW: = Duplicating request component in an HTTP authentication = scheme
Can't you always have the front = end web server preserve the original URI in a header or something before = the rewrite engine or application framework mangle it, = right?
For example, this Nginx = conf that preserves original parts of the request that get changed when = the request is proxied to the upstream web = server:
  proxy_set_header  X-Real-IP     =     = $remote_addr;
  proxy_set_header =  X-Forwarded-For   = $proxy_add_x_forwarded_for;
  proxy_set_header =  X-Forwarded-Proto https;
  proxy_set_header  Host   =           =  $http_host;
 
Or even = writing a module that validated the signature and intended target = directly in the web server before the app = framework.
I guess this makes in = hard to write a complete drop-in solution just on the app framework but = that doesn't seem like a good idea anyways. Seems like libraries that do = different modular pieces OAuth are a lot more useful rather than = "plugin" library deciding something like you should write a nonce to a = MySQL DB table every = request. 
On May 28, 2010, at 11:02 = AM, Brian Eaton wrote:
On Thu, May 27, 2010 at = 10:51 PM, Eran Hammer-Lahav <
Cool. =  Glad we can put Roy's security concern to rest, at = least.


You raise a bunch of really good points in your response, = and I'm
going to ignore almost all of them for now.  =3D)

I= want to get to the heart of the "potentially less secure" = statement.

In OAuth 1.0, in order to be secure, the server had to = check a signature. [1]

Under the proposal I made earlier, the = same server will need to check
a signature, and it will also need to = check the intended target of the
signed message.

That is *not = unusual* in authentication protocols.  OpenID, SAML, and
others = all have the exact same requirement.  It's documented in = their
security recommendations.  And there are compliance tests = that verify
that servers do check this.  If someone fails to = make this check, it
will be revealed as soon as anyone looks at their = code or tests their
server.

Cheers,
Brian

[1] Aside: = secure servers actually need to do lots more than check
signatures. =  They need good user management, and key management, = and
XSS-prevention, and XSRF-prevention, and patch management, = and
physical security, and so on.  But that's out of scope for = an
authentication = protocol.
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr+k6tLJxyOvdJ/SpepL/m+D3p/FAAKUHxg References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C508@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F47217057953CE@SNV-EXVS08.ds.corp.yahoo.com> From: "William Mills" To: "Roy T. Fielding" X-OriginalArrivalTime: 28 May 2010 23:26:53.0172 (UTC) FILETIME=[41531B40:01CAFEBD] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 28 May 2010 23:28:24 -0000 So we can define something much simpler than Oauth 1.0, where the complexity was around normalizing the parameters, and if you want to implement signing you have to be able to know what you are actually sending, yes? I'm OK with having some frameworks not capable of signing without being fixed. > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@gbiv.com]=20 > Sent: Friday, May 28, 2010 11:28 AM > To: William Mills > Cc: Eran Hammer-Lahav; Brian Eaton; oauth@ietf.org > Subject: Re: [OAUTH-WG] FW: Duplicating request component in=20 > an HTTP authentication scheme >=20 > On May 28, 2010, at 9:21 AM, William Mills wrote: >=20 > > I thought one of the fundamental ugly problems is that the client=20 > > doesn't actually know the full URL authoritatively in all=20 > frameworks,=20 > > because variables get appended to the query string in an=20 > unknown order=20 > > in some cases? >=20 > If the client doesn't know exactly what it is sending, then=20 > it isn't a secure client and any signature it might provide=20 > is bogus, by definition. Why do you bother to consider such=20 > a case? Let the clients fix their own technology. >=20 > ....Roy >=20 >=20 From eran@hueniverse.com Fri May 28 18:47:55 2010 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 8A6CA3A6916 for ; Fri, 28 May 2010 18:47:55 -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.522, 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 Xantd-cdURJs for ; Fri, 28 May 2010 18:47:48 -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 0477C3A68DE for ; Fri, 28 May 2010 18:47:47 -0700 (PDT) Received: (qmail 13258 invoked from network); 29 May 2010 01:47:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 May 2010 01:47:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 28 May 2010 18:47:33 -0700 From: Eran Hammer-Lahav To: Kris Selden Date: Fri, 28 May 2010 18:47:29 -0700 Thread-Topic: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr+t35bfl1TpB27TWamieA8D0gJxgAGWDdg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC494@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC25E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <2E90D7D3-DBDC-40CA-97B4-C8BF6590E57D@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469@P3PW5EX1MB01.EX1.SECURESERVER.NET> <806FD5A9-5E91-45F8-B3E1-AE6D45C5ADE8@gmail.com> In-Reply-To: <806FD5A9-5E91-45F8-B3E1-AE6D45C5ADE8@gmail.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_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC494P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "fielding@gbiv.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 29 May 2010 01:47:55 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC494P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How is that different than using the authorization header? EHL From: Kris Selden [mailto:kris.selden@gmail.com] Sent: Friday, May 28, 2010 3:46 PM To: Eran Hammer-Lahav Cc: Brian Eaton; fielding@gbiv.com; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authen= tication scheme Except you are in control of your web server so you know you put it there a= nd where it came from right? On May 28, 2010, at 3:35 PM, Eran Hammer-Lahav wrote: That's the same thing (in a header or in the attached signed blob). EHL From: Kris Selden [mailto:kris.selden@gmail.com] Sent: Friday, May 28, 2010 3:21 PM To: Brian Eaton Cc: Eran Hammer-Lahav; fielding@gbiv.com; OAuth W= G (oauth@ietf.org) Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authen= tication scheme Can't you always have the front end web server preserve the original URI in= a header or something before the rewrite engine or application framework m= angle it, right? For example, this Nginx conf that preserves original parts of the request t= hat get changed when the request is proxied to the upstream web server: proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header Host $http_host; Or even writing a module that validated the signature and intended target d= irectly in the web server before the app framework. I guess this makes in hard to write a complete drop-in solution just on the= app framework but that doesn't seem like a good idea anyways. Seems like l= ibraries that do different modular pieces OAuth are a lot more useful rathe= r than "plugin" library deciding something like you should write a nonce to= a MySQL DB table every request. On May 28, 2010, at 11:02 AM, Brian Eaton wrote: On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav > wrote: Cool. Glad we can put Roy's security concern to rest, at least. I disagree. Your signature proposal makes matching worse, but moves the "canonicalization problem" to the server side. You just flipped the problem= . The client gets much simpler but the server gets potentially less secure (as a likely result of poor implementation). You raise a bunch of really good points in your response, and I'm going to ignore almost all of them for now. =3D) I want to get to the heart of the "potentially less secure" statement. In OAuth 1.0, in order to be secure, the server had to check a signature. [= 1] Under the proposal I made earlier, the same server will need to check a signature, and it will also need to check the intended target of the signed message. That is *not unusual* in authentication protocols. OpenID, SAML, and others all have the exact same requirement. It's documented in their security recommendations. And there are compliance tests that verify that servers do check this. If someone fails to make this check, it will be revealed as soon as anyone looks at their code or tests their server. Cheers, Brian [1] Aside: secure servers actually need to do lots more than check signatures. They need good user management, and key management, and XSS-prevention, and XSRF-prevention, and patch management, and physical security, and so on. But that's out of scope for an authentication protocol. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC494P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How is th= at different than using the authorization header?

 

EHL

 =

 

Exc= ept you are in control of your web server so you know you put it there and = where it came from right?

&nbs= p;



 

Can't you always have the front end= web server preserve the original URI in a header or something before the&n= bsp;rewrite engine or application framework mangle it, right?

 

For example, this Nginx conf that preserves orig= inal parts of the request that get changed when the request is proxied to t= he upstream web server:

  proxy_set_header  X-Real-IP   &n= bsp;     $remote_addr;

  proxy_set_header  X-F= orwarded-For   $proxy_add_x_forwarded_for;

  proxy_set_header=  X-Forwarded-Proto https;

  proxy_set_header  Host  = ;            $http_host;

 

Or even writing a module that valid= ated the signature and intended target directly in the web server before th= e app framework.

&= nbsp;

 <= /o:p>

I guess this makes in h= ard to write a complete drop-in solution just on the app framework but that= doesn't seem like a good idea anyways. Seems like libraries that do differ= ent modular pieces OAuth are a lot more useful rather than "plugin&quo= t; library deciding something like you should write a nonce to a MySQL DB t= able every request. 

 

On May 28, 2010, at 11:02 AM, Brian Eaton wrote:




On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
=

Cool.  Glad we can put Roy's se= curity concern to rest, at least.

 

I disagree. Your signat= ure proposal makes matching worse, but moves the

"canonicalization problem" to the server side. Y= ou just flipped the problem.

The= client gets much simpler but the server gets potentially less secure<= /o:p>

(as a likely result of poor implement= ation).


You raise a bunch of really good points in your respo= nse, and I'm
going to ignore almost all of them for now.  =3D)
<= br>I want to get to the heart of the "potentially less secure" st= atement.

In OAuth 1.0, in order to be secure, the server had to chec= k a signature. [1]

Under the proposal I made earlier, the same serve= r will need to check
a signature, and it will also need to check the int= ended target of the
signed message.

That is *not unusual* in auth= entication protocols.  OpenID, SAML, and
others all have the exact = same requirement.  It's documented in their
security recommendation= s.  And there are compliance tests that verify
that servers do chec= k this.  If someone fails to make this check, it
will be revealed a= s soon as anyone looks at their code or tests their
server.

Cheer= s,
Brian

[1] Aside: secure servers actually need to do lots more = than check
signatures.  They need good user management, and key man= agement, and
XSS-prevention, and XSRF-prevention, and patch management, = and
physical security, and so on.  But that's out of scope for anauthentication protocol.
_____________________________________________= __
OAuth mailing list
OAuth@ietf.or= g
https://ww= w.ietf.org/mailman/listinfo/oauth

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC494P3PW5EX1MB01E_-- From kris.selden@gmail.com Fri May 28 19:29:19 2010 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 338F23A6882 for ; Fri, 28 May 2010 19:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 oVwNN1tcw-Ve for ; Fri, 28 May 2010 19:29:16 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 544D53A69D1 for ; Fri, 28 May 2010 19:29:16 -0700 (PDT) Received: by pwi8 with SMTP id 8so871511pwi.31 for ; Fri, 28 May 2010 19:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=vovsZKedf5ZogokMOA2/G3oQ+KyDKTQBGYbJqfNl0BQ=; b=VxUHJQA02KlMcs88EqTD78DUk8njuB5ux18Mkg1NbOeSHvR3bSHYI3TSxi5HX4O+Tu hWKFdwMmucwwRGB0qnVE4BWIBK+ChlHKJe7zrGWs5eRFhE/5+df6nhbG0b9LbJCLiBxS LH2phGo+Amn8jc6W4SZOJ2MU45bjR4XItT+pI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=qXWFxFu9u8slIe2sSn48ldkd9NmwAAn3eHic9Y8Zw/SVMRqyazMKKSxShr2qhVjqPk G2tLPuA44rcFFj5BLKatu/n7EGsejzzqkjEhsmsYVkALnzzqA8bUeXZO23ACTwGOyuHB BD1r7/bTBRpqqNcDVFSFKiswr5zMqEPg7weDE= Received: by 10.142.10.5 with SMTP id 5mr797014wfj.267.1275100143544; Fri, 28 May 2010 19:29:03 -0700 (PDT) Received: from [172.16.2.9] (c-76-121-106-185.hsd1.wa.comcast.net [76.121.106.185]) by mx.google.com with ESMTPS id f11sm24820137wai.11.2010.05.28.19.28.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 May 2010 19:29:01 -0700 (PDT) References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC25E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <2E90D7D3-DBDC-40CA-97B4-C8BF6590E57D@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC469@P3PW5EX1MB01.EX1.SECURESERVER.NET> <806FD5A9-5E91-45F8-B3E1-AE6D45C5ADE8@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC494@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: <0FC473E9-F0FC-46C8-B8B2-90E6CF17B961@gmail.com> From: Kris Selden To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC494@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary=Apple-Mail-1-440192231 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 28 May 2010 19:28:54 -0700 Cc: "fielding@gbiv.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme 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, 29 May 2010 02:29:19 -0000 --Apple-Mail-1-440192231 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Because the authorization header is from the client which isn't =20 trusted like your web front end server. All I was trying to say is the duplication is not necessary because =20 you can workaround it on the server side before it gets mangled by =20 rewrite rules or the app framework. You only need that workaround if =20 you don't have access to the original uri. On May 28, 2010, at 6:47 PM, Eran Hammer-Lahav =20 wrote: > How is that different than using the authorization header? > > > > EHL > > > > From: Kris Selden [mailto:kris.selden@gmail.com] > Sent: Friday, May 28, 2010 3:46 PM > To: Eran Hammer-Lahav > Cc: Brian Eaton; fielding@gbiv.com; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP =20= > authentication scheme > > > > Except you are in control of your web server so you know you put it =20= > there and where it came from right? > > > > On May 28, 2010, at 3:35 PM, Eran Hammer-Lahav wrote: > > > > > That=E2=80=99s the same thing (in a header or in the attached signed = blob). > > > > EHL > > > > From: Kris Selden [mailto:kris.selden@gmail.com] > Sent: Friday, May 28, 2010 3:21 PM > To: Brian Eaton > Cc: Eran Hammer-Lahav; fielding@gbiv.com; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP =20= > authentication scheme > > > > Can't you always have the front end web server preserve the original =20= > URI in a header or something before the rewrite engine or =20 > application framework mangle it, right? > > > > For example, this Nginx conf that preserves original parts of the =20 > request that get changed when the request is proxied to the upstream =20= > web server: > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > proxy_set_header X-Forwarded-Proto https; > > proxy_set_header Host $http_host; > > > > Or even writing a module that validated the signature and intended =20 > target directly in the web server before the app framework. > > > > > > I guess this makes in hard to write a complete drop-in solution just =20= > on the app framework but that doesn't seem like a good idea anyways. =20= > Seems like libraries that do different modular pieces OAuth are a =20 > lot more useful rather than "plugin" library deciding something like =20= > you should write a nonce to a MySQL DB table every request. > > > > On May 28, 2010, at 11:02 AM, Brian Eaton wrote: > > > > > > On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav = > wrote: > > > > Cool. Glad we can put Roy's security concern to rest, at least. > > > > I disagree. Your signature proposal makes matching worse, but moves =20= > the > > "canonicalization problem" to the server side. You just flipped the =20= > problem. > > The client gets much simpler but the server gets potentially less =20 > secure > > (as a likely result of poor implementation). > > > You raise a bunch of really good points in your response, and I'm > going to ignore almost all of them for now. =3D) > > I want to get to the heart of the "potentially less secure" statement. > > In OAuth 1.0, in order to be secure, the server had to check a =20 > signature. [1] > > Under the proposal I made earlier, the same server will need to check > a signature, and it will also need to check the intended target of the > signed message. > > That is *not unusual* in authentication protocols. OpenID, SAML, and > others all have the exact same requirement. It's documented in their > security recommendations. And there are compliance tests that verify > that servers do check this. If someone fails to make this check, it > will be revealed as soon as anyone looks at their code or tests their > server. > > Cheers, > Brian > > [1] Aside: secure servers actually need to do lots more than check > signatures. They need good user management, and key management, and > XSS-prevention, and XSRF-prevention, and patch management, and > physical security, and so on. But that's out of scope for an > authentication protocol. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --Apple-Mail-1-440192231 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Because the authorization header is = from the client which isn't trusted like your web front end = server.

All I was trying to say is the = duplication is not necessary because you can workaround it on the server = side before it gets mangled by rewrite rules or the app framework. You = only need that workaround if you don't have access to the original = uri.

On May 28, 2010, at 6:47 PM, Eran Hammer-Lahav <eran@hueniverse.com> = wrote:

How is that different than using the authorization = header?

 

EHL

 

From: Kris Selden [mailto:kris.selden@gmail.com]
Sent: = Friday, May 28, 2010 3:46 PM
To: Eran = Hammer-Lahav
Cc: Brian Eaton; fielding@gbiv.com; OAuth WG (oauth@ietf.org)
Subject: = Re: [OAUTH-WG] FW: Duplicating request component in an HTTP = authentication scheme

 

Except = you are in control of your web server so you know you put it there and = where it came from right?

 

On May 28, 2010, at 3:35 PM, Eran Hammer-Lahav = wrote:



That=E2=80=99s the same thing (in a header or in = the attached signed blob).

 

EHL

 

From: Kris Selden [mailto:kris.selden@gmail.com] 
Sent: Friday, May 28, 2010 3:21 = PM
To: Brian = Eaton
Cc: Eran= Hammer-Lahav; fielding@gbiv.com; OAuth WG = (oauth@ietf.org)
Subject:<= span class=3D"apple-converted-space"> Re: [OAUTH-WG] FW: = Duplicating request component in an HTTP authentication = scheme

 

Can't you always have the front end web server = preserve the original URI in a header or something before = the rewrite engine or application framework mangle it, = right?

 

For example, this Nginx conf that preserves original = parts of the request that get changed when the request is proxied to the = upstream web server:

  proxy_set_header=  X-Real-IP         = $remote_addr;

  proxy_set_header=  X-Forwarded-For   = $proxy_add_x_forwarded_for;

<= p class=3D"MsoNormal">  proxy_set_header=  X-Forwarded-Proto = https;

  proxy_set_header=  Host             =  $http_host;

 

Or even writing a module that validated the = signature and intended target directly in the web server before the app = framework.

 

 

I guess this makes in hard to write a complete = drop-in solution just on the app framework but that doesn't seem like a = good idea anyways. Seems like libraries that do different modular pieces = OAuth are a lot more useful rather than "plugin" library deciding = something like you should write a nonce to a MySQL DB table every = request. 

 

On May 28, 2010, at 11:02 AM, Brian Eaton = wrote:




On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav = <eran@hueniverse.com> = wrote:


Cool.  Glad we can put Roy's security concern = to rest, at least.

 

I disagree. Your signature proposal makes matching = worse, but moves the

"canonicalization problem" to the server side. You = just flipped the problem.

The client gets much simpler but the server gets = potentially less secure

(as a likely result of poor = implementation).


You raise a bunch of really good = points in your response, and I'm
going to ignore almost all of them = for now.  =3D)

I want to get to the heart of the = "potentially less secure" statement.

In OAuth 1.0, in order to be = secure, the server had to check a signature. [1]

Under the = proposal I made earlier, the same server will need to check
a = signature, and it will also need to check the intended target of = the
signed message.

That is *not unusual* in authentication = protocols.  OpenID, SAML, and
others all have the exact same = requirement.  It's documented in their
security recommendations. =  And there are compliance tests that verify
that servers do = check this.  If someone fails to make this check, it
will be = revealed as soon as anyone looks at their code or tests = their
server.

Cheers,
Brian

[1] Aside: secure = servers actually need to do lots more than check
signatures. =  They need good user management, and key management, = and
XSS-prevention, and XSRF-prevention, and patch management, = and
physical security, and so on.  But that's out of scope for = an
authentication = protocol.
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

 

 

= --Apple-Mail-1-440192231-- From andrewarnott@gmail.com Fri May 28 20:13:47 2010 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 238143A6842 for ; Fri, 28 May 2010 20:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_BACKHAIR_45=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 hysR7iHDdNUm for ; Fri, 28 May 2010 20:13:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id AFA903A65A6 for ; Fri, 28 May 2010 20:13:45 -0700 (PDT) Received: by gyh4 with SMTP id 4so1563094gyh.31 for ; Fri, 28 May 2010 20:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=E4iJl825H0PpR4Nc61XaPuULS7m3Ti1pO763OLibVU8=; b=JbBroUvpp5oMJzU0BROyVANevCF505TL2BW1g6Dxye31hk5CL0DlLs6FeZGBjw1xGj EBIkgocPjebeqs7kg9UtmBJDwtJf0SNCqmOeCZxSMJPkwNOZAjvIMxTrTrSSlf1uFky2 EPp9QxM+y7cWGJ0XnD5Ztj6FWTn3tbFjMo440= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qmZQekRJ4zQ7H6XZ88uG2ccCHW9YQEoDiXtoyBjpmOf2oAgMs+y/CiHrhZzM2+5kpx IzfV3lsA7GM0hY1AsWz4DQyheevUlMo1v4lIVNjzlUVpLMJn9jqmI33ZDU99fa4VREu6 NFPNqNa9CU1jhEk5q7HzWLgYIW2vQ9ymBJwro= MIME-Version: 1.0 Received: by 10.150.255.18 with SMTP id c18mr2471125ybi.141.1275102813011; Fri, 28 May 2010 20:13:33 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Fri, 28 May 2010 20:13:33 -0700 (PDT) Date: Fri, 28 May 2010 20:13:33 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd676a238c1700487b30221 Subject: [OAUTH-WG] Authorization tokens with signatures on query strings and POST entity 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, 29 May 2010 03:13:47 -0000 --000e0cd676a238c1700487b30221 Content-Type: text/plain; charset=ISO-8859-1 The OAuth 2.0 draft 5 spectells about how the Authorization header can contain a Token as well as an optional set of parameters for tokens that have associated secrets. But the query string and POST methods for including the access token does not discuss whether these extra parameters are allowed. Am I missing something, or are tokens with secrets only usable in the Authorization header? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --000e0cd676a238c1700487b30221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The OAuth 2.0 draft 5 spec tells about how the Authorization header = can contain a Token as well as an optional set of parameters for tokens tha= t have associated secrets.=A0 But the query string and POST methods for inc= luding the access token does not discuss whether these extra parameters are= allowed.=A0 Am I missing something, or are tokens with secrets only usable= in the Authorization header?

--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre
--000e0cd676a238c1700487b30221-- From eran@hueniverse.com Fri May 28 20:21:32 2010 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 20EE33A699A for ; Fri, 28 May 2010 20:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.479, 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 U3WuS+O02vtz for ; Fri, 28 May 2010 20:21:31 -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 4493E3A65A6 for ; Fri, 28 May 2010 20:21:31 -0700 (PDT) Received: (qmail 30007 invoked from network); 29 May 2010 03:21:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 May 2010 03:21:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 28 May 2010 20:21:18 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Fri, 28 May 2010 20:21:14 -0700 Thread-Topic: [OAUTH-WG] Authorization tokens with signatures on query strings and POST entity Thread-Index: Acr+3PBvCPkKJSgzQcmh7ryZEh9GuQAAQTlw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC495@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 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_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC495P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization tokens with signatures on query strings and POST entity 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, 29 May 2010 03:21:32 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC495P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yep. You are not missing anything. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Friday, May 28, 2010 8:14 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Authorization tokens with signatures on query strings a= nd POST entity The OAuth 2.0 draft 5 spec tells about how the Authorization header can contain a T= oken as well as an optional set of parameters for tokens that have associat= ed secrets. But the query string and POST methods for including the access= token does not discuss whether these extra parameters are allowed. Am I m= issing something, or are tokens with secrets only usable in the Authorizati= on header? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death = your right to say it." - S. G. Tallentyre --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC495P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yep. You = are not missing anything.

=  

EHL

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: oauth-bounces@ietf.org [mailto:oauth-bounc= es@ietf.org] On Behalf Of Andrew Arnott
Sent: Friday, May = 28, 2010 8:14 PM
To: OAuth WG (oauth@ietf.org)
Subject:= [OAUTH-WG] Authorization tokens with signatures on query strings and POST = entity

 

The OAuth 2.0 draft 5 spec tells about h= ow the Authorization header can contain a Token as well as an optional set = of parameters for tokens that have associated secrets.  But the query = string and POST methods for including the access token does not discuss whe= ther these extra parameters are allowed.  Am I missing something, or a= re tokens with secrets only usable in the Authorization header?

--
Andrew Arnott
"I [may] not agree with what you have t= o say, but I'll defend to the death your right to say it." - S. G. Tal= lentyre

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC495P3PW5EX1MB01E_-- From sakimura@gmail.com Fri May 28 20:24:00 2010 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 A509D3A69D9 for ; Fri, 28 May 2010 20:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 8TycTb2CaYJz for ; Fri, 28 May 2010 20:23:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E0CEB3A699A for ; Fri, 28 May 2010 20:23:58 -0700 (PDT) Received: by gyh4 with SMTP id 4so1566457gyh.31 for ; Fri, 28 May 2010 20:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zvlxfcMmVhEO1JQH/lxBncI6BeZdI3gcmr60kZQKoYk=; b=KdSxa5IWH0TxjCNMDQP0YL1XWdju5aVDeqyd6ZP9LrttaS/DJEkdAaTufyVjt6ESr6 IUnmedVzn/nVkz4RfcDmDhlQCbxntLYKUnoKNV8Ouvv4ubxD6VcVc656l45GHaUnjUFX nuz8Hu127sisJoWPU0lYOjcr4c2+vbYF3goGQ= 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=I6JCebvgP6uzbZAIlq4KcXZ1Bg+PLdlOMRdoEBLfEug8MceNskKme14lD8Dwjat3pS tRpsrBcxLi7Vouf0rf0WLHrJfaQRYSnVYQUaVUk3znNAjfhtN1GYTBkht8CmNxywhqnu DrW30ysjNn98rjiCN1jhU+i1Vu3BjfltvvNu4= MIME-Version: 1.0 Received: by 10.231.185.86 with SMTP id cn22mr1484525ibb.69.1275103425382; Fri, 28 May 2010 20:23:45 -0700 (PDT) Received: by 10.231.31.132 with HTTP; Fri, 28 May 2010 20:23:45 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263B6402C@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263B6402C@WSMSG3153V.srv.dir.telstra.com> Date: Sat, 29 May 2010 12:23:45 +0900 Message-ID: From: Nat Sakimura To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 29 May 2010 03:24:01 -0000 The "type" and "immediate" were the two parameters that I had feedbacks that they want it in the URL. "type" being in the URL is that implementations are using it as a switch. "immediate" was to avoid creating two Request File in the case "immediate" did not succeed. In my original manuscript, neither of them were there in the URL. As to the "example includes client_id in the URL" issue is concerned, the example is wrong. I should remove the client_id from there. All the request parameters MUST be provided through request file. The "request_url" MUST be provided in the URL. I am still not sure if "type" MUST be provided in the URL. Conceptually, it need not be there. It depends on how implementors feel. Any other parameters MAY be provided in the URL to override what is in the request_file, but the URL total length MUST NOT exceed 512 bytes. Would that be reasonable? =3Dnat On Fri, May 28, 2010 at 1:12 PM, Manger, James H wrote: > Why are the 'type' and 'immediate' parameters provided directly (in the U= RI), instead of indirectly (in the response to the request_uri)? > > The text implies all other parameters have to provided indirectly. Is the= re any criteria for choosing whether a parameter MUST, MAY or MUST NOT be p= rovided indirectly? > > The example doesn't match the text as it directly include a 'client_id' p= arameter. > > Allowing any parameters to be provided indirectly sounds more sensible. > > -- > James Manger > > > ---------- > From: Nat Sakimura [mailto:sakimura@gmail.com] > Sent: Thursday, 27 May 2010 9:07 PM > To: David Recordon > Cc: Manger, James H; oauth > Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow > > ... > =A0 Client Requests Authorization > > =A0 =A0 =A0 type =A0 =A0 =A0 =A0 REQUIRED. The parameter value MUST be se= t to web_server > > =A0 =A0 =A0 request_url =A0REQUIRED. Request file url from which the Auth= orization > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Server may obt= ain the request parameters > > =A0 =A0 =A0 Immediate =A0 =A0OPTIONAL. The parameter value must be set to= true or false... > ... > > =A0GET /authorize?type=3Dweb_server&client_id=3Ds6BhdRkqt3&redirect_uri= =3D > =A0 =A0 =A0https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 > =A0Host: server.example.com > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From andrewarnott@gmail.com Fri May 28 20:48:29 2010 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 336B73A6987 for ; Fri, 28 May 2010 20:48:29 -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 fi-vYs2tzKpY for ; Fri, 28 May 2010 20:48:28 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 468563A67E7 for ; Fri, 28 May 2010 20:48:28 -0700 (PDT) Received: by gwj19 with SMTP id 19so1572275gwj.31 for ; Fri, 28 May 2010 20:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ifo+pY7OSX+FGLBY5nlVcyrwAP2GzV+LUT7pZVzznBQ=; b=bZUR2AHXrvgOZBHDLNpQMtTp2Udv7luWNklGhbezRutTzwVj7cohqQfl9Ii9yNPzNv Iop9TtPOPIvUKFgFIrhp39RD38kBf/ATHBRdr4fa3IdFeG+9JUa25j5/mvIwqTEY8BDf ozM/hFi+7qE4csl3ch1CFCPD4UbeX9f3szW5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=glEnBmliMSnB6IBEYXe+tZV7ecmJqMCO1PjtxgAgMBI8Rc/yEIdB+mW/3p1SloItmB b90RxuY2PZWyYJoyzmFUnja9rBCxpQ0FGHAuIBMLnv7bUqml9UnhVl9jcRMZj39FRAbq mN8b5tIp0CMJZ+fs0w+sb2bNW7ZAy7Tvqt29o= MIME-Version: 1.0 Received: by 10.150.67.18 with SMTP id p18mr2517322yba.387.1275104891500; Fri, 28 May 2010 20:48:11 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Fri, 28 May 2010 20:48:11 -0700 (PDT) Date: Fri, 28 May 2010 20:48:11 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd51d841bf9720487b37e42 Subject: [OAUTH-WG] Missing quotes? 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, 29 May 2010 03:48:29 -0000 --000e0cd51d841bf9720487b37e42 Content-Type: text/plain; charset=ISO-8859-1 http://tools.ietf.org/id/draft-ietf-oauth-v2-05.html#authz_header It seems that the spec for the Authorization header requires quotes around the values of everything *except* the algorithm. Look closely at how the <"> substring is absent from the third line. timestamp = "timestamp" "=" <"> 1*DIGIT <"> nonce = "nonce" "=" <"> token <"> algorithm = "algorithm" "=" algorithm-name Is this a mistake? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --000e0cd51d841bf9720487b37e42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/id/draft-ietf-oauth-v2-05.html#authz_header
It seems that the spec for the Authorization header requires quotes ar= ound the values of everything except the algorithm.=A0 Look closely = at how the <"> substring is absent from the third line.
  timestamp        =3D "timestamp" "=3D" <"=
;> 1*DIGIT <">
  nonce            =3D "nonce" &q=
uot;=3D" <"> token <">

  algorithm       =
 =3D "algorithm" "=3D" algorithm-name

Is this a mistake?

--
Andrew Arnott
&q= uot;I [may] not agree with what you have to say, but I'll defend to the= death your right to say it." - S. G. Tallentyre
--000e0cd51d841bf9720487b37e42-- From eran@hueniverse.com Sat May 29 00:40:44 2010 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 92EF73A6981 for ; Sat, 29 May 2010 00:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_40=-0.185, 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 aFPaGFwXZifC for ; Sat, 29 May 2010 00:40:27 -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 99FB63A6767 for ; Sat, 29 May 2010 00:40:26 -0700 (PDT) Received: (qmail 15506 invoked from network); 29 May 2010 07:40:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 May 2010 07:40:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 29 May 2010 00:40:14 -0700 From: Eran Hammer-Lahav To: George Fletcher , Allen Tom Date: Sat, 29 May 2010 00:40:11 -0700 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr924zzUKryw6y+Q9+/goiHa1NJ4gBJoW6Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3E8AC4AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BFED668.8060100@aol.com> In-Reply-To: <4BFED668.8060100@aol.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_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC4AAP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sat, 29 May 2010 07:40:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC4AAP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, and add to that using bearer tokens too (i.e. providers can choose to= only support signed requests if that suits them). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of G= eorge Fletcher Sent: Thursday, May 27, 2010 1:31 PM To: Allen Tom Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth= 2 Thanks, makes sense. +1 to SP's deciding on what signature mech is required= :) On 5/27/10 4:08 PM, Allen Tom wrote: Hi George, The really short summary is that Yahoo is fine with client based signatures= being in the spec, although we do not want Service Providers to be obligat= ed to support them. The decision as to whether or not signatures should be = used, and which signature algorithm to use should be up to the Service Prov= ider. We are very strongly against signatures generated using the client secret f= or the overwhelming majority of our APIs - which is why we want the signatu= re algorithm to be chosen by the SP. A signature using the Access Token sec= ret (without the client secret) is OK, although it's unnecessary for our ap= plications. A plain bearer token by itself (provided that it's only valid = for about an hour) is sufficient for all of Yahoo's services - even without= HTTPS. We'd rather increase security by deploying HTTPS rather than requi= ring developers to sign their requests. Thanks Allen On 5/27/10 11:11 AM, "George Fletcher" wrote: Hmm... to me this says... Yahoo won't deploy PRs that require client_secret signatures, but may have = some internal apps where this is ok. So, to me that sounds like Yahoo is ok with client_secret based signatures= as one way to sign the requests, but they don't want it to be the only way= . I would like to bring back what Dirk has said earlier in this thread... 1. Signing isn't about the token but rather about the message 2. Signing provides message integrity 3. Signing provides (or should allow for) proof of sender I'd like to add... 4. Signing (combined with appropriate information in the AT) enables "right= to present" the token I think that for certain use cases, its critical that the PR be able to ens= ure that the client is "authorized" to present the AT. This isn't possible = for bearer tokens. I also don't believe this hurts sub-delegation because t= he AS can create an AT that can be sub-delegated and when the sub-delegate = presents the AT, the PR can verify that the sub-delegate is allowed to pres= ent that AT. Thanks, George On 5/27/10 12:58 PM, Allen Tom wrote: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 The sh= ort summary is that Yahoo thinks that signatures should not be required for= most use cases. In the exceptional cases where signatures are required, th= en it should be up to the service provider (and not the client) to determin= e when they're required, and which signature algorithm is to be used. Yah= oo does not want to be forced to support signatures generated using the cli= ent secret - we don't even want this to be an option for the overwhelming m= ajority of our APIs. Due to the way services are deployed at Yahoo, our sec= urity team feels that in general, having PR endpoints validate signatures c= omputed using the client secret makes our overall system LESS secure - sinc= e we'd be forced to distribute client secrets to the PR endpoints. Distribu= ting the client secret to the PR endpoints is very undesirable, since doing= so requires that the PR endpoints have the same level of security as the A= S. Having a clean separation between the AS and the PR was one of the goals of= Oauth-WRAP - and having the PR authenticate the client using the client se= cret violates this goal. That being said, Yahoo does have private/internal APIs which require a very= high level of security in which bearer tokens are not sufficient, and sign= atures using the AT secret aren't sufficient either - in these cases, signi= ng the request with the client secret is probably the right way to go. Agai= n - this should be up to the SP to determine that a signature is required, = and how that signature is generated. So what I'm trying to say is - yes there are cases where it's desirable to = have stronger signatures than just signing with the AT secret - however I t= hink that the cases in which signatures are required, and which signature a= lgorithm is to be used should be entirely up to the SP. Does that clarify things? Allen On 5/27/10 9:04 AM, "Dirk Balfanz" wrote: On Thu, May 27, 2010 at 8:56 AM, David Recordon wrote= : I thought Allen clearly said that signing with the client secret won't work= for Yahoo!? Right - but he also said that they (i.e. Yahoo!) wouldn't need signatures a= t all. So I think we're good from the Yahoo! side of things. Allen - did I get this right? Dirk. Hi Dirk- We at Yahoo would be very much against using the client secret for signing = requests to Protected Resources, since this would require that the client s= ecret be distributed to the PR endpoints. For security reasons, one of the = design goals for WRAP was to keep the client secret a secret between only t= he AS and the Client - deliberately separating the authentication of the cl= ient (on the AS) from the serving of the protected resource. >From your post, it's not quite clear what the disadvantage is with using t= he Access Token secret for generating signatures. (forgive me if this was already discussed today - I was very zonked out aft= er 3 days of IIW) Thanks Allen On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz wrote: Sorry, I didn't mean to turn this into a debate over whether we should have= signatures. I think you guys stated your case clearly, and there are other= use cases as well. The questions I was trying to figure out was whether - you'd be ok using the client secret to sign instead of the token secret (= I think I heard David say that that was ok), - you'd be ok with a signature scheme that's sufficiently factored out of t= he rest of the spec that it might warrant it's own companion spec (I agree = that this is getting close to bikeshed territory, so let's worry about this= once we know what the signatures look like). Dirk. On Wed, May 26, 2010 at 2:17 PM, Luke Shepard wrote= : So, when I argued for signatures, the specific use cases we are concerned w= ith: - Mobile handsets and networks that don't support SSL very well - High-volume applications where SSL is a significant cost to both sides - = for Facebook, the top few apps make up a significant amount of API traffic,= so we could do signatures for them and not for everyone else I expect that these are issues that others will encounter as they expand in= to these areas- especially on the mobile side. These are not Facebook-speci= fic issues. That said, I agree with David that we should just figure out what the signa= tures are - I don't really care where they live. If they need to live in a = separate spec then whatever, as long as the specs interoperate very cleanly= . But I would like to hear from other mobile developers if they have tried = OAuth 2.0 with success (Brian, I think you mentioned you may have some data= about that?) On May 26, 2010, at 11:20 AM, David Recordon wrote: How about we figure out the technical details of signatures before figuring= out where they're placed? :) On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz wrote: Ok - to those advocating a separate spec: What if the separate spec was rea= lly simple (a couple of pages), and we just pasted it as "Section X" into t= he core OAuth spec? To Facebook: What if the core OAuth spec had a section called "Signed OAuth= Requests" that (in its extreme form) had the single sentence: "If PRs requ= ire signing, then Clients use the XYZ mechanism to sign their OAuth request= s" (with a link to XYZ)? Dirk. On Wed, May 26, 2010 at 10:55 AM, David Recordon wrot= e: I'd prefer that we keep signatures simple enough that they can remain in th= e core spec. --David On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz wrote: Repeating what I said before: - separate spec is fine by me - part of the point I'm trying to make is that that spec shouldn't be about= signed _tokens_, but instead about signed _HTTP requests_ (so instead of m= erely proving that you know a secret that came with the token, you prove w= ho you are when you use the token). I'd be interested what the Facebook guys think about this - I believe the c= urrent signature scheme is in there mostly to address a use case they had. Luke, Dave - would a separate signing spec be ok with you guys? Dirk. On Tue, May 25, 2010 at 6:56 PM, Allen Tom wrote: +1 I fully agree with Dirk and Brian that there needs to be some work on signatures. There are many types of applications that require higher levels of security than what bearer tokens can provide. That being said, I think that bearer token/refresh token model can satisify the majority of use cases - in fact it would satisfy 100% of all public API= s that we have at Yahoo. Perhaps in the interest of keeping the spec focused, it would make more sense to split out a Signed Token Spec, as Justin proposes, that is focused solely on uses cases that require a signature? Allen On 5/21/10 11:27 AM, "Richer, Justin P." wrote: > I have a slightly more radical proposal. What if we factor out the signed > token use case into a parallel spec? The OAuth 2.0 Signed Token spec, giv= en > the same attention by the group and all that like Eran was talking about > yesterday. What this would take is taking out all reference to signing an= d > making core OAuth just about bare tokens, then have a separate spec that > details what to call your shared secret parameters, how to get them, and = how > to sign with them. This makes the core spec a lot simpler (as detailed be= low) > but makes the overall use case of using signed tokens more complicated to > follow, as it'd be split in two. > > -- justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Dirk > Balfanz [balfanz@google.com] > Sent: Thursday, May 20, 2010 7:39 PM > To: OAuth WG > Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 > > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away wit= h > base string canonicalization, (2) allow for symmetric and public keys, an= d (3) > allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal b= y > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth = 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it = would > work both with the signing mechanism in the current spec, as well as with > Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easi= er to > implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put togeth= er by > Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from = the > spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then= X, > else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like = this: > > "Servers may require that requests be authenticated by the Client, so tha= t > presentation of the access token alone is not sufficient to access a Prot= ected > Resource. This has several use cases, including, but not limited to, the > following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access t= okens > may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. T= he > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, t= hen > the Client uses the following mechanism to sign their HTTP requests: [...= ]" > > Then, we basically drop the old Section 5.3 here (except we use the clien= t > secret instead of the access token secret). Eventually, instead of Sectio= n > 5.3, we may have Brian's new signature scheme section here, which would a= dd > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieve= d > once we have public-key crypto. > > _______________________________________________ > 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC4AAP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] proposal for factoring out reques= t signing in OAuth 2

= Sure, and add to that using bearer tokens too (i.e. providers can ch= oose to only support signed requests if that suits them).=

 

EHL

&nbs= p;

Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.o= rg] On Behalf Of George Fletcher
Sent: Thursday, May 27, 2= 010 1:31 PM
To: Allen Tom
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2

 

Than= ks, makes sense. +1 to SP's deciding on what signature mech is required :)<= /span>

On 5/27/10 4:08 PM, Allen Tom wrote:

Hi George,

The really short sum= mary is that Yahoo is fine with client based signatures being in the spec, = although we do not want Service Providers to be obligated to support them. = The decision as to whether or not signatures should be used, and which sign= ature algorithm to use should be up to the Service Provider.

We are = very strongly against signatures generated using the client secret for the = overwhelming majority of our APIs – which is why we want the signatur= e algorithm to be chosen by the SP. A signature using the Access Token secr= et (without the client secret) is OK, although it’s unnecessary for o= ur applications.  A plain bearer token by itself (provided that itR= 17;s only valid for about an hour) is sufficient for all of Yahoo’s s= ervices – even without HTTPS.  We’d rather increase securi= ty by deploying HTTPS rather than requiring developers to sign their reques= ts.

Thanks
Allen


On 5/27/10 11:11 AM, "George Fle= tcher" <gffletch@aol.com> wrote= :

= Hmm..= . to me this says...

Yahoo won't depl= oy PRs that require client_secret signatures, but may have some internal ap= ps where this is ok.

 So, to me that sounds like Yahoo is ok = with client_secret based signatures as one way to sign the requests, but th= ey don't want it to be the only way.

<= br>I would like to bring back what Dirk has said earlier in this thread...<= br>
1. Signing isn't about the token but rather about the message
2. = Signing provides message integrity
3. Signing provides (or should allow = for) proof of sender

I'd like to add...
4. Signing (combined with= appropriate information in the AT) enables "right to present" th= e token

I think that for certain use cases, its critical that the PR= be able to ensure that the client is "authorized" to present the= AT. This isn't possible for bearer tokens. I also don't believe this hurts= sub-delegation because the AS can create an AT that can be sub-delegated a= nd when the sub-delegate presents the AT, the PR can verify that the sub-de= legate is allowed to present that AT.

Thanks,
George

On 5/= 27/10 12:58 PM, Allen Tom wrote:

Re: [O= AUTH-WG] proposal for factoring out request signing in OAuth 2 The short su= mmary is that Yahoo thinks that signatures should not be required for most = use cases. In the exceptional cases where signatures are required, then it = should be up to the service provider (and not the client) to determine when= they’re required, and  which signature algorithm is to be used.=  Yahoo does not want to be forced to support signatures generated usi= ng the client secret – we don’t even want this to be an option = for the overwhelming majority of our APIs. Due to the way services are depl= oyed at Yahoo, our security team feels that in general, having PR endpoints= validate signatures computed using the client secret makes our overall sys= tem LESS secure – since we’d be forced to distribute client sec= rets to the PR endpoints. Distributing the client secret to the PR endpoint= s is very undesirable, since doing so requires that the PR endpoints have t= he same level of security as the AS.
 
Having a clean separation= between the AS and the PR was one of the goals of Oauth-WRAP – and h= aving the PR authenticate the client using the client secret violates this = goal.
 
That being said, Yahoo does have private/internal APIs = which require a very high level of security in which bearer tokens are not = sufficient, and signatures using the AT secret aren’t sufficient eith= er – in these cases, signing the request with the client secret is pr= obably the right way to go. Again – this should be up to the SP to de= termine that a signature is required, and how that signature is generated.<= br> 
So what I’m trying to say is – yes there are cases= where it’s desirable to have stronger signatures than just signing w= ith the AT secret – however I think that the cases in which signature= s are required, and which signature algorithm is to be used should be entir= ely up to the SP.
 
Does that clarify things?
Allen
 =
 
 
 
On 5/27/10 9:04 AM, "Dirk Balfanz&qu= ot; <balfanz@google.com> wrote: 
  


 
On= Thu, May 27, 2010 at 8:56 AM, David Recordon <recordond@gmail.com> wrote:
  =

I thought Allen clearly said that signing with the client= secret won't work for Yahoo!?
 


Right - but he also said that they (i.e. Yahoo!) wouldn't need signatu= res at all. So I think we're good from the Yahoo! side of things.
 = ;
Allen - did I get this right?
 
Dirk.
 
   


  

Hi Dirk-
 
We at Yahoo would be very = much against using the client secret for signing requests to Protected Reso= urces, since this would require that the client secret be distributed to th= e PR endpoints. For security reasons, one of the design goals for WRAP was = to keep the client secret a secret between only the AS and the Client ̵= 1; deliberately separating the authentication of the client (on the AS) fro= m the serving of the protected resource.
 
>From your post, = it’s not quite clear what the disadvantage is with using the Access T= oken secret for generating signatures.
 
(forgive me if this was= already discussed today - I was very zonked out after 3 days of IIW)
&n= bsp;
Thanks
Allen
 


&n= bsp;
On Thu, May 27, 2010 at 9:41 AM, Dirk Balfanz <balfanz@google.com> wrote:
  =

Sorry, I didn't mean to turn this into a debate ove= r whether we should have signatures. I think you guys stated your case clea= rly, and there are other use cases as well.
 
The questions I w= as trying to figure out was whether
 
- you'd be ok using the c= lient secret to sign instead of the token secret (I think I heard David say= that that was ok),
- you'd be ok with a signature scheme that's suffic= iently factored out of the rest of the spec that it might warrant it's own = companion spec (I agree that this is getting close to bikeshed territory, s= o let's worry about this once we know what the signatures look like).
&n= bsp;
 Dirk.
 

On Wed, May 26, 2010 at = 2:17 PM, Luke Shepard <lshepard@facebo= ok.com> wrote:
  

So= , when I argued for signatures, the specific use cases we are concerned wit= h:
 
- Mobile handsets and networks that don't support SSL very = well
- High-volume applications where SSL is a significant cost to both = sides - for Facebook, the top few apps make up a significant amount of API = traffic, so we could do signatures for them and not for everyone else
&n= bsp;
I expect that these are issues that others will encounter as they e= xpand into these areas- especially on the mobile side. These are not Facebo= ok-specific issues.
 
That said, I agree with David that we shou= ld just figure out what the signatures are - I don't really care where they= live. If they need to live in a separate spec then whatever, as long as th= e specs interoperate very cleanly. But I would like to hear from other mobi= le developers if they have tried OAuth 2.0 with success (Brian, I think you= mentioned you may have some data about that?)
 
On May 26, 2010= , at 11:20 AM, David Recordon wrote:
 
  <= /o:p>

How about we figure out the technical details of sig= natures before figuring out where they're placed? :) </bikeshed>
&= nbsp;
 
On Wed, May 26, 2010 at 12:15 PM, Dirk Balfanz <balfanz@google.com> wrote:
  =

Ok - to those advocating a separate spe= c: What if the separate spec was really simple (a couple of pages), and we = just pasted it as "Section X" into the core OAuth spec?
 =
To Facebook: What if the core OAuth spec had a section called "Sig= ned OAuth Requests" that (in its extreme form) had the single sentence= : "If PRs require signing, then Clients use the XYZ mechanism to sign = their OAuth requests" (with a link to XYZ)?
 
 = Dirk.
 

On Wed, May 26, 2010 at 10:55 AM, David Recor= don <recordond@gmail.com> wrote:<= br>  
I'd prefer that we keep signatures simple enough that th= ey can remain in the core spec.
 
 --David 

 
On Wed, May 26, 2010 at 11:44 AM, Dirk Balfanz <= ;balfanz@google.com> wrote:
 =
 

=

 

 

&n= bsp;

 

 

Repeating what I said before:
 
- separate spec is fine by me- part of the point I'm trying to make is that that spec shouldn't be abo= ut signed _tokens_, but instead about signed _HTTP requests_ (so instead of= merely proving that you know a secret that came with the token, you  = prove who you are when you use the token).
 
I'd be interested = what the Facebook guys think about this - I believe the current signature s= cheme is in there mostly to address a use case they had.
 
Luke,= Dave - would a separate signing spec be ok with you guys?
 
&nb= sp;Dirk.
 

On Tue, May 25, 2010 at 6:56 PM, Al= len Tom <atom@yahoo-inc.com> wrote= :
+1
 
I fully agree with Dirk and Brian that there needs to = be some work on
signatures. There are many types of applications that re= quire higher levels
of security than what bearer tokens can provide.
=  
That being said, I think that bearer token/refresh token model ca= n satisify
the majority of use cases - in fact it would satisfy 100% of = all public APIs
that we have at Yahoo.
 
Perhaps in the inter= est of keeping the spec focused, it would make more
sense to split out a= Signed Token Spec, as Justin proposes, that is focused
solely on uses c= ases that require a signature?
 
Allen
 
 
On 5/21/10 11:27 AM, "Richer, Justin P." <jricher@mitre.org> wrote:
 
>= ; I have a slightly more radical proposal. What if we factor out the signed=
> token use case into a parallel spec? The OAuth 2.0 Signed Token sp= ec, given
> the same attention by the group and all that like Eran wa= s talking about
> yesterday. What this would take is taking out all r= eference to signing and
> making core OAuth just about bare tokens, t= hen have a separate spec that
> details what to call your shared secr= et parameters, how to get them, and how
> to sign with them. This mak= es the core spec a lot simpler (as detailed below)
> but makes the ov= erall use case of using signed tokens more complicated to
> follow, a= s it'd be split in two.
>
>  -- justin
> ___________= _____________________________
> From: oauth-bounces@ietf.org [oauth-bo= unces@ietf.org] On Behalf Of Dirk
> Balfanz [balfanz@google.com]
> Sent: Thursday, May 20, 2010 7:3= 9 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposal for factorin= g out request signing in OAuth 2
>
> Hi guys,
>
> a= t today's interim meeting, we were discussing Brian Eaton's proposal for> OAuth signatures. He was proposing a mechanism that would (1) do away= with
> base string canonicalization, (2) allow for symmetric and pub= lic keys, and (3)
> allow for extensibility.
>
> He got h= omework from the group to prove the feasibility of his proposal by
> = showing a couple of implementations.
>
> In this post, I would = like to introduce another improvement of the OAuth 2
> signing mechan= ism, one which is orthogonal to Brian's proposal (i.e., it would
> wo= rk both with the signing mechanism in the current spec, as well as with
= > Brian's signature mechanism). The goal of my proposal is twofold:
&= gt;
> - it simplifies the spec. It will become more readable and ther= efore easier to
> implement
> - it separates out the mechanisms= for delegated authorization and for
> integrity protection into two = independent pieces, which can be put together by
> Servers and/or Cli= ents like LEGO blocks.
>
> Summary:
>
> - use the c= lient secret instead of the token secret for signing PR access
> requ= ests.
>
> Long version of the proposal:
>
> - remov= e all references to access tokens that are not bearer tokens from the
&g= t; spec.
> - stop calling the access tokens "bearer tokens"= . Call them just "access
> tokens".
> - remove all re= ferences to token secrets from the spec
> - remove all parts of the s= pec that are of the kind "if bearer_token then X,
> else Y"= , and replace them with X.
> - delete section 5.3
> - add a sec= tion called "Request Authentication" that goes something like thi= s:
>
> "Servers may require that requests be authenticated= by the Client, so that
> presentation of the access token alone is n= ot sufficient to access a Protected
> Resource.  This has severa= l use cases, including, but not limited to, the
> following:
><= br>> - Non-repudiation: high-security deployments may require that reque= sts be
> authenticated (signed) in a non-repudiateable way[1]
>= - Access to protected resources is not protected by SSL, so that access to= kens
> may leak.
> - End-to-end-integrity: even if SSL _is_ use= d, network infrastructure may
> strip SSL protection before the reque= st reaches the protected resource. The
> protected resource, however,= may require end-to-end integrity.
>
> If the Server requires t= hat the Client authenticate PR access requests, then
> the Client use= s the following mechanism to sign their HTTP requests: [...]"
><= br>> Then, we basically drop the old Section 5.3 here (except we use the= client
> secret instead of the access token secret). Eventually, ins= tead of Section
> 5.3, we may have Brian's new signature scheme secti= on here, which would add
> the option of public-key crypto[1], etc.>
> What do you guys think?
>
> Dirk.
>
>= ; [1] Technically speaking, the goal of non-repudiation can only be achieve= d
> once we have public-key crypto.
>
> _________________= ______________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=
 
 
 
_________________________________________= ______
OAuth mailing list
 OAuth@ietf= .org
 h= ttps://www.ietf.org/mailman/listinfo/oauth
 
  

 

 

 

 

&= nbsp;



 
 
 

=

=
<= ;ATT00001..txt>
 


 


 


 


 
 

______________________________________= _________
OAuth mailing list
 OAuth@i= etf.org
 https://www.ietf.org/mailman/listinfo/oauth
 




______________________________= _________________
OAuth mailing list
OAuth= @ietf.org
ht= tps://www.ietf.org/mailman/listinfo/oauth

 <= /p>

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3E8AC4AAP3PW5EX1MB01E_-- From andrewarnott@gmail.com Sat May 29 05:21:23 2010 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 50D4F3A6A1C for ; Sat, 29 May 2010 05:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIWqA45Tac1r for ; Sat, 29 May 2010 05:21:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DAB033A677D for ; Sat, 29 May 2010 05:21:21 -0700 (PDT) Received: by gyh4 with SMTP id 4so1716997gyh.31 for ; Sat, 29 May 2010 05:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qmQELFZ9StdwTIehqqzeYreSBiYCZqPuX9XeABa0jM0=; b=o2J6vh8EnBFXk6uNf7yuklE43CDypzOUMn2zswUuKGcDiJvbrRJaeu11HbB16U2gzf pcOgwVcqVo4HH/VSajrZzDArDoFPPrmbDpY0k2Dvny/O8iCdSX5R/Qqdys8rYRC2lZk1 BNvnIAMmzhC5uKg2XnylIVOXhieltlqkl+qRg= 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=ICcSgmuaEjJs3XVywpDxW1knpp+yghbMzp118yr+Op13fze1382PprB9wXsRRkF38A gL8u9DrKrgSfXX8k8EsX+oxEXIkyT6+u9AZrRAJXDklJ/EKiNPm269betxby9hwlSm5m 8KJ2NseZ/u0AEgpEUJO9k53UVr12az6l9gXbE= MIME-Version: 1.0 Received: by 10.151.1.36 with SMTP id d36mr2890609ybi.1.1275135668589; Sat, 29 May 2010 05:21:08 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Sat, 29 May 2010 05:21:08 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 May 2010 05:21:08 -0700 Message-ID: From: Andrew Arnott To: Dirk Balfanz Content-Type: multipart/alternative; boundary=000e0cd5cc4c91145c0487baa802 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sat, 29 May 2010 12:21:23 -0000 --000e0cd5cc4c91145c0487baa802 Content-Type: text/plain; charset=ISO-8859-1 Hi Dirk, If you eradicated access token secrets in favor of signing with client secrets, how would installed apps, where the client secret is worthless and usually blank, authenticate/sign their own requests? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz wrote: > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's proposal for > OAuth signatures. He was proposing a mechanism that would (1) do away with > base string canonicalization, (2) allow for symmetric and public keys, and > (3) allow for extensibility. > > He got homework from the group to prove the feasibility of his proposal by > showing a couple of implementations. > > In this post, I would like to introduce another improvement of the OAuth 2 > signing mechanism, one which is orthogonal to Brian's proposal (i.e., it > would work both with the signing mechanism in the current spec, as well as > with Brian's signature mechanism). The goal of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore easier > to implement > - it separates out the mechanisms for delegated authorization and for > integrity protection into two independent pieces, which can be put together > by Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR access > requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens from > the spec. > - stop calling the access tokens "bearer tokens". Call them just "access > tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token then > X, else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something like > this: > > "Servers may require that requests be authenticated by the Client, so that > presentation of the access token alone is not sufficient to access a > Protected Resource. This has several use cases, including, but not limited > to, the following: > > - Non-repudiation: high-security deployments may require that requests be > authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that access > tokens may leak. > - End-to-end-integrity: even if SSL _is_ used, network infrastructure may > strip SSL protection before the request reaches the protected resource. The > protected resource, however, may require end-to-end integrity. > > If the Server requires that the Client authenticate PR access requests, > then the Client uses the following mechanism to sign their HTTP requests: > [...]" > > Then, we basically drop the old Section 5.3 here (except we use the client > secret instead of the access token secret). Eventually, instead of Section > 5.3, we may have Brian's new signature scheme section here, which would add > the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be achieved > once we have public-key crypto. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd5cc4c91145c0487baa802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dirk,

If you eradicated access token secrets in favor of signing = with client secrets, how would installed apps, where the client secret is w= orthless and usually blank, authenticate/sign their own requests?=A0
--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


On Thu, May 20, 2010 at 4:39 PM, Dirk Ba= lfanz <balfanz@g= oogle.com> wrote:
Hi guys,=A0

at today's interim meeting, we were disc= ussing Brian Eaton's proposal for OAuth signatures. He was proposing a = mechanism that would (1) do away with base string canonicalization, (2) all= ow for symmetric and public keys, and (3) allow for extensibility.=A0

He got homework from the group to prove the feasibility= of his proposal by showing a couple of implementations.=A0

<= /div>
In this post, I would like to introduce another improvement of th= e OAuth 2 signing mechanism, one which is orthogonal to Brian's proposa= l (i.e., it would work both with the signing mechanism in the current spec,= as well as with Brian's signature mechanism). The goal of my proposal = is twofold:

- it simplifies the spec. It will become more readable = and therefore easier to implement
- it separates out the mechanis= ms for delegated authorization and for integrity protection into two indepe= ndent pieces, which can be put together by Servers and/or Clients like LEGO= blocks.

Summary:

- use the client secr= et instead of the token secret for signing PR access requests.
Long version of the proposal:

- remov= e all references to access tokens that are not bearer tokens from the spec.=
- stop calling the access tokens "bearer tokens". Call them = just "access tokens".=A0
- remove all references to tok= en secrets from the spec
- remove all parts of the spec that are = of the kind "if bearer_token then X, else Y", and replace them wi= th X.
- delete section 5.3
- add a section called "Request Au= thentication" that goes something like this:

= "Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a P= rotected Resource. =A0This has several use cases, including, but not limite= d to, the following:

- Non-repudiation: high-security deployments may requir= e that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that acc= ess tokens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure = may strip SSL protection before the request reaches the protected resource.= The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR = access requests, then the Client uses the following mechanism to sign their= HTTP requests: [...]"

Then, we basically dro= p the old Section 5.3 here (except we use the client secret instead of the = access token secret). Eventually, instead of Section 5.3, we may have Brian= 's new signature scheme section here, which would add the option of pub= lic-key crypto[1], etc.

What do you guys think?

Dirk.<= /div>

[1] Technically speaking, the goal of non-repudiat= ion can only be achieved once we have public-key crypto.


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


--000e0cd5cc4c91145c0487baa802-- From andrewarnott@gmail.com Sat May 29 18:28:09 2010 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 2F1123A69C7 for ; Sat, 29 May 2010 18:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.994, 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 B4hG6Grceu4G for ; Sat, 29 May 2010 18:28:07 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by core3.amsl.com (Postfix) with ESMTP id 008773A6958 for ; Sat, 29 May 2010 18:27:56 -0700 (PDT) Received: by ywh12 with SMTP id 12so1800235ywh.19 for ; Sat, 29 May 2010 18:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=U3ONKaKbwfWPz2BZlCmY4Vq9TA8ZnazRHCLAieb+yzs=; b=Ia2dy4WjzPRZ4EsPUeFe0ueYQsyi44YMRQcny0LEN9kV4a8j2Qm+rnlEQtlfGW8SdL 4UnGUU4erSYcc9C9Bh4sXo+LmCMVYnb0LEgCMNKWEL+362twaht46nm/fNrdShVNnzTF vA4PrvizGaRBjddV59Kqk8ezitZatdKdclxlc= 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=q0hnddZALl3D7sdBkMpJao++Ko6eQNH1NhOECvJrCPfnVMfhG8W4riWerUmRq58Z3y Pvo1BK7VSY4uvny0mCb60ldZot5jb9Q7nt5bnXr5A0Zo0yTLazUwvLmuTYxOTU1gVaTY fpnBYOoB9RwjyXIFoXbdNpmRRKUPZkGWhfDk4= MIME-Version: 1.0 Received: by 10.150.242.3 with SMTP id p3mr3321321ybh.130.1275182863023; Sat, 29 May 2010 18:27:43 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Sat, 29 May 2010 18:27:42 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 May 2010 18:27:42 -0700 Message-ID: From: Andrew Arnott To: Dirk Balfanz Content-Type: multipart/alternative; boundary=000e0cd5186692fd580487c5a5e1 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sun, 30 May 2010 01:28:09 -0000 --000e0cd5186692fd580487c5a5e1 Content-Type: text/plain; charset=ISO-8859-1 Perhaps we can say that installed client apps can have client secrets after all, by calling the authorization server and asking for a new client_id and client_secret assignment for that particular app-install. Any thoughts on that? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott wrote: > Hi Dirk, > > If you eradicated access token secrets in favor of signing with client > secrets, how would installed apps, where the client secret is worthless and > usually blank, authenticate/sign their own requests? > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz wrote: > >> Hi guys, >> >> at today's interim meeting, we were discussing Brian Eaton's proposal for >> OAuth signatures. He was proposing a mechanism that would (1) do away with >> base string canonicalization, (2) allow for symmetric and public keys, and >> (3) allow for extensibility. >> >> He got homework from the group to prove the feasibility of his proposal by >> showing a couple of implementations. >> >> In this post, I would like to introduce another improvement of the OAuth 2 >> signing mechanism, one which is orthogonal to Brian's proposal (i.e., it >> would work both with the signing mechanism in the current spec, as well as >> with Brian's signature mechanism). The goal of my proposal is twofold: >> >> - it simplifies the spec. It will become more readable and therefore >> easier to implement >> - it separates out the mechanisms for delegated authorization and for >> integrity protection into two independent pieces, which can be put together >> by Servers and/or Clients like LEGO blocks. >> >> Summary: >> >> - use the client secret instead of the token secret for signing PR access >> requests. >> >> Long version of the proposal: >> >> - remove all references to access tokens that are not bearer tokens from >> the spec. >> - stop calling the access tokens "bearer tokens". Call them just "access >> tokens". >> - remove all references to token secrets from the spec >> - remove all parts of the spec that are of the kind "if bearer_token then >> X, else Y", and replace them with X. >> - delete section 5.3 >> - add a section called "Request Authentication" that goes something like >> this: >> >> "Servers may require that requests be authenticated by the Client, so that >> presentation of the access token alone is not sufficient to access a >> Protected Resource. This has several use cases, including, but not limited >> to, the following: >> >> - Non-repudiation: high-security deployments may require that requests be >> authenticated (signed) in a non-repudiateable way[1] >> - Access to protected resources is not protected by SSL, so that access >> tokens may leak. >> - End-to-end-integrity: even if SSL _is_ used, network infrastructure may >> strip SSL protection before the request reaches the protected resource. The >> protected resource, however, may require end-to-end integrity. >> >> If the Server requires that the Client authenticate PR access requests, >> then the Client uses the following mechanism to sign their HTTP requests: >> [...]" >> >> Then, we basically drop the old Section 5.3 here (except we use the client >> secret instead of the access token secret). Eventually, instead of Section >> 5.3, we may have Brian's new signature scheme section here, which would add >> the option of public-key crypto[1], etc. >> >> What do you guys think? >> >> Dirk. >> >> [1] Technically speaking, the goal of non-repudiation can only be achieved >> once we have public-key crypto. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --000e0cd5186692fd580487c5a5e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps we can say that installed client apps can have client secrets after= all, by calling the authorization server and asking for a new client_id an= d client_secret assignment for that particular app-install.=A0

Any = thoughts on that?
--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


On Sat, May 29, 2010 at 5:21 AM, Andrew = Arnott <andr= ewarnott@gmail.com> wrote:
Hi Dirk,

If you eradicated access token secrets in favor of signing = with client secrets, how would installed apps, where the client secret is w= orthless and usually blank, authenticate/sign their own requests?=A0

--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz <balfanz@google.com>= ; wrote:
=
Hi guys,=A0

at today's interim meeting, we were disc= ussing Brian Eaton's proposal for OAuth signatures. He was proposing a = mechanism that would (1) do away with base string canonicalization, (2) all= ow for symmetric and public keys, and (3) allow for extensibility.=A0

He got homework from the group to prove the feasibility= of his proposal by showing a couple of implementations.=A0

<= /div>
In this post, I would like to introduce another improvement of th= e OAuth 2 signing mechanism, one which is orthogonal to Brian's proposa= l (i.e., it would work both with the signing mechanism in the current spec,= as well as with Brian's signature mechanism). The goal of my proposal = is twofold:

- it simplifies the spec. It will become more readable = and therefore easier to implement
- it separates out the mechanis= ms for delegated authorization and for integrity protection into two indepe= ndent pieces, which can be put together by Servers and/or Clients like LEGO= blocks.

Summary:

- use the client secr= et instead of the token secret for signing PR access requests.
Long version of the proposal:

- remov= e all references to access tokens that are not bearer tokens from the spec.=
- stop calling the access tokens "bearer tokens". Call them = just "access tokens".=A0
- remove all references to tok= en secrets from the spec
- remove all parts of the spec that are = of the kind "if bearer_token then X, else Y", and replace them wi= th X.
- delete section 5.3
- add a section called "Request Au= thentication" that goes something like this:

= "Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a P= rotected Resource. =A0This has several use cases, including, but not limite= d to, the following:

- Non-repudiation: high-security deployments may requir= e that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that acc= ess tokens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure = may strip SSL protection before the request reaches the protected resource.= The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR = access requests, then the Client uses the following mechanism to sign their= HTTP requests: [...]"

Then, we basically dro= p the old Section 5.3 here (except we use the client secret instead of the = access token secret). Eventually, instead of Section 5.3, we may have Brian= 's new signature scheme section here, which would add the option of pub= lic-key crypto[1], etc.

What do you guys think?

Dirk.<= /div>

[1] Technically speaking, the goal of non-repudiat= ion can only be achieved once we have public-key crypto.


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



--000e0cd5186692fd580487c5a5e1-- From torsten@lodderstedt.net Sun May 30 01:46:06 2010 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 EBB1B3A67E2 for ; Sun, 30 May 2010 01:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, 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 QfQw9Uzj6zty for ; Sun, 30 May 2010 01:46:05 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 503823A67B5 for ; Sun, 30 May 2010 01:46:04 -0700 (PDT) Received: from [80.187.98.24] (helo=[10.214.29.88]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OIe9W-0003yw-UV; Sun, 30 May 2010 10:45:52 +0200 References: Message-Id: <1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net> From: Torsten Lodderstedt To: Andrew Arnott In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1-549182832 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Sun, 30 May 2010 10:45:24 +0200 X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sun, 30 May 2010 08:46:07 -0000 --Apple-Mail-1-549182832 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit what is the advantage in comparison to a token secret? How do you want to propagate the client_id and secret to the resource servers? regrards, Torsten. Am 30.05.2010 um 03:27 schrieb Andrew Arnott : > Perhaps we can say that installed client apps can have client > secrets after all, by calling the authorization server and asking > for a new client_id and client_secret assignment for that particular > app-install. > > Any thoughts on that? > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > > On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott > wrote: > Hi Dirk, > > If you eradicated access token secrets in favor of signing with > client secrets, how would installed apps, where the client secret is > worthless and usually blank, authenticate/sign their own requests? > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > > On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz > wrote: > Hi guys, > > at today's interim meeting, we were discussing Brian Eaton's > proposal for OAuth signatures. He was proposing a mechanism that > would (1) do away with base string canonicalization, (2) allow for > symmetric and public keys, and (3) allow for extensibility. > > He got homework from the group to prove the feasibility of his > proposal by showing a couple of implementations. > > In this post, I would like to introduce another improvement of the > OAuth 2 signing mechanism, one which is orthogonal to Brian's > proposal (i.e., it would work both with the signing mechanism in the > current spec, as well as with Brian's signature mechanism). The goal > of my proposal is twofold: > > - it simplifies the spec. It will become more readable and therefore > easier to implement > - it separates out the mechanisms for delegated authorization and > for integrity protection into two independent pieces, which can be > put together by Servers and/or Clients like LEGO blocks. > > Summary: > > - use the client secret instead of the token secret for signing PR > access requests. > > Long version of the proposal: > > - remove all references to access tokens that are not bearer tokens > from the spec. > - stop calling the access tokens "bearer tokens". Call them just > "access tokens". > - remove all references to token secrets from the spec > - remove all parts of the spec that are of the kind "if bearer_token > then X, else Y", and replace them with X. > - delete section 5.3 > - add a section called "Request Authentication" that goes something > like this: > > "Servers may require that requests be authenticated by the Client, > so that presentation of the access token alone is not sufficient to > access a Protected Resource. This has several use cases, including, > but not limited to, the following: > > - Non-repudiation: high-security deployments may require that > requests be authenticated (signed) in a non-repudiateable way[1] > - Access to protected resources is not protected by SSL, so that > access tokens may leak. > - End-to-end-integrity: even if SSL _is_ used, network > infrastructure may strip SSL protection before the request reaches > the protected resource. The protected resource, however, may require > end-to-end integrity. > > If the Server requires that the Client authenticate PR access > requests, then the Client uses the following mechanism to sign their > HTTP requests: [...]" > > Then, we basically drop the old Section 5.3 here (except we use the > client secret instead of the access token secret). Eventually, > instead of Section 5.3, we may have Brian's new signature scheme > section here, which would add the option of public-key crypto[1], etc. > > What do you guys think? > > Dirk. > > [1] Technically speaking, the goal of non-repudiation can only be > achieved once we have public-key crypto. > > > _______________________________________________ > 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 --Apple-Mail-1-549182832 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
what is the advantage in comparison to a token secret?

How do you want to propagate the client_id and secret to the resource servers? 

regrards,
Torsten.


Am 30.05.2010 um 03:27 schrieb Andrew Arnott <andrewarnott@gmail.com>:

Perhaps we can say that installed client apps can have client secrets after all, by calling the authorization server and asking for a new client_id and client_secret assignment for that particular app-install. 

Any thoughts on that?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott <andrewarnott@gmail.com> wrote:
Hi Dirk,

If you eradicated access token secrets in favor of signing with client secrets, how would installed apps, where the client secret is worthless and usually blank, authenticate/sign their own requests? 

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz <balfanz@google.com> wrote:
Hi guys, 

at today's interim meeting, we were discussing Brian Eaton's proposal for OAuth signatures. He was proposing a mechanism that would (1) do away with base string canonicalization, (2) allow for symmetric and public keys, and (3) allow for extensibility. 

He got homework from the group to prove the feasibility of his proposal by showing a couple of implementations. 

In this post, I would like to introduce another improvement of the OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would work both with the signing mechanism in the current spec, as well as with Brian's signature mechanism). The goal of my proposal is twofold:

- it simplifies the spec. It will become more readable and therefore easier to implement
- it separates out the mechanisms for delegated authorization and for integrity protection into two independent pieces, which can be put together by Servers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access requests.

Long version of the proposal:

- remove all references to access tokens that are not bearer tokens from the spec.
- stop calling the access tokens "bearer tokens". Call them just "access tokens". 
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token then X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes something like this:

"Servers may require that requests be authenticated by the Client, so that presentation of the access token alone is not sufficient to access a Protected Resource.  This has several use cases, including, but not limited to, the following:

- Non-repudiation: high-security deployments may require that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that access tokens may leak. 
- End-to-end-integrity: even if SSL _is_ used, network infrastructure may strip SSL protection before the request reaches the protected resource. The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR access requests, then the Client uses the following mechanism to sign their HTTP requests: [...]"

Then, we basically drop the old Section 5.3 here (except we use the client secret instead of the access token secret). Eventually, instead of Section 5.3, we may have Brian's new signature scheme section here, which would add the option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only be achieved once we have public-key crypto.


_______________________________________________
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
--Apple-Mail-1-549182832-- From torsten@lodderstedt.net Sun May 30 08:57:10 2010 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 AA0883A68AD for ; Sun, 30 May 2010 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 1SDbq6Wilnps for ; Sun, 30 May 2010 08:57:10 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id DDED73A684E for ; Sun, 30 May 2010 08:57:09 -0700 (PDT) Received: from p4fff2079.dip.t-dialin.net ([79.255.32.121] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OIksj-00054X-Dg for oauth@ietf.org; Sun, 30 May 2010 17:56:57 +0200 Message-ID: <4C028AC7.5020102@lodderstedt.net> Date: Sun, 30 May 2010 17:56:55 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] Questions about scopes (section 6.1) 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, 30 May 2010 15:57:10 -0000 I have some questions regarding the WWW-Authenticate header's "scope" attribute. The spec states "The "scope" attribute is a space-delimited list of URIs (relative or absolute) indicating the required scope of the access token for accessing the requested resource." Which of the scope URIs are required for accessing the resource server, at least one or all of them? How is an interoperable OAuth2 client supposed to use this atttribute? Shall the client copy the content into the scope parameter of a subsequent authorization request? What is the envisioned behavior if a client seeks for access authorization to different resources, which happen to rely on the same authorization server? Is the client allowed to combine the scope attributes from the WWW-Authenticate header of both resources in a single authorization flow? This would allow the client to obtain authorization with a single flow. From my point of view, reducing the number of authorization flows would improve user experience. How is as equivalence of authorization servers determined (token-uri, user-uri, both)? regards, Torsten. From andrewarnott@gmail.com Sun May 30 09:39:00 2010 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 B141A3A68D3 for ; Sun, 30 May 2010 09:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_BACKHAIR_53=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 2YQ-JTbvCh8a for ; Sun, 30 May 2010 09:38:58 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id A37913A68D5 for ; Sun, 30 May 2010 09:38:58 -0700 (PDT) Received: by gyh4 with SMTP id 4so2249909gyh.31 for ; Sun, 30 May 2010 09:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=M4FL64ppcHvO4NfnnwAAwUnnVc+1Ta27pXewbmPMGT8=; b=Za1yx/NME7/2frmFDV7H4tCpTpYM2tzqnHgcqeqL9y7EYnIQOlOy3M2xdoeXd6tiaT xvDTX7pPTG7RKL8i2MgkPqzIS8TEy5osB1+ouC5Y6wG949t9cJhF40cn/ZdkIhTbXUgB dF0vz2l9JGvPfBGcYICx4mZZKpEKCrN7+yvSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Dbm1KuLgk7DNCD06xT/8e4jE/XIy88V23mL+iolH52+Vv5pJ0XF+j9NwvYSxm2/bZp zEE5CnNlC4jv1xbZF7m8L/mMSLg3pybAVNWuZaMDex3dBqgfrkPGfSNhdfpTh75Uv1Xy 9Y6Id+PyyHgPSm2FrjrON3fiAkzidhJWemXqA= MIME-Version: 1.0 Received: by 10.150.47.33 with SMTP id u33mr4010817ybu.49.1275237524857; Sun, 30 May 2010 09:38:44 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Sun, 30 May 2010 09:38:44 -0700 (PDT) Date: Sun, 30 May 2010 09:38:44 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd70a9cac63510487d25f32 Subject: [OAUTH-WG] Should replay of access token request be allowed? 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, 30 May 2010 16:39:00 -0000 --000e0cd70a9cac63510487d25f32 Content-Type: text/plain; charset=ISO-8859-1 I was reviewing 3.6.2. Client Requests Access Tokenand it occurred to me that there's no requirement in the spec (that I can find) that a given callback URI and verification code can only be exchanged for access and refresh tokens at most once. Should the verification code include an encoded nonce from the auth server so that it is only usable once? I seem to recall one of the social engineering attacks in OAuth 1.0 was mitigated by ensuring that the user authorization could only be redeemed for an access token once. Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --000e0cd70a9cac63510487d25f32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was reviewing 3.6.2.=A0 Client Requests Access Token and it occurred t= o me that there's no requirement in the spec (that I can find) that a g= iven callback URI and verification code can only be exchanged for access an= d refresh tokens at most once.=A0 Should the verification code include an e= ncoded nonce from the auth server so that it is only usable once?

I seem to recall one of the social engineering attacks in OAuth 1.0 was= mitigated by ensuring that the user authorization could only be redeemed f= or an access token once.

Thanks.

--
Andrew A= rnott
"I [may] not agree with what you have to say, but I'll defend to t= he death your right to say it." - S. G. Tallentyre
--000e0cd70a9cac63510487d25f32-- From andrewarnott@gmail.com Sun May 30 09:45:39 2010 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 29AFC3A68C6 for ; Sun, 30 May 2010 09:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_40=-0.185, 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 NHxJSwj+ZumD for ; Sun, 30 May 2010 09:45:36 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D54FA3A68B3 for ; Sun, 30 May 2010 09:45:35 -0700 (PDT) Received: by gyh4 with SMTP id 4so2252294gyh.31 for ; Sun, 30 May 2010 09:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ryu24kcJ46ULdAf+4akf2OtQXib9R9cPVvopf0GAvAk=; b=uFm/sj9TypXXx2DnLrKH7EkjmUh7GWF9hJxytpMI357XZyDcWRjL45VvEZAXGvfLDL 0SZ9BRvHDroy2NcLGJl9saMrRUbpHubkIxJNEKKmGIjhWQikIcHRyr9hQatY+1s9OVHm ksWJUR71VX4zuuOgRH1M8O5XKIJtpLsLWPB8M= 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=ck0z7y7eKislpt0IfKEcAYUeMBgkRTlFPLtB4RdSTkkaj20U3s/RrDBfIHP2mq5x5O DtfnpuynkzFxl1KAmPFEGv9ofUN0Qfz6BDNT6+LXB9uYpWtoqYpmt+hcfi/G8rA599OY kpsmMf1B1NxC8Am+AgOerXamTO51AL2ywh3n4= MIME-Version: 1.0 Received: by 10.150.160.18 with SMTP id i18mr4258097ybe.100.1275237921316; Sun, 30 May 2010 09:45:21 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Sun, 30 May 2010 09:45:21 -0700 (PDT) In-Reply-To: <1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net> References: <1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net> Date: Sun, 30 May 2010 09:45:21 -0700 Message-ID: From: Andrew Arnott To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=000e0cd7615a4de0ee0487d27787 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sun, 30 May 2010 16:45:39 -0000 --000e0cd7615a4de0ee0487d27787 Content-Type: text/plain; charset=ISO-8859-1 The advantage over using token secrets as it seems to me is that neither auth server nor resource server need to store any issued access tokens because they could be self-describing and signed. By having token secrets I think storing every issued token at the auth server or resource server side is almost unavoidable. I say "almost" because theoretically the token secret could be encrypted and included in the token itself, such that only the auth/resource server could decrypt the secret, then use that secret to verify the signature. This is likely more trouble than it's worth for some applications. I don't have a solution to the "avoid sharing client secret with resource servers" problem. Some good points were made I think in this thread about how that would need to be solved. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Sun, May 30, 2010 at 1:45 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > what is the advantage in comparison to a token secret? > > How do you want to propagate the client_id and secret to the resource > servers? > > regrards, > Torsten. > > > Am 30.05.2010 um 03:27 schrieb Andrew Arnott : > > Perhaps we can say that installed client apps can have client secrets after > all, by calling the authorization server and asking for a new client_id and > client_secret assignment for that particular app-install. > > Any thoughts on that? > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott < > andrewarnott@gmail.com> wrote: > >> Hi Dirk, >> >> If you eradicated access token secrets in favor of signing with client >> secrets, how would installed apps, where the client secret is worthless and >> usually blank, authenticate/sign their own requests? >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the death >> your right to say it." - S. G. Tallentyre >> >> >> On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz < >> balfanz@google.com> wrote: >> >>> Hi guys, >>> >>> at today's interim meeting, we were discussing Brian Eaton's proposal for >>> OAuth signatures. He was proposing a mechanism that would (1) do away with >>> base string canonicalization, (2) allow for symmetric and public keys, and >>> (3) allow for extensibility. >>> >>> He got homework from the group to prove the feasibility of his proposal >>> by showing a couple of implementations. >>> >>> In this post, I would like to introduce another improvement of the OAuth >>> 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it >>> would work both with the signing mechanism in the current spec, as well as >>> with Brian's signature mechanism). The goal of my proposal is twofold: >>> >>> - it simplifies the spec. It will become more readable and therefore >>> easier to implement >>> - it separates out the mechanisms for delegated authorization and for >>> integrity protection into two independent pieces, which can be put together >>> by Servers and/or Clients like LEGO blocks. >>> >>> Summary: >>> >>> - use the client secret instead of the token secret for signing PR access >>> requests. >>> >>> Long version of the proposal: >>> >>> - remove all references to access tokens that are not bearer tokens from >>> the spec. >>> - stop calling the access tokens "bearer tokens". Call them just "access >>> tokens". >>> - remove all references to token secrets from the spec >>> - remove all parts of the spec that are of the kind "if bearer_token then >>> X, else Y", and replace them with X. >>> - delete section 5.3 >>> - add a section called "Request Authentication" that goes something like >>> this: >>> >>> "Servers may require that requests be authenticated by the Client, so >>> that presentation of the access token alone is not sufficient to access a >>> Protected Resource. This has several use cases, including, but not limited >>> to, the following: >>> >>> - Non-repudiation: high-security deployments may require that requests be >>> authenticated (signed) in a non-repudiateable way[1] >>> - Access to protected resources is not protected by SSL, so that access >>> tokens may leak. >>> - End-to-end-integrity: even if SSL _is_ used, network infrastructure may >>> strip SSL protection before the request reaches the protected resource. The >>> protected resource, however, may require end-to-end integrity. >>> >>> If the Server requires that the Client authenticate PR access requests, >>> then the Client uses the following mechanism to sign their HTTP requests: >>> [...]" >>> >>> Then, we basically drop the old Section 5.3 here (except we use the >>> client secret instead of the access token secret). Eventually, instead of >>> Section 5.3, we may have Brian's new signature scheme section here, which >>> would add the option of public-key crypto[1], etc. >>> >>> What do you guys think? >>> >>> Dirk. >>> >>> [1] Technically speaking, the goal of non-repudiation can only be >>> achieved once we have public-key crypto. >>> >>> >>> _______________________________________________ >>> 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 > > --000e0cd7615a4de0ee0487d27787 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The advantage over using token secrets as it seems to me is that neither au= th server nor resource server need to store any issued access tokens becaus= e they could be self-describing and signed.=A0 By having token secrets I th= ink storing every issued token at the auth server or resource server side i= s almost unavoidable.=A0 I say "almost" because theoretically the= token secret could be encrypted and included in the token itself, such tha= t only the auth/resource server could decrypt the secret, then use that sec= ret to verify the signature.=A0 This is likely more trouble than it's w= orth for some applications.

I don't have a solution to the "avoid sharing client secret wi= th resource servers" problem.=A0 Some good points were made I think in= this thread about how that would need to be solved.=A0
-= -
Andrew Arnott
"I [may] not agree with what you have to say, but I&#= 39;ll defend to the death your right to say it." - S. G. Tallentyre

On Sun, May 30, 2010 at 1:45 AM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
what is the advantage in comparison to a toke= n secret?

How do you want to propagate the client_= id and secret to the resource servers?=A0

regrards,
Torsten.


Am 30.05.2010 um 03:27 schrieb Andrew A= rnott <andre= warnott@gmail.com>:

<= div>
Perhaps we can say that installed clie= nt apps can have client secrets after all, by calling the authorization ser= ver and asking for a new client_id and client_secret assignment for that pa= rticular app-install.=A0

Any thoughts on that?
--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


On Sat, May 29, 2010 at 5:21 AM, Andrew = Arnott <andrewarnott@gmail.com> wrote:
Hi Dirk,

If you eradicated access token secrets in favor of signing = with client secrets, how would installed apps, where the client secret is w= orthless and usually blank, authenticate/sign their own requests?=A0

--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


On Thu, May = 20, 2010 at 4:39 PM, Dirk Balfanz <balfanz@google.com> wrote:
=
Hi guys,=A0

at today's interim meeting, we were disc= ussing Brian Eaton's proposal for OAuth signatures. He was proposing a = mechanism that would (1) do away with base string canonicalization, (2) all= ow for symmetric and public keys, and (3) allow for extensibility.=A0

He got homework from the group to prove the feasibility= of his proposal by showing a couple of implementations.=A0

<= /div>
In this post, I would like to introduce another improvement of th= e OAuth 2 signing mechanism, one which is orthogonal to Brian's proposa= l (i.e., it would work both with the signing mechanism in the current spec,= as well as with Brian's signature mechanism). The goal of my proposal = is twofold:

- it simplifies the spec. It will become more readable = and therefore easier to implement
- it separates out the mechanis= ms for delegated authorization and for integrity protection into two indepe= ndent pieces, which can be put together by Servers and/or Clients like LEGO= blocks.

Summary:

- use the client secr= et instead of the token secret for signing PR access requests.
Long version of the proposal:

- remov= e all references to access tokens that are not bearer tokens from the spec.=
- stop calling the access tokens "bearer tokens". Call them = just "access tokens".=A0
- remove all references to tok= en secrets from the spec
- remove all parts of the spec that are = of the kind "if bearer_token then X, else Y", and replace them wi= th X.
- delete section 5.3
- add a section called "Request Au= thentication" that goes something like this:

= "Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a P= rotected Resource. =A0This has several use cases, including, but not limite= d to, the following:

- Non-repudiation: high-security deployments may requir= e that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that acc= ess tokens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure = may strip SSL protection before the request reaches the protected resource.= The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR = access requests, then the Client uses the following mechanism to sign their= HTTP requests: [...]"

Then, we basically dro= p the old Section 5.3 here (except we use the client secret instead of the = access token secret). Eventually, instead of Section 5.3, we may have Brian= 's new signature scheme section here, which would add the option of pub= lic-key crypto[1], etc.

What do you guys think?

Dirk.<= /div>

[1] Technically speaking, the goal of non-repudiat= ion can only be achieved once we have public-key crypto.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
<= /a>https://www.ietf.org/mailman/listinfo/oauth



___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth

--000e0cd7615a4de0ee0487d27787-- From dick.hardt@gmail.com Sun May 30 09:47:46 2010 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 C353E3A681B for ; Sun, 30 May 2010 09:47:46 -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 i72BVP0QEr+c for ; Sun, 30 May 2010 09:47:46 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id B7A153A68DF for ; Sun, 30 May 2010 09:47:44 -0700 (PDT) Received: by pxi19 with SMTP id 19so1320594pxi.31 for ; Sun, 30 May 2010 09:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=naeI1YwnsU+ylhLYCwYbHNym7C43ReXQNfCaKSgjqZ8=; b=n1+kiOeDH8SxfaOCBiByDItOHvAjS+aP/gaPS+HhzkJQc9134WKenwKUGJocIh+x1c sUeigwfIsBVj4K4HrOMmFifaFhu46zRGNsCakkxnOe+JMJTXZUB0AjsySrLwnD+2aH91 XK9p7ANV4+fZ/OnKUAAHeqHFxaYQ7VSwmem/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=tW/xHl+6nIkdRFfOqVnEU4fpbSQRNF+qHcr1bwTHIeyQymNipvagL7ron/7n6IHOH2 aRkvA/0qC0mCpVg9R1qguNZr0CrMhLK0EvSbpA1XLIGo/nEFrJ7t3bQxNQyCxD3sUkDN ogdQtv2ziWB6kpxnIFaQy3u+XhKKZP4dCTpxc= Received: by 10.114.249.24 with SMTP id w24mr2538860wah.217.1275238050529; Sun, 30 May 2010 09:47:30 -0700 (PDT) Received: from [10.0.1.12] ([24.130.32.55]) by mx.google.com with ESMTPS id b6sm41134428wam.9.2010.05.30.09.47.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 May 2010 09:47:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-66-578104564 From: Dick Hardt In-Reply-To: Date: Sun, 30 May 2010 09:47:27 -0700 Message-Id: References: To: Andrew Arnott X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Should replay of access token request be allowed? 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, 30 May 2010 16:47:47 -0000 --Apple-Mail-66-578104564 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think so. In WRAP the verification code was RECOMMENDED one time use. On 2010-05-30, at 9:38 AM, Andrew Arnott wrote: > I was reviewing 3.6.2. Client Requests Access Token and it occurred = to me that there's no requirement in the spec (that I can find) that a = given callback URI and verification code can only be exchanged for = access and refresh tokens at most once. Should the verification code = include an encoded nonce from the auth server so that it is only usable = once? >=20 > I seem to recall one of the social engineering attacks in OAuth 1.0 = was mitigated by ensuring that the user authorization could only be = redeemed for an access token once. >=20 > Thanks. >=20 > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the = death your right to say it." - S. G. Tallentyre > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-66-578104564 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I think so. In WRAP the verification code was RECOMMENDED one time use.

On 2010-05-30, at 9:38 AM, Andrew Arnott wrote:

I was reviewing 3.6.2.  Client Requests Access Token and it occurred to me that there's no requirement in the spec (that I can find) that a given callback URI and verification code can only be exchanged for access and refresh tokens at most once.  Should the verification code include an encoded nonce from the auth server so that it is only usable once?

I seem to recall one of the social engineering attacks in OAuth 1.0 was mitigated by ensuring that the user authorization could only be redeemed for an access token once.

Thanks.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-66-578104564-- From torsten@lodderstedt.net Sun May 30 11:56:07 2010 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 2A53F3A68DC for ; Sun, 30 May 2010 11:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 XVqQ6M26kNuY for ; Sun, 30 May 2010 11:56:05 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id 0C2043A681B for ; Sun, 30 May 2010 11:56:04 -0700 (PDT) Received: from p4fff2079.dip.t-dialin.net ([79.255.32.121] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OInfq-0002Fd-Jj; Sun, 30 May 2010 20:55:50 +0200 Message-ID: <4C02B4AE.4000200@lodderstedt.net> Date: Sun, 30 May 2010 20:55:42 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Arnott References: <1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050903010000030002060100" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sun, 30 May 2010 18:56:07 -0000 This is a multi-part message in MIME format. --------------050903010000030002060100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Encrypting the token secret in self-contained tokens is the obvious solution, from my point of view. That's the way such things are handled in Kerberos. Regarding client secrets: One of the major obstacles when using OAuth 1.0 in large deployments is the need for sharing client secrets between authz server and resource server. Overcoming that obstacle was an important requirement for OAuth2 from the beginning, expressed by a lot of people. If you want to use client secrets (or privat keys) for the purpose, that's fine with me - as long as token secrets are supported as an alternative way of signing token-authorized requests. regards, Torsten. Am 30.05.2010 18:45, schrieb Andrew Arnott: > The advantage over using token secrets as it seems to me is that > neither auth server nor resource server need to store any issued > access tokens because they could be self-describing and signed. By > having token secrets I think storing every issued token at the auth > server or resource server side is almost unavoidable. I say "almost" > because theoretically the token secret could be encrypted and included > in the token itself, such that only the auth/resource server could > decrypt the secret, then use that secret to verify the signature. > This is likely more trouble than it's worth for some applications. > > I don't have a solution to the "avoid sharing client secret with > resource servers" problem. Some good points were made I think in this > thread about how that would need to be solved. > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the > death your right to say it." - S. G. Tallentyre > > > On Sun, May 30, 2010 at 1:45 AM, Torsten Lodderstedt > > wrote: > > what is the advantage in comparison to a token secret? > > How do you want to propagate the client_id and secret to the > resource servers? > > regrards, > Torsten. > > > Am 30.05.2010 um 03:27 schrieb Andrew Arnott > >: > >> Perhaps we can say that installed client apps can have client >> secrets after all, by calling the authorization server and asking >> for a new client_id and client_secret assignment for that >> particular app-install. >> >> Any thoughts on that? >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to >> the death your right to say it." - S. G. Tallentyre >> >> >> On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott >> > wrote: >> >> Hi Dirk, >> >> If you eradicated access token secrets in favor of signing >> with client secrets, how would installed apps, where the >> client secret is worthless and usually blank, >> authenticate/sign their own requests? >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend >> to the death your right to say it." - S. G. Tallentyre >> >> >> On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz >> > wrote: >> >> Hi guys, >> >> at today's interim meeting, we were discussing Brian >> Eaton's proposal for OAuth signatures. He was proposing a >> mechanism that would (1) do away with base string >> canonicalization, (2) allow for symmetric and public >> keys, and (3) allow for extensibility. >> >> He got homework from the group to prove the feasibility >> of his proposal by showing a couple of implementations. >> >> In this post, I would like to introduce another >> improvement of the OAuth 2 signing mechanism, one which >> is orthogonal to Brian's proposal (i.e., it would work >> both with the signing mechanism in the current spec, as >> well as with Brian's signature mechanism). The goal of my >> proposal is twofold: >> >> - it simplifies the spec. It will become more readable >> and therefore easier to implement >> - it separates out the mechanisms for delegated >> authorization and for integrity protection into two >> independent pieces, which can be put together by Servers >> and/or Clients like LEGO blocks. >> >> Summary: >> >> - use the client secret instead of the token secret for >> signing PR access requests. >> >> Long version of the proposal: >> >> - remove all references to access tokens that are not >> bearer tokens from the spec. >> - stop calling the access tokens "bearer tokens". Call >> them just "access tokens". >> - remove all references to token secrets from the spec >> - remove all parts of the spec that are of the kind "if >> bearer_token then X, else Y", and replace them with X. >> - delete section 5.3 >> - add a section called "Request Authentication" that goes >> something like this: >> >> "Servers may require that requests be authenticated by >> the Client, so that presentation of the access token >> alone is not sufficient to access a Protected Resource. >> This has several use cases, including, but not limited >> to, the following: >> >> - Non-repudiation: high-security deployments may require >> that requests be authenticated (signed) in a >> non-repudiateable way[1] >> - Access to protected resources is not protected by SSL, >> so that access tokens may leak. >> - End-to-end-integrity: even if SSL _is_ used, network >> infrastructure may strip SSL protection before the >> request reaches the protected resource. The protected >> resource, however, may require end-to-end integrity. >> >> If the Server requires that the Client authenticate PR >> access requests, then the Client uses the following >> mechanism to sign their HTTP requests: [...]" >> >> Then, we basically drop the old Section 5.3 here (except >> we use the client secret instead of the access token >> secret). Eventually, instead of Section 5.3, we may have >> Brian's new signature scheme section here, which would >> add the option of public-key crypto[1], etc. >> >> What do you guys think? >> >> Dirk. >> >> [1] Technically speaking, the goal of non-repudiation can >> only be achieved once we have public-key crypto. >> >> >> _______________________________________________ >> 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 > > --------------050903010000030002060100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Encrypting the token secret in self-contained tokens is the obvious solution, from my point of view. That's the way such things are handled in Kerberos.

Regarding client secrets: One of the major obstacles when using OAuth 1.0 in large deployments is the need for sharing client secrets between authz server and resource server. Overcoming that obstacle was an important requirement for OAuth2 from the beginning, expressed by a lot of people.

If you want to use client secrets (or privat keys) for the purpose, that's fine with me - as long as token secrets are supported as an alternative way of signing token-authorized requests.

regards,
Torsten.

Am 30.05.2010 18:45, schrieb Andrew Arnott:
The advantage over using token secrets as it seems to me is that neither auth server nor resource server need to store any issued access tokens because they could be self-describing and signed.  By having token secrets I think storing every issued token at the auth server or resource server side is almost unavoidable.  I say "almost" because theoretically the token secret could be encrypted and included in the token itself, such that only the auth/resource server could decrypt the secret, then use that secret to verify the signature.  This is likely more trouble than it's worth for some applications.

I don't have a solution to the "avoid sharing client secret with resource servers" problem.  Some good points were made I think in this thread about how that would need to be solved. 
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Sun, May 30, 2010 at 1:45 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
what is the advantage in comparison to a token secret?

How do you want to propagate the client_id and secret to the resource servers? 

regrards,
Torsten.


Am 30.05.2010 um 03:27 schrieb Andrew Arnott <andrewarnott@gmail.com>:

Perhaps we can say that installed client apps can have client secrets after all, by calling the authorization server and asking for a new client_id and client_secret assignment for that particular app-install. 

Any thoughts on that?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott <andrewarnott@gmail.com> wrote:
Hi Dirk,

If you eradicated access token secrets in favor of signing with client secrets, how would installed apps, where the client secret is worthless and usually blank, authenticate/sign their own requests? 

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz <balfanz@google.com> wrote:
Hi guys, 

at today's interim meeting, we were discussing Brian Eaton's proposal for OAuth signatures. He was proposing a mechanism that would (1) do away with base string canonicalization, (2) allow for symmetric and public keys, and (3) allow for extensibility. 

He got homework from the group to prove the feasibility of his proposal by showing a couple of implementations. 

In this post, I would like to introduce another improvement of the OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would work both with the signing mechanism in the current spec, as well as with Brian's signature mechanism). The goal of my proposal is twofold:

- it simplifies the spec. It will become more readable and therefore easier to implement
- it separates out the mechanisms for delegated authorization and for integrity protection into two independent pieces, which can be put together by Servers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing PR access requests.

Long version of the proposal:

- remove all references to access tokens that are not bearer tokens from the spec.
- stop calling the access tokens "bearer tokens". Call them just "access tokens". 
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if bearer_token then X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes something like this:

"Servers may require that requests be authenticated by the Client, so that presentation of the access token alone is not sufficient to access a Protected Resource.  This has several use cases, including, but not limited to, the following:

- Non-repudiation: high-security deployments may require that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that access tokens may leak. 
- End-to-end-integrity: even if SSL _is_ used, network infrastructure may strip SSL protection before the request reaches the protected resource. The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR access requests, then the Client uses the following mechanism to sign their HTTP requests: [...]"

Then, we basically drop the old Section 5.3 here (except we use the client secret instead of the access token secret). Eventually, instead of Section 5.3, we may have Brian's new signature scheme section here, which would add the option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only be achieved once we have public-key crypto.


_______________________________________________
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

--------------050903010000030002060100-- From beaton@google.com Sun May 30 14:41:59 2010 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 CF7413A692C for ; Sun, 30 May 2010 14:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.841 X-Spam-Level: X-Spam-Status: No, score=-103.841 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, 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 LgOLfnyJSQ6l for ; Sun, 30 May 2010 14:41:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D33E33A6923 for ; Sun, 30 May 2010 14:41:53 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o4ULffMA002631 for ; Sun, 30 May 2010 14:41:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275255701; bh=ZprtDwOkE6b+IWZDbXalnxCre8M=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=LYIxmquyS9hdf2vmW8rC9EpPWzIk7JDCZNtNP2urlZ410+SsJqZ4RvavOpkHrGmv4 Nca60w/RMsorqz44cp1yg== 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=oEH4dKltJP+BiAh1qefYhiVHxWBDJcIcGZ94lLpICsdn4YXwFu8jJbqJOGDckjEio bhN3gdz9x6XyBAgDzWpfg== Received: from pzk37 (pzk37.prod.google.com [10.243.19.165]) by kpbe11.cbf.corp.google.com with ESMTP id o4ULfdSF012892 for ; Sun, 30 May 2010 14:41:40 -0700 Received: by pzk37 with SMTP id 37so1965775pzk.27 for ; Sun, 30 May 2010 14:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.21.25 with SMTP id y25mr2341232wfi.62.1275255699456; Sun, 30 May 2010 14:41:39 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Sun, 30 May 2010 14:41:39 -0700 (PDT) In-Reply-To: <4C02B4AE.4000200@lodderstedt.net> References: <1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net> <4C02B4AE.4000200@lodderstedt.net> Date: Sun, 30 May 2010 14:41:39 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Sun, 30 May 2010 21:42:00 -0000 On Sun, May 30, 2010 at 11:55 AM, Torsten Lodderstedt wrote: > Regarding client secrets: One of the major obstacles when using OAuth 1.0 in > large deployments is the need for sharing client secrets between authz > server and resource server. Overcoming that obstacle was an important > requirement for OAuth2 from the beginning, expressed by a lot of people. There are actually a bunch of fundamentally conflicting requirements for signatures from the various folks contributing to this working group. - no shared secrets with protected resources at all - no permanent shared secrets with protected resources - no shared secrets with clients - allow access tokens to be used by multiple clients without sharing consumer secrets - don't allow access tokens to be shared by multiple clients - don't use public key, because it's slow - use public key, because it makes key distribution easier - don't use cryptography at all, because it's too complicated - don't use bearer tokens at all, because they might leak - keep access tokens short - encode lots of information in the access token I'm sure I'm forgetting some. For the record, I think *every single one* of those requirements makes sense in certain contexts. I'm pretty sure we're going to be able to agree on the cryptographic primitives without too much trouble. But we're going to have to split out profiles to deal with the different key distribution challenges. Cheers, Brian From James.H.Manger@team.telstra.com Sun May 30 18:17:35 2010 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 2D7173A6986 for ; Sun, 30 May 2010 18:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMvXItF6QEm5 for ; Sun, 30 May 2010 18:17:34 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 379B73A6985 for ; Sun, 30 May 2010 18:17:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,329,1272808800"; d="scan'208";a="3451028" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 31 May 2010 11:17:20 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5998"; a="2646073" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdni.tcif.telstra.com.au with ESMTP; 31 May 2010 11:17:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Mon, 31 May 2010 11:17:21 +1000 From: "Manger, James H" To: Nat Sakimura Date: Mon, 31 May 2010 11:17:19 +1000 Thread-Topic: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow Thread-Index: Acr+3lphMYz2epEfScy2MwX7oYKXLgBfseQA Message-ID: <255B9BB34FB7D647A506DC292726F6E11263BF2F2E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263B6402C@WSMSG3153V.srv.dir.telstra.com> 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 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow 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, 31 May 2010 01:17:35 -0000 TmF0LA0KDQo+IEFsbCB0aGUgcmVxdWVzdCBwYXJhbWV0ZXJzIE1VU1QgYmUgcHJvdmlkZWQgdGhy b3VnaCByZXF1ZXN0IGZpbGUuDQoNCiJBbGwiIGRvZXNuJ3QgbWFrZSBtdWNoIHNlbnNlIGlmIHBh cmFtcyBjYW4gc3RpbGwgYXBwZWFyIGluIHRoZSBVUkksIGFuZCBvdmVycmlkZSB0aGUgZmlsZS4N Cg0KPiBUaGUgInJlcXVlc3RfdXJsIiBNVVNUIGJlIHByb3ZpZGVkIGluIHRoZSBVUkwuDQoNClRo aXMgaXNuJ3QgcmVhbGx5IGEgIk1VU1QiLCBpdHMganVzdCBpbmRpY2F0ZXMgaWYgeW91IGFyZSB1 c2luZyB0aGlzIGZlYXR1cmUgKHRoaXMgImZsb3ciKS4NCg0KV291bGQgYmUgZ29vZCB0byBzYXkg IkEgcmVxdWVzdF91cmwgcGFyYW0gTVVTVCBOT1QgYmUgcHJvdmlkZWQgaW4gYSByZXF1ZXN0IGZp bGUiLiBQcm9iYWJseSBnb29kIHRvIGFkZCAiQSByZXF1ZXN0IGZpbGUgTVVTVCBiZSByZWplY3Rl ZCBpZiBpdCBpbmNsdWRlcyBhIHJlcXVlc3RfdXJsIHBhcmFtIi4NCg0KPiBJIGFtIHN0aWxsIG5v dCBzdXJlIGlmICJ0eXBlIiBNVVNUIGJlIHByb3ZpZGVkIGluIHRoZSBVUkwuDQo+IENvbmNlcHR1 YWxseSwgaXQgbmVlZCBub3QgYmUgdGhlcmUuIEl0IGRlcGVuZHMgb24gaG93IGltcGxlbWVudG9y cyBmZWVsLg0KDQo+IEFueSBvdGhlciBwYXJhbWV0ZXJzIE1BWSBiZSBwcm92aWRlZCBpbiB0aGUg VVJMIHRvIG92ZXJyaWRlIHdoYXQgaXMgaW4gdGhlIHJlcXVlc3RfZmlsZSwNCg0KSSBhZ3JlZS4N Cg0KPiBidXQgdGhlIFVSTCB0b3RhbCBsZW5ndGggTVVTVCBOT1QgZXhjZWVkIDUxMiBieXRlcy4N Cg0KVGhhdCBpcyByZWFzb25hYmxlLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From torsten@lodderstedt.net Sun May 30 22:08:36 2010 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 8301D3A688B for ; Sun, 30 May 2010 22:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.466 X-Spam-Level: X-Spam-Status: No, score=0.466 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_50=0.001, HELO_EQ_DE=0.35] 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 asgiZlC-guLA for ; Sun, 30 May 2010 22:08:35 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id 451743A65A6 for ; Sun, 30 May 2010 22:08:34 -0700 (PDT) Received: from p4fff3635.dip.t-dialin.net ([79.255.54.53] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OIxEc-0001EP-A5; Mon, 31 May 2010 07:08:22 +0200 Message-ID: <4C034444.2070806@lodderstedt.net> Date: Mon, 31 May 2010 07:08:20 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian Eaton References: <1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net> <4C02B4AE.4000200@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Mon, 31 May 2010 05:08:36 -0000 sounds reasonable Are your working on the cryptographic primitives and such profiles? regards, Torsten. Am 30.05.2010 23:41, schrieb Brian Eaton: > On Sun, May 30, 2010 at 11:55 AM, Torsten Lodderstedt > wrote: > >> Regarding client secrets: One of the major obstacles when using OAuth 1.0 in >> large deployments is the need for sharing client secrets between authz >> server and resource server. Overcoming that obstacle was an important >> requirement for OAuth2 from the beginning, expressed by a lot of people. >> > There are actually a bunch of fundamentally conflicting requirements > for signatures from the various folks contributing to this working > group. > > - no shared secrets with protected resources at all > > - no permanent shared secrets with protected resources > > - no shared secrets with clients > > - allow access tokens to be used by multiple clients without sharing > consumer secrets > > - don't allow access tokens to be shared by multiple clients > > - don't use public key, because it's slow > > - use public key, because it makes key distribution easier > > - don't use cryptography at all, because it's too complicated > > - don't use bearer tokens at all, because they might leak > > - keep access tokens short > > - encode lots of information in the access token > > I'm sure I'm forgetting some. > > For the record, I think *every single one* of those requirements makes > sense in certain contexts. > > I'm pretty sure we're going to be able to agree on the cryptographic > primitives without too much trouble. > > But we're going to have to split out profiles to deal with the > different key distribution challenges. > > Cheers, > Brian > From James.H.Manger@team.telstra.com Sun May 30 22:58:37 2010 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 189CE3A69C2 for ; Sun, 30 May 2010 22:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.094 X-Spam-Level: ** X-Spam-Status: No, score=2.094 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hnJLpL-XznK for ; Sun, 30 May 2010 22:58:36 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id ECB6A3A69BF for ; Sun, 30 May 2010 22:58:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,331,1272808800"; d="scan'208";a="3486334" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 31 May 2010 15:58:21 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,5998"; a="2592413" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbvi.tcif.telstra.com.au with ESMTP; 31 May 2010 15:58:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Mon, 31 May 2010 15:58:22 +1000 From: "Manger, James H" To: Brian Eaton Date: Mon, 31 May 2010 15:58:20 +1000 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: AcsAQO1em/rkd+TiQF+jN9aWWBu4IwAP3z0w Message-ID: <255B9BB34FB7D647A506DC292726F6E11263BF36FD@WSMSG3153V.srv.dir.telstra.com> References: <1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net> <4C02B4AE.4000200@lodderstedt.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 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Mon, 31 May 2010 05:58:37 -0000 QnJpYW4sDQoNCj4gVGhlcmUgYXJlIGFjdHVhbGx5IGEgYnVuY2ggb2YgZnVuZGFtZW50YWxseSBj b25mbGljdGluZyByZXF1aXJlbWVudHMNCj4gZm9yIHNpZ25hdHVyZXMgZnJvbSB0aGUgdmFyaW91 cyBmb2xrcyBjb250cmlidXRpbmcgdG8gdGhpcyB3b3JraW5nDQo+IGdyb3VwLg0KPiAuLi4NCj4g Rm9yIHRoZSByZWNvcmQsIEkgdGhpbmsgKmV2ZXJ5IHNpbmdsZSBvbmUqIG9mIHRob3NlIHJlcXVp cmVtZW50cyBtYWtlcw0KPiBzZW5zZSBpbiBjZXJ0YWluIGNvbnRleHRzLg0KDQpJIGFncmVlLg0K DQo+Li4uIHdlJ3JlIGdvaW5nIHRvIGhhdmUgdG8gc3BsaXQgb3V0IHByb2ZpbGVzIHRvIGRlYWwg d2l0aCB0aGUNCj4gZGlmZmVyZW50IGtleSBkaXN0cmlidXRpb24gY2hhbGxlbmdlcy4NCg0KSW5z dGVhZCBvZiBzdGFydGluZyB3aXRoIHByb2ZpbGVzLCBJIHRoaW5rIGEga2V5IHRvIGFkZHJlc3Np bmcgdGhpcyBpc3N1ZSBpcyB0byBtYWtlIHRoZSB0b2tlbiByZXNwb25zZSBmb3JtYXQgcmljaGVy LiBJdCBzaG91bGQgdGVsbCB0aGUgY2xpZW50IGFwcCBhbGwgaXQgbmVlZHMgdG8ga25vdyB0byBh dXRoZW50aWNhdGUgaXRzIGNhbGxzIHRvIHByb3RlY3RlZCByZXNvdXJjZXMuIEZyb20gYSB0b2tl biByZXNwb25zZSwgYSBjbGllbnQgYXBwIHNob3VsZCBrbm93IHRoaXMgcGFydGljdWxhciBzZXJ2 aWNl4oCZcyByZXF1aXJlbWVudHM6IGJlYXJlciB0b2tlbiAvIGNsaWVudCBzZWNyZXQgLyB0b2tl biBzZWNyZXQ7IHNoYXJlZCBzZWNyZXQgLyBwdWJsaWMga2V5OyBzaG9ydC10ZXJtIC8gcGVybWFu ZW50OyAuLi4uDQoNCk15IG1lbnRhbCBtb2RlbCBvZiB0aGUgdG9rZW4gcmVzcG9uc2UgaGFzIGl0 IHBlcmZvcm1pbmcgdHdvIHRhc2tzOg0KMS4gSW5kaWNhdGluZyBob3cgdG8gYXV0aGVudGljYXRl IHJlcXVlc3RzIHRvIHByb3RlY3RlZCByZXNvdXJjZXMgLS0gbXVjaCBsaWtlIGEgV1dXLUF1dGhl bnRpY2F0ZSByZXNwb25zZSBoZWFkZXIgZm9yIGEgIm5vcm1hbCIgYXV0aGVudGljYXRpb24gc2No ZW1lICh3aXRob3V0IHVzZXIgZGVsZWdhdGlvbikuDQoyLiBQcm92aWRlIGFsbCBvciBzb21lIG9m IHRoZSB2YWx1ZXMgbmVjZXNzYXJ5IHRvIG1ha2UgdGhvc2UgYXV0aGVudGljYXRlZCByZXF1ZXN0 cy4NCg0KVGhlIHRva2VuIHJlc3BvbnNlIHNob3VsZCBpbmNsdWRlIHRoZSBuYW1lIG9mIHRoZSBI VFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSB0aGF0IHdpbGwgYmUgdXNlZCB0byBhY2Nlc3MgcHJv dGVjdGVkIHJlc291cmNlcy4NCkV4YW1wbGU6IHsgInNjaGVtZSI6IkJBU0lDIiAuLi59IG9yIHsi c2NoZW1lIjoiVG9rZW4iIC4uLn0NCg0KSXQgbWFrZXMgaXQgZmFpcmx5IG9idmlvdXMgaG93IHRv IGludGVncmF0ZSBvdGhlciBhdXRoIHNjaGVtZXMgd2l0aCBPQXV0aDoganVzdCBpbmNsdWRlIHRo ZSBwYXJhbWV0ZXJzIGZyb20gdGhhdCBzY2hlbWXigJlzIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVy IGluIGEgdG9rZW4gcmVzcG9uc2UuDQoNCg0KSSBxdWl0ZSBsaWtlIHRoZSBpZGVhIG9mIGluZGlj YXRpbmcgd2hldGhlciBzdWJzZXF1ZW50IHJlcXVlc3RzIGFyZSBzaWduZWQgd2l0aCB0aGUgY2xp ZW504oCZcyBzZWNyZXQgb3IgYSB0b2tlbiBzZWNyZXQgYnkgc2ltcGx5IG9taXR0aW5nIG9yIGlu Y2x1ZGluZyBzdWNoIGEgc2VjcmV0IGluIHRoZSB0b2tlbiByZXNwb25zZS4NCltUaGlzIGRvZXMg YXNzdW1lIHRoYXQga25vd2luZyB0aGUgInNjaGVtZSIgaXMgc3VmZmljaWVudCB0byBkZXRlcm1p bmUgaWYgYSBzZWNyZXQgaXMgcmVxdWlyZWQsIHdoaWNoIGlzIG9uZSBtb3JlIHJlYXNvbiB3aHkg cmV1c2luZyAiVG9rZW4iIGZvciBiZWFyZXIsIE1BQyBhbmQgcHVibGljLWtleSBvcGVyYXRpb25z IGlzIGEgcG9vciBkZXNpZ24uXQ0KQSAobGVzcyBkZXNpcmFibGUpIGFsdGVybmF0aXZlIGlzIGEg c3BlY2lmaWMgImNsaWVudF9hdXRoIjpbVFJVRXxGQUxTRV0gcGFyYW1ldGVyIGluIGEgdG9rZW4g cmVzcG9uc2UuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From andrewarnott@gmail.com Mon May 31 09:12:49 2010 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 A4F793A677D for ; Mon, 31 May 2010 09:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.743 X-Spam-Level: X-Spam-Status: No, score=-0.743 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_20=-0.74, 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 8BNOj635Z2vG for ; Mon, 31 May 2010 09:12:47 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D0C0A3A685C for ; Mon, 31 May 2010 09:12:46 -0700 (PDT) Received: by gyh4 with SMTP id 4so2934088gyh.31 for ; Mon, 31 May 2010 09:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=qfgYhFDWFnuNax8te6OQK06pXFrf7AXf0U1BUETUci8=; b=Q5+E62jEdkHCZyMe63eCvz+OxMj+/0upBgvWrTg/gwfIPOO0OAnTi0JgE9OAq9svzU JQYhG081A05GPjUFAE6IEZ5ylTLaCEUoKhqUbUHQml15S/L5uKfBa2q3r3nPcrV95eAk s+viVxu/lbk5iSJ0URGnXc+kl2SZjR/bUDczE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=e9/NecetniNHGNpdfEG55hHDX8hLxhHRSAJlLCrgI9Go3TDs8VyWmrpsTQEq5YEW6M ZB7CczS9LbnMGYuEpldVMn9/06px8yi2wxCrLmfugIBFoQMAVID3ows8N8kOPNw09T5+ rTAU0qbDSINLuaacK/nojDpAfAv3/DOg6xpWM= MIME-Version: 1.0 Received: by 10.150.114.2 with SMTP id m2mr5311519ybc.327.1275322352499; Mon, 31 May 2010 09:12:32 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Mon, 31 May 2010 09:12:32 -0700 (PDT) Date: Mon, 31 May 2010 09:12:32 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd48bc6cb7c8a0487e61ff6 Subject: [OAUTH-WG] Definition of XML response format 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, 31 May 2010 16:12:49 -0000 --000e0cd48bc6cb7c8a0487e61ff6 Content-Type: text/plain; charset=ISO-8859-1 Where is the definition of how a auth server response in XML format should look? At the least we need an XML namespace and root node name. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --000e0cd48bc6cb7c8a0487e61ff6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Where is the definition of how a auth server response in XML format should = look?=A0 At the least we need an XML namespace and root node name.

--
Andrew Arnott
"I [may] not agree with what you h= ave to say, but I'll defend to the death your right to say it." - = S. G. Tallentyre
--000e0cd48bc6cb7c8a0487e61ff6-- From wmills@yahoo-inc.com Mon May 31 20:20:26 2010 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 820293A6403 for ; Mon, 31 May 2010 20:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.048 X-Spam-Level: X-Spam-Status: No, score=-16.048 tagged_above=-999 required=5 tests=[AWL=-1.384, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] 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 BqjAyWy19H45 for ; Mon, 31 May 2010 20:20:24 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 6C3193A6819 for ; Mon, 31 May 2010 20:20:24 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o513ITvK022196; Mon, 31 May 2010 20:18:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:x-originalarrivaltime; b=WGlKgXy0TdWTw3QCP3uJRZzLX01hAxe9uOcupQ6+lEn5ByUuORrbDu9i+9m1z7WL Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 May 2010 20:18:28 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0139.19DF8D55" Date: Mon, 31 May 2010 20:18:26 -0700 Message-ID: <012AB2B223CB3F4BB846962876F4721705795447@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: Acr/KoDgvlGP9TAZSi+/VTcTnH4/lAAdXUfw References: From: "William Mills" To: "Andrew Arnott" , "Dirk Balfanz" X-OriginalArrivalTime: 01 Jun 2010 03:18:28.0871 (UTC) FILETIME=[1B0BC170:01CB0139] Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Tue, 01 Jun 2010 03:20:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0139.19DF8D55 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In the client apps case you use bearer tokens. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott Sent: Saturday, May 29, 2010 5:21 AM To: Dirk Balfanz Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 =09 =09 Hi Dirk, =09 If you eradicated access token secrets in favor of signing with client secrets, how would installed apps, where the client secret is worthless and usually blank, authenticate/sign their own requests? =20 =09 -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre =09 =09 =09 On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz wrote: =09 Hi guys, =20 at today's interim meeting, we were discussing Brian Eaton's proposal for OAuth signatures. He was proposing a mechanism that would (1) do away with base string canonicalization, (2) allow for symmetric and public keys, and (3) allow for extensibility.=20 He got homework from the group to prove the feasibility of his proposal by showing a couple of implementations.=20 In this post, I would like to introduce another improvement of the OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would work both with the signing mechanism in the current spec, as well as with Brian's signature mechanism). The goal of my proposal is twofold: - it simplifies the spec. It will become more readable and therefore easier to implement - it separates out the mechanisms for delegated authorization and for integrity protection into two independent pieces, which can be put together by Servers and/or Clients like LEGO blocks. Summary: - use the client secret instead of the token secret for signing PR access requests. Long version of the proposal: - remove all references to access tokens that are not bearer tokens from the spec. - stop calling the access tokens "bearer tokens". Call them just "access tokens".=20 - remove all references to token secrets from the spec - remove all parts of the spec that are of the kind "if bearer_token then X, else Y", and replace them with X. - delete section 5.3 - add a section called "Request Authentication" that goes something like this: "Servers may require that requests be authenticated by the Client, so that presentation of the access token alone is not sufficient to access a Protected Resource. This has several use cases, including, but not limited to, the following: - Non-repudiation: high-security deployments may require that requests be authenticated (signed) in a non-repudiateable way[1] - Access to protected resources is not protected by SSL, so that access tokens may leak.=20 - End-to-end-integrity: even if SSL _is_ used, network infrastructure may strip SSL protection before the request reaches the protected resource. The protected resource, however, may require end-to-end integrity. If the Server requires that the Client authenticate PR access requests, then the Client uses the following mechanism to sign their HTTP requests: [...]" Then, we basically drop the old Section 5.3 here (except we use the client secret instead of the access token secret). Eventually, instead of Section 5.3, we may have Brian's new signature scheme section here, which would add the option of public-key crypto[1], etc. What do you guys think? Dirk. [1] Technically speaking, the goal of non-repudiation can only be achieved once we have public-key crypto. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =09 =09 ------_=_NextPart_001_01CB0139.19DF8D55 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
In the client apps case you use bearer=20 tokens.

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew=20 Arnott
Sent: Saturday, May 29, 2010 5:21 AM
To: = Dirk=20 Balfanz
Cc: OAuth WG
Subject: Re: [OAUTH-WG] = proposal for=20 factoring out request signing in OAuth 2

Hi Dirk,

If you eradicated access token secrets in = favor of=20 signing with client secrets, how would installed apps, where the = client secret=20 is worthless and usually blank, authenticate/sign their own = requests? =20

--
Andrew Arnott
"I [may] not agree with = what you have=20 to say, but I'll defend to the death your right to say it." - S. G.=20 Tallentyre


On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz = <balfanz@google.com> = wrote:
Hi guys, 

at today's interim meeting, we were discussing Brian Eaton's = proposal=20 for OAuth signatures. He was proposing a mechanism that would (1) do = away=20 with base string canonicalization, (2) allow for symmetric and = public keys,=20 and (3) allow for extensibility. 

He got homework from the group to prove the feasibility of his = proposal=20 by showing a couple of implementations. 

In this post, I would like to introduce another improvement of = the=20 OAuth 2 signing mechanism, one which is orthogonal to Brian's = proposal=20 (i.e., it would work both with the signing mechanism in the current = spec, as=20 well as with Brian's signature mechanism). The goal of my proposal = is=20 twofold:

- it simplifies the spec. It will become more readable and = therefore=20 easier to implement
- it separates out the mechanisms for delegated authorization = and for=20 integrity protection into two independent pieces, which can be put = together=20 by Servers and/or Clients like LEGO blocks.

Summary:

- use the client secret instead of the token secret for signing = PR=20 access requests.

Long version of the proposal:

- remove all references to access tokens that are not bearer = tokens=20 from the spec.
- stop calling the access tokens "bearer tokens". Call them = just=20 "access tokens". 
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if = bearer_token=20 then X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes = something=20 like this:

"Servers may require that requests be authenticated by the = Client, so=20 that presentation of the access token alone is not sufficient to = access a=20 Protected Resource.  This has several use cases, including, but = not=20 limited to, the following:

- Non-repudiation: high-security deployments may require that = requests=20 be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so = that access=20 tokens may leak. 
- End-to-end-integrity: even if SSL _is_ used, network = infrastructure=20 may strip SSL protection before the request reaches the protected = resource.=20 The protected resource, however, may require end-to-end = integrity.

If the Server requires that the Client authenticate PR access = requests,=20 then the Client uses the following mechanism to sign their HTTP = requests:=20 [...]"

Then, we basically drop the old Section 5.3 here (except we use = the=20 client secret instead of the access token secret). Eventually, = instead of=20 Section 5.3, we may have Brian's new signature scheme section here, = which=20 would add the option of public-key crypto[1], etc.

What do you guys think?

Dirk.

[1] Technically speaking, the goal of non-repudiation can only = be=20 achieved once we have public-key crypto.
=


_______________________________________________
OAu= th=20 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------_=_NextPart_001_01CB0139.19DF8D55-- From balfanz@google.com Mon May 31 22:42:06 2010 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 B26343A6965 for ; Mon, 31 May 2010 22:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.676 X-Spam-Level: X-Spam-Status: No, score=-104.676 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 9sZDNEdWuAKX for ; Mon, 31 May 2010 22:42:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CD9423A67D3 for ; Mon, 31 May 2010 22:42:03 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o515fmuH022150 for ; Mon, 31 May 2010 22:41:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275370909; bh=rQtwIVHgMiKxs13En/mjDcnxdyY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=D6dYJwlgdB1guB06IbZ9Xl4NBUD5r4cuB15Ki3IMTKLS2zSSQh7jc7zTFAqRjI9g3 An3iXMBEDBLER/dLdF3cg== 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=rDW9QLhXCAQhYdmj66msxPEpkx+ypa/BhnxuJec8beHe7qiL1Ga3X2/e95Jxq8rwX EnOM0nDI540v7zi3Sbe7g== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by kpbe11.cbf.corp.google.com with ESMTP id o515flJx006390 for ; Mon, 31 May 2010 22:41:47 -0700 Received: by gyf1 with SMTP id 1so3074496gyf.21 for ; Mon, 31 May 2010 22:41:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.150.4 with SMTP id w4mr7160215ibv.41.1275370906390; Mon, 31 May 2010 22:41:46 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Mon, 31 May 2010 22:41:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 May 2010 22:41:46 -0700 Message-ID: From: Dirk Balfanz To: Andrew Arnott Content-Type: multipart/alternative; boundary=0016e68dd284d512770487f16d1e X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 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: Tue, 01 Jun 2010 05:42:06 -0000 --0016e68dd284d512770487f16d1e Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 29, 2010 at 6:27 PM, Andrew Arnott wrote: > Perhaps we can say that installed client apps can have client secrets after > all, by calling the authorization server and asking for a new client_id and > client_secret assignment for that particular app-install. > > Any thoughts on that? Maybe. Do we have an example of somebody who needs to do that? (At Google we would probably just use SSL, or if that's not possible make the access token very short-lived, but stick with bearer tokens.) Dirk. > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott wrote: > >> Hi Dirk, >> >> If you eradicated access token secrets in favor of signing with client >> secrets, how would installed apps, where the client secret is worthless and >> usually blank, authenticate/sign their own requests? >> >> -- >> Andrew Arnott >> "I [may] not agree with what you have to say, but I'll defend to the death >> your right to say it." - S. G. Tallentyre >> >> >> On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz wrote: >> >>> Hi guys, >>> >>> at today's interim meeting, we were discussing Brian Eaton's proposal for >>> OAuth signatures. He was proposing a mechanism that would (1) do away with >>> base string canonicalization, (2) allow for symmetric and public keys, and >>> (3) allow for extensibility. >>> >>> He got homework from the group to prove the feasibility of his proposal >>> by showing a couple of implementations. >>> >>> In this post, I would like to introduce another improvement of the OAuth >>> 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it >>> would work both with the signing mechanism in the current spec, as well as >>> with Brian's signature mechanism). The goal of my proposal is twofold: >>> >>> - it simplifies the spec. It will become more readable and therefore >>> easier to implement >>> - it separates out the mechanisms for delegated authorization and for >>> integrity protection into two independent pieces, which can be put together >>> by Servers and/or Clients like LEGO blocks. >>> >>> Summary: >>> >>> - use the client secret instead of the token secret for signing PR access >>> requests. >>> >>> Long version of the proposal: >>> >>> - remove all references to access tokens that are not bearer tokens from >>> the spec. >>> - stop calling the access tokens "bearer tokens". Call them just "access >>> tokens". >>> - remove all references to token secrets from the spec >>> - remove all parts of the spec that are of the kind "if bearer_token then >>> X, else Y", and replace them with X. >>> - delete section 5.3 >>> - add a section called "Request Authentication" that goes something like >>> this: >>> >>> "Servers may require that requests be authenticated by the Client, so >>> that presentation of the access token alone is not sufficient to access a >>> Protected Resource. This has several use cases, including, but not limited >>> to, the following: >>> >>> - Non-repudiation: high-security deployments may require that requests be >>> authenticated (signed) in a non-repudiateable way[1] >>> - Access to protected resources is not protected by SSL, so that access >>> tokens may leak. >>> - End-to-end-integrity: even if SSL _is_ used, network infrastructure may >>> strip SSL protection before the request reaches the protected resource. The >>> protected resource, however, may require end-to-end integrity. >>> >>> If the Server requires that the Client authenticate PR access requests, >>> then the Client uses the following mechanism to sign their HTTP requests: >>> [...]" >>> >>> Then, we basically drop the old Section 5.3 here (except we use the >>> client secret instead of the access token secret). Eventually, instead of >>> Section 5.3, we may have Brian's new signature scheme section here, which >>> would add the option of public-key crypto[1], etc. >>> >>> What do you guys think? >>> >>> Dirk. >>> >>> [1] Technically speaking, the goal of non-repudiation can only be >>> achieved once we have public-key crypto. >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > --0016e68dd284d512770487f16d1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 29, 2010 at 6:27 PM, Andrew Arnott <andrewarnott@gmail.com> w= rote:
Perhaps we can say that installed client apps can have client secrets after= all, by calling the authorization server and asking for a new client_id an= d client_secret assignment for that particular app-install.=A0

Any = thoughts on that?

Maybe. Do we have an example of somebody who needs to d= o that? (At Google we would probably just use SSL, or if that's not pos= sible make the access token very short-lived, but stick with bearer tokens.= )=A0

Dirk.
=A0

--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


= On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott <andrewarnott@gmail.co= m> wrote:
Hi Dirk,

If you eradicated access token secrets in favor of signing = with client secrets, how would installed apps, where the client secret is w= orthless and usually blank, authenticate/sign their own requests?=A0

--
Andrew Arnott
"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


On Thu, May = 20, 2010 at 4:39 PM, Dirk Balfanz <balfanz@google.com> wrot= e:
<= /div>
Hi guys,=A0

at today's interim meeting, we were disc= ussing Brian Eaton's proposal for OAuth signatures. He was proposing a = mechanism that would (1) do away with base string canonicalization, (2) all= ow for symmetric and public keys, and (3) allow for extensibility.=A0

He got homework from the group to prove the feasibility= of his proposal by showing a couple of implementations.=A0

<= /div>
In this post, I would like to introduce another improvement of th= e OAuth 2 signing mechanism, one which is orthogonal to Brian's proposa= l (i.e., it would work both with the signing mechanism in the current spec,= as well as with Brian's signature mechanism). The goal of my proposal = is twofold:

- it simplifies the spec. It will become more readable = and therefore easier to implement
- it separates out the mechanis= ms for delegated authorization and for integrity protection into two indepe= ndent pieces, which can be put together by Servers and/or Clients like LEGO= blocks.

Summary:

- use the client secr= et instead of the token secret for signing PR access requests.
Long version of the proposal:

- remov= e all references to access tokens that are not bearer tokens from the spec.=
- stop calling the access tokens "bearer tokens". Call them = just "access tokens".=A0
- remove all references to tok= en secrets from the spec
- remove all parts of the spec that are = of the kind "if bearer_token then X, else Y", and replace them wi= th X.
- delete section 5.3
- add a section called "Request Au= thentication" that goes something like this:

= "Servers may require that requests be authenticated by the Client, so = that presentation of the access token alone is not sufficient to access a P= rotected Resource. =A0This has several use cases, including, but not limite= d to, the following:

- Non-repudiation: high-security deployments may requir= e that requests be authenticated (signed) in a non-repudiateable way[1]
- Access to protected resources is not protected by SSL, so that acc= ess tokens may leak.=A0
- End-to-end-integrity: even if SSL _is_ used, network infrastructure = may strip SSL protection before the request reaches the protected resource.= The protected resource, however, may require end-to-end integrity.

If the Server requires that the Client authenticate PR = access requests, then the Client uses the following mechanism to sign their= HTTP requests: [...]"

Then, we basically dro= p the old Section 5.3 here (except we use the client secret instead of the = access token secret). Eventually, instead of Section 5.3, we may have Brian= 's new signature scheme section here, which would add the option of pub= lic-key crypto[1], etc.

What do you guys think?

Dirk.<= /div>

[1] Technically speaking, the goal of non-repudiat= ion can only be achieved once we have public-key crypto.


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




--0016e68dd284d512770487f16d1e-- From recordond@gmail.com Mon May 31 23:30:01 2010 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 42EF628C129 for ; Mon, 31 May 2010 23:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 p7bDkRncv00r for ; Mon, 31 May 2010 23:30:00 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 43CD528C0D6 for ; Mon, 31 May 2010 23:29:59 -0700 (PDT) Received: by gyh4 with SMTP id 4so3432374gyh.31 for ; Mon, 31 May 2010 23:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=uJv8wccdOI+MbiioEuPqwHP6qP/7+pajUGVPEpKSKd8=; b=GPbV4NqZeuyE2253K0BAvfxY2u3D3qBA2iWy+60swl8ChHXRVZP7ezT9CoV8R3qrqh fgX7ma95rJd4dN/nvny1xQp4yR/HRKYVwh/EXC8Ii6fpJX1CnBMenL0Yy6jamMJpFfzG 68w9RFLEC0gsfGk+SXVpg5o63jbohBhyLHk54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u5/3gEL/TWEDwAkQxYKXW4MRuczd7meouvctVogJ0BoydztYfVlEU0Caz+eBKTuNm8 jTf/hH+tda+CIJeQEZK6kSwQ7TCqocnFpjqVXgxeMSRk+QMnstCAdnOELO8NIMoIQx8q A3DssDVdaBDV/C5fmpsXeHVzNT/dHawCLdcl0= MIME-Version: 1.0 Received: by 10.231.149.12 with SMTP id r12mr7185844ibv.57.1275373784505; Mon, 31 May 2010 23:29:44 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Mon, 31 May 2010 23:29:44 -0700 (PDT) Date: Tue, 1 Jun 2010 00:29:44 -0600 Message-ID: From: David Recordon To: OAuth WG , technoweenie@gmail.com Content-Type: multipart/alternative; boundary=0016e645b942619f0f0487f21915 Subject: [OAUTH-WG] GitHub ships server 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, 01 Jun 2010 06:30:01 -0000 --0016e645b942619f0f0487f21915 Content-Type: text/plain; charset=ISO-8859-1 With support for the Web Server and User Agent flows. Desktop said to be coming soon and a few different scopes. GitHub doesn't support OAuth 1.0. http://support.github.com/discussions/api/28-oauth2-busy-developers-guide http://gist.github.com/419219 Rick, is this based off of draft 5? Cool stuff! --David --0016e645b942619f0f0487f21915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With support for the Web Server and User Agent flows. Desktop said to be co= ming soon and a few different scopes. GitHub doesn't support OAuth 1.0.=


Rick, is this based off of draft 5? Cool stu= ff!

--David
--0016e645b942619f0f0487f21915-- From technoweenie@gmail.com Mon May 31 23:40:34 2010 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 29A163A6783 for ; Mon, 31 May 2010 23:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 qpqrIKG3o8nT for ; Mon, 31 May 2010 23:40:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AFA5528C105 for ; Mon, 31 May 2010 23:40:23 -0700 (PDT) Received: by vws11 with SMTP id 11so644912vws.31 for ; Mon, 31 May 2010 23:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mCahsDxYwbocbG3EXZ9zZobN0HNcK5JbSfpv6WPd4Ns=; b=MxlPWXSPXnox5n7q5kJ6cNPUCBlKQMXHOYroiomghPDrzQI/ZNJy6wZHH+9V3xS5ZB OBvPfrwTwQSMlAUUzrQW1l1WpmqXDsgFy+W/yCcLAOsKjFzX9GgGkfk1wh+jPWw71T6f baVvR5trobk+TVuCJbsHwjYCyZ7mB7/mSY050= 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=rh6BEeWvWuOMkuVhWroyLBFUXuni2G4kCm6RN3LIWyBYxNn3xhSTkogZvaGVJP4z9c IUUBZbbtuS5ObHvlNdPHPj1b9JvzKmkgqt4slp8nmby3B15AzZ56dJKSHZ5QoHOm1H3I OWEsWHVntl3hElkEKcRm2eL0ngKDIGHzpM2g8= MIME-Version: 1.0 Received: by 10.229.215.138 with SMTP id he10mr850081qcb.60.1275374408068; Mon, 31 May 2010 23:40:08 -0700 (PDT) Received: by 10.229.23.195 with HTTP; Mon, 31 May 2010 23:40:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 May 2010 23:40:08 -0700 Message-ID: From: Rick Olson To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] GitHub ships server 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, 01 Jun 2010 06:43:36 -0000 Partly draft 5 and partly the Facebook implementation :) Thanks for pinging me, I meant to find the OAuth list to ask for some clarifications on a few items. On Mon, May 31, 2010 at 11:29 PM, David Recordon wrote: > With support for the Web Server and User Agent flows. Desktop said to be > coming soon and a few different scopes. GitHub doesn't support OAuth 1.0. > http://support.github.com/discussions/api/28-oauth2-busy-developers-guide > http://gist.github.com/419219 > Rick, is this based off of draft 5? Cool stuff! > --David -- Rick Olson