From primmer@google.com Wed Dec 1 13:17: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 890CF3A6765 for ; Wed, 1 Dec 2010 13:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 nanMX65Ew3Fu for ; Wed, 1 Dec 2010 13:17:06 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E114C3A6358 for ; Wed, 1 Dec 2010 13:17:05 -0800 (PST) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id oB1LIJjg024256 for ; Wed, 1 Dec 2010 13:18:19 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291238299; bh=5VTq+f7iIKrOa+9tmDULgxtI2yc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=gcB0oKPuvgvYkBimhd+OcvqHCCHpWg2StsXLUcl0tcBPqEQnIapAFxQNEqF5cRsJC z2xI5dMEwC/xhWllCZkog== Received: from iwn35 (iwn35.prod.google.com [10.241.68.99]) by hpaq6.eem.corp.google.com with ESMTP id oB1LIACl000765 for ; Wed, 1 Dec 2010 13:18:18 -0800 Received: by iwn35 with SMTP id 35so8525iwn.35 for ; Wed, 01 Dec 2010 13:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=doaKMfJmGypPiXXkgXSDqevHGwSgjfNWSPMk1i1ZXxI=; b=GcGNouw7zFQNfyw6ru+LLBg5ViUb5LwEiVjmiP63xXavQzTk+EOW5is2DOSPAuqs9z 84TCr37JQ6aJSg8I9mxA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=o3geiM2CxaVhjo6a2U/K5ceBDtS7zSEVdYh3Icuoaplv3GOw+5Lkr3fd4ZpBb+FXZR z3HYhCdx4pkpDluNyqcw== Received: by 10.231.14.130 with SMTP id g2mr9392503iba.192.1291238295569; Wed, 01 Dec 2010 13:18:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.26.157 with HTTP; Wed, 1 Dec 2010 13:17:55 -0800 (PST) In-Reply-To: <20101126094122.53764oqlukyiow4y@ugs.tarent.de> References: <20101126094122.53764oqlukyiow4y@ugs.tarent.de> From: David Primmer Date: Wed, 1 Dec 2010 13:17:55 -0800 Message-ID: To: Martin Ley 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] Requesting mutliple scope, but user authorizes not all X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Dec 2010 21:17:07 -0000 As Eran pointed out, the way you've formatted your scope request, you've only specified one scope and I'd guess to keep things simple and consistent can either be approved or denied. I don't have a spec reference about what happens when the user doesn't approve but I assume the response is sent to the callback url. Now, what I heard in your email was a question about best-practices. The developer requests a number of scopes and the approval page on the authorization server allows the user to select which of those they approve and reject the rest. I don't think this is the the way that this sort of thing has been implemented for the most part. It's an all-or-none deal on most of the larger providers these days. Microsoft initially had a multiple choice UI for OAuth1 but I think they've abandoned that. So the real question is: how do you make sure the developer sends exactly what the user is prepared to approve to the AS, instead of allowing downscoping during the approval step. The common way this works out is either the developer knows they only need certain scopes for their application and they're relatively static or it's a selective disclosure system like you've described and the user needs to pick what they're going to approve on the developer's site before any browser redirects are done and those pre-filtered choices are sent to the AS. hope this helps. davep On Fri, Nov 26, 2010 at 12:41 AM, Martin Ley wrote: > Dear list, > > perhaps I've overread it in the specification or it was not explicit abou= t > my required scenario: > > > The Web-Server-Flow is used. An application requests data about the user. > The scopes are dateofbirth,isover18,address. Now the user is forwarded to > the authorization server to identify and authenticate and give permission= s > to the applications. The user decides to give only permission for the > isover18 scope but not dateofbirth and address. > > How would the application be notified about the granted scopes and the no= t > granted scopes? > > Best regards > > Martin > > > -- > tarent Gesellschaft f=FCr Softwareentwicklung und IT-Beratung mbH > Gesch=E4ftsf=FChrer: Boris Esser, Elmar Geese > HRB AG Bonn 5168 - USt-ID (VAT): DE122264941 > > Heilsbachstra=DFe 24, 53123 Bonn, =A0 Telefon: +49 228 52675-0 > Thiemannstra=DFe 36a, 12059 Berlin, Telefon: +49 30 5682943-30 > Internet: http://www.tarent.de/ =A0 Telefax: +49 228 52675-25 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Wed Dec 1 13:36: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 169263A67B0 for ; Wed, 1 Dec 2010 13:36:16 -0800 (PST) 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 hfitHI6aMVFX for ; Wed, 1 Dec 2010 13:36:13 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id A42BB3A672F for ; Wed, 1 Dec 2010 13:36:12 -0800 (PST) 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 oB1LbQbL002006 for ; Wed, 1 Dec 2010 16:37:26 -0500 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 oB1LbQDr002003; Wed, 1 Dec 2010 16:37:26 -0500 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Wed, 1 Dec 2010 16:37:25 -0500 From: Justin Richer To: David Primmer In-Reply-To: References: <20101126094122.53764oqlukyiow4y@ugs.tarent.de> Content-Type: text/plain; charset="UTF-8" Date: Wed, 1 Dec 2010 16:37:24 -0500 Message-ID: <1291239444.32049.250.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Requesting mutliple scope, but user authorizes not all X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Dec 2010 21:36:16 -0000 Just as a matter of clarification about the downscope language in the spec: The downscoping capability here is intended mostly for getting special-use tokens, for things like redelegation to other apps. So say I grant access to AppA with scope "read write", and AppA gets a refresh and access token. AppA can then present its refresh token to the token endpoint and request an access token with scope "read" in order to get a downscoped token (in this example, a read-only token), either to limit the vulnerabilities of tokens in flight or to hand to another app. The key is that AppA's request for a downscoped token with their previously-verified grant will not reprompt the user. -- Justin On Wed, 2010-12-01 at 16:17 -0500, David Primmer wrote: > As Eran pointed out, the way you've formatted your scope request, > you've only specified one scope and I'd guess to keep things simple > and consistent can either be approved or denied. I don't have a spec > reference about what happens when the user doesn't approve but I > assume the response is sent to the callback url. > > Now, what I heard in your email was a question about best-practices. > The developer requests a number of scopes and the approval page on the > authorization server allows the user to select which of those they > approve and reject the rest. I don't think this is the the way that > this sort of thing has been implemented for the most part. It's an > all-or-none deal on most of the larger providers these days. Microsoft > initially had a multiple choice UI for OAuth1 but I think they've > abandoned that. > > So the real question is: how do you make sure the developer sends > exactly what the user is prepared to approve to the AS, instead of > allowing downscoping during the approval step. The common way this > works out is either the developer knows they only need certain scopes > for their application and they're relatively static or it's a > selective disclosure system like you've described and the user needs > to pick what they're going to approve on the developer's site before > any browser redirects are done and those pre-filtered choices are sent > to the AS. > > hope this helps. > > davep > > On Fri, Nov 26, 2010 at 12:41 AM, Martin Ley wrote: > > Dear list, > > > > perhaps I've overread it in the specification or it was not explicit about > > my required scenario: > > > > > > The Web-Server-Flow is used. An application requests data about the user. > > The scopes are dateofbirth,isover18,address. Now the user is forwarded to > > the authorization server to identify and authenticate and give permissions > > to the applications. The user decides to give only permission for the > > isover18 scope but not dateofbirth and address. > > > > How would the application be notified about the granted scopes and the not > > granted scopes? > > > > Best regards > > > > Martin > > > > > > -- > > tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH > > Geschäftsführer: Boris Esser, Elmar Geese > > HRB AG Bonn 5168 - USt-ID (VAT): DE122264941 > > > > Heilsbachstraße 24, 53123 Bonn, Telefon: +49 228 52675-0 > > Thiemannstraße 36a, 12059 Berlin, Telefon: +49 30 5682943-30 > > Internet: http://www.tarent.de/ Telefax: +49 228 52675-25 > > > > _______________________________________________ > > 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 subbu@subbu.org Wed Dec 1 14:04: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 A3AF23A67B5 for ; Wed, 1 Dec 2010 14:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YEgWm6xjGMiw for ; Wed, 1 Dec 2010 14:04:15 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 99B993A63EB for ; Wed, 1 Dec 2010 14:04:15 -0800 (PST) Received: by fxm9 with SMTP id 9so6237274fxm.31 for ; Wed, 01 Dec 2010 14:05:29 -0800 (PST) Received: by 10.223.118.132 with SMTP id v4mr8968054faq.87.1291241129293; Wed, 01 Dec 2010 14:05:29 -0800 (PST) Received: from wlan-snve-154-178.corp.yahoo.com (nat-dip6.cfw-a-gci.corp.yahoo.com [209.131.62.115]) by mx.google.com with ESMTPS id c10sm232042fat.6.2010.12.01.14.05.26 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 14:05:27 -0800 (PST) From: Subbu Allamaraju Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Dec 2010 14:05:24 -0800 Message-Id: <69A9A98B-89A1-4C42-88C2-AC682C1827AB@subbu.org> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [OAUTH-WG] Comment on 'application/x-www-form-urlencoded' for URI parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Dec 2010 22:04:16 -0000 Here is some feedback on the use of the = 'application/x-www-form-urlencoded' media type in the latest drafts (10 = or 11). The draft refers to the 'application/x-www-form-urlencoded' media type = for encoding parameters into the query component of URIs. For instance, = see 4.1 in draft 11 has "In order to direct the end-user's user-agent to the authorization server, the client constructs the request URI by adding the following parameters to the end-user authorization endpoint URI query component using the "application/x-www-form-urlencoded" format as defined by [W3C.REC-html401-19991224]" However, this media type specifies how to encode parameters in the body = of a representation but not in URIs. In fact use of this encoding for = characters like spaces will break URIs.=20 Subbu= From eran@hueniverse.com Wed Dec 1 14:15: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 3E2793A67E3 for ; Wed, 1 Dec 2010 14:15:30 -0800 (PST) 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.089, 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 imIo-YXNBSu0 for ; Wed, 1 Dec 2010 14:15:29 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 72C6D3A67B5 for ; Wed, 1 Dec 2010 14:15:29 -0800 (PST) Received: (qmail 15166 invoked from network); 1 Dec 2010 22:16:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Dec 2010 22:16:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 1 Dec 2010 15:16:38 -0700 From: Eran Hammer-Lahav To: Subbu Allamaraju , OAuth WG Date: Wed, 1 Dec 2010 15:16:49 -0700 Thread-Topic: [OAUTH-WG] Comment on 'application/x-www-form-urlencoded' for URI parameters Thread-Index: AcuRo+ZoNwvm/9VtSDO/o1NaG1+FiQAAYChA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B065B2A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <69A9A98B-89A1-4C42-88C2-AC682C1827AB@subbu.org> In-Reply-To: <69A9A98B-89A1-4C42-88C2-AC682C1827AB@subbu.org> 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] Comment on 'application/x-www-form-urlencoded' for URI parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Dec 2010 22:15:30 -0000 The latest reference is: http://www.w3.org/TR/html5/association-of-controls-and-forms.html#applicati= on-x-www-form-urlencoded-encoding-algorithm But that's still a draft. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Subbu Allamaraju > Sent: Wednesday, December 01, 2010 2:05 PM > To: OAuth WG > Subject: [OAUTH-WG] Comment on 'application/x-www-form-urlencoded' > for URI parameters >=20 > Here is some feedback on the use of the 'application/x-www-form- > urlencoded' media type in the latest drafts (10 or 11). >=20 > The draft refers to the 'application/x-www-form-urlencoded' media type fo= r > encoding parameters into the query component of URIs. For instance, see > 4.1 in draft 11 has >=20 > "In order to direct the end-user's user-agent to the authorization > server, the client constructs the request URI by adding the following > parameters to the end-user authorization endpoint URI query component > using the "application/x-www-form-urlencoded" format as defined by > [W3C.REC-html401-19991224]" >=20 > However, this media type specifies how to encode parameters in the body o= f > a representation but not in URIs. In fact use of this encoding for charac= ters > like spaces will break URIs. >=20 > Subbu > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Internet-Drafts@ietf.org Wed Dec 1 23:00: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 17D273A68A3; Wed, 1 Dec 2010 23:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbns79XkhX1e; Wed, 1 Dec 2010 23:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1113A689D; Wed, 1 Dec 2010 23:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101202070002.21825.7224.idtracker@localhost> Date: Wed, 01 Dec 2010 23:00:02 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-bearer-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 07:00:04 -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: Bearer Tokens Author(s) : M. Jones, et al. Filename : draft-ietf-oauth-v2-bearer-00.txt Pages : 11 Date : 2010-12-01 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-00.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-bearer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-01225901.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Dec 1 23:15: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 A8DF93A68CF; Wed, 1 Dec 2010 23:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9+O5end72qk; Wed, 1 Dec 2010 23:15:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E773A68C6; Wed, 1 Dec 2010 23:15:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101202071502.27172.87495.idtracker@localhost> Date: Wed, 01 Dec 2010 23:15:02 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-bearer-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: Thu, 02 Dec 2010 07:15:11 -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: Bearer Tokens Author(s) : M. Jones, et al. Filename : draft-ietf-oauth-v2-bearer-01.txt Pages : 11 Date : 2010-12-01 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-bearer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-01230656.I-D@ietf.org> --NextPart-- From Michael.Jones@microsoft.com Wed Dec 1 23:34: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 B97E43A6838 for ; Wed, 1 Dec 2010 23:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Iuv0g91ucmpm for ; Wed, 1 Dec 2010 23:34:24 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id CE07C3A67FD for ; Wed, 1 Dec 2010 23:34:24 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 1 Dec 2010 23:35:39 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.228]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Wed, 1 Dec 2010 23:35:39 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuR84PTKQ3VtH/7T02XcbsmyzxgnA== Date: Thu, 2 Dec 2010 07:35:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739432463848ATK5EX14MBXC201r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 07:34:28 -0000 --_000_4E1F6AAD24975D4BA5B16804296739432463848ATK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -01 of the OAuth 2.0 Bearer Token specification is now available. Th= is version is intended to accompany OAuth 2.0 draft -11. This draft is based upon the= September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav, with input= from David Recordon and several others. It includes an extensive Security= Considerations section, for which Hannes Tschofenig gets significant credi= t. The draft is available at these locations: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repositor= y, with html, txt, and html versions available) If any of you believe that you should be added to the Acknowledgments in Ap= pendix A, please drop me a note and I'll be glad to add you. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739432463848ATK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -01 of the OAuth 2.0 Bearer Token specificatio= n is now available.  This version is intended to accompany = OAuth 2.0 draft -11.  This draft is based upon the September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav, with input from= David Recordon and several others.  It includes an extensive Security Considerations section, for which Hannes Ts= chofenig gets significant credit.

 

The draft is available at these locations:

http://www.ietf= .org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt

http://www.ietf.or= g/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml

http://self-issued.info/= docs/draft-ietf-oauth-v2-bearer-01.html

http://self-issued.info/d= ocs/draft-ietf-oauth-v2-bearer-01.txt

http://self-issued.info/d= ocs/draft-ietf-oauth-v2-bearer-01.xml

http://svn.openid.net/repos/specif= ications/oauth/2.0/ (Subversion repository, with html, txt, and html ve= rsions available)

 

If any of you believe that you should be added to th= e Acknowledgments in Appendix A, please drop me a note and I’ll be gl= ad to add you.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739432463848ATK5EX14MBXC201r_-- From andrea.reginato@gmail.com Thu Dec 2 01:42: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 B406F3A68E0 for ; Thu, 2 Dec 2010 01:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Y+nvphLjXaX6 for ; Thu, 2 Dec 2010 01:42:13 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EDFC13A68D6 for ; Thu, 2 Dec 2010 01:42:12 -0800 (PST) Received: by wwa36 with SMTP id 36so8342676wwa.13 for ; Thu, 02 Dec 2010 01:43:27 -0800 (PST) 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=JhE9DOheE+hvUJOKdkGdVIoARlhQn/hMcMjFH/dqhKE=; b=wc5HpZnBHL0FT0GvqXxzaNzN93ZGyZpKza17BwRSF4IxHZpHjUdlobXK9lKUWV/eQU 1WZHkIjaGl+CpiEPFLEBnBLsz33htNiHMJf9voxL20Ns2gRvIEAK+hEBfaL3VQZtdwth wBn2Fp9192cO9uNfihLagPdgEcO1g12j2ZoC0= 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=N36AQoqhPAYc/LU4gw/cgbUNP6S+i9768ilLk4Yj3oRtefuOIYeQbroilmJlNYFQAf Y+BzZAmVdQsPSFcP5AbEzH8sL3QBMVVlYzbJ07dXg5oZGvY8MRRPpV151yUiGOte9CZM /xuPEsmT3snikvHSEaIm9h5nqGso6uQKZh2KE= MIME-Version: 1.0 Received: by 10.227.29.204 with SMTP id r12mr10855273wbc.110.1291283007409; Thu, 02 Dec 2010 01:43:27 -0800 (PST) Received: by 10.227.147.143 with HTTP; Thu, 2 Dec 2010 01:43:27 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> Date: Thu, 2 Dec 2010 10:43:27 +0100 Message-ID: From: Andrea Reginato To: Mike Jones Content-Type: multipart/alternative; boundary=0022159755daf60dc304966a4042 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 09:42:15 -0000 --0022159755daf60dc304966a4042 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I was reading the specifications, mainly the new related to the security issues. One thing is pointed out in the security summary is related to the fact tha= t the token should not be in the URL. So, here come some of my doubts on the the user agent flow, where it is set on the URL fragment. Even more, if working only on the client side, I suppose I should save the token somewhere and th= e cookie, secure one, should be the option. There should also be the possibility to save it on a JavaScript variable, but this means I'll only use AJAX styl= e web page definition (no reloads). If possible, I would love to have some clarifications on the the user agent flow security definition. As far I've searched on the web several project do not use it because they think "its not secure", so I would love to understand more about. On Thu, Dec 2, 2010 at 8:35 AM, Mike Jones wro= te: > Draft -01 of the OAuth 2.0 Bearer Token specification is now available. > This version is intended to accompany OAuth 2.0 draft -11. > This draft is based upon the September 3rd preliminary OAuth 2.0 draft by > Eran Hammer-Lahav, with input from David Recordon and several others. It > includes an extensive Security Considerations section, for which Hannes > Tschofenig gets significant credit. > > > > The draft is available at these locations: > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml > > http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion > repository, with html, txt, and html versions available) > > > > If any of you believe that you should be added to the Acknowledgments in > Appendix A, please drop me a note and I=92ll be glad to add you. > > > > -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Andrea Reginato --0022159755daf60dc304966a4042 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I was reading the specifications, mainly the new related to the security is= sues.=A0

One thing is pointed out in the security summar= y is related to the fact that the=A0
token should not be in the U= RL. So, here come some of my doubts on the the
user agent flow, where it is set on the URL fragment. Even more, if wo= rking
only on the client side, I suppose I should save the token = somewhere and the
cookie, secure one, should be the option. There= should also be the possibility
to save it on a JavaScript variable, but this means I'll only use = AJAX style web
page definition (no reloads).

=
If possible, I would love to have some clarifications on the the user = agent flow
security definition. As far I've searched on the web several proje= ct do not use it
because they think "its not secure", s= o I would love to understand more about.

On Thu, Dec 2, 2010 at 8:35 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Draft -01 of the OAuth 2.0 Bearer Token specificatio= n is now available. =A0This version is intended to accompany OAuth 2.0 draft -11.=A0 This draft is based upon the = September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav, = with input from David Recordon and several others.=A0 It includes an extensive Security Considerations section, for which Hannes Ts= chofenig gets significant credit.

=A0

The draft is available at these locations:

http://www.ietf.org/= internet-drafts/draft-ietf-oauth-v2-bearer-01.txt

= http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml

http:/= /self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html

http://= self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt

http://= self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml

http://svn.openi= d.net/repos/specifications/oauth/2.0/ (Subversion repository, with html= , txt, and html versions available)

=A0

If any of you believe that you should be added to th= e Acknowledgments in Appendix A, please drop me a note and I=92ll be glad t= o add you.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0


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




--
Andrea Reginato
=
--0022159755daf60dc304966a4042-- From eran@hueniverse.com Thu Dec 2 07:23: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 6A0DD3A6971 for ; Thu, 2 Dec 2010 07:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.084, 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 LpT7P+JQdr2O for ; Thu, 2 Dec 2010 07:23:16 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D123828C15A for ; Thu, 2 Dec 2010 07:23:16 -0800 (PST) Received: (qmail 755 invoked from network); 2 Dec 2010 15:24:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Dec 2010 15:24:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 2 Dec 2010 08:24:19 -0700 From: Eran Hammer-Lahav To: Andrea Reginato , Mike Jones Date: Thu, 2 Dec 2010 08:24:33 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuSBWKgRoqlYRdYSeOVFPlJBytmKQAL4uWQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B065BEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.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_90C41DD21FB7C64BB94121FBBC2E72343D4B065BEAP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 15:23:21 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343D4B065BEAP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fragments are not allowed in the HTTP request URI and are not transmitted. = They are allowed in the Location header which is not an issue. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrea Reginato Sent: Thursday, December 02, 2010 1:43 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 I was reading the specifications, mainly the new related to the security is= sues. One thing is pointed out in the security summary is related to the fact tha= t the token should not be in the URL. So, here come some of my doubts on the the user agent flow, where it is set on the URL fragment. Even more, if working only on the client side, I suppose I should save the token somewhere and th= e cookie, secure one, should be the option. There should also be the possibil= ity to save it on a JavaScript variable, but this means I'll only use AJAX styl= e web page definition (no reloads). If possible, I would love to have some clarifications on the the user agent= flow security definition. As far I've searched on the web several project do not= use it because they think "its not secure", so I would love to understand more abo= ut. On Thu, Dec 2, 2010 at 8:35 AM, Mike Jones > wrote: Draft -01 of the OAuth 2.0 Bearer Token specification is now available. Th= is version is intended to accompany OAuth 2.0 draft -11. This draft is based upon the= September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav, with input= from David Recordon and several others. It includes an extensive Security= Considerations section, for which Hannes Tschofenig gets significant credi= t. The draft is available at these locations: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repositor= y, with html, txt, and html versions available) If any of you believe that you should be added to the Acknowledgments in Ap= pendix A, please drop me a note and I'll be glad to add you. -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Andrea Reginato --_000_90C41DD21FB7C64BB94121FBBC2E72343D4B065BEAP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fragments= are not allowed in the HTTP request URI and are not transmitted. They are = allowed in the Location header which is not an issue.

=

 

EHL

 

From: oauth-bounces@= ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrea Reginat= o
Sent: Thursday, December 02, 2010 1:43 AM
To: Mike Jo= nes
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.= 0 Bearer Token specification draft -01

 

I was reading t= he specifications, mainly the new related to the security issues. 

 

One thing is pointed out in the security summary is related = to the fact that the 

to= ken should not be in the URL. So, here come some of my doubts on the the

user agent flow, where it is se= t on the URL fragment. Even more, if working

only on the client side, I suppose I should save the token = somewhere and the

cookie, sec= ure one, should be the option. There should also be the possibility

to save it on a JavaScript variable,= but this means I'll only use AJAX style web

page definition (no reloads).

 

If po= ssible, I would love to have some clarifications on the the user agent flow=

security definition. As far = I've searched on the web several project do not use it

=

because they think "its not secure", so= I would love to understand more about.

 

On Thu, Dec 2, = 2010 at 8:35 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Draft -01 of the OAuth 2.0 Bearer Token specification is now available. =  This version is intended to accompany OAuth 2.0 dra= ft -11.  This draft is based upon the September 3rd pre= liminary OAuth 2.0 draft by Eran Hammer-Lahav, with input from David Record= on and several others.  It includes an extensive Security Consideratio= ns section, for which Hannes Tschofenig gets significant credit.=

 

The draft is available at these loca= tions:

http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt<= o:p>

http://www.i= etf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml

http://self-issued.info/docs/dr= aft-ietf-oauth-v2-bearer-01.html

= http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-0= 1.txt

http://se= lf-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml

http://svn.openid.net/repos/specifications/oa= uth/2.0/ (Subversion repository, with html, txt, and html versions avai= lable)

 

If any of you beli= eve that you should be added to the Acknowledgments in Appendix A, please d= rop me a note and I’ll be glad to add you.

 = ;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 


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


=

--
Andrea Reginato

= = --_000_90C41DD21FB7C64BB94121FBBC2E72343D4B065BEAP3PW5EX1MB01E_-- From kris.selden@gmail.com Thu Dec 2 08: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 2E58528C115 for ; Thu, 2 Dec 2010 08:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 7HofQFPsT8FM for ; Thu, 2 Dec 2010 08:14:45 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 94FDB28C0F4 for ; Thu, 2 Dec 2010 08:14:45 -0800 (PST) Received: by gwj17 with SMTP id 17so4683453gwj.31 for ; Thu, 02 Dec 2010 08:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=5YPRbsijPBBIfE80MtMciSm7t3VsXMFRWsf/tKMxjMs=; b=LC+9s4kIPjWOtAahEyDHqXTrv0BlRGdMPUkRwm6CG3CHmIYVV6p0BDy6e1awIm2+jm DjE23R27B4anP3TxzSrZ4NGVdysmyuxPYiIxu2Ha8qKxVmFWwVBm1sBdMXv37QQSQnAj eLGmJwsI/p3BCEqZUWn+WHP0BrxFQgP7MssX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=P8gbOIJquTJeEFIQoLjEoDXAERtycnDYMvjlS7CagGLUBqJMoLiTOEl0KuE0NSnvef JLPv/+wJlUDjfLLzYVo/eqlFO9xlQLICQcxUwCA1/VNF8OhRwytkJJumoy5AD/xekyK8 cPwo9KsJ+jA0pBia0i75Xv3kMT1pLXpMaJkcw= Received: by 10.150.217.4 with SMTP id p4mr1746748ybg.155.1291306560741; Thu, 02 Dec 2010 08:16:00 -0800 (PST) Received: from [172.16.2.7] (c-71-197-233-96.hsd1.wa.comcast.net [71.197.233.96]) by mx.google.com with ESMTPS id u3sm2536719yba.4.2010.12.02.08.15.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Dec 2010 08:15:59 -0800 (PST) References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065BEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B065BEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--533218385 Message-Id: X-Mailer: iPhone Mail (8B117) From: Kris Selden Date: Thu, 2 Dec 2010 08:16:29 -0800 To: Eran Hammer-Lahav Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 16:14:47 -0000 --Apple-Mail-1--533218385 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Also, when a browser follows the Location header it strips the fragment from= the URL. Fragments are visible to the client but not sent to the server. On Dec 2, 2010, at 7:24 AM, Eran Hammer-Lahav wrote: > Fragments are not allowed in the HTTP request URI and are not transmitted.= They are allowed in the Location header which is not an issue. >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrea Reginato > Sent: Thursday, December 02, 2010 1:43 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >=20 > =20 >=20 > I was reading the specifications, mainly the new related to the security i= ssues.=20 >=20 > =20 >=20 > One thing is pointed out in the security summary is related to the fact th= at the=20 >=20 > token should not be in the URL. So, here come some of my doubts on the the= >=20 > user agent flow, where it is set on the URL fragment. Even more, if workin= g >=20 > only on the client side, I suppose I should save the token somewhere and t= he >=20 > cookie, secure one, should be the option. There should also be the possibi= lity >=20 > to save it on a JavaScript variable, but this means I'll only use AJAX sty= le web >=20 > page definition (no reloads). >=20 > =20 >=20 > If possible, I would love to have some clarifications on the the user agen= t flow >=20 > security definition. As far I've searched on the web several project do no= t use it >=20 > because they think "its not secure", so I would love to understand more ab= out. >=20 > =20 >=20 > On Thu, Dec 2, 2010 at 8:35 AM, Mike Jones w= rote: >=20 > Draft -01 of the OAuth 2.0 Bearer Token specification is now available. T= his version is intended to accompany OAuth 2.0 draft -11. This draft is bas= ed upon the September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav, w= ith input from David Recordon and several others. It includes an extensive S= ecurity Considerations section, for which Hannes Tschofenig gets significant= credit. >=20 > =20 >=20 > The draft is available at these locations: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt >=20 > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml >=20 > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html >=20 > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt >=20 > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml >=20 > http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion reposito= ry, with html, txt, and html versions available) >=20 > =20 >=20 > If any of you believe that you should be added to the Acknowledgments in A= ppendix A, please drop me a note and I=E2=80=99ll be glad to add you. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > Andrea Reginato >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1--533218385 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Also, when a browser follows the Locati= on header it strips the fragment from the URL. Fragments are visible to the c= lient but not sent to the server.

On Dec 2, 2010, at 7:24 AM, E= ran Hammer-Lahav <eran@hueniverse.= com> wrote:

Fra= gments are not allowed in the HTTP request URI and are not transmitted. They= are allowed in the Location header which is not an issue.=

 

EHL<= /p>

 =

From:= oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf Of Andrea Reginato
= Sent: Thursday, December 02, 2010 1:43 AM
To: Mike JonesCc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Beare= r Token specification draft -01

 

I was reading the sp= ecifications, mainly the new related to the security issues. 

 

One thing is pointed out in the security summary is related to t= he fact that the 

token= should not be in the URL. So, here come some of my doubts on the the

user agent flow, where it is set o= n the URL fragment. Even more, if working

only on the client side, I suppose I should save the token somew= here and the

cookie, secure o= ne, should be the option. There should also be the possibility

to save it on a JavaScript variable, but t= his means I'll only use AJAX style web

page definition (no reloads).

 

If possib= le, I would love to have some clarifications on the the user agent flow=

security definition. As far I've= searched on the web several project do not use it

=

because they think "its not secure", so I would love t= o understand more about.

 

On Thu, Dec 2, 2010 at 8:35 AM= , Mike Jones <Michael.Jones@microsoft.com> w= rote:

Draft -01 of the OAuth 2.0 Bearer Toke= n specification is now available.  This version is intended to accompan= y OAuth 2.0 draft -11.  This draft is based upon t= he September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav= , with input from David Recordon and several others.  It includes an ex= tensive Security Considerations section, for which Hannes Tschofenig gets si= gnificant credit.

 

The dra= ft is available at these locations:

http://www.ietf.org/internet-drafts/draft-= ietf-oauth-v2-bearer-01.txt

<= a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.= xml" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-= oauth-v2-bearer-01.xml

http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html<= /a>

http://self-i= ssued.info/docs/draft-ietf-oauth-v2-bearer-01.txt

http://self-issued.info/docs/draft-ietf= -oauth-v2-bearer-01.xml

http://s= vn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository= , with html, txt, and html versions available)

 =

If any of you believe that you should be added to the= Acknowledgments in Appendix A, please drop me a note and I=E2=80=99ll be gl= ad to add you.

 

 &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;       -- Mike

 = ;


_______________________________________________
OAuth mailing l= ist
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">

<= br>--
Andrea Reginato

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h
= --Apple-Mail-1--533218385-- From subbu@subbu.org Thu Dec 2 11:19: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 99AF328C159 for ; Thu, 2 Dec 2010 11:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 grjNuA5kPqyc for ; Thu, 2 Dec 2010 11:19:27 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B086A28C14D for ; Thu, 2 Dec 2010 11:19:26 -0800 (PST) Received: by eyd10 with SMTP id 10so4727234eyd.31 for ; Thu, 02 Dec 2010 11:20:42 -0800 (PST) Received: by 10.223.109.199 with SMTP id k7mr1009850fap.93.1291317641925; Thu, 02 Dec 2010 11:20:41 -0800 (PST) Received: from wlan-snve-154-178.corp.yahoo.com (nat-dip6.cfw-a-gci.corp.yahoo.com [209.131.62.115]) by mx.google.com with ESMTPS id 21sm340394fav.41.2010.12.02.11.20.39 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Dec 2010 11:20:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Subbu Allamaraju In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B065B2A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 2 Dec 2010 11:20:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <174D976E-CCA1-476B-8257-F87DCDF1AAA7@subbu.org> References: <69A9A98B-89A1-4C42-88C2-AC682C1827AB@subbu.org> <90C41DD21FB7C64BB94121FBBC2E72343D4B065B2A@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Comment on 'application/x-www-form-urlencoded' for URI parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 19:19:28 -0000 Eran - but that does change anything. That HTML4/HTML5 media type does = not specify how to encode parameters into query portion of URIs. I'm not = aware of any RFC that describes this name=3Dvalue pair encoding. So, = OAuth draft needs to specify how a client needs to manipulate = auth/resource server's URIs to add protocol-specific parameters. Subbu On Dec 1, 2010, at 2:16 PM, Eran Hammer-Lahav wrote: > The latest reference is: >=20 > = http://www.w3.org/TR/html5/association-of-controls-and-forms.html#applicat= ion-x-www-form-urlencoded-encoding-algorithm >=20 > But that's still a draft. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Subbu Allamaraju >> Sent: Wednesday, December 01, 2010 2:05 PM >> To: OAuth WG >> Subject: [OAUTH-WG] Comment on 'application/x-www-form-urlencoded' >> for URI parameters >>=20 >> Here is some feedback on the use of the 'application/x-www-form- >> urlencoded' media type in the latest drafts (10 or 11). >>=20 >> The draft refers to the 'application/x-www-form-urlencoded' media = type for >> encoding parameters into the query component of URIs. For instance, = see >> 4.1 in draft 11 has >>=20 >> "In order to direct the end-user's user-agent to the authorization >> server, the client constructs the request URI by adding the = following >> parameters to the end-user authorization endpoint URI query = component >> using the "application/x-www-form-urlencoded" format as defined by >> [W3C.REC-html401-19991224]" >>=20 >> However, this media type specifies how to encode parameters in the = body of >> a representation but not in URIs. In fact use of this encoding for = characters >> like spaces will break URIs. >>=20 >> Subbu >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Dec 2 11:24: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 1ABBA28C13A for ; Thu, 2 Dec 2010 11:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 ZVqlZ0y7RhSB for ; Thu, 2 Dec 2010 11:24:40 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D3F023A69D6 for ; Thu, 2 Dec 2010 11:24:38 -0800 (PST) Received: (qmail 19175 invoked from network); 2 Dec 2010 19:25:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Dec 2010 19:25:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 2 Dec 2010 12:25:50 -0700 From: Eran Hammer-Lahav To: Subbu Allamaraju Date: Thu, 2 Dec 2010 12:26:06 -0700 Thread-Topic: [OAUTH-WG] Comment on 'application/x-www-form-urlencoded' for URI parameters Thread-Index: AcuSVg4iNoqqwcFzRPuuTmZk+qelkgAAFbYQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B065C8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <69A9A98B-89A1-4C42-88C2-AC682C1827AB@subbu.org> <90C41DD21FB7C64BB94121FBBC2E72343D4B065B2A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <174D976E-CCA1-476B-8257-F87DCDF1AAA7@subbu.org> In-Reply-To: <174D976E-CCA1-476B-8257-F87DCDF1AAA7@subbu.org> 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] Comment on 'application/x-www-form-urlencoded' for URI parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 19:24:49 -0000 Using form-encoding to encode the URI query is well established and directl= y based on the media type rules. No further specification is needed. EHL > -----Original Message----- > From: Subbu Allamaraju [mailto:subbu@subbu.org] > Sent: Thursday, December 02, 2010 11:21 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Comment on 'application/x-www-form- > urlencoded' for URI parameters >=20 > Eran - but that does change anything. That HTML4/HTML5 media type does > not specify how to encode parameters into query portion of URIs. I'm not > aware of any RFC that describes this name=3Dvalue pair encoding. So, OAut= h > draft needs to specify how a client needs to manipulate auth/resource > server's URIs to add protocol-specific parameters. >=20 > Subbu >=20 > On Dec 1, 2010, at 2:16 PM, Eran Hammer-Lahav wrote: >=20 > > The latest reference is: > > > > http://www.w3.org/TR/html5/association-of-controls-and- > forms.html#appl > > ication-x-www-form-urlencoded-encoding-algorithm > > > > But that's still a draft. > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Subbu Allamaraju > >> Sent: Wednesday, December 01, 2010 2:05 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] Comment on 'application/x-www-form- > urlencoded' > >> for URI parameters > >> > >> Here is some feedback on the use of the 'application/x-www-form- > >> urlencoded' media type in the latest drafts (10 or 11). > >> > >> The draft refers to the 'application/x-www-form-urlencoded' media > >> type for encoding parameters into the query component of URIs. For > >> instance, see > >> 4.1 in draft 11 has > >> > >> "In order to direct the end-user's user-agent to the authorization > >> server, the client constructs the request URI by adding the followin= g > >> parameters to the end-user authorization endpoint URI query > component > >> using the "application/x-www-form-urlencoded" format as defined by > >> [W3C.REC-html401-19991224]" > >> > >> However, this media type specifies how to encode parameters in the > >> body of a representation but not in URIs. In fact use of this > >> encoding for characters like spaces will break URIs. > >> > >> Subbu > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Thu Dec 2 12:18: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 2D9A928C144 for ; Thu, 2 Dec 2010 12:18:10 -0800 (PST) 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 or5eya2aKxEk for ; Thu, 2 Dec 2010 12:18:09 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0E82C28C131 for ; Thu, 2 Dec 2010 12:18:08 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id oB2KJOY3000903 for ; Thu, 2 Dec 2010 12:19:25 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291321165; bh=2k8pf+k/jQvVR/DRWuEk63vFDRo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=k6ZnyaoJeVdyP7qutpeh5j8TyeIY/SQ8jCKYRDyM3ZWtyGwn23a0o/e8kn68fhwAq qA4rkaD0AjYlq8moXzs5w== Received: from gxk24 (gxk24.prod.google.com [10.202.11.24]) by wpaz1.hot.corp.google.com with ESMTP id oB2KJGgv021929 for ; Thu, 2 Dec 2010 12:19:24 -0800 Received: by gxk24 with SMTP id 24so4574863gxk.32 for ; Thu, 02 Dec 2010 12:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=TbYBrh57nC1ZM6QZ3kPCFoDJwmZ4Q/tVlU4JW8lj7+0=; b=iBOYTCFFYvLTwEgHGq9oWkwuFnEe8ms5BVtkvbI2PG3pjR1xR2iYH2nYpd9QU7oulL 4fJv+F0a5l6FM0OJ1Z0A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=V9U5OiMQy/s3hjEdt1fBQwxIt0eOSYY86c5RIPmd6H+IiYdlFkGvTN48rSbp3lRG73 7ZS8i+5Qw66IqhwQ5soA== Received: by 10.100.13.11 with SMTP id 11mr812597anm.20.1291321163663; Thu, 02 Dec 2010 12:19:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Thu, 2 Dec 2010 12:19:03 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Thu, 2 Dec 2010 12:19:03 -0800 Message-ID: To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 20:18:10 -0000 OAuth 2 Protocol Framework v11 introduces a new required parameter: token_t= ype. Should the Bearer Token spec define the value for this parameter for bearer tokens? Are we blocked by the missing section 6.1. (Access Token Types) of the Framework spec? Marius On Wed, Dec 1, 2010 at 11:35 PM, Mike Jones w= rote: > Draft -01 of the OAuth 2.0 Bearer Token specification is now available. > =A0This version is intended to accompany OAuth 2.0 draft -11.=A0 This dra= ft is > based upon the September 3rd preliminary OAuth 2.0 draft by Eran > Hammer-Lahav, with input from David Recordon and several others.=A0 It > includes an extensive Security Considerations section, for which Hannes > Tschofenig gets significant credit. > > > > The draft is available at these locations: > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml > > http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion > repository, with html, txt, and html versions available) > > > > If any of you believe that you should be added to the Acknowledgments in > Appendix A, please drop me a note and I=92ll be glad to add you. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Thu Dec 2 12: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 3096728C199 for ; Thu, 2 Dec 2010 12:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, 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 XyjGcE+anD-M for ; Thu, 2 Dec 2010 12:21:29 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id ABBF328C131 for ; Thu, 2 Dec 2010 12:21:29 -0800 (PST) Received: (qmail 19761 invoked from network); 2 Dec 2010 20:22:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2010 20:22:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 2 Dec 2010 13:22:40 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , Mike Jones Date: Thu, 2 Dec 2010 13:22:55 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuSXkMhj/qpF0UhR7GQKXrTeLLj1AAADUKw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 20:21:32 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Thursday, December 02, 2010 12:19 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >=20 > OAuth 2 Protocol Framework v11 introduces a new required parameter: > token_type. >=20 > Should the Bearer Token spec define the value for this parameter for bear= er > tokens? Yes. 'bearer' seems sensible, but I don't really care. I am going to define= 'mac' in my own extension. =20 > Are we blocked by the missing section 6.1. (Access Token Types) of the > Framework spec? No. It will simply describe the general flow and how to define (register) t= oken types and authentication methods for those types. IOW, all spec-talk. = You can decide how it works and implement and deal with the extension paper= work later. EHL =20 > Marius >=20 >=20 >=20 > On Wed, Dec 1, 2010 at 11:35 PM, Mike Jones > wrote: > > Draft -01 of the OAuth 2.0 Bearer Token specification is now available. > > =A0This version is intended to accompany OAuth 2.0 draft -11.=A0 This > > draft is based upon the September 3rd preliminary OAuth 2.0 draft by > > Eran Hammer-Lahav, with input from David Recordon and several others. > > It includes an extensive Security Considerations section, for which > > Hannes Tschofenig gets significant credit. > > > > > > > > The draft is available at these locations: > > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt > > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml > > > > http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion > > repository, with html, txt, and html versions available) > > > > > > > > If any of you believe that you should be added to the Acknowledgments > > in Appendix A, please drop me a note and I'll be glad to add you. > > > > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > > > > > _______________________________________________ > > 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 Thu Dec 2 12:29: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 54D123A69CF for ; Thu, 2 Dec 2010 12:29:14 -0800 (PST) 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 tECYZCcNQeLO for ; Thu, 2 Dec 2010 12:29:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A3B5E3A69C2 for ; Thu, 2 Dec 2010 12:29:12 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id oB2KURnU020398 for ; Thu, 2 Dec 2010 12:30:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291321828; bh=9QDA9mKcsG3q4Sgagamqar3yKxk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=bKZIWvCXxI717WGgFkVMRDRNLbwpdt35ZOXlus+onY2M0Z/cZFdnobxUs2bcBxIvT 8PZ1dlJ/InwnpmtEcdtyw== Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by hpaq1.eem.corp.google.com with ESMTP id oB2KTk80019366 for ; Thu, 2 Dec 2010 12:30:26 -0800 Received: by yxe42 with SMTP id 42so5520605yxe.37 for ; Thu, 02 Dec 2010 12:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=u4UyRO0f17YddAnDu8Hj+B/jkuB1hS27uZeIDVydP7s=; b=NFefBN2J+Phm66x9VQiI4yBe7Y3i6QhBbVpkR+bCYUlGXiR2fRcwkN/ZvC08fy8Bwb p5Y+1OZHSYLVkLZ9grGA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=iaKpdXAHy975RtkPSDaXLhp+fyUTx03f8zJ2WNw8Deayawonpp/Bi+8N+T0IwK1aPq RP7eOXZW6TXM+liavfSg== Received: by 10.101.165.35 with SMTP id s35mr776176ano.190.1291321805351; Thu, 02 Dec 2010 12:30:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Thu, 2 Dec 2010 12:29:45 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 2 Dec 2010 12:29:45 -0800 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] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 20:29:14 -0000 "bearer" sounds good. Thanks for clarifying 6.1. Both specs look great! Thanks, Marius On Thu, Dec 2, 2010 at 12:22 PM, Eran Hammer-Lahav wr= ote: > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Marius Scurtescu >> Sent: Thursday, December 02, 2010 12:19 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >> >> OAuth 2 Protocol Framework v11 introduces a new required parameter: >> token_type. >> >> Should the Bearer Token spec define the value for this parameter for bea= rer >> tokens? > > Yes. 'bearer' seems sensible, but I don't really care. I am going to defi= ne 'mac' in my own extension. > >> Are we blocked by the missing section 6.1. (Access Token Types) of the >> Framework spec? > > No. It will simply describe the general flow and how to define (register)= token types and authentication methods for those types. IOW, all spec-talk= . You can decide how it works and implement and deal with the extension pap= erwork later. > > EHL > >> Marius >> >> >> >> On Wed, Dec 1, 2010 at 11:35 PM, Mike Jones >> wrote: >> > Draft -01 of the OAuth 2.0 Bearer Token specification is now available= . >> > =A0This version is intended to accompany OAuth 2.0 draft -11.=A0 This >> > draft is based upon the September 3rd preliminary OAuth 2.0 draft by >> > Eran Hammer-Lahav, with input from David Recordon and several others. >> > It includes an extensive Security Considerations section, for which >> > Hannes Tschofenig gets significant credit. >> > >> > >> > >> > The draft is available at these locations: >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml >> > >> > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html >> > >> > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt >> > >> > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml >> > >> > http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion >> > repository, with html, txt, and html versions available) >> > >> > >> > >> > If any of you believe that you should be added to the Acknowledgments >> > in Appendix A, please drop me a note and I'll be glad to add you. >> > >> > >> > >> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike >> > >> > >> > >> > _______________________________________________ >> > 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 Dec 2 13:03: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 3BF203A67B1 for ; Thu, 2 Dec 2010 13:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 9bwBrcAqhwSt for ; Thu, 2 Dec 2010 13:03:07 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 68AE73A635F for ; Thu, 2 Dec 2010 13:03:07 -0800 (PST) Received: (qmail 20414 invoked from network); 2 Dec 2010 21:04:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Dec 2010 21:04:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 2 Dec 2010 14:04:14 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Thu, 2 Dec 2010 14:04:29 -0700 Thread-Topic: Bikeshedding poll: 'attributes' parameter vs. attributes parameters Thread-Index: AcuSY7ZEm/j2A80+QwiUerDdAF8qHg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B065CD9@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] Bikeshedding poll: 'attributes' parameter vs. attributes parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 21:03:08 -0000 I'm defining a new token type: MAC based on my previous HTTP Token authenti= cation draft (which in turn was based on 1.0a HMAC-SHA1). This is being dra= fted and implemented in my current project (in node.js). I will have a draf= t to share shortly (I do not plan to make this a WG item, but will not obje= ct if the group wants to). When issuing a token, the authorization server needs to provide two additio= nal attributes: - mac algorithm (hmac-sha1 and hmac-sha256 will be defined) - secret I have two options; extend the token response by registering: 1. Type specific parameters: 'mac_algorithm' and 'token_secret' 2. Generic parameter: 'attributes' with some form of key-value pairs I prefer #1 because it is much simpler. However, #2 is cleaner and better i= f we end up with a lot of token types. So I'm going with #1 but open to other suggestions and feedback. EHL From jricher@mitre.org Thu Dec 2 13: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 6BE363A699D for ; Thu, 2 Dec 2010 13:43:31 -0800 (PST) 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=[AWL=0.000, 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 twiEaPdhLb0B for ; Thu, 2 Dec 2010 13:43:30 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 6AD913A6452 for ; Thu, 2 Dec 2010 13:43:30 -0800 (PST) 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 oB2LikbI002468 for ; Thu, 2 Dec 2010 16:44:46 -0500 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 oB2LijHa002455; Thu, 2 Dec 2010 16:44:45 -0500 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Thu, 2 Dec 2010 16:44:45 -0500 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B065CD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343D4B065CD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 2 Dec 2010 16:44:44 -0500 Message-ID: <1291326284.32049.261.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Bikeshedding poll: 'attributes' parameter vs. attributes parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 21:43:31 -0000 #1 #2 feels like overengineering, and we're going to end up with things that spit back stuff that aren't token attributes anyway that will want to put them at the top level. Also, no need to require a more complex structure. I tried to make it so that the XML encoding can handle more complex things like lists and sub-objects, but even so I'd rather keep the basic specification (and recommendations for extensions) as flat as possible. -- Justin On Thu, 2010-12-02 at 16:04 -0500, Eran Hammer-Lahav wrote: > I'm defining a new token type: MAC based on my previous HTTP Token authentication draft (which in turn was based on 1.0a HMAC-SHA1). This is being drafted and implemented in my current project (in node.js). I will have a draft to share shortly (I do not plan to make this a WG item, but will not object if the group wants to). > > When issuing a token, the authorization server needs to provide two additional attributes: > > - mac algorithm (hmac-sha1 and hmac-sha256 will be defined) > - secret > > I have two options; extend the token response by registering: > > 1. Type specific parameters: 'mac_algorithm' and 'token_secret' > 2. Generic parameter: 'attributes' with some form of key-value pairs > > I prefer #1 because it is much simpler. However, #2 is cleaner and better if we end up with a lot of token types. > > So I'm going with #1 but open to other suggestions and feedback. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Thu Dec 2 13:55: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 B8DC23A6359 for ; Thu, 2 Dec 2010 13:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 XThqCAw0l4To for ; Thu, 2 Dec 2010 13:55:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id B886D3A697E for ; Thu, 2 Dec 2010 13:55:10 -0800 (PST) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id oB2LuQRf017645 for ; Thu, 2 Dec 2010 13:56:26 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291326986; bh=TH9MF/kVWeIRkBwFztwSX0rdHrM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Ofss3HMUmlfWh5OODgjEHt8MyaTijl1AWj89aHh4d1xr9S0xIGXa4YsHv02K86CT2 RGo4aK/GgYaAiq0aiExSA== Received: from yxd5 (yxd5.prod.google.com [10.190.1.197]) by hpaq2.eem.corp.google.com with ESMTP id oB2LuOm5007634 for ; Thu, 2 Dec 2010 13:56:25 -0800 Received: by yxd5 with SMTP id 5so4869883yxd.20 for ; Thu, 02 Dec 2010 13:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=SyWqEkXDwuZGDYYQpzmArLfIARcyBVUpr04dTSOpxTY=; b=ONriEAqwXM0bLiv+4Biqyv/N0ONj75iACGNW5rOczJ7+wkyPm/jcf17YybhW4NaaBd UmcdpPUjBPonoxJ5wXgQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=MuAwojZhoKUn5gWwsfwLr1cTR3DmYRwU8y95gySC8aJt4vN0lf9whemtAjbcx/juMU +CMhnbgGv44tedbdN+Yw== Received: by 10.100.119.5 with SMTP id r5mr869268anc.88.1291326984139; Thu, 02 Dec 2010 13:56:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Thu, 2 Dec 2010 13:56:04 -0800 (PST) In-Reply-To: <1291326284.32049.261.camel@pulse> References: <90C41DD21FB7C64BB94121FBBC2E72343D4B065CD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1291326284.32049.261.camel@pulse> From: Marius Scurtescu Date: Thu, 2 Dec 2010 13:56:04 -0800 Message-ID: To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Bikeshedding poll: 'attributes' parameter vs. attributes parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 21:55:11 -0000 On Thu, Dec 2, 2010 at 1:44 PM, Justin Richer wrote: > #1 > > #2 feels like overengineering, and we're going to end up with things > that spit back stuff that aren't token attributes anyway that will want > to put them at the top level. > > Also, no need to require a more complex structure. I tried to make it so > that the XML encoding can handle more complex things like lists and > sub-objects, but even so I'd rather keep the basic specification (and > recommendations for extensions) as flat as possible. Same here, I think #1 makes more sense. And, I don't think we have to worry about collision across token types, only one will be use at a time. Marius From James.H.Manger@team.telstra.com Thu Dec 2 15:40: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 A185D28C132 for ; Thu, 2 Dec 2010 15:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 wqKeHxjIHjnO for ; Thu, 2 Dec 2010 15:40:42 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 586FC28C12B for ; Thu, 2 Dec 2010 15:40:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,290,1288530000"; d="scan'208";a="19059286" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 03 Dec 2010 10:41:57 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6185"; a="14551496" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 03 Dec 2010 10:41:57 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 3 Dec 2010 09:41:56 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 3 Dec 2010 09:41:55 +1000 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuSX8hmJOkfgwswSLCmwCDoUYn81AAEtzvg Message-ID: <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 02 Dec 2010 23:40:43 -0000 token_type should be an HTTP authentication scheme name (eg "BASIC" or "BEA= RER" or "MAC"...). The core spec (draft-ietf-oauth-v2) should explicitly state this rule. >From the token_type, the client app knows which auth scheme to use. [renaming the parameter from "token_type" to "scheme" would help.] Defining token_type to be an HTTP authentication scheme name effectively de= fines how OAuth2 can deliver credentials for auth schemes that are independ= ent of OAuth2, eg schemes specified before OAuth2 existed. It eliminates th= e need for additional specs just to provide a link from OAuth2 to every aut= hentication mechanism. Some auth mechanisms for which OAuth2 could deliver credentials are not act= ually HTTP authentication schemes. Eg OAuth2 delivering an id/secret to use= in TLS-PSK (pre-shared key). For that you will need a small additional spe= c to define a token_type value -- ie define a pseudo-HTTP-auth-scheme-name. P.S. Related to this, the bearer spec (draft-ietf-oauth-v2-bearer) must not= use the "OAuth2" scheme name. It needs its own scheme name, eg "BEARER". -- James Manger From James.H.Manger@team.telstra.com Thu Dec 2 16:53: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 2AD9D28C128 for ; Thu, 2 Dec 2010 16:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.422 X-Spam-Level: X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qle+jWvxBG0F for ; Thu, 2 Dec 2010 16:53:32 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 0E6853A6A27 for ; Thu, 2 Dec 2010 16:53:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,290,1288530000"; d="scan'208,217";a="18701874" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 03 Dec 2010 11:54:46 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6185"; a="14490991" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 03 Dec 2010 11:54:46 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Fri, 3 Dec 2010 11:54:45 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 3 Dec 2010 11:54:40 +1100 Thread-Topic: draft-ietf-oauth-v2-bearer: scheme name Thread-Index: AcuR84PTKQ3VtH/7T02XcbsmyzxgnAAi1vcQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1127A6EA270@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.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_255B9BB34FB7D647A506DC292726F6E1127A6EA270WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer: scheme name X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Dec 2010 00:53:37 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127A6EA270WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike Jones, Thanks for writing draft-ietf-oauth-v2-bearer-01. I feel there are some major problems with this draft, though. Primarily, it is bound so tightly to OAuth2 core that it misses the point (= & benefit) of separating the specs. This draft re-uses the "OAuth2" HTTP authentication scheme name. It uses it= to transmit a bearer token from a client app to a web server. This scheme = name is already used by the core spec (draft-ietf-oauth-v2). The core spec = uses it to indicate when a client needs to do a delegation/get-a-token/swap= -longterm-cred-for-shortterm-cred flow (and hopefully in the future it will= indicate the URIs for doing those flows). These core & bearer uses are qui= te different. They are different enough that different scheme names need to= be used. The reason the bearer draft almost gets away with re-using OAuth2 is that i= s only defines an "Authorization: OAuth2 ..." header, while the core spec o= nly defines an "WWW-Authenticate: OAuth2 ..." header so the clash isn't obv= ious. However, the bearer draft could (and should) usefully define a WWW-Au= thenticate response header. For instance, such a header could indicate whet= her or not the server supports bearer tokens in URI query parameters, and/o= r in the body. At the moment a server MAY support these, with no nice way f= or a client app to tell. Splitting the OAuth2 document recognised that OAuth2 delegation flows can d= eliver credentials for different authentication schemes - so one such authe= ntication scheme should not hijack the OAuth2 name. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127A6EA270WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike Jones,=

 

Thanks for writing dra= ft-ietf-oauth-v2-bearer-01.

I feel there are some = major problems with this draft, though.

Primarily, it is bound= so tightly to OAuth2 core that it misses the point (& benefit) of sepa= rating the specs.

 

This draft re-uses the= “OAuth2” HTTP authentication scheme name. It uses it to transm= it a bearer token from a client app to a web server. This scheme name is al= ready used by the core spec (draft-ietf-oauth-v2). The core spec uses it to indicate when a client needs to do a delegation/g= et-a-token/swap-longterm-cred-for-shortterm-cred flow (and hopefully in the= future it will indicate the URIs for doing those flows). These core & = bearer uses are quite different. They are different enough that different scheme names need to be used.

 

The reason the bearer = draft almost gets away with re-using OAuth2 is that is only defines an R= 20;Authorization: OAuth2 …” header, while the core spec only de= fines an “WWW-Authenticate: OAuth2 …” header so the clash isn’t obvious. However, the bearer draft could (and should) usefully= define a WWW-Authenticate response header. For instance, such a header cou= ld indicate whether or not the server supports bearer tokens in URI query p= arameters, and/or in the body. At the moment a server MAY support these, with no nice way for a client app to te= ll.

 

Splitting the OAuth2 d= ocument recognised that OAuth2 delegation flows can deliver credentials for= different authentication schemes – so one such authentication scheme= should not hijack the OAuth2 name.

 

 

--

James Manger

 

--_000_255B9BB34FB7D647A506DC292726F6E1127A6EA270WSMSG3153Vsrv_-- From mscurtescu@google.com Thu Dec 2 17:34: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 B0F6D3A67E1 for ; Thu, 2 Dec 2010 17:34:00 -0800 (PST) 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 Zg+WuNFjPb2K for ; Thu, 2 Dec 2010 17:33:58 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 35DB03A69DA for ; Thu, 2 Dec 2010 17:33:57 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id oB31ZDt7022938 for ; Thu, 2 Dec 2010 17:35:14 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291340114; bh=rtNE+ReaP3T4Cp7LlFflkO3aZ34=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=mD6dtC47TjX2o9OCtzB80fRXIJK9ddm5mKpT/sRXKjCybvXEzhPPf6SLldzFUwy1S Tz/mva4CjQxlDtwWRTAYg== Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by kpbe11.cbf.corp.google.com with ESMTP id oB31ZCQG006586 for ; Thu, 2 Dec 2010 17:35:13 -0800 Received: by gxk28 with SMTP id 28so4480097gxk.17 for ; Thu, 02 Dec 2010 17:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=OmU/6udmF38/mDuFwOxVNUhC3w7gqTDZDevEhz6tqhY=; b=aHhWni9IDG/SkOUHQl+rHY3VRQiQajzgR/NlJkbH3IOVXu0N4PUq3307tq/1G/pTTx +RzZn9RdPoAGBgKfDmoA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=XynNeEfgnUbV6JF+Wu1pLdSjoTaUwXtUv5Ggu2baLZpxm/b2qc9/8MamMxt2iZMYMO ucjVsrtVxxhL6vR75YmQ== Received: by 10.100.119.5 with SMTP id r5mr1020253anc.88.1291340112389; Thu, 02 Dec 2010 17:35:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Thu, 2 Dec 2010 17:34:52 -0800 (PST) From: Marius Scurtescu Date: Thu, 2 Dec 2010 17:34:52 -0800 Message-ID: To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] Client Password Credentials X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Dec 2010 01:34:01 -0000 Currently there are two different ways a client can send credentials, as specified in section 3.1, and: "The authorization server MUST accept the client credentials using both the request parameter, and the HTTP Basic authentication scheme." I know there was a long thread on this subject, but I cannot recall the reasoning. Can someone summarize it? How many of the existing OAuth 2 server implementations out there currently support both methods? Thanks, Marius From James.H.Manger@team.telstra.com Thu Dec 2 19:57: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 43B423A6A53 for ; Thu, 2 Dec 2010 19:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_65=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 I4zFqTAiaQnD for ; Thu, 2 Dec 2010 19:57:51 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 259E13A6A51 for ; Thu, 2 Dec 2010 19:57:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,291,1288530000"; d="scan'208";a="18724520" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 03 Dec 2010 14:59:06 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6185"; a="14579411" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcavi.tcif.telstra.com.au with ESMTP; 03 Dec 2010 14:59:06 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Fri, 3 Dec 2010 14:59:06 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 3 Dec 2010 14:59:04 +1100 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuSX8hmJOkfgwswSLCmwCDoUYn81AAEtzvgAAflxEAAAYywQA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Dec 2010 03:57:52 -0000 Eran, > What does scheme=3Dbasic mean [in a token response]? It means this token response contains credentials that can be used with the= HTTP BASIC authentication scheme. Don't try to use the credentials with an= y other scheme. The access_token value would be used as the user-id, and th= e token_secret value as the password. > I think tying type and scheme together is less intuitive then > letting the type definition provide the right scheme(s). Keeping them separate offers an additional degree of indirection. Indirection is sometimes useful, but I don't think it adds any value here. It just means we need another registry (of token_types, with associated pro= cedures); and we need an extra spec for each authentication mechanism to de= fine the linkage to OAuth2. A lot of authentication mechanisms take similar inputs (an id and a secret)= so they shouldn't each need a separate spec to define their binding to OAu= th2. > I am using 'MAC' for my draft. As the token_type? As the HTTP authentication scheme? I hope both. > But its still an OAuth2 extension, not a completely generic HTTP scheme. I guess it is an OAuth2 extension in as much as it defines how to get MAC c= redentials from an OAuth2 token response: check token_type=3DMAC; access_to= ken is the id; token_secret is the MAC key; mac_algorithm is the MAC algori= thm. > It can be used independent of OAuth2 if you somehow got > a token, secret, and mac algorithm name. Hopefully you define a "WWW-Authenticate: MAC ..." response header that can= list acceptable MAC algorithms. I think an OAuth2 token response for a MAC scheme should contain the same i= nformation as the WWW-Authenticate response header for the MAC scheme, plus= the credentials to use (id & secret) and the OAuth2-specific lifetime mana= gement bits (eg how/when to refresh). We should explicitly define (in core)= how to put a WWW-Authenticate header into a token response. -- James Manger From James.H.Manger@team.telstra.com Thu Dec 2 21:00: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 725D73A6A5C for ; Thu, 2 Dec 2010 21:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 FSvg8pKRXo8A for ; Thu, 2 Dec 2010 21:00:21 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id AE2133A6843 for ; Thu, 2 Dec 2010 21:00:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,291,1288530000"; d="scan'208,217";a="21977384" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 03 Dec 2010 16:01:35 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6185"; a="14746677" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 03 Dec 2010 16:01:35 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 3 Dec 2010 16:01:35 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 3 Dec 2010 16:01:33 +1100 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer: token characters Thread-Index: AcuSpygAvWIojtdxRs6+VqtB8J58IA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1127A6EA89B@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_255B9BB34FB7D647A506DC292726F6E1127A6EA89BWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer: token characters X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Dec 2010 05:00:25 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127A6EA89BWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In draft-ietf-oauth-v2-bearer-01 section 2.1 "The Authorization Request Hea= der Field" an access-token can use 93 ASCII characters, including: comma, d= ouble-quote, equals, backslash etc. These have no special meaning. No escap= ing is defined. This is fairly diabolical. It is incompatible with the RFC2617 spec for the Authorization header, wher= e after the scheme name come comma-separated name=3Dvalue pairs. A name is = a (77 allowed ASCII chars). A value is a or a (226 allowed ISO-8859-1 chars, 2 needing escaping). It is incompatible with draft-ietf-httpbis-p7-auth-12 (the httpbis update f= or RFC2617). That draft is more lenient to reflect BASIC and NTLM etc that = have a single base64 blob, instead of comma-separated name=3Dvalue pairs. The bearer draft wants an initial blob AND comma-separate name=3Dvalue pair= s. Please pick one - unless you can first convince the httpbis group to mak= e the Authorization header even more lenient (which I suspect they will rej= ect as it isn't necessary and there isn't a deployed based actively using t= he more lenient syntax). The bearer draft allows the initial blob (access-token) to look like: name=3Dvalue but not be a parameter; comma-separated params, but not be; a quoted-string, but not use the defined escaping mechanism for quoted-stri= ng; an internationalized RFC2047 word in another charset, but it is not suppose= d to be processed as such. Please restrict access-token to the 66 web-safe chars. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127A6EA89BWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In draft-ietf-oauth-v2-bearer-01 section 2.1 “= The Authorization Request Header Field” an access-token can use 93 AS= CII characters, including: comma, double-quote, equals, backslash etc. Thes= e have no special meaning. No escaping is defined.

This is fairly diabolical.

 

It is incompatible with the RFC2617 spec for the Aut= horization header, where after the scheme name come comma-separated name=3D= value pairs. A name is a <token> (77 allowed ASCII chars). A value is= a <token> or a <quoted-string> (226 allowed ISO-8859-1 chars, 2 needing escaping).

 

It is incompatible with draft-ietf-httpbis-p7-auth-1= 2 (the httpbis update for RFC2617). That draft is more lenient to reflect B= ASIC and NTLM etc that have a single base64 blob, instead of comma-separate= d name=3Dvalue pairs.

 

The bearer draft wants an initial blob AND comma-sep= arate name=3Dvalue pairs. Please pick one – unless you can first conv= ince the httpbis group to make the Authorization header even more lenient (= which I suspect they will reject as it isn’t necessary and there isn’t a deployed based actively using the more l= enient syntax).

 

The bearer draft allows the initial blob (access-tok= en) to look like:

name=3Dvalue but not be a parameter;

comma-separated params, but not be;

a quoted-string, but not use the defined escaping me= chanism for quoted-string;

an internationalized RFC2047 word in another charset= , but it is not supposed to be processed as such.

 

Please restrict access-token to the 66 web-safe char= s.

 

--

James Manger

 

--_000_255B9BB34FB7D647A506DC292726F6E1127A6EA89BWSMSG3153Vsrv_-- From mzero@google.com Fri Dec 3 09:32: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 CD93328C17E for ; Fri, 3 Dec 2010 09:32:54 -0800 (PST) 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 BRGB8JtcUEQJ for ; Fri, 3 Dec 2010 09:32:53 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E004C28C179 for ; Fri, 3 Dec 2010 09:32:52 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id oB3HYAAG024346 for ; Fri, 3 Dec 2010 09:34:10 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291397650; bh=pT5ZheB7ZGy1IwX4z3XtM3vGskg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=jDWiDXuDYRMMTF3/nkzvD/o6zPGuY93ukKfsSPOFEv6+gpPPZ0Ho+oTTkYPmXdnM0 Bf7eQ05meh39lzVX9HWDw== Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by wpaz29.hot.corp.google.com with ESMTP id oB3HY9J7000780 for ; Fri, 3 Dec 2010 09:34:09 -0800 Received: by gxk8 with SMTP id 8so32239779gxk.27 for ; Fri, 03 Dec 2010 09:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=8GmmzVlNMYvNNGeni5S4XMoq8jqG5uKKm2JJdRfjYX0=; b=wwEbSOHvWiYaUf3RqX/T+v6uioTcZ5ziKMyRm9jv7Ffkj4HTOgvFNjUQ6V+4TyBiUx p70uRrIzh4Fhdq10hu0g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=iGcVh7OLEkIe/Lpde/FntChXVtxHECEkw7u0Q3RoOx2AF5wEJnty8fDgefnndCp/Iw +owNWU3WsOCLDAc4X5IA== Received: by 10.100.127.18 with SMTP id z18mr1684974anc.37.1291397649003; Fri, 03 Dec 2010 09:34:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.95.19 with HTTP; Fri, 3 Dec 2010 09:33:48 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127A6EA89B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127A6EA89B@WSMSG3153V.srv.dir.telstra.com> From: Mark Lentczner Date: Fri, 3 Dec 2010 09:33:48 -0800 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001485f91bd221f67f049684f2b5 X-System-Of-Record: true Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer: token characters X-BeenThere: oauth@ietf.org X-Mailman-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, 03 Dec 2010 17:32:55 -0000 --001485f91bd221f67f049684f2b5 Content-Type: text/plain; charset=UTF-8 Please see my e-mail to this list from Oct 27th with the subject "OAuth v2 Authorization Header Credentials". It outlines several major problems in the parsing of the Authorization header that were in OAuth v2 draft 10, and are still present in this new bearer draft. That e-mail also proposes a solution, and a corrected ABNF grammar. I can resend if people would like. - Mark Lentczner mzero@google.com --001485f91bd221f67f049684f2b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please see my e-mail to this list from Oct 27th with the subject "OAut= h v2 Authorization Header Credentials". It outlines several major prob= lems in the parsing of the Authorization header that were in OAuth v2 draft= 10, and are still present in this new bearer draft.

That e-mail also proposes a solution, and a corrected ABNF g= rammar.

I can resend if people would like.

=
=C2=A0=C2=A0- Mark Lentczner
=C2=A0=C2=A0 =C2=A0mzero@google.com

--001485f91bd221f67f049684f2b5-- From igor.faynberg@alcatel-lucent.com Fri Dec 3 13:08: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 5AAD428C16B for ; Fri, 3 Dec 2010 13:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 XXzP2VFbY7ar for ; Fri, 3 Dec 2010 13:08:48 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 62D1528C136 for ; Fri, 3 Dec 2010 13:08:48 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id oB3LA4Up009998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Dec 2010 15:10:04 -0600 (CST) Received: from [135.244.37.132] (faynberg.lra.lucent.com [135.244.37.132]) by umail.lucent.com (8.13.8/TPES) with ESMTP id oB3LA3ww027875; Fri, 3 Dec 2010 15:10:03 -0600 (CST) Message-ID: <4CF95CAA.2080708@alcatel-lucent.com> Date: Fri, 03 Dec 2010 16:10:02 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343D4B065CD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1291326284.32049.261.camel@pulse> In-Reply-To: <1291326284.32049.261.camel@pulse> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bikeshedding poll: 'attributes' parameter vs. attributes parameters 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: Fri, 03 Dec 2010 21:08:49 -0000 Abstain. (The reason: I cannot predict how the tokens will evolve.) Igor > > On Thu, 2010-12-02 at 16:04 -0500, Eran Hammer-Lahav wrote: > >> I'm defining a new token type: MAC based on my previous HTTP Token authentication draft (which in turn was based on 1.0a HMAC-SHA1). This is being drafted and implemented in my current project (in node.js). I will have a draft to share shortly (I do not plan to make this a WG item, but will not object if the group wants to). >> >> When issuing a token, the authorization server needs to provide two additional attributes: >> >> - mac algorithm (hmac-sha1 and hmac-sha256 will be defined) >> - secret >> >> I have two options; extend the token response by registering: >> >> 1. Type specific parameters: 'mac_algorithm' and 'token_secret' >> 2. Generic parameter: 'attributes' with some form of key-value pairs >> >> I prefer #1 because it is much simpler. However, #2 is cleaner and better if we end up with a lot of token types. >> >> So I'm going with #1 but open to other suggestions and feedback. >> >> 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 > From mscurtescu@google.com Fri Dec 3 16:27: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 E64A53A69FA for ; Fri, 3 Dec 2010 16:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=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 Pz-TjnAW1J1B for ; Fri, 3 Dec 2010 16:26:57 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4DAFB28C0EA for ; Fri, 3 Dec 2010 16:26:44 -0800 (PST) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id oB40RhtU018945 for ; Fri, 3 Dec 2010 16:27:44 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291422466; bh=uFhj0pKSZXxfjhxVAohV/yDfckQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=LPJW2EkkRLFN0aSeJrF33cedBIbvfKqgJgGRY5b0c8nOsXuDbTKhoZLiYRogfb7O8 34X/wyE+Vrsmamagxsjwg== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by hpaq5.eem.corp.google.com with ESMTP id oB40REUr021410 for ; Fri, 3 Dec 2010 16:27:42 -0800 Received: by yxt33 with SMTP id 33so1618118yxt.17 for ; Fri, 03 Dec 2010 16:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=w0X0s05sZDzffCzcswMb+37Wla5qpddNVbHk78lPV40=; b=YrVh11kW6J/bXkOoHJf8X35JxUJEiRy8JFJk01OuohtggdfNQt9RPQ7f1AvKHbySlc KaGjgtLR36u8JwbPyZjA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=SpmBgwGYftqNQYFr8o6OIWb2f12HCc3ScebH+qLiUd9UO6RABvNycei/xCfdsW48BL D9yyxV7FR8rzFQ+dEjeA== Received: by 10.100.119.5 with SMTP id r5mr1977860anc.88.1291422461230; Fri, 03 Dec 2010 16:27:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Fri, 3 Dec 2010 16:27:21 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Fri, 3 Dec 2010 16:27:21 -0800 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@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Dec 2010 00:27:54 -0000 How about: - keeping the scheme "OAuth2", for both WWW-Authenticate and Authorization - define both as name/value pairs (WWW-Authenticate is already) - require that one of the pairs be "type=3D" For example: WWW-Authenticate: OAuth2 type=3Dbearer Authorization: OAuth2 token=3DvF9dft4qmT, type=3Dbearer Marius On Thu, Dec 2, 2010 at 7:59 PM, Manger, James H wrote: > Eran, > >> What does scheme=3Dbasic mean [in a token response]? > > It means this token response contains credentials that can be used with t= he HTTP BASIC authentication scheme. Don't try to use the credentials with = any other scheme. The access_token value would be used as the user-id, and = the token_secret value as the password. > > >> I think tying type and scheme together is less intuitive then >> letting the type definition provide the right scheme(s). > > Keeping them separate offers an additional degree of indirection. > Indirection is sometimes useful, but I don't think it adds any value here= . > It just means we need another registry (of token_types, with associated p= rocedures); and we need an extra spec for each authentication mechanism to = define the linkage to OAuth2. > > A lot of authentication mechanisms take similar inputs (an id and a secre= t) so they shouldn't each need a separate spec to define their binding to O= Auth2. > > >> I am using 'MAC' for my draft. > > As the token_type? As the HTTP authentication scheme? I hope both. > >> But its still an OAuth2 extension, not a completely generic HTTP scheme. > > I guess it is an OAuth2 extension in as much as it defines how to get MAC= credentials from an OAuth2 token response: check token_type=3DMAC; access_= token is the id; token_secret is the MAC key; mac_algorithm is the MAC algo= rithm. > >> It can be used independent of OAuth2 if you somehow got >> a token, secret, and mac algorithm name. > > Hopefully you define a "WWW-Authenticate: MAC ..." response header that c= an list acceptable MAC algorithms. > I think an OAuth2 token response for a MAC scheme should contain the same= information as the WWW-Authenticate response header for the MAC scheme, pl= us the credentials to use (id & secret) and the OAuth2-specific lifetime ma= nagement bits (eg how/when to refresh). We should explicitly define (in cor= e) how to put a WWW-Authenticate header into a token response. > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Fri Dec 3 16: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 638643A69D2 for ; Fri, 3 Dec 2010 16:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.902 X-Spam-Level: X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 3AW0kE3ms5lk for ; Fri, 3 Dec 2010 16:45:37 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 495E43A67F8 for ; Fri, 3 Dec 2010 16:45:37 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id oB40krqF024203 for ; Fri, 3 Dec 2010 16:46:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291423614; bh=3KIDoK74Tbrzdgfv8J1jd9lk7/g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=TkAcR1KwUqwazvWeZYCL9PcnNgLkqP3va5fG0wwqtJ1twHZf9LRMSNqbo42Pksw+g shC4ZOAj+ViHCiFCYan2A== Received: from gxk20 (gxk20.prod.google.com [10.202.11.20]) by kpbe19.cbf.corp.google.com with ESMTP id oB40kVj8007039 for ; Fri, 3 Dec 2010 16:46:52 -0800 Received: by gxk20 with SMTP id 20so5628901gxk.20 for ; Fri, 03 Dec 2010 16:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ZrNtMAefT0AIijp8x1dWKmA9VfVDbGgB2yAOxOXoj8I=; b=LO+KAAmhu3dRlvjP94mk84fV4xkiySnov8nHsleMpyYo0TGDgEQZ7Wg/2rtRSwQofz 88BT4wR0Xklzd8q/HfbQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=OQYDXuy227AxEfh9wtPWXvQNYYaJfwIAGI3cn3R3zLxBSZwh3xKZVliafqOzMx9xAo yHcBW0n5kxevzSaEhwig== Received: by 10.101.165.35 with SMTP id s35mr1932265ano.190.1291423612440; Fri, 03 Dec 2010 16:46:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Fri, 3 Dec 2010 16:46:32 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B06593E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343D4B06593E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Fri, 3 Dec 2010 16:46:32 -0800 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 Subject: Re: [OAUTH-WG] -11 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Dec 2010 00:45:38 -0000 1. Minor formatting issue: section 1.2, "authorization code" and "access grant" need a new line before the definition. 2. The new token_type parameter is required in responses from the server. If the server supports multiple formats, which one will be used? In this case, would it make sense to allow the client to request a specific format? 3. The new Client Assertion Credentials do make sense, but the name is creating confusion. Hard to distinguish from assertion profile. 4. Do we really need both basic auth and request parameters for Client Password Credentials (section 3.1). Can we move basic auth to an extension? 5. Section 4.1, second to last paragraph. The server is required to redirect to the client in case of bad request. Do we really want that? At that point the redirect_uri is just a guess. 6. Section 5, description of grant_type. It is stated that value is a URI for the assertion flow. But it is a URI for extensions as well. Maybe we should stick with "assertion" grant type and assertion_type, it gets ambiguous like this. 7. Section 7.2. What about applications using legacy parameters? Does not make much sense to register them, and they cannot be changed to x_. Broken record: using a prefix for all registered parameters is much cleaner. Marius On Tue, Nov 30, 2010 at 10:53 PM, Eran Hammer-Lahav w= rote: > I didn't get to finish the editorial changes I want to make so I pushed t= he incomplete but stable draft out as -11. This includes all the normative = language changes the group agreed on, as well as all the feedback I had for= -10. The remaining editorial work should not change any implementation det= ails. It will just impact the document organization. > > Changes in -11 include: > > =A0 -11 > > =A0 o =A0Many editorial changes. =A0Fixed user authorization section > =A0 =A0 =A0structure. =A0Removed unused normative references. =A0Adjusted > =A0 =A0 =A0language regarding single use of authorization codes. > > =A0 o =A0Fixed header ABNF. > > =A0 o =A0Change access token description from shared symmetric secret to > =A0 =A0 =A0password. > > =A0 o =A0Moved access grant 'none' to a separate section, renamed to > =A0 =A0 =A0'client_credentials'. > > =A0 o =A0Demoted the HTTP status code requirement from MUST to SHOULD in > =A0 =A0 =A0protected resource response error. > > =A0 o =A0Removed 'expired_token' error code. > > =A0 o =A0Moved all the 'code_and_token' parameter to the fragment (from > =A0 =A0 =A0code being in the query). > > =A0 o =A0Removed 'assertion_type' parameter (moved to 'grant_type'). > > =A0 o =A0Added note about redirecting to invalid redirection URIs (open > =A0 =A0 =A0redirectors). > > =A0 o =A0Removed bearer token section, added new required 'token_type' > =A0 =A0 =A0parameter with extensibility. > > =A0 o =A0'error-uri' parameter value changed to absolute URI. > > =A0 o =A0OAuth 2.0 HTTP authentication scheme name changed to 'OAuth2'. > > =A0 o =A0Dropped the 'WWW-Authenticate' header field 'realm' parameter. > > =A0 o =A0Removed definition of access token characters. > > =A0 o =A0Added instructions for dealing with error and an invalid > =A0 =A0 =A0redirection URI. > > Please provide feedback and review the document fully, even with the pend= ing editorial changes. IOW, please consider this document the final draft (= pre-WG last call) for all normative/implementation language. > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From Michael.Jones@microsoft.com Fri Dec 3 17: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 3BDC23A69C2 for ; Fri, 3 Dec 2010 17:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 eboqIjJY9eP9 for ; Fri, 3 Dec 2010 17:06:37 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id D86A53A680C for ; Fri, 3 Dec 2010 17:06:37 -0800 (PST) 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; Fri, 3 Dec 2010 17:07:56 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.228]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Fri, 3 Dec 2010 17:07:55 -0800 From: Mike Jones To: Eran Hammer-Lahav , Marius Scurtescu Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuR84PTKQ3VtH/7T02XcbsmyzxgnAArbPCAAAAikoAAKy+g8A== Date: Sat, 4 Dec 2010 01:07:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432463D3B1@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Dec 2010 01:06:39 -0000 My assumption about the new token_type parameter is that it would be used t= o communicate the data type of the token -- not the class of the token. I = was imagining token_type values like: SWT JWT urn:oasis:names:tc:SAML:1.0:assertion urn:oasis:names:tc:SAML:2.0:assertion Or Eran, did you mean for the token_type to be more like the WS-Trust 1.3 w= st:KeyType parameter, where values defined by that spec are: http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer I hope you meant the former, as this information would be generally useful = (and something I know that our developers have asked for, based upon their = deployment experiences). Thanks, -- Mike -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Thursday, December 02, 2010 12:23 PM To: Marius Scurtescu; Mike Jones Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Marius Scurtescu > Sent: Thursday, December 02, 2010 12:19 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >=20 > OAuth 2 Protocol Framework v11 introduces a new required parameter: > token_type. >=20 > Should the Bearer Token spec define the value for this parameter for=20 > bearer tokens? Yes. 'bearer' seems sensible, but I don't really care. I am going to define= 'mac' in my own extension. =20 > Are we blocked by the missing section 6.1. (Access Token Types) of the=20 > Framework spec? No. It will simply describe the general flow and how to define (register) t= oken types and authentication methods for those types. IOW, all spec-talk. = You can decide how it works and implement and deal with the extension paper= work later. EHL =20 > Marius >=20 >=20 >=20 > On Wed, Dec 1, 2010 at 11:35 PM, Mike Jones=20 > wrote: > > Draft -01 of the OAuth 2.0 Bearer Token specification is now available. > > =A0This version is intended to accompany OAuth 2.0 draft -11.=A0 This=20 > > draft is based upon the September 3rd preliminary OAuth 2.0 draft by=20 > > Eran Hammer-Lahav, with input from David Recordon and several others. > > It includes an extensive Security Considerations section, for which=20 > > Hannes Tschofenig gets significant credit. > > > > > > > > The draft is available at these locations: > > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.tx > > t > > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xm > > l > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml > > > > http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion=20 > > repository, with html, txt, and html versions available) > > > > > > > > If any of you believe that you should be added to the=20 > > Acknowledgments in Appendix A, please drop me a note and I'll be glad t= o add you. > > > > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > > > > > _______________________________________________ > > 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 Michael.Jones@microsoft.com Fri Dec 3 17:17: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 4401C28C127 for ; Fri, 3 Dec 2010 17:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 5b7SgcvKe-jS for ; Fri, 3 Dec 2010 17:17:29 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 2F38228C119 for ; Fri, 3 Dec 2010 17:17:29 -0800 (PST) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 3 Dec 2010 17:18:41 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.228]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0255.003; Fri, 3 Dec 2010 17:18:40 -0800 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Bikeshedding poll: 'attributes' parameter vs. attributes parameters Thread-Index: AcuTUSrwgYC8XpnPS+GX+a5WevrTww== Date: Sat, 4 Dec 2010 01:18:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739432463D3E5@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bikeshedding poll: 'attributes' parameter vs. attributes parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Dec 2010 01:17:30 -0000 To understand your thinking a little more, Eran, as a not-hypothetical thou= ght experiment, how would you recommend that people specify JSON Web Tokens= (JWTs) in a parallel manner to your description below of using the MAC tok= en type? Would they use a token_type=3DJWT parameter to specify the token type? How= would you see this relating to the mac_algorithm, token_secret, and attrib= utes parameters below? =20 Thanks, -- Mike P.S. I described JWTs at http://self-issued.info/?p=3D349. A new draft in= corporating the consensus decisions reached at IIW will be published shortl= y. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, December 02, 2010 1:04 PM To: OAuth WG Subject: [OAUTH-WG] Bikeshedding poll: 'attributes' parameter vs. attribute= s parameters I'm defining a new token type: MAC based on my previous HTTP Token authenti= cation draft (which in turn was based on 1.0a HMAC-SHA1). This is being dra= fted and implemented in my current project (in node.js). I will have a draf= t to share shortly (I do not plan to make this a WG item, but will not obje= ct if the group wants to). When issuing a token, the authorization server needs to provide two additio= nal attributes: - mac algorithm (hmac-sha1 and hmac-sha256 will be defined) - secret I have two options; extend the token response by registering: 1. Type specific parameters: 'mac_algorithm' and 'token_secret' 2. Generic parameter: 'attributes' with some form of key-value pairs I prefer #1 because it is much simpler. However, #2 is cleaner and better i= f we end up with a lot of token types. So I'm going with #1 but open to other suggestions and feedback. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eve@xmlgrrl.com Sat Dec 4 19:40: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 6E9123A69E7 for ; Sat, 4 Dec 2010 19:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 s+4Nye+Hdxd9 for ; Sat, 4 Dec 2010 19:40:54 -0800 (PST) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id A00623A69D4 for ; Sat, 4 Dec 2010 19:40:51 -0800 (PST) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id oB53gBgG019878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Dec 2010 19:42:11 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B06532D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 4 Dec 2010 19:42:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <62D210BF-3FA7-4789-9382-5BCCE45C5F84@xmlgrrl.com> References: <4E1F6AAD24975D4BA5B16804296739432461C3F9@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B06532D@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: "oauth@ietf.org (oauth@ietf.org)" X-Mailer: Apple Mail (2.1082) Subject: Re: [OAUTH-WG] Feedback on preliminary draft 11 from implementers of draft 10 X-BeenThere: oauth@ietf.org X-Mailman-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, 05 Dec 2010 03:40:55 -0000 A comment on Mike's comment on the idea of a "resource" parameter... On 24 Nov 2010, at 11:31 PM, Eran Hammer-Lahav wrote: > Thanks Mike! Comments inline. >=20 >> Normative Issues >>=20 >> 4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1 "Scope" parameter should = be paired with >> complimentary "resource" parameter >=20 > I am more inclined to drop 'scope' than to include 'resource'. Scope = as currently defined can easily accommodate resource - we specifically = chose space-delimited to allow URI values. If you want a new parameter, = *you* will have to build consensus. Not wearing my editor hat, I'm -1. Over in UMA-land we've had to solve for this because our use cases = anticipate protecting arbitrary resources, not just singular APIs, and = because our loosely coupled resource server and authorization server = components need to communicate about this stuff in an organized fashion. After many months of discussion, as well as UX and implementation work = by various participants, in the last week we finally got consensus = around having two parts (resource sets and actions, the latter being a = close analogue to today's OAuth scopes) rather than a single flat scope = namespace. The degenerate case could be very much like today's common = practice, but we believe it handles a lot more use cases. There's still work to do to propagate information in this two-part form = throughout the protocol flow (which is what Mike was directly = suggesting), but at least we now have a conceptual foundation for doing = that. If there is consensus here for adding a parameter, it would make = UMA's life easier as we wouldn't have to invent anything weird and = nonstandard. :-) See the "Resource Registration" spec link from our Working Drafts page = for more info; if there's sufficient interest, we could contribute it as = an IETF I-D soonish: http://kantarainitiative.org/confluence/display/uma/Working+Drafts Eve Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl= From James.H.Manger@team.telstra.com Sun Dec 5 15:26: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 673D628C0ED for ; Sun, 5 Dec 2010 15:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=0.008, 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 S2Q80J-nx3AU for ; Sun, 5 Dec 2010 15:26:25 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 3E81A28C0D0 for ; Sun, 5 Dec 2010 15:26:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,303,1288530000"; d="scan'208";a="19066672" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 06 Dec 2010 10:27:46 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6188"; a="15130161" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcani.tcif.telstra.com.au with ESMTP; 06 Dec 2010 10:27:46 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Mon, 6 Dec 2010 10:27:45 +1100 From: "Manger, James H" To: Marius Scurtescu Date: Mon, 6 Dec 2010 10:27:44 +1100 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuTShTPaHPC6VVhTduciJr2rcridgBg4Ahg Message-ID: <255B9BB34FB7D647A506DC292726F6E1127A7B8279@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 05 Dec 2010 23:26:26 -0000 Marius, > How about: > - keeping the scheme "OAuth2", for both WWW-Authenticate and Authorizatio= n > - define both as name/value pairs (WWW-Authenticate is already) > - require that one of the pairs be "type=3D" > > For example: > WWW-Authenticate: OAuth2 type=3Dbearer > Authorization: OAuth2 token=3DvF9dft4qmT, type=3Dbearer What is the benefit of trying to couple one form of bearer token so strongl= y to the OAuth2 delegation flows? You have now complicated the Authorization header (extra type=3Dbearer para= m), and the WWW-Authentication header (now indicates that delegation is ava= ilable, swapping-permanent-cred-for-temp-token is available, and bearer aut= hentication is required -- I hope a client can work out which is relevant i= n any response). Should Eran's MAC mechanim also use the same scheme, just with type=3Dmac a= nd adding its own parameters? I hope not. We end up with multiple specs (core, bearer, MAC, any other auth mechanism.= ..) all adding bits to the same HTTP scheme -- and not just registering the= ir own "type" value, but also all their own parameters (eg alg, nonce?, tok= en...). This causes unnecessary complications, because it is unnecessary ti= ght coupling. > WWW-Authenticate: OAuth2 type=3Dbearer What does this mean to a client app? Does it mean that if the client app already has a bearer token it should re= peat the request with that token. Does it mean the client app should do an OAuth2 flow (which?) and expect a = bearer token? Does this type value override any type information in a subse= quent token response? That could be dangerous. Should a server include mult= iple "WWW-Authenticate: OAuth2" headers if it can issue tokens for differen= t authentication mechanisms depending on resources/scopes/client-app-prefer= ences? "Authorization: BEARER ..." avoids a lot of confusion. -- James Manger From eran@hueniverse.com Sun Dec 5 22:32: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 3DD8D3A6891 for ; Sun, 5 Dec 2010 22:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_37=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 DS5xBhFFHEZc for ; Sun, 5 Dec 2010 22:32:20 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EB1DB3A63CB for ; Sun, 5 Dec 2010 22:32:19 -0800 (PST) Received: (qmail 23871 invoked from network); 6 Dec 2010 06:33:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Dec 2010 06:33:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 5 Dec 2010 23:33:41 -0700 From: Eran Hammer-Lahav To: Mike Jones , Marius Scurtescu Date: Sun, 5 Dec 2010 23:33:27 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuR84PTKQ3VtH/7T02XcbsmyzxgnAArbPCAAAAikoAAKy+g8ABwKxuQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739432463D3B1@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432463D3B1@TK5EX14MBXC201.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 06:32:22 -0000 Token type is as simple as informing the client how to use the token issued= . If you tell it 'bearer' is means 'present it as is without having to do a= nything else'. If you tell it 'mac' is means 'construct a very specific sig= nature base string and hmac it with the provided secret'. For JWT it means = figure out what the token internals mean and use it as needed. It is pretty straight forward. You give the client a token and tell it exac= tly what to do with it. EHL -----Original Message----- From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Friday, December 03, 2010 5:08 PM To: Eran Hammer-Lahav; Marius Scurtescu Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 My assumption about the new token_type parameter is that it would be used t= o communicate the data type of the token -- not the class of the token. I = was imagining token_type values like: SWT JWT urn:oasis:names:tc:SAML:1.0:assertion urn:oasis:names:tc:SAML:2.0:assertion Or Eran, did you mean for the token_type to be more like the WS-Trust 1.3 w= st:KeyType parameter, where values defined by that spec are: http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer I hope you meant the former, as this information would be generally useful = (and something I know that our developers have asked for, based upon their = deployment experiences). Thanks, -- Mike -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Thursday, December 02, 2010 12:23 PM To: Marius Scurtescu; Mike Jones Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Marius Scurtescu > Sent: Thursday, December 02, 2010 12:19 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >=20 > OAuth 2 Protocol Framework v11 introduces a new required parameter: > token_type. >=20 > Should the Bearer Token spec define the value for this parameter for=20 > bearer tokens? Yes. 'bearer' seems sensible, but I don't really care. I am going to define= 'mac' in my own extension. =20 > Are we blocked by the missing section 6.1. (Access Token Types) of the=20 > Framework spec? No. It will simply describe the general flow and how to define (register) t= oken types and authentication methods for those types. IOW, all spec-talk. = You can decide how it works and implement and deal with the extension paper= work later. EHL =20 > Marius >=20 >=20 >=20 > On Wed, Dec 1, 2010 at 11:35 PM, Mike Jones=20 > wrote: > > Draft -01 of the OAuth 2.0 Bearer Token specification is now available. > > =A0This version is intended to accompany OAuth 2.0 draft -11.=A0 This=20 > > draft is based upon the September 3rd preliminary OAuth 2.0 draft by=20 > > Eran Hammer-Lahav, with input from David Recordon and several others. > > It includes an extensive Security Considerations section, for which=20 > > Hannes Tschofenig gets significant credit. > > > > > > > > The draft is available at these locations: > > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.tx > > t > > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xm > > l > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt > > > > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml > > > > http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion=20 > > repository, with html, txt, and html versions available) > > > > > > > > If any of you believe that you should be added to the=20 > > Acknowledgments in Appendix A, please drop me a note and I'll be glad t= o add you. > > > > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > > > > > _______________________________________________ > > 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 Dec 5 22: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 8D97E3A6892 for ; Sun, 5 Dec 2010 22:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_65=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 oqKtM4IaNzTr for ; Sun, 5 Dec 2010 22:33:42 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 752793A63CB for ; Sun, 5 Dec 2010 22:33:42 -0800 (PST) Received: (qmail 28303 invoked from network); 6 Dec 2010 06:35:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Dec 2010 06:35:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 5 Dec 2010 23:35:04 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , "Manger, James H" Date: Sun, 5 Dec 2010 23:34:49 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuTSlOJ17/1NFFmQIKyKCjatUD04gBxTx0g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@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@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 06:33:44 -0000 This is not how most HTTP authentication frameworks work (that was the conc= lusion from my HTTP Token scheme proposal a year ago). Most frameworks rath= er switch on the scheme name, not on a parameter inside the header. EHL -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= arius Scurtescu Sent: Friday, December 03, 2010 4:27 PM To: Manger, James H Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 How about: - keeping the scheme "OAuth2", for both WWW-Authenticate and Authorization - define both as name/value pairs (WWW-Authenticate is already) - require that one of the pairs be "type=3D" For example: WWW-Authenticate: OAuth2 type=3Dbearer Authorization: OAuth2 token=3DvF9dft4qmT, type=3Dbearer Marius On Thu, Dec 2, 2010 at 7:59 PM, Manger, James H wrote: > Eran, > >> What does scheme=3Dbasic mean [in a token response]? > > It means this token response contains credentials that can be used with t= he HTTP BASIC authentication scheme. Don't try to use the credentials with = any other scheme. The access_token value would be used as the user-id, and = the token_secret value as the password. > > >> I think tying type and scheme together is less intuitive then letting=20 >> the type definition provide the right scheme(s). > > Keeping them separate offers an additional degree of indirection. > Indirection is sometimes useful, but I don't think it adds any value here= . > It just means we need another registry (of token_types, with associated p= rocedures); and we need an extra spec for each authentication mechanism to = define the linkage to OAuth2. > > A lot of authentication mechanisms take similar inputs (an id and a secre= t) so they shouldn't each need a separate spec to define their binding to O= Auth2. > > >> I am using 'MAC' for my draft. > > As the token_type? As the HTTP authentication scheme? I hope both. > >> But its still an OAuth2 extension, not a completely generic HTTP scheme. > > I guess it is an OAuth2 extension in as much as it defines how to get MAC= credentials from an OAuth2 token response: check token_type=3DMAC; access_= token is the id; token_secret is the MAC key; mac_algorithm is the MAC algo= rithm. > >> It can be used independent of OAuth2 if you somehow got a token,=20 >> secret, and mac algorithm name. > > Hopefully you define a "WWW-Authenticate: MAC ..." response header that c= an list acceptable MAC algorithms. > I think an OAuth2 token response for a MAC scheme should contain the same= information as the WWW-Authenticate response header for the MAC scheme, pl= us the credentials to use (id & secret) and the OAuth2-specific lifetime ma= nagement bits (eg how/when to refresh). We should explicitly define (in cor= e) how to put a WWW-Authenticate header into a token response. > > -- > 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 eran@hueniverse.com Sun Dec 5 22:38: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 C15C93A69F1 for ; Sun, 5 Dec 2010 22:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 QbkurbmxIXct for ; Sun, 5 Dec 2010 22:38:30 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 273393A63CB for ; Sun, 5 Dec 2010 22:38:30 -0800 (PST) Received: (qmail 30892 invoked from network); 6 Dec 2010 06:39:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Dec 2010 06:39:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 5 Dec 2010 23:39:47 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , OAuth WG Date: Sun, 5 Dec 2010 23:39:33 -0700 Thread-Topic: [OAUTH-WG] Client Password Credentials Thread-Index: AcuSilmeU1zDuEjFSier2bYL/tMXngChZvMA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602F@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] Client Password Credentials X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 06:38:32 -0000 The argument was, since these are basic credentials, they should be used in= the native HTTP method using the header. But since that is not as simple a= s a pair of parameters, we ended up with both. The easy way and the right w= ay. >From implementing it, my experience has been that it can be hard to deal wi= th Basic in the context of another authentication class. Since OAuth and Ba= sic are usually two classes provided by the same authentication layer, havi= ng one use the other can lead to tricky architecture. This trivial to imple= ment in a clean environment, but a bit messy when adding to an existing fra= mework. I am split between doing what is right and what is practical here. EHL -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= arius Scurtescu Sent: Thursday, December 02, 2010 5:35 PM To: OAuth WG Subject: [OAUTH-WG] Client Password Credentials Currently there are two different ways a client can send credentials, as sp= ecified in section 3.1, and: "The authorization server MUST accept the client credentials using both the= request parameter, and the HTTP Basic authentication scheme." I know there was a long thread on this subject, but I cannot recall the rea= soning. Can someone summarize it? How many of the existing OAuth 2 server implementations out there currently= support both methods? Thanks, Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Dec 5 22:41: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 1662E3A69F6 for ; Sun, 5 Dec 2010 22:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 jcSV+xwshQsS for ; Sun, 5 Dec 2010 22:40:59 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D285E3A6A0A for ; Sun, 5 Dec 2010 22:40:59 -0800 (PST) Received: (qmail 1354 invoked from network); 6 Dec 2010 06:42:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Dec 2010 06:42:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 5 Dec 2010 23:42:22 -0700 From: Eran Hammer-Lahav To: Mike Jones , OAuth WG Date: Sun, 5 Dec 2010 23:42:08 -0700 Thread-Topic: Bikeshedding poll: 'attributes' parameter vs. attributes parameters Thread-Index: AcuTUSrwgYC8XpnPS+GX+a5WevrTwwBv165w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B066030@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463D3E5@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739432463D3E5@TK5EX14MBXC201.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] Bikeshedding poll: 'attributes' parameter vs. attributes parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 06:41:13 -0000 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, December 03, 2010 5:19 PM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: Bikeshedding poll: 'attributes' parameter vs. attributes > parameters >=20 > To understand your thinking a little more, Eran, as a not-hypothetical th= ought > experiment, how would you recommend that people specify JSON Web > Tokens (JWTs) in a parallel manner to your description below of using the > MAC token type? > > Would they use a token_type=3DJWT parameter to specify the token type? Yep. Case insensitive... > How would you see this relating to the mac_algorithm, token_secret, and > attributes parameters below? Those parameter are specific to the MAC token type. If you want to use them= , you will need to redefine them for that token type. Ideally, they will ha= ve the same meaning or you should pick a different name. EHL >=20 > Thanks, > -- Mike >=20 > P.S. I described JWTs at http://self-issued.info/?p=3D349. A new draft > incorporating the consensus decisions reached at IIW will be published > shortly. >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Thursday, December 02, 2010 1:04 PM > To: OAuth WG > Subject: [OAUTH-WG] Bikeshedding poll: 'attributes' parameter vs. attribu= tes > parameters >=20 > I'm defining a new token type: MAC based on my previous HTTP Token > authentication draft (which in turn was based on 1.0a HMAC-SHA1). This is > being drafted and implemented in my current project (in node.js). I will = have > a draft to share shortly (I do not plan to make this a WG item, but will = not > object if the group wants to). >=20 > When issuing a token, the authorization server needs to provide two > additional attributes: >=20 > - mac algorithm (hmac-sha1 and hmac-sha256 will be defined) > - secret >=20 > I have two options; extend the token response by registering: >=20 > 1. Type specific parameters: 'mac_algorithm' and 'token_secret' > 2. Generic parameter: 'attributes' with some form of key-value pairs >=20 > I prefer #1 because it is much simpler. However, #2 is cleaner and better= if > we end up with a lot of token types. >=20 > So I'm going with #1 but open to other suggestions and feedback. >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Dec 5 23:10: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 C270D3A69EB for ; Sun, 5 Dec 2010 23:10:48 -0800 (PST) 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.211, BAYES_00=-2.599, J_CHICKENPOX_65=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 sHZJ4uhYzUbz for ; Sun, 5 Dec 2010 23:10:44 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 38C3D3A63CB for ; Sun, 5 Dec 2010 23:10:42 -0800 (PST) Received: (qmail 21203 invoked from network); 6 Dec 2010 07:12:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Dec 2010 07:12:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 6 Dec 2010 00:12:03 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Mon, 6 Dec 2010 00:11:50 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuSX8hmJOkfgwswSLCmwCDoUYn81AAEtzvgAAflxEAAAYywQACe4CrQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B066036@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127A6EA714@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] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 07:10:48 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, December 02, 2010 7:59 PM > > What does scheme=3Dbasic mean [in a token response]? >=20 > It means this token response contains credentials that can be used with t= he > HTTP BASIC authentication scheme. Don't try to use the credentials with a= ny > other scheme. The access_token value would be used as the user-id, and th= e > token_secret value as the password. But that has the same security properties as bearer. > > I think tying type and scheme together is less intuitive then letting > > the type definition provide the right scheme(s). >=20 > Keeping them separate offers an additional degree of indirection. > Indirection is sometimes useful, but I don't think it adds any value here= . > It just means we need another registry (of token_types, with associated > procedures); and we need an extra spec for each authentication mechanism > to define the linkage to OAuth2. Yeah. But I'm not expecting a flood. We'll have a handful and probably 2 wi= ll survive the deployment test. OAuth 1.0a had three signature methods and = only one really got any significant traction. =20 > A lot of authentication mechanisms take similar inputs (an id and a secre= t) so > they shouldn't each need a separate spec to define their binding to OAuth= 2. I don't see a way around it. OAuth returns tokens using form-encoded URI an= d JSON body replies. If your token is not self describing, you need extra p= arameters so binding is required anyway. =20 > > I am using 'MAC' for my draft. >=20 > As the token_type? As the HTTP authentication scheme? I hope both. In my case both, but I don't care about it as a generic HTTP authentication= scheme. It can be used that way but it is defined in clear OAuth context. =20 > > But its still an OAuth2 extension, not a completely generic HTTP scheme= . >=20 > I guess it is an OAuth2 extension in as much as it defines how to get MAC > credentials from an OAuth2 token response: check token_type=3DMAC; > access_token is the id; token_secret is the MAC key; mac_algorithm is the > MAC algorithm. >=20 > > It can be used independent of OAuth2 if you somehow got a token, > > secret, and mac algorithm name. >=20 > Hopefully you define a "WWW-Authenticate: MAC ..." response header that > can list acceptable MAC algorithms. Nope. You are told what to use when you are issued the token. That's as far= as my requirements go (and this spec is based directly on my current proje= ct). EHL > I think an OAuth2 token response for a MAC scheme should contain the > same information as the WWW-Authenticate response header for the MAC > scheme, plus the credentials to use (id & secret) and the OAuth2-specific > lifetime management bits (eg how/when to refresh). We should explicitly > define (in core) how to put a WWW-Authenticate header into a token > response. >=20 > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon Dec 6 06:20: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 218303A67FC for ; Mon, 6 Dec 2010 06:20:23 -0800 (PST) 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 R0IulY-uJ-vV for ; Mon, 6 Dec 2010 06:20:22 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 1E7AC3A6803 for ; Mon, 6 Dec 2010 06:20:22 -0800 (PST) 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 oB6ELiqc016269 for ; Mon, 6 Dec 2010 09:21:45 -0500 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 oB6ELiJP016266; Mon, 6 Dec 2010 09:21:44 -0500 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Mon, 6 Dec 2010 09:21:44 -0500 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Mon, 6 Dec 2010 09:21:43 -0500 Message-ID: <1291645303.6035.6.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Client Password Credentials X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 14:20:23 -0000 Is there a real downside to making them both optional with availability specified by the AS? I have a feeling that's what we're going to end up with in the wild anyway. That is to say, frameworks that can't dig deep enough into HTTP to get to the Basic credentials just won't support that method, even if the spec technically requires it. -- justin On Mon, 2010-12-06 at 01:39 -0500, Eran Hammer-Lahav wrote: > The argument was, since these are basic credentials, they should be used in the native HTTP method using the header. But since that is not as simple as a pair of parameters, we ended up with both. The easy way and the right way. > > From implementing it, my experience has been that it can be hard to deal with Basic in the context of another authentication class. Since OAuth and Basic are usually two classes provided by the same authentication layer, having one use the other can lead to tricky architecture. This trivial to implement in a clean environment, but a bit messy when adding to an existing framework. > > I am split between doing what is right and what is practical here. > > EHL > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu > Sent: Thursday, December 02, 2010 5:35 PM > To: OAuth WG > Subject: [OAUTH-WG] Client Password Credentials > > Currently there are two different ways a client can send credentials, as specified in section 3.1, and: > "The authorization server MUST accept the client credentials using both the request parameter, and the HTTP Basic authentication scheme." > > I know there was a long thread on this subject, but I cannot recall the reasoning. Can someone summarize it? > > How many of the existing OAuth 2 server implementations out there currently support both methods? > > Thanks, > 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 From jricher@mitre.org Mon Dec 6 06:39: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 8D7AC3A6807 for ; Mon, 6 Dec 2010 06:39:46 -0800 (PST) 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=[AWL=0.000, 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 KIg8vALnqcZB for ; Mon, 6 Dec 2010 06:39:06 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D35A43A67B4 for ; Mon, 6 Dec 2010 06:39:05 -0800 (PST) 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 oB6EeTeO004338 for ; Mon, 6 Dec 2010 09:40:29 -0500 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 oB6EeTQp004335 for ; Mon, 6 Dec 2010 09:40:29 -0500 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Mon, 6 Dec 2010 09:40:29 -0500 From: Justin Richer To: "oauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Date: Mon, 6 Dec 2010 09:40:28 -0500 Message-ID: <1291646428.6035.23.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Signed Fetch X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 14:39:47 -0000 With the core drafts finally settling in, I think it's time for the WG to look into a widely-used usecase of OAuth 1.0 that's not currently addressed directly by OAuth2: classical 2-legged OAuth 1.0, or tokenless signed http fetch. People use this method today to replace developer key credentials, but also to ensure validity of parameters in the request. Tokens (especially signed tokens) can help in the first case, but not so much in the second, unless I'm missing a key feature of JWT. I'm personally fine with profiling the 1.0 signature method for use with generic HTTP messages, apart from OAuth and tokens entirely. I'd be happier with a system that had an explicit signature base string (such as what Brian Eaton proposed ages ago) instead of the blind magic that OAuth 1.0 uses. I personally wouldn't know where to start with normative language for something like this, as I am not a signatures/crypto guy. But I'd be happy to help edit such a document and work on profiles and use cases for this. My question for the WG is then: are signed HTTP fetch messages something we want to take on, and who would be willing/able to edit such a document? -- Justin From mscurtescu@google.com Mon Dec 6 11:55: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 803283A68A3 for ; Mon, 6 Dec 2010 11:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.677 X-Spam-Level: X-Spam-Status: No, score=-109.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8, 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 6QWjJgBdeNCC for ; Mon, 6 Dec 2010 11:55:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3D44E3A6889 for ; Mon, 6 Dec 2010 11:55:30 -0800 (PST) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id oB6JurDM016738 for ; Mon, 6 Dec 2010 11:56:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291665413; bh=aaitlUsY6xngS7e3GBm+DBrmmCE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=viaXjHUq739+jyWSGxp8+qWMX7MBCPvRDMpAwYECmuePF7W8W6rbLMIXihPYF4pV7 hWx6KCJwYVtqjWlMEmNFw== Received: from gxk3 (gxk3.prod.google.com [10.202.11.3]) by hpaq2.eem.corp.google.com with ESMTP id oB6JupH1019506 for ; Mon, 6 Dec 2010 11:56:52 -0800 Received: by gxk3 with SMTP id 3so956393gxk.5 for ; Mon, 06 Dec 2010 11:56:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=jw5eocyjrR18CX0buz9jpg2lesNhAXKiUSFL54gQ3pM=; b=wb8CR2TU1ZcrpCTjon/rWE202emYJ2BN7sjJyQnnjRL07aV0aSt29gkzjN3NEfy0Xa m/zSnssbeNR3zd4iZ3zg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=cSmEriXKD2z0J9GOTlruHeIscIf2KEGk9YQCmvPVstWD5NGgybMIJgq5LRrG7KtORS M7OVcqMeeozekl1d39Ig== Received: by 10.100.17.13 with SMTP id 13mr1123042anq.190.1291665411523; Mon, 06 Dec 2010 11:56:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Mon, 6 Dec 2010 11:56:31 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B06602E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 6 Dec 2010 11:56:31 -0800 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] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 19:55:31 -0000 On Sun, Dec 5, 2010 at 10:34 PM, Eran Hammer-Lahav wr= ote: > This is not how most HTTP authentication frameworks work (that was the co= nclusion from my HTTP Token scheme proposal a year ago). Most frameworks ra= ther switch on the scheme name, not on a parameter inside the header. The alternative, as suggested by James, requires a new scheme for each token type. My guess is that we will have quite a few types pretty soon: - bearer opaque - bearer transparent (JSON, signed by authz server) - JWT signed - MAC - etc. Who controls the auth header scheme names? Aren't we asking for a collision here? Marius > > EHL > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Marius Scurtescu > Sent: Friday, December 03, 2010 4:27 PM > To: Manger, James H > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 > > How about: > - keeping the scheme "OAuth2", for both WWW-Authenticate and Authorizatio= n > - define both as name/value pairs (WWW-Authenticate is already) > - require that one of the pairs be "type=3D" > > For example: > WWW-Authenticate: OAuth2 type=3Dbearer > Authorization: OAuth2 token=3DvF9dft4qmT, type=3Dbearer > > Marius > > > > On Thu, Dec 2, 2010 at 7:59 PM, Manger, James H wrote: >> Eran, >> >>> What does scheme=3Dbasic mean [in a token response]? >> >> It means this token response contains credentials that can be used with = the HTTP BASIC authentication scheme. Don't try to use the credentials with= any other scheme. The access_token value would be used as the user-id, and= the token_secret value as the password. >> >> >>> I think tying type and scheme together is less intuitive then letting >>> the type definition provide the right scheme(s). >> >> Keeping them separate offers an additional degree of indirection. >> Indirection is sometimes useful, but I don't think it adds any value her= e. >> It just means we need another registry (of token_types, with associated = procedures); and we need an extra spec for each authentication mechanism to= define the linkage to OAuth2. >> >> A lot of authentication mechanisms take similar inputs (an id and a secr= et) so they shouldn't each need a separate spec to define their binding to = OAuth2. >> >> >>> I am using 'MAC' for my draft. >> >> As the token_type? As the HTTP authentication scheme? I hope both. >> >>> But its still an OAuth2 extension, not a completely generic HTTP scheme= . >> >> I guess it is an OAuth2 extension in as much as it defines how to get MA= C credentials from an OAuth2 token response: check token_type=3DMAC; access= _token is the id; token_secret is the MAC key; mac_algorithm is the MAC alg= orithm. >> >>> It can be used independent of OAuth2 if you somehow got a token, >>> secret, and mac algorithm name. >> >> Hopefully you define a "WWW-Authenticate: MAC ..." response header that = can list acceptable MAC algorithms. >> I think an OAuth2 token response for a MAC scheme should contain the sam= e information as the WWW-Authenticate response header for the MAC scheme, p= lus the credentials to use (id & secret) and the OAuth2-specific lifetime m= anagement bits (eg how/when to refresh). We should explicitly define (in co= re) how to put a WWW-Authenticate header into a token response. >> >> -- >> 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 mscurtescu@google.com Mon Dec 6 12:00: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 86B243A68A3 for ; Mon, 6 Dec 2010 12:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.827 X-Spam-Level: X-Spam-Status: No, score=-109.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 BtjfEaHFndrY for ; Mon, 6 Dec 2010 12:00:25 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 0155028B56A for ; Mon, 6 Dec 2010 12:00:16 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id oB6K1drd024057 for ; Mon, 6 Dec 2010 12:01:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291665700; bh=mW/ZdlLbsUfFz5PtXEiJ3F7U3KE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=OgwIjzacA4J9aNwtofZ3/N+GS8ZKsEX5/2t4azg1aifgqwtMQq+XF0Qnlxih4kB4D vMbeah+29b6S0+XrIWMrQ== Received: from gwj23 (gwj23.prod.google.com [10.200.10.23]) by kpbe17.cbf.corp.google.com with ESMTP id oB6K0pwT026434 for ; Mon, 6 Dec 2010 12:01:38 -0800 Received: by gwj23 with SMTP id 23so4774456gwj.32 for ; Mon, 06 Dec 2010 12:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ps/kehuX4UBRDHxkQZQOqKtiCzMnHZ5G72gJLoM7BAA=; b=NQajGxpmNwa3g4tUhSKJ1NLY5lubP22zuyKV7d+NlPx48XaCUaK9hUKP6Qpyha/IjK e4SmqJFa7O473T8so9OQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Vqr2Erf8+y7JkAOyF6eIPlSKY4N9PoucVKSzpdHbuqN2BVI4tXyNIkAeEA2jdvlFn2 Yg4UNEjK0PJoafuht+gQ== Received: by 10.100.194.6 with SMTP id r6mr4297361anf.122.1291665698229; Mon, 06 Dec 2010 12:01:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Mon, 6 Dec 2010 12:01:18 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127A7B8279@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1127A7B8279@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Mon, 6 Dec 2010 12:01:18 -0800 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@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 20:00:26 -0000 On Sun, Dec 5, 2010 at 3:27 PM, Manger, James H wrote: > Marius, > >> How about: >> - keeping the scheme "OAuth2", for both WWW-Authenticate and Authorizati= on >> - define both as name/value pairs (WWW-Authenticate is already) >> - require that one of the pairs be "type=3D" >> >> For example: >> WWW-Authenticate: OAuth2 type=3Dbearer >> Authorization: OAuth2 token=3DvF9dft4qmT, type=3Dbearer > > > What is the benefit of trying to couple one form of bearer token so stron= gly to the OAuth2 delegation flows? > You have now complicated the Authorization header (extra type=3Dbearer pa= ram), and the WWW-Authentication header (now indicates that delegation is a= vailable, swapping-permanent-cred-for-temp-token is available, and bearer a= uthentication is required -- I hope a client can work out which is relevant= in any response). Not sure the Authorization header is that more complicated. Name/value pairs are pretty straight forward and any client or server must be able to handle them. If anything, the Basic scheme type seems the odd one to me. > Should Eran's MAC mechanim also use the same scheme, just with type=3Dmac= and adding its own parameters? I hope not. That's what I was suggesting. Why not? > We end up with multiple specs (core, bearer, MAC, any other auth mechanis= m...) all adding bits to the same HTTP scheme -- and not just registering t= heir own "type" value, but also all their own parameters (eg alg, nonce?, t= oken...). This causes unnecessary complications, because it is unnecessary = tight coupling. I don't see where the complication is coming from. They all share the scheme and a 'type' parameter, the rest is type specific. >> WWW-Authenticate: OAuth2 type=3Dbearer > > What does this mean to a client app? > Does it mean that if the client app already has a bearer token it should = repeat the request with that token. > Does it mean the client app should do an OAuth2 flow (which?) and expect = a bearer token? Does this type value override any type information in a sub= sequent token response? That could be dangerous. Should a server include mu= ltiple "WWW-Authenticate: OAuth2" headers if it can issue tokens for differ= ent authentication mechanisms depending on resources/scopes/client-app-pref= erences? > > "Authorization: BEARER ..." avoids a lot of confusion. Maybe, but how many schemes are we going to generate? Who controls these scheme names? Marius From mscurtescu@google.com Mon Dec 6 12:10: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 242813A68A9 for ; Mon, 6 Dec 2010 12:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.877 X-Spam-Level: X-Spam-Status: No, score=-109.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 ncTF88LyQA+U for ; Mon, 6 Dec 2010 12:10:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id EB7623A689F for ; Mon, 6 Dec 2010 12:10:06 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id oB6KBTU8021114 for ; Mon, 6 Dec 2010 12:11:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291666290; bh=AN1TGg42k+Cc1v5+VI/gAKQxXKo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=D0fCErJuniGCI2F4sJXFYbtRsf1n2OEN77ZaDqbLZ92RUTQn//VGk0o1+qyae6UgM pRA4w1px2LOz9LJukhVWA== Received: from gxk20 (gxk20.prod.google.com [10.202.11.20]) by wpaz29.hot.corp.google.com with ESMTP id oB6KBSUt006467 for ; Mon, 6 Dec 2010 12:11:28 -0800 Received: by gxk20 with SMTP id 20so9095181gxk.15 for ; Mon, 06 Dec 2010 12:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=gCvfyZUtpVOOUeujOhicToEhkJUGQmjzEnHGCPeVR98=; b=P8kD5dtAzoSRERJfcDukdKfWFDtlvOgdReBPNM1orZ8IlnAYIy3clpa9l2X86Rn5Bq M8cVxOj+kAZ1rgb0bqWw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ncrqF1BzNvOZO92Fnalo0to2VrOqcZ5x/indE2jBgn0kEHH81g7wRv+viedePqS+vL tq5WX5NLsHAlMrQbyEJQ== Received: by 10.100.194.6 with SMTP id r6mr4304720anf.122.1291666288463; Mon, 06 Dec 2010 12:11:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Mon, 6 Dec 2010 12:11:08 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 6 Dec 2010 12:11:08 -0800 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 Subject: Re: [OAUTH-WG] Client Password Credentials X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 20:10:08 -0000 On Sun, Dec 5, 2010 at 10:39 PM, Eran Hammer-Lahav wr= ote: > The argument was, since these are basic credentials, they should be used = in the native HTTP method using the header. But since that is not as simple= as a pair of parameters, we ended up with both. The easy way and the right= way. Not sure why is native HTTP the right way. Just because they are basic credentials? So is the username+password in the profile with the same name. > From implementing it, my experience has been that it can be hard to deal = with Basic in the context of another authentication class. Since OAuth and = Basic are usually two classes provided by the same authentication layer, ha= ving one use the other can lead to tricky architecture. This trivial to imp= lement in a clean environment, but a bit messy when adding to an existing f= ramework. The other complication comes from the fact that the server has to send an error response differently, based on how the credentials were sent. I really don't see the point for all this complication. I asked a few of the early OAuth 2 implementors, most don't implement the HTTP method at all, one implements it but only for the sake of the spec. If most implementors do not find this feature useful then I think it should be removed from core. Just to keep things simple. It can always be added as an extension. Marius From eran@hueniverse.com Mon Dec 6 12:42: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 D33F03A68BC for ; Mon, 6 Dec 2010 12:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_65=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 93srXCTwYoZ5 for ; Mon, 6 Dec 2010 12:42:43 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E0D383A68BA for ; Mon, 6 Dec 2010 12:42:42 -0800 (PST) Received: (qmail 8078 invoked from network); 6 Dec 2010 20:44:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Dec 2010 20:44:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 6 Dec 2010 13:43:53 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Mon, 6 Dec 2010 13:43:38 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuVf7/MsCeu8ZBBSTaJUME5ZezBEQABnZFg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B0661B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B06602E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 20:42:44 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Monday, December 06, 2010 11:57 AM > To: Eran Hammer-Lahav > Cc: Manger, James H; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >=20 > On Sun, Dec 5, 2010 at 10:34 PM, Eran Hammer-Lahav > wrote: > > This is not how most HTTP authentication frameworks work (that was the > conclusion from my HTTP Token scheme proposal a year ago). Most > frameworks rather switch on the scheme name, not on a parameter inside > the header. >=20 > The alternative, as suggested by James, requires a new scheme for each > token type. My guess is that we will have quite a few types pretty > soon: > - bearer opaque > - bearer transparent (JSON, signed by authz server) > - JWT signed > - MAC > - etc. >=20 > Who controls the auth header scheme names? Aren't we asking for a > collision here? Nah. It's a proposed registry and has never been very active. EHL > Marius >=20 >=20 > > > > EHL > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Marius Scurtescu > > Sent: Friday, December 03, 2010 4:27 PM > > To: Manger, James H > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 > > > > How about: > > - keeping the scheme "OAuth2", for both WWW-Authenticate and > > Authorization > > - define both as name/value pairs (WWW-Authenticate is already) > > - require that one of the pairs be "type=3D" > > > > For example: > > WWW-Authenticate: OAuth2 type=3Dbearer > > Authorization: OAuth2 token=3DvF9dft4qmT, type=3Dbearer > > > > Marius > > > > > > > > On Thu, Dec 2, 2010 at 7:59 PM, Manger, James H > wrote: > >> Eran, > >> > >>> What does scheme=3Dbasic mean [in a token response]? > >> > >> It means this token response contains credentials that can be used wit= h > the HTTP BASIC authentication scheme. Don't try to use the credentials wi= th > any other scheme. The access_token value would be used as the user-id, > and the token_secret value as the password. > >> > >> > >>> I think tying type and scheme together is less intuitive then > >>> letting the type definition provide the right scheme(s). > >> > >> Keeping them separate offers an additional degree of indirection. > >> Indirection is sometimes useful, but I don't think it adds any value h= ere. > >> It just means we need another registry (of token_types, with associate= d > procedures); and we need an extra spec for each authentication mechanism > to define the linkage to OAuth2. > >> > >> A lot of authentication mechanisms take similar inputs (an id and a se= cret) > so they shouldn't each need a separate spec to define their binding to > OAuth2. > >> > >> > >>> I am using 'MAC' for my draft. > >> > >> As the token_type? As the HTTP authentication scheme? I hope both. > >> > >>> But its still an OAuth2 extension, not a completely generic HTTP sche= me. > >> > >> I guess it is an OAuth2 extension in as much as it defines how to get = MAC > credentials from an OAuth2 token response: check token_type=3DMAC; > access_token is the id; token_secret is the MAC key; mac_algorithm is the > MAC algorithm. > >> > >>> It can be used independent of OAuth2 if you somehow got a token, > >>> secret, and mac algorithm name. > >> > >> Hopefully you define a "WWW-Authenticate: MAC ..." response header > that can list acceptable MAC algorithms. > >> I think an OAuth2 token response for a MAC scheme should contain the > same information as the WWW-Authenticate response header for the MAC > scheme, plus the credentials to use (id & secret) and the OAuth2-specific > lifetime management bits (eg how/when to refresh). We should explicitly > define (in core) how to put a WWW-Authenticate header into a token > response. > >> > >> -- > >> 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 mscurtescu@google.com Mon Dec 6 12: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 C628328C0D8 for ; Mon, 6 Dec 2010 12:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.902 X-Spam-Level: X-Spam-Status: No, score=-109.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 poiw+KFodZ5c for ; Mon, 6 Dec 2010 12:46:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 8485728B797 for ; Mon, 6 Dec 2010 12:46:02 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id oB6KlPFc030884 for ; Mon, 6 Dec 2010 12:47:25 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291668446; bh=VzIy7sM+yUskFdpE9ject7F5moE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=B8snzVRKEf+BNavxwiGDHNLuI6/Yo0HKzb23CAC38Ai5ONb5hrQU9hsxsrFZiqiuM LW4ERmXAt5H/uiO/F5Rcg== Received: from yxl31 (yxl31.prod.google.com [10.190.3.223]) by kpbe16.cbf.corp.google.com with ESMTP id oB6Kkel0030740 for ; Mon, 6 Dec 2010 12:47:24 -0800 Received: by yxl31 with SMTP id 31so6557829yxl.32 for ; Mon, 06 Dec 2010 12:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=zWCW0tK1KSk05Ro7f/xPDW1ybffDHfij/wiMptdifh0=; b=FfxE0SEcDLFqpTT+5/4Y30D++udWAUlgxJQLLB5oiDVtHEnN+nzMxM+UML9mqNZbuf LGS6O73WELUvrdjvxeDA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mPQQKQoT7rPQ8+ePYOv5Mt1zL0ipK45d3tnSjBO7zlV6a4N7pNAJ8iKF87tksg8r4I kCY2JtPrgCRHDK6hFNCQ== Received: by 10.100.13.11 with SMTP id 11mr4351447anm.20.1291668443969; Mon, 06 Dec 2010 12:47:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Mon, 6 Dec 2010 12:47:03 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B0661B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B06602E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343D4B0661B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Mon, 6 Dec 2010 12:47:03 -0800 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] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 20:46:03 -0000 On Mon, Dec 6, 2010 at 12:43 PM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Monday, December 06, 2010 11:57 AM >> To: Eran Hammer-Lahav >> Cc: Manger, James H; oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >> >> On Sun, Dec 5, 2010 at 10:34 PM, Eran Hammer-Lahav >> wrote: >> > This is not how most HTTP authentication frameworks work (that was the >> conclusion from my HTTP Token scheme proposal a year ago). Most >> frameworks rather switch on the scheme name, not on a parameter inside >> the header. >> >> The alternative, as suggested by James, requires a new scheme for each >> token type. My guess is that we will have quite a few types pretty >> soon: >> - bearer opaque >> - bearer transparent (JSON, signed by authz server) >> - JWT signed >> - MAC >> - etc. >> >> Who controls the auth header scheme names? Aren't we asking for a >> collision here? > > Nah. It's a proposed registry and has never been very active. Doesn't that mean that we should be even more cautious with creating lots of schemes? Marius From eran@hueniverse.com Mon Dec 6 13:10: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 1739D3A68BF for ; Mon, 6 Dec 2010 13:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 G4Kpya1aeI1Y for ; Mon, 6 Dec 2010 13:10:46 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 23E533A6806 for ; Mon, 6 Dec 2010 13:10:46 -0800 (PST) Received: (qmail 22249 invoked from network); 6 Dec 2010 21:12:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Dec 2010 21:12:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 6 Dec 2010 14:12:00 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Mon, 6 Dec 2010 14:11:44 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuVhs654wUO7NSSRAyk8N8jYBxTFgAAz9Ew Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D4B0661D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B06602E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343D4B0661B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 21:10:47 -0000 Each scheme will have an RFC and will get proper review. If there is consen= sus for a new scheme, the rest doesn't matter. And being able to reuse thes= e schemes without having to use a confusing OAuth2 scheme is a big benefit. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Monday, December 06, 2010 12:47 PM > To: Eran Hammer-Lahav > Cc: Manger, James H; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >=20 > On Mon, Dec 6, 2010 at 12:43 PM, Eran Hammer-Lahav > wrote: > > > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Monday, December 06, 2010 11:57 AM > >> To: Eran Hammer-Lahav > >> Cc: Manger, James H; oauth@ietf.org > >> Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft > >> -01 > >> > >> On Sun, Dec 5, 2010 at 10:34 PM, Eran Hammer-Lahav > >> wrote: > >> > This is not how most HTTP authentication frameworks work (that was > >> > the > >> conclusion from my HTTP Token scheme proposal a year ago). Most > >> frameworks rather switch on the scheme name, not on a parameter > >> inside the header. > >> > >> The alternative, as suggested by James, requires a new scheme for > >> each token type. My guess is that we will have quite a few types > >> pretty > >> soon: > >> - bearer opaque > >> - bearer transparent (JSON, signed by authz server) > >> - JWT signed > >> - MAC > >> - etc. > >> > >> Who controls the auth header scheme names? Aren't we asking for a > >> collision here? > > > > Nah. It's a proposed registry and has never been very active. >=20 > Doesn't that mean that we should be even more cautious with creating lots > of schemes? >=20 > Marius From James.H.Manger@team.telstra.com Mon Dec 6 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 7A0D53A68D6 for ; Mon, 6 Dec 2010 14:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=0.007, 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 JLtX3SDeEtdT for ; Mon, 6 Dec 2010 14:59:22 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 697633A68CD for ; Mon, 6 Dec 2010 14:59:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,307,1288530000"; d="scan'208";a="19181424" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 07 Dec 2010 10:00:45 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6189"; a="14918063" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccni.tcif.telstra.com.au with ESMTP; 07 Dec 2010 10:00:45 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 7 Dec 2010 10:00:44 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Tue, 7 Dec 2010 10:00:43 +1100 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuR84PTKQ3VtH/7T02XcbsmyzxgnAArbPCAAAAikoAAKy+g8ABwKxuQACEURcA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1127A892E4F@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739432463D3B1@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B06602D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B06602D@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 22:59:23 -0000 When a client app gets an OAuth2 token response it needs to know what to do= next. In particular, which authentication *protocol* it should use with th= e received credential. I thought this was what token_type was designed for,= hence my suggestion that it hold an HTTP authentication scheme name. A totally separate piece of information is what is the internal format of a= token. Is it a random index to server-side state, or a JWT, or a base64-en= coded SAML message? This information could be helpful for protected resourc= e servers if they trust multiple authorization servers. It might be helpful= to some client apps, though most should be able to treat a token as an opa= que blob. Mike Jones though this was what token_type was designed for. These two uses are quite separate. A bearer token could use a JWT, SWT, SAML, or random-string syntax. Similarly, an "id" in a MAC scheme (or the user-id in the BASIC scheme) cou= ld be a JWT, SWT, SAML, or random-string. Conversely, knowing a token is in JWT format doesn't tell a client app if i= t should sent the token in a "Authorization: BEARER ..." header, or a oauth= _token=3D.. query-string/body parameter, or in a "Authorization: MAC ..." h= eader along with a signature. Marius, I certainly do NOT want new HTTP schemes to be invented every time an autho= rization server comes up with a new internal structure for its tokens/ids. = If we need to indicate the internal structure of a token/id (and assuming s= elf-describing syntaxes are insufficient), then we need a parameter that is= *separate* from the indication of the authentication protocol. Looks like we need two parameters: * scheme * token_format -- James Manger From James.H.Manger@team.telstra.com Mon Dec 6 15:43: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 AE7173A68DB for ; Mon, 6 Dec 2010 15:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_65=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 kAl+FP7TSY98 for ; Mon, 6 Dec 2010 15:43:29 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 6444E3A68B1 for ; Mon, 6 Dec 2010 15:43:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,307,1288530000"; d="scan'208";a="19335521" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 Dec 2010 10:44:52 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6189"; a="14689834" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdvi.tcif.telstra.com.au with ESMTP; 07 Dec 2010 10:44:52 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 7 Dec 2010 10:44:51 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "oauth@ietf.org" Date: Tue, 7 Dec 2010 10:44:51 +1100 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: AcuSX8hmJOkfgwswSLCmwCDoUYn81AAEtzvgAAflxEAAAYywQACe4CrQACHKhrA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1127A892FC8@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739432463848A@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA025@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B065D90@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127A6EA714@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B066036@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B066036@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Dec 2010 23:43:30 -0000 Eran, >>> What does scheme=3Dbasic mean [in a token response]? > But that has the same security properties as bearer. True. >> Keeping [type and scheme] separate... >> It just means we need another registry (of token_types, with associated >> procedures); and we need an extra spec for each authentication mechanism >> to define the linkage to OAuth2. > Yeah. But I'm not expecting a flood. We'll have a handful and probably 2 = will survive the deployment test. OAuth 1.0a had three signature methods an= d only one really got any significant traction. Its not a flood of schemes I am concerned about, but providing a clear ment= al model. It is less obvious how delegation and HTTP auth go together when = one uses "type" and the other uses "scheme", with any connection between th= e two left to a case-by-case description. >> A lot of authentication mechanisms take similar inputs (an id and a secr= et) so >> they shouldn't each need a separate spec to define their binding to OAut= h2. >I don't see a way around it. OAuth returns tokens using form-encoded URI a= nd JSON body replies. If your token is not self describing, you need extra = parameters so binding is required anyway. It is a pity the form-encoding isn't a base64url-encoded version of the JSO= N body reply isn't it :-( >>> I am using 'MAC' for my draft. >> >> As the token_type? As the HTTP authentication scheme? I hope both. > > In my case both, but I don't care about it as a generic HTTP authenticati= on scheme. It can be used that way but it is defined in clear OAuth context= . My guess is that it would be easier to understand a standalone MAC HTTP aut= h scheme, than have to understand it amongst the complexities of delegation= /swapping-perm-cred-for-temp-cred/swapping-assertion-for-temp-cred/etc. I am looking forward (with some trepidation) to seeing the MAC scheme in yo= ur current project. -- James Manger From stpeter@stpeter.im Wed Dec 8 16:34: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 5E4963A68D0 for ; Wed, 8 Dec 2010 16:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTKNQ1vIDcp2 for ; Wed, 8 Dec 2010 16:34:51 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1DB283A68CE for ; Wed, 8 Dec 2010 16:34:51 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A27CE4009B for ; Wed, 8 Dec 2010 17:48:12 -0700 (MST) Message-ID: <4D002481.40408@stpeter.im> Date: Wed, 08 Dec 2010 17:36:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090709050702000105080503" Subject: [OAUTH-WG] Fwd: I-D Action:draft-hardjono-oauth-kerberos-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: Thu, 09 Dec 2010 00:34:52 -0000 This is a cryptographically signed message in MIME format. --------------ms090709050702000105080503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks to Thomas for updating this document, which I continue to think is quite interesting and helpful... -------- Original Message -------- Subject: I-D Action:draft-hardjono-oauth-kerberos-01.txt Date: Wed, 08 Dec 2010 13:00:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OAuth 2.0 support for the Kerberos V5 Authentication Protocol Author(s) : T. Hardjono Filename : draft-hardjono-oauth-kerberos-01.txt Pages : 20 Date : 2010-12-08 This draft proposes an OAuth2.0 profile for Kerberos v5. We compare the Kerberos protocol flow with the OAuth protocol flow and as far as possible map the relevant parameters in Kerberos to OAuth parameters. We propose the use of the OAuth 2.0 message flows and its tokens to carry Kerberos TGTs and Service Tickets in an opaque manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hardjono-oauth-kerberos-01.txt --------------ms090709050702000105080503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIw OTAwMzYxN1owIwYJKoZIhvcNAQkEMRYEFHgD0ysUGPLfYKdFYUQoU2ayGD3eMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBxj3Oe5bJDoMzKwo49oEdI5wZTr1Rul9L+Y8pKiM0jI5nyjD+smlYS74ob FJHSTYgRy8j6AESMC+8ot0YGW23lw1/o/HAPqWvHwVV209ZS5ZzVQZSjbDd+9NzokouSFyqH iP1VaUgFs7IkVODDc0HPuZF3f+wGQWHjvsb6622c7ZgJFqM+ZrgaxwJ8RAIx9Ix5DZ8Bqt8y EODp3RiKxY2Wi6qtdYjwh1YnfNAx7UpmIbKp7J9uGq+Hgx+TLDDA4QMq2jhVRYEwppsKDg3B kEvVUTUk534QENwrgaaY2uZs6cHNSA9FUxqyyz5dDTJApeG35OkeJa1q8z7HTTk8OVrJAAAA AAAA --------------ms090709050702000105080503-- From hardjono@mit.edu Thu Dec 9 07:05: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 CAF2F28C0D6 for ; Thu, 9 Dec 2010 07:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[AWL=-1.511, 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 qcM-F8HjIVa6 for ; Thu, 9 Dec 2010 07:05:55 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by core3.amsl.com (Postfix) with ESMTP id 1B8223A67A2 for ; Thu, 9 Dec 2010 07:05:54 -0800 (PST) X-AuditID: 12074425-b7c98ae000000a04-5c-4d00f0acac9c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id CC.00.02564.CA0F00D4; Thu, 9 Dec 2010 10:07:24 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id oB9F7NO2020057; Thu, 9 Dec 2010 10:07:24 -0500 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 oB9F7M0H025867; Thu, 9 Dec 2010 10:07:22 -0500 Received: from w92exhub7.exchange.mit.edu (18.7.73.13) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 9 Dec 2010 10:06:52 -0500 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub7.exchange.mit.edu ([18.7.73.13]) with mapi; Thu, 9 Dec 2010 10:07:22 -0500 From: Thomas Hardjono To: Peter Saint-Andre , OAuth WG Date: Thu, 9 Dec 2010 10:07:18 -0500 Thread-Topic: [OAUTH-WG] Fwd: I-D Action:draft-hardjono-oauth-kerberos-01.txt Thread-Index: AcuXORya69y3A6omTju2oCL81Gtb3wAeUPHQ Message-ID: References: <4D002481.40408@stpeter.im> In-Reply-To: <4D002481.40408@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CB9788.DB85B330" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] Fwd: I-D Action:draft-hardjono-oauth-kerberos-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: Thu, 09 Dec 2010 15:05:57 -0000 ------=_NextPart_000_0000_01CB9788.DB85B330 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thanks Peter, I believe there is genuine interest in Enterprises in seeing OAuth interoperate with existing security infra. Hopefully I can add more to the draft in the near future. /thomas/ __________________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Wednesday, December 08, 2010 7:36 PM > To: OAuth WG > Subject: [OAUTH-WG] Fwd: I-D Action:draft-hardjono-oauth-kerberos- > 01.txt > > Thanks to Thomas for updating this document, which I continue to think > is quite interesting and helpful... > > -------- Original Message -------- > Subject: I-D Action:draft-hardjono-oauth-kerberos-01.txt > Date: Wed, 08 Dec 2010 13:00:01 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : OAuth 2.0 support for the Kerberos V5 > Authentication > Protocol > Author(s) : T. Hardjono > Filename : draft-hardjono-oauth-kerberos-01.txt > Pages : 20 > Date : 2010-12-08 > > This draft proposes an OAuth2.0 profile for Kerberos v5. We compare > the Kerberos protocol flow with the OAuth protocol flow and as far as > possible map the relevant parameters in Kerberos to OAuth parameters. > We propose the use of the OAuth 2.0 message flows and its tokens to > carry Kerberos TGTs and Service Tickets in an opaque manner. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hardjono-oauth-kerberos- > 01.txt > ------=_NextPart_000_0000_01CB9788.DB85B330 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILazCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggRGMIIDr6ADAgECAhBm/Ufjwhnk6JrNmd31OsskMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjgf8wgfwwEgYDVR0TAQH/BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAuBgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0 ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQUEX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwDQYJKoZIhvcNAQEFBQAD gYEAPKPaAmM6xJOqq3LT3K1QOB4MnhZKiLfu69n/D42VoNa7+moLrmGE2GhHie9PrLIfSUGbSTN2 k4uebrlDHGC9wtyKLYfBRcARcgQaayQqbG/n/AcTKdB3OiPn9cGFaBm/xgFUIBmuNYLMYjxhCcb0 1euwD6afM4Wa03GOUI+Z3WIwggTcMIIDxKADAgECAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqGSIb3 DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwHhcNMTAwMjE3MDAwMDAwWhcNMTEwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3Mg MSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0G CSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5IPN5gsvYs8ugsfq1ndIZqRJXlbGSKsX+IH45pbnLeWPFWzfG7mxch4QhqOD0RUs2GCI1YNHPS8C sFyj1V05XnT0p/1eHa8eHOV2V3RVljq3P5R2+vhskoGE2Nwm1wi8YP9ce0Cs2Qf4wiPm9oL2ls5M yvOCR0aWfBkXD231vBUCAwEAAaOB4jCB3zAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9u ZTBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNv bS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJrdkpPOIr2sXpSrE9hlj36x FOukzUivx4QwmsyLSFvMrkSQ/7NCGQ73O6DMlmJZbtQPMdIpqc9ZwPYhOkyQ9AaKz10yHVO8TkW2 CAN0Atk1ZfAF78C1h/jch429nYmjADnDZyDuyRUi2yW4ouJkX84Suj1SYaC5ptZVmmMUyRwcNV6/ iHewW8wsIf0mOqtP79RMAJ6oGh0XlUmzlahqtMbi3JX02D9gAVW9j8zXqtI0pHSpMNkNzkFp8GRd 5bxaCdQzszNIPfQGNIM0x7w97ZbF8z+F2yCRSL0+4G9kQxGRpxkd1OWjov5OJfmPvOyTZkkX9cmd Sivi3+fEDBgv0kIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMAkGBSsOAwIaBQCgggMbMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIwOTE1MDcxNlowIwYJ KoZIhvcNAQkEMRYEFArs0aQ5bds8GcyTMAagZY8Vnc4eMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEB1s nuonW3elCgnJYj0ahc0wggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqG SIb3DQEBAQUABIGAzyJ1b2jR5YCKyWLmPGfyCuSVb7AI6fLXKuvm3ITwb6XJ+dkoycyfjLtBLhzR XhbmyCrycrSY7DxdFZ6oJ3iWw1n0TMK+MYEV9bjXweJmIF/vRKaSD49R3sJxHQhG5rIcYh23o3Lp 1tqvz6JRlWQYYyAXjfyR4GrefrWk2dsfOb0AAAAAAAA= ------=_NextPart_000_0000_01CB9788.DB85B330-- From bcampbell@pingidentity.com Thu Dec 9 13: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 EC9D33A69A0 for ; Thu, 9 Dec 2010 13:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 EjdG1IdBWifO for ; Thu, 9 Dec 2010 13:37:03 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id 2CBB13A6835 for ; Thu, 9 Dec 2010 13:37:02 -0800 (PST) Received: from source ([209.85.161.43]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTQFMWP2QB32zKvX2tHFhpn7oTfi1BS08@postini.com; Thu, 09 Dec 2010 13:38:33 PST Received: by mail-fx0-f43.google.com with SMTP id 18so2969202fxm.2 for ; Thu, 09 Dec 2010 13:38:32 -0800 (PST) Received: by 10.223.93.133 with SMTP id v5mr232360fam.119.1291930712201; Thu, 09 Dec 2010 13:38:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.35.1 with HTTP; Thu, 9 Dec 2010 13:38:02 -0800 (PST) From: Brian Campbell Date: Thu, 9 Dec 2010 14:38:02 -0700 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Dec 2010 21:37:05 -0000 I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however, a couple things jumped out at me in areas that hadn't received much attention yet so I wanted to raise the questions on a separate thread. Near the end of section 3.2. Threat Mitigation, it says: " Furthermore, the resource server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the resource server. " Was the intent here to say authorization server rather than resource server? The resource server doesn't hand out tokens. Also, aren't there legitimate cases where the client isn't authenticated (anonymous or other cases where the client can't keep secrets)? Then it says: "The authorization server MUST also receive a confirmation (the consent of the resource owner) prior to providing a token to the client." Does this allow for implicit consent? On my first read of it, I interpret this as potentially being more restrictive than what is in draft-ietf-oauth-v2-11 From Michael.Jones@microsoft.com Thu Dec 9 21:37: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 872183A6C39 for ; Thu, 9 Dec 2010 21:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 UKrHLdEEJs2Y for ; Thu, 9 Dec 2010 21:37:12 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B395E3A68A6 for ; Thu, 9 Dec 2010 21:37:11 -0800 (PST) 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, 9 Dec 2010 21:38:42 -0800 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.228]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Thu, 9 Dec 2010 21:38:42 -0800 From: Mike Jones To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations Thread-Index: AcuYLIBiXC1ULO/RRbazk6O5//eDAA== Date: Fri, 10 Dec 2010 05:38:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394324649C50@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Dec 2010 05:37:16 -0000 Hannes, can you take a stab at answering these, since I believe you were th= e author (or perhaps editor) of the text below? Thanks, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Thursday, December 09, 2010 1:38 PM To: oauth Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 secur= ity considerations I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however= , a couple things jumped out at me in areas that hadn't received much atten= tion yet so I wanted to raise the questions on a separate thread. Near the end of section 3.2. Threat Mitigation, it says: " Furthermore, the resource server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the resource server. " Was the intent here to say authorization server rather than resource server= ? The resource server doesn't hand out tokens. Also, aren't there legitimat= e cases where the client isn't authenticated (anonymous or other cases wher= e the client can't keep secrets)? Then it says: "The authorization server MUST also receive a confirmation (the consent of the resource owner) prior to providing a token to the client." Does this allow for implicit consent? On my first read of it, I interpret t= his as potentially being more restrictive than what is in draft-ietf-oauth-v2-11 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Dec 9 21:44: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 37F5E28C14F for ; Thu, 9 Dec 2010 21:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[AWL=0.031, 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 7-NCjAA8BDNj for ; Thu, 9 Dec 2010 21:44:29 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 1C8D028C150 for ; Thu, 9 Dec 2010 21:44:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,322,1288530000"; d="scan'208";a="19592435" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 10 Dec 2010 16:45:59 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6192"; a="15241249" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbni.tcif.telstra.com.au with ESMTP; 10 Dec 2010 16:45:58 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Fri, 10 Dec 2010 16:45:58 +1100 From: "Manger, James H" To: Mike Jones , Brian Campbell , oauth Date: Fri, 10 Dec 2010 16:45:56 +1100 Thread-Topic: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations Thread-Index: AcuYLIBiXC1ULO/RRbazk6O5//eDAAAAFUjQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1127AA90906@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394324649C50@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394324649C50@TK5EX14MBXC201.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Dec 2010 05:44:30 -0000 I think these items shouldn't be in the bearer spec at all. They are about = "getting a token", not about "using a bearer token" so they should be left = to the core spec. -- James Manger -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Thursday, December 09, 2010 1:38 PM To: oauth Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 secur= ity considerations I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however= , a couple things jumped out at me in areas that hadn't received much atten= tion yet so I wanted to raise the questions on a separate thread. Near the end of section 3.2. Threat Mitigation, it says: " Furthermore, the resource server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the resource server. " Was the intent here to say authorization server rather than resource server= ? The resource server doesn't hand out tokens. Also, aren't there legitimat= e cases where the client isn't authenticated (anonymous or other cases wher= e the client can't keep secrets)? Then it says: "The authorization server MUST also receive a confirmation (the consent of the resource owner) prior to providing a token to the client." Does this allow for implicit consent? On my first read of it, I interpret t= his as potentially being more restrictive than what is in draft-ietf-oauth-v2-11 From primmer@google.com Fri Dec 10 17:57: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 A10C43A6CBF for ; Fri, 10 Dec 2010 17:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.574 X-Spam-Level: X-Spam-Status: No, score=-109.574 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, 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 lLpjNU8+F41s for ; Fri, 10 Dec 2010 17:57:38 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3FCE63A68B6 for ; Fri, 10 Dec 2010 17:57:38 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id oBB1x9mE027641 for ; Fri, 10 Dec 2010 17:59:09 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292032750; bh=rs9OwdXHxCPg+uqGCC5DKrFV6zQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=VE940/hgHXVjSgr+gU/S5cYfy+xHJzDFjF3rUbFJOmG/6DSzrKIZYDySJ4gHW5V70 0cyoSMIXBkf40Ozgkfv9w== Received: from qyk12 (qyk12.prod.google.com [10.241.83.140]) by wpaz1.hot.corp.google.com with ESMTP id oBB1x8Xc016640 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 10 Dec 2010 17:59:08 -0800 Received: by qyk12 with SMTP id 12so3915838qyk.12 for ; Fri, 10 Dec 2010 17:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=M6bNof9ceSHktJZnO3U1pA9WvY8Koo5JDzH6o1IlLgw=; b=kgsZMD/+vXBtx0RmJZB+hVHOkI9EjNkSau5ONx3BbYZbx4XRec/KS/XaOyzJmv617H EP4bqZ+UE6XeTsRpqh7g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=tAGCuMEnZg8mkckQKfuz6qD/t7BncYtNbeS0vtUCr6+HcnZSOqlSuSt59phJxLI5QB fV+STA5Pl3tFyljpymUA== Received: by 10.229.220.144 with SMTP id hy16mr1240952qcb.259.1292032747868; Fri, 10 Dec 2010 17:59:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.76.85 with HTTP; Fri, 10 Dec 2010 17:58:47 -0800 (PST) In-Reply-To: <62D210BF-3FA7-4789-9382-5BCCE45C5F84@xmlgrrl.com> References: <4E1F6AAD24975D4BA5B16804296739432461C3F9@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B06532D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <62D210BF-3FA7-4789-9382-5BCCE45C5F84@xmlgrrl.com> From: David Primmer Date: Fri, 10 Dec 2010 17:58:47 -0800 Message-ID: To: Eve Maler 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] Feedback on preliminary draft 11 from implementers of draft 10 X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Dec 2010 01:57:39 -0000 -1 to separate parameters. I'd imagine every provider has the same issues as the ones you point out, however I don't think we should take another step toward complexity in this area. We've all managed to squeeze our resource access control semantics down into a single value and it usually requires some form of specific (I'd rather not call it "proprietary") formatting. I don't think there's any problem with defining what works for you there. And, I don't think we to get into XACML-like complexity around this 'scope' feature. It's a slippery scope slope. davep On Sat, Dec 4, 2010 at 7:42 PM, Eve Maler wrote: > A comment on Mike's comment on the idea of a "resource" parameter... > > On 24 Nov 2010, at 11:31 PM, Eran Hammer-Lahav wrote: > >> Thanks Mike! Comments inline. >> >>> Normative Issues >>> >>> 4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1 "Scope" parameter should be = paired with >>> complimentary "resource" parameter >> >> I am more inclined to drop 'scope' than to include 'resource'. Scope as = currently defined can easily accommodate resource - we specifically chose s= pace-delimited to allow URI values. If you want a new parameter, *you* will= have to build consensus. Not wearing my editor hat, I'm -1. > > Over in UMA-land we've had to solve for this because our use cases antici= pate protecting arbitrary resources, not just singular APIs, and because ou= r loosely coupled resource server and authorization server components need = to communicate about this stuff in an organized fashion. > > After many months of discussion, as well as UX and implementation work by= various participants, in the last week we finally got consensus around hav= ing two parts (resource sets and actions, the latter being a close analogue= to today's OAuth scopes) rather than a single flat scope namespace. =A0The= degenerate case could be very much like today's common practice, but we be= lieve it handles a lot more use cases. > > There's still work to do to propagate information in this two-part form t= hroughout the protocol flow (which is what Mike was directly suggesting), b= ut at least we now have a conceptual foundation for doing that. =A0If there= is consensus here for adding a parameter, it would make UMA's life easier = as we wouldn't have to invent anything weird and nonstandard. :-) > > See the "Resource Registration" spec link from our Working Drafts page fo= r more info; if there's sufficient interest, we could contribute it as an I= ETF I-D soonish: > > http://kantarainitiative.org/confluence/display/uma/Working+Drafts > > =A0 =A0 =A0 =A0Eve > > Eve Maler =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0http://www.xmlgrrl.com/blog > +1 425 345 6756 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.twitter.com/xmlgrrl > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Dec 10 21:58: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 748AA3A69D5 for ; Fri, 10 Dec 2010 21:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.095, 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 Vfk4+SNjH1qn for ; Fri, 10 Dec 2010 21:58:24 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AF22E3A69D2 for ; Fri, 10 Dec 2010 21:58:24 -0800 (PST) Received: (qmail 5212 invoked from network); 11 Dec 2010 05:59:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Dec 2010 05:59:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 10 Dec 2010 22:59:56 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 10 Dec 2010 22:59:36 -0700 Thread-Topic: Terminology editorial work Thread-Index: AcuY+EwiHywIMr/OQuuNWnUrraOHyw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343FD1CA2778@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_90C41DD21FB7C64BB94121FBBC2E72343FD1CA2778P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Terminology editorial work X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Dec 2010 05:58:25 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343FD1CA2778P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After reading the specification from start to finish, I decided that the te= rminology section comes too early and is more confusing than helpful. I am = moving it to an appendix and replacing it with short prose in the introduct= ion. With this change, I am no open to include any other term used in the d= ocument not already defined. If you notice any term which will be useful to include in a reference termi= nology appendix, please let me know. In the past I resisted expanding the t= erminology section, but now would like to make it more complete. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343FD1CA2778P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After reading th= e specification from start to finish, I decided that the terminology sectio= n comes too early and is more confusing than helpful. I am moving it to an = appendix and replacing it with short prose in the introduction. With this c= hange, I am no open to include any other term used in the document not alre= ady defined.

 

If you notice any term which will be useful to include in a = reference terminology appendix, please let me know. In the past I resisted = expanding the terminology section, but now would like to make it more compl= ete.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E72343FD1CA2778P3PW5EX1MB01E_-- From bcampbell@pingidentity.com Mon Dec 13 05:59: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 507463A6E97 for ; Mon, 13 Dec 2010 05:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 mJeohG4cZ3Sy for ; Mon, 13 Dec 2010 05:59:37 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 1B0E53A6D9E for ; Mon, 13 Dec 2010 05:59:36 -0800 (PST) Received: from source ([209.85.161.49]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTQYnJwxRBkuI+PYk1pnfV/6nRN+fhrZk@postini.com; Mon, 13 Dec 2010 06:01:15 PST Received: by mail-fx0-f49.google.com with SMTP id 19so5784823fxm.36 for ; Mon, 13 Dec 2010 06:01:11 -0800 (PST) Received: by 10.223.106.129 with SMTP id x1mr1467934fao.39.1292248870981; Mon, 13 Dec 2010 06:01:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.115.201 with HTTP; Mon, 13 Dec 2010 06:00:40 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127AA90906@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394324649C50@TK5EX14MBXC201.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1127AA90906@WSMSG3153V.srv.dir.telstra.com> From: Brian Campbell Date: Mon, 13 Dec 2010 07:00:40 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Dec 2010 13:59:38 -0000 I think James makes a good point here. On Thu, Dec 9, 2010 at 10:45 PM, Manger, James H wrote: > I think these items shouldn't be in the bearer spec at all. They are abou= t "getting a token", not about "using a bearer token" so they should be lef= t to the core spec. > > -- > James Manger > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Brian Campbell > Sent: Thursday, December 09, 2010 1:38 PM > To: oauth > Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 sec= urity considerations > > I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, howev= er, a couple things jumped out at me in areas that hadn't received much att= ention yet so I wanted to raise the questions on a separate thread. > > Near the end of section 3.2. Threat Mitigation, it says: > > " Furthermore, the resource server MUST ensure that it only hands out > =A0 tokens to clients it has authenticated first and authorized. =A0For > =A0 this purpose, the client MUST be authenticated and authorized by the > =A0 resource server. " > > Was the intent here to say authorization server rather than resource serv= er? The resource server doesn't hand out tokens. Also, aren't there legitim= ate cases where the client isn't authenticated (anonymous or other cases wh= ere the client can't keep secrets)? > > Then it says: > > "The authorization server MUST also receive a > =A0 confirmation (the consent of the resource owner) prior to providing a > =A0 token to the client." > > Does this allow for implicit consent? On my first read of it, I interpret= this as potentially being more restrictive than what is in > draft-ietf-oauth-v2-11 > From torsten@lodderstedt.net Mon Dec 13 10:58: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 E7CD33A6DEB for ; Mon, 13 Dec 2010 10:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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 1kFJW-cCbFqC for ; Mon, 13 Dec 2010 10:58:51 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 2347328C0DF for ; Mon, 13 Dec 2010 10:58:50 -0800 (PST) Received: from [79.253.50.128] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PSDdL-0004me-TY for oauth@ietf.org; Mon, 13 Dec 2010 20:00:27 +0100 Message-ID: <4D066D50.6000105@lodderstedt.net> Date: Mon, 13 Dec 2010 20:00:32 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Comments on core draft -11 X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Dec 2010 18:58:52 -0000 section 5.1.5 Assertion I expected the assertion flow to be replaced by a general extension model for new grant types (as described in section 7.4)? But the the current text in section 5.1.5. requires every new grant type to use the "assertion" parameter. Thus it supports additional assertion formats, only. What is the benefit of that restriction? Moreover, how should one define new grant types that are not assertion based or need no or more than one parameter? For example in the context of telecommunication, I see the need to support GBA, HOTP, and plain IP address-based user authentication. For the later, only a grant type w/o any further parameters is required. I would suggest dropping the required parameter “assertion”. Instead, deployments could define new grant types along with their accompanying parameters. For assertion-based new grant type this could be the assertion parameter though. w/ respect to section 7.4 I would suggest to change “Applications that wish to define additional access grant types can do so by utilizing a new or existing assertion type and format.” into “Applications that wish to define additional access grant types can do so by utilizing a new or existing grant type name.” section 5.1.5 The description mixes up user authentication via assertion and client authentication via assertion. Shouldn’t clients be authenticated via client_assertion parameter? section 5.2 “The authorization server SHOULD NOT issue a refresh token when the access grant type is an assertion or a set of client credentials.” How shall the server determine whether to issue refresh tokens in case of grant type “Resource Owner Password Credentials”? In contrast to authorization code, the user is not directly involved in the interaction with the authorization server. I would suggest adding an optional request parameter “refresh_token” of type boolean to explicitly ask the server for a refresh token. section 5.1.3 Error code “unauthorized_client” in my opinion calls for status code 403 regards, Torsten. From mscurtescu@google.com Mon Dec 13 13:25: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 830BC28C0F3 for ; Mon, 13 Dec 2010 13:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.917 X-Spam-Level: X-Spam-Status: No, score=-105.917 tagged_above=-999 required=5 tests=[AWL=0.060, 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 IWHUiRqMSdVn for ; Mon, 13 Dec 2010 13:25:45 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 989FA3A6D2C for ; Mon, 13 Dec 2010 13:25:45 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id oBDLRNwh003023 for ; Mon, 13 Dec 2010 13:27:23 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292275643; bh=/s5rWyC9k0uxb2dy0foS0xUiC3Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Y4wSgqAsHAO7HeYpImXUYiVe7Hr7+Ze1Of9TJM/hTXNFUgBiM6sB6hligFOjvei8E Rx4tNWXvYYfDCPjECdN5g== Received: from gxk3 (gxk3.prod.google.com [10.202.11.3]) by wpaz9.hot.corp.google.com with ESMTP id oBDLQvpe007796 for ; Mon, 13 Dec 2010 13:27:22 -0800 Received: by gxk3 with SMTP id 3so6709gxk.19 for ; Mon, 13 Dec 2010 13:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=m0TgMGzevgh/MZPiH5J7o74geuRtAHsmfe47yPsVggI=; b=tBBJY/wzu3WY4cX7nZZ1PTQ/fnDLhLwtKcjkziqnSslCFAH3Vo6zzgYWOmAxE8BCRv vKX9VwjnJlkm+ZQAf70g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=HytxDMVPbTbIGS+CTy1tssJbD8MEs3soUfEfY+7bK1ZEVmSKxEQ3kfzPLIiXqZsxr7 obj9u6/8b0R3P/BFl1ag== Received: by 10.100.227.13 with SMTP id z13mr3052594ang.54.1292275642558; Mon, 13 Dec 2010 13:27:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Mon, 13 Dec 2010 13:27:02 -0800 (PST) In-Reply-To: <4D066D50.6000105@lodderstedt.net> References: <4D066D50.6000105@lodderstedt.net> From: Marius Scurtescu Date: Mon, 13 Dec 2010 13:27:02 -0800 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Comments on core draft -11 X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Dec 2010 21:25:46 -0000 On Mon, Dec 13, 2010 at 11:00 AM, Torsten Lodderstedt wrote: > section 5.2 > =93The authorization server SHOULD NOT issue a refresh token when the acc= ess > grant type is an assertion or a set of client credentials.=94 > > How shall the server determine whether to issue refresh tokens in case of > grant type =93Resource Owner Password Credentials=94? In contrast to > authorization code, the user is not directly involved in the interaction > with the authorization server. Not directly, but the user did provide the credentials. In this case the only long term credentials the client has are the end user credentials, the server better issue a refresh token so the client is not forced to store the user credentials, right? > I would suggest adding an optional request parameter =93refresh_token=94 = of type > boolean to explicitly ask the server for a refresh token. I agree that something like this parameter would be useful. Maybe something a bit more generic to allow clients to request access and/or refresh tokens. I will send an extension proposal in this regard. But I don't think this mechanism should be used to decide if the assertion profile issues a refresh token. Marius From torsten@lodderstedt.net Mon Dec 13 14:07: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 7D5B73A6D44 for ; Mon, 13 Dec 2010 14:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 wJ12b+QXSIeC for ; Mon, 13 Dec 2010 14:07:31 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by core3.amsl.com (Postfix) with ESMTP id 986E93A6D3F for ; Mon, 13 Dec 2010 14:07:31 -0800 (PST) Received: from [79.253.50.128] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PSGZw-0004yr-Ls; Mon, 13 Dec 2010 23:09:08 +0100 Message-ID: <4D069988.2000806@lodderstedt.net> Date: Mon, 13 Dec 2010 23:09:12 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marius Scurtescu References: <4D066D50.6000105@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Comments on core draft -11 X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Dec 2010 22:07:32 -0000 Am 13.12.2010 22:27, schrieb Marius Scurtescu: > On Mon, Dec 13, 2010 at 11:00 AM, Torsten Lodderstedt > wrote: >> section 5.2 >> The authorization server SHOULD NOT issue a refresh token when the access >> grant type is an assertion or a set of client credentials. >> >> How shall the server determine whether to issue refresh tokens in case of >> grant type Resource Owner Password Credentials? In contrast to >> authorization code, the user is not directly involved in the interaction >> with the authorization server. > Not directly, but the user did provide the credentials. In this case > the only long term credentials the client has are the end user > credentials, the server better issue a refresh token so the client is > not forced to store the user credentials, right? Agreed, it's better to store a refresh token than username/password. But that's not my point. The user gave the client his credentials, which is a user consent somehow. But the user does not necessarily want to stay logged in (i.e. he didn't disabled the respective checkbox). That's why I think we need a way to signal this distinction to the authorization server. So the server does not need to create a refresh token, which is useless. If you have a more generic proposal, that's fine with me. regards, Torsten. From bcampbell@pingidentity.com Mon Dec 13 14:52: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 B224A28C111 for ; Mon, 13 Dec 2010 14:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eqjkpWbTchJ6 for ; Mon, 13 Dec 2010 14:52:17 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with ESMTP id 2385228C112 for ; Mon, 13 Dec 2010 14:52:16 -0800 (PST) Received: from source ([209.85.215.178]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTQakAxEHC94NBpesQkOGLLWDavTMziKJ@postini.com; Mon, 13 Dec 2010 14:53:56 PST Received: by mail-ey0-f178.google.com with SMTP id 5so182eyh.37 for ; Mon, 13 Dec 2010 14:53:55 -0800 (PST) Received: by 10.213.35.208 with SMTP id q16mr17675ebd.24.1292280833270; Mon, 13 Dec 2010 14:53:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.10.1 with HTTP; Mon, 13 Dec 2010 14:53:23 -0800 (PST) In-Reply-To: References: <20101213221033.77C333A6D3F@core3.amsl.com> From: Brian Campbell Date: Mon, 13 Dec 2010 15:53:23 -0700 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Dec 2010 22:52:18 -0000 Draft -01 of "SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0" is now available at http://www.ietf.org/id/draft-campbell-oauth-saml-01.txt The changes (change log pasted blow) are mostly responding to feedback from this WG and from the SSTC as well as bringing it up to date with draft-ietf-oauth-v2-11. The one change that was previously discussed on this list that I didn't incorporate into the draft, and I'm still somewhat on the fence about, is allowing for more than one assertion. Comments and questions are welcome as always. Thanks, Brian -01 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes from -10 to -11. o Updated examples. o Relaxed processing rules to allow for more than one SubjectConfirmation element. o Removed the 'MUST NOT contain a NotBefore attribute' on SubjectConfirmationData. o Relaxed wording that ties the subject of the Assertion to the resource owner. o Added some wording about identifying the client when the subject hasn't directly authenticated including an informative reference to SAML V2.0 Condition for Delegation Restriction. o Added a few examples to the language about verifying that the Assertion is valid in all other respects. o Added some wording to the introduction about the similarities to Web SSO in the format and processing rules o Changed the grant_type (was assertion_type) URI from http://oauth.net/assertion_type/saml/2.0/bearer to http://oauth.net/grant_type/assertion/saml/2.0/bearer o Changed title to include "Grant Type" in it. o Editorial updates based on feedback from the WG and others (including capitalization of Assertion when referring to SAML). ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Dec 13, 2010 at 3:10 PM Subject: New Version Notification for draft-campbell-oauth-saml-01 A new version of I-D, draft-campbell-oauth-saml-01.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-campbell-oauth-saml Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 SAML 2.0 Bearer Assertion Grant Type Profile for= OAuth 2.0 Creation_date: =A0 2010-12-13 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 11 Abstract: This specification defines the use of a SAML 2.0 bearer Assertion as means for requesting an OAuth 2.0 access token. The IETF Secretariat. From eran@hueniverse.com Mon Dec 13 19:18: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 DC1173A6D9B for ; Mon, 13 Dec 2010 19:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 EAxvIXiB2a1D for ; Mon, 13 Dec 2010 19:18:34 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5C1A93A6E37 for ; Mon, 13 Dec 2010 19:18:34 -0800 (PST) Received: (qmail 32755 invoked from network); 14 Dec 2010 03:19:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Dec 2010 03:19:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 13 Dec 2010 20:19:44 -0700 From: Eran Hammer-Lahav To: Brian Campbell , oauth Date: Mon, 13 Dec 2010 20:19:25 -0700 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 Thread-Index: AcubGMvr/JpOnVmyQsWACuHOZ+xXrAAJNRHA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20101213221033.77C333A6D3F@core3.amsl.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 03:18:36 -0000 I think the 'assertion' parameter should be moved into this draft and defin= ed there. This will also facilitate its proper definition and status (requi= red, singular, etc.). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Campbell > Sent: Monday, December 13, 2010 2:53 PM > To: oauth > Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell- > oauth-saml-01 >=20 > Draft -01 of "SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0"= is > now available at http://www.ietf.org/id/draft-campbell-oauth-saml-01.txt >=20 > The changes (change log pasted blow) are mostly responding to feedback > from this WG and from the SSTC as well as bringing it up to date with dra= ft- > ietf-oauth-v2-11. The one change that was previously discussed on this l= ist > that I didn't incorporate into the draft, and I'm still somewhat on the f= ence > about, is allowing for more than one assertion. >=20 > Comments and questions are welcome as always. >=20 > Thanks, > Brian >=20 > -01 >=20 > o Updated to reference draft-ietf-oauth-v2-11 and reflect changes > from -10 to -11. >=20 > o Updated examples. >=20 > o Relaxed processing rules to allow for more than one > SubjectConfirmation element. >=20 > o Removed the 'MUST NOT contain a NotBefore attribute' on > SubjectConfirmationData. >=20 > o Relaxed wording that ties the subject of the Assertion to the > resource owner. >=20 > o Added some wording about identifying the client when the subject > hasn't directly authenticated including an informative reference > to SAML V2.0 Condition for Delegation Restriction. >=20 > o Added a few examples to the language about verifying that the > Assertion is valid in all other respects. >=20 > o Added some wording to the introduction about the similarities to > Web SSO in the format and processing rules >=20 > o Changed the grant_type (was assertion_type) URI from > http://oauth.net/assertion_type/saml/2.0/bearer to > http://oauth.net/grant_type/assertion/saml/2.0/bearer >=20 > o Changed title to include "Grant Type" in it. >=20 > o Editorial updates based on feedback from the WG and others > (including capitalization of Assertion when referring to SAML). >=20 >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool > Date: Mon, Dec 13, 2010 at 3:10 PM > Subject: New Version Notification for draft-campbell-oauth-saml-01 >=20 > A new version of I-D, draft-campbell-oauth-saml-01.txt has been successfu= lly > submitted by Brian Campbell and posted to the IETF repository. >=20 > Filename: =A0 =A0 =A0 =A0draft-campbell-oauth-saml > Revision: =A0 =A0 =A0 =A001 > Title: =A0 =A0 =A0 =A0 =A0 SAML 2.0 Bearer Assertion Grant Type Profile f= or OAuth 2.0 > Creation_date: =A0 2010-12-13 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 11 >=20 > Abstract: > This specification defines the use of a SAML 2.0 bearer Assertion as mean= s > for requesting an OAuth 2.0 access token. >=20 >=20 >=20 > The IETF Secretariat. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Dec 14 08:05: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 332843A6EA4 for ; Tue, 14 Dec 2010 08:05:15 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9IQIts4AZSa for ; Tue, 14 Dec 2010 08:05:14 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by core3.amsl.com (Postfix) with ESMTP id 573C53A6E9E for ; Tue, 14 Dec 2010 08:05:12 -0800 (PST) Received: from [80.187.101.33] (helo=[10.220.214.161]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1PSXOs-0007bt-VW; Tue, 14 Dec 2010 17:06:51 +0100 References: <20101213221033.77C333A6D3F@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <86C32B7E-1233-496C-8F74-490287251C16@lodderstedt.net> X-Mailer: iPhone Mail (8B117) From: Torsten Lodderstedt Date: Tue, 14 Dec 2010 17:05:50 +0100 To: Eran Hammer-Lahav X-Df-Sender: 141509 Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 16:05:15 -0000 +1 Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav : > I think the 'assertion' parameter should be moved into this draft and defi= ned there. This will also facilitate its proper definition and status (requi= red, singular, etc.). >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Campbell >> Sent: Monday, December 13, 2010 2:53 PM >> To: oauth >> Subject: [OAUTH-WG] Fwd: New Version Notification for draft-campbell- >> oauth-saml-01 >>=20 >> Draft -01 of "SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0"= is >> now available at http://www.ietf.org/id/draft-campbell-oauth-saml-01.txt >>=20 >> The changes (change log pasted blow) are mostly responding to feedback >> from this WG and from the SSTC as well as bringing it up to date with dra= ft- >> ietf-oauth-v2-11. The one change that was previously discussed on this l= ist >> that I didn't incorporate into the draft, and I'm still somewhat on the f= ence >> about, is allowing for more than one assertion. >>=20 >> Comments and questions are welcome as always. >>=20 >> Thanks, >> Brian >>=20 >> -01 >>=20 >> o Updated to reference draft-ietf-oauth-v2-11 and reflect changes >> from -10 to -11. >>=20 >> o Updated examples. >>=20 >> o Relaxed processing rules to allow for more than one >> SubjectConfirmation element. >>=20 >> o Removed the 'MUST NOT contain a NotBefore attribute' on >> SubjectConfirmationData. >>=20 >> o Relaxed wording that ties the subject of the Assertion to the >> resource owner. >>=20 >> o Added some wording about identifying the client when the subject >> hasn't directly authenticated including an informative reference >> to SAML V2.0 Condition for Delegation Restriction. >>=20 >> o Added a few examples to the language about verifying that the >> Assertion is valid in all other respects. >>=20 >> o Added some wording to the introduction about the similarities to >> Web SSO in the format and processing rules >>=20 >> o Changed the grant_type (was assertion_type) URI from >> http://oauth.net/assertion_type/saml/2.0/bearer to >> http://oauth.net/grant_type/assertion/saml/2.0/bearer >>=20 >> o Changed title to include "Grant Type" in it. >>=20 >> o Editorial updates based on feedback from the WG and others >> (including capitalization of Assertion when referring to SAML). >>=20 >>=20 >>=20 >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: IETF I-D Submission Tool >> Date: Mon, Dec 13, 2010 at 3:10 PM >> Subject: New Version Notification for draft-campbell-oauth-saml-01 >>=20 >> A new version of I-D, draft-campbell-oauth-saml-01.txt has been successfu= lly >> submitted by Brian Campbell and posted to the IETF repository. >>=20 >> Filename: draft-campbell-oauth-saml >> Revision: 01 >> Title: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2= .0 >> Creation_date: 2010-12-13 >> WG ID: Independent Submission >> Number_of_pages: 11 >>=20 >> Abstract: >> This specification defines the use of a SAML 2.0 bearer Assertion as mean= s >> for requesting an OAuth 2.0 access token. >>=20 >>=20 >>=20 >> The IETF Secretariat. >> _______________________________________________ >> 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 bcampbell@pingidentity.com Tue Dec 14 08:09: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 3FE0B3A6F9B for ; Tue, 14 Dec 2010 08:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3grEIhQEPpIC for ; Tue, 14 Dec 2010 08:09:38 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 12D123A6EAE for ; Tue, 14 Dec 2010 08:09:37 -0800 (PST) Received: from source ([209.85.215.49]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTQeXJUt+qXHC0uxpa0DiYZMOZ2BFq8Ya@postini.com; Tue, 14 Dec 2010 08:11:19 PST Received: by mail-ew0-f49.google.com with SMTP id 20so513845ewy.8 for ; Tue, 14 Dec 2010 08:11:17 -0800 (PST) Received: by 10.223.86.16 with SMTP id q16mr5979539fal.58.1292343077598; Tue, 14 Dec 2010 08:11:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.9 with HTTP; Tue, 14 Dec 2010 08:10:47 -0800 (PST) In-Reply-To: <86C32B7E-1233-496C-8F74-490287251C16@lodderstedt.net> References: <20101213221033.77C333A6D3F@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <86C32B7E-1233-496C-8F74-490287251C16@lodderstedt.net> From: Brian Campbell Date: Tue, 14 Dec 2010 09:10:47 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 16:09:39 -0000 Future revisions of this SAML draft will build off whatever assertion/extension mechanism is provided by the core framework spec. However, some compelling reasons were previously given for keeping the 'assertion' (one thread on the topic: http://www.ietf.org/mail-archive/web/oauth/current/msg04401.html) parameter in core. Has the thinking on that changed? On Tue, Dec 14, 2010 at 9:05 AM, Torsten Lodderstedt wrote: > +1 > > > > Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav : > >> I think the 'assertion' parameter should be moved into this draft and defined there. This will also facilitate its proper definition and status (required, singular, etc.). >> >> EHL >> From eran@hueniverse.com Tue Dec 14 08: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 BF8F23A6EA9 for ; Tue, 14 Dec 2010 08:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 XRhHVLHHRVY2 for ; Tue, 14 Dec 2010 08:40:23 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 613173A6FB4 for ; Tue, 14 Dec 2010 08:40:23 -0800 (PST) Received: (qmail 4040 invoked from network); 14 Dec 2010 16:23:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Dec 2010 16:23:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 14 Dec 2010 09:23:53 -0700 From: Eran Hammer-Lahav To: Brian Campbell , Torsten Lodderstedt Date: Tue, 14 Dec 2010 09:23:33 -0700 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 Thread-Index: AcubqiouxLsWe+ETSQuq9BuFt4RkkwAAGLXQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723441191F387A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20101213221033.77C333A6D3F@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <86C32B7E-1233-496C-8F74-490287251C16@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 Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 16:40:24 -0000 Torsten made a good argument that now that we combined assertions and exten= sions into a single mechanism, it does not make sense to make the 'assertio= n' parameter required, and that some extensions will be confusing with such= a parameter name. In addition, the recent document split demoted this spec= ification from 'core' to 'framework' which is more friendly to extensions a= nd companion specifications. I would suggest we drop the assertion parameter from the spec, but add a di= rectly reference to the SAML assertion specification and give an example sh= owing the parameter. This will remove the normative language (which really = doesn't belong there - something I've long maintained), but will keep the S= AML assertion option on equal ground (directly demonstrated in the spec). A= fter all, you can't implement assertions just by reading the framework spec= , you still need the SAML work. This will require moving the SAML into a WG item (not a must but best) whic= h I am supportive of and would like to see happen quickly (in a few days). Thoughts? EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Tuesday, December 14, 2010 8:11 AM > To: Torsten Lodderstedt > Cc: Eran Hammer-Lahav; oauth > Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell- > oauth-saml-01 >=20 > Future revisions of this SAML draft will build off whatever > assertion/extension mechanism is provided by the core framework spec. > However, some compelling reasons were previously given for keeping the > 'assertion' (one thread on the topic: > http://www.ietf.org/mail-archive/web/oauth/current/msg04401.html) > parameter in core. Has the thinking on that changed? >=20 > On Tue, Dec 14, 2010 at 9:05 AM, Torsten Lodderstedt > wrote: > > +1 > > > > > > > > Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav > : > > > >> I think the 'assertion' parameter should be moved into this draft and > defined there. This will also facilitate its proper definition and status > (required, singular, etc.). > >> > >> EHL > >> From bcampbell@pingidentity.com Tue Dec 14 10:17: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 F27EA3A6FBA for ; Tue, 14 Dec 2010 10:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 uyAHkaz0Ao0d for ; Tue, 14 Dec 2010 10:17:16 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 6330C3A6EBA for ; Tue, 14 Dec 2010 10:17:16 -0800 (PST) Received: from source ([209.85.161.43]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTQe1EKb+srIkDQj81YyTpDxkwLUyeCWh@postini.com; Tue, 14 Dec 2010 10:18:57 PST Received: by fxm18 with SMTP id 18so1011325fxm.16 for ; Tue, 14 Dec 2010 10:18:55 -0800 (PST) Received: by 10.223.93.137 with SMTP id v9mr6111674fam.77.1292350734787; Tue, 14 Dec 2010 10:18:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.9 with HTTP; Tue, 14 Dec 2010 10:18:24 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723441191F387A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20101213221033.77C333A6D3F@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <86C32B7E-1233-496C-8F74-490287251C16@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723441191F387A@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Tue, 14 Dec 2010 11:18:24 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 18:17:18 -0000 I don't have any objection to it and think it's probably cleaner. Previously I'd informally asked that the SAML profile be considered a WG item and I don't think there was any objection. What needs to be done to make that happen? If you/we take this approach, what else will you need from me? On Tue, Dec 14, 2010 at 9:23 AM, Eran Hammer-Lahav wr= ote: > Torsten made a good argument that now that we combined assertions and ext= ensions into a single mechanism, it does not make sense to make the 'assert= ion' parameter required, and that some extensions will be confusing with su= ch a parameter name. In addition, the recent document split demoted this sp= ecification from 'core' to 'framework' which is more friendly to extensions= and companion specifications. > > I would suggest we drop the assertion parameter from the spec, but add a = directly reference to the SAML assertion specification and give an example = showing the parameter. This will remove the normative language (which reall= y doesn't belong there - something I've long maintained), but will keep the= SAML assertion option on equal ground (directly demonstrated in the spec).= After all, you can't implement assertions just by reading the framework sp= ec, you still need the SAML work. > > This will require moving the SAML into a WG item (not a must but best) wh= ich I am supportive of and would like to see happen quickly (in a few days)= . > > Thoughts? > > EHL > >> -----Original Message----- >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> Sent: Tuesday, December 14, 2010 8:11 AM >> To: Torsten Lodderstedt >> Cc: Eran Hammer-Lahav; oauth >> Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell= - >> oauth-saml-01 >> >> Future revisions of this SAML draft will build off whatever >> assertion/extension mechanism is provided by the core framework spec. >> However, some compelling reasons were previously given for keeping the >> 'assertion' (one thread on the topic: >> http://www.ietf.org/mail-archive/web/oauth/current/msg04401.html) >> parameter in core. =A0Has the thinking on that changed? >> >> On Tue, Dec 14, 2010 at 9:05 AM, Torsten Lodderstedt >> wrote: >> > +1 >> > >> > >> > >> > Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav >> : >> > >> >> I think the 'assertion' parameter should be moved into this draft and >> defined there. This will also facilitate its proper definition and statu= s >> (required, singular, etc.). >> >> >> >> EHL >> >> > From pjwalker@gmail.com Tue Dec 14 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 9D00928C11B for ; Tue, 14 Dec 2010 13:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VexN5hWsKSbO for ; Tue, 14 Dec 2010 13:12:23 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id BFC5A28C115 for ; Tue, 14 Dec 2010 13:12:23 -0800 (PST) Received: by pvc21 with SMTP id 21so237410pvc.31 for ; Tue, 14 Dec 2010 13:14:04 -0800 (PST) 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=NnXVriL6xSHgMlWOvc1moJmDcSlCPuyz6yB0vxy1KHc=; b=kiCCT7ECfY3f21yp9VUV0GShy4dnBs1O8LLYRWkEO6dGcj0eCONNfltOFw2mLUeeMg T8GWKF1qHPitUElWbS9khdLiRYFzF3qaTwed+g/P4iVEnfjhN0aw8xPRJTXnru5lvuuY 4X/wIPmQ+9Q7amHIZgxSr8gtoppJ5fNluqz+M= 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=NFINbxyddvuWPVQdezI1+htCg4Kuq+oLLtRZOvjVX4Up1wC1f6gkkgueOgDOysP5// LsdoypNBFZW53fBV8KEHEexmAx/X0lS32WOPzRweGyMluN1JoBj+krLr8rgOWFQtXdoR m3MvBvgytoVW8c8dgljutc6BfngabgYlDaTEY= Received: by 10.142.128.12 with SMTP id a12mr4913272wfd.60.1292361244558; Tue, 14 Dec 2010 13:14:04 -0800 (PST) Received: from paul-lan.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id w14sm580997wfd.18.2010.12.14.13.14.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 13:14:03 -0800 (PST) From: Paul Walker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Dec 2010 13:14:01 -0800 Message-Id: To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 14 Dec 2010 13:16:12 -0800 Subject: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 21:13:14 -0000 Has there been discussion of using expires_at as an exact epoch time in = seconds as opposed to expires_in which is, at best, an approximation = "from the time the response was generated by the authorization server?" = I apologize if this has been discussed previously. ~pj= From jbhate@exacttarget.com Tue Dec 14 13:22: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 C071E28C13B for ; Tue, 14 Dec 2010 13:22:29 -0800 (PST) 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 hyqNTggZcuW6 for ; Tue, 14 Dec 2010 13:22:28 -0800 (PST) Received: from hub02.exacttarget.com (hub02.exacttarget.com [207.67.98.220]) by core3.amsl.com (Postfix) with ESMTP id 32B2328C136 for ; Tue, 14 Dec 2010 13:22:28 -0800 (PST) From: Jitesh Bhate To: Paul Walker , OAuth WG Date: Tue, 14 Dec 2010 16:24:27 -0500 Thread-Topic: [OAUTH-WG] expires_at vs expires_in Thread-Index: Acub1GSx5VUoxxVbTPm3aiY5/d+WgQAAMtiw 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] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 21:22:29 -0000 I have same question, Thanks Paul for Raising this Regards Jitesh -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Walker Sent: Tuesday, December 14, 2010 4:14 PM To: OAuth WG Subject: [OAUTH-WG] expires_at vs expires_in Has there been discussion of using expires_at as an exact epoch time in sec= onds as opposed to expires_in which is, at best, an approximation "from the= time the response was generated by the authorization server?" I apologize= if this has been discussed previously. ~pj _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Dec 14 13:33: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 00DDA28C115 for ; Tue, 14 Dec 2010 13:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.917 X-Spam-Level: X-Spam-Status: No, score=-109.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 YVvVoLS58ZFa for ; Tue, 14 Dec 2010 13:33:55 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id F297828C100 for ; Tue, 14 Dec 2010 13:33:54 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id oBELZYST003627 for ; Tue, 14 Dec 2010 13:35:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292362535; bh=vjkLNWMSkr+3DP1sbR3zk7l20Tc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=vYbku4iatjE0dYqBfceU6T0owjbawmkP+SlbEQOjt9ZbpjQoEy+VF8i7EHBnGKJlE NrrcN3L+DfcV516ab6RtA== Received: from ywf7 (ywf7.prod.google.com [10.192.6.7]) by kpbe14.cbf.corp.google.com with ESMTP id oBELZWL3009203 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 14 Dec 2010 13:35:33 -0800 Received: by ywf7 with SMTP id 7so705943ywf.36 for ; Tue, 14 Dec 2010 13:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=s1PVlB2ANmXpF+kNiZotdVWrn4N1xr4oFIGC6rWwCn0=; b=jkTzqaP+azZ3zj7QUp2dd/Mye2m2qNZy25m2tEhrtRR8n5qZzHTYMVE/7MhntjCAEH OajflUNSAXWRPzedi6IQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=iBUN0KaUTJO6+V4yvNV5AtRlNGsQb1JkRLuHsTbcJVjPgk1aERuKjIJRb7WSLrlA/g D9PjYRr0VeLwZrvCeqWQ== Received: by 10.100.127.7 with SMTP id z7mr3935025anc.156.1292362532429; Tue, 14 Dec 2010 13:35:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Tue, 14 Dec 2010 13:35:12 -0800 (PST) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 14 Dec 2010 13:35:12 -0800 Message-ID: To: Jitesh Bhate Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 21:33:56 -0000 expires_at requires very good time synchronization for all machines involve= d. expires_in, while not very exact, is more resilient. Marius On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate wrot= e: > I have same question, Thanks Paul for Raising this > > Regards > Jitesh > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Paul Walker > Sent: Tuesday, December 14, 2010 4:14 PM > To: OAuth WG > Subject: [OAUTH-WG] expires_at vs expires_in > > Has there been discussion of using expires_at as an exact epoch time in s= econds as opposed to expires_in which is, at best, an approximation "from t= he time the response was generated by the authorization server?" =A0I apolo= gize if this has been discussed previously. > > ~pj > _______________________________________________ > 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 jbhate@exacttarget.com Tue Dec 14 13: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 BC55C28C138 for ; Tue, 14 Dec 2010 13:50:13 -0800 (PST) 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 dz1mV8iXlsO6 for ; Tue, 14 Dec 2010 13:50:11 -0800 (PST) Received: from hub02.exacttarget.com (hub02.exacttarget.com [207.67.98.220]) by core3.amsl.com (Postfix) with ESMTP id D65C928C130 for ; Tue, 14 Dec 2010 13:50:07 -0800 (PST) From: Jitesh Bhate To: "OAuth@ietf.org" Date: Tue, 14 Dec 2010 16:52:08 -0500 Thread-Topic: OAuth 2.0 does not require parameter name oauth_token= while passing in authorization header Thread-Index: Acub2SdRvfvjtf+iRL690L+KREKH1w== Message-ID: 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_A72BD02C502A0F48AFA56C4A84CB23E5467701EFB5ETINMBCLUSTER_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 does not require parameter name oauth_token= while passing in authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 21:50:13 -0000 --_000_A72BD02C502A0F48AFA56C4A84CB23E5467701EFB5ETINMBCLUSTER_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While Integrating our Apis WITH CoTweet library We found that OAuth 2.0 has changed (from oauth 1.0) the way Oauth token is= passed in authorization header. OAuth 2.0 does not require the oauth_token=3D while passing in authorization header http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.1.1 shouldn't following request 1) is more easy to parse as key value pairs tha= n 2) ??? 1) GET /resource HTTP/1.1 Host: server.example.com Authorization: OAuth oauth_token=3DvF9dft4qmT 2) GET /resource HTTP/1.1 Host: server.example.com Authorization: OAuth vF9dft4qmT --_000_A72BD02C502A0F48AFA56C4A84CB23E5467701EFB5ETINMBCLUSTER_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While Integra= ting our Apis WITH CoTweet library

W= e found that OAuth 2.0 has changed (from oauth 1.0) the way Oauth token is = passed in authorization header.

=  

OAuth 2.0 does not

<= p class=3DMsoPlainText>require the oauth_token=3D while passing in authoriz= ation header

http://tools.ietf.org/= html/draft-ietf-oauth-v2-10#section-5.1.1

 

 

shouldn’t following request 1) is more easy to pars= e as key value pairs than 2) ???

 

1)

GET /resource HTTP/1.1

Host: ser= ver.example.com

Authorization: OAuth = oauth_token= =3DvF9dft4qmT

 

2)

GET /resource HTTP/1.1=

     Host: server.example.com

     Authorization: OAuth vF9dft4qmT

 

= --_000_A72BD02C502A0F48AFA56C4A84CB23E5467701EFB5ETINMBCLUSTER_-- From mscurtescu@google.com Tue Dec 14 13:53: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 85D4828C130 for ; Tue, 14 Dec 2010 13:53:13 -0800 (PST) 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 sgex9Nm2DWcc for ; Tue, 14 Dec 2010 13:53:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7393E28C13F for ; Tue, 14 Dec 2010 13:53:12 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id oBELsrDm024201 for ; Tue, 14 Dec 2010 13:54:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292363693; bh=KAsYcZZvYXHQRxt0g6987HjzlUQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=f9smnHjzha1MzhplP13NjO26mcrrbu3lHpoKNmU9RqP1ScgC8Dn9N1M/WkRYsQ9Co VNlqV2Iu3irg26cSvlWeg== Received: from gyd12 (gyd12.prod.google.com [10.243.49.204]) by wpaz29.hot.corp.google.com with ESMTP id oBELsp9K031284 for ; Tue, 14 Dec 2010 13:54:52 -0800 Received: by gyd12 with SMTP id 12so681580gyd.3 for ; Tue, 14 Dec 2010 13:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Xn3NWn1ZPKZwIq+QKOV4rSVStjEcXsfIJ8TNB+8C3pk=; b=i5CeqIOZ6QoAhcE7ZqkG2J0/ZGSol9KV0coXrEPhNcxjFfZ1z8tfWNlXn5UaSNlbNC WvgzTekKT/RynuVTsQKQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=KLPw099UjunTb9GFL8zDt6m0ojItxGU5znSwHx74orX2gMRmkKxVVi3U3JYSrQYkzK CaRpfnB7DIOirSr33oFw== Received: by 10.100.96.5 with SMTP id t5mr3932898anb.258.1292363690216; Tue, 14 Dec 2010 13:54:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Tue, 14 Dec 2010 13:54:30 -0800 (PST) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 14 Dec 2010 13:54:30 -0800 Message-ID: To: Jitesh Bhate Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 does not require parameter name oauth_token= while passing in authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 21:53:13 -0000 I tend to agree. Check the archives, there are recent discussions on this subject. The exact format of the Authorization header is still debated, including the scheme. Marius On Tue, Dec 14, 2010 at 1:52 PM, Jitesh Bhate wrot= e: > While Integrating our Apis WITH CoTweet library > > We found that OAuth 2.0 has changed (from oauth 1.0) the way Oauth token = is > passed in authorization header. > > > > OAuth 2.0 does not > > require the oauth_token=3D while passing in authorization header > > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.1.1 > > > > > > shouldn=92t following request 1) is more easy to parse as key value pairs= than > 2) ??? > > > > 1) > > GET /resource HTTP/1.1 > > Host: server.example.com > > Authorization: OAuth oauth_token=3DvF9dft4qmT > > > > 2) > > GET /resource HTTP/1.1 > > =A0=A0=A0=A0 Host: server.example.com > > =A0=A0=A0=A0 Authorization: OAuth vF9dft4qmT > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From jbhate@exacttarget.com Tue Dec 14 14:09: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 8AE3A3A6ECA for ; Tue, 14 Dec 2010 14:09:03 -0800 (PST) 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 o0o+yVSOD9rZ for ; Tue, 14 Dec 2010 14:09:02 -0800 (PST) Received: from hub01.exacttarget.com (hub01.exacttarget.com [207.67.98.219]) by core3.amsl.com (Postfix) with ESMTP id 185D03A6EC9 for ; Tue, 14 Dec 2010 14:09:02 -0800 (PST) From: Jitesh Bhate To: Marius Scurtescu Date: Tue, 14 Dec 2010 17:11:01 -0500 Thread-Topic: [OAUTH-WG] OAuth 2.0 does not require parameter name oauth_token= while passing in authorization header Thread-Index: Acub2YwupyjCOPvoQiuWud+vOulnQAAAi0Hw 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 does not require parameter name oauth_token= while passing in authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 22:09:03 -0000 Thanks for your Response I think I got one thread in archive=20 http://www.ietf.org/mail-archive/web/oauth/current/msg04673.html -----Original Message----- From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 Sent: Tuesday, December 14, 2010 4:55 PM To: Jitesh Bhate Cc: OAuth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 does not require parameter name oauth_tok= en=3D while passing in authorization header I tend to agree. Check the archives, there are recent discussions on this subject. The exact format of the Authorization header is still debated, including the scheme. Marius On Tue, Dec 14, 2010 at 1:52 PM, Jitesh Bhate wrot= e: > While Integrating our Apis WITH CoTweet library > > We found that OAuth 2.0 has changed (from oauth 1.0) the way Oauth token = is > passed in authorization header. > > > > OAuth 2.0 does not > > require the oauth_token=3D while passing in authorization header > > http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.1.1 > > > > > > shouldn't following request 1) is more easy to parse as key value pairs t= han > 2) ??? > > > > 1) > > GET /resource HTTP/1.1 > > Host: server.example.com > > Authorization: OAuth oauth_token=3DvF9dft4qmT > > > > 2) > > GET /resource HTTP/1.1 > > =A0=A0=A0=A0 Host: server.example.com > > =A0=A0=A0=A0 Authorization: OAuth vF9dft4qmT > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From mscurtescu@google.com Tue Dec 14 14:30: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 2429528C0E6 for ; Tue, 14 Dec 2010 14:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.934 X-Spam-Level: X-Spam-Status: No, score=-105.934 tagged_above=-999 required=5 tests=[AWL=0.043, 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 9DLJ+hG4wI9l for ; Tue, 14 Dec 2010 14:30:57 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3ACFC3A683E for ; Tue, 14 Dec 2010 14:30:56 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id oBEMWbI6015472 for ; Tue, 14 Dec 2010 14:32:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292365957; bh=TAz+6T24HaaFulxjA0JbPQ1r/lE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=utQXjiDaZVnh3y6P/gtSKnjReldpLCorEZ6k9FPunipGAgTRvjYAuKMWwelRloXSf t7BgWNqci3i7O6xojOhLw== Received: from gxk5 (gxk5.prod.google.com [10.202.11.5]) by hpaq12.eem.corp.google.com with ESMTP id oBEMWZPk004188 for ; Tue, 14 Dec 2010 14:32:36 -0800 Received: by gxk5 with SMTP id 5so840287gxk.28 for ; Tue, 14 Dec 2010 14:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=fr6ulfqjoLSWqax5kAYjhEqRigXQojQvNSR8r1nHi84=; b=mNOvrG+ziSCqaEx3NqVBDCriHz2L+7D8gxHZb9vxoXKgtU9sCmP+3ep+fcpf1qstOa Xp0TnNGaU9P4Mtt20SUg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ES2s8WniN5JeDSfbQQAo5boGL/UNx0DjKJtStYNoTq7Tbb2ZkD3EpZN4ej/J1eEe8H wcgRVatEjnhsIfS9M+zA== Received: by 10.100.194.6 with SMTP id r6mr3974193anf.122.1292365954915; Tue, 14 Dec 2010 14:32:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Tue, 14 Dec 2010 14:32:14 -0800 (PST) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 14 Dec 2010 14:32:14 -0800 Message-ID: To: Jitesh Bhate 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] OAuth 2.0 does not require parameter name oauth_token= while passing in authorization header X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 22:30:58 -0000 Also look for the thread with subject "OAuth 2.0 Bearer Token specification draft -01". Marius On Tue, Dec 14, 2010 at 2:11 PM, Jitesh Bhate wrot= e: > Thanks for your Response > I think I got one thread in archive > http://www.ietf.org/mail-archive/web/oauth/current/msg04673.html > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, December 14, 2010 4:55 PM > To: Jitesh Bhate > Cc: OAuth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 does not require parameter name oauth_t= oken=3D while passing in authorization header > > I tend to agree. > > Check the archives, there are recent discussions on this subject. The > exact format of the Authorization header is still debated, including > the scheme. > > Marius > > > > On Tue, Dec 14, 2010 at 1:52 PM, Jitesh Bhate wr= ote: >> While Integrating our Apis WITH CoTweet library >> >> We found that OAuth 2.0 has changed (from oauth 1.0) the way Oauth token= is >> passed in authorization header. >> >> >> >> OAuth 2.0 does not >> >> require the oauth_token=3D while passing in authorization header >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.1.1 >> >> >> >> >> >> shouldn't following request 1) is more easy to parse as key value pairs = than >> 2) ??? >> >> >> >> 1) >> >> GET /resource HTTP/1.1 >> >> Host: server.example.com >> >> Authorization: OAuth oauth_token=3DvF9dft4qmT >> >> >> >> 2) >> >> GET /resource HTTP/1.1 >> >> =A0=A0=A0=A0 Host: server.example.com >> >> =A0=A0=A0=A0 Authorization: OAuth vF9dft4qmT >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > From pjwalker@gmail.com Tue Dec 14 14:52: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 12C4C28C13F for ; Tue, 14 Dec 2010 14:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, 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 s4196oWBNjy0 for ; Tue, 14 Dec 2010 14:52:29 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 9A21F28C115 for ; Tue, 14 Dec 2010 14:52:29 -0800 (PST) Received: by pvc21 with SMTP id 21so254090pvc.31 for ; Tue, 14 Dec 2010 14:54:10 -0800 (PST) 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=CFiDmJwZvKH0PLoUSLU82zA4Mjc7i4GcECSjoujuDVQ=; b=bq+J1QDuFF9anxS/ZW+O9oZMTDM0XDOw+bjiVfgW48dMadjR1tiUMhD4vX23BGFwf4 YJseoEogt29TuLKWeHywVHMjTGajprcgM/lglUmQnElbdE/LJqmVk/Cj0HMITKYb3SkE vqZZmRr4gQTCg4ST9W0oB8gQzBQRcvS+ScEss= 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=GDi8olk0rAI1dMYd4xTxV7aO/7EofT0eisbz186V8ans2ihUtJ/fpds8Fybqvnan6w GjVaMtQTli4j6TlsQn6PxzVrMwIPtoAfy1fnzsvErLrdTxnJnKsAwkr2NKZ1LMXmUaGe Ql9fENa4D43LL//EhD6EO8sVx9v3U3L+ZpDxs= Received: by 10.142.88.18 with SMTP id l18mr4948884wfb.338.1292367248966; Tue, 14 Dec 2010 14:54:08 -0800 (PST) Received: from paul-lan.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id v19sm697003wfh.0.2010.12.14.14.54.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 14:54:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Walker In-Reply-To: Date: Tue, 14 Dec 2010 14:54:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 22:52:38 -0000 It seems to me that expires_in suffers from the same machine time = synchronization issue and additionally throws in an indeterminable time = amount, while expires_at would only suffer from the former.=20 ~pj On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: > expires_at requires very good time synchronization for all machines = involved. >=20 > expires_in, while not very exact, is more resilient. >=20 > Marius >=20 >=20 >=20 > On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate = wrote: >> I have same question, Thanks Paul for Raising this >>=20 >> Regards >> Jitesh >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Paul Walker >> Sent: Tuesday, December 14, 2010 4:14 PM >> To: OAuth WG >> Subject: [OAUTH-WG] expires_at vs expires_in >>=20 >> Has there been discussion of using expires_at as an exact epoch time = in seconds as opposed to expires_in which is, at best, an approximation = "from the time the response was generated by the authorization server?" = I apologize if this has been discussed previously. >>=20 >> ~pj >> _______________________________________________ >> 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 aaron@parecki.com Tue Dec 14 15:21: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 7E38828C115 for ; Tue, 14 Dec 2010 15:21:54 -0800 (PST) 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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 WvLlfAMNTNGt for ; Tue, 14 Dec 2010 15:21:53 -0800 (PST) Received: from mail-bw0-f66.google.com (mail-bw0-f66.google.com [209.85.214.66]) by core3.amsl.com (Postfix) with ESMTP id 7958828C14D for ; Tue, 14 Dec 2010 15:21:52 -0800 (PST) Received: by bwz7 with SMTP id 7so521327bwz.1 for ; Tue, 14 Dec 2010 15:23:32 -0800 (PST) Received: by 10.204.76.145 with SMTP id c17mr6238674bkk.52.1292369010098; Tue, 14 Dec 2010 15:23:30 -0800 (PST) Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by mx.google.com with ESMTPS id v25sm278055bkt.18.2010.12.14.15.23.28 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 15:23:29 -0800 (PST) Received: by fxm18 with SMTP id 18so1357351fxm.16 for ; Tue, 14 Dec 2010 15:23:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.118.136 with SMTP id v8mr2442340faq.90.1292369007906; Tue, 14 Dec 2010 15:23:27 -0800 (PST) Received: by 10.223.103.142 with HTTP; Tue, 14 Dec 2010 15:23:27 -0800 (PST) Received: by 10.223.103.142 with HTTP; Tue, 14 Dec 2010 15:23:27 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Dec 2010 15:23:27 -0800 Message-ID: From: Aaron Parecki To: Paul Walker Content-Type: multipart/alternative; boundary=001636c5b4c2a292020497671bfc Cc: OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 23:21:54 -0000 --001636c5b4c2a292020497671bfc Content-Type: text/plain; charset=UTF-8 Agreed. I like the idea of expires_at as well. One of the first things a client is going to do after receiving the expires_in is calculate the current time plus the offset. Makes sense to eliminate one source of timing errors. On Dec 14, 2010 2:54 PM, "Paul Walker" wrote: > It seems to me that expires_in suffers from the same machine time synchronization issue and additionally throws in an indeterminable time amount, while expires_at would only suffer from the former. > > ~pj > > On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: > >> expires_at requires very good time synchronization for all machines involved. >> >> expires_in, while not very exact, is more resilient. >> >> Marius >> >> >> >> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate wrote: >>> I have same question, Thanks Paul for Raising this >>> >>> Regards >>> Jitesh >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Paul Walker >>> Sent: Tuesday, December 14, 2010 4:14 PM >>> To: OAuth WG >>> Subject: [OAUTH-WG] expires_at vs expires_in >>> >>> Has there been discussion of using expires_at as an exact epoch time in seconds as opposed to expires_in which is, at best, an approximation "from the time the response was generated by the authorization server?" I apologize if this has been discussed previously. >>> >>> ~pj >>> _______________________________________________ >>> 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 --001636c5b4c2a292020497671bfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Agreed. I like the idea of expires_at as well. One of the first things a= client is going to do after receiving the expires_in is calculate the curr= ent time plus the offset. Makes sense to eliminate one source of timing err= ors.

On Dec 14, 2010 2:54 PM, "Paul Walker"= <pjwalker@gmail.com> wrote= :
> It seems to me that expires_in suffers from = the same machine time synchronization issue and additionally throws in an i= ndeterminable time amount, while expires_at would only suffer from the form= er.
>
> ~pj
>
> On Dec 14, 2010, at 1:35 PM, Marius Scur= tescu wrote:
>
>> expires_at requires very good time synchr= onization for all machines involved.
>>
>> expires_in, w= hile not very exact, is more resilient.
>>
>> Marius
>>
>>
>>
>= > On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <jbhate@exacttarget.com> wrote:
>>>= I have same question, Thanks Paul for Raising this
>>>
>>> Regards
>>> Jitesh
>>>= ;
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Paul Walker
>>> Sent: Tuesday, December 14, 2010 4:14 PM
>>> To: O= Auth WG
>>> Subject: [OAUTH-WG] expires_at vs expires_in
>= ;>>
>>> Has there been discussion of using expires_at as= an exact epoch time in seconds as opposed to expires_in which is, at best,= an approximation "from the time the response was generated by the aut= horization server?" I apologize if this has been discussed previously= .
>>>
>>> ~pj
>>> _________________________= ______________________
>>> OAuth mailing list
>>> <= a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org
>>> https://www.ietf.org/mailm= an/listinfo/oauth
>>> _______________________________________________
>>>= ; OAuth mailing list
>>> OAut= h@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>
> ____________________________________________= ___
> OAuth mailing list
> OA= uth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--001636c5b4c2a292020497671bfc-- From lindner@inuus.com Tue Dec 14 15:55: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 595423A6E13 for ; Tue, 14 Dec 2010 15:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 P6g1Zv1284Vi for ; Tue, 14 Dec 2010 15:55:07 -0800 (PST) Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by core3.amsl.com (Postfix) with ESMTP id 7BFB93A6E12 for ; Tue, 14 Dec 2010 15:55:07 -0800 (PST) Received: by fxm18 with SMTP id 18so1380804fxm.16 for ; Tue, 14 Dec 2010 15:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inuus.com; s=google; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hrDLQ2yuDIyLHmY5a9qXgyXkAYp5zcCYjHYii50/UtQ=; b=p4O3ajSsNqoRHGcwxMZkk5tWgJNFrlz9CTKHKj/Y5ZInNuexaSoqRvjgZdaaetQVGw j9TybmiJi0HiKbyoEDcri2ZIqjyH79OT6rBtyFJLcIiUida+lKP1IIeIh2L4JP9gsiRC RC086K9pCxXjK1TosOC1j7tIBB9iMvA8Jr6Ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=inuus.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QhdGZEw00XreF+FeajGzEger8okdDj6uo2eeOGDOt4jQQ1fxpfKezxvv8auC61Mgiz pV/enHC7W6ZBeicolhEQYfyXPeMdRf68KpQhWBoU0pgUu9zcAd7aXM14FOSjzLr/Pr3L zi7OvndCW2hPnTrVpFgYWm0TVxLM2M2Fpc0kk= MIME-Version: 1.0 Received: by 10.223.96.137 with SMTP id h9mr6410624fan.54.1292371007642; Tue, 14 Dec 2010 15:56:47 -0800 (PST) Received: by 10.223.22.146 with HTTP; Tue, 14 Dec 2010 15:56:47 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Dec 2010 15:56:47 -0800 Message-ID: From: Paul Lindner To: Aaron Parecki Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 23:55:09 -0000 For User Agent flow you really really really want expires_in Do you know how many PCs and browsers have their clock set incorrectly? On Tue, Dec 14, 2010 at 3:23 PM, Aaron Parecki wrote: > Agreed. I like the idea of expires_at as well. One of the first things a > client is going to do after receiving the expires_in is calculate the > current time plus the offset. Makes sense to eliminate one source of timi= ng > errors. > > On Dec 14, 2010 2:54 PM, "Paul Walker" wrote: >> It seems to me that expires_in suffers from the same machine time >> synchronization issue and additionally throws in an indeterminable time >> amount, while expires_at would only suffer from the former. >> >> ~pj >> >> On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: >> >>> expires_at requires very good time synchronization for all machines >>> involved. >>> >>> expires_in, while not very exact, is more resilient. >>> >>> Marius >>> >>> >>> >>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate >>> wrote: >>>> I have same question, Thanks Paul for Raising this >>>> >>>> Regards >>>> Jitesh >>>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>>> Of Paul Walker >>>> Sent: Tuesday, December 14, 2010 4:14 PM >>>> To: OAuth WG >>>> Subject: [OAUTH-WG] expires_at vs expires_in >>>> >>>> Has there been discussion of using expires_at as an exact epoch time i= n >>>> seconds as opposed to expires_in which is, at best, an approximation "= from >>>> the time the response was generated by the authorization server?" I >>>> apologize if this has been discussed previously. >>>> >>>> ~pj >>>> _______________________________________________ >>>> 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 Paul Lindner=A0-- lindner@inuus.com --=A0linkedin.com/in/plindner From david@alkaline-solutions.com Tue Dec 14 15: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 89C3A3A6E1F for ; Tue, 14 Dec 2010 15:56:32 -0800 (PST) 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 HxFfcTHYjsK5 for ; Tue, 14 Dec 2010 15:56:31 -0800 (PST) Received: from alkaline-solutions.com (lithium4.alkaline-solutions.com [208.78.100.23]) by core3.amsl.com (Postfix) with ESMTP id 246013A6E12 for ; Tue, 14 Dec 2010 15:56:31 -0800 (PST) Received: from [192.168.3.10] (c-24-9-59-104.hsd1.co.comcast.net [24.9.59.104]) by alkaline-solutions.com (Postfix) with ESMTPSA id 6651311C06D; Tue, 14 Dec 2010 23:58:11 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-138-531277755 From: David Waite In-Reply-To: Date: Tue, 14 Dec 2010 16:58:10 -0700 Message-Id: <8E49A9D7-7585-4486-AEC1-DDAA09FD4704@alkaline-solutions.com> References: To: Aaron Parecki X-Mailer: Apple Mail (2.1082) Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 14 Dec 2010 23:56:32 -0000 --Apple-Mail-138-531277755 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It depends how the time is used. A machine hosting a client is more = likely to have the local clock off, so letting it calculate lifetime = locally (say, this token is good for 10 minutes) is better than having = it interpret it locally (say, this is good until 3:30 PM). One thing = I've seen more than once is the clock being manually set a few hours off = - because the user did not change their location (and thus their = timezone).=20 A persistent cookie set to time-out in a few minutes is problematic for = this very reason - because the hardware hosting the user agent may have = a different interpretation of the current time. -DW On Dec 14, 2010, at 4:23 PM, Aaron Parecki wrote: > Agreed. I like the idea of expires_at as well. One of the first things = a client is going to do after receiving the expires_in is calculate the = current time plus the offset. Makes sense to eliminate one source of = timing errors. >=20 > On Dec 14, 2010 2:54 PM, "Paul Walker" wrote: > > It seems to me that expires_in suffers from the same machine time = synchronization issue and additionally throws in an indeterminable time = amount, while expires_at would only suffer from the former.=20 > >=20 > > ~pj > >=20 > > On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: > >=20 > >> expires_at requires very good time synchronization for all machines = involved. > >>=20 > >> expires_in, while not very exact, is more resilient. > >>=20 > >> Marius > >>=20 > >>=20 > >>=20 > >> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate = wrote: > >>> I have same question, Thanks Paul for Raising this > >>>=20 > >>> Regards > >>> Jitesh > >>>=20 > >>> -----Original Message----- > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Paul Walker > >>> Sent: Tuesday, December 14, 2010 4:14 PM > >>> To: OAuth WG > >>> Subject: [OAUTH-WG] expires_at vs expires_in > >>>=20 > >>> Has there been discussion of using expires_at as an exact epoch = time in seconds as opposed to expires_in which is, at best, an = approximation "from the time the response was generated by the = authorization server?" I apologize if this has been discussed = previously. > >>>=20 > >>> ~pj > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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-138-531277755 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Agreed. = I like the idea of expires_at as well. One of the first things a client = is going to do after receiving the expires_in is calculate the current = time plus the offset. Makes sense to eliminate one source of timing = errors.

On Dec 14, 2010 2:54 PM, "Paul Walker" <pjwalker@gmail.com> wrote:
> It seems to me that expires_in suffers from = the same machine time synchronization issue and additionally throws in = an indeterminable time amount, while expires_at would only suffer from = the former.
>
> ~pj
>
> On Dec 14, 2010, at 1:35 PM, Marius = Scurtescu wrote:
>
>> expires_at requires very good time = synchronization for all machines involved.
>>
>> = expires_in, while not very exact, is more resilient.
>>
>> Marius
>>
>>
>> =
>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <jbhate@exacttarget.com> = wrote:
>>> I have same question, Thanks Paul for Raising = this
>>>
>>> Regards
>>> = Jitesh
>>>
>>> -----Original = Message-----
>>> From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On = Behalf Of Paul Walker
>>> Sent: Tuesday, December 14, 2010 4:14 PM
>>> = To: OAuth WG
>>> Subject: [OAUTH-WG] expires_at vs = expires_in
>>>
>>> Has there been discussion of = using expires_at as an exact epoch time in seconds as opposed to = expires_in which is, at best, an approximation "from the time the = response was generated by the authorization server?" I apologize if = this has been discussed previously.
>>>
>>> ~pj
>>> = _______________________________________________
>>> 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

= --Apple-Mail-138-531277755-- From mscurtescu@google.com Tue Dec 14 16:33: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 4DF853A6E14 for ; Tue, 14 Dec 2010 16:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.927 X-Spam-Level: X-Spam-Status: No, score=-109.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 2tD1yoM63IHJ for ; Tue, 14 Dec 2010 16:33:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 61C943A6E13 for ; Tue, 14 Dec 2010 16:33:14 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id oBF0YsH7012009 for ; Tue, 14 Dec 2010 16:34:54 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292373295; bh=w5wu1Y8YpEPMKtc00P985HFSAr8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CSQECjPXJlDgxErAc2AYXzUte07JUjapRwLc8UygJ/21mROlRV4k4q0S2YX1bFZqI x7ZEz4ia8boZ948HXx2VA== Received: from gxk19 (gxk19.prod.google.com [10.202.11.19]) by kpbe12.cbf.corp.google.com with ESMTP id oBF0Yqfx030186 for ; Tue, 14 Dec 2010 16:34:53 -0800 Received: by gxk19 with SMTP id 19so943324gxk.39 for ; Tue, 14 Dec 2010 16:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=J8Qhpl9JxxhJELZrJ29WIE3GqXuPL8Pot8HWDyf0OUI=; b=oI5UPbxTgFulJz+ThmH9MXo4q2VNhKtCc/WfZyXfhJTN8730+9+BmTZ4FbgxI95qnm +1ct7kRDmKo5CAWTT3VQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lDR900hSZgXMGbn+tdyGrhYqs0AY+ANKDRahtr529tvdPFcR4PbJ80JcBM4mRByrBd 9ZjzknhcpFKZclKldCYA== Received: by 10.100.127.7 with SMTP id z7mr4045593anc.156.1292373292687; Tue, 14 Dec 2010 16:34:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.6 with HTTP; Tue, 14 Dec 2010 16:34:32 -0800 (PST) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 14 Dec 2010 16:34:32 -0800 Message-ID: To: Paul Walker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Dec 2010 00:33:15 -0000 On Tue, Dec 14, 2010 at 2:54 PM, Paul Walker wrote: > It seems to me that expires_in suffers from the same machine time synchronization issue and additionally throws in an indeterminable time amount, while expires_at would only suffer from the former. I don't see how expires_in suffers from same problem, it does not require any time synchronization. I does require a simple calculation, current time + expires_in, and it can be a few seconds off (the time since the token was issued until the client receives it and calculates the absolute expiration time). Marius From praveen.neppalli@gmail.com Tue Dec 14 16:47: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 3569F3A6E14 for ; Tue, 14 Dec 2010 16:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6PHEwcDfT5Km for ; Tue, 14 Dec 2010 16:47:15 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1BC7B3A6E0F for ; Tue, 14 Dec 2010 16:47:14 -0800 (PST) Received: by iwn40 with SMTP id 40so1533192iwn.31 for ; Tue, 14 Dec 2010 16:48:56 -0800 (PST) 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=s64PIzZPXRi7zrRCDpiQfNR3lz1s51swTHAsa629R3c=; b=pWfSuZcne0Fs51b1LNvsTQfTroJozQL8WvaVvZuV0kIF7e3SDM7xRLhOkXD8CrziXg fLev8jx702rofY4R8kXRSQdeusbJuirv1taQpGZaVcwjo/GMiis+pVvYU33t4TVJVPBy /0cPZp+tsTce5raX61lQ0XELaDbyPWyMGWjQ8= 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=N0WrEcWoig8GWE5xtvkqIOr7zSd519Weap/r9s/hZxJ38+wNdXp+QHD07ud8DQz0o7 wBLebuxl5d+AzfQgxPJ2tHPi5TdXzMmA8NZkfEyGv4AlzIBnkL8PzGOXP/EVZv++fQdW LoJEHzL/3DawTONlksyZiCBB48ZduYMBAHxK0= Received: by 10.231.149.194 with SMTP id u2mr4213882ibv.32.1292374135921; Tue, 14 Dec 2010 16:48:55 -0800 (PST) Received: from [10.63.205.177] ([166.205.139.144]) by mx.google.com with ESMTPS id z4sm448361ibg.1.2010.12.14.16.48.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 16:48:54 -0800 (PST) References: Message-Id: <4DA40520-A11F-44EC-AB73-8DD87D82C4D1@gmail.com> From: Praveen To: Paul Lindner In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Tue, 14 Dec 2010 16:48:43 -0800 Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Dec 2010 00:47:16 -0000 We at Linkedin use expires_in for the user-agent flow, just for the reasons Paul mentioned. The one issue is when developers pass the token to their backend. Praveen On Dec 14, 2010, at 3:56 PM, Paul Lindner wrote: > For User Agent flow you really really really want expires_in > > Do you know how many PCs and browsers have their clock set > incorrectly? > > > On Tue, Dec 14, 2010 at 3:23 PM, Aaron Parecki > wrote: >> Agreed. I like the idea of expires_at as well. One of the first >> things a >> client is going to do after receiving the expires_in is calculate the >> current time plus the offset. Makes sense to eliminate one source >> of timing >> errors. >> >> On Dec 14, 2010 2:54 PM, "Paul Walker" wrote: >>> It seems to me that expires_in suffers from the same machine time >>> synchronization issue and additionally throws in an indeterminable >>> time >>> amount, while expires_at would only suffer from the former. >>> >>> ~pj >>> >>> On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: >>> >>>> expires_at requires very good time synchronization for all machines >>>> involved. >>>> >>>> expires_in, while not very exact, is more resilient. >>>> >>>> Marius >>>> >>>> >>>> >>>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate >>> > >>>> wrote: >>>>> I have same question, Thanks Paul for Raising this >>>>> >>>>> Regards >>>>> Jitesh >>>>> >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>> Behalf >>>>> Of Paul Walker >>>>> Sent: Tuesday, December 14, 2010 4:14 PM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] expires_at vs expires_in >>>>> >>>>> Has there been discussion of using expires_at as an exact epoch >>>>> time in >>>>> seconds as opposed to expires_in which is, at best, an >>>>> approximation "from >>>>> the time the response was generated by the authorization >>>>> server?" I >>>>> apologize if this has been discussed previously. >>>>> >>>>> ~pj >>>>> _______________________________________________ >>>>> 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 >> >> > > > > -- > Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rs@dailymotion.com Tue Dec 14 17:09: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 5ADDB3A6E1B for ; Tue, 14 Dec 2010 17:09:11 -0800 (PST) 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 f7Y-dQuwhMf3 for ; Tue, 14 Dec 2010 17:09:10 -0800 (PST) Received: from intsvc-01.dailymotion.com (intsvc-01.dailymotion.com [195.8.215.87]) by core3.amsl.com (Postfix) with ESMTP id 2728C3A6E16 for ; Tue, 14 Dec 2010 17:09:10 -0800 (PST) Received: from EXCHANGE-02.daily.local (unknown [195.8.215.118]) by intsvc-01.dailymotion.com (Postfix) with ESMTP id BAE6B48510; Wed, 15 Dec 2010 02:10:50 +0100 (CET) Received: from EXCHANGE-02.daily.local ([195.8.215.118]) by exchange-02 ([195.8.215.118]) with mapi; Wed, 15 Dec 2010 02:06:54 +0100 From: Olivier POITREY To: Praveen Date: Wed, 15 Dec 2010 02:10:49 +0100 Thread-Topic: [OAUTH-WG] expires_at vs expires_in Thread-Index: Acub9FzrnOqRQtrkTaSwTn8vJ99Zxg== Message-ID: <0844A4AC-1E29-4A00-90E4-3981147B858C@dailymotion.com> References: <4DA40520-A11F-44EC-AB73-8DD87D82C4D1@gmail.com> In-Reply-To: <4DA40520-A11F-44EC-AB73-8DD87D82C4D1@gmail.com> Accept-Language: en-US, fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Walker , OAuth, WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Dec 2010 01:09:11 -0000 That is exactly the problem we're currently facing at Dailymotion with the = writing of our Javascript SDK. How do you handle this issue at Linkedin? Fa= cebook seems to use the expires_at pattern and just don't rely on expiratio= n time in their Javascript SDK but refresh the token 20 minutes (hard coded= in the client lib). What about providing both values in the response? The expires_in + time wou= ld be used by the client who directly obtained the token from the authoriza= tion server and expires_at would be used to share the session with a tier (= i.e.: javascript to backend via cookies). On 15 d=E9c. 2010, at 01:48, Praveen wrote: > We at Linkedin use expires_in for the user-agent flow, just for the =20 > reasons Paul mentioned. > The one issue is when developers pass the token to their backend. >=20 > Praveen >=20 > On Dec 14, 2010, at 3:56 PM, Paul Lindner wrote: >=20 >> For User Agent flow you really really really want expires_in >>=20 >> Do you know how many PCs and browsers have their clock set =20 >> incorrectly? >>=20 >>=20 >> On Tue, Dec 14, 2010 at 3:23 PM, Aaron Parecki =20 >> wrote: >>> Agreed. I like the idea of expires_at as well. One of the first =20 >>> things a >>> client is going to do after receiving the expires_in is calculate the >>> current time plus the offset. Makes sense to eliminate one source =20 >>> of timing >>> errors. >>>=20 >>> On Dec 14, 2010 2:54 PM, "Paul Walker" wrote: >>>> It seems to me that expires_in suffers from the same machine time >>>> synchronization issue and additionally throws in an indeterminable =20 >>>> time >>>> amount, while expires_at would only suffer from the former. >>>>=20 >>>> ~pj >>>>=20 >>>> On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: >>>>=20 >>>>> expires_at requires very good time synchronization for all machines >>>>> involved. >>>>>=20 >>>>> expires_in, while not very exact, is more resilient. >>>>>=20 >>>>> Marius >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate >>>>>=20 >>>>> wrote: >>>>>> I have same question, Thanks Paul for Raising this >>>>>>=20 >>>>>> Regards >>>>>> Jitesh >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =20 >>>>>> Behalf >>>>>> Of Paul Walker >>>>>> Sent: Tuesday, December 14, 2010 4:14 PM >>>>>> To: OAuth WG >>>>>> Subject: [OAUTH-WG] expires_at vs expires_in >>>>>>=20 >>>>>> Has there been discussion of using expires_at as an exact epoch =20 >>>>>> time in >>>>>> seconds as opposed to expires_in which is, at best, an =20 >>>>>> approximation "from >>>>>> the time the response was generated by the authorization =20 >>>>>> server?" I >>>>>> apologize if this has been discussed previously. >>>>>>=20 >>>>>> ~pj >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner >> _______________________________________________ >> 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 Dec 14 17: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 4313028C15E for ; Tue, 14 Dec 2010 17:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 ExFUsGsfsfCf for ; Tue, 14 Dec 2010 17:24:33 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4F4E428C15B for ; Tue, 14 Dec 2010 17:24:33 -0800 (PST) Received: (qmail 27612 invoked from network); 15 Dec 2010 01:26:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Dec 2010 01:26:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 14 Dec 2010 18:26:12 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Tue, 14 Dec 2010 18:26:07 -0700 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 Thread-Index: Acubu5fMO37s1EiNT5iW49Nw7fuY9gAO0TNQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723441191F3A34@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20101213221033.77C333A6D3F@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <86C32B7E-1233-496C-8F74-490287251C16@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723441191F387A@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 Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Dec 2010 01:24:34 -0000 Prepare a new draft if needed and submit it with draft-ietf-oauth- prefix. = One of the chairs will need to approve it and it will be published. I think= we have wide consensus for this and this was already proposed a long time = ago with no objections. EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Tuesday, December 14, 2010 10:18 AM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; oauth > Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell- > oauth-saml-01 >=20 > I don't have any objection to it and think it's probably cleaner. >=20 > Previously I'd informally asked that the SAML profile be considered a WG > item and I don't think there was any objection. What needs to be done to > make that happen? >=20 > If you/we take this approach, what else will you need from me? >=20 > On Tue, Dec 14, 2010 at 9:23 AM, Eran Hammer-Lahav > wrote: > > Torsten made a good argument that now that we combined assertions and > extensions into a single mechanism, it does not make sense to make the > 'assertion' parameter required, and that some extensions will be confusin= g > with such a parameter name. In addition, the recent document split > demoted this specification from 'core' to 'framework' which is more frien= dly > to extensions and companion specifications. > > > > I would suggest we drop the assertion parameter from the spec, but add = a > directly reference to the SAML assertion specification and give an exampl= e > showing the parameter. This will remove the normative language (which > really doesn't belong there - something I've long maintained), but will k= eep > the SAML assertion option on equal ground (directly demonstrated in the > spec). After all, you can't implement assertions just by reading the > framework spec, you still need the SAML work. > > > > This will require moving the SAML into a WG item (not a must but best) > which I am supportive of and would like to see happen quickly (in a few > days). > > > > Thoughts? > > > > EHL > > > >> -----Original Message----- > >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] > >> Sent: Tuesday, December 14, 2010 8:11 AM > >> To: Torsten Lodderstedt > >> Cc: Eran Hammer-Lahav; oauth > >> Subject: Re: [OAUTH-WG] Fwd: New Version Notification for > >> draft-campbell- > >> oauth-saml-01 > >> > >> Future revisions of this SAML draft will build off whatever > >> assertion/extension mechanism is provided by the core framework spec. > >> However, some compelling reasons were previously given for keeping > >> the 'assertion' (one thread on the topic: > >> http://www.ietf.org/mail-archive/web/oauth/current/msg04401.html) > >> parameter in core. =A0Has the thinking on that changed? > >> > >> On Tue, Dec 14, 2010 at 9:05 AM, Torsten Lodderstedt > >> wrote: > >> > +1 > >> > > >> > > >> > > >> > Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav > >> : > >> > > >> >> I think the 'assertion' parameter should be moved into this draft > >> >> and > >> defined there. This will also facilitate its proper definition and > >> status (required, singular, etc.). > >> >> > >> >> EHL > >> >> > > From pjwalker@gmail.com Tue Dec 14 17:35: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 450AB28C15D for ; Tue, 14 Dec 2010 17:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 Ptn7H1FBzVIn for ; Tue, 14 Dec 2010 17:35:23 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 8B06728C13D for ; Tue, 14 Dec 2010 17:35:23 -0800 (PST) Received: by pwi7 with SMTP id 7so199495pwi.31 for ; Tue, 14 Dec 2010 17:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=25lKGJ3ARpPhuYZ0PVWXlvBKS+PN85aTCK8/R0gOtQg=; b=DmrMIzKzp7KvGdoehq9/Sbozh4YYVQc51vAbEl8eTvCFi7qkmyE7HCAp4fjD0aWZ5Z 9O9RFwYexbWR5KZ0jgeUsRZ6GuVwFaVsLsEr0wtErUjdQSBimiwOO0o/fhsvUXtOYC6M 39774/rrR3oyiGBBoxafvok2SbV1qIBZHvn3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=gbxXDI4VB8WAs81mQ/IdoufWr+qqjQuyarXjTx6/1v3XRLReRHn5J9GQOycFQnME4K lW1yH/qK6F+ogTJIPIPXK+RarT6o7H99N99XisXCphPKEvCgVJ0IhUcwEaxttDUwyBB7 RGon93tYWc6Bsam4fGTKQJD3dzMYQrjOJLhwE= Received: by 10.142.179.5 with SMTP id b5mr5103332wff.225.1292377024705; Tue, 14 Dec 2010 17:37:04 -0800 (PST) Received: from paul.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id p8sm851461wff.4.2010.12.14.17.37.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 17:37:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Paul Walker In-Reply-To: Date: Tue, 14 Dec 2010 17:37:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7D6E9F8A-081D-4DA2-8CA0-4FA1B2C9C2CD@gmail.com> References: To: OAuth WG X-Mailer: Apple Mail (2.1082) Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Dec 2010 01:35:24 -0000 Correct, I guess their respective calculations would be both off by the = same amount. On Dec 14, 2010, at 4:34 PM, Marius Scurtescu wrote: > On Tue, Dec 14, 2010 at 2:54 PM, Paul Walker = wrote: >> It seems to me that expires_in suffers from the same machine time = synchronization issue and additionally throws in an indeterminable time = amount, while expires_at would only suffer from the former. >=20 > I don't see how expires_in suffers from same problem, it does not > require any time synchronization. I does require a simple calculation, > current time + expires_in, and it can be a few seconds off (the time > since the token was issued until the client receives it and calculates > the absolute expiration time). >=20 > Marius From pjwalker@gmail.com Tue Dec 14 17:38: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 D845828C13D for ; Tue, 14 Dec 2010 17:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HtqhWPNsxNuv for ; Tue, 14 Dec 2010 17:38:57 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 74B8828C13C for ; Tue, 14 Dec 2010 17:38:57 -0800 (PST) Received: by pzk5 with SMTP id 5so281042pzk.31 for ; Tue, 14 Dec 2010 17:40:39 -0800 (PST) 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=TkdnsCq9q2G4vDWy0ctpl8QO2KGeEutGFZjZ411jWtM=; b=dCe9owbh/84fe4bAnB7DJmj+Ypf8k4S/E6qPr+DBnJrGeDfm6EAjgYSzP85IX9P4+K fqOoO4Xyzhhc28G6vNm5jTzStAWOwMbPg0Qv5mEcGoWQwpJrZKHHXED4Rkc/FKv16NgL dmvIQmQpS1+MYKr2Y6Pk+fhE+pJAscezecczA= 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=ZJWCm1wdd8epEMN3JOaZ07SG2BUocSLmLmZSXFy8CrNJ3hlU8WLgv2PkvSJ5o+TCJQ LDZ8PlTFvKncVk6YAzuIvlzwXxCy3PyXGc6ujxvMu5c8Yul745jJDftHGnXlPIIkNUCq 25U4urZD7ovk26D3U5LtWrfTf0M/MZxbvhZPU= Received: by 10.142.54.2 with SMTP id c2mr5062365wfa.246.1292377237911; Tue, 14 Dec 2010 17:40:37 -0800 (PST) Received: from paul.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id p8sm848945wff.16.2010.12.14.17.40.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 17:40:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-7-537422360 From: Paul Walker In-Reply-To: Date: Tue, 14 Dec 2010 17:40:34 -0800 Message-Id: References: To: Paul Lindner X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Dec 2010 01:38:58 -0000 --Apple-Mail-7-537422360 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I did not consider the user-agent flow. I guess the only truly accurate = response would provide both an expires_from and an expires_at? On Dec 14, 2010, at 3:56 PM, Paul Lindner wrote: > For User Agent flow you really really really want expires_in >=20 > Do you know how many PCs and browsers have their clock set = incorrectly? >=20 >=20 > On Tue, Dec 14, 2010 at 3:23 PM, Aaron Parecki = wrote: >> Agreed. I like the idea of expires_at as well. One of the first = things a >> client is going to do after receiving the expires_in is calculate the >> current time plus the offset. Makes sense to eliminate one source of = timing >> errors. >>=20 >> On Dec 14, 2010 2:54 PM, "Paul Walker" wrote: >>> It seems to me that expires_in suffers from the same machine time >>> synchronization issue and additionally throws in an indeterminable = time >>> amount, while expires_at would only suffer from the former. >>>=20 >>> ~pj >>>=20 >>> On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: >>>=20 >>>> expires_at requires very good time synchronization for all machines >>>> involved. >>>>=20 >>>> expires_in, while not very exact, is more resilient. >>>>=20 >>>> Marius >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate = >>>> wrote: >>>>> I have same question, Thanks Paul for Raising this >>>>>=20 >>>>> Regards >>>>> Jitesh >>>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>>>> Of Paul Walker >>>>> Sent: Tuesday, December 14, 2010 4:14 PM >>>>> To: OAuth WG >>>>> Subject: [OAUTH-WG] expires_at vs expires_in >>>>>=20 >>>>> Has there been discussion of using expires_at as an exact epoch = time in >>>>> seconds as opposed to expires_in which is, at best, an = approximation "from >>>>> the time the response was generated by the authorization server?" = I >>>>> apologize if this has been discussed previously. >>>>>=20 >>>>> ~pj >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 >=20 >=20 > --=20 > Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner --Apple-Mail-7-537422360 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
For User Agent flow you really really really want = expires_in

Do you know how many PCs and browsers have their clock = set incorrectly?


On Tue, Dec 14, 2010 at 3:23 PM, Aaron = Parecki <aaron@parecki.com>= wrote:
Agreed. I like the idea of = expires_at as well. One of the first things = a
client is going to do after = receiving the expires_in is calculate the
current time plus the offset. Makes sense to eliminate one = source of timing
errors.

On Dec 14, 2010 = 2:54 PM, "Paul Walker" <pjwalker@gmail.com> = wrote:
It seems to me that expires_in suffers from the same = machine time
synchronization issue and = additionally throws in an indeterminable = time
amount, while expires_at would only suffer from the = former.

~pj

On Dec 14, 2010, at 1:35 PM, = Marius Scurtescu wrote:

expires_at requires very good time synchronization for all = machines
involved.

expires_in, while not very exact, is more = resilient.

Marius



On = Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <jbhate@exacttarget.com>
<= /blockquote>
wrote:
I have same question, Thanks = Paul for Raising = this

Regards
Jitesh

-----Original = Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On = Behalf
Of Paul = Walker
Sent: Tuesday, December 14, 2010 = 4:14 = PM
To: OAuth = WG
Subject: [OAUTH-WG] expires_at = vs = expires_in

Has there been discussion of = using expires_at as an exact epoch time = in
seconds as opposed to expires_in = which is, at best, an approximation = "from
the time the response was = generated by the authorization server?" = I
apologize if this has been = discussed = previously.

~pj
<= blockquote type=3D"cite">
_______________________________________________
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





--
Paul Lindner -- = lindner@inuus.com -- linkedin.com/in/plindner
<= /div>

= --Apple-Mail-7-537422360-- From pjwalker@gmail.com Wed Dec 15 12:21: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 88E473A7060 for ; Wed, 15 Dec 2010 12:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, 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 3L0S3V9HzL-X for ; Wed, 15 Dec 2010 12:21:03 -0800 (PST) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id 9EBD33A6FBF for ; Wed, 15 Dec 2010 12:21:03 -0800 (PST) Received: by pxi1 with SMTP id 1so365623pxi.27 for ; Wed, 15 Dec 2010 12:22:46 -0800 (PST) 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=7vp44E57NkKcHGpry0suGF/4dY/5/t+qYEpi/W11RD4=; b=cqssizPwDJC3HG9cK13NVc/4AUuPCjX6IeCBQWAD+QIk2mz2cPNpok/LRhqQ6cVKJC mmb2iFVj8hjS2j6sXFaEb+k94z2FgXgIQuD28/XqHpfJES4o4mP7Lwzfq40KToBCVupI AQ+PdEU+RmsfQWxd7HZO94Udb+SV1e0L4zwrk= 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=nxcWBE2tkpAEel7rd+XZckf0nVb8oY4iXyqsL6/8jfmKf7oJJ/8DLLgCewhjuzkATT 69S9f6q7BH4i0mLnZ+6SIeXlvodS6O62POTFWZCnOeJJxzGRDrT3FKVxI39CVCquvWN0 SsTDQMTu6qt2lfoW1TEfm48yZ+74/5p0dCehc= Received: by 10.142.170.13 with SMTP id s13mr6035581wfe.139.1292444566686; Wed, 15 Dec 2010 12:22:46 -0800 (PST) Received: from paul-lan.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id p8sm2034039wff.4.2010.12.15.12.22.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Dec 2010 12:22:45 -0800 (PST) From: Paul Walker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Dec 2010 12:22:44 -0800 Message-Id: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [OAUTH-WG] No client_id parameter in resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 20:21:04 -0000 What is the reasoning behind the lack of a client_id parameter in = requests to protected resources? Could it not add value if a resource = server wanted to provide IP white-lisitng (in a server to server = scenario), in that the resource server would not have to decrypt/look up = the client before denying the request? Also, it would alleviate the = need to create provider wide unique access token values. There is = probably some security reasoning behind this that I don't = understand...can someone kindly inform me? :-). Thanks, ~pj From lindner@inuus.com Wed Dec 15 12: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 9CFC528C0EA for ; Wed, 15 Dec 2010 12:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 MLNNOtqPk-jy for ; Wed, 15 Dec 2010 12:41:46 -0800 (PST) Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by core3.amsl.com (Postfix) with ESMTP id 30AC028C0DC for ; Wed, 15 Dec 2010 12:41:46 -0800 (PST) Received: by fxm18 with SMTP id 18so2473443fxm.16 for ; Wed, 15 Dec 2010 12:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inuus.com; s=google; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Npc3HKZwrjUgXCJpM7S2TRBG7A919NQYRbxEtnga+Lg=; b=bSDYHItSyG2o8D6Q9vZsBebmESrLcmbPZq9U0F+dABJOszzvbgWcY/l6lmBzVG5iNZ tLiCUr2tvt+AohaodGMedlbHFal+RZ0OKpvzwEjPqk7nixp2uPCgCt+k2tpgsJDy/LXs VukwTEN5pEn0IxBRFTHsV3Am6wH2Mc60ohwUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=inuus.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JpBfq7sLyRUfZScm2OMjRpStV+rCeGk9QRO8G3ikc0Vs78BurAxUc0IBx10NtambOM IDLsBOQR9PnTsoBOhLNREoibU9XKhUjK979VVwqGHO6hPt7arbwJ+E/23ViHsNLmicWq CruQuSvdEhwDIOSXRVX6UH/QtI+Ksk0mKwe9M= MIME-Version: 1.0 Received: by 10.223.125.136 with SMTP id y8mr285893far.149.1292445808686; Wed, 15 Dec 2010 12:43:28 -0800 (PST) Received: by 10.223.22.146 with HTTP; Wed, 15 Dec 2010 12:43:28 -0800 (PST) In-Reply-To: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> Date: Wed, 15 Dec 2010 12:43:28 -0800 Message-ID: From: Paul Lindner To: Paul Walker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] No client_id parameter in resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 20:41:47 -0000 You want the client_id on each API request? Put it in the token or make it part of your API. The token is opaque for a reason. On Wed, Dec 15, 2010 at 12:22 PM, Paul Walker wrote: > > What is the reasoning behind the lack of a client_id parameter in request= s to protected resources? =A0Could it not add value if a resource server wa= nted to provide IP white-lisitng (in a server to server scenario), in that = the resource server would not have to decrypt/look up the client before den= ying the request? =A0Also, it would alleviate the need to create provider w= ide unique access token values. =A0There is probably some security reasonin= g behind this that I don't understand...can someone kindly inform me? =A0:-= ). > > Thanks, > ~pj > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Paul Lindner=A0-- lindner@inuus.com --=A0linkedin.com/in/plindner From phil.hunt@oracle.com Wed Dec 15 14:19: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 E731F28C106 for ; Wed, 15 Dec 2010 14:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vnhw7X-yd9Gq for ; Wed, 15 Dec 2010 14:19:57 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 736CE28C11B for ; Wed, 15 Dec 2010 14:19:55 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBFMLaQ6017690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Dec 2010 22:21:37 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBFMLT9M025517; Wed, 15 Dec 2010 22:21:30 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 878596481292451514; Wed, 15 Dec 2010 14:18:34 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Dec 2010 14:18:34 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-23-611699474 From: Phil Hunt In-Reply-To: Date: Wed, 15 Dec 2010 14:18:31 -0800 Message-Id: <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> To: Paul Lindner X-Mailer: Apple Mail (2.1082) Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] No client_id parameter in resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 22:20:00 -0000 --Apple-Mail-23-611699474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom the spec, from section 5, draft 11 obtaining the access token = includes it... "The client obtains an access token by authenticating with the = authorization server and presenting its access grant (in the form of an = authorization code, resource owner credentials, an assertion, or a = refresh token)." But, when accessing the resource (sect 6), I agree it is unclear. I am = assuming the there is some method that binds the active client with the = resource access token (much like an SSO cookie does in a browser). I am = concerned about issues similar to SAML 1.1 browser artifact profile and = having the necessary counter-measures. See section 4.1.1 of this = document: = http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bin= dings-1.1.pdf Phil phil.hunt@oracle.com On 2010-12-15, at 12:43 PM, Paul Lindner wrote: > You want the client_id on each API request? Put it in the token or > make it part of your API. The token is opaque for a reason. >=20 > On Wed, Dec 15, 2010 at 12:22 PM, Paul Walker = wrote: >>=20 >> What is the reasoning behind the lack of a client_id parameter in = requests to protected resources? Could it not add value if a resource = server wanted to provide IP white-lisitng (in a server to server = scenario), in that the resource server would not have to decrypt/look up = the client before denying the request? Also, it would alleviate the = need to create provider wide unique access token values. There is = probably some security reasoning behind this that I don't = understand...can someone kindly inform me? :-). >>=20 >> Thanks, >> ~pj >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 > Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-23-611699474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii by authenticating with the authorization = server and presenting its access grant (in the form of an = authorization code, resource owner credentials, an assertion, or a = refresh token)."

But, when accessing the resource = (sect 6), I agree it is unclear. I am assuming the there is some method = that binds the active client with the resource access token (much like = an SSO cookie does in a browser). I am concerned about issues similar to = SAML 1.1 browser artifact profile and having the necessary = counter-measures.  See section 4.1.1 of this = document:


On 2010-12-15, at 12:43 PM, Paul Lindner = wrote:

You want the client_id on each API request?  Put = it in the token or
make it part of your API.  The token is = opaque for a reason.

On Wed, Dec 15, 2010 at 12:22 PM, Paul = Walker <pjwalker@gmail.com> = wrote:

What is the reasoning behind the lack of a client_id = parameter in requests to protected resources?  Could it not add = value if a resource server wanted to provide IP white-lisitng (in a = server to server scenario), in that the resource server would not have = to decrypt/look up the client before denying the request?  Also, it = would alleviate the need to create provider wide unique access token = values.  There is probably some security reasoning behind this that = I don't understand...can someone kindly inform me? =  :-).

Thanks,
~pj

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




--
Paul Lindner -- = lindner@inuus.com -- linkedin.com/in/plindner
_= ______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= = --Apple-Mail-23-611699474-- From pjwalker@gmail.com Wed Dec 15 14:58: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 2341D28C0E7 for ; Wed, 15 Dec 2010 14:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xR5yk7BdUL1Q for ; Wed, 15 Dec 2010 14:58:24 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E3EF428C0DC for ; Wed, 15 Dec 2010 14:58:23 -0800 (PST) Received: by pwi7 with SMTP id 7so407160pwi.31 for ; Wed, 15 Dec 2010 15:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:mime-version :content-type:subject:date:in-reply-to:to:references:message-id :x-mailer; bh=Bilf1qnxs7m+My5I93ZYaUU7Iks61e4NmNMwuevoTFU=; b=RyEyfQDTmL6AMA7YOhG2oV4VoO1QTBhFtwR1le8+SkryJB53VdvnlH699lMztWwGQI wEGXafKK7iSrXQ8Icx6rL9fTDxx362L64VAGsAeW40W6jNrrJL0vZqFAU4Ve12j0a7e2 lga2Ixc2PIqMvCAk6fwF40T+Abo+jnXWC3/fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=KFdt3kK6sAAwe0bg9AY6MTPPX8NQDiqqFkUG/r0K3sV8b5hsveUSkUUmYenaeru9xC kgoOYB84s11/2cr7ZCMqU9qMF1IFJFRqgWvotRoFA/WDfPLbPY1dU9GvpgrL1l1mg3eW 8p66GaI3T0BSbpTyhjYOzZmHM9QPklAFomO38= Received: by 10.143.161.17 with SMTP id n17mr6226396wfo.160.1292454007168; Wed, 15 Dec 2010 15:00:07 -0800 (PST) Received: from paul-lan.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id w14sm2187439wfd.18.2010.12.15.15.00.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Dec 2010 15:00:06 -0800 (PST) From: Paul Walker Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4-614192151 Date: Wed, 15 Dec 2010 15:00:04 -0800 In-Reply-To: <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> To: OAuth WG References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> Message-Id: <4FD254C7-8DEB-4590-843A-BE9C2B75AC57@gmail.com> X-Mailer: Apple Mail (2.1082) Subject: Re: [OAUTH-WG] No client_id parameter in resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 22:58:25 -0000 --Apple-Mail-4-614192151 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The same capability to store the client_id in an opaque value holds true = for the authorization code and refresh token, yet the client_id = parameter is required in those requests. Although section 5.0 does not = actually say the client_id is required in access token requests, but the = examples in 5.1.1 and 5.1.4 have the client_id present. ~pj On Dec 15, 2010, at 2:18 PM, Phil Hunt wrote: > =46rom the spec, from section 5, draft 11 obtaining the access token = includes it... >=20 > "The client obtains an access token by authenticating with the = authorization server and presenting its access grant (in the form of an = authorization code, resource owner credentials, an assertion, or a = refresh token)." >=20 > But, when accessing the resource (sect 6), I agree it is unclear. I am = assuming the there is some method that binds the active client with the = resource access token (much like an SSO cookie does in a browser). I am = concerned about issues similar to SAML 1.1 browser artifact profile and = having the necessary counter-measures. See section 4.1.1 of this = document: > = http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bin= dings-1.1.pdf >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2010-12-15, at 12:43 PM, Paul Lindner wrote: >=20 >> You want the client_id on each API request? Put it in the token or >> make it part of your API. The token is opaque for a reason. >>=20 >> On Wed, Dec 15, 2010 at 12:22 PM, Paul Walker = wrote: >>>=20 >>> What is the reasoning behind the lack of a client_id parameter in = requests to protected resources? Could it not add value if a resource = server wanted to provide IP white-lisitng (in a server to server = scenario), in that the resource server would not have to decrypt/look up = the client before denying the request? Also, it would alleviate the = need to create provider wide unique access token values. There is = probably some security reasoning behind this that I don't = understand...can someone kindly inform me? :-). >>>=20 >>> Thanks, >>> ~pj >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-4-614192151 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = same capability to store the client_id in an opaque value holds true for = the authorization code and refresh token, yet the client_id parameter is = required in those requests.  Although section 5.0 does not actually = say the client_id is required in access token requests, but the examples = in 5.1.1 and 5.1.4 have the client_id = present.

~pj

On Dec 15, 2010, = at 2:18 PM, Phil Hunt wrote:

=46rom the spec, from = section 5, draft 11 obtaining the access token includes = it...

"The client obtains an access token = by authenticating with the authorization server and = presenting its access grant (in the form of an authorization code, = resource owner credentials, an assertion, or a refresh = token)."

But, when accessing the resource (sect = 6), I agree it is unclear. I am assuming the there is some method that = binds the active client with the resource access token (much like an SSO = cookie does in a browser). I am concerned about issues similar to SAML = 1.1 browser artifact profile and having the necessary counter-measures. =  See section 4.1.1 of this document:
http://www.oasis-open.org/committees/download.php/3= 405/oasis-sstc-saml-bindings-1.1.pdf


On 2010-12-15, at 12:43 PM, Paul Lindner = wrote:

You want the client_id on each API request?  Put = it in the token or
make it part of your API.  The token is = opaque for a reason.

On Wed, Dec 15, 2010 at 12:22 PM, Paul = Walker <pjwalker@gmail.com> = wrote:

What is the reasoning behind the lack of a client_id = parameter in requests to protected resources?  Could it not add = value if a resource server wanted to provide IP white-lisitng (in a = server to server scenario), in that the resource server would not have = to decrypt/look up the client before denying the request?  Also, it = would alleviate the need to create provider wide unique access token = values.  There is probably some security reasoning behind this that = I don't understand...can someone kindly inform me? =  :-).

Thanks,
~pj

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




--
Paul Lindner -- = lindner@inuus.com -- linkedin.com/in/plindner
_= ______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail-4-614192151-- From James.H.Manger@team.telstra.com Wed Dec 15 16:08: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 950B328C0F4 for ; Wed, 15 Dec 2010 16:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 m9OCs0Q+DiWW for ; Wed, 15 Dec 2010 16:08:20 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 55E7428C0EC for ; Wed, 15 Dec 2010 16:08:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,351,1288530000"; d="scan'208,217";a="21746272" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 16 Dec 2010 11:10:01 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6198"; a="15474474" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 16 Dec 2010 11:10:01 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 16 Dec 2010 10:10:00 +1000 From: "Manger, James H" To: Paul Walker , OAuth WG Date: Thu, 16 Dec 2010 10:09:59 +1000 Thread-Topic: [OAUTH-WG] No client_id parameter in resource requests Thread-Index: Acucq9Zk9BWBdc+GSpmFtZzyg3C0pwABDUuw Message-ID: <255B9BB34FB7D647A506DC292726F6E1127AC7EAD9@WSMSG3153V.srv.dir.telstra.com> References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> <4FD254C7-8DEB-4590-843A-BE9C2B75AC57@gmail.com> In-Reply-To: <4FD254C7-8DEB-4590-843A-BE9C2B75AC57@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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127AC7EAD9WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] No client_id parameter in resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 00:08:23 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127AC7EAD9WSMSG3153Vsrv_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 What is the reasoning behind the lack of a client_id parameter in requ= ests to protected resources? When the client app is acting on its own behalf (with the app's own long-te= rm credentials)... the client_id is included as part of authenticating the = client app (as a query/form parameter, or as the user-id field in a "Author= ization: BASIC" header, or in any other authentication mechanism). When the client app is acting on behalf of a user (with credentials from an= OAuth token response)... the client_id is NOT included. The credentials fr= om the token response are sufficient. Adding client_id here is unnecessary = (the server can include it in the token if it is convenient for protected r= esources), and harmful (it means the protocol that uses the credentials fro= m the token response cannot look like a normal authentication protocol). -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127AC7EAD9WSMSG3153Vsrv_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  What is the reasoning behind the lack of a c= lient_id parameter in requests to protected resources?

 

When the client app is acting on its own behalf (with the ap= p’s own long-term credentials)… the client_id is included as pa= rt of authenticating the client app (as a query/form parameter, or as the user-id field in a “Author= ization: BASIC” header, or in any other authentication mechanism).

 

When the client app is acting on behalf of a user (with cred= entials from an OAuth token response)… the client_id is NOT included.= The credentials from the token response are sufficient. Adding client_id here is unnecessary (the s= erver can include it in the token if it is convenient for protected resourc= es), and harmful (it means the protocol that uses the credentials from the = token response cannot look like a normal authentication protocol).

 

--

James Manger

--_000_255B9BB34FB7D647A506DC292726F6E1127AC7EAD9WSMSG3153Vsrv_-- From igor.faynberg@alcatel-lucent.com Wed Dec 15 16:29: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 572C028C0EC for ; Wed, 15 Dec 2010 16:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 ijcoLLb+9EUb for ; Wed, 15 Dec 2010 16:29:01 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id ABC6B28C0FF for ; Wed, 15 Dec 2010 16:29:00 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id oBG0Ug7Q021361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2010 18:30:42 -0600 (CST) Received: from [135.244.1.66] (faynberg.lra.lucent.com [135.244.1.66]) by umail.lucent.com (8.13.8/TPES) with ESMTP id oBG0UZg0013557; Wed, 15 Dec 2010 18:30:36 -0600 (CST) Message-ID: <4D095DB2.9050705@alcatel-lucent.com> Date: Wed, 15 Dec 2010 19:30:42 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Manger, James H" References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> <4FD254C7-8DEB-4590-843A-BE9C2B75AC57@gmail.com> <255B9BB34FB7D647A506DC292726F6E1127AC7EAD9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127AC7EAD9@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] No client_id parameter in resource requests 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: Thu, 16 Dec 2010 00:29:02 -0000 James, Could you please clarify the last point (i.e., "cannot look like a normal authentication protocol")? I simply don't understand what you mean. With thanks, Igor Manger, James H wrote: > > .... Adding client_id here is unnecessary (the server can include it > in the token if it is convenient for protected resources), and harmful > (it means the protocol that uses the credentials from the token > response cannot look like a normal authentication protocol). > > > > From phil.hunt@oracle.com Wed Dec 15 17:20: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 F1EE128C143 for ; Wed, 15 Dec 2010 17:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CloeYmwHi0Ou for ; Wed, 15 Dec 2010 17:20:43 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5F71D3A6E0E for ; Wed, 15 Dec 2010 17:20:43 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBG1MNaQ010444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 01:22:24 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBG1MKC4000790; Thu, 16 Dec 2010 01:22:20 GMT Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 878984331292462372; Wed, 15 Dec 2010 17:19:32 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 Dec 2010 17:19:31 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2-622557220 From: Phil Hunt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127AC7EAD9@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 15 Dec 2010 17:19:29 -0800 Message-Id: <4B6255DE-A796-41C7-B0FD-8AA164BD518B@oracle.com> References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> <4FD254C7-8DEB-4590-843A-BE9C2B75AC57@gmail.com> <255B9BB34FB7D647A506DC292726F6E1127AC7EAD9@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1082) Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] No client_id parameter in resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 01:20:47 -0000 --Apple-Mail-2-622557220 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 See below.. Phil phil.hunt@oracle.com On 2010-12-15, at 4:09 PM, Manger, James H wrote: > =D8 What is the reasoning behind the lack of a client_id parameter in = requests to protected resources? > =20 > When the client app is acting on its own behalf (with the app=92s own = long-term credentials)=85 the client_id is included as part of = authenticating the client app (as a query/form parameter, or as the = user-id field in a =93Authorization: BASIC=94 header, or in any other = authentication mechanism). > =20 > When the client app is acting on behalf of a user (with credentials = from an OAuth token response)=85 the client_id is NOT included. The = credentials from the token response are sufficient. Adding client_id = here is unnecessary (the server can include it in the token if it is = convenient for protected resources), and harmful (it means the protocol = that uses the credentials from the token response cannot look like a = normal authentication protocol). It is useful for the resource authorization policy server to know what = client is acting on behalf of what user. E.g. if a financial aggregator = was using OAuth to access a bank, the bank systems can differentiate = rights between normal end-user access and a client app access (e.g. = read-only regardless of scope). I know scope already covers some of = this, but it seems like an important distinction if for some reason a = policy server needs to apply additional rules for clients beyond those = of scope. > =20 > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2-622557220 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 See = below..


On 2010-12-15, at 4:09 PM, Manger, James H wrote:

=D8  What = is the reasoning behind the lack of a client_id parameter in requests to = protected resources?When = the client app is acting on its own behalf (with the app=92s own = long-term credentials)=85 the client_id is included as part of = authenticating the client app (as a query/form parameter, or as the = user-id field in a =93Authorization: BASIC=94 header, or in any other = authentication mechanism).
When = the client app is acting on behalf of a user (with credentials from an = OAuth token response)=85 the client_id is NOT included. The credentials = from the token response are sufficient. Adding client_id here is = unnecessary (the server can include it in the token if it is convenient = for protected resources), and harmful (it means the protocol that uses = the credentials from the token response cannot look like a normal = authentication = protocol).

It = is useful for the resource authorization policy server to know what = client is acting on behalf of what user.  E.g. if a financial = aggregator was using OAuth to access a bank, the bank systems can = differentiate rights between normal end-user access and a client app = access (e.g. read-only regardless of scope).  I know scope already = covers some of this, but it seems like an important distinction if for = some reason a policy server needs to apply additional rules for clients = beyond those of scope.
James = Manger
________________________________= _______________
OAuth mailing list
To: Phil Hunt Date: Thu, 16 Dec 2010 12:49:14 +1100 Thread-Topic: [OAUTH-WG] No client_id parameter in resource requests Thread-Index: Acucv7Yng2fEiePbRKCNAyfbLLaC1gAAP5cw Message-ID: <255B9BB34FB7D647A506DC292726F6E1127ACF65AD@WSMSG3153V.srv.dir.telstra.com> References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> <4FD254C7-8DEB-4590-843A-BE9C2B75AC57@gmail.com> <255B9BB34FB7D647A506DC292726F6E1127AC7EAD9@WSMSG3153V.srv.dir.telstra.com> <4B6255DE-A796-41C7-B0FD-8AA164BD518B@oracle.com> In-Reply-To: <4B6255DE-A796-41C7-B0FD-8AA164BD518B@oracle.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_255B9BB34FB7D647A506DC292726F6E1127ACF65ADWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] No client_id parameter in resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 01:47:36 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127ACF65ADWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, > It is useful for the resource authorization policy server to know what cl= ient is acting on behalf of what user. E.g. if a financial aggregator was = using OAuth to access a bank, the bank systems can differentiate rights bet= ween normal end-user access and a client app access (e.g. read-only regardl= ess of scope). I know scope already covers some of this, but it seems like= an important distinction if for some reason a policy server needs to apply= additional rules for clients beyond those of scope. It certainly makes sense for a bank "protected resource" to be able to dist= inguish requests from (1) a financial aggregator app acting on a user's beh= alf, and (2) requests from the user. But the bank gets that by arranging wi= th the authorization server (also the bank) to issue tokens that distinguis= h those cases. Eg user-ids are 16-digit credit card numbers; tokens issued = to client apps start with "DELEGATE_...". The client app need not care how = the bank does this. It does not need the OAuth2 framework to specify an exp= licit client_id parameter to include in those requests. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127ACF65ADWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil,

 

> It is useful for the resource authorization policy server to know what clie= nt is acting on behalf of what user.  E.g. if a financial aggregator w= as using OAuth to access a bank, the bank systems can differentiate rights = between normal end-user access and a client app access (e.g. read-only regardless of scope).  I know scope= already covers some of this, but it seems like an important distinction if= for some reason a policy server needs to apply additional rules for client= s beyond those of scope.

 

It certainly makes sense for a bank “protected resourc= e” to be able to distinguish requests from (1) a financial aggregator= app acting on a user’s behalf, and (2) requests from the user. But the bank gets that by arranging with t= he authorization server (also the bank) to issue tokens that distinguish th= ose cases. Eg user-ids are 16-digit credit card numbers; tokens issued to c= lient apps start with “DELEGATE_...”. The client app need not care how the bank does this. It does not need the = OAuth2 framework to specify an explicit client_id parameter to include in t= hose requests.

 

--

James Manger

--_000_255B9BB34FB7D647A506DC292726F6E1127ACF65ADWSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Wed Dec 15 18:26: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 561DC28C13A for ; Wed, 15 Dec 2010 18:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=0.025, 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 R+qeYHoIuRDE for ; Wed, 15 Dec 2010 18:26:28 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 22A4028C12A for ; Wed, 15 Dec 2010 18:26:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,352,1288530000"; d="scan'208";a="23162625" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 16 Dec 2010 13:28:08 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6198"; a="15672279" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdni.tcif.telstra.com.au with ESMTP; 16 Dec 2010 13:28:08 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 16 Dec 2010 13:28:08 +1100 From: "Manger, James H" To: "igor.faynberg@alcatel-lucent.com" , OAuth WG Date: Thu, 16 Dec 2010 13:28:06 +1100 Thread-Topic: [OAUTH-WG] No client_id parameter in resource requests Thread-Index: AcucuHv0bShtLQKzTTeEoPnTmvUBYgABpEHw Message-ID: <255B9BB34FB7D647A506DC292726F6E1127ACF6660@WSMSG3153V.srv.dir.telstra.com> References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> <4FD254C7-8DEB-4590-843A-BE9C2B75AC57@gmail.com> <255B9BB34FB7D647A506DC292726F6E1127AC7EAD9@WSMSG3153V.srv.dir.telstra.com> <4D095DB2.9050705@alcatel-lucent.com> In-Reply-To: <4D095DB2.9050705@alcatel-lucent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] No client_id parameter in resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 02:26:29 -0000 Igor, >> .... Adding client_id here is unnecessary (the server can include it=20 >> in the token if it is convenient for protected resources), and harmful=20 >> (it means the protocol that uses the credentials from the token=20 >> response cannot look like a normal authentication protocol). > Could you please clarify the last point (i.e., "cannot look like a=20 > normal authentication protocol")? I simply don't understand what you mea= n. Perhaps an example would help. Consider a server (of protected resources) t= hat authenticates requests using the HTTP DIGEST scheme (or substitute any = other request signing scheme that is not OAuth-specific). If it wants, the server can authenticate requests directly from users: by r= eturning WWW-Auth: DIGEST... to trigger the browser to prompt the user for = their password. To support delegated access (requests from a client app on a user's behalf)= the server tells the client app to orchestrate an OAuth2 flow. The client = app ends up with a token response that contains credentials to use with the= HTTP DIGEST scheme (ie a user-id/password pair that represents this delega= tion). The client app now makes requests on the user's behalf to the server using = "normal" HTTP DIGEST. On the wire, these requests are totally standard HTTP= DIGEST authentication requests (so they can use totally standard implement= ations and APIs). There is no extra client_id field in the HTTP DIGEST scheme. It does take a= n id, but in this context that is the id of the delegation (client app X ac= ting for user Y). DIGEST assumes a model with two parties that shared a se= cret -- it simply has no use for the extra concept of a third party, and ne= ither will any other "normal" authentication protocol. I believe the SASL model is a bit more sophisticated. It includes 2 ids: an= authentication_id and an authorization_id. But neither of those would corr= espond to client_id. The authorization_id could be a bearer token (when the= re is no authentication_id); or the authentication_id could be the id from = a token response that had a secret key (and the authorization_id could be t= he user-id). If the OAuth framework spec forced an explicit client_id parameter into req= uests for protected resources it would be unusable with HTTP DIGEST (and ev= ery other authentication scheme, past and future, that is not OAuth-specifi= c). Is my meaning any clearer now? -- James Manger From igor.faynberg@alcatel-lucent.com Thu Dec 16 06:58: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 3BA073A6823 for ; Thu, 16 Dec 2010 06:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 QHC9zBpwC41e for ; Thu, 16 Dec 2010 06:58:50 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 665423A680B for ; Thu, 16 Dec 2010 06:58:48 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id oBGF0T4r006324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Dec 2010 09:00:29 -0600 (CST) Received: from [135.244.1.128] (faynberg.lra.lucent.com [135.244.1.128]) by umail.lucent.com (8.13.8/TPES) with ESMTP id oBGF0S0J001101; Thu, 16 Dec 2010 09:00:28 -0600 (CST) Message-ID: <4D0A298C.9080807@alcatel-lucent.com> Date: Thu, 16 Dec 2010 10:00:28 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Manger, James H" References: <6F756E1E-E116-4F74-866E-95ABAFCD85D1@gmail.com> <8690CD4D-D9CB-460B-B2E0-E83FC11EA4CD@oracle.com> <4FD254C7-8DEB-4590-843A-BE9C2B75AC57@gmail.com> <255B9BB34FB7D647A506DC292726F6E1127AC7EAD9@WSMSG3153V.srv.dir.telstra.com> <4D095DB2.9050705@alcatel-lucent.com> <255B9BB34FB7D647A506DC292726F6E1127ACF6660@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127ACF6660@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: OAuth WG Subject: Re: [OAUTH-WG] No client_id parameter in resource requests 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: Thu, 16 Dec 2010 14:58:51 -0000 James, Yes, I understand you now and I agree with you. With thanks, Igor Manger, James H wrote: > Igor, > > >>> .... Adding client_id here is unnecessary (the server can include it >>> in the token if it is convenient for protected resources), and harmful >>> (it means the protocol that uses the credentials from the token >>> response cannot look like a normal authentication protocol). >>> > > >> Could you please clarify the last point (i.e., "cannot look like a >> normal authentication protocol")? I simply don't understand what you mean. >> > > Perhaps an example would help. Consider a server (of protected resources) that authenticates requests using the HTTP DIGEST scheme (or substitute any other request signing scheme that is not OAuth-specific). > > If it wants, the server can authenticate requests directly from users: by returning WWW-Auth: DIGEST... to trigger the browser to prompt the user for their password. > > To support delegated access (requests from a client app on a user's behalf) the server tells the client app to orchestrate an OAuth2 flow. The client app ends up with a token response that contains credentials to use with the HTTP DIGEST scheme (ie a user-id/password pair that represents this delegation). > > The client app now makes requests on the user's behalf to the server using "normal" HTTP DIGEST. On the wire, these requests are totally standard HTTP DIGEST authentication requests (so they can use totally standard implementations and APIs). > > There is no extra client_id field in the HTTP DIGEST scheme. It does take an id, but in this context that is the id of the delegation (client app X acting for user Y). DIGEST assumes a model with two parties that shared a secret -- it simply has no use for the extra concept of a third party, and neither will any other "normal" authentication protocol. > > I believe the SASL model is a bit more sophisticated. It includes 2 ids: an authentication_id and an authorization_id. But neither of those would correspond to client_id. The authorization_id could be a bearer token (when there is no authentication_id); or the authentication_id could be the id from a token response that had a secret key (and the authorization_id could be the user-id). > > If the OAuth framework spec forced an explicit client_id parameter into requests for protected resources it would be unusable with HTTP DIGEST (and every other authentication scheme, past and future, that is not OAuth-specific). > > Is my meaning any clearer now? > > > -- > James Manger > From catch-all@paulwalker.tv Tue Dec 14 17: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 E485928C145 for ; Tue, 14 Dec 2010 17:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uwrCdWSOzbb4 for ; Tue, 14 Dec 2010 17:46:14 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 900EB28C13C for ; Tue, 14 Dec 2010 17:46:14 -0800 (PST) Received: by pzk5 with SMTP id 5so282060pzk.31 for ; Tue, 14 Dec 2010 17:47:56 -0800 (PST) Received: by 10.142.229.8 with SMTP id b8mr5070432wfh.20.1292377676016; Tue, 14 Dec 2010 17:47:56 -0800 (PST) Received: from paul.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id w22sm861254wfd.7.2010.12.14.17.47.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 17:47:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-8-537859572 From: Paul Walker In-Reply-To: Date: Tue, 14 Dec 2010 17:47:52 -0800 Message-Id: <07D709B4-2923-4985-B737-490FC9831F87@paulwalker.tv> References: To: Paul Walker X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 16 Dec 2010 09:02:06 -0800 Cc: OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Dec 2010 01:47:09 -0000 --Apple-Mail-8-537859572 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Which also doesn't provide any real value over expires_in in the web = server flow when I think about it. On Dec 14, 2010, at 5:40 PM, Paul Walker wrote: > I did not consider the user-agent flow. I guess the only truly = accurate response would provide both an expires_from and an expires_at? >=20 > On Dec 14, 2010, at 3:56 PM, Paul Lindner wrote: >=20 >> For User Agent flow you really really really want expires_in >>=20 >> Do you know how many PCs and browsers have their clock set = incorrectly? >>=20 >>=20 >> On Tue, Dec 14, 2010 at 3:23 PM, Aaron Parecki = wrote: >>> Agreed. I like the idea of expires_at as well. One of the first = things a >>> client is going to do after receiving the expires_in is calculate = the >>> current time plus the offset. Makes sense to eliminate one source of = timing >>> errors. >>>=20 >>> On Dec 14, 2010 2:54 PM, "Paul Walker" wrote: >>>> It seems to me that expires_in suffers from the same machine time >>>> synchronization issue and additionally throws in an indeterminable = time >>>> amount, while expires_at would only suffer from the former. >>>>=20 >>>> ~pj >>>>=20 >>>> On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: >>>>=20 >>>>> expires_at requires very good time synchronization for all = machines >>>>> involved. >>>>>=20 >>>>> expires_in, while not very exact, is more resilient. >>>>>=20 >>>>> Marius >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate = >>>>> wrote: >>>>>> I have same question, Thanks Paul for Raising this >>>>>>=20 >>>>>> Regards >>>>>> Jitesh >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>>>>> Of Paul Walker >>>>>> Sent: Tuesday, December 14, 2010 4:14 PM >>>>>> To: OAuth WG >>>>>> Subject: [OAUTH-WG] expires_at vs expires_in >>>>>>=20 >>>>>> Has there been discussion of using expires_at as an exact epoch = time in >>>>>> seconds as opposed to expires_in which is, at best, an = approximation "from >>>>>> the time the response was generated by the authorization server?" = I >>>>>> apologize if this has been discussed previously. >>>>>>=20 >>>>>> ~pj >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-8-537859572 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Which = also doesn't provide any real value over expires_in in the web server = flow when I think about it.

On Dec 14, 2010, at 5:40 = PM, Paul Walker wrote:

I did not consider the = user-agent flow.  I guess the only truly accurate response would = provide both an expires_from and an = expires_at?

On Dec 14, 2010, at 3:56 PM, Paul = Lindner wrote:

For User Agent flow you really really really want = expires_in

Do you know how many PCs and browsers have their clock = set incorrectly?


On Tue, Dec 14, 2010 at 3:23 PM, Aaron = Parecki <aaron@parecki.com>= wrote:
Agreed. I like the idea of = expires_at as well. One of the first things = a
client is going to do after = receiving the expires_in is calculate the
current time plus the offset. Makes sense to eliminate one = source of timing
errors.

On Dec 14, 2010 = 2:54 PM, "Paul Walker" <pjwalker@gmail.com> = wrote:
It seems to me that expires_in suffers from the same = machine time
synchronization issue and = additionally throws in an indeterminable = time
amount, while expires_at would only suffer from the = former.

~pj

On Dec 14, 2010, at 1:35 PM, = Marius Scurtescu wrote:

expires_at requires very good time synchronization for all = machines
involved.

expires_in, while not very exact, is more = resilient.

Marius



On = Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <jbhate@exacttarget.com>
<= /blockquote>
wrote:
I have same question, Thanks = Paul for Raising = this

Regards
Jitesh

-----Original = Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On = Behalf
Of Paul = Walker
Sent: Tuesday, December 14, 2010 = 4:14 = PM
To: OAuth = WG
Subject: [OAUTH-WG] expires_at = vs = expires_in

Has there been discussion of = using expires_at as an exact epoch time = in
seconds as opposed to expires_in = which is, at best, an approximation = "from
the time the response was = generated by the authorization server?" = I
apologize if this has been = discussed = previously.

~pj
<= blockquote type=3D"cite">
_______________________________________________
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





--
Paul Lindner -- = lindner@inuus.com -- linkedin.com/in/plindner
<= /div>

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

= --Apple-Mail-8-537859572-- From zachary.zeltsan@alcatel-lucent.com Thu Dec 16 12:55: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 A48613A69D2 for ; Thu, 16 Dec 2010 12:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Y9EQSMYppgt3 for ; Thu, 16 Dec 2010 12:55:19 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id CD4253A69CD for ; Thu, 16 Dec 2010 12:55:18 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id oBGKv2XV022121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 14:57:02 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oBGKv169017690 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Dec 2010 14:57:02 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 16 Dec 2010 14:57:01 -0600 From: "Zeltsan, Zachary (Zachary)" To: "'Aaron Parecki'" , Paul Walker Date: Thu, 16 Dec 2010 14:57:01 -0600 Thread-Topic: [OAUTH-WG] expires_at vs expires_in Thread-Index: Acub5fKwcKv+qbR8StWWNbRzgOKefQBcG2Ng Message-ID: <5710F82C0E73B04FA559560098BF95B12505F0405D@USNAVSXCHMBSA3.ndc.alcatel-lucent.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_5710F82C0E73B04FA559560098BF95B12505F0405DUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 16 Dec 2010 20:55:24 -0000 --_000_5710F82C0E73B04FA559560098BF95B12505F0405DUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > One of the first things a client is going to do after receiving the expir= es_in is calculate the current time plus the offset. The client does not need to do that. The draft oauth-v2-v11 does not specify what client has to do with the para= meter expires_in. In fact, it may do nothing. If an access token has expire= d then the resource server rejects the client's request and the client has = to obtain a new access token. Time synchronization is necessary between the authorization and resource se= rvers, but "the methods used by the resource server to validate the access = token are beyond the scope" of the draft. Zachary ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= aron Parecki Sent: Tuesday, December 14, 2010 6:23 PM To: Paul Walker Cc: OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in Agreed. I like the idea of expires_at as well. One of the first things a cl= ient is going to do after receiving the expires_in is calculate the current= time plus the offset. Makes sense to eliminate one source of timing errors= . On Dec 14, 2010 2:54 PM, "Paul Walker" > wrote: > It seems to me that expires_in suffers from the same machine time synchro= nization issue and additionally throws in an indeterminable time amount, wh= ile expires_at would only suffer from the former. > > ~pj > > On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote: > >> expires_at requires very good time synchronization for all machines invo= lved. >> >> expires_in, while not very exact, is more resilient. >> >> Marius >> >> >> >> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate > wrote: >>> I have same question, Thanks Paul for Raising this >>> >>> Regards >>> Jitesh >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oau= th-bounces@ietf.org] On Behalf Of Paul Walke= r >>> Sent: Tuesday, December 14, 2010 4:14 PM >>> To: OAuth WG >>> Subject: [OAUTH-WG] expires_at vs expires_in >>> >>> Has there been discussion of using expires_at as an exact epoch time in= seconds as opposed to expires_in which is, at best, an approximation "from= the time the response was generated by the authorization server?" I apolog= ize if this has been discussed previously. >>> >>> ~pj >>> _______________________________________________ >>> 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_5710F82C0E73B04FA559560098BF95B12505F0405DUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> One of the first things a client is going to do after receivin= g the expires_in is calculate the current time plus the offset.

The client does not need to do that.

The draft oauth-v2-v11 does not specif= y what client has to do with the parameter expires_in. In fact, it may do not= hing. If an access token has expired then the resource server rejects the client&= #8217;s request and the client has to obtain a new access token. =

Time synchronization is necessary betw= een the authorization and resource servers, but “the methods used by the resource server to validate the access token are beyond the scope” of= the draft.

 

Zachary

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Aaron Parecki
Sent: Tuesday, December 14, = 2010 6:23 PM
To: Paul Walker
Cc: OAuth WG
Subject: Re: [OAUTH-WG] expi= res_at vs expires_in

 

Agreed. I like the idea of expires_at as well. One of the first things a client is go= ing to do after receiving the expires_in is calculate the current time plus the offset. Makes sense to eliminate one source of timing errors.

On Dec 14, 2010 2:54 PM, "Paul Walker" <pjwalker@gmail.com> wrote:
> It seems to me that expires_in suffers from the same machine time synchronization issue and additionally throws in an indeterminable time amo= unt, while expires_at would only suffer from the former.
>
> ~pj
>
> On Dec 14, 2010, at 1:35 PM, Marius Scurtescu wrote:
>
>> expires_at requires very good time synchronization for all machine= s involved.
>>
>> expires_in, while not very exact, is more resilient.
>>
>> Marius
>>
>>
>>
>> On Tue, Dec 14, 2010 at 1:24 PM, Jitesh Bhate <jbhate@exacttarget.com> wrote= :
>>> I have same question, Thanks Paul for Raising this
>>>
>>> Regards
>>> Jitesh
>>>
>>> -----Original Message-----
>>> From: oauth-bounces@= ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Paul Walker
>>> Sent: Tuesday, December 14, 2010 4:14 PM
>>> To: OAuth WG
>>> Subject: [OAUTH-WG] expires_at vs expires_in
>>>
>>> Has there been discussion of using expires_at as an exact epoc= h time in seconds as opposed to expires_in which is, at best, an approximatio= n "from the time the response was generated by the authorization server?" I apologize if this has been discussed previously.
>>>
>>> ~pj
>>> _______________________________________________
>>> 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.ie= tf.org/mailman/listinfo/oauth

--_000_5710F82C0E73B04FA559560098BF95B12505F0405DUSNAVSXCHMBSA_-- From subbu@subbu.org Sun Dec 19 15: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 8AED73A6954 for ; Sun, 19 Dec 2010 15:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 te0vA7NzTwKU for ; Sun, 19 Dec 2010 15:38:05 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 715963A694F for ; Sun, 19 Dec 2010 15:38:05 -0800 (PST) Received: by gyd12 with SMTP id 12so1051602gyd.31 for ; Sun, 19 Dec 2010 15:39:57 -0800 (PST) Received: by 10.150.12.20 with SMTP id 20mr5496228ybl.295.1292801997068; Sun, 19 Dec 2010 15:39:57 -0800 (PST) Received: from [192.168.11.59] (c-98-225-24-91.hsd1.wa.comcast.net [98.225.24.91]) by mx.google.com with ESMTPS id l4sm7017286ybj.21.2010.12.19.15.39.54 (version=SSLv3 cipher=RC4-MD5); Sun, 19 Dec 2010 15:39:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Subbu Allamaraju In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B065C8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 19 Dec 2010 15:39:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9D9D7BFD-62F5-4480-88DE-84C4D36567F2@subbu.org> References: <69A9A98B-89A1-4C42-88C2-AC682C1827AB@subbu.org> <90C41DD21FB7C64BB94121FBBC2E72343D4B065B2A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <174D976E-CCA1-476B-8257-F87DCDF1AAA7@subbu.org> <90C41DD21FB7C64BB94121FBBC2E72343D4B065C8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Comment on 'application/x-www-form-urlencoded' for URI parameters X-BeenThere: oauth@ietf.org X-Mailman-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, 19 Dec 2010 23:38:06 -0000 This is a minor point, but for a spec, it is better to be precise than = rely on conventions. The spec should at least say where it differs from = the application/x-www-form-urlencoded encoding algorithm (such as using = UTF-8 encoding for all octets including 0x20).=20 My 2 cents. Subbu On Dec 2, 2010, at 11:26 AM, Eran Hammer-Lahav wrote: > Using form-encoding to encode the URI query is well established and = directly based on the media type rules. No further specification is = needed. >=20 > EHL >=20 >> -----Original Message----- >> From: Subbu Allamaraju [mailto:subbu@subbu.org] >> Sent: Thursday, December 02, 2010 11:21 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Comment on 'application/x-www-form- >> urlencoded' for URI parameters >>=20 >> Eran - but that does change anything. That HTML4/HTML5 media type = does >> not specify how to encode parameters into query portion of URIs. I'm = not >> aware of any RFC that describes this name=3Dvalue pair encoding. So, = OAuth >> draft needs to specify how a client needs to manipulate auth/resource >> server's URIs to add protocol-specific parameters. >>=20 >> Subbu >>=20 >> On Dec 1, 2010, at 2:16 PM, Eran Hammer-Lahav wrote: >>=20 >>> The latest reference is: >>>=20 >>> http://www.w3.org/TR/html5/association-of-controls-and- >> forms.html#appl >>> ication-x-www-form-urlencoded-encoding-algorithm >>>=20 >>> But that's still a draft. >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Subbu Allamaraju >>>> Sent: Wednesday, December 01, 2010 2:05 PM >>>> To: OAuth WG >>>> Subject: [OAUTH-WG] Comment on 'application/x-www-form- >> urlencoded' >>>> for URI parameters >>>>=20 >>>> Here is some feedback on the use of the 'application/x-www-form- >>>> urlencoded' media type in the latest drafts (10 or 11). >>>>=20 >>>> The draft refers to the 'application/x-www-form-urlencoded' media >>>> type for encoding parameters into the query component of URIs. For >>>> instance, see >>>> 4.1 in draft 11 has >>>>=20 >>>> "In order to direct the end-user's user-agent to the authorization >>>> server, the client constructs the request URI by adding the = following >>>> parameters to the end-user authorization endpoint URI query >> component >>>> using the "application/x-www-form-urlencoded" format as defined by >>>> [W3C.REC-html401-19991224]" >>>>=20 >>>> However, this media type specifies how to encode parameters in the >>>> body of a representation but not in URIs. In fact use of this >>>> encoding for characters like spaces will break URIs. >>>>=20 >>>> Subbu >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From pierre.ruyssen@gmail.com Mon Dec 20 02:05: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 BEB9D3A67E6 for ; Mon, 20 Dec 2010 02:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BaFI0sFM4Fhs for ; Mon, 20 Dec 2010 02:05:52 -0800 (PST) Received: from mail-bw0-f50.google.com (mail-bw0-f50.google.com [209.85.214.50]) by core3.amsl.com (Postfix) with ESMTP id 8803C3A67E9 for ; Mon, 20 Dec 2010 02:05:52 -0800 (PST) Received: by bwg12 with SMTP id 12so3174696bwg.37 for ; Mon, 20 Dec 2010 02:07:45 -0800 (PST) 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=WmCAlrWlUOEQaQxJjyZw+ING0T7O3PNQlmFjti8y2Dk=; b=X8UjVri/Wc5w74KvzsbPweMwZ0JpF1qZ01T6Up3fl7RTeC5/qV+77vFG09ikCLhJCg cOJtdHY0yhN03dKeCgNc65ZRXAkSqRcyVaSjydp2Et/FQCwap25ESn0u7NVDmxBcirBT LKjHAgxVJ0QMYO1yfrSyw20yTr9VHOOFQ/hBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oczW0EHnoKTyUcCMvCZQsN16wJw4J+eVbu6kWe3M2rxVNjNndVjpB+slGqBYv8XTZM Wgzf0vpNvP4ZNkZUF8nuoPM7bK51ZdV650fH/3ROPTKtxIULVWBbtoCol1UkIuPy5n+O maubgwrWQpf7Z75EDtHczAyqaJGvbBWK7fW4Y= MIME-Version: 1.0 Received: by 10.204.72.207 with SMTP id n15mr3331199bkj.62.1292839665205; Mon, 20 Dec 2010 02:07:45 -0800 (PST) Received: by 10.204.69.75 with HTTP; Mon, 20 Dec 2010 02:07:45 -0800 (PST) Date: Mon, 20 Dec 2010 11:07:45 +0100 Message-ID: From: Pierre Ruyssen To: OAuth WG Content-Type: multipart/alternative; boundary=001636d34c44ff01ee0497d4b073 Subject: [OAUTH-WG] OAuth2.0 client and server in Node.js X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Dec 2010 10:05:53 -0000 --001636d34c44ff01ee0497d4b073 Content-Type: text/plain; charset=UTF-8 Hello, I have started 3 projects around OAuth2 (draft 10 for now), and I thought you could be interested in it: - https://github.com/AF83/oauth2_client_node - https://github.com/AF83/oauth2_server_node - https://github.com/AF83/auth_server Feedbacks are welcome, Cheers, Pierre --001636d34c44ff01ee0497d4b073 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello,

I have started 3 projects around OAuth2 (draft 10= for now), and I thought you could be interested in it:

Feedbacks are welcome,
Cheers,
Pierre
<= meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"> --001636d34c44ff01ee0497d4b073-- From kristoffer.gronowski@ericsson.com Mon Dec 20 09:48: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 6BD793A68D5 for ; Mon, 20 Dec 2010 09:48:57 -0800 (PST) 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 6orO3wx1wI3K for ; Mon, 20 Dec 2010 09:48:56 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 27AB63A67D4 for ; Mon, 20 Dec 2010 09:48:56 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oBKINF2Z018453 for ; Mon, 20 Dec 2010 12:23:16 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 20 Dec 2010 12:50:44 -0500 From: Kristoffer Gronowski To: "oauth@ietf.org" Date: Mon, 20 Dec 2010 12:50:43 -0500 Thread-Topic: Opensource REST base Java impl of Oauth2 Thread-Index: AcugbDeQ7tngaON/Tz6dFlBWoZFlvQAALf7w Message-ID: 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_C0AC8FAB6849AB4FADACCC70A949E2F1092A68A03EEUSAACMS0701e_" MIME-Version: 1.0 Subject: [OAUTH-WG] Opensource REST base Java impl of Oauth2 X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Dec 2010 17:48:57 -0000 --_000_C0AC8FAB6849AB4FADACCC70A949E2F1092A68A03EEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! Just wanted to let any developers on the list know that we have released a = Oauth2 REST Java library in collaboration with the Restlet community. All the source is open and part of the Restlet incubator until we get into = a more stable phase in the spec. At the moment draft 10 is implemented and 3 different flows: webclient, use= r agent and none. (token refresh is also in place). Except of this we are also hosting a auth server for inter-op testing at ht= tp://labs.ericsson.com and we try to blog and promote the technology going = forward. The code is not entirely new since we have been using it from draft 00 and = on for internal purposes. If you want to look at the code it is located at http://restlet.tigris.org/= source/browse/restlet/trunk/incubator/ And the day to day working page at Restlet wiki. http://wiki.restlet.org/de= velopers/257-restlet/310-restlet.html For identity part we are using OpenID only but anyone with the code can cha= nge that part and implement whatever. Here is a small Youtube clip that show a sample service http://www.youtube.com/watch?v=3DH9R4OyVeSeo Please give feedback and draft 11 will be up and running soon. BR Kristoffer --_000_C0AC8FAB6849AB4FADACCC70A949E2F1092A68A03EEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi!
 
Just wanted to let any developers on the list = know that we have released a Oauth2 REST Java library in collaboration with= the Restlet community.
All the source is open and part of the Restlet= incubator until we get into a more stable phase in the spec.
At the moment draft 10 is implemented and 3 di= fferent flows: webclient, user agent and none. (token refresh is also in pl= ace).
Except of this we are also hosting a auth serv= er for inter-op testing at http://l= abs.ericsson.com and we try to blog and promote the technology goin= g forward.
 
The code is not entirely new since we have bee= n using it from draft 00 and on for internal purposes.
If you want to look at the code it is located = at http://restlet.tigris.org/source/browse/restlet/trunk/incubator/
And the day to day working page at Restlet wik= i. http://wiki.restlet.org/developers/257-restlet/310-restlet.html<= /a>
 
For identity part we are using OpenID only but anyone with the code ca= n change that part and implement whatever.
Here is a small Youtube clip that show a sample service
 
 
 
<object width=3D"425" height=3D"344"><par= am name=3D"movie" value=3D"http://www.youtube.com/v/H9R4OyVe= Seo?hl=3Dsv&fs=3D1"></param><param name=3D"allowF= ullScreen" value=3D"true"></param><param name=3D= "allowscriptaccess" value=3D"always"></param>&= lt;embed src=3D"http://www.youtube.com/v/H9R4OyVeSeo?hl=3Dsv&fs=3D= 1" type=3D"application/x-shockwave-flash" allowscriptaccess=3D"= always" allowfullscreen=3D"true" width=3D"425" hei= ght=3D"344"></embed></object>
 
Please give feedback and draft 11 will be up a= nd running soon.
 
BR Kristoffer
 
 --_000_C0AC8FAB6849AB4FADACCC70A949E2F1092A68A03EEUSAACMS0701e_-- From fcorella@pomcor.com Wed Dec 22 09:55: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 883253A6BBC for ; Wed, 22 Dec 2010 09:55:53 -0800 (PST) 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 2YKmP2QaWx0X for ; Wed, 22 Dec 2010 09:55:52 -0800 (PST) Received: from nm26-vm0.bullet.mail.ac4.yahoo.com (nm26-vm0.bullet.mail.ac4.yahoo.com [98.139.52.242]) by core3.amsl.com (Postfix) with SMTP id 64C923A6B2A for ; Wed, 22 Dec 2010 09:55:52 -0800 (PST) Received: from [98.139.52.195] by nm26.bullet.mail.ac4.yahoo.com with NNFMP; 22 Dec 2010 17:57:48 -0000 Received: from [98.139.52.129] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 22 Dec 2010 17:57:48 -0000 Received: from [127.0.0.1] by omp1012.mail.ac4.yahoo.com with NNFMP; 22 Dec 2010 17:57:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 228429.99177.bm@omp1012.mail.ac4.yahoo.com Received: (qmail 31904 invoked by uid 60001); 22 Dec 2010 17:57:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1293040668; bh=3D+7qt9QkDCm2kE+GGhJVdhdR/0XyA04OSlnNtaeQUc=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=GOuoTdRpaQjnekWyU2zxCAzA4VlTiLYczRcbgpnZp7kEf0E9ptH8W4EFcubwbUiI7r5IycZmMDR4hpsnd5mM/JxgTpOQ8na5dzccsRMEpz0gUnsU3VQJiGHzX1+lDDPOCC3yeOzEmxbgKBlJSmM09p1e86Wst80MUW5u9iYaNLs= Message-ID: <132020.31505.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: WPkFGRsVM1kE3jQiSPoCJD.O_Oag40ccH5eIbfAihf4HjLc kyEbvWcQ6JnNfUr_1k7ggOZ29EZHxyI.7iaOiKoIFE5DhWe7xFNmqPXBz3i2 tlr25RJqBSONwnJKfZF4QQPDjAvPIxoodfpv7TVS.r_uWALq496e1HzXqX4e utV8dRoLnTlQkGB9u5tJecuo9h2orrLQ1Lrd0RXHmtDy_jd.4kj4kIaC3Vtr WvaF3Ekw.oHz6knYehqfDaKrpKM5ibrvSeZZPZkBCGUt9lwAsdXCUN8Inh45 .zw9tp5qnCBZxUXDQKYJU7S3BL_nsDywOMTeZT9_pKN1rdpBw0HILRW9l0Du JLHg85ersykNa86mL5HnpKpaCMBOinFacWV9SYnAPyFsboh3am11d9Jud9eU UaMc- Received: from [67.91.91.101] by web55801.mail.re3.yahoo.com via HTTP; Wed, 22 Dec 2010 09:57:48 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Wed, 22 Dec 2010 09:57:48 -0800 (PST) From: Francisco Corella To: oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1549845165-1293040668=:31505" Subject: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:55:53 -0000 --0-1549845165-1293040668=:31505 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, OAuth provides only weak security when used with unregistered applications.=A0 OTOH compulsory registration is a bad idea: imagine a situation where a social site becomes dominant, social login via that site becomes the de facto authentication standard on the Web, every application has to register with the site, and the site can kill any application by revoking its registration.=A0 I've written a paper that proposes a solution.=A0 Thanks in advance for any comments. -- Francisco --0-1549845165-1293040668=:31505 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

OAuth provides only weak secur= ity when used with
unregistered applications.  OTOH compulsory regi= stration is
a bad idea: imagine a situation where a social site becomes<= br>dominant, social login via that site becomes the de facto
authenticat= ion standard on the Web, every application has to
register with the site= , and the site can kill any
application by revoking its registration.&nb= sp; I've written a
paper that proposes a solution.  Thanks in advance for any
= comments.

-- Francisco

--0-1549845165-1293040668=:31505-- From pelle@kodfabrik.se Thu Dec 23 02: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 1018A3A6AF6 for ; Thu, 23 Dec 2010 02:37:59 -0800 (PST) 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 Xxb-pnE-7Ci2 for ; Thu, 23 Dec 2010 02:37:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 43EDF3A6B20 for ; Thu, 23 Dec 2010 02:37:58 -0800 (PST) Received: by iyi42 with SMTP id 42so5280969iyi.31 for ; Thu, 23 Dec 2010 02:39:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.15.5 with SMTP id i5mr7748492iba.149.1293100798008; Thu, 23 Dec 2010 02:39:58 -0800 (PST) Received: by 10.231.52.200 with HTTP; Thu, 23 Dec 2010 02:39:57 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Dec 2010 11:39:57 +0100 Message-ID: From: Pelle Wessman To: Paul Walker Content-Type: multipart/alternative; boundary=00221534d4cfb95d270498117d33 Cc: OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Dec 2010 10:37:59 -0000 --00221534d4cfb95d270498117d33 Content-Type: text/plain; charset=ISO-8859-1 For the Web Server flow you will have a HTTP Date header containing the timestamp at which the token was generated - right? Combining the value of that header with expires_in will get you the value of expires_at. / Pelle On Tue, Dec 14, 2010 at 10:14 PM, Paul Walker wrote: > Has there been discussion of using expires_at as an exact epoch time in > seconds as opposed to expires_in which is, at best, an approximation "from > the time the response was generated by the authorization server?" I > apologize if this has been discussed previously. > > ~pj > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00221534d4cfb95d270498117d33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For the Web Server flow you will have a HTTP Date header containing the tim= estamp at which the token was generated - right? Combining the value of tha= t header with expires_in will get you the value of expires_at.

/ Pel= le

On Tue, Dec 14, 2010 at 10:14 PM, Paul Walke= r <pjwalker@gmai= l.com> wrote:
Has there been discussion of using expires_at as an exact epoch time in sec= onds as opposed to expires_in which is, at best, an approximation "fro= m the time the response was generated by the authorization server?" = =A0I apologize if this has been discussed previously.

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

--00221534d4cfb95d270498117d33-- From rs@dailymotion.com Thu Dec 23 02:41: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 AC7B83A6AF2 for ; Thu, 23 Dec 2010 02:41:22 -0800 (PST) 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 Pk39A2t8nGQp for ; Thu, 23 Dec 2010 02:41:21 -0800 (PST) Received: from intsvc-01.dailymotion.com (intsvc-01.dailymotion.com [195.8.215.87]) by core3.amsl.com (Postfix) with ESMTP id 7C6493A6AF6 for ; Thu, 23 Dec 2010 02:41:21 -0800 (PST) Received: from EXCHANGE-02.daily.local (unknown [195.8.215.118]) by intsvc-01.dailymotion.com (Postfix) with ESMTP id 0724448364; Thu, 23 Dec 2010 11:43:21 +0100 (CET) Received: from EXCHANGE-02.daily.local ([195.8.215.118]) by exchange-02 ([195.8.215.118]) with mapi; Thu, 23 Dec 2010 11:39:19 +0100 From: Olivier POITREY To: Pelle Wessman Date: Thu, 23 Dec 2010 11:43:12 +0100 Thread-Topic: [OAUTH-WG] expires_at vs expires_in Thread-Index: AcuijadQQM4YYe9WQqOkHncuob7f+A== Message-ID: <3772D688-B518-4956-A763-B8E80E1A677E@dailymotion.com> References: In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, fr-FR Content-Type: multipart/alternative; boundary="_000_3772D688B5184956A763B8E80E1A677Edailymotioncom_" MIME-Version: 1.0 Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Dec 2010 10:41:22 -0000 --_000_3772D688B5184956A763B8E80E1A677Edailymotioncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNhbid0IGFjY2VzcyBpdCBmcm9tIEphdmFTY3JpcHQgaW4gbW9zdCB1c2UtY2FzZXMgdW5m b3J0dW5hdGVseS4gSXQncyB3aHkgaGF2aW5nIGJvdGggZXhwaXJlc19pbiBhbmQgZXhwaXJlc19h dCB3b3VsZCBiZSBuaWNlLg0KDQpPbiAyMyBkw6ljLiAyMDEwLCBhdCAxMTozNiwgIlBlbGxlIFdl c3NtYW4iIDxwZWxsZUBrb2RmYWJyaWsuc2U8bWFpbHRvOnBlbGxlQGtvZGZhYnJpay5zZT4+IHdy b3RlOg0KDQpGb3IgdGhlIFdlYiBTZXJ2ZXIgZmxvdyB5b3Ugd2lsbCBoYXZlIGEgSFRUUCBEYXRl IGhlYWRlciBjb250YWluaW5nIHRoZSB0aW1lc3RhbXAgYXQgd2hpY2ggdGhlIHRva2VuIHdhcyBn ZW5lcmF0ZWQgLSByaWdodD8gQ29tYmluaW5nIHRoZSB2YWx1ZSBvZiB0aGF0IGhlYWRlciB3aXRo IGV4cGlyZXNfaW4gd2lsbCBnZXQgeW91IHRoZSB2YWx1ZSBvZiBleHBpcmVzX2F0Lg0KDQovIFBl bGxlDQoNCk9uIFR1ZSwgRGVjIDE0LCAyMDEwIGF0IDEwOjE0IFBNLCBQYXVsIFdhbGtlciA8PG1h aWx0bzpwandhbGtlckBnbWFpbC5jb20+cGp3YWxrZXJAZ21haWwuY29tPG1haWx0bzpwandhbGtl ckBnbWFpbC5jb20+PiB3cm90ZToNCkhhcyB0aGVyZSBiZWVuIGRpc2N1c3Npb24gb2YgdXNpbmcg ZXhwaXJlc19hdCBhcyBhbiBleGFjdCBlcG9jaCB0aW1lIGluIHNlY29uZHMgYXMgb3Bwb3NlZCB0 byBleHBpcmVzX2luIHdoaWNoIGlzLCBhdCBiZXN0LCBhbiBhcHByb3hpbWF0aW9uICJmcm9tIHRo ZSB0aW1lIHRoZSByZXNwb25zZSB3YXMgZ2VuZXJhdGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNl cnZlcj8iICBJIGFwb2xvZ2l6ZSBpZiB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBwcmV2aW91c2x5 Lg0KDQp+cGoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCjxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+T0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_3772D688B5184956A763B8E80E1A677Edailymotioncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5Zb3UgY2FuJ3QgYWNjZXNzIGl0IGZy b20gSmF2YVNjcmlwdCBpbiBtb3N0IHVzZS1jYXNlcyB1bmZvcnR1bmF0ZWx5LiBJdCdzIHdoeSBo YXZpbmcgYm90aCBleHBpcmVzX2luIGFuZCBleHBpcmVzX2F0IHdvdWxkIGJlIG5pY2UuPGJyPjxi cj5PbiAyMyBkw6ljLiAyMDEwLCBhdCAxMTozNiwgIlBlbGxlIFdlc3NtYW4iICZsdDs8YSBocmVm PSJtYWlsdG86cGVsbGVAa29kZmFicmlrLnNlIj5wZWxsZUBrb2RmYWJyaWsuc2U8L2E+Jmd0OyB3 cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp dj5Gb3IgdGhlIFdlYiBTZXJ2ZXIgZmxvdyB5b3Ugd2lsbCBoYXZlIGEgSFRUUCBEYXRlIGhlYWRl ciBjb250YWluaW5nIHRoZSB0aW1lc3RhbXAgYXQgd2hpY2ggdGhlIHRva2VuIHdhcyBnZW5lcmF0 ZWQgLSByaWdodD8gQ29tYmluaW5nIHRoZSB2YWx1ZSBvZiB0aGF0IGhlYWRlciB3aXRoIGV4cGly ZXNfaW4gd2lsbCBnZXQgeW91IHRoZSB2YWx1ZSBvZiBleHBpcmVzX2F0Ljxicj48YnI+LyBQZWxs ZTxicj4NCjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBEZWMgMTQsIDIwMTAg YXQgMTA6MTQgUE0sIFBhdWwgV2Fsa2VyIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFp bHRvOnBqd2Fsa2VyQGdtYWlsLmNvbSI+PGEgaHJlZj0ibWFpbHRvOnBqd2Fsa2VyQGdtYWlsLmNv bSI+cGp3YWxrZXJAZ21haWwuY29tPC9hPjwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleDsiPg0KSGFzIHRoZXJlIGJlZW4g ZGlzY3Vzc2lvbiBvZiB1c2luZyBleHBpcmVzX2F0IGFzIGFuIGV4YWN0IGVwb2NoIHRpbWUgaW4g c2Vjb25kcyBhcyBvcHBvc2VkIHRvIGV4cGlyZXNfaW4gd2hpY2ggaXMsIGF0IGJlc3QsIGFuIGFw cHJveGltYXRpb24gImZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQgYnkg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyPyIgJm5ic3A7SSBhcG9sb2dpemUgaWYgdGhpcyBoYXMg YmVlbiBkaXNjdXNzZWQgcHJldmlvdXNseS48YnI+DQoNCjxicj4NCn5wajxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L2E+PGJyPg0K PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4NCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5PQXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJy PjxzcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+ PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_3772D688B5184956A763B8E80E1A677Edailymotioncom_-- From mscurtescu@google.com Thu Dec 23 10:10: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 C2D733A685E for ; Thu, 23 Dec 2010 10:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.94 X-Spam-Level: X-Spam-Status: No, score=-105.94 tagged_above=-999 required=5 tests=[AWL=0.038, 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 xYrKkud4Qnyd for ; Thu, 23 Dec 2010 10:10:19 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B3FBA3A6864 for ; Thu, 23 Dec 2010 10:10:18 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id oBNICIjK005457 for ; Thu, 23 Dec 2010 10:12:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293127939; bh=D9QLZCbgrjA7MMBWj8xfkrxb1R0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=gMABn61KgjFg4wdySbiQwGbolqbUMP9HWfdxhpydKIU7+NdeJ0hf5DX3JLU70yCni L8IKVGxhGl0fVZ4wP6qgA== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by wpaz1.hot.corp.google.com with ESMTP id oBNIBDEm004488 for ; Thu, 23 Dec 2010 10:12:17 -0800 Received: by yxm8 with SMTP id 8so3564460yxm.7 for ; Thu, 23 Dec 2010 10:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=R9YmIiNDYAoGZiZdgM6ydYMUlV+nutWVCbAaPfrx3e0=; b=MsSgL72cKe2gH5Rfl12ukLvvhQ9JTLZPyRMwWlHqOVCLe6kKnbtG9yNVhcppEJHvGt rGzTUeMnWvVsL43GWZsg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=uwU+3ag9s4856T3EbEjuhGNePnownbgxFg95s4Bbd4x6o37SmlOZsZ6rTZNcfhx8Gy 64p7XZ2GT0HqwObR4moQ== Received: by 10.100.31.9 with SMTP id e9mr5191323ane.162.1293127937640; Thu, 23 Dec 2010 10:12:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Thu, 23 Dec 2010 10:11:57 -0800 (PST) In-Reply-To: <3772D688-B518-4956-A763-B8E80E1A677E@dailymotion.com> References: <3772D688-B518-4956-A763-B8E80E1A677E@dailymotion.com> From: Marius Scurtescu Date: Thu, 23 Dec 2010 10:11:57 -0800 Message-ID: To: Olivier POITREY Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Dec 2010 18:10:23 -0000 This expiration time is just a hint, client code should work perfectly fine without it, or with a wrong one. Trying to understand the use case here: JavaScript code receives an access token and the associated expires_in. It passes the access token to backend code, and this backend code is properly time synchronized and it needs to know when does the token expire. Right? Is the JavaScript code passing the access token down right away, or only after a while? If right away, then the backend code can just use expires_in as an offset from current time. It will be a few seconds off, but that should be acceptable IMO. Marius On Thu, Dec 23, 2010 at 2:43 AM, Olivier POITREY wrote= : > You can't access it from JavaScript in most use-cases unfortunately. It's > why having both expires_in and expires_at would be nice. > > On 23 d=E9c. 2010, at 11:36, "Pelle Wessman" wrote: > > For the Web Server flow you will have a HTTP Date header containing the > timestamp at which the token was generated - right? Combining the value o= f > that header with expires_in will get you the value of expires_at. > > / Pelle > > On Tue, Dec 14, 2010 at 10:14 PM, Paul Walker wrote: >> >> Has there been discussion of using expires_at as an exact epoch time in >> seconds as opposed to expires_in which is, at best, an approximation "fr= om >> the time the response was generated by the authorization server?" =A0I >> apologize if this has been discussed previously. >> >> ~pj >> _______________________________________________ >> 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 Thu Dec 23 12: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 8F0FD3A6892 for ; Thu, 23 Dec 2010 12:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.943 X-Spam-Level: X-Spam-Status: No, score=-105.943 tagged_above=-999 required=5 tests=[AWL=0.033, 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 PJNXaBBuL1Fq for ; Thu, 23 Dec 2010 12:30:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A31DF3A688E for ; Thu, 23 Dec 2010 12:30:27 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id oBNKWSaE005421 for ; Thu, 23 Dec 2010 12:32:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293136348; bh=W+RgMfp6Wx/kA5hwDCYE3NKKVCs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ewDvrM/tr6WjubJ61F6oA0petbqteIpt5DYzyx0JL5EAaNTUyiVhvrtKKN1wYnho/ gx/onsifsmaDzp7i44Peg== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by wpaz24.hot.corp.google.com with ESMTP id oBNKWRhW029683 for ; Thu, 23 Dec 2010 12:32:27 -0800 Received: by yxm8 with SMTP id 8so3622781yxm.7 for ; Thu, 23 Dec 2010 12:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=UCfRr31XjjbjOA1+krEo9DlXs/4fnIHWeCl8wFePkYs=; b=UdiYI/fL7/yc9ZwZSj2kGG/6hniPp6HNIltWIQ7t/ch+G6qI2JaucWNkkYr0ndn/Yp K2NyJ2mXfGXYQ3EuQjag== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=QJv7xyLHi8XxzADUQAOD+UgxzdxbvxPhw2NUYb4bNQztVOudelki3obowMpIOifnVM X91a7Sasxn50vkJ2Tnfg== Received: by 10.100.31.9 with SMTP id e9mr5284285ane.162.1293136347144; Thu, 23 Dec 2010 12:32:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Thu, 23 Dec 2010 12:32:07 -0800 (PST) In-Reply-To: <132020.31505.qm@web55801.mail.re3.yahoo.com> References: <132020.31505.qm@web55801.mail.re3.yahoo.com> From: Marius Scurtescu Date: Thu, 23 Dec 2010 12:32:07 -0800 Message-ID: To: fcorella@pomcor.com Content-Type: multipart/alternative; boundary=0016e644df669e2349049819c477 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Dec 2010 20:30:29 -0000 --0016e644df669e2349049819c477 Content-Type: text/plain; charset=ISO-8859-1 Hi Francisco, PKAuth seems similar to OAuth 2, I think it would help if you used the same terminology: - application => client - social site => authorization server - client => end user - reference code => authorization code The paper claims that users do not know how to interpret domain names, which is probably true. Is there any evidence that users are doing better with names as found in SSL certificates? Discovery is based on link tags in HTML pages, did you consider using /.well-known/host-meta instead? At step 1, the difference between official-name and alternative-name can only be "www.". Why not just follow redirects? Not sure I understand why the reference code must be generated by the social site, how would session fixation work if it was generated by the application? The social site most likely has a large number of API endpoints, providing only one pkauth-subsequent-access does not scale. Or maybe I misunderstood the purpose of pkauth-subsequent-access. PKAuth would work only for web applications and compared to OAuth 2 it raises the bar for them: they need an SSL cert and also an API endpoint. Especially web app only, is a very strong limitation. Marius On Wed, Dec 22, 2010 at 9:57 AM, Francisco Corella wrote: > Hi all, > > OAuth provides only weak security when used with > unregistered applications. OTOH compulsory registration is > a bad idea: imagine a situation where a social site becomes > dominant, social login via that site becomes the de facto > authentication standard on the Web, every application has to > register with the site, and the site can kill any > application by revoking its registration. I've written a > paper that proposes a > solution. Thanks in advance for any > comments. > > -- Francisco > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016e644df669e2349049819c477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Francisco,

PKAuth seems similar to OAuth 2, I think it would help= if you used the same terminology:
- application =3D> client
- soc= ial site =3D> authorization server
- client =3D> end user
- ref= erence code =3D> authorization code

The paper claims that users do not know how to interpret domain names, = which is probably true. Is there any evidence that users are doing better w= ith names as found in SSL certificates?

Discovery is based on link t= ags in HTML pages, did you consider using /.well-known/host-meta instead?
At step 1, the difference between official-name and alternative-name ca= n only be "www.". Why not just follow redirects?

Not sure = I understand why the reference code must be generated by the social site, h= ow would session fixation work if it was generated by the application?

The social site most likely has a large number of API endpoints, provid= ing only one pkauth-subsequent-access does not scale. Or maybe I misunderst= ood the purpose of pkauth-subsequent-access.

PKAuth would work only = for web applications and compared to OAuth 2 it raises the bar for them: th= ey need an SSL cert and also an API endpoint. Especially=A0 web app only, i= s a very strong limitation.

Marius


On Wed, Dec 22, 2010 at 9:57 AM, Francis= co Corella <fco= rella@pomcor.com> wrote:
Hi all,

OAuth provides only weak= security when used with
unregistered applications.=A0 OTOH compulsory r= egistration is
a bad idea: imagine a situation where a social site becomes
dominant, so= cial login via that site becomes the de facto
authentication standard on= the Web, every application has to
register with the site, and the site = can kill any
application by revoking its registration.=A0 I've written a
paper that proposes a solution.=A0 Thanks in advance for any
comments.
<= font color=3D"#888888">
-- Francisco


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


--0016e644df669e2349049819c477-- From fcorella@pomcor.com Thu Dec 23 21:36: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 8E0913A68E9 for ; Thu, 23 Dec 2010 21:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OBFU_AMP2B=2.555] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZAB4PrlNGXL for ; Thu, 23 Dec 2010 21:36:13 -0800 (PST) Received: from nm29-vm0.bullet.mail.ac4.yahoo.com (nm29-vm0.bullet.mail.ac4.yahoo.com [98.139.52.248]) by core3.amsl.com (Postfix) with SMTP id EB7973A68E1 for ; Thu, 23 Dec 2010 21:36:12 -0800 (PST) Received: from [98.139.52.194] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 24 Dec 2010 05:38:11 -0000 Received: from [98.139.52.129] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 24 Dec 2010 05:38:11 -0000 Received: from [127.0.0.1] by omp1012.mail.ac4.yahoo.com with NNFMP; 24 Dec 2010 05:38:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 920093.29995.bm@omp1012.mail.ac4.yahoo.com Received: (qmail 19268 invoked by uid 60001); 24 Dec 2010 05:38:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1293169091; bh=vzPu6HuuaBVJfxxqjQmJ6LGF9+9fWtTnS9Vkh8NgWag=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ha9gWLGz3DD24w5/xM4j6RnnzdqmGsFqZQUDRtyPHjuUiFW93C6Q0gggsdPdADelHABkCtQNGjjPoEEO8Z5lyhUeT/F4qO1PuEdB61lv4IXtEF6gYRfiEb1Gf8xqSr/htiY1ec/Q34AfB39PhmM+y75yj3uYC0BhsTsICYWn0n8= Message-ID: <711776.14666.qm@web55806.mail.re3.yahoo.com> X-YMail-OSG: CJ8AobUVM1nko3pKjtgtfFc7qt6Mhhb46q5TFyv_baV0zb_ C3d3Bv976GAjrVHIeaKyz6b38zBmBtq9TFSBR8IWIvgisaZVrDC18UhUP4Do 7IgXWIO8X5cZXinSVTQTE8KMCQoMDbpDuxECT7BkUth4sy20Lw0j3JfB0gvx TdPokdkLsWh1v8qe5wino5T0L3AfjLaTCTU9vKBzm66T_xbxeIhqvdIzXwpI zIOcRTX9qIyfDryrfg4DCoTjX4iMPf5TUnk7ZgKQGp5gLgucK9Gf1JM2H2vB Oc6FId_uWmHwJr6dPOaw3jFkZKb71Sd5ESJ2WaGN8bkDn4G53KhFPobVznmn Uqa_x6L9k8kC6onM9lLcjgGlxIh94RsYREtBtzIe23ee5sKPghQA6.H3VCTT ziAA- Received: from [174.65.103.16] by web55806.mail.re3.yahoo.com via HTTP; Thu, 23 Dec 2010 21:38:11 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Thu, 23 Dec 2010 21:38:11 -0800 (PST) From: Francisco Corella To: Marius Scurtescu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-885575584-1293169091=:14666" Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 05:36:15 -0000 --0-885575584-1293169091=:14666 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marius, Thank you very much for your detailed reading of the paper and your very useful comments.=A0 I've revised the paper based on your comments and put a new version online, with an acknowledgment of your contribution. > PKAuth seems similar to OAuth 2, I think it would help if you used the sa= me terminology: > - application =3D> client > - social site =3D> authorization server > - client =3D> end user > - reference code =3D> authorization code PKAuth provides the functionality of both OAuth and OpenID, which use different terminologies.=A0 And OAuth 1.0 and RFC 5849 also have different terminologies, which people still seem to be using.=A0 So there are 4 different "formal" terminologies.=A0 I decided to use an "informal" one, at least at this early stage, that can be understood without having to look up definitions in a terminology section. I did not mean to use "client" for "end user".=A0 I've rechecked the paper and I see that I used "client" once, by mistake, where I should have said "application".=A0 That must have been confusing.=A0 I've fixed it. > The paper claims that users do not know how to interpret > domain names, which is probably true. Is there any evidence > that users are doing better with names as found in SSL > certificates? I don't know of any evidence, but that's because users do not usually see the information in the certificate.=A0 I said in the abstract that browsers display certificate information, but that was a mistake: the user has to do some clicking to see it.=A0 The browser does not have real estate to display certificate info without clicking, but in PKAuth the social site has plenty of real estate in the page where it asks the user whether the application is to be trusted. So this is a new way of using the information in the certificate.=A0 It would be interesting to do a study to see how much it helps. > Discovery is based on link tags in HTML pages, did you > consider using /.well-known/host-meta instead? To be honest, I was not aware of that.=A0 Now I've looked at it and I see that that it would make it possible to support multiple social sites having URLs with the same host name. But on the other hand it adds complexity, and I was trying to keep the protocol as simple as possible, so I'm not sure if it's a good idea. > At step 1, the difference between official-name and > alternative-name can only be "www.". Why not just follow > redirects? You're very right, the social site should redirect from https://alternative-name to https://official-name rather providing a PKAuth link element in https://alternative-name.=A0 I've fixed that. > Not sure I understand why the reference code must be > generated by the social site, how would session fixation > work if it was generated by the application? Suppose the protocol requires the application to send the reference code as an additional parameter in step 2.=A0 Here is the attack scenario.=A0 The attacker is a Web user who does not have an account at the application nor at the social site.=A0 The attacker takes advantage of a victim who has an account at both the application and the social site.=A0 The attacker makes a login request to the application, and chooses to use the social site for authentication.=A0 The application provides a response that redirects to the site. The attacker uses an ad-hoc user agent that does not follow up on the redirect, but reports instead the redirect URL, which contains the reference code, to the attacker.=A0 The attacker creates a link whose target is the redirect URL, places it on a Web page, and tricks the victim into clicking on the link.=A0 The social site authenticates the victim (step 4), sends the reference code, authorization token, etc., to the direct callback endpoint of the application (step 5), then sends the reference code, etc., to the redirect callback endpoint by redirecting the victim's browser (step 7).=A0 But the attacker knows the reference code and can send the same request to the redirect callback endpoint.=A0 So the victim and the attacker both send a request with the reference code to the redirect callback endpoint.=A0 In step 8, when the application receives a request at the redirect callback endpoint, it uses the reference code to locate the authorization code and other info received earlier through the direct callback endpoint, and it logs in the user and sets an authentication cookie in the user's browser.=A0 If the attacker's request arrives before the victim's request, the attacker will be logged in and an authentication cookie will be placed in the attacker's browser.=A0 If the victim's request arrives first the victim will be logged in but, if the application takes no precautions, it may later log in the attacker too. > The social site most likely has a large number of API > endpoints, providing only one pkauth-subsequent-access does > not scale. Or maybe I misunderstood the purpose of > pkauth-subsequent-access. Very true.=A0 That was silly of me.=A0 The protocol does not need a pkauth-subsequent-access endpoint.=A0 Once the application has the authorization token it can send it to any API endpoint for subsequent access. > PKAuth would work only for web applications and compared to > OAuth 2 it raises the bar for them: they need an SSL cert > and also an API endpoint. Especially web app only, is a very > strong limitation. Here I have to disagree.=A0=20 First, in OAuth the client is also a Web application, isn't it?=A0 What else could it be?=A0=20 Second, an SSL cert is a requirement for any Web application that authenticates its users, isn't it?=A0=20 Third, what's the problem with an API endpoint?=A0 I assume that by "API endpoint" you mean an endpoint that does not return a Web page to be displayed by a browser.=A0 Well, it's a lot easier to implement an endpoint that does not return a Web page than one that does.=A0 The PKAuth application has two such endpoints, the application authentication endpoint and the direct callback endpoint.=A0 The application authentication endpoint can be as simple as the URL of a static text file with two lines providing the URLs of the direct and redirect callback endpoints.=A0 The direct callback endpoint receives data and stores it in a database record. How long does it take to implement that?=A0 One hour? Actually, I argue that PKAuth is simpler than OAuth because it does not require an intermediate token.=A0 In OAuth two tokens are needed (the access grant and the access token) precisely because of the danger that the first token, send by redirection, may fall into the wrong hands.=A0 In the case of a registered application, the first token is exchanged for the second token only after the appplication has proved its identity.=A0 But if the application is unregistered, the exchange provides no security.=A0 In PKAuth there is only one token, which is sent to the direct callback endpoint and does not run the risk of falling into the wrong hands.=A0 I've added this argument to the paper. Again, thanks a lot! Francisco --0-885575584-1293169091=:14666 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marius,

Thank you very much for you= r detailed reading of the paper
and your very useful comments.  I'v= e revised the paper based
on your comments and put a new version online, with an
ac= knowledgment of your contribution.

> PKAuth seems similar to OAut= h 2, I think it would help if you used the same terminology:
> - appl= ication =3D> client
> - social site =3D> authorization server> - client =3D> end user
> - reference code =3D> authoriza= tion code

PKAuth provides the functionality of both OAuth and OpenID= ,
which use different terminologies.  And OAuth 1.0 and RFC
5849= also have different terminologies, which people still
seem to be using.=   So there are 4 different "formal"
terminologies.  I decided = to use an "informal" one, at least
at this early stage, that can be understood wi= thout having
to look up definitions in a terminology section.

I d= id not mean to use "client" for "end user".  I've rechecked
the pap= er and I see that I used "client" once, by mistake,
where I should have = said "application".  That must have been
confusing.  I've fixe= d it.

> The paper claims that users do not know how to interpret<= br>> domain names, which is probably true. Is there any evidence
>= that users are doing better with names as found in SSL
> certificate= s?

I don't know of any evidence, but that's because users do
not = usually see the information in the certificate.  I said
in the abst= ract that browsers display certificate
information, but that was a mista= ke: the user has to do some
clicking to see it.  The browser does n= ot have real estate
to display certificate info without clicking, but in PKAuth
the social site has plenty of real estate in the page whe= re
it asks the user whether the application is to be trusted.
So this= is a new way of using the information in the
certificate.  It woul= d be interesting to do a study to see
how much it helps.

> Dis= covery is based on link tags in HTML pages, did you
> consider using = /.well-known/host-meta instead?

To be honest, I was not aware of tha= t.  Now I've looked at
it and I see that that it would make it poss= ible to support
multiple social sites having URLs with the same host nam= e.
But on the other hand it adds complexity, and I was trying
to keep= the protocol as simple as possible, so I'm not sure
if it's a good idea= .

> At step 1, the difference between official-name and
> a= lternative-name can only be "www.". Why not just follow
> redirects?<= br>
You're very right, the social site should redirect from
https://alternative-name to https://official-name rather
provid= ing a PKAuth link element in
https://alternative-name.  I've fixed = that.

> Not sure I understand why the reference code must be
&= gt; generated by the social site, how would session fixation
> work i= f it was generated by the application?

Suppose the protocol requires= the application to send the
reference code as an additional parameter i= n step 2.  Here
is the attack scenario.  The attacker is a Web= user who does
not have an account at the application nor at the social<= br>site.  The attacker takes advantage of a victim who has an
accou= nt at both the application and the social site.  The
attacker makes= a login request to the application, and
chooses to use the social site = for authentication.  The
application provides a response that redir= ects to the site.
The attacker uses an ad-hoc user agent that does not follow
up on the redirect, but reports instead the redirect UR= L,
which contains the reference code, to the attacker.  The
atta= cker creates a link whose target is the redirect URL,
places it on a Web= page, and tricks the victim into clicking
on the link.  The social= site authenticates the victim (step
4), sends the reference code, autho= rization token, etc., to
the direct callback endpoint of the application= (step 5),
then sends the reference code, etc., to the redirect
callb= ack endpoint by redirecting the victim's browser (step
7).  But the= attacker knows the reference code and can send
the same request to the = redirect callback endpoint.  So the
victim and the attacker both se= nd a request with the
reference code to the redirect callback endpoint.&= nbsp; In step
8, when the application receives a request at the redirect=
callback endpoint, it uses the reference code to locate the
authorization code and other info received earlier through
the d= irect callback endpoint, and it logs in the user and
sets an authenticat= ion cookie in the user's browser.  If the
attacker's request arrive= s before the victim's request, the
attacker will be logged in and an aut= hentication cookie will
be placed in the attacker's browser.  If th= e victim's
request arrives first the victim will be logged in but, ifthe application takes no precautions, it may later log in
the attacker = too.

> The social site most likely has a large number of API
&= gt; endpoints, providing only one pkauth-subsequent-access does
> not= scale. Or maybe I misunderstood the purpose of
> pkauth-subsequent-a= ccess.

Very true.  That was silly of me.  The protocol doe= s not
need a pkauth-subsequent-access endpoint.  Once the
applic= ation has the authorization token it can send it to
any API endpoint for subsequent access.

> PKAuth would work only for web= applications and compared to
> OAuth 2 it raises the bar for them: t= hey need an SSL cert
> and also an API endpoint. Especially web app o= nly, is a very
> strong limitation.

Here I have to disagree.&n= bsp;

First, in OAuth the client is also a Web application, isn'tit?  What else could it be? 

Second, an SSL cert is a re= quirement for any Web application
that authenticates its users, isn't it= ? 

Third, what's the problem with an API endpoint?  I ass= ume
that by "API endpoint" you mean an endpoint that does not
return = a Web page to be displayed by a browser.  Well, it's
a lot easier t= o implement an endpoint that does not return a
Web page than one that do= es.  The PKAuth application has two
such endpoints, the application= authentication endpoint and
the direct callback endpoint.  The application
authentication endpoint can be as simple as the URL of = a
static text file with two lines providing the URLs of the
direct an= d redirect callback endpoints.  The direct callback
endpoint receiv= es data and stores it in a database record.
How long does it take to imp= lement that?  One hour?

Actually, I argue that PKAuth is simple= r than OAuth because
it does not require an intermediate token.  In= OAuth two
tokens are needed (the access grant and the access token)
= precisely because of the danger that the first token, send
by redirectio= n, may fall into the wrong hands.  In the case
of a registered appl= ication, the first token is exchanged
for the second token only after th= e appplication has proved
its identity.  But if the application is = unregistered, the
exchange provides no security.  In PKAuth there i= s only one
token, which is sent to the direct callback endpoint and
does not run the risk of falling into the wrong hands.  I'veadded this argument to the paper.

Again, thanks a lot!

Fran= cisco

--0-885575584-1293169091=:14666-- From rs@dailymotion.com Wed Dec 29 07:33: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 093DC28C10B for ; Wed, 29 Dec 2010 07:33:07 -0800 (PST) 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 D0+-7lnb5eXy for ; Wed, 29 Dec 2010 07:33:05 -0800 (PST) Received: from intsvc-01.dailymotion.com (intsvc-01.dailymotion.com [195.8.215.87]) by core3.amsl.com (Postfix) with ESMTP id 301D428C0FB for ; Wed, 29 Dec 2010 07:33:05 -0800 (PST) Received: from EXCHANGE-02.daily.local (unknown [195.8.215.118]) by intsvc-01.dailymotion.com (Postfix) with ESMTP id E8C0D48D73; Wed, 29 Dec 2010 16:35:09 +0100 (CET) Received: from EXCHANGE-02.daily.local ([195.8.215.118]) by exchange-02 ([195.8.215.118]) with mapi; Wed, 29 Dec 2010 16:31:04 +0100 From: Olivier POITREY To: Marius Scurtescu Date: Wed, 29 Dec 2010 16:35:08 +0100 Thread-Topic: [OAUTH-WG] expires_at vs expires_in Thread-Index: AcunbWf4q+JWcF5qQ7K6z6Xk1FvlRw== Message-ID: <6B589E6C-892D-432F-8C91-83A2907E8255@dailymotion.com> References: <3772D688-B518-4956-A763-B8E80E1A677E@dailymotion.com> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Walker , OAuth WG Subject: Re: [OAUTH-WG] expires_at vs expires_in X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Dec 2010 15:33:07 -0000 I know the expiration time is just a hint, but it's a useful hint to save c= lients and servers from many requests leading to 401 errors. If we can find= a solution to make this hint more reliable in all use-cases, why not do it= ? The problem here arises when you acquire an oauth session from javascript (= using the user-agent profile) and want to share your session with the backe= nd. This use-case is used by facebook connect for example, where a signatur= e is added to the session and shared via cookies so that backend code can v= alidate that the session is not forged. The issue is that javascript relies on the user-agent's host clock, which i= s more likely than a server to be incorrectly synchronized. Facebook doesn'= t follow the OAuth 2.0 spec on expiration definition: they don't use expire= s_in, but expires with an absolute unix timestamp. This expires value can t= hen be shared with the backend as-is, but the user-agent can't use it as it= can't rely on the local clock. Facebook javascript SDK uses a fixed hard-c= oded refresh timer instead, which is perfectly acceptable in their case as = they control both ends of the protocol. Here is the code from connect-js handing client side expiration: if (FB.Auth._loadState && session && session.expires) { // refresh every 20 minutes. we don't rely on the expires time because // then we would also need to rely on the local time available in JS // which is often incorrect. FB.Auth._refreshTimer =3D window.setTimeout(function() { FB.getLoginStatus(null, true); // force refresh }, 1200000); // 20 minutes } IMHO, this is not a viable solution for an auth protocol in which the clien= t isn't developed by the same entity as the server implementation. It's why= I propose to include both representations of the expiration time: the rela= tive and the absolute forms. The relative form can be used by the original = requestor of the session because it knows exactly (minus the request round-= trip time) when the session was created, and can compute the expiration tim= e without worrying about its clock. But this computed expiration time can o= nly be considered valid by the entity which computed it. For sharing the se= ssion, the expiration time computed by the server is more viable and should= be used instead. In our facebook connect use-case, the javascript library would use the expi= res_in to compute the local expiration time of the session and the backend = would use the expires_at value when using the session shared by the javascr= ipt library. On 23 d=E9c. 2010, at 19:11, Marius Scurtescu wrote: > This expiration time is just a hint, client code should work perfectly > fine without it, or with a wrong one. >=20 > Trying to understand the use case here: JavaScript code receives an > access token and the associated expires_in. It passes the access token > to backend code, and this backend code is properly time synchronized > and it needs to know when does the token expire. Right? Is the > JavaScript code passing the access token down right away, or only > after a while? If right away, then the backend code can just use > expires_in as an offset from current time. It will be a few seconds > off, but that should be acceptable IMO. >=20 > Marius >=20 >=20 >=20 > On Thu, Dec 23, 2010 at 2:43 AM, Olivier POITREY wro= te: >> You can't access it from JavaScript in most use-cases unfortunately. It'= s >> why having both expires_in and expires_at would be nice. >>=20 >> On 23 d=E9c. 2010, at 11:36, "Pelle Wessman" wrote: >>=20 >> For the Web Server flow you will have a HTTP Date header containing the >> timestamp at which the token was generated - right? Combining the value = of >> that header with expires_in will get you the value of expires_at. >>=20 >> / Pelle >>=20 >> On Tue, Dec 14, 2010 at 10:14 PM, Paul Walker wrote= : >>>=20 >>> Has there been discussion of using expires_at as an exact epoch time in >>> seconds as opposed to expires_in which is, at best, an approximation "f= rom >>> the time the response was generated by the authorization server?" I >>> apologize if this has been discussed previously. >>>=20 >>> ~pj >>> _______________________________________________ >>> 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 >>=20 >>=20 From mscurtescu@google.com Wed Dec 29 14: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 A8C8728C11E for ; Wed, 29 Dec 2010 14:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.934 X-Spam-Level: X-Spam-Status: No, score=-105.934 tagged_above=-999 required=5 tests=[AWL=-3.957, 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 rzLOnQbkWVBl for ; Wed, 29 Dec 2010 14:04:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 2941B28C11B for ; Wed, 29 Dec 2010 14:04:20 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id oBTM6OIH003118 for ; Wed, 29 Dec 2010 14:06:24 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293660384; bh=Lr63mbZ9crvqtmspdD3U51KiAUs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=xFunddHigmIzETgQq4+MYx0kvqLmrRvIGMvX7KetXw3u7Jdvs6TV97PkILnAvlkJi M2BRKGiXgc9Ouwe5GUbLw== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by kpbe16.cbf.corp.google.com with ESMTP id oBTM6Mu9003866 for ; Wed, 29 Dec 2010 14:06:22 -0800 Received: by gwaa12 with SMTP id a12so2044075gwa.6 for ; Wed, 29 Dec 2010 14:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=pBFUaaQkXJugPWRYDetzJx3z300wmLYdB28SwE91Zbs=; b=V0w005CZBMW+excSA+TNoZfpiY9i50V0/TGFydniJ8BKfWKrknEQ6ee0un4xWT9o8p hrRwuwIiHIMw+2Ab5rDA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=A76k4RXLJINx9qWyNWMOcOshwMLQsidTz9g26vlpPevwEXfxAiFz7YE1NmhHPn/iFT j14MK+m5o7T40WF71ang== Received: by 10.100.10.20 with SMTP id 20mr8751817anj.264.1293660382143; Wed, 29 Dec 2010 14:06:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Wed, 29 Dec 2010 14:06:02 -0800 (PST) In-Reply-To: <711776.14666.qm@web55806.mail.re3.yahoo.com> References: <711776.14666.qm@web55806.mail.re3.yahoo.com> From: Marius Scurtescu Date: Wed, 29 Dec 2010 14:06:02 -0800 Message-ID: To: fcorella@pomcor.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Dec 2010 22:04:22 -0000 On Thu, Dec 23, 2010 at 9:38 PM, Francisco Corella wr= ote: > Thank you very much for your detailed reading of the paper > and your very useful comments.=A0 I've revised the paper based > on your comments and put a new version online, with an > acknowledgment of your contribution. I'm glad you found the comments useful, not sure I really deserve to be mentioned. > > PKAuth seems similar to OAuth 2, I think it would help if you used the = same terminology: > > - application =3D> client > > - social site =3D> authorization server > > - client =3D> end user > > - reference code =3D> authorization code > > PKAuth provides the functionality of both OAuth and OpenID, > which use different terminologies.=A0 And OAuth 1.0 and RFC > 5849 also have different terminologies, which people still > seem to be using.=A0 So there are 4 different "formal" > terminologies.=A0 I decided to use an "informal" one, at least > at this early stage, that can be understood without having > to look up definitions in a terminology section. Yeah, really confusing as is. I just thought it would help if you used one of the existing terminologies. > I did not mean to use "client" for "end user".=A0 I've rechecked > the paper and I see that I used "client" once, by mistake, > where I should have said "application".=A0 That must have been > confusing.=A0 I've fixed it. > > > The paper claims that users do not know how to interpret > > domain names, which is probably true. Is there any evidence > > that users are doing better with names as found in SSL > > certificates? > > I don't know of any evidence, but that's because users do > not usually see the information in the certificate.=A0 I said > in the abstract that browsers display certificate > information, but that was a mistake: the user has to do some > clicking to see it.=A0 The browser does not have real estate > to display certificate info without clicking, but in PKAuth > the social site has plenty of real estate in the page where > it asks the user whether the application is to be trusted. > So this is a new way of using the information in the > certificate.=A0 It would be interesting to do a study to see > how much it helps. > > > Discovery is based on link tags in HTML pages, did you > > consider using /.well-known/host-meta instead? > > To be honest, I was not aware of that.=A0 Now I've looked at > it and I see that that it would make it possible to support > multiple social sites having URLs with the same host name. > But on the other hand it adds complexity, and I was trying > to keep the protocol as simple as possible, so I'm not sure > if it's a good idea. I don't think it adds much complexity. And for implementors it is a big help, much simpler to implement /.well-known/host-meta. Imagine asking a large website to add a few HTML tags to every single request to / as opposed to adding a special file. > > At step 1, the difference between official-name and > > alternative-name can only be "www.". Why not just follow > > redirects? > > You're very right, the social site should redirect from > https://alternative-name to https://official-name rather > providing a PKAuth link element in > https://alternative-name.=A0 I've fixed that. > > > Not sure I understand why the reference code must be > > generated by the social site, how would session fixation > > work if it was generated by the application? > > Suppose the protocol requires the application to send the > reference code as an additional parameter in step 2.=A0 Here > is the attack scenario.=A0 The attacker is a Web user who does > not have an account at the application nor at the social > site.=A0 The attacker takes advantage of a victim who has an > account at both the application and the social site.=A0 The > attacker makes a login request to the application, and > chooses to use the social site for authentication.=A0 The > application provides a response that redirects to the site. > The attacker uses an ad-hoc user agent that does not follow > up on the redirect, but reports instead the redirect URL, > which contains the reference code, to the attacker.=A0 The > attacker creates a link whose target is the redirect URL, > places it on a Web page, and tricks the victim into clicking > on the link.=A0 The social site authenticates the victim (step > 4), sends the reference code, authorization token, etc., to > the direct callback endpoint of the application (step 5), > then sends the reference code, etc., to the redirect > callback endpoint by redirecting the victim's browser (step > 7).=A0 But the attacker knows the reference code and can send > the same request to the redirect callback endpoint.=A0 So the > victim and the attacker both send a request with the > reference code to the redirect callback endpoint.=A0 In step > 8, when the application receives a request at the redirect > callback endpoint, it uses the reference code to locate the > authorization code and other info received earlier through > the direct callback endpoint, and it logs in the user and > sets an authentication cookie in the user's browser.=A0 If the > attacker's request arrives before the victim's request, the > attacker will be logged in and an authentication cookie will > be placed in the attacker's browser.=A0 If the victim's > request arrives first the victim will be logged in but, if > the application takes no precautions, it may later log in > the attacker too. Got it, thanks. > > The social site most likely has a large number of API > > endpoints, providing only one pkauth-subsequent-access does > > not scale. Or maybe I misunderstood the purpose of > > pkauth-subsequent-access. > > Very true.=A0 That was silly of me.=A0 The protocol does not > need a pkauth-subsequent-access endpoint.=A0 Once the > application has the authorization token it can send it to > any API endpoint for subsequent access. > > > PKAuth would work only for web applications and compared to > > OAuth 2 it raises the bar for them: they need an SSL cert > > and also an API endpoint. Especially web app only, is a very > > strong limitation. > > Here I have to disagree. > > First, in OAuth the client is also a Web application, isn't > it?=A0 What else could it be? A native app, a JavaScript widget, a device. https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth/ > Second, an SSL cert is a requirement for any Web application > that authenticates its users, isn't it? > > Third, what's the problem with an API endpoint?=A0 I assume > that by "API endpoint" you mean an endpoint that does not > return a Web page to be displayed by a browser.=A0 Well, it's > a lot easier to implement an endpoint that does not return a > Web page than one that does.=A0 The PKAuth application has two > such endpoints, the application authentication endpoint and > the direct callback endpoint.=A0 The application > authentication endpoint can be as simple as the URL of a > static text file with two lines providing the URLs of the > direct and redirect callback endpoints.=A0 The direct callback > endpoint receives data and stores it in a database record. > How long does it take to implement that?=A0 One hour? > > Actually, I argue that PKAuth is simpler than OAuth because > it does not require an intermediate token.=A0 In OAuth two > tokens are needed (the access grant and the access token) > precisely because of the danger that the first token, send > by redirection, may fall into the wrong hands.=A0 In the case > of a registered application, the first token is exchanged > for the second token only after the appplication has proved > its identity.=A0 But if the application is unregistered, the > exchange provides no security.=A0 In PKAuth there is only one > token, which is sent to the direct callback endpoint and > does not run the risk of falling into the wrong hands.=A0 I've > added this argument to the paper. I think you still have two tokens, the reference code (similar to the authorization code in OAuth 2) and an authorization token (access / refresh token in OAuth 2). Marius From mscurtescu@google.com Wed Dec 29 14:38: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 574003A68C0 for ; Wed, 29 Dec 2010 14:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.373 X-Spam-Level: X-Spam-Status: No, score=-105.373 tagged_above=-999 required=5 tests=[AWL=-3.529, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, 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 0wUYf3tF6y-z for ; Wed, 29 Dec 2010 14:38:56 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id D3E843A68AE for ; Wed, 29 Dec 2010 14:38:55 -0800 (PST) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id oBTMf02u014468 for ; Wed, 29 Dec 2010 14:41:00 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293662460; bh=/tk6Fv2d1hlSzZRZ4X/7zzNW3qo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=BwwsrRju2bQn7G0Ud4xwNtPvw7H/dq2125ktMArGYw1l+WWF3ZO7eTHq40ENwUrkf SMAvE+TRlLIi07unqgIQA== Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by hpaq13.eem.corp.google.com with ESMTP id oBTMewIN001712 for ; Wed, 29 Dec 2010 14:40:59 -0800 Received: by yxt3 with SMTP id 3so4296941yxt.19 for ; Wed, 29 Dec 2010 14:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=qz7asgop5I/YAa0xGrcoV/sQVzkDUOyP/kbOJcDul3A=; b=Krfqa/umq4XjChBbPv9fl7uyFGg/d5Mkax7+uXvSLe+CaCYWzjAQ1CJxo/t7KG9Npo 4Y9dBGguutDA5heb/MWw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=iUzgWHnXCEKDCf9hlS2xWR8TEQ1Y+FH5E/jM7U4uZD2nUvIjuf5t1U2j0rXqz8CPiz A4kSx6NmjUzbIGD2flpA== Received: by 10.101.179.30 with SMTP id g30mr8813730anp.196.1293662457064; Wed, 29 Dec 2010 14:40:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Wed, 29 Dec 2010 14:40:36 -0800 (PST) In-Reply-To: References: From: Marius Scurtescu Date: Wed, 29 Dec 2010 14:40:36 -0800 Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Dec 2010 22:38:57 -0000 Hi David, A few suggestions for this extension. I am assuming that you will update it soon to conform to draft 11 of the core protocol. 1. Instead of passing an assertion why not treat it as another grant type and pass all parameters as POST parameters. For example: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dhttp%3A%2F%2Foauth.net%2Ftoken%2F1.0& oauth_token=3DrjmaGaw9ATW& oauth_token_secret=3DOgFcfEjBR& client_id=3D8eSEIpnqmM& client_secret=3Ds6BhdRkqt3 2. I think it should also require the OAuth 1 consumer key and secret. Maybe the assumption was that these are the same as the OAuth 2 client id and secret, but that may not always be the case. Example: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=3Dhttp%3A%2F%2Foauth.net%2Ftoken%2F1.0& oauth_token=3DrjmaGaw9ATW& oauth_token_secret=3DOgFcfEjBR& oauth_consumer_key=3D8eSEIpnqmM& oauth_consumer_secret=3Ds6BhdRkqt3 client_id=3D8eSEIpnqmM& client_secret=3Ds6BhdRkqt3 Marius On Fri, Aug 27, 2010 at 1:26 PM, David Recordon wrote= : > This draft is now an Internet Draft and I'm curious if anyone has any > feedback on > it?=A0http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00 > I'd also like to request that this draft moves to become a Working Group > item. I'm am happy to act as the editor unless someone else wishes to do = so > moving forward. > Thanks, > --David > > On Mon, Jul 12, 2010 at 10:39 PM, David Recordon > wrote: >> >> The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access >> tokens has come up on the list a few times. Attached is a draft assertio= n >> format which allows a client to trade an OAuth 1.0 token/secret pair for= an >> OAuth 2.0 access token. The assertion format is a JSON object with value= s >> for the token and token secret. My goal is that this draft become a work= ing >> group document. >> A question for the group is if upgrading multiple tokens at once is >> a=A0necessary=A0use case? The assertion format within the core spec only >> supports issuing a single access token. Facebook has a custom endpoint w= hich >> allows upgrading multiple tokens at once, but I don't actually have data >> about how many developers make use of that functionality. >> Thanks, >> --David > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From mscurtescu@google.com Wed Dec 29 14: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 F02763A68C2 for ; Wed, 29 Dec 2010 14:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.047 X-Spam-Level: X-Spam-Status: No, score=-105.047 tagged_above=-999 required=5 tests=[AWL=-3.070, 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 zYErDw9nS9pi for ; Wed, 29 Dec 2010 14:52:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 83DC23A68C0 for ; Wed, 29 Dec 2010 14:52:02 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id oBTMs7Mj031242 for ; Wed, 29 Dec 2010 14:54:07 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293663247; bh=115MOL1YToMDjUT3tBGf+R47TS8=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=UMlNPJh24OZqwATaTEK2L3GY+fmPz7M8jfWMpKnyydSI3N8nc3di3OTnaFo8M+HHA ZVz9fwB4CXWmLWk+NBOrA== Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by wpaz5.hot.corp.google.com with ESMTP id oBTMs5Xr031888 for ; Wed, 29 Dec 2010 14:54:06 -0800 Received: by yib12 with SMTP id 12so2075368yib.10 for ; Wed, 29 Dec 2010 14:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=KIhLEDnbekBpW66YHJqTMet/7S/4XXzJrJWDePlUe4E=; b=FFYxCQ2oZ3+nlTGaRouNFnFyxsJLG9h7sE6BSDCYMKOEJfrLCBVycjivLEpnBh2iUz u9cxGTHRZ7C1KqiDEqFA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=sKj5zT2iISz7nElr0Ijt+DtiiJnPeZqn7SrSbNzjhvv2i2leFUFBM2YekGpeITVNRE YPf0i6CX0TrEDg0tN0/g== Received: by 10.100.31.9 with SMTP id e9mr8822045ane.162.1293663245506; Wed, 29 Dec 2010 14:54:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.34.4 with HTTP; Wed, 29 Dec 2010 14:53:45 -0800 (PST) From: Marius Scurtescu Date: Wed, 29 Dec 2010 14:53:45 -0800 Message-ID: To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] Native Client Extension X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Dec 2010 22:52:04 -0000 I would like to propose an OAuth 2 extension that helps native clients close the loop after the approval page. The extension defines a special value for the redirect URI for the case when the client does not have such a URI and it also defines that the authorization server should provide a default result page for this case and how to format the result on this page. If a native client does not have a redirect URI then the client can specify the special value "oob" for that parameter. redirect_uri=oob signals to the authorization server that it should use a default result page to show the final result. In this case the authorization server cannot redirect any kind of messages back to the client, not even error responses. The default result page should show the authorization code (code) and instruct the user to copy to native application. The default result page should also show both the authorization code and the passed through client state (state) in the page title, the two parameters should be form-encoded and appear space separated at the end of the normal title Example page title: Success code=123456&state=qwerty Browsers will truncate the title at some browser and OS dependent length. Ideally the whole title should be shorter than 100 characters. The Authorization Server should use a short title prefix and it should make the authorization codes as short as possible. Native clients should try to pass very short state strings and only of really needed. If the user denies, or there are other errors, the default page should similarly display the error code and also put the error message in the title: Denied error=access_denied&state=qwerty References: * Section 6.3.3.2 of draft-hardt-oauth-wrap-01 If there is interest and rough consensus then I can create a formal version of this extension. Thanks, Marius